CLASH / TROUBLESHOOTING

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

接続、サブスクリプション、DNS、システムプロキシ、モバイル端末の問題を症状別に解説します。初期設定はClash入門ガイドに沿って、ダウンロード、設定のインポート、接続まで進めてください。設定を取り込んだ後に問題が起きた場合は、このページで原因を確認できます。入門ガイドでは接続の確立を、本ページでは通信がどの段階で止まるのかを扱います。

調査を始める前に、プラットフォーム、クライアント名、現在の設定、プロキシモード、問題が発生した時刻を記録してください。初めて使う方にはClash Plusがおすすめです。Clash Verge RevやFlClashなどをすでに利用している場合、まずクライアントを変更する必要はありません。画面の名称はクライアントによって異なるため、以下ではコアの動作と設定項目を基準に説明します。インストーラーはClashダウンロードページから入手できます。

インターネットに接続できない：ネットワークとプロキシ経路を切り分ける

プロキシを無効にして直接接続を確認

まず他のプロキシ、通信最適化ツール、VPNを終了し、使用中のクライアントでシステムプロキシとTUNを無効にします。普段から直接接続できるサイトを開き、ルーターの管理画面にもアクセスしてみてください。どちらにも接続できない場合は、Wi-Fi、有線接続、ゲートウェイ、ネットワーク認証ページを確認します。公衆Wi-Fiでは、ブラウザーで認証を済ませる必要があることがよくあります。プロキシが先に通信を引き継ぐと、認証ページが開けない場合があります。その場合は、IPアドレスとDNSを自動取得する設定に戻して認証を済ませてから、クライアントを起動してください。

直接接続のテストでは、2つの段階を確認します。ルーターの管理画面を開けても、端末からローカルネットワークまでの経路が使えると分かるだけで、インターネット接続が正常とは限りません。同じネットワークにつないだ他の端末でも外部サイトを開けない場合は、ルーターや上位ネットワークを確認してください。現在の端末だけに問題がある場合は、ファイアウォール、残存するプロキシ設定、静的ルートを調べます。ネットワークが復旧する前にサブスクリプションを何度も更新すると、ネットワーク障害をURLの無効化と誤認しかねません。

プロキシの入口・ルール・出口に分けてテスト

直接接続が復旧したらクライアントを起動し、コアが動作していること、設定が読み込まれていることを順に確認します。画面が開いていても、プロキシポートが待ち受けているとは限りません。起動ログで設定の解析エラー、ポートの競合、権限不足がないか確認してください。次にシステムプロキシだけを有効にし、TUNは同時に有効にしないでください。クライアントに表示されている実際のmixed-portを確認し、以下のコマンドでプロキシの入口を明示してテストします。ポート番号は例です。設定が異なる場合は、コマンドも合わせて変更してください。

# macOS / Linux；Windows では同様のコマンドを curl.exe で実行できます
curl --connect-timeout 10 --max-time 20 \
  --proxy http://127.0.0.1:7890 \
  --head https://example.com

# 環境変数で設定されたプロキシを経由しない比較用
curl --noproxy '*' --connect-timeout 10 --max-time 20 \
  --head https://example.com

プロキシを明示したリクエストが成功し、ブラウザーでは失敗する場合、コアの入口から接続先までの経路は少なくとも今回のリクエストでは使えています。ブラウザーのプロキシ設定、拡張機能、システムプロキシを確認してください。明示的なリクエストがローカルポートへの接続に失敗する場合は、待ち受けアドレスとポートを確認します。プロキシへの接続後にタイムアウトする場合は、この接続に適用されたルール、プロキシグループ、ノードを確認してください。テスト先から必ず成功ステータスが返る必要はありません。正常なHTTPレスポンスが返れば、リクエストが何らかのサーバーに到達したことを確認できます。

ルールモードで特定のサイトだけ開けない場合は、該当するプロキシグループを一時的に利用可能と分かっているノードに切り替え、接続ログの対象ドメインと最終的に適用されたポリシーを比較します。一時的にグローバルプロキシへ切り替えると、ルールの違いを切り分けられますが、すべてのルールが誤っている証拠にはなりません。ルールモードに戻して、該当したルールを特定してください。REJECTに一致する場合はルールの提供元と順序を確認し、誤ってDIRECTになる場合はドメインが先行するルールに一致していないか調べます。誤った一致を隠すためにルール全体を削除しないでください。

復旧時に設定の一部だけが残らないようにする

TUNを有効にすると通信できず、システムプロキシだけなら動作する場合は、ノードのパスワードを入力し直すのではなく、仮想ネットワークアダプター、ルート、DNSの引き継ぎを確認します。管理者権限の不足、別のVPNのデフォルトルート、同一サブネットの競合などにより、仮想インターフェースへ入った通信が正しく戻らないことがあります。まずTUNを無効にしてルートが復旧することを確認し、クライアントの案内に従ってサービスモードを確認してください。仮想ネットワークアダプターのドライバーを次々にインストールしないでください。ネットワークを引き継ぐクライアントは1つに絞ると、問題を再現しやすくなります。

