なぜプライベートクラウドはWi-Fiでは動作するのに、モバイルデータでは動作しないのですか？

プライベートクラウドは自宅Wi-Fiでは完璧に動作してもモバイルデータでは失敗することがあります。これは通常、プライベートクラウドアプリが壊れているわけではありません。電話が異なるネットワーク経路を使用していることを意味します。

自宅では電話はローカルIPアドレス、ローカルホスト名、またはLAN専用の検出サービスにアクセスできます。モバイルデータでは電話はパブリックドメイン、パブリックIP、VPN、トンネル、または他のリモートアクセス経路を通じてプライベートクラウドにアクセスする必要があります。DNS、ルーティング、証明書、信頼ドメイン、ファイアウォールルール、またはキャリアの挙動が間違っていると、Wi-Fiは機能してもモバイルデータは失敗します。

Wi-Fiとモバイルデータはプライベートクラウドに異なる方法で接続します

症状はよくあるものです：プライベートクラウドアプリは自宅Wi-Fiで動作し、写真のバックアップは正常に行われ、ファイル同期は接続し、ウェブUIは電話から開けます。しかし5GやLTEに切り替えるとタイムアウト、接続不可、ログイン失敗、証明書エラー、またはアプリがずっと読み込み状態になることがあります。

Wi-Fi使用時、電話とプライベートクラウドは同じLAN内にあります。接続は次のようなローカルアドレスを使用する場合があります。 192.168.1.50ローカルホスト名または自動検出。モバイルデータ使用時、電話はキャリアネットワーク上にあります。ローカル経路ではなくリモート経路を通じて自宅サーバーにアクセスする必要があります。

Wi-Fiでの成功はローカル経路が機能していることを証明します。モバイルデータでの失敗は外部経路が欠如、ブロック、誤設定、またはモバイルネットワークと互換性がないことを意味します。トラブルシューティングは内部アクセスと外部アクセスを分けて扱うべきで、一つの接続として扱うべきではありません。

アプリが自宅でしか機能しないローカルアドレスを使用している可能性があります

最も一般的な原因は最も単純です。プライベートクラウドアプリが次のようなURLで保存されている可能性があります。 http://192.168.1.50:8080, https://cloud.local, https://nas.localまたはルーターが割り当てたデバイス名。そのようなアドレスは自宅では機能しますが、他の場所では失敗します。

10.x.x.x、172.16–31.x.x、192.168.x.xなどのプライベートIPv4レンジはプライベートネットワーク用に設計されています。ローカル専用プライベートアドレスはパブリックインターネットの宛先ではないため、モバイルデータ使用時に電話から直接アクセスすることはできません。

モバイルアプリがLAN専用のURLを使用している場合、ランダムにファイアウォール設定を変更することから始めないでください。まず、モバイルアクセスにパブリックドメイン、VPNまたはメッシュVPN、またはトンネルのいずれかを使用するかどうかを決めてください。これらの経路がなければ、電話は家の中にしか存在しないアドレスにアクセスしようとしています。

内部URLと外部URLはしばしば混同されます

多くのプライベートクラウドのセットアップでは、2つの識別子が存在します。内部URLは自宅で機能し、例えば http://192.168.1.50:8080外部URLは、例えば外部からのアクセスを想定して機能することになっています。 https://cloud.example.com またはトンネルのホスト名です。

これら2つの名前は同じサービスを指すかもしれませんが、アクセス設計は異なります。内部URLはプライベートIP、ローカルDNS、または自己署名証明書を使うことがあります。外部URLはパブリックDNS、HTTPS、リバースプロキシ、ポートフォワーディング、VPNルーティング、またはトンネルを必要とすることがあります。

ブックマーク、モバイルアプリ、同期クライアント、ブラウザのショートカットがこれらの識別子を混在させると問題が発生します。モバイルデータの場合、サービスが外部からアクセス可能であれば外部URLを使用してください。すべてをプライベートに保ちたい場合は、まずVPNで接続し、その後LANアドレスを使用してください。

