なぜウェブアクセスはできるのにモバイルアプリの同期が失敗するのか?

エヴァ・ウォンテクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

モバイル同期が失敗してもウェブアクセスが機能するのは、アプリが異なるAPI、信頼ルール、トークン、バックグラウンドのネットワーク動作を使用しているためです。

ブラウザは通常のHTTPSを通じてログインページを読み込む一方で、モバイルアプリはWebDAV、REST、ファイルトークン、通知、チャンクアップロード、バックグラウンド同期のエンドポイントを呼び出し、これらは異なるプロキシ経路や証明書チェックに従います。診断ではアプリの正確な失敗リクエストをキャプチャし、ブラウザの経路と比較し、TLS、URL生成、トークン、モバイルの権限、ネットワーク状況を個別にテストする必要があります。

どのモバイル操作が失敗しているか特定する

ログイン、ファイル一覧表示、ダウンロード、アップロード、自動アップロード、バックグラウンド同期、プレビュー、通知、共有を分けて考えます。失敗した操作について、アプリのバージョン、OS、ネットワーク、エラー、タイムスタンプ、サーバーログのエントリを記録してください。

Seafileの事例では、ブラウザは正常に動作していたのに対し、モバイルアプリはスペースを含むファイル名で失敗しました。これはアプリが異なるファイルAPIパスを使用しており、プロキシがそれを拒否したためです。

もし一つの操作だけが失敗している場合は、サーバー全体を再インストールしないでください。まず失敗しているエンドポイントとメソッドを特定しましょう。ダッシュボードが動作していれば、WebDAVアップロードやモバイルトークンのダウンロードは問題ないことが証明されます。

ブラウザUI外でアプリのエンドポイントをテストする

モバイルクライアントが使用する同期、WebDAV、API、またはファイルサーバーのURLを見つけます。同じホスト名と認証情報を保持したまま、適切なクライアントやリクエストツールでそのエンドポイントを直接テストしてください。

Nextcloudの報告によると、ファイル一覧表示や自動アップロードはアクティビティや通知APIとは異なるURLを使うことがあり、API URL設定の誤りがアプリの一部機能だけに影響を与えることがあります。

APIエンドポイントが404、405、400、または内部ホストへのリダイレクトを返す場合は、プロキシのルーティングやアプリケーションのベースURLを確認してください。アプリ外で動作するなら、TLSの信頼、アプリのトークン、モバイルOSのポリシーを続けて調査します。

モバイルのTLS信頼とブラウザの信頼を比較する

証明書チェーン全体、ホスト名、有効期限、中間証明書、アプリがIPv4またはIPv6経由で接続しているかを調べます。ブラウザは中間証明書をキャッシュしたり、ユーザー例外を許可することがありますが、モバイルアプリは共有しない場合があります。

Joplinのモバイル事例では、デスクトップではWebDAVが動作していたのにモバイルで失敗したのは、iOSがプレーンHTTPや信頼されていない証明書を拒否したためであり、モバイルのTLSポリシーがブラウザの挙動と異なることを示しています。

検証を無効にするのではなく、公開された信頼済み証明書か正しくインストールされたプライベートCAを使用してください。証明書の識別範囲外のプライベートIPではなく、正確な同期ホスト名をテストしましょう。

プロキシ経路、リクエストサイズ、エンコーディングを確認する

ブラウザの操作1件とモバイル同期の操作1件のプロキシログを比較します。メソッド、パス、リクエストサイズ、ステータス、アップストリーム、タイムアウト、エンコードされたURL、WebDAV動詞、チャンクアップロードをブロックするセキュリティルールを記録してください。

モバイルアプリはPROPFINDPUT、トークン化されたダウンロードURL、レンジ指定、チャンクエンドポイントを使うことがあり、通常のウェブUIはこれらを使いません。ブラウザのGETやPOSTは許可しても、これらのメソッドやパスはプロキシが拒否することがあります。

必要なルート、メソッド、制限、タイムアウトだけを追加してください。モバイルの1リクエストが失敗したからといってプロキシの全セキュリティを無効にせず、正確なリクエストを再現して狭い範囲で修正を検証しましょう。

アプリのトークンと正規のサーバーURLを更新する

アプリに保存されているサーバーURLと現在の公開または内部の正規URLを比較します。まずメインアカウントのパスワードを変更するのではなく、アプリ固有のパスワードやトークンを1つ取り消して再作成してください。

モバイルクライアントはサーバー移行後に古いポート、HTTP URL、内部アドレス、期限切れトークン、以前のリバースプロキシパスを保持していることがあります。ブラウザはリダイレクトに成功しても、同期クライアントは古いエンドポイントを呼び続けることがあります。

未同期のモバイルデータをエクスポートまたは保護した後、テスト用デバイスからアカウントを削除してください。正規のHTTPSドメインで再追加し、サーバーが新しいトークンを発行することを確認してからアップロードとダウンロードをテストします。

モバイルのバックグラウンドとネットワーク制限をテストする

フォアグラウンドで手動同期を実行し、画面をロックしてバックグラウンド動作をテストします。バッテリー最適化、バックグラウンドデータ、ローカルネットワーク権限、セルラー権限、VPN、プライベートDNS、Wi-Fiのみアップロードルールを確認してください。

ZimaSpaceの記事リモートプライベートクラウドの経路が異なる理由は、アプリケーション経路の失敗と基本的なブラウザアクセスの結果を区別するのに役立ちます。

問題は、アプリが意図したフォアグラウンドおよびバックグラウンド条件でログイン、ファイル一覧表示、アップロード、ダウンロード、再開、同期を行うまで解決しません。ウェブアクセスだけが動作している場合は、サーバーが一般的に正常とみなさず、モバイル固有のエンドポイントの追跡を続けてください。

サポートとヒント

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.