クライアントを終了してもインターネットに接続できない場合は、システムプロキシが古いローカルポートを指したままになっていないか、手動設定のDNSが残っていないか確認します。元の値を記録してから戻してください。会社のネットワークで必要な静的設定を変更しないよう注意します。復旧したら新しい接続を開いてください。ブラウザーの既存の接続は以前のセッションを引き継ぐ場合があります。最終的に、直接接続、プロキシの入口、ルール、出口のどこに問題があったかを特定してください。「何も開けない」とだけ説明するより、原因を絞って次の章に進むほうが効率的です。

ノードのタイムアウト：テスト対象と失敗した段階を確認

遅延テストの失敗と実際の通信障害を区別する

クライアントにtimeoutと表示されても、指定されたテスト先へのリクエストが制限時間内に完了しなかったことを示すだけで、あらゆる用途でノードが使えないとは限りません。まずノードを選択し、ブラウザーまたはプロキシを明示したコマンドで、アクセス可能なHTTPSサイトに接続します。その結果を遅延テストと比較してください。実際のアクセスに問題がなければ、テスト先、タイムアウト設定、自動リクエストを制限するサイトの有無を確認します。テスト先1つの結果だけを根拠に、サブスクリプション全体を削除しないでください。

すべてのノードが同時にタイムアウトする場合、同じネットワーク、クライアント、時間帯で起きているか比較します。端末の時刻が大きくずれているとTLS証明書の検証に影響するため、自動時刻設定を有効にし、タイムゾーンも確認してください。次に、端末からノードサーバーのドメインを名前解決できるか調べます。Webサイトのドメインを解決できても、サーバーのドメインを解決できるとは限りません。異なる経路で名前解決される場合があります。ログにサーバードメインの名前解決エラーがある場合は、回線品質ではなく、まず名前解決を修復してください。

名前解決、ポート、プロトコルを順に確認

サーバーのドメインを名前解決できたら、該当ポートへのTCP接続をテストします。以下は説明用のドメインとポートです。実際の調査ではサブスクリプションに記載されたサーバーアドレスとポートに置き換え、端末上でのみ実行してください。TCPテストの成功で確認できるのは、該当ポートまで接続できたことだけです。認証、暗号化パラメーター、UDP経路は確認できません。UDPを主に使うプロトコルでは、TCPプローブの失敗だけでノードが無効だとは判断できません。

# Windows PowerShell：TCP接続のみテスト
Test-NetConnection -ComputerName example.com -Port 443

# macOS / Linux：nc がインストールされている場合に使用
nc -vz -w 5 example.com 443

ログに接続拒否と表示される場合、接続先のポートが待ち受けていないか、中継機器から拒否応答が返されている可能性があります。待ち続けてタイムアウトする場合は、通信経路で破棄されている、接続先に到達できない、戻りの通信が妨げられている可能性があります。対処方法は異なります。拒否された場合はサーバーポートとリモート側の待ち受け状態を確認します。タイムアウトする場合は、別のローカルネットワークでも試してください。会社、学校、公衆Wi-Fiのネットワークでは、一部のポートやプロトコルが制限されることがあります。その環境での結果だけを根拠に、設定が壊れていると判断しないでください。

トランスポート層に接続できるのにハンドシェイクに失敗する場合は、ノードの種類、パスワードや識別子、トランスポート方式、TLSの有効・無効、サーバー名、パスを1つずつ確認します。プロトコルによっては、公開鍵、フィンガープリント、追加のトランスポート設定も必要です。項目が不足していてもクライアントが無視する場合と、解析エラーになる場合があります。まずサービス提供元が用意した互換性のある設定を再インポートしてください。別のコア向けの項目を、名前だけを頼りに追加しないでください。ハンドシェイクエラーを回避するために証明書検証を無効にしたまま使わず、ドメインと証明書が一致しているか確認してください。

比較テストで原因の範囲を絞る

特定のノードだけ失敗し、他のノードは正常な場合は、そのノードの設定やリモート側の状態を優先して確認します。同じ端末ですべてのノードが失敗し、別の端末では正常な場合は、コアの互換性、セキュリティソフト、端末側のネットワーク引き継ぎを比較します。ネットワークを変えるときはノードと設定を維持し、ノードを変えるときはネットワークを維持してください。ネットワーク、ソフト、サブスクリプションを同時に変えて復旧しても、原因は特定できません。同じ問題が再発しやすくなります。

ノードの選択が実際に反映されているかも確認します。プロキシグループが別のグループを参照していたり、自動選択グループが別のノードを選び直したりする場合があります。また、一部の接続では確立済みのセッションが再利用されます。接続の詳細でポリシーの経路全体を確認し、必要に応じて対象アプリの既存接続だけを終了してから、もう一度リクエストします。通常の速度テストで全接続を何度も切断しないでください。ダウンロードや通話が中断されるうえ、再接続が同時に発生してテスト結果に影響します。

サービス提供元に問い合わせる際は、問題が発生した時刻、接続していたネットワークの種類、プロトコル、失敗した段階、機密情報を除いたエラーを伝えます。サブスクリプションURL全体は送らないでください。詳しい確認手順はすべてのノードがtimeoutと表示される場合の確認手順をご覧ください。復旧後は成功したアクセスログを一部保存し、一時変更したテスト先とログレベルを元に戻して、次回の調査に影響しないようにしてください。

サブスクリプションの取得失敗：取得・解析・適用を切り分ける

まずURLから何が返ってきたか確認