Wi-FiではDNSが正しく解決されても、セルラーでは失敗することがあります

ドメインが自宅では機能し、モバイルデータでは失敗するのは、電話が異なるDNSシステムに問い合わせているためです。自宅では、ルーター、Pi-hole、AdGuard Home、またはローカルDNSサーバーが解決している可能性があります。 cloud.example.com 内部IPに対して。モバイルデータでは、キャリアのDNSやパブリックDNSが異なる回答を返すか、まったく回答しないことがあります。

これはスプリットDNS構成でよくあることです。LAN内では、速度と簡便さのためにドメインはプライベートアドレスを指します。LAN外では、パブリックIP、VPNアクセス可能な名前、またはトンネルのエンドポイントを指す必要があります。外部のレコードが欠落しているか古い場合、電話はサービスを見つけられません。

Wi-Fiで動作するからといって、そのドメインが正しいと決めつけないでください。同じドメインをモバイルデータでテストし、どこに解決されるかを確認してください。内部DNSと外部DNSの結果が意図的に異なる場合は、その設計を文書化し、アプリの設定が誤った名前を使わないようにしてください。

信頼されたドメイン、ベースURL、およびリバースプロキシはモバイルアクセスを拒否することがあります

モバイルからのリクエストがサーバーに届いても、アプリが動作しないことがあります。信頼されていないドメインの警告、無効なホストエラー、ログイン失敗、リダイレクトループ、またはWebDAVの同期問題が表示されることがあります。これは通常、パスはプライベートクラウドに到達しているものの、アプリケーションが受け取った名前やプロキシヘッダーを信頼していないことを意味します。

プライベートクラウドソフトウェアは、多くの場合、明示的なホスト名とURLの設定が必要です。Nextcloudの設定リファレンスには信頼されたドメインとベースURLの設定が含まれており、リバースプロキシのドキュメントではリバースプロキシのURL検出について、自動ホスト名、プロトコル、またはウェブルートの検出が失敗した場合の対応が説明されています。

モバイルデータでログインページは読み込めるが、ログイン、リダイレクト、同期、共有リンクが失敗する場合は、アプリ設定を確認してください。外部ホスト名は信頼されているべきで、パブリックURLはユーザーが入力するものと一致し、プロキシヘッダーは正しく、HTTPからHTTPSへのリダイレクトがアプリをプライベートLANアドレスに戻さないようにしてください。

HTTPS証明書はしばしば誤ったアクセス設計を明らかにします

Wi-Fiアクセスは自己署名証明書、内部ホスト名、または数か月前に手動で承認したブラウザ警告で動作することがあります。モバイルアプリは特にファイル、写真、カレンダー、WebDAVデータのバックグラウンド同期時により厳格になることがあります。

HTTPS証明書は名前に紐づいています。アプリが接続する場合、 192.168.1.50, cloud.local証明書と異なるホスト名の場合、モバイルクライアントは接続を拒否することがあります。リバースプロキシがホスト名やプロトコルを誤って変更すると、ログイン後にアプリが失敗することもあります。

クリーンな外部設定は、有効な証明書と一致するリバースプロキシ構成を持つ安定したパブリックドメインを1つ使用します。クリーンなプライベート設定はまずVPNまたはメッシュVPNを使用し、その後内部アクセスを行います。IPアドレス、ローカル名、パブリック名、証明書の不一致を混在させると、モバイルアクセスが不安定になります。

ポートフォワーディング、VPN、またはトンネルがモバイル経路を提供しなければなりません

プライベートクラウドはWi-Fiで動作しても、モバイルデータから自動的にアクセス可能になるわけではありません。外部トラフィックにはホームネットワークやサービスエンドポイントへの意図的な経路が必要です。

一般的なパターンは3つあります。ポートフォワーディングは特定のパブリックトラフィックをルーター経由でプライベートクラウドに送ります。VPNまたはメッシュVPNはまず電話をプライベートネットワークに参加させます。リバーストンネルはサーバーがパブリックエンドポイントにアウトバウンド接続を作成し、モバイルデバイスはそのエンドポイントを通じて接続します。

