ownCloudモバイルアプリの「接続拒否」エラーを修正する方法

ownCloudモバイルアプリで「接続拒否」メッセージが表示される場合、通常は認証開始前の接続問題を示しています。つまり、端末はアドレスに到達したものの、要求されたネットワークエンドポイントで接続が受け入れられなかったということです。メッセージの文言はAndroidまたはiOSのバージョンによって異なる場合があるため、このメッセージは診断ではなく症状として捉えてください。

あくまで例示シナリオです。Northstar Studioという小規模なデザイン会社を想像してみてください。同社のスタッフは通常、https://cloud.example.com/owncloudownCloudモバイルアプリから接続しています。リバースプロキシの変更後、複数の端末で「接続拒否」と表示されるようになりました。ownCloudのWebインターフェースは、オフィス内の管理者用ノートパソコンからは引き続き動作しますが、モバイルデータからは動作しません。この架空のシナリオは、トラブルシューティングの手順がどのように連携するかを示すためにガイド全体を通して使用されます。これは実際の導入事例やテスト結果の報告ではありません。

まず、「接続拒否」エラーとログインエラーを区別する

ユーザーのパスワードをリセットすることから始めないでください。パスワードの間違い、トークンの有効期限切れ、またはOAuthの問題は、クライアントがサーバーと通信できるようになった後に発生します。TCP接続の拒否は、ホストまたはポートの間違い、Webサーバーまたはプロキシの停止、ファイアウォールルール、または内部インターフェースのみでリッスンしているサービスに関連していることが多いです。

ownCloudの最新のモバイル向けドキュメントでは、アプリはownCloudサーバーのURLで構成されていることが確認されています。また、ownCloudのWebDAVドキュメントでは、モバイルアプリはWebDAVエンドポイントを手動で入力するのではなく、<URL>などのベースURLとフォルダを使用する必要があると記載されています。ownCloudのWebDAVアクセスに関するドキュメントexample.com/owncloudを参照してください。

1. モバイルアプリでURLを確認してください

Northstar の例では、期待される URL は ですhttps://cloud.example.com/owncloud。スキーム、ホスト名、オプションのポート、パスの 4 つのコンポーネントすべてを確認してください。よくある間違いとしては、http://パブリック サービスが HTTPS でのみリッスンしているのに を使用したり、標準以外のポートを省略したり、オフィス外から解決できない内部ホスト名を使用したり、ownCloud のベース URL の代わりに DAV エンドポイントを入力したりすることが挙げられます。

Android版のドキュメントによると、サーバーURLと認証情報を入力した後、アプリは接続テストを実行し、HTTPS接続のためにSSL対応サーバーの使用を推奨しています。iOS版のドキュメントでも同様に、アカウント追加時にサーバーURL、認証方法、TLS証明書を確認します。詳しくは、ownCloud Android版接続ガイドとownCloud iOS版アカウントガイドをご覧ください。

2. アプリ外で同じURLをテストする

影響を受けている端末で、ブラウザでownCloudの正確なURLを開いてください。これが問題の切り分けになります。ブラウザではownCloudページが読み込めるのにアプリでは読み込めない場合は、アプリ固有の証明書、リダイレクト、OAuth、またはアカウント設定を調査してください。ブラウザとアプリの両方で同じネットワーク上でエラーが発生する場合は、サーバーとネットワークのチェックを続けてください。

複数のネットワークからテストしてください。例として挙げたNorthstarのケースでは、オフィスのWi-Fiは動作しますが、モバイルデータ通信は失敗します。これは、ownCloudのユーザー名の問題ではなく、パブリックDNS、ファイアウォール、NAT、またはリバースプロキシの露出に問題があることを示唆しています。

3. 公開エンドポイントが実際にリッスンしていることを確認します。

サーバーにアクセスできるマシンから、URLとリスニングソケットをテストしてください。以下のようなコマンドが参考になります。

curl -I https://cloud.example.com/owncloud
sudo ss -tlnp | grep -E ':80|:443'

HTTPレスポンスが成功した場合、必ずしもリダイレクトである必要はありません200。リダイレクトによっても、Webサービスが応答していることがわかります。重要なのは、TCP接続が受け入れられているかどうかです。想定される公開ポートで何もリッスンしていない場合は、ownCloudアプリケーションの設定を変更する前に、その問題を修正してください。

4. Webサーバーまたはリバースプロキシを確認する

ownCloudの多くのデプロイメントでは、Apache、NGINX、HAProxy、Traefik、またはその他のプロキシがアプリケーションの前に配置されています。公開サービスが実行され、意図したインターフェースにバインドされ、トラフィックが実際のownCloudバックエンドに転送されていることを確認してください。プロキシが停止している、特定のポートにのみバインドされている127.0.0.1、または間違ったアップストリームポートに設定されていると、即座に拒否される可能性があります。

ownCloud はリバースプロキシについて明示的に説明しており、ownCloud が信頼するプロキシ アドレスは設定ファイルで構成する必要がありますtrusted_proxies。また、プロキシの背後でホスト名、プロトコル、またはウェブルートの自動検出が失敗した場合の上書き設定についても説明しています。ownCloudのリバースプロキシ構成ガイドを参照してください。

5. ファイアウォール、NAT、およびネットワークパスを確認する