サブスクリプションの問題は、クライアントが内容をダウンロードできるか、取得した内容を解析できるか、解析後の設定を有効にできるかの3段階に分けられます。まずエラーの全文を確認してください。接続のタイムアウトや名前解決エラーは取得段階の問題です。行番号、インデント、フィールドの型に関するエラーは解析段階の問題です。インポートは成功したのにノードが表示されない場合は、新しい設定が選択されているか、プロキシグループがノードを参照しているかも確認します。これらの問題をすべてクライアントの再インストールで解決しようとしないでください。

サービス提供元のページからサブスクリプションURLをコピーし直し、改行、前後の空白、チャットアプリが付けた句読点などが混ざっていないか確認します。URLにはアカウント情報が含まれることが多いため、公開変換サイト、スクリーンショット、オンラインデバッグツールに貼り付けないでください。ブラウザーで開いたときにログイン画面、CAPTCHA、サービス案内が表示される場合、取得したのは設定ではなくHTMLの可能性があります。サーバーが成功ステータスを返しても、内容の形式が間違っていることがあるため、ステータスコードだけで判断しないでください。

未認証またはアクセス禁止が返る場合は、サブスクリプションがリセットされていないか、アカウント権限が変更されていないか、リクエスト頻度が制限されていないか確認します。リソースが見つからない場合はURLが完全か確認し、サーバーエラーの場合は発生時刻を記録してから時間を置いて再試行してください。連続して更新ボタンを押さず、間隔を空けて再試行します。直接接続では取得できず、現在のプロキシ経由なら取得できる場合は、クライアントが対応していれば更新に使用する出口を指定できます。現在の設定がすでに使えない場合は、復旧経路を確保するため、まず利用可能なローカル設定を入手してください。

完全な設定ファイルとノードプロバイダーを見分ける

完全なClash設定には、ノード、プロキシグループ、ルール、DNSを含められます。一方、ノードプロバイダーのファイルは通常ノード一覧のみを提供し、メイン設定のproviderから参照されます。用途は異なります。プロバイダーのURLを完全な設定としてインポートすると、画面が空になったりプロキシグループが不足したりする場合があります。ノード一覧だけを受け付ける画面に完全な設定を読み込んでも、形式エラーになることがあります。サービス提供元が示すリンクの種類を確認し、クライアントの設定インポートまたはプロバイダー追加に適した項目を選んでください。

# 完全な設定ファイルの構成例；proxies が空の場合、リモートプロキシノードは作成されません
mixed-port: 7890
mode: rule
proxies: []
proxy-groups:
  - name: 手動選択
    type: select
    proxies:
      - DIRECT
rules:
  - MATCH,手動選択

上記は設定の構成を確認するための例です。デフォルトでは直接接続し、利用可能なプロキシサーバーは含まれていません。実際のノードは利用中のサービス設定から取得してください。YAMLのインデントには半角スペースを使い、同じ階層の項目を揃え、リスト項目を正しい親フィールドの下に配置します。エラー行だけでなく、その前の行にコロンや引用符の不足がないかも確認してください。半角コロンを全角コロンに置き換えたり、Webページのコードブロックを囲む記号をファイルに一緒にコピーしたりしないでください。

リクエストヘッダーによって返される内容の形式が変わる場合もあります。一部のサブスクリプションサービスはUser-Agentに応じて異なる設定を生成するため、ブラウザーでダウンロードできても、クライアントが同じ内容を受け取るとは限りません。サービスのドキュメントで指定されている場合に限り、対応するクライアント識別子をリクエストヘッダーに設定してください。別のソフトウェアをむやみに装うと、サーバーから互換性のない項目が返されることがあります。未対応のプロトコルや不明な項目がある場合は、エラー項目をすべて削除するのではなく、現在のクライアントのコアとサブスクリプションの出力先が互換性のあるものか確認してください。

新しい設定が実際に有効になっているか確認

インポート後、設定一覧で更新時刻と選択状態を確認し、プロキシグループにノードが表示されるか調べます。プロバイダーは個別の更新が必要な場合があります。メイン設定の更新時刻が変わっても、参照先のリソースが更新されたとは限りません。グループ内のフィルター式が特定の名前だけを残していると、ノード一覧が空になることもあります。サービス提供元がノードを返していないと決めつける前に、フィルター条件、プロバイダーの読み込みエラー、ノード名の変更を確認してください。

ローカルのオーバーライド、スクリプト、マージ設定によって、インポート後にルールやノードが書き換えられることがあります。調査前にバックアップを取り、これらの処理を一時的に無効にして、元の設定と実際に動作している設定の差を比較してください。クライアントが自動生成する実行用ファイルを直接編集しても、次の読み込み時に変更が上書きされる可能性があります。調整を長期的に適用する場合は、クライアントが正式に対応するオーバーライド機能を使い、変更箇所を最小限にしてください。

サブスクリプションが復旧したら、手動で一度更新して有効にし、新しい接続を確立して確認します。ノード数だけでなく、ルール、DNS、プロキシグループが想定どおりかも確認してください。形式やリクエストヘッダーの詳しい確認方法はサブスクリプションの更新失敗とYAMLの確認リストをご覧ください。サービス提供元がURLをリセットした場合は、失効した情報を使い続ける端末が繰り返しリクエストしないよう、古いURLも削除してください。

速度が遅い：応答開始・転送速度・アプリごとの差を調べる