個人用プライベートクラウドへのアクセスには、通常VPNまたはメッシュVPNがより安全な最初の選択肢です。他者とサービスを直接共有する場合は、HTTPS対応のパブリックドメイン、リバースプロキシ、および慎重なアクセス制御が適切な場合があります。CGNATや制限されたルーターの場合、ポートフォワーディングよりもトンネルの方が実用的です。

CGNATはポートフォワーディングが正しく見えても失敗することがあります

CGNATはフラストレーションの原因となります。家庭の設定は正しく見えることが多いからです。プライベートクラウドはWi-Fiで動作し、サーバーファイアウォールはポートを許可し、ルーターにはフォワーディングルールがあります。しかし、モバイルデータからはサービスにアクセスできません。

問題は、ルーターが実際のパブリックIPv4アドレスを持っていない可能性があることです。RFC 6598は100.64.0.0/10をCGNAT用の共有アドレス空間として予約しています。ISPがルーターをキャリアグレードNATの背後に置くと、外部からのトラフィックが家庭用ルーターに届かず、ポートフォワーディングルールが機能しません。

ルーターに表示されるWAN IPと外部のIP確認サイトに表示されるパブリックIPを比較してください。これらが一致しない場合、またはWANアドレスが共有またはプライベート範囲にある場合、従来のポートフォワーディングは適切な解決策ではない可能性があります。ISPのパブリックIPオプション、メッシュVPN、またはリバーストンネルを使用してください。

モバイルネットワークはIPv6やキャリア固有の問題を追加することがあります

一部の問題はモバイルデータでのみ発生します。同じプライベートクラウドが別のWi-Fiネットワークでは動作しても、5GやLTEでは失敗することがあります。また、あるキャリアでは動作しても別のキャリアでは動作しないこともあります。これは家庭用ルーターの範囲を超えた問題を示しています。

モバイルネットワークはIPv6専用設計、NAT64、CGNAT、キャリアDNS、APNポリシー、フィルタリング、プロキシ動作を使用することがあります。AppleのIPv6専用モバイルネットワーク互換性に関するガイダンスは、モバイルネットワークが通常のデュアルスタック家庭LANのように動作しない可能性があることを思い出させます。特にアプリやサーバーがIPv4専用の動作を前提としている場合は注意が必要です。

モバイルデータだけが問題の場合は、複数の角度からテストしてください。同じURLをモバイルブラウザで試し、別のキャリアやホットスポットをテストし、AおよびAAAAのDNSレコードを確認し、サーバーが使用しているアドレスファミリーをサポートしているか確認し、モバイルデータでVPNを試してください。VPNが動作すれば、プライベートクラウド自体は問題なく、パブリックなモバイル経路に問題がある可能性が高いです。

モバイルアプリはブラウザとは異なる動作をすることがあります

電話のブラウザとモバイルアプリは必ずしも同じ動作をするわけではありません。ブラウザはログインページを開くのに対し、アプリは同期に失敗することがあります。また、アプリはWi-Fiではサーバーをローカルで検出して動作しても、モバイルデータでは検出できずに失敗することがあります。

モバイルアプリは古いサーバーURLをキャッシュしている場合があり、HTTPSを要求し、証明書の不一致を拒否し、ブラウザページとは異なるWebDAVまたはAPIエンドポイントを使用し、バックグラウンドデータを制限し、リダイレクトの処理が異なることがあります。一部のアプリは内部用と外部用のサーバーアドレスを別々に保存していることもあり、それが明示されていない場合があります。

両方の経路を必ずテストしてください。モバイルデータ接続中に電話のブラウザで外部URLを開き、次にアプリをテストします。ブラウザも失敗する場合は、DNS、ルーティング、TLS、CGNAT、またはトンネル設定の問題の可能性が高いです。ブラウザは動作するがアプリが失敗する場合は、アプリのURL設定、信頼ドメイン、証明書、WebDAV/APIパス、アプリのキャッシュに注目してください。

