Clashトラブルシューティングハンドブック

始める前に:調査の考え方と情報収集

トラブルシューティングは運より方法論が重要です。この章自体は具体的な問題を解決しませんが、以降の各章をどれだけ速く正確に調査できるかを左右します。3分で読み終える内容ですが、その後の試行錯誤を1時間分は省けます。

調査の3原則

一度に変更する変数は1つだけ。問題が起きると、ノード変更・モード切替・クライアント再起動・PC再起動を同時に行う人が多いですが、直ったとしてもどの操作が効いたのか分からず、再発時にまた手探りになります。正しいやり方は「1箇所変更→1回検証→記録」の繰り返しです。

自分に近い側から外側へ調べる。通信の経路は「アプリ → システムプロキシ/TUN → クライアント → ノード → 目的のサイト」です。左側ほど自分で確認しやすく、右側ほど第三者に依存します。まず自分のマシン側に問題がないか確認し、その後でノードやサブスクプロバイダーを疑ってください。順序を逆にすると徒労になります。

各ステップで検証操作を行う。「たぶん直った気がする」は根拠になりません。curlコマンド1本、レイテンシテスト1回、固定サイトへのアクセス結果など、明確な検証手段を用意しましょう。本ガイドの各章でも対応する検証方法を示します。

作業前に収集すべき情報

• クライアント名と動作プラットフォーム(例:Clash Plus / Windows、Clash Verge Rev / Linux)。クライアントによって設定項目の位置は異なりますが、調査の考え方は共通です。
• 現在のプロキシモード:ルール/グローバル/直接接続、およびTUN(仮想ネットワークカード)モードの有効・無効。
• サブスクの出所:リンクがプロバイダーから直接発行されたものか、変換サービスを経由したものか。
• クライアントのログに残っている直近のエラー行。ほとんどのクライアントにログパネルがあるので、ログレベルをinfoにして一度再現させておきましょう。
• 問題が「以前からずっとそうだった」のか「ある変更の後に発生した」のかを確認。後者であれば、その変更を取り消すだけで解決することが多く、調査より速いです。

症状早見表

どの章を見るべきか分からない場合は、まず下表で症状を探し、章名をクリックして該当箇所へ移動してください。

症状1:プロキシをONにしてもネットに全く繋がらない

先に結論:この種の問題の9割は次の2箇所が原因です——トラフィックがそもそもクライアントに入っていない(システムプロキシが設定されていない、他のソフトに横取りされている)か、クライアントには入るが出て行けない(モード選択ミス、ルールでブロック、ノード全滅)。1つのコマンドでこの2つを切り分けられるので、再インストールを急がないでください。

ステップ1:curlでクライアントのポートを直接叩く

クライアントの設定画面を開き、ミックスポート番号を確認します(デフォルトは7890が多いですが、必ずクライアントに表示されている値を使ってください。ネットの記事の数字をそのまま使わないこと)。ターミナル/コマンドプロンプトで次を実行:

curl -x http://127.0.0.1:7890 -I https://www.gstatic.com/generate_204

このコマンドはシステムプロキシを経由せず、トラフィックを強制的にクライアントのポートへ流します。結果は次の2パターンのみです:

• 204または何らかのHTTPレスポンスヘッダーが返る:クライアントからノードまでの経路は通っています。問題は「トラフィックが入ってこない」側です——次の項目でシステムプロキシを確認してください。
• 接続拒否/タイムアウトになる:トラフィックはクライアントに入っているが出て行けません。問題はクライアントの設定かノード側です——「トラフィックが出て行けない」の項目へ。

トラフィックが入ってこない場合:システムプロキシとブラウザ拡張機能を確認

まずクライアントの「システムプロキシ」スイッチがONになっているか確認し、次にシステム設定側で実際にプロキシが書き込まれているか確認します(各プラットフォームの確認場所はシステムプロキシの章の対照表を参照)。書き込まれているのにダメな場合は、トラフィックを横取りする3つの疑わしい要因を重点的に調べます:

• ブラウザのプロキシ拡張機能:SwitchyOmegaなどの拡張機能はシステムプロキシより優先度が高く、拡張機能側に無効なプロキシが設定されているとブラウザ全体が繋がらなくなります。拡張機能を「システムプロキシを使用」に切り替える、または無効化して試してください。
• 他のプロキシソフトの残存:以前使っていたプロキシツールが完全にアンインストールされておらず、終了時にシステムプロキシを元に戻していなかったり、起動時に自動起動して現在のクライアントと競合したりします。タスクマネージャーで確認し、不要なものは完全に終了させてください。
• セキュリティソフトと組織のポリシー:一部のセキュリティソフトはプロキシ設定をロックします。社用PCではグループポリシーでプロキシが強制されている場合があり、そうした環境ではまずロックを解除する必要があります。

トラフィックが出て行けない場合:モードとルールを確認

1. プロキシモードを確認。直接接続モードではすべてのトラフィックがノードを経由しません。誤ってONにするとプロキシが無意味になり、初心者がこのスイッチを誤操作する確率はかなり高いです。
2. ルールモードの場合、クライアントの接続/ログパネルを開き、開けないサイトに一度アクセスして、その接続がどのルールにマッチし、どのポリシーグループに割り当てられたかを確認します。REJECTにマッチしていればルールでブロックされています。マッチしたポリシーグループで選択中のノードが無効な場合は、別のノードに切り替えてください。
3. 「グローバルテスト」を実施:グローバルモードに切り替え、レイテンシが正常だったノードを手動で選んでアクセスします。グローバルで通ってルールで通らないなら、ルールまたはポリシーグループの選択に問題があるとほぼ断定できます。

TUNとシステムプロキシの併用による落とし穴

TUNモードとシステムプロキシを同時にONにすると、通信経路の推測が非常に難しくなります。一部の接続は仮想ネットワークカードを通り、別の接続はシステムプロキシを通るため、ログが矛盾して見えることがあります。調査中は経路を1つだけに絞りましょう——TUNをOFFにしてシステムプロキシのみ使う、またはTUNをONにしてシステムプロキシをOFFにする。問題を特定できたら、通常の組み合わせに戻してください。

症状2:ノードのレイテンシテストがタイムアウトする

レイテンシ一覧が全て「タイムアウト」なのは確かに焦りますが、まず理解しておくべきことがあります:レイテンシテストのタイムアウトは、必ずしもノードが使えないことを意味しません。レイテンシテストはノードに固定のテストアドレスへアクセスさせるものですが、個別のノードがそのテストアドレスと相性が悪くても、実際のアクセスは正常な場合があります。逆に、レイテンシの数値が良好でも実際にはページが開かないこともあります。最終的には実際のアクセス結果を基準とし、レイテンシは参考値に過ぎません。

全ノードがタイムアウト:まずローカルとサブスクを確認、ノードのせいにしない

すべてのノードが同時にタイムアウトする場合、ノード側の集団障害である可能性はむしろ低く、あなたの側の問題である可能性が高いです:

1. ローカルネットワークが正常か確認:プロキシをOFFにする(または直接接続モードに切り替える)、そして日本国内の一般的なサイトを開いてみます。それも開けない場合はローカルネットワーク側の問題で、クライアントのせいではありません。
2. サブスクが有効か確認:サブスクの期限切れ、トラフィックの使い切り、プロバイダーによるリンクのリセットなどが起きると、ノード一式が全滅します。直接接続の状態でプロバイダーの公式サイトにログインして状態を確認し、クライアントでサブスクを手動更新してください。
3. テストアドレスを確認:一部のクライアントはレイテンシテストのURLをカスタマイズできます。そもそも到達不能なアドレスに変更されていると、当然全てタイムアウトになります。デフォルトのgenerate_204系アドレスに戻してから再テストしてください。
4. 別のクライアントで相互検証:同じサブスクを別のクライアントに導入してみます(ダウンロードページには5つのプラットフォームすべてに代替クライアントがあります)。別のクライアントで正常なら、元のクライアントの設定に問題があります。ポート・TUN・DNSの3点を重点的に確認してください。