まず遅い段階を特定

Webページの表示開始まで時間がかかる、ダウンロード開始後の速度が低い、動画が断続的に止まる。これらは異なる症状です。最初の症状はDNS、接続確立、TLSハンドシェイクが関係していることがよくあります。転送速度が低い状態が続く場合は、回線の混雑、接続先の速度制限、端末のリソース不足も考えられます。断続的に止まる場合は、パケットロス、Wi-Fi干渉、アプリのキャッシュを確認します。接続先、ノード、ネットワークを1つずつ固定し、待ち時間と転送中の状態を記録してください。複数のサイトの結果を混ぜて比較しないようにします。

クライアントの遅延テストは帯域幅テストではありません。テスト先への応答が速いノードでも、動画サービスやファイルサーバーへの経路が良いとは限りません。速度測定サイトが地域の異なるサーバーを選ぶこともあり、結果を比較できない場合があります。まずは実際の利用状況で比較してください。同じ時間帯、端末、ファイルを使い、直接接続とプロキシ接続で速度を測り、プロキシ経由だけ遅いか記録します。大容量ファイルのダウンロードと複数ノードの速度テストを同時に行うと、測定用の通信が確認中の帯域を消費するため避けてください。

接続段階と適用ルールの記録から判断

以下のコマンドでは、名前解決、接続、TLS、最初の1バイトまでにかかった時間が累積値として表示されます。HTTPプロキシ経由の場合、一部の値はプロキシの入口までの段階を示し、リモートノード単体の所要時間とは限りません。同じ条件で変更前後を比べる用途には向いていますが、特定の経路の実際の遅延を単独で算出するものではありません。まずリクエストが成功したことを確認してから、時間を比較してください。エラーページやキャッシュへのアクセスでも短い値が出る場合があります。

curl --proxy http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 30 \
  --output /dev/null --silent --show-error \
  --write-out 'DNS:%{time_namelookup} CONNECT:%{time_connect} TLS:%{time_appconnect} FIRST:%{time_starttransfer} TOTAL:%{time_total}\n' \
  https://example.com

Windowsでcurl.exeを使う場合は、出力先をNULに変更し、コマンドを1行で実行できます。最初の1バイトまでの待ち時間が長く、その後の転送は正常な場合は、名前解決、ハンドシェイク、接続先の応答、ノードから接続先までの経路を確認してください。応答開始は速いのに転送速度が大きく低下する場合は、別のノード、別のファイル提供元、端末のWi-Fi品質を比較します。短いリクエスト1回だけで長時間のダウンロード性能を推測しないでください。混雑や速度制限の条件が異なる可能性があります。

接続パネルを開き、対象のリクエストが想定したノードを実際に経由しているか確認します。Webページのメインドメインと画像、動画、ダウンロード用ドメインでは異なるルールが適用されることがあり、「ページは速いのに動画は遅い」場合は特に個別の確認が必要です。自動選択のプロキシグループがテスト中に出口を切り替える場合があります。比較テスト中はノードを一時的に固定し、終了後に元の設定へ戻してください。一部のサービスでは地域をまたぐセッションが制限されます。ノードを頻繁に切り替えると追加認証が発生し、かえって利用しにくくなる場合があります。

端末、プロトコル、ネットワーク境界を確認

まずCPU、メモリ、ディスクの使用状況を確認します。大量のデバッグログ、過剰な接続数、リアルタイムスキャン、他のダウンロードが端末側のボトルネックになる場合があります。ノートPCの省電力モードやモバイル端末の高温による性能低下も、暗号化処理に影響します。テスト中は不要な高負荷作業を終了し、ログレベルを通常に戻して同じリクエストを再確認してください。速度テストのためにファイアウォールを長時間無効にしないでください。明確なブロック記録に基づき、必要なルールを追加します。

リアルタイム通話、ゲーム、一部の動画だけに問題がある場合は、UDP対応と通信の引き継ぎ方式を確認します。ブラウザーがQUICを使っていても、システムのHTTPプロキシではその通信が処理されない場合があります。制御されたテストとしてアプリをTCP接続に切り替え、改善するか確認してから、TUNや関連ルールを調整します。プロトコルの切り替えは原因を絞るための手段であり、すべての端末に共通する最適化設定ではありません。MTUを調べるのは、大きなパケットの転送が止まる一方で小さなリクエストは正常といった根拠がある場合に限ります。まずインターフェースの元の値を記録し、狭い範囲で比較してください。

ローカルネットワークでWi-Fiの電波が強くても、干渉が少ないとは限りません。ルーターの近くで試す、有線接続に切り替える、別のネットワークを使うといった方法で、Wi-Fiとプロキシのどちらがボトルネックかを切り分けられます。複数の端末やクライアントで同じノードから同じリソースにアクセスしても遅い場合は、リモート側または中間の通信経路に原因がある可能性が高くなります。その場合は、端末の最適化設定を増やすのではなく、対象の種類、時間帯、比較結果を添えてサービス提供元に問い合わせてください。復旧後は一時的な速度制限、ノード固定、プロトコルテストの設定を解除し、設定の状態を把握できるようにします。

DNSの問題：名前解決の入口とFake-IPの対応関係を確認

どの層でドメインを名前解決しているか確認

