Clash トラブルシューティング完全ガイド

第1章:まず問題の発生箇所を特定し、それから対処する

トラブル対応で最も避けたいのは、あちこち手を加えた結果、何が効いたのか分からなくなることです。手を動かす前に、まず全体像を把握しましょう。1回のプロキシリクエストが発生してから応答が戻るまでには、以下の経路をたどります。どこか1箇所でも問題があれば「ネットにつながらない」という同じ症状になりますが、解決策は箇所ごとに全く異なります。

アプリケーション → システムプロキシ / TUN モード → Clash コア(ローカルポート) → ルールマッチング(ポリシーグループ) → ノード → 目的のサイト

段階別に説明します。第1段階では、アプリがそもそもシステムプロキシに流量を渡しているか——一部のアプリ(ゲームやCLIツールなど)はデフォルトでシステムプロキシ設定を読み込みません。第2段階では、システムプロキシが実際に書き込まれているか、指定ポートがClashコアのリスンポートと一致しているか。第3段階では、コアがリクエストを受け取った後、ルールセットを順に照合し、直接接続かポリシーグループへの転送かを決定し、ポリシーグループが具体的なノードを選択します。第4段階では、ノードが生存しているか、プロトコルがコアに対応しているか、途中で通信事業者にブロックされていないか。障害がどの段階にあるかによって、対応する章が変わります。

切り分けの3原則

1. まず発生箇所を特定し、それから手を加える。障害が経路のどの段階で起きているかを判断してから対応する章の解決策を探しましょう。特定せずに設定を変えるのは目隠しで薬を選ぶようなもので、うまくいくのは運任せ、間違えれば新たな不具合を招きます。
2. 1回に変更する変数は1つだけ。1箇所変更したら1回テストする。3箇所同時に変更すると、良くなっても何が効いたか分からず、悪化しても何が原因か分からず、切り分けが底なし沼になります。
3. 結論を出す前にまずログを確認する。ログはClashの診療記録です。リクエストが届いたか、どのルールにマッチしたか、どんなエラーが出たかがすべて記録されています。切り分けの前にログレベルをデフォルトのwarningからinfoまたはdebugに変更し、障害を再現してからログを読みましょう。errorレベルは致命的なエラーのみ記録し、infoは各接続の行き先が確認でき、debugは最も詳細ですが最もうるさいです。特定後は元のレベルに戻すことを忘れずに。

3つの基本テスト

以下の3つのテストは本ガイド全体で使うもので、各章で繰り返しここに戻ってくるよう案内します。

テスト1、ローカルポートテスト——コアからノードまでの経路が通っているか確認:

HTTPレスポンスヘッダーが返れば、コア・ルール・ノードのこの区間は通っており、問題はシステムプロキシまたはアプリ側にあります。タイムアウトやエラーが出た場合は、コアからノードまでの区間に問題があります。ポート7890はよくあるデフォルト値ですが、クライアント画面に表示される混合ポート(mixed-port)の値を確認してください。

テスト2、レイテンシテスト——クライアント画面上のレイテンシテストは、ノードがTCP接続を確立できるかのみを反映しており、速度の速さとは関係ありません。全ノードがtimeoutになる場合と一部だけがtimeoutになる場合は全く別の問題で、第3章の異なる2つの手順に進みます。

テスト3、直接接続との比較——一時的にシステムプロキシを無効化(またはクライアントを終了)し、ローカルネットワーク自体がインターネットにつながることを確認します。ローカルで通信できなければ、まずローカルネットワークを修正してください。Clashではそれを解決できません。

第2章:接続後にネットにつながらない

症状クライアントは実行中でシステムプロキシのスイッチもオンになっているが、ブラウザでどのウェブページも開けない。または一部のサイトだけ開き、それ以外は読み込み中のままタイムアウトする。

切り分け手順