一部のノードがタイムアウト:ノード側の問題の判断

一部のノードだけがタイムアウトする場合は、対処はむしろ簡単です:

• 地域単位でまとまってタイムアウト:特定の国際回線の障害やメンテナンスです。ひとまず他の地域のノードに切り替え、数時間後に再確認してください。
• 特定のノードが長期間タイムアウト:そのノードがすでにオフラインだがサブスクから削除されていない可能性が高いです。プロバイダーにフィードバックしましょう。
• 夜間のピーク時に全体が遅くなり、時々タイムアウト:回線混雑の典型的な症状で、速度低下の章の範囲です。人気の低い地域のノードに切り替えると緩和されます。
• ネットワーク環境を変えたらまとまってタイムアウト:一部のネットワーク(学内ネットワーク、社内ネットワークなど)は特定のポートやプロトコルをブロックします。同じサブスク内の別のプロトコル・別のポートのノードを試してください。

症状3:サブスクのインポートまたは更新に失敗する

サブスクの問題の良い点は、エラーメッセージが比較的分かりやすいことです。悪い点は、多くのクライアントがエラーをログに折り畳んでポップアップ表示しないことです。インポート/更新に失敗したら、まずログパネルを開いて赤字の行を見つけ、下表と照らし合わせてください。

エラーメッセージ対照表

コマンドでサブスクリンクを手動検証する

リンクが壊れているのかクライアントの問題なのか判断がつかない場合、curlでクライアントの動作を模してサブスクを取得してみます(以下は例のリンクで実在しません。自分のリンクに置き換えてください):

curl -A "clash" -I "https://example.com/api/sub?token=xxxx"

200が返り、レスポンスヘッダーにsubscription-userinfoのようなフィールドが見える場合、リンク自体は正常でクライアント側の問題です。404/403が返る場合は、プロバイダーの管理画面で新しいリンクに交換してください。-A "clash"というパラメータに注意:多くのサブスクサービスはUser-Agentによって異なるフォーマットを返すため、ブラウザで直接開いた内容とクライアントが取得する内容が異なることがあります。検証時はclash系のUAを付けてこそ意味があります。

インポートは成功したがノード一覧が空になる

この「見せかけの成功」は通常フォーマットの問題です:サブスクが返しているのが汎用の共有フォーマットでClashの設定ではない、または古いカーネルのクライアントが新しいプロトコルのノードに遭遇して丸ごとスキップしている可能性があります。対処方向は2つ:1つはプロバイダーにClash専用のサブスクエントリを問い合わせること。もう1つはmihomoカーネルを使うクライアントかどうか確認すること(ダウンロードページ掲載の主力クライアントはすべてそうです)。新しいプロトコルへの対応が充実しており、古い形式への互換性も高くなります。

サブスク関連のその他の一問一答(自動更新間隔、複数サブスクの共存、トラフィック情報が表示されない等)はよくある質問の「インストールと設定」カテゴリにまとめてあります。

症状4:接続はできるが速度が遅い

「遅い」は最も調査が難しい症状です。ボトルネックが経路上のどこにあってもおかしくないためです。この章の核心となる方法は一言で言えます:まず相互テストでボトルネックの箇所を特定し、そこだけを最適化する。いきなりサブスクを乗り換えないでください。

3段階の相互テストによる特定法