ドメインを開けない一方、すでに確立した接続の一部は使える場合、DNSが関係している可能性はありますが、すぐに原因と決めつけないでください。まずログの名前解決エラーを記録し、システムが使用するDNSアドレス、クライアントのDNS機能の有効・無効、アプリ独自の暗号化DNSを確認します。システム、ブラウザー、プロキシコア、ルーターには、それぞれ別のキャッシュや名前解決経路がある場合があります。ある層だけを変更して別の層をテストすると結果が食い違いやすいため、各テストで誰に問い合わせているかを明確にしてください。

プロキシ接続では、接続先のドメインをプロキシ側で名前解決する場合があります。そのため、ローカルでの名前解決に失敗しても、プロキシ経由のアクセスは成功することがあります。ノードサーバーのドメインの名前解決はさらに別の問題です。ノードへの接続前にDNSが必要なのに、選択したリゾルバーへのアクセスにノードが必要だと、起動時に依存関係が発生します。まずリゾルバー自身のドメインを名前解決できる経路を確保し、その後で通常のサービスのドメインを確認してください。まだ確立していないプロキシ接続にすべてのDNSリクエストを強制的に通さないでください。

ポートを明示してコアのDNSをテスト

以下はmihomoのDNS設定例です。待ち受けはローカル端末に限定し、テスト用に専用ポートを使っています。パブリックDNSは設定例であり、現在のネットワークで到達できるとは限りません。プライバシーや通信経路の推奨を示すものでもありません。既存の設定に追加する前に、dnsルート項目が重複していないか、クライアントがこの項目を上書きしないか確認してください。待ち受けを有効にしただけではシステムが自動的に利用するとは限りません。クライアントによる引き継ぎ、または明示的な問い合わせが必要です。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 1.1.1.1
  nameserver:
    - https://cloudflare-dns.com/dns-query
# macOS / Linux：dig をインストールして、指定した DNS の入口をテスト
dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com AAAA

Fake-IPモードでは、予約済みアドレス範囲から割り当てられたIPアドレスが返されます。これは想定どおりの動作であり、Webサイトのサーバーが実際にそのアドレスにあることを示すものではありません。コアは割り当てとドメインの対応関係を使ってドメインを特定し、ルールを適用して通信を転送します。アプリが割り当てられたIPアドレスを取得した後、コアを経由せず直接接続すると失敗する場合があります。Fake-IPの動作確認では、返されたIPアドレスがパブリックIPに見えるかどうかだけでなく、その後の接続が同じコアに引き継がれているか、対応表が残っているかも確認してください。

拡張モードの切り替え、コアの再起動、設定の変更後に、システムやアプリに古い対応情報が残る場合があります。まず対象のアプリを終了し、該当するキャッシュを消去してから、新しいリクエストを実行します。Windowsではipconfig /flushdnsでシステムのDNSキャッシュを削除できますが、ブラウザー、アプリ、ルーターにも独立したキャッシュがある場合があります。他のプラットフォームではシステムの手順に従い、特定のOS向けコマンドをすべての端末で使わないでください。キャッシュを消す前に名前解決の経路を修復しないと、同じエラーが再び発生します。

ローカルドメイン、IPv6、ルートの競合を確認

プリンター、社内ネットワーク、家庭内ストレージのドメインでは、通常、ローカルDNSや特定の検索ドメインが必要です。すべてのドメインをパブリックDNSに問い合わせると、これらのサービスが使えなくなる場合があります。ローカルでの名前解決が必要と確認できたドメインには、個別のDNSポリシーを設定してください。必要に応じてFake-IPのフィルターに追加し、実際のアドレスを返します。フィルターには問題が確認されたドメインだけを指定してください。範囲の広すぎるワイルドカードは多くの通常リクエストに影響し、問題の再現も難しくなります。

IPv4とIPv6の両方を確認します。ドメインからAAAAレコードが返されても端末のIPv6経路が利用できない場合、アプリが接続に失敗してからIPv4へ切り替えるため、初回のアクセスに時間がかかることがあります。比較テストとして一方のIPv6機能を一時的に無効にする方法もありますが、システムインターフェース、コアの名前解決、ノードの出口のどこに問題があるか区別してください。最終的には経路を修復するか、明確なポリシーを設定します。すべての層で同時に無効にすると原因を特定できなくなります。企業ネットワークではFake-IPのアドレス範囲とルートが競合する場合もあるため、範囲を変更する前に既存のネットワークを確認してください。

ブラウザーのセキュアDNSとシステムのDNS引き継ぎが同時に動作している場合もあります。ブラウザーだけに問題がある場合は、セキュアDNSの設定を比較してください。社内ネットワークだけに問題がある場合は、ドメイン別の名前解決とローカルルートを確認します。復旧の目安は、新しい名前解決が成功し、新しい接続に想定どおりのポリシーが適用され、ローカルサービスも引き続き利用できることです。DNSから応答があっても、回答が正しいことや接続経路が安全であることまでは確認できません。設定項目の意味は用語クイックガイドで、DNSやネットワークスタックに関する用語をご確認ください。

システムプロキシが機能しない：アプリがプロキシの入口を使っているか確認

システムプロキシ、環境変数、TUNの適用範囲を確認