1. ログに新しい接続があるか確認する。クライアントのログ画面を開き、開けないページをもう一度読み込みます。ログに新しい記録が1件もなければ、リクエストがそもそもClashに届いていないことを意味し、システムプロキシが反映されていない可能性が高いので第7章へ。記録がある場合は次に進みます。
2. グローバルモードに切り替えてテストする。プロキシモードを「ルール」から「グローバル」に切り替え、再度ページを読み込みます。グローバルモードで開ける場合は、コアとノードには問題がなく、ルールがリクエストを直接接続や誤ったポリシーグループに送っていることを意味するので、本章の「ルールの誤爆」の項を参照してください。グローバルでも開けない場合は次へ。
3. ノードを変えてテストする。ポリシーグループで手動でノードを切り替え、再度読み込みます。ノードを変えると開ける場合は、元のノードに障害があるので第3章へ。数個のノードに変えても開けない場合は次へ。
4. TUNとシステムプロキシが競合していないか確認する。TUNモードとシステムプロキシを同時に有効にすると、一部の環境ではループが発生します。流量が2つの経路の間で往復し、すべてのリクエストがタイムアウトする現象として現れます。片方をオフにしてから再テストしてください。
5. セキュリティソフトによるブロックを確認する。一部のウイルス対策ソフトやファイアウォールは、ローカルプロキシポートのループバック接続をブロックしたり、Clashコアの発信通信を直接ブロックすることがあります。一時的に無効化して再テストし、原因と確認できたらクライアントをホワイトリストに追加してから保護を再開してください。

ルールの誤爆:グローバルでは使えるがルールモードでは使えない

ルールモードでは、各リクエストはルールセットに従って上から順にマッチングされます。DIRECTにマッチすれば直接接続、いずれかのポリシーグループにマッチすればプロキシ経由、どれにもマッチしなければ最終ルールに従います。目的のサイトが開けるかどうかは、どのルールにマッチしたかで決まります。よくある誤爆は次の3種類です。

• ルールセットが古い:新しく登場したドメインがまだ収録されておらず、最終ルールによって直接接続に振られる。サブスクまたはルールデータ(GeoIP / GEOSITE)を更新してから再試行してください。
• カスタムルールの記述ミス:手動で追加したルールのドメインサフィックスのスペルミス、または順番が前過ぎてリクエストを先に横取りしてしまう。ルールは上から順にマッチングされるため、疑わしいカスタムルールを一時的にコメントアウトしてテストしてください。
• ポリシーグループの向き先が異常:目的のサイトがあるポリシーグループにマッチしたが、そのグループで現在選択されているノードが死んでいる。グループ内のノードを切り替えるか、そのグループをurl-testによる自動選択に変更してください。

特定のアプリだけネットにつながらない

ブラウザは正常なのに、あるアプリだけどうしてもプロキシを経由しない場合、そのアプリがシステムプロキシ設定を読み込んでいないケースが多いです——一部のゲーム、CLIツール、一部のデスクトップアプリはこのタイプです。解決策は2つ:TUNモードを有効にし、ネットワークカード層で流量を接管させることで、アプリ側の対応状況とは無関係にする。あるいはそのアプリのネットワーク設定で手動でプロキシ127.0.0.1:7890を指定する。TUNモードの有効化条件と代償については第7章末尾を参照してください。

第3章:ノード タイムアウトと接続失敗

症状レイテンシテストが一斉にtimeoutになる、または単一のノードが赤く表示され、ログにconnect timeout、connection refused、handshake failureが繰り返し記録される。

まず「全滅」か「一部だけ」かを区別する

全ノードが同時にタイムアウトする場合、ほとんどはローカルまたはサブスク側に原因があります——数十のノードが同時に故障する確率は極めて低いためです。一部のノードだけがタイムアウトする場合は、ノード自体に原因があります。両者は切り分けの方向が全く異なるので、先に区別してから進めてください。

全滅の場合:4項目を順に確認

