一、Wi-Fi とセルラー（モバイルデータ）で何が変わるか
まず抱えやすい誤解は、「購読やノードが壊れているからセルラーだけ失敗する」という単純化です。購読 URL が生きていて Wi-Fi で問題ないなら、多くの場合出口ノード以前の層——端末 OS がモバイル回線に切り替わったときのVPN スタックの再起動、DNS の上書き、バッテリー最適化によるプロセス停止——のどれかが絡みます。Clash 系クライアントは実装によって HTTP プロキシ／SOCKS と TUN（仮想ネットワーク）／OS の VPN 枠を切り替えられるので、Wi-Fi のときは「プロキシだけ」で足りていて、セルラーではアプリが生ソケットを直に叩いてプロキシ外に出る、というパターンも珍しくありません。
切り分けの出発点として、症状を次のように分類してください。(A) ブラウザだけ繋がらない、(B) 全体が繋がらない、(C) 接続はするが一部ドメインだけ失敗する。 (B) は TUN/VPN レイヤーや OS のデフォルトルート奪取の問題寄り、(A)(C) はアプリ個別や分流ルール・DNS寄りです。以下ではまず共通の「接続モード」を揃えてから、プラットフォーム別に潰し込みます。
二、共通：システムプロキシ・TUN、ネットワーク切り替え時の挙動
システムプロキシ（ローカルの HTTP/SOCKS を OS に指し示す方式）は、ブラウザなどプロキシ対応アプリには効きやすい一方、一部のアプリや QUIC／UDP はスタック外に出ることがあります。TUN モードや OS が認識する VPN 接続は、カーネル階層からトラフィックを集約しやすいですが、モバイルでは電池持ちやメーカー独自の「通信高速化」機能とぶつかりやすい、というトレードオフがあります。セルラーに切り替わった瞬間に VPN 接続がいったん落ち、ユーザー操作なしでは復帰しないクライアントもあるため、「Wi-Fi に戻すと直る」はこの層を疑うサインになります。
また、回線が変わると OS が DNS サーバのリストをキャリアの推奨値に差し替えることがあります。Clash 側で dns と fake-ip を使っている場合、クライアントの「システム DNS を追従」系オプションと相性が悪いと、Wi-Fi ではうまくいってもセルラーでは名前解決だけ別経路になる、という見え方をします。細部は fake-ip と DNS の記事で述べているとおり、誰が握っている DNS かを一つに揃えるのが筋です。
| 見え方 | まず疑う層 |
|---|---|
| Wi-Fi 復帰で一発で直る | VPN プロセスの再起動、省電力による kill、セルラー側 DNS の差し替え |
| ブラウザだけ失敗する | システムプロキシのみ／ブラウザの Secure DNS（プライベート DNS）との二重解決 |
| 全体が全く繋がらない | TUN/VPN のルート競合、機内モード後の再接続、クライアントの「全トラフィック」設定 |
三、Android：VPN 権限・省電力・プライベート DNS を順に確認する
3.1 VPN 権限と「常にオン」
Android では多くの Clash クライアントが VPN 接続として動作します。初回のみ権限を許可し、その後アップデートでVPN プロファイルが無効化されたり、セルラー切り替え後に接続ダイアログを再表示する端末があります。設定アプリの VPN 一覧で、使用中のプロファイルが接続中か確認し、可能なら常にオン（Always-on）やブロックなく接続を維持に近いオプションをクライアントのドキュメントに従って検討してください（仕様は OEM 依存が大きいです）。
3.2 バッテリー最適化とバックグラウンド
省電力設定はWi-Fi 接続時は穏やかでも、モバイルデータ時だけアグレッシブになることがあります。対象アプリに対して 最適化を無効にする、制限なしのバックグラウンドを許可する、といった操作はメーカーごとに名称が違うため、「機種名＋バッテリー最適化＋VPN」で公式ヘルプを当てがうのが現実的です。これを放置すると、画面消灯直後やセルラー切り替え直後にだけ VPN が落ち、Clash だけ「Wi-Fi のときだけ安定」という体感になります。
3.3 プライベート DNS・デュアル SIM
プライベート DNS（DoT など）を端末で有効にしていると、Clash の仮想 DNSと二重化しやすいです。切り分けのため、テスト中だけ「オフ」または「自動」に戻し、クライアント側の DNS 設定と一本化してください。また デュアル SIM ではデータ通信に使う回線を切り替えたとき、VPN の再ダイヤルが必要になる場合があります。購読やルール更新が別問題であっても、まずは一行にしたデータ SIMで再現するか確認すると原因が絞れます。
四、iOS：VPN プロファイル・接続維持・省電力を順に確認する
iOS／iPadOS では、プロキシや TUN を扱うクライアントが VPN とデバイス管理の枠で動くことが多く、プロファイルのインストール状態や信頼が崩れていると、Wi-Fi では偶然通ってもセルラーで詰まる、ということがあります。設定の 一般 → VPN とデバイス管理から、対象の構成プロファイルと VPN の接続状態を確認してください。アップデート後に再接続を一度挟む必要があるクライアントもあります。
また iOS は低データモードや省電力モード、アプリのバックグラウンド更新がネットワーク利用に影響します。VPN タンネルがバックグラウンドで切られたと感じる場合は、当面これらをオフにして比較実験してください。iCloud プライベートリレーやサードパーティ VPN が同時に有効だと、トラフィックの取り合いになるため、切り分けでは片方だけにしてください。
クライアントによっては Network Extension の権限やローカルネットワークの許可が別画面にあるため、公式ドキュメントのスクリーンショットと照合すると抜け漏れが防げます。デスクトップの macOS の Network Extension 記事は別 OS ですが、拡張の許可範囲が足りないと一部回線だけ不安定という発想は共通です。
五、分流・DNS がセルラーでだけ崩れるとき
プロファイル内の 分流が「Wi-Fi 固定の国内直結」や「特定インターフェース前提」になっている例は稀ですが、CIDR 形式のルールとキャリアのアドレス帯が偶然衝突すると、セルラーだけ誤って DIRECT になる、といったエッジケースは理論上あり得ます。現実的にはログで該当ドメインがどのポリシーに落ちたかを確認し、Wi-Fi 時とセルラー時で同一プロファイルかどうかも確認してください（プロファイルの複製で片方だけ古い、など）。
DNS 方面では、キャリアの IPv6 と IPv4 の扱い差で、解決パスのみが変わることがあります。クライアントのログに DNS 問い合わせ失敗やノードへの TLS 失敗が出ていれば、まずは fake-ip 関連の設定を見直し、二重の名前解決を排除します。全体設計の参照として ドキュメント索引も併せて確認すると、自分のクライアントに存在する項目名に合わせやすくなります。
# ルールと DNS の典型イメージ（実際のキーは利用コアのドキュメントに合わせる）
mode: rule
dns:
enable: true
enhanced-mode: fake-ip
rules:
- DOMAIN-SUFFIX,example.com,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXY六、まとめ
Wi-Fi では使えるのにモバイルデータにすると Clash が効かない問題は、単一の設定キーワードではなく、OS の VPN スタック・DNS・省電力・回線切り替えが重なったときに現れやすいです。まず症状が全体か一部かで層を分け、Android では VPN 権限と省電力を、iOS ではプロファイルと通信制御を疑う順序が実務的です。分流や fake-ip は Wi-Fi とセルラーで環境が変わったときのDNS 経路の差として表れがちなので、ログとセットで読み解いてください。
モバイルではクライアントの差も大きいため、まずは安定版の入手とプロファイルの単純化から試すのが近道です。多機能な設定より、接続モードを一つに揃え、ネットワークを切り替えるたびに再接続の要否を確認するクセを付けると、再発時の切り分けが早くなります。
Clash はルールベースの透明性が高く、Wi-Fi とセルラーのようなシーン切り替えでもログから原因を辿りやすいのが利点です。手元の環境に合わせたクライアントを用意し、落ち着いて一層ずつ確認してみてください。