サーバー自体ではHTTPSが機能するのに、LAN外の電話からは機能しない場合は、ホストファイアウォール、クラウドセキュリティグループ、ルーターまたはNATルール、および上流の企業ファイアウォールを確認してください。通常のHTTPS展開では、パブリックアドレスでTCP 443にアクセスできる必要があります。カスタムポートを意図的に使用する場合は、そのポート番号を公開し、URLに含める必要があります。

恒久的な解決策としてファイアウォールを無効にしないでください。代わりに、必要なリスナーを特定し、設計に必要なトラフィックのみを許可してください。Northstar のシナリオでは、「ファイアウォールは有効ですか？」ではなく、「外部クライアントは ownCloud 用に公開されているアドレスとポートに到達できますか？」という質問が役立ちます。

6. ポートに到達可能になったら、TLS証明書とリダイレクトを確認します。

証明書の問題は、文字通りのTCP拒否とは異なりますが、到達可能性を修正した直後に発生することがよくあります。現在のiOSのドキュメントによると、アプリはサーバーを追加する際にTLS証明書をチェックし、ユーザーが証明書の詳細を確認できるようになっています。Androidのドキュメントにも、検証できない証明書に関する警告が記載されています。

可能な限り、ホスト名がownCloudの公開ホスト名と一致し、証明書チェーンがデバイスによって信頼されている証明書を使用してください。また、HTTPからHTTPSへのリダイレクトについても確認してください。iOSのセキュリティドキュメントには、ログイン中のリダイレクトは自動的に実行されるのではなく、ユーザーに承認を求めると記載されています。ownCloudのiOSセキュリティドキュメントを参照してください。

7. ownCloudの信頼済みドメインとプロキシURLの処理を確認する

ウェブサーバーが接続を受け入れたら、ownCloudがスマートフォンで使用されているホスト名を認識していることを確認してください。ownCloudでは、サーバーへのアクセスに使用されるURLが許可されている必要がありますtrusted_domains。これは、新しいパブリックホスト名を導入する場合、サービスを移行する場合、または以前は内部インストールだったものを公開する場合に重要になります。

従来のインストールでは、設定を盲目的に編集するのではなく、内容を確認してください。occ設定済みのドメインを読み取るには、次のツールを使用できます。

sudo -u www-data ./occ config:system:get trusted_domains

パブリックホスト名が欠落している場合は、occ config:system:set未使用の配列インデックスのドキュメントに記載されている構文を使用して追加してください。公式のコマンドリファレンスは、ownCloud occ コマンドのドキュメントOWNCLOUD_TRUSTED_DOMAINSで確認できます。コンテナデプロイメントの場合、現在の ownCloud ドキュメントでは、環境変数などを介して同等のドメインおよびプロキシ関連の設定を公開していますOWNCLOUD_TRUSTED_PROXIES。

8. 元の電話機で再テストを行い、結果を比較する

影響を受けたデバイスに戻り、以下の手順でテストを行ってください。まず、ブラウザでURLを読み込み、次にownCloudアカウントを追加または再接続し、最後にファイルビューを開いてディレクトリ一覧が表示されることを確認します。サービスがWi-Fiとモバイルデータの両方で動作するように設計されている場合は、Wi-Fiとモバイルデータでそれぞれ1回ずつ繰り返してください。

Northstarの例では、管理者が、代替のリバースプロキシがプライベートインターフェースのポート443でのみリッスンしていることを発見したとします。パブリックリスナーを正しくバインドすれば、オフィスへのアクセスは機能するのに携帯電話からのアクセスが拒否された理由が説明できます。これは推論プロセスを示す例であり、実際のownCloudのインシデントに関する主張ではありません。

クイック診断表

まず最初に変えてはいけないこと

モバイルアプリに「接続拒否」と表示されたからといって、パスワード、データベース設定、ファイル権限、PHPメモリ制限などを変更しないでください。これらの設定はownCloudの他の障害の原因となる可能性はありますが、クライアントがネットワーク接続を全く確立できない場合に最初に調査すべき箇所ではありません。同様に、公開TLS構成を修正する代わりに、証明書の警告を恒久的に回避することも避けてください。

最終確認チェックリスト

• 電話機は、正しいスキーム、ホスト名、パス、および該当する場合は非標準ポートを含む、意図されたownCloudベースURLを使用します。
• 電話機が接続されているネットワークからホスト名は正しく解決されます。
• パブリックWebサーバーまたはリバースプロキシが、想定されるTCPポートで待機しています。
• ホスト、クラウド、ルーター、および上流のファイアウォールは、意図したトラフィックを許可します。
• リバースプロキシはownCloudのバックエンドにアクセスできます。
• TLS証明書は公開ホスト名に適しており、デバイスによって受け入れられています。
• ホスト名はownCloudの信頼済みドメイン設定に含まれています。
• ウェブインターフェースとモバイルアプリはどちらも、展開先がサポートするすべてのネットワークで動作します。

2026年10月現在、ownCloudはClassicサーバーと、AndroidおよびiOSモバイルクライアントそれぞれに関する最新のドキュメントを公開しています。アプリのリリースごとにラベルや画面表示が変わる可能性があるため、上記のトラブルシューティング手順を確実な方法としてご利用ください。まずネットワーク接続性を確認し、次にプロキシとTLSの動作を検証してから、ownCloudアプリケーションと認証設定に進んでください。