1. ローカルネットワーク:プロキシを無効にして直接接続を試し、本体のネットワークが正常か確認する。ローカルで通信できない場合は、まずローカルを修正すれば、他は確認する必要がなくなります。
2. サブスク状態:プロバイダの管理画面にログインし、プランの期限切れやトラフィック使用量を確認する。サブスクが失効してもノードリストがクライアントに残っていることが多いですが、ノードはすべて使用不可になっています——これが「全滅」の最も一般的な原因です。確認後は第4章に進んでサブスクを更新してください。
3. システム時刻:TLSハンドシェイクでは証明書の有効期限を検証するため、システム時刻の誤差が大きい(数分以上)と全ノードでハンドシェイクが失敗し、全滅として現れます。システム時刻を修正してから再試行してください。この対処は見落とされがちです。
4. ローカルポートとファイアウォール:コアのプロキシポートが他のプログラムに占有されている、またはファイアウォールでブロックされていると、すべてのリクエストが失敗する状態になります。ポート占有の確認方法は第8章を参照してください。

一部だけタイムアウトする場合:3項目を順に確認

1. ノード自体の障害またはブロック:夜間のピーク時に基幹回線が混雑する、ノードのIPが接続先地域の通信事業者にブロックされるなど、いずれも単一ノードのタイムアウトとして現れます。別の地域や別の入口のノードで比較してみてください。
2. プロトコルとコアの不一致:サブスクに複数のプロトコルのノードが混在している場合、古いClashコアはVLESS、Hysteria2などの新しいプロトコルを認識できず、これらのノードだけがすべて使用不可、他は正常という状態になります。mihomoコア搭載のクライアントに変更すれば認識できます——ダウンロードページに掲載のクライアントはすべてmihomoコア採用です。
3. ノードパラメータの変更:プロバイダがポート・パスワード・入口アドレスを変更したのに、ローカルのサブスクが更新されておらず、古いパラメータのままでは接続できないのは当然です。サブスクを更新してから再テストしてください。

第4章:サブスク更新失敗

症状「サブスク更新」をクリックするとエラーが出る:ダウンロード失敗、リクエストタイムアウト、解析失敗、設定が空。または更新ボタンがしばらく回っているだけで、ノードリストが全く変化しない。

切り分け手順

1. サブスクのリンクをブラウザに貼り付けて直接開く。テキストファイル(YAMLまたはBase64形式の内容)がダウンロードできれば、リンク自体は有効で、問題はクライアント側にあるのでステップ2へ。開けない、404/403エラーが出る、またはプロバイダのお知らせページにリダイレクトされる場合は、リンクが失効しているかプランに異常があるのでステップ3へ。
2. クライアント側:「プロキシ経由でサブスクを更新」をオフにして再試行する。ここには循環依存があります。プロキシがすでに機能していない状態でプロキシ経由でサブスクを更新すれば必ず失敗し、新しいノードがなければプロキシはさらに機能しなくなります。サブスクの更新は必ず直接接続で行ってください。それでも失敗する場合は、TUNモードが更新リクエストまで接管していないか確認し、必要であればクライアントを終了してブラウザでダウンロードし、ローカルファイルとしてインポートしてください。
3. リンク側:プロバイダの管理画面でサブスクのアドレスを再取得する。管理画面でサブスクのトークンをリセットすると、古いリンクは無効になります。プランの期限切れやトラフィック使用量超過時、一部のプロバイダはサブスクを空の内容やエラーページとして返し、更新後に復旧します。サブスク変換サービスを利用している場合、変換サービス自体が停止していてもダウンロードに失敗するので、プロバイダ本来のサブスクリンクに戻して試してみてください。

ダウンロードはできるが解析に失敗する

解析失敗は、クライアントが受け取った内容が認識できる形式でないことを意味します。よくある3パターンは以下の通りです。