システムプロキシは、通常、システム設定に従うアプリにHTTPプロキシの入口を提供しますが、端末上のすべての通信を引き継ぐわけではありません。コマンドラインツール、ゲーム、サービスプロセス、独自のネットワークスタックを持つアプリは、この設定を無視する場合があります。TUNは仮想インターフェースとルートを使って通信を引き継ぎますが、権限、除外ルール、他のネットワークソフトの影響を受けます。まず対象のアプリがどの入口を使うか確認してから対処方法を選んでください。システムプロキシのスイッチがオンであることを、端末全体の通信がプロキシ経由である証拠とみなさないでください。

最も簡単な切り分け方法は、プロキシを明示したコマンドでテストすることです。明示的なリクエストは成功するのに、対象アプリがクライアントの接続ログにまったく表示されない場合は、ノードではなくアプリ側の接続方法を確認します。ログにリクエストが表示されるのにDIRECTを通る場合は、ルールまたはポリシーに問題があります。想定したノードを経由して失敗する場合は出口を調べます。接続ログを確認するときはリクエストを新たに実行してください。確立済みの長時間接続は、システム設定を変えてもすぐに切り替わらない場合があります。

待ち受け、環境変数、プラットフォームの設定を確認

ローカルプロキシは通常、ループバックアドレスで待ち受けます。クライアントとアプリが同じOS上で動作する場合は127.0.0.1を使用できます。コンテナー、仮想マシン、一部のサブシステムでは、ループバックアドレスがホストではなく各環境自身を指す場合があります。実際のネットワークモードに応じてホストのアドレスとアクセス権を確認し、ローカル端末向けのコマンドをそのままコピーしないでください。LANからのアクセスが本当に必要な場合に限り、待ち受け範囲、ファイアウォール、認証を設定します。コンテナーのテストのためだけに、プロキシポートをネットワーク全体に公開しないでください。

入口主な対象確認するポイント
システムプロキシシステム設定に従うアプリプロキシアドレス、例外リスト、ブラウザー拡張機能
環境変数対応する環境変数を使うコマンドラインプログラム現在のプロセス環境、環境変数の優先順位
TUN仮想インターフェースに入る通信権限、ルート、除外項目、DNS
アプリ内プロキシ該当アプリ自身プロトコルの種類、ポート、接続先での名前解決方法

ターミナルツールはHTTP_PROXY、HTTPS_PROXY、ALL_PROXYを参照する場合もあれば、小文字の変数だけを参照する場合もあります。詳しくは各ツールのドキュメントを確認してください。環境変数を変更しても、起動済みのプロセスには通常、新しい値が自動で反映されません。まず現在のターミナルで一時的に設定してテストし、すぐに全体設定の起動ファイルへ書き込まないでください。NO_PROXYも確認します。例外の範囲が広すぎると、対象がプロキシを経由しなくなります。設定の残存を防ぐため、以下の例では1回のコマンドだけに適用する方法を使います。

# macOS / Linux：今回のリクエストに限って環境変数を設定
HTTP_PROXY=http://127.0.0.1:7890 \
HTTPS_PROXY=http://127.0.0.1:7890 \
curl --head --max-time 20 https://example.com

# Windows：現在のユーザー設定と WinHTTP 設定を確認（それぞれ別の入口）
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable
netsh winhttp show proxy

WindowsのユーザープロキシとWinHTTPのサービス用プロキシは別々の設定です。一方の確認コマンドの結果で、もう一方の設定を判断することはできません。サービスの通信がプロキシを経由しないからといって、すぐに全体設定をインポートしないでください。まずサービスの実行アカウントと対応方法を確認します。macOSのプロキシ設定はネットワークサービスごとに異なり、Wi-Fiと有線を切り替えると別の設定が使われる場合があります。Linuxのデスクトップ環境のプロキシ設定も、バックグラウンドサービスに引き継がれるとは限りません。ネットワークを切り替えるたびに、対象アプリが実際に使う入口を確認してください。

UWP、拡張機能、異常終了後に残った設定を確認

Windowsの一部のサンドボックスアプリでは、ローカルのループバックへのアクセスが制限されています。コアの入口が使え、通常のデスクトップアプリは正常なのに、特定のアプリだけがループバックポートに接続できない場合に限り、UWPのループバック制限を確認してください。クライアントの管理機能を優先して使い、対象アプリだけに例外を設定します。制限の解除はローカルネットワークへのアクセス権を変更するもので、ノード認証、サブスクリプション、リモート接続の問題は解決しません。不要になったら該当アプリの例外を取り消してください。

ブラウザーのプロキシ拡張機能、自動構成スクリプト、システムの手動プロキシ設定が互いに上書きし合うことがあります。調査中は拡張機能を一時的に無効にし、設定元を1つだけにして、例外リストに対象ドメインが含まれていないか確認してください。クライアントが異常終了すると、システムが終了済みのローカルポートを引き続き参照し、ブラウザー全体でアクセスできなくなることがあります。システム設定を元に戻してからクライアントを再起動し、スイッチの状態と実際のアドレスが一致することを確認します。終了するたびに設定が残る場合は、誤ったプロキシ設定を残したまま起動を繰り返すのではなく、終了時のログを確認してください。

クライアントのクラッシュ：画面、コア、サービスの障害を切り分ける

まず停止したプロセスを確認