1. 同じノードで異なるサイトをテスト:現在のノードで3〜4つの異なるサイトを開きます。すべて遅ければノードかローカル側を疑い、特定のサイトだけ遅ければそのサイト自体、またはこの回線と相性が悪いだけなので、ノードの地域を変えれば改善します。
2. 同じサイトで異なるノードに切り替え:2〜3個の異なる地域のノードで同じサイトにアクセスします。どのノードでも遅ければローカル側を重点的に確認、地域を変えたら速くなれば元のノードの混雑が原因です。
3. 直接接続でベース速度を測定:直接接続モードに切り替えて一度速度測定を行います。直接接続でも遅ければ、まず光回線やWi-Fiの問題を解決してください。プロキシがベース速度を超える速さを出すことはありません。

ノード側:混雑・倍率・プロトコル

夜間ピーク時の速度低下は共有回線では常態化しており、閑散時間帯は速く混雑時間帯は遅いというパターンであれば、混雑が原因だとほぼ確定できます。人気の低い地域のノードに切り替えるのが最も直接的な緩和策です。また、サブスク内のトラフィック倍率表記にも注意してください——高倍率のノードは通常より高コストな回線を使っており、速度の体感も異なるため、使う価値があるかは自分で判断してください。同じプロバイダーが複数のプロトコルエントリを提供している場合は、切り替えて比較することもできます。プロトコルごとにネットワーク環境による表現の差はかなり大きいです。

クライアント側:モードと設定

• 日常はルールモードを使い、グローバルモードにしない:グローバルモードでは国内サイトへのアクセスもノード経由になり、すべてのトラフィックが狭い門を通ることになります。ルールモードで直接接続すべきトラフィックを直接接続に流すのが、速度と体感の両面で最適解です。
• ログレベルをinfoに戻す:debugレベルは膨大なログを記録し、長期間ONにしていると性能に影響します。調査が終わったら戻すのを忘れずに。
• 多重プロキシになっていないか確認:ポリシーグループで「中継/チェーン」系のグループを選んでいたり、クライアントの外側にさらに別のプロキシツールを重ねていたりすると、経由するホップが増えるたびに速度のコストがかかります。
• ルールセットが大きすぎる:カスタムルールが数万行に積み重なり、書き方も非効率(大量の正規表現)だとマッチングのコストが上がります。ルールを整理するか、rule-providerで必要に応じて読み込む方式に変更してください。

端末とネットワーク環境側

Wi-Fi信号が弱い、2.4GHz帯が混雑している、ルーターの性能不足などは、経路全体の下限を決めてしまいます。特にルーター上で直接カーネルを動かす構成についても触れておきます:ソフトルーター/サブルーターの性能が不足していると、プロキシの処理負荷が家全体のネット速度を直接押し下げます。構成の考え方はブログのルーターで直接mihomoカーネルを動かす構築概要を参照してください。また、ダウンロードツールやクラウド同期がバックグラウンドで上りを占有していないかも確認しましょう——上りが飽和すると、すべての接続の性能が一気に悪化します。

症状5:DNS解析の異常

DNSは最も見えにくい種類の障害で、症状も多岐にわたります。ノードのレイテンシは正常なのにページがぐるぐる回って開かない、直接接続すべきサイトが変な地域に解決されてしまう、LAN内の機器が突然見つからなくなる、などです。ノードとシステムプロキシの問題を除外してもまだおかしい場合は、8割方DNSが原因です。

まずfake-ipとredir-hostを理解する

Clash系カーネルのDNSには2つの拡張モードがあります。fake-ipは各ドメインに対して予約セグメントの偽IPをまず返し、接続が来た時点でドメイン名に基づいてルールマッチングを行うため、速度が速くルールのマッチも正確で、現在の主流のデフォルトです。redir-hostは実際の解決結果を返し、互換性が必要な場面で使われます。両者の詳細な違いと適用場面は用語集に該当項目があり、ブログのDNS設定の詳細解説ではさらに詳しく分解しています。ここでは調査方法のみ扱います。

典型的な症状対照表