• 返ってきたのはHTMLのエラーページ:サブスクのアドレスがリバースプロキシや変換サービスにブロックされ、設定ファイルではなくウェブページが返されています。ブラウザでそのリンクを開けば、内容を見ればすぐに分かります。
• 形式がクライアントと一致しない:サブスクの内容が他のクライアント専用の形式になっている(一部のパネルはデフォルトで別形式を出力します)。プロバイダの管理画面や変換リンクのパラメータで、Clash / mihomo形式での出力を指定してください。
• 内容が途中で切れている:ネットワークの不安定によりダウンロードが不完全になり、YAML構造が欠損している。再度更新するか、ブラウザで完全なファイルをダウンロードしてローカルからインポートしてください。

ローカルインポートによる回避策

サブスクのアドレスがすぐには復旧しない場合、ブラウザで開けたサブスクの内容を.yamlファイルとして保存し、クライアントで「ファイルからインポート」を選択できます。ローカルファイルは自動更新されないため、サブスクが復旧したらサブスクリンク方式に戻すことを忘れずに。そうしないとノードの変更が永久に反映されません。設定ファイル(Profile)のより詳しい管理方法——複数設定の切り替え、統合、更新戦略——については《Clashの設定ファイルとは》を参照してください。

第5章:速度低下・カクつき・バッファリング

症状プロキシは接続できているが、ページの読み込みが遅い、動画のバッファリングが頻発する、ダウンロード速度が予想を大きく下回る。または日中は正常なのに夜間だけカクつくなど、規則性のある発生パターンを示す。

まずどの段階で遅くなっているかを区別する

比較テストを行いましょう。プロキシをオフにして直接接続で速度を測り、次にプロキシをオンにして速度を測ります。直接接続でも遅い場合は、自宅のブロードバンドまたはWi-Fi側の問題なので、まずローカルを修正してください。直接接続は正常でプロキシだけ遅い場合は、ノードやルールに原因があるので次に進んでください。

レイテンシの数値は速度と一致しない

クライアント画面のレイテンシテストが反映するのはTCP接続の確立にかかったミリ秒数だけで、帯域幅とは別の話です。レイテンシ300msのノードが100Mbpsをフルに使える場合もあれば、レイテンシ80msのノードが数Mbpsしか出せない場合もあります。ノードを選ぶ際はレイテンシのランキングではなく、実際にページを開いたり動画のシークバーを動かしたりする感触、または測速ページでの実測を見てください。

ノード側の3つの遅延要因

• 夜間ピークの負荷:夜の8時から11時はノードが最も混雑する時間帯で、同じノードでも日中と夜間で速度が数倍変わることがあります。この時間帯は負荷の低いノードや別の地域を試してみてください。
• 回線の迂回:ノードから目的サイトまでの回線品質が体感を左右します。日本のサイトにアクセスするのに米国のノードを経由すると、データが太平洋を2回横断することになります。目的サイトの所在地域に応じて近いノードを選んでください。
• 倍率と速度制限:一部のプロバイダは低倍率ノードや単一接続に速度制限をかけています。大容量タスク(システム更新、クラウドストレージの同期など)はできるだけ直接接続ルールに振り、プロキシの帯域を占有しないようにしましょう。

ルール側の2つの遅延要因

• 目的地が誤ったポリシーグループに振られている:ログを開き、目的ドメインがどのルールにマッチし、どのグループに振られているかを確認しましょう。動画配信サービスのドメインが「最終直接接続」グループに振られていると、遅くなるだけでなく、地域限定コンテンツが視聴できないこともあります。
• 自動選択グループの誤動作:url-testグループはレイテンシでノードを選ぶため、レイテンシが低くても帯域の狭いノードを選んでしまうことがあります。ピーク時間帯は主要なポリシーグループを手動指定に切り替えた方が、逆に安定することがあります。

端末側の2つの遅延要因