ウィンドウが消える、画面が真っ白になる、コアが終了する、サービスの起動に失敗する場合では、対処方法が異なります。ウィンドウを開けなくてもプロキシが使える場合は、画面側だけの問題かもしれません。画面は正常でもプロキシポートが待ち受けていない場合は、コアのログを確認してください。TUNだけ起動できない場合は、サービスの権限や仮想インターフェースに問題がある可能性があります。まずタスクマネージャーまたはシステムモニターでプロセスの状態を確認し、最後に記録されたエラーを保存します。画面の異常だけを根拠に設定をすべて削除しないでください。問題を再現するための重要な情報が失われます。

問題が起きたときの操作を記録します。起動直後に終了する、特定の設定を読み込むと終了する、TUNを有効にすると終了する、長時間実行後に終了するなど、発生条件によって確認範囲が異なります。起動直後の失敗ではファイル権限、アーキテクチャ、実行時の依存関係を確認します。設定の読み込みがきっかけなら解析エラーや独自処理を調べます。長時間実行後に終了する場合は、メモリ、接続数、ログの増加を確認してください。システムのイベントビューアーやクラッシュレポートもクライアントのログを補完できますが、共有する前にユーザー名、パス、アクセス情報を削除してください。

設定の検査と最小構成で原因を特定

mihomoを単独で実行できる環境では、まずコアの設定検査機能を使ってファイルを解析できるか確認します。コマンドでは実際の設定ファイルを指定してください。設定が外部ルールやノードプロバイダーを参照する場合は、関連リソースのパスが存在することも確認します。検査に成功しても、すべてのリモートノードに接続できるとは限りません。また、GUIのオーバーライドを適用した最終設定が同一とは限りません。クライアントで実行中の設定を確認できる場合は、サブスクリプションの元ファイルだけでなく、実際に使われている設定を優先して確認してください。

# macOS / Linux：コアがあるディレクトリで実行
./mihomo -t -f ./config.yaml

# Windows PowerShell：コアがあるディレクトリで実行
.\mihomo.exe -t -f .\config.yaml

設定検査でポートの競合が報告された場合は、誰が待ち受けているか確認してから、既存のプロセスを終了するかポートを変更するか判断します。名前が似たプロセスを一括で終了しないでください。システムサービスや別のアプリが使用している場合があります。mixed-portを変更したら、システムプロキシ、アプリ内プロキシ、コマンドラインの環境変数も更新します。コントローラー用ポートとプロキシポートは用途が異なります。ブラウザーの接続先をコントローラー用ポートにしても、通常のプロキシ接続は確立されません。

最小構成での起動でも、元に戻せる状態を保ってください。まず設定ディレクトリ全体をコピーし、スクリプト、オーバーライド、カスタムルール、追加プロバイダーを一時的に無効にします。その後、毎回1項目ずつ戻してください。最小構成で動作する場合は、元の項目を段階的に追加して問題を再現します。バックアップなしでアプリのデータを消去しないでください。サブスクリプション、プロキシの選択、ローカルルールも含まれている可能性があります。ディレクトリの場所はクライアントの設定またはログで確認してください。プラットフォームやインストール方法によって異なる場合があります。

システム環境を確認し、復元できる状態を保つ

インストーラーはCPUアーキテクチャとOSの種類に合ったものを使います。Linuxではディストリビューションに応じてパッケージ形式も確認してください。セキュリティソフトが起動をブロックした場合は、明確なブロック記録とファイルの配布元を確認します。起動のために保護機能全体を無効にしないでください。ディレクトリへの書き込み権限がない、ディスク容量が不足している、同期ツールがユーザー設定ディレクトリをロックしているといった理由で、保存や起動に失敗することもあります。比較テストには通常ユーザーが書き込める別のディレクトリを使えますが、すべてのプログラムを管理者権限で常時実行しないでください。

画面が真っ白になる原因には、システムのWebViewやグラフィックドライバーが関係している場合もあります。ただし、これは該当コンポーネントを使うクライアントに限られ、すべてのClashクライアントに当てはまるわけではありません。まずシステムコンポーネントが正常か確認し、対象クライアントのドキュメントに沿って対処してください。コアのログが出続ける一方で画面が応答しなくなる場合は、大量の接続更新やログの連続出力が伴っているか記録します。画面更新の負荷を減らして比較できますが、ログをすべて無効にしたまま原因を推測しないでください。

再インストールが必要な場合は、ダウンロードページから対応するプラットフォームとアーキテクチャのものを選び、まずバックアップした設定のコピーでテストしてください。Clash for WindowsとClashX Metaは開発が終了したアーカイブ版クライアントです。新しいOSとの互換性に問題がある場合は、Clash Plusやダウンロードページにある他の対応クライアントを検討してください。画面を変更するだけで設定がすべて自動移行されるとは限りません。Linuxでコアを単独で展開する方法はmihomoとsystemdのセットアップ手順をご覧ください。

問い合わせ時は、プラットフォーム、アーキテクチャ、クライアント名、問題を起こす手順、設定検査の結果、機密情報を除いたエラーを添えてください。特定の設定でのみ再現する場合は、最小限のサンプルに切り詰め、実際のサーバー認証情報を削除した状態でも再現することを確認します。復旧後はシステムプロキシとTUNの状態も確認してください。クラッシュ後に残った設定が、別のネットワーク障害を引き起こす場合があります。最後に、調査中に上げたログレベルを元に戻し、ログがディスク容量を使い続けないようにします。