VPNまたはメッシュVPNはLAN経路を復元することで問題を解決することが多いです

プライベートクラウドがWi-Fiでは動作するがモバイルデータでは動作しない場合、VPNは電話の位置を変えるため効果的な解決策となります。電話はランダムな外部クライアントとしてプライベートクラウドにアクセスするのではなく、まずプライベートネットワークに参加します。

メッシュVPNツールは、関係するネットワークに応じて直接経路またはリレー経路を使用することがあります。Tailscaleは直接またはリレー接続によるプライベートアクセスを文書化しており、モバイルデバイスがプライベートクラウドを直接インターネットに公開せずにホームサーバーにアクセスする際に役立つ情報です。

個人利用の場合、これは通常最もわかりやすいモデルです。VPN接続後、アプリは内部LANアドレスまたはプライベートDNS名を使用できます。プライベートクラウドは公開インターネットから隔離され、モバイルデバイスは内部サービスに到達する前に認証されます。

リバーストンネルはポートを開けずに外部URLが必要な場合に役立ちます

リバーストンネルは、ルーターのインバウンドポートを開けない、または開けたくない場合に便利です。これはCGNAT、制限されたISPルーター、アパートのインターネット、またはホームルーターを直接公開したくないユーザーに一般的です。

Cloudflare Tunnelはリモートアクセス用のアウトバウンドトンネルを使用しており、ネットワーク内のコネクタが外向きに接続を開始します。モバイルデバイスはトンネルを経由して戻るパブリックホスト名にアクセスします。

これによりモバイルデータへのアクセスが容易になりますが、慎重に設定する必要があります。アクセスポリシー、HTTPS、限定的なサービス公開、管理インターフェースと公開ユーザー向けサービスの分離を利用してください。トンネルは到達可能性を解決しますが、権限やアプリの設定を自動的に解決するわけではありません。

実用的なトラブルシューティングの順序

DNS、ルーターのルール、証明書、アプリ設定、モバイルネットワークが一度に変わると問題は複雑になります。より良い方法は、一層ずつテストすることです。

まずWi-Fiで動作する正確なURLを書き出します。それがプライベートIPかローカルホスト名かパブリックドメインかを判断します。次にWi-Fiを切って同じURLをモバイルデータでテストします。次に意図したパブリックドメインをテストし、パブリックDNSを確認し、ルーターのWAN IPとパブリックIPを比較し、ポートフォワーディング、VPN、トンネルの使用有無を確認し、TLS証明書と信頼ドメイン設定をチェックします。

結果は通常、問題の層を示します。ブラウザとアプリの両方が失敗する場合は、DNS、パブリック経路、CGNAT、証明書、トンネルに注目しましょう。ブラウザは動作するがアプリが失敗する場合は、アプリ設定、信頼ドメイン、WebDAV/APIエンドポイント、リダイレクト、キャッシュされたサーバーURLに注目します。モバイルデータ上のVPNが動作すれば、プライベートクラウドは正常で、外部経路に問題があります。

より安全なデフォルトは、明確なリモートアクセスパターンを一つに絞ることです

プライベートクラウドのアクセスは、LAN IP、ローカルホスト名、DDNS名、トンネルURL、古いアプリURL、リバースプロキシホスト名、誰も覚えていないブックマークなど、半端に動く入口が多すぎると信頼性が落ちます。

メインのパターンを一つ選びましょう。個人アクセスの場合、ローカルのみ＋VPNが最もシンプルです。外部からの直接アプリアクセスには、1つのパブリックドメイン、有効なHTTPS、正しい信頼ドメイン設定、安全なリバースプロキシまたはトンネルを使いましょう。CGNATの場合は、ポートフォワーディングと戦うよりトンネルやメッシュVPNを使うべきです。