• TUNモードのオーバーヘッド:TUNはネットワークカード層で全流量を処理するため、大容量ダウンロード時に余分な負荷がかかります。極限の速度を求める場合は、ブラウザはシステムプロキシ経由、ダウンローダーは直接接続、という組み合わせがより効率的です。
• 二重プロキシ:システムプロキシとTUNを同時に有効にしている、またはブラウザのプロキシ拡張機能とシステムプロキシが重複している場合、流量が余分な経路を通ることになり、速度が無駄に低下します。接管する層は1つだけに保ちましょう。

ノードの選び方の体系的な方法——レイテンシ、倍率、地域、プロトコルの4軸のバランスをどう取るか——について、別記事《Clashのノードの選び方》で解説しています。

第6章:DNS解析の異常

症状ブラウザで「サーバーのIPアドレスが見つかりません」と表示される。一部のドメインが開けないが、対応するIPには接続できる。ページを初めて開く際の待ち時間が極端に長く、2回目以降は正常に戻る。

まずClashのDNSの2つの動作方式を理解する

Clashコアには内蔵のDNSモジュールがあり、2つの解析方式があります。挙動と互換性が異なり、選択を誤ると上記の症状が発生します。

切り分け手順

1. DNS障害であることを確認する。開けないサイトに対して、そのIPで直接接続(または別の端末でモバイル回線を使用)すれば開ける場合、原因はほぼ解析段階にあり、ノードではないと判断できます。
2. 現在のDNS設定を確認する。設定ファイル内のdns.enableがtrueになっているか、クライアント画面の「DNS接管」系のスイッチがオフになっていないか確認します。コアがDNSを接管していないと、汚染やハイジャックがそのままシステム解析に直撃します。
3. fake-ipの互換性を確認する。障害がゲーム、LANサービス(プリンター、NAS、画面共有)、一部の官公庁・銀行系アプリに集中している場合、fake-ipの非互換の可能性が非常に高いです。これらのドメインをfake-ip-filterに追加するか、全体をredir-hostモードに戻してください。
4. 通信事業者によるハイジャックを確認する。家庭用ブロードバンドのデフォルトDNSは、UDP 53ポートの平文クエリをハイジャックし、改ざんされた結果を返すことがよくあります。nameserverにDoH / DoTの暗号化解析を設定すれば、ハイジャックは無効化されます。

そのまま使える設定例

dns:
  enable: true
  listen: 0.0.0.0:53
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "*.home.arpa"
    - localhost.ptlogin2.qq.com
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query

設定の意味:nameserverは自国内のドメイン解析を担当し、速いルートを使います。fallbackは海外ドメインの解析を担当し、暗号化通信で汚染を防ぎます。fake-ip-filterには仮アドレスを認識しないドメインを入れ、ワイルドカードの書き方は上記の通りです。設定変更後はコアの再起動が必要です。

確認用コマンド:

198.18.x.x帯のアドレスが返る場合はfake-ipが正常に動作しています。タイムアウトする場合は、コアのDNSが起動していないことを意味するので、ステップ2に戻ってdns.enableとリスンポートを確認してください。

第7章:システムプロキシが反映されない

症状クライアントは実行中でノードも正常だが、ログに新しい接続記録が全く現れない。システム設定にプロキシ項目が見当たらない、またはプロキシ項目が指すポートがクライアントと一致していない。

各OSでシステムプロキシが書き込まれているか確認する

書き込みに失敗するよくある原因