• ページがぐるぐる回って開かないが、ノードのレイテンシは正常:多くの場合nameserverに設定した上流DNSが使用不可で、解決のステップで詰まっています。到達可能なDoHアドレスに変えて再試行してください。
• 特定の国内サイトが海外に解決され、読み込みが異常:振り分けがfallbackの海外解決結果を参照してしまっています。fallback-filterにgeoipのフォールバックが設定されているか確認してください。
• LAN内の機器、NAS、プリンターが見つからなくなった:fake-ipがLANのドメインまでハイジャックしています。*.lanや+.localなどをfake-ip-filterに追加してください。
• クライアントを終了してもしばらくネットが異常なままになる:システムにfake-ipセグメントの解決結果がキャッシュされています。システムのDNSキャッシュを1回クリアすれば復旧します。

そのまま使えるDNSセクションの例

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "+.local"
    - "+.msftconnecttest.com"
  nameserver:
    - https://223.5.5.5/dns-query
    - https://doh.pub/dns-query
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

考え方はシンプルです:nameserverは日常的な解決を担当し、直接接続で到達可能かつ応答が速いものを選びます。fallbackは海外ドメインのフォールバックを担当し、fallback-filterのgeoipルールと組み合わせます——解決結果が中国本土のIPに該当する場合はnameserverを信頼し、そうでなければfallbackの結果を採用して、汚染を防ぎます。

変更後の検証方法

設定をリロードしたら、クライアントのDNSリスニングポートに直接クエリを送ってみます(上記設定の1053番ポートに対応):

nslookup -port=1053 www.gstatic.com 127.0.0.1

fake-ipモードで198.18から始まるアドレスが返れば正常に動作しています。また、古い結果が判断を妨げないよう、システムキャッシュも一度クリアしておきましょう:

# Windows
ipconfig /flushdns

# macOS
sudo killall -HUP mDNSResponder

症状6:システムプロキシが機能しない

先に原理を理解しておくと、後の不思議な現象もすべて説明がつきます。クライアントで「システムプロキシ」をONにするというのは、本質的にはOSのネットワーク設定にHTTP/SOCKSプロキシのアドレスを登記するだけです。アプリがこの登記を読み取るかどうかは、完全にアプリ側の自由です。ブラウザは読み取るのでプロキシを通り、多くのCLIツールや一部のデスクトップアプリは読み取らないので直接接続を続けます。これは不具合ではなく、仕組み上そうなっているだけです。

各プラットフォームでシステムプロキシを確認する場所

クライアント側のスイッチはONなのにシステム設定側が空の場合、書き込みが失敗しています。クライアントがネットワーク設定を変更する権限を持っているか、または他のソフトが繰り返し元に戻していないか(残存したプロキシツールや一部のセキュリティソフトがこれをやります)を確認してください。Linuxデスクトップ環境は落とし穴がさらに多く、GNOMEとKDEそれぞれに独自のプロキシ設定があり、ターミナルはさらに環境変数を見るため、3系統が互いに連動しません。構築の詳細はブログのLinuxの2つの構築ルートを参照してください。

コマンドラインと開発ツール:個別に設定が必要

ターミナルのcurl、pip、npmなどはデフォルトでシステムプロキシを読み取らず、環境変数で指定する必要があります(ポート番号はクライアントの実際のポートに置き換えてください):

export https_proxy=http://127.0.0.1:7890
export http_proxy=http://127.0.0.1:7890
export all_proxy=socks5://127.0.0.1:7891

Gitには独自の設定項目があり、よく使われる書き方はgit config --global http.proxy http://127.0.0.1:7890です。使わなくなったら--unsetを忘れずに。デスクトップアプリに「ネットワーク設定」や「システムプロキシを使用」というスイッチがあれば、アプリ内でONにする方が、システム全体をいじるよりずっとすっきりします。

個別設定が面倒な場合:TUNモードを使う

