「コアの起動」と「通信の成功」を切り分ける
Clashクライアントに「接続済み」と表示されても、GUIがローカルのコアに接続した、あるいはシステムプロキシが有効になったことを示すだけの場合があります。サブスクリプション内のノードが使えることや、ブラウザーのリクエストが適切なポリシーグループを通ることまでは保証されません。通信経路は、アプリからのリクエスト → ローカルプロキシまたはTUNによる取り込み → ルール判定 → ポリシーグループの選択 → ノードへの接続 → 接続先サイトからの応答、という流れです。どこか一つでも失敗すれば、ページが読み込み中のままになることがあります。
Clashは、プロキシコアや設定エコシステムを指す一般的な呼称です。Clash Metaはその後、mihomoの名称で開発が続いています。GUIクライアントによってメニューの場所、設定の上書き方法、コアの機能は異なります。トラブルシューティングを始める前に、クライアントの「バージョン情報」または「コア」画面で実際のバージョンを確認してください。設定は使用中のコアが対応する項目に合わせ、他人のYAMLファイル全体を現在のサブスクリプションにそのまま上書きしないでください。
再現可能なテスト条件を整える
- 現在の設定名、プロキシモード、ポリシーグループで選択中のノード、HTTPまたは混合ポート、TUNの有効・無効を記録します。
- ほかのVPN、プロキシクライアント、ブラウザー拡張機能によるプロキシ設定を一時的に無効にし、経路の競合を避けます。組織で必要なセキュリティソフトはそのままにしてください。
- プロキシなしで普段アクセスできるサイトと、現在のプロキシ経由でアクセスするサイトを一つずつ用意し、毎回同じURLでテストします。
- クライアントの接続一覧とログを開き、まずInfoレベルで問題を再現します。情報が足りない場合のみ、短時間Debugを有効にしてください。
手順1：サブスクリプションの有効性と設定の読み込みを確認
「サブスクリプション更新成功」は、クライアントが更新処理を完了したことを示すだけです。プランの通信量が残っていることや、ダウンロードした設定が現在有効な設定であることまでは意味しません。設定またはサブスクリプション画面で対象の設定が選択されていることを確認し、プロキシ画面に想定したノードとポリシーグループが表示されるか確認します。古いノードが表示されたままなら、別の未有効サブスクリプションを更新していないか確認してください。
- プランの状態：プロバイダーのアカウントページで、有効期限、残りの通信量、デバイス数の制限を確認します。クライアントに表示される使用量は通常、サブスクリプションのレスポンスヘッダーに基づくため、表示されない場合や反映が遅れる場合があります。
- ダウンロードエラー：HTTP 401や403は認証エラーまたはアクセス制限、404はURLの無効化、429はリクエスト頻度の制限で発生することがあります。更新ボタンを何度も連続して押さないでください。
- 設定内容のエラー：ログにYAMLの解析エラー、未知の項目、ポリシーグループが見つからないといった表示がある場合は、まず設定の互換性を確認します。ログイン画面やエラーページのHTMLをClashの設定として使うことはできません。
- リモートリソース：メイン設定の読み込みが完了していても、
proxy-providersやrule-providersの更新に失敗すると、ノードが表示されなかったり、ルールが想定どおりに動かなかったりすることがあります。
サブスクリプションの更新にプロキシが必要で、利用可能なノードもない場合は、プロバイダーが許可する範囲で、利用可能なネットワークや公式の予備購読用URLを試してください。完全なサブスクリプションURLを、見知らぬ変換サイトや公開掲示板に貼り付けないでください。URL内のアクセストークンは、アカウント情報と同じように扱う必要があります。
手順2：遅延の数値だけで判断せず、ノードを検証
遅延テストの成功が示すのは、その時点で指定されたテスト先への疎通確認ができたことだけです。テスト先に接続できても、目的のWebサイトに接続できるとは限りません。また、80 msと表示されても十分な帯域があるとは限りません。Webページの通信にはDNS、TLS、複数のリソースドメイン、場合によってはUDP通信も関わり、単発の疎通確認より複雑です。
ノードを手動選択して比較する
- 対象の通信を実際に処理するポリシーグループでノードを手動選択します。トラブルシューティング中に自動選択グループが出口を切り替え続けるのを防げます。
- 対象サイトにアクセスし、ログに表示された時刻、ノード名、エラーを記録します。次に別の回線のノードへ切り替え、同じリクエストを試してください。
- スマートフォンのテザリングに切り替えて再試行します。同じノードが特定のWi-Fiでだけ失敗する場合は、そのネットワークの外部接続制限、認証ページ、DNSを引き続き確認してください。
| 結果 | 確認する項目 |
|---|---|
| 特定のノードだけが繰り返しタイムアウトする | ノードサービス、アドレス解決、ポート、現在のネットワークからサーバーへの接続性 |
| すべてのノードで失敗し、直接接続は正常 | サブスクリプションの状態、コアの互換性、共通して使われるDNS、ローカルでの通信遮断 |
| ほとんどのサイトは正常だが、特定のサイトだけ失敗する | 対象サイトの制限、ルール判定、地域要件、特定のリソースドメイン |
| 証明書の日付エラーが表示される | デバイスの日時、タイムゾーン、システム証明書、ネットワーク上のHTTPS検査 |
ログのconnection refusedは通常、接続先のいずれかが接続を拒否したことを示します。i/o timeoutは、該当する処理が制限時間内に完了しなかったことを表します。エラー内の接続先アドレスを確認し、どの段階で発生したか判断してください。TLSエラーを消すために証明書検証を無効にするのではなく、まずシステム時刻を合わせ、ノードの設定値を確認してください。
手順3：プロキシモードを切り替えて原因を絞り込む
ルールモードではルール一覧に基づいて使用するポリシーが決まり、グローバルモードではコアが取り込んだリクエストがグローバルポリシーに送られます。DIRECTモードでは接続先に直接接続します。ここでいう「グローバル」は通信の出口ポリシーを指し、すべてのアプリが自動的にClashを経由するという意味ではありません。システムプロキシを使わず、プロキシを明示的に設定せず、TUNにも取り込まれていないプログラムは、コアを経由しないことがあります。
- まずルールモードで問題を再現し、接続一覧に表示されるルールと出口を記録します。
- 一時的にグローバルモードへ切り替え、手順1で動作を確認したノードを明示的に選択してから、同じWebページを開きます。
- グローバルモードでは成功し、ルールモードで失敗する場合は、ルール、ポリシーグループ、直接接続時の名前解決を重点的に確認します。両方で失敗する場合は、プロキシの入口とDNSを引き続き確認してください。
- テスト後はルールモードに戻し、プロキシ不要の通信がグローバル出口を通り続けないようにします。
手順4：システムプロキシとローカルの待ち受けポートを確認
以下のコマンドは、クライアントでmixed-port: 7890が有効になっていることを前提としています。7890は例なので、画面に表示された実際のポート番号に置き換えてください。混合ポートはHTTPとSOCKSの両方のプロキシ接続を受け付けますが、SOCKS専用ポートをHTTPプロキシとして入力することはできません。デスクトップPC上の通常のローカルプロキシアドレスは127.0.0.1です。ローカルのブラウザーで利用するだけなら、LAN共有を有効にする必要はありません。
システム設定とプロキシを明示したリクエストを確認
Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシとセットアップスクリプトを確認します。macOSでは「システム設定」→「ネットワーク」→現在のネットワークサービス→「詳細」→「プロキシ」を確認してください。クライアントがシステムプロキシを設定している場合、ここに表示される設定は実際の待ち受けポートと一致している必要があります。Firefoxなど、独自の設定を使うブラウザーもあります。「設定」→「一般」→「ネットワーク設定」→「設定」を開き、システムプロキシを使うのか、別の手動ポートを使うのか確認してください。
Windows PowerShellでは、まず待ち受け状態を確認し、次にHTTPプロキシを指定したリクエストを実行します。curl.exeを使うと、旧バージョンのPowerShellで同名のエイリアスが干渉するのを防げます。
Get-NetTCPConnection -State Listen -LocalPort 7890
curl.exe -I --connect-timeout 10 --max-time 20 -x http://127.0.0.1:7890 https://example.com/
curl.exe -I --connect-timeout 10 --max-time 20 --noproxy "*" https://example.com/macOSとLinuxでは、以下のリクエストで動作を比較できます。テスト用URLは一般公開されている例なので、続けて実際に開けないサイトのURLでも試してください。-IはHEADリクエストを送ります。サイトがHEADに対応していない場合は、-o /dev/null -vに切り替えて通常のGETリクエストを送信してください。
curl -I --connect-timeout 10 --max-time 20 -x http://127.0.0.1:7890 https://example.com/
curl -I --connect-timeout 10 --max-time 20 --noproxy "*" https://example.com/- 127.0.0.1にすぐ接続できない：コアが起動しているか、ポートが変更されていないか、待ち受け中のプロセスが本当に現在のクライアントのものかを確認してください。
- プロキシを明示すると成功するが、ブラウザーでは失敗する：ブラウザーのプロキシ拡張機能、PACスクリプト、独自のプロキシ設定、古い接続のキャッシュを優先的に確認してください。
- HTTP 407が表示される：ローカルプロキシで認証が必要か確認してください。リモートノードが原因とは限りません。
- 接続トンネルの確立後にTLSエラーが発生する：トンネルが確立してもWebページの表示成功とは限りません。TLSエラーとコアのログを引き続き確認してください。
--noproxy "*"が回避するのはcurlのアプリケーション層プロキシ設定だけで、TUNやほかのVPNは回避できません。実際の直接接続経路と比較する場合は、現在の状態を記録してから、関連する通信取り込み機能を一時的に無効にしてください。ターミナルがデスクトップのシステムプロキシ設定を参照するとは限りません。HTTP_PROXY、HTTPS_PROXY、ALL_PROXY、NO_PROXYを確認し、古い環境変数で別のポートにリクエストが送られていないか調べてください。
手順5：DNSエラーがどの層で発生しているか切り分ける
DNSには少なくとも、ノードサーバーのホスト名、アクセス先サイトのドメイン名、暗号化DNSサービス自体のドメイン名という三つの異なる対象があります。ノードサーバーのホスト名を解決できないと、プロキシトンネルを確立できないことがあります。接続先ドメインの名前解決に失敗した場合は、特定のサイトだけでエラーになることがあります。また、まだ確立していないプロキシ経路にDNSの上流サーバーが依存していると、循環依存が発生する場合もあります。
まず状況を確認し、必要な場合にだけDNSを変更する
- ログに
lookup、no such host、DNS timeoutなどが記録されていないか確認し、該当するドメイン名を控えてください。 - Windowsでは
Resolve-DnsName example.com、macOSまたはLinuxではnslookup example.comを実行してシステムの名前解決を確認し、クライアントのログに記録された結果と比較します。 - ブラウザーのセキュアDNS設定を確認します。ブラウザー内蔵のDoHによって名前解決の経路が変わることがあります。一時的に無効にして再テストした後、必要に応じて元の設定に戻してください。
- システムのDNSキャッシュが古いと確認できた場合に限り、Windowsで
ipconfig /flushdnsを実行してから、ブラウザーで接続し直してください。
システムのDNS問い合わせに成功しても、コアのDNSが正常とは限りません。両者で異なる上流サーバーを使う場合があります。反対に、システムの問い合わせに失敗しても、プロキシ経由のドメイン要求はコアやリモート側で名前解決されるため、必ず失敗するとは限りません。1回のnslookupだけを根拠に、すべてのDNS項目を一括で置き換えないでください。
fake-ipモードで、設定のfake-ip-rangeに含まれる合成アドレスが表示されるのは正常な場合があります。よく使われる範囲の例は198.18.0.0/16です。こうしたアドレスは、コアがドメイン名と接続を関連付けるために使うもので、実際のWebサイトのアドレスではありません。アプリが合成アドレスを取得しても、接続がその通信を取り込むコアに戻らなければ失敗します。hostsに合成アドレスを書き込むのではなく、ルーティング、DNSの取り込み、ほかのVPNとの競合を確認してください。
手順6：ルールの判定とポリシーグループの最終出口を確認
グローバルモードでは使えるのにルールモードで失敗する場合は、接続一覧を開き、対象ドメインへのリクエストを探して、適用されたルールとポリシーの経路を確認します。ルールは通常、上から順に照合されます。先にある広範なルールがリクエストを先取りしている場合があります。MATCHは最後のフォールバックなので、後続のルールを有効にしたい場合は、その前に置かないでください。
以下はルールの順序を示す例であり、サブスクリプションをそのまま置き換えられる完全な設定ではありません。example.comとそのサブドメインを「Webプロキシ」というポリシーグループに送り、それ以外の接続は直接接続します。使用前に、そのグループが実際に存在し、利用可能なノードが選択されていることを確認してください。
rules:
- DOMAIN-SUFFIX,example.com,Webプロキシ
- MATCH,DIRECT- DIRECTに一致：直接接続が想定どおりか、現在のネットワークからそのサイトに直接接続できるかを確認してください。
- REJECTに一致：ブロックルールやルールセットに対象ドメインが誤って含まれていないか確認してください。すべての保護ルールを一度に無効にしないでください。
- プロキシグループに一致しても失敗する：ポリシーの経路をたどり、入れ子になったグループの最終ノードを確認してください。グループ名が同じでも、出口が同じとは限りません。
- トップページは表示されるが、画像やログインが失敗する：CDN、認証、APIのドメインを確認してください。これらのリクエストには異なるルールが適用されている可能性があります。
ルールセットのダウンロード失敗、クライアント側の設定上書き、プロセスルール、サブスクリプションの更新によって、最終的な設定が変わることがあります。サブスクリプションの元ファイルだけでなく、実際に有効な設定と接続履歴を確認してください。設定を変更した後は、新しい接続を開始して再テストします。既存の長時間接続は変更前の経路を使い続ける場合があります。
手順7：必要な場合のみTUN、IPv6、UDPを確認
ブラウザーでプロキシを明示したリクエストは成功するのに、ゲーム、ターミナル、ほかのアプリで失敗する場合は、まず対象アプリがプロキシに対応しているか確認します。すべてのプログラムがシステムプロキシ設定に従うとは限りません。より広範囲の通信を取り込む必要がある場合にのみTUNを検討してください。TUNを有効にしても、適切なルーティング、権限、DNSが必要です。スイッチをオンにするだけで、すべての問題が解決するわけではありません。
- TUNと権限：サービスモードまたは必要な権限が有効か確認し、仮想インターフェースやルートの作成に失敗したというログがないか調べてください。
- ネットワークの競合：必須ではない別のVPNを一時的に停止して再テストし、ルートの優先順位、仮想ネットワークアダプター、DNSの取り込みが競合していないか確認してください。
- IPv6：対象にAAAAレコードがあるか、実際の接続がIPv6を使っているか確認してください。IPv4では接続できてもIPv6で失敗する場合は、該当するルートまたは出口を修正します。システム全体でIPv6を無効にする方法を安易に既定の対処法にしないでください。
- UDPとQUIC：ブラウザーによっては、UDP 443を使うHTTP/3で通信します。TCPのWebリクエストは成功するのにUDPを使うアプリが失敗する場合は、ノードのプロトコル、サーバー、ローカル側の通信取り込みが、そのUDP経路に対応しているか確認してください。
必要であれば、比較のためにブラウザーのQUICを一時的に無効にできますが、汎用的な高速化設定として扱わないでください。大きなページだけ読み込みが止まり、小さなリクエストは正常な場合は、経路MTU、パケットロス、回線の混雑も考えられます。まず再現時の記録を残し、MTUの数値を次々と試さないでください。
最後に：最小限の設定に戻し、障害の記録をまとめる
原因を特定したら、ルールモード、通常使用するDNS、必要な通信取り込み方法に戻し、比較のために加えた一時的な変更を取り消します。クライアント終了後も、待ち受けプロセスのないポートを指すシステムプロキシ設定を残さないでください。クライアントを終了するとすべてのページが開けなくなる場合は、ブラウザーをすぐに再インストールするのではなく、システムプロキシが127.0.0.1:7890を指したままになっていないか確認してください。
問い合わせ時に添える情報
- OSのバージョン、クライアントのバージョン、実際に使用しているコアのバージョン。TUN、システムプロキシ、ブラウザーのセキュアDNSが有効かどうか。
- 問題が発生した時刻、対象ドメイン、再現手順、すべてのサイトに影響するのか特定のサイトだけなのか。
- ルールモード、グローバルモード、別のノード、別のネットワークで同じ対象を試した結果。
- 個人情報を削除したエラーログ、ルールの判定、最終的な出口。サブスクリプショントークン、ノードのパスワード、認証情報を含む完全な設定は共有しないでください。
「何度も再起動した」よりも、「プロキシを明示すると成功するがブラウザーでは失敗する」や「グローバルモードでは成功し、ルールモードでDIRECTに一致すると失敗する」といった情報のほうが役立ちます。通信経路ごとに切り分けた記録があれば、問題をアプリの入口、ノード、DNS、ルールに絞り込めます。設定を何度も変更することで新たな問題が起きるのも防げます。