1. 権限不足:システムプロキシの書き込みには相応の権限が必要です。Windowsでは通常権限で実行しているクライアントがグループポリシーで制限されることがあります。macOSでは初回有効化時に許可ダイアログが表示され、「許可しない」を選んだ場合はシステム設定のネットワークプロキシ画面で手動オンにしてください。
2. ブラウザ拡張機能による横取り:SwitchyOmegaのようなプロキシ拡張機能がブラウザを制御している場合、システムプロキシは完全に無視され、拡張機能自体のルールに従います。「システムプロキシは確かにオンなのにブラウザが経由しない」という症状で現れます。拡張機能を無効化するか、拡張機能側を「システムプロキシを使う」モードに切り替えてください。
3. 他のプロキシソフトの残留設定:以前インストールしたVPNやアクセラレータが終了時にシステムプロキシをクリアせず、システム設定が古いポートを指したままになっている。システムプロキシを手動で127.0.0.1と現在のクライアントのポートに書き換える、または一度オフにしてクライアントに再度書き込ませてください。
4. ポートの不一致:クライアントごとにデフォルトポートが異なります(一般的には7890、一部は7897)。設定ファイルでmixed-portを変更している場合もあり、システムプロキシが古い値を指したままの可能性があります。両者を一致させるか、クライアントでシステムプロキシを一度オフ・オンして、現在の設定で書き換えさせてください。

手動での書き込みとTUNによる回避策

自動書き込みが常に失敗する場合、システム設定に手動で入力できます:アドレス127.0.0.1、ポートはクライアントのmixed-portと一致させます。手動書き込みの欠点は、クライアント終了後もシステムプロキシが自動でクリアされないことです。終了前に手動でオフにしないと、次回起動時にクライアントを立ち上げなければネット全体が使えなくなります。

より確実な解決策はTUNモードです。ネットワークカード層で全流量を接管するため、システムプロキシに依存せず、システムプロキシを読み込まないアプリ(ゲーム、CLIツールなど)も接管対象になります。代償として、サービスモードのインストールまたは管理者/root権限が必要で、システムプロキシと同時に有効にすると回線がループする可能性があるため、どちらか一方を選ぶ必要があります。Windowsでは管理者としてクライアントを実行してからTUNを有効化、macOSではクライアントの指示に従って補助ツールをインストールし許可、Linuxではrootまたはcapabilitiesの設定が必要です。

第8章:クライアントのクラッシュと起動失敗

症状クライアントをダブルクリックしても反応がない、起動直後にクラッシュする、「コアの起動に失敗しました」というエラーが表示される、画面がフリーズして応答しない、起動時自動起動後にひっそり終了する。

まず実際のエラー内容を取得する

GUIがクラッシュする場合、コマンドラインからクライアントを起動するか、コアを単独で起動すると、エラーが直接ターミナルに表示されます。エラーメッセージは本章のすべての解決策への入口です——まずこれを取得し、以下の4つの高頻度原因と照らし合わせてください。GUIがエラーを握りつぶしている状態では、アイコンを眺めていても原因は分かりません。

よくある4つの原因

設定ファイルの構文エラー

YAMLはインデントに非常に敏感です:必ずスペースを使い、同じ階層は揃え、Tabは使用不可で、コロンの後には必ずスペースが1つ必要です。手動で設定を編集した後にコアが起動しなくなる場合、9割はインデントや記号の問題です。変更を元に戻すか、設定をYAML検証ツールに貼り付けて確認してから起動してください。

ポートの占有

プロキシポート(デフォルト7890)または外部制御ポート(デフォルト9090)が他のプログラムに占有されていると、コアは起動直後に終了します。占有状況の確認方法:

1行目はWindows用、2行目はmacOS / Linux用です。占有しているのが正しく終了しなかった以前のClashプロセスであれば、それを終了してから起動してください。他のソフトであれば、クライアントのポートを変更するか、そのソフト側のポートを変更してください。

権限不足

TUNモードや強化モードには特権が必要で、権限が不足している場合、コアの起動に失敗したりTUNネットワークカードの構築に失敗したりします。Windowsでは右クリックから「管理者として実行」、macOSでは表示に従いパスワードを入力して補助ツールをインストール、Linuxではsudoまたはsetcapで権限を付与してください。

設定ディレクトリの破損