TUNモードは仮想ネットワークカードを1枚作成し、ネットワーク層でトラフィック全体を引き受けます。どのアプリの協力にも依存せず、システムプロキシが対応できないCLIツール、ゲーム、UWPアプリまで全てカバーできます。代償は管理者権限/システム拡張の許可が必要で、DNSの設定も正しく行う必要があります(前章のfake-ip方式と組み合わせます)。有効化の入口と権限付与の手順はクライアントごとに異なり、使い方ガイドに該当項目があります。概念的な説明は用語集のTUN項目を参照してください。TUNを有効にしたら、症状1で説明した「経路を1つに絞る」という理由から、システムプロキシはOFFにすることをお勧めします。

症状7:クライアントがクラッシュする、または起動しない

クラッシュは見た目こそ怖いですが、実際は原因が最も集中しているタイプの症状です:設定ファイルの構文エラーとポート競合、この2つで大半のケースをカバーできます。以下の順序で確認すれば、通常10分以内に判明します。

第一の疑い:設定ファイルの構文

新しいサブスクを導入した直後、または設定を手動で編集した直後にクラッシュが始まった場合は、設定の問題だとほぼ断定できます。最もクリーンな検証方法はカーネルで直接構文チェックすることです——mihomoカーネルには検証用パラメータが付属しています(カーネルはダウンロードページのカーネルセクションで入手できます):

mihomo -t -f /path/to/config.yaml

エラーがあれば行番号と原因を直接指摘してくれます。手動編集で最もよくある3つの初歩的なミス:YAMLのインデントにTabを使った、または階層がずれている、コピペで全角引用符が混入した、同じ階層に重複キーが存在する、です。1つずつ照らし合わせて修正してください。原因が分からない場合は、まず動作していた前の設定に戻して、クライアントを先に起動させましょう。

第二の疑い:ポート競合と残存プロセス

前回のクライアントのプロセスが完全に終了していない、または別のソフトが同じポートを占有している場合、新しいプロセスは必然的に起動できません。まずどのプロセスがポートを占有しているか確認します:

# Windows
netstat -ano | findstr 7890

# macOS / Linux
lsof -i :7890

占有しているプロセスを見つけたら、それを終了するか、クライアントの設定で別のポート番号に変更してください。ついでに、自動起動項目に2つのプロキシクライアントが並んで競合していないかも確認しましょう——1つだけ残してください。

ログの読み方を身につける

上記をすべて除外してもまだクラッシュする場合は、ログに語らせましょう。主力クライアント(Clash Plus、Clash Verge Rev、FlClashなど)にはログページや「ログディレクトリを開く」という入口があります。ログレベルをdebugにしてクラッシュを一度再現させ、ログの最後の数行を確認してください——クラッシュ直前の最後の記録が、通常は原因のモジュールです。理解できないエラーは、そのキーワードでよくある質問の「トラブルシューティング」カテゴリを検索してください。よくあるエラーは項目として収録されています。

クリーンな再インストールの正しい手順

1. まずバックアップ:サブスクリンクをエクスポートまたはメモしておき、カスタムルールと設定ファイルを別の場所にコピーしておきます。
2. アンインストールして残存物を消す:アンインストール後、設定ディレクトリを手動で削除します(場所はクライアントの「設定ディレクトリを開く」入口を参照)。残った壊れた設定は「再インストールしてもクラッシュする」の最大の原因です。
3. 再インストールして段階的に復元する:まず空の設定で起動できることを確認し、次にサブスクを導入し、その後カスタム内容を段階的に戻していきます。1ステップごとに検証すれば、問題のある部分が自然と明らかになります。
4. 別のクライアントで相互検証する:同じプラットフォームで別のクライアントに切り替えます(ダウンロードページには各プラットフォームに2〜4個の選択肢があり、Clash Plusを第一候補としてお勧めします)。同じ設定で別のクライアントでもクラッシュするなら設定の問題、正常なら元のクライアント側をさらに調べてください。

症状8:モバイル専項(Android / iOS)