エントリーポイントを減らせば減らすほど、電話の設定は簡単になります。プライベートクラウドは、ネットワークごとに異なる謎のURLを必要とすべきではありません。安定した名前付け、一致する証明書、明確なアクセス方法が、Wi-Fiやモバイルデータを一貫して動作させる鍵です。

最終的なポイント

プライベートクラウドがWi-Fiでは動作するがモバイルデータで失敗する場合、プライベートクラウド自体は問題ない可能性があります。Wi-Fiはローカル経路を使い、モバイルデータはリモート経路を必要とします。失敗の原因は通常、ローカル専用URL、DNSの不一致、ポートフォワーディングの欠如、VPNやトンネルの未使用、CGNAT、TLS証明書の不一致、信頼されたドメイン設定、IPv6/IPv4の挙動、またはモバイルアプリの違いです。

まずアプリが使うURLがローカルかパブリックか、パブリックDNSが解決するか、ルーターに実際のパブリックIPがあるか、HTTPSと信頼されたドメインが外部名と一致しているかを確認してください。個人用アクセスにはVPNやメッシュVPNが最も確実な解決策です。直接外部アクセスには、一貫したパブリックドメイン、有効な証明書、慎重に保護された経路を使ってください。

信頼できるプライベートクラウドNASはファイル、写真、同期、バックアップ、リモートアクセスサービスをホストできますが、モバイルデータでのアクセスはネットワーク経路、ドメイン、証明書、アプリの設定に依存します。

よくある質問

なぜプライベートクラウドはWi-Fiでは動作するのにモバイルデータでは動作しないのですか？

Wi-Fiはローカルネットワークを使うため、プライベートIPアドレスやローカルホスト名が機能します。モバイルデータはキャリアネットワークを使うため、パブリックドメイン、VPN、トンネル、または他の外部アクセス経路が必要です。

モバイルデータで192.168.x.xを使えますか？

いいえ。A 192.168.x.x アドレスはプライベートで、ローカルネットワーク内でのみ動作します。モバイルデータから使うには、まずVPNやメッシュVPNで自宅ネットワークに接続してください。

なぜ自宅ではドメインが動作するのに携帯回線では動作しないのですか？

ご自宅のWi-FiはローカルDNSを使ってドメインをプライベートIPに向けているかもしれません。携帯回線では、電話はパブリックまたはキャリアのDNSを使い、同じレコードがなかったり間違ったエンドポイントを指している可能性があります。

なぜブラウザは動作するのにモバイルアプリは失敗するのですか？

アプリは異なるAPIやWebDAVパスを使用しているかもしれませんし、古いURLをキャッシュしているかもしれません。信頼されたドメインが必要だったり、証明書を拒否したり、ブラウザとは異なるリダイレクト処理をしている可能性もあります。

CGNATはモバイルデータからのプライベートクラウドアクセスに影響しますか？

はい。ご自宅のISPがCGNATを使用している場合、ポートフォワーディングがルーターに届かないことがあります。その場合は、パブリックIPオプション、VPN/メッシュVPN、またはリバーストンネルを使用してください。

IPv6がモバイルデータのアクセス問題を引き起こすことはありますか？

そうなることがあります。一部のモバイルネットワークはIPv6専用またはIPv6優先の経路を使用しています。ドメイン、アプリ、またはホームサーバーがIPv4専用であったりDNSレコードが誤っている場合、モバイルデータはWi-Fiとは異なる動作をすることがあります。

プライベートクラウドのためにポートを開けるよりVPNの方が良いですか？

個人用アクセスの場合、通常はそうです。VPNやメッシュVPNはプライベートクラウドをオープンインターネットから切り離し、信頼されたデバイスがまるで自宅LANにいるかのようにアクセスできるようにします。

最初に何を確認すればいいですか？

アプリに保存されているURLを確認してください。それがローカルIPアドレスである場合、 .local ホスト名は、VPNを使用しない限りモバイルデータでは動作しません。その後、パブリックDNS、CGNAT、HTTPS、信頼されたドメイン、およびアプリの設定を確認してください。