異常な電源切断や強制終了により、キャッシュや設定インデックスが破損することがあり、クライアントは開けるが少し操作すると即クラッシュする症状として現れます。まずサブスクのリンクとカスタムルールをバックアップしてから、設定ディレクトリを削除してクライアントに再構築させてください。設定ディレクトリの場所:Windowsでは%APPDATA%内のクライアント名のディレクトリ、macOSでは~/Library/Application Support/、Linuxでは~/.config/です。

ウイルス対策ソフトによる誤検知

一部のセキュリティソフトはプロキシコアを不審なプログラムとしてブロックまたは隔離します。コアファイルが突然消える、更新のたびにブロックされる、といった典型的な症状が現れます。クライアントのインストールディレクトリと設定ディレクトリをホワイトリストに追加し、隔離されたコアファイルを復元してから再起動してください。

第9章:モバイル端末専用の切り分け(Android / iOS)

症状Androidでロック画面後に通信が切れる、アプリ切り替え後にプロキシが無効になる。iOSでバックグラウンドに一定時間置くと接続が切断される。またはモバイル端末特有の「VPNアイコンが消える」「スイッチが自動でオフになる」現象。

Android専用対策

1. 省電力機能によるバックグラウンド終了(最も頻発):国内メーカー製ROMはデフォルトでバックグラウンドの掃除が積極的で、ロック画面後わずか数分でプロキシコアが終了させられます。システム設定に入り、クライアントを電池最適化のホワイトリストに追加し、自動起動を許可し、最近使用したアプリ一覧にロックしてください。ROMごとに入口が異なるので(小米は「省電力とバッテリー」、Huaweiは「アプリの起動管理」)、見つからない場合は設定内で「電池最適化」を検索してください。
2. VPNの排他競合:Androidは同時に1つのアプリしかVPNサービスを保持できません。他のVPN、アクセラレータ、広告ブロックアプリがVPNの座を占有していると、Clashのスイッチが押し出されてしまいます。競合するアプリを停止してからオンにしてください。
3. アプリ別プロキシ設定:クライアント内の「アプリ別プロキシ」で対象アプリが除外リストに入っていると、そのアプリはプロキシを経由しない状態になります。リストを確認するか、一時的に「すべてのアプリをプロキシ」に切り替えて比較してみてください。
4. プライベートDNSの競合:システムの「プライベートDNS」(Private DNS)を有効にすると、プロキシのDNS接管を回避してしまい、場面によっては解析異常を引き起こします。プロキシの動作がおかしい場合は、まずプライベートDNSをオフにして比較してみてください。

iOS専用対策

1. バックグラウンド更新の制限:iOSはバックグラウンドのネットワーク活動を厳しく制限しており、ロック画面やアプリ切り替え後一定時間経つと、接続がシステムによって保留され、アプリに戻ると自動的に再接続されます。これはシステムの仕組みであり、故障ではありません。切断が頻発する場合は、低電力モードがオンになっていないか確認してください。オンだとバックグラウンド活動がさらに制限されます。
2. VPN設定の競合:複数のプロキシ系アプリをインストールしている場合、システムに複数のVPN設定が残っていて、互いにスイッチを押し出し合うことがあります。「設定 → 一般 → VPNとデバイス管理」で不要な設定を削除してください。
3. Wi-Fiとモバイル通信の切り替え:ネットワークが切り替わる瞬間、プロキシのトンネルが再構築されるため数秒間の通信断が発生しますが、これは正常な再接続プロセスです。切り替え後長時間復旧しない場合は、機内モードを一度オン・オフして強制的に再接続してください。

モバイル端末向けクライアントの選択:AndroidではClash Plusを推奨、他にClash Meta for Android、FlClashも選択可能です。iOSではClash Plus(App Storeで配信、公式サイト clashplus.io)を推奨します。各プラットフォームのクライアントの詳細な比較はクライアント比較ページを、インストーラーはダウンロードページを参照してください。