スマートフォンの問題には独自のロジックがあります。デスクトップの不具合は主に設定にあり、モバイルの不具合は主にシステム権限とバックグラウンドポリシーにあります。デスクトップの発想をそのままスマホに適用すると、しばしば見当違いの方向を調べてしまうため、独立した章として扱います。

Android:権限とバックグラウンドが2大要所

• VPN権限:AndroidクライアントはVpnServiceでトラフィックを引き受けます。初回起動時の許可ダイアログで必ず「許可」をタップしてください。その後システム設定で権限を取り消したり、別のVPN系アプリをインストールしてチャネルを奪われたりすると(システムは同時に1つのVPNしかアクティブにできません)、クライアントは静かに機能しなくなります。設定 → ネットワーク → VPNで現在アクティブなものを確認してください。
• 電池最適化によるバックグラウンド終了:メーカー独自カスタムシステムの積極的な省電力ポリシーは「使っているうちに切れる」の最大の元凶です。クライアントを電池最適化のホワイトリストに追加し、バックグラウンド動作と自動起動を許可してください。一部の機種では最近使用したアプリ画面でロックする操作も必要です。
• アプリ別プロキシの設定ミス:クライアントのアプリ別プロキシ(許可/除外リスト)で対象アプリが除外リストに入っていると、そのアプリは当然プロキシを通りません。問題が起きたら、まずアプリ別プロキシをデフォルトに戻してから調査してください。
• データ節約モードとプライベートDNS:システムのデータ節約モードはバックグラウンドの通信を制限します。システム層の「プライベートDNS」設定もクライアントのDNSと競合する可能性があるため、調査中は自動設定にしてください。

Android向けの主力クライアント(Clash Plus、Clash Meta for Android、FlClash、Surfboard)はダウンロードページのAndroidセクションを参照してください。同じサブスクで別のクライアントに切り替えて相互検証するという考え方は、スマホでも同じように有効です。

iOS:VPN構成にまつわる注意点

• インストール方法:iOS向けはApp StoreからClash Plusをインストールするだけです。入口はダウンロードページのiOSセクションにあります。
• VPN構成の競合:複数のプロキシ系アプリをインストールした端末では、設定 → 一般 → VPNとデバイス管理に複数のVPN構成が存在します。アプリを切り替える前に古い方を切断してください。2つの構成がチャネルを奪い合うのは、iOSで「ONにしたのにトラフィックが流れない」という現象の一般的な原因です。
• ネットワーク切り替え後の一時的な断線:Wi-Fiとモバイルデータの間で切り替わる際、VPNトンネルの再構築が必要になり、数秒間の断線は正常な現象です。頻繁に切断して復旧しない場合は、クライアントの「オンデマンド接続/自動再接続」設定がONになっているか確認してください。
• バックグラウンドがシステムに回収される:iOSはメモリが不足するとバックグラウンドアプリを回収します。VPNトンネルは通常残っていますが、アプリの画面は再読み込みが必要です。アプリを再度開けば済み、不具合ではありません。
• サブスクの更新失敗:モバイルデータ通信時は、システムがそのアプリのモバイルデータ利用を禁止していないか確認してください(設定 → モバイル通信でアプリごとにスイッチがあります)。

モバイル共通のアドバイス

スマホのネットワーク環境はデスクトップよりずっと複雑です。Wi-Fi、モバイルデータ、キャリアのDNS、テザリングにはそれぞれ独自の特性があります。「時々おかしくなる」場合は、まず同じネットワーク環境に固定して再現させてください。電車の中で基地局を切り替えながら調査するのはやめましょう。サブスクの更新に失敗したら、リンクをブラウザにコピーして到達可能性を検証してみます(方法はサブスク失敗の章と同様)。リンクの問題かアプリの問題かを素早く区別できます。両プラットフォームの省電力モード・低データモードはバックグラウンド通信を妨げるため、調査中はすべてOFFにしてください。