モバイル端末のトラブル：権限、バックグラウンド動作、ネットワーク切り替え

Android：VPNの許可と対象アプリを確認

Androidクライアントは通常、システムのVPNインターフェースを通じて通信を引き継ぎます。初回起動時にはシステムの許可が必要です。他のVPN、仕事用プロファイルのネットワークツール、セキュリティアプリが同じインターフェースを使用している場合もあります。まず他の通信引き継ぎツールを終了してからクライアントを起動し、システムのVPN状態とクライアントのログが一致しているか確認してください。ステータスアイコンで分かるのはシステムインターフェースが存在することだけです。ノード、DNS、ルールが正常とは限らないため、新しいリクエストを実行して適用されたポリシーを確認します。

Clash Plus、Clash Meta for Android、FlClash、Surfboardでは画面や設定機能が異なります。あるクライアントが対応する項目を、他のクライアントでも使えると決めつけないでください。インポート後にプロトコルやルールのエラーが出る場合は、サブスクリプションの出力が選択したクライアントに対応しているか確認します。Surfboardの設定形式も、すべてのClash YAMLと同じではありません。初めて使う場合は入門ガイドに沿って基本的な接続を確立し、その後にアプリ別設定やカスタムルールを追加してください。

アプリ別プロキシを有効にしている場合は、選択したアプリだけをプロキシ経由にするモードか、選択したアプリを除外するモードか確認します。アプリ一覧は似ていても、意味は正反対です。対象アプリが接続ログに表示されない場合、除外されているか、アプリが古い接続を使い続けている可能性があります。対象を変更した後は、そのアプリの既存セッションを終了して再起動してください。ブラウザーは使えるのに他のアプリで問題が起きる場合は、アプリ独自のDNS、証明書の要件、プロキシ設定も確認します。バックグラウンド権限だけを原因と決めつけないでください。

iOS：設定が有効か、システムトンネルが動作しているか確認

iPhoneではiOSダウンロードページからClash PlusのApp Storeページにアクセスできます。公式サイトはclashplus.ioです。インストール後に設定をインポートし、システムVPNの許可を済ませたうえで、新しくインポートした設定が有効になっているか確認します。サブスクリプション一覧にファイルが表示されても、トンネルがその設定を使っているとは限りません。更新後はプロキシグループを確認し、新しい接続で出口をテストしてください。

iOSでも複数のVPN設定や他のネットワーク拡張機能が存在する場合があります。まず実際に動作させる通信引き継ぎ元を1つに絞り、トンネルが確立しているか確認します。アプリを前面に表示している間は使えるのに、画面ロック後に切断される場合は、システムの動作制御、ネットワーク切り替え、リモート側の長時間接続の切断を区別してください。アプリを再び前面に表示した後の状態だけを見ず、切断が起きた時刻を記録し、新しいリクエストで自動復旧するか確認します。一時的な再接続と継続的な通信不能は別の問題として説明してください。

特定のアプリだけに問題がある場合は、通常のWebページ、同じサービスの別の入口、そのアプリの接続ログを比較します。アプリ独自の地域、アカウント、不正利用対策、サーバー側ポリシーが影響している場合もあり、プロキシ接続が成功してもすべての機能が使えるとは限りません。1つの機能エラーに対して複数の出口を頻繁に切り替えないでください。追加の認証が発生することがあります。設定の入手からインポートまでの手順はiPhoneクライアントとサブスクリプション設定のインポートをご覧ください。

バックグラウンド動作、省電力、Wi-Fi切り替えを確認

Androidで画面ロック後に切断される場合は、バックグラウンド動作、バッテリー最適化、バックグラウンドデータが制限されていないか確認します。端末の設定から必要な権限だけを許可し、省電力機能を端末全体で無効にしないでください。端末によっては、タスクの終了時にネットワークプロセスも停止する場合があります。前面表示で安定して接続できることを確認してから画面をロックし、ログにプロセスの再起動が記録されているか調べてください。プロセスが停止しておらず接続だけが失敗する場合は、ネットワークやノードを引き続き確認し、切断をすべてシステムによる終了のせいにしないでください。

Wi-Fiとモバイルデータを切り替えると、アドレス、デフォルトルート、名前解決環境が変わり、既存の接続を再利用できなくなる場合があります。テストではまずネットワークを1つに固定し、安定したことを確認してから切り替えます。切り替えた瞬間だけ失敗するのか、その後も新しい接続を確立できないのかを記録してください。切り替え後にトンネルを再確立すると復旧する場合は、ネットワーク変更時の処理を重点的に確認します。ネットワークを固定しても定期的に失敗する場合は、ノード、DNS、バックグラウンド制限の各章に戻ってください。移動しながらホットスポットを切り替えて、ノードの安定性を判断しないでください。

モバイルホットスポットにも通信の引き継ぎ範囲があります。スマートフォン自身がVPN経由でも、テザリング先のPCが同じ経路を通るとは限りません。共有された通信がトンネルを通るかどうかは、OSとクライアントの機能によります。スマートフォンのステータスバーだけを見ず、接続先の端末でも個別に確認してください。従量課金のネットワークでは、サブスクリプションの一括テストや大容量ファイルの速度測定も停止し、調査自体が通信量を使い続けないようにします。