クライアントの状態とWebリクエストを切り分ける

Clashクライアントに「接続済み」と表示されるのは、通常、コアが動作している、プロキシが有効になっている、または特定のチェックに成功したことを示します。ブラウザーのすべてのリクエストがノード経由になっているとは限りません。通信経路には、アプリのプロキシ設定、コアのルール、出口ノード、ドメイン名の解決、接続先のサーバーが含まれます。どこか一つでも問題があれば、Webページが読み込み中のままになることがあります。

トラブルシューティングでは、一度に変更する項目を一つに絞ってください。まず現在の設定とオーバーライドファイルを残し、クライアント名、コアのバージョン、選択中のポリシー、エラーが発生した時刻を記録します。クライアントによって設定項目の名称は異なるため、以下では設定フィールド、OSの設定画面、確認できる結果を基準に説明します。特定のクライアントのボタン名を共通メニューとして扱うことはありません。

  • すべてのアプリで通信できない：まずプロキシとTUNをオフにし、Wi-Fi、有線LAN、デフォルトゲートウェイ、ネットワーク認証が正常か確認します。
  • ブラウザーだけ開けない：ブラウザーの拡張機能、個別プロキシ設定、セキュアDNS、キャッシュを確認します。
  • 一部のサイトだけ開けない：まず適用ルール、ノードの出口、接続先サイトの制限を確認します。
  • TUNを有効にしたときだけ通信できない：まずシステムプロキシで正常に通信できる状態を確認してから、ルーティングの取り込みを調べます。

手順1：システムプロキシが実際の待受ポートを参照しているか確認する

システムプロキシでよく使われるアドレスは127.0.0.1:7890ですが、7890に固定されているわけではありません。現在の実行設定にあるmixed-portを確認してください。このポートはHTTPとSOCKSの両方のプロキシ接続を受け付けます。external-controllerは制御用インターフェースなので、ブラウザーのプロキシポートには指定できません。

OSとブラウザーの設定を確認する

  • Windows 11：「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシのアドレスとポートを確認します。クライアントが自動構成スクリプトを使う場合は、実際に有効な設定を確認し、手動プロキシと古いスクリプトを併用しないようにします。
  • macOS：「システム設定」→「ネットワーク」→現在のネットワーク接続→「詳細」→「プロキシ」を開き、HTTP、HTTPS、SOCKSの設定がクライアントと一致しているか確認します。
  • Firefox：「設定」→「一般」→「ネットワーク設定」→「設定」を開き、システムプロキシを使用する設定になっているか確認します。手動設定の場合は、アドレスとポートも確認してください。
  • スマートフォンでは通常、ローカルVPNで通信を取り込みます。デスクトップのシステムプロキシ設定をそのまま適用せず、まずOSで現在有効になっているVPNプロファイルを確認してください。

ポートが実際に待ち受けているか確認する

以下のWindows PowerShellコマンドで、TCP 7890の待受状態とプロセスIDを確認できます。何も表示されない場合、そのポートではTCP接続を待ち受けていません。システムプロキシがコアに接続済みだと決めつけないでください。

Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

macOSまたはlsofをインストールしたLinuxでは、同じポートを次のように確認できます。

lsof -nP -iTCP:7890 -sTCP:LISTEN

設定をmixed-port: 7891に変更した場合は、システムプロキシ、コマンドラインのプロキシ、アプリ内の手動プロキシもすべて7891に変更します。ローカルで使う場合、ループバックアドレスで待ち受けるのは正常です。トラブルシューティングのためだけにLANからのアクセスを有効にする必要はありません。

手順2：明示的なプロキシ接続でブラウザーの問題を切り分ける

TUNを一時的にオフにしてコアは動作させたまま、コマンドでプロキシを明示して接続します。これにより、ブラウザーの拡張機能やシステムプロキシの選択処理を経由せずに確認できます。Windowsではcurl.exeを使い、一部のPowerShell環境でcurlが別のコマンドとして解釈されるのを避けます。macOSとLinuxではcurlを使います。

curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

ここでのexample.comは公開テスト用ドメインの例であり、固定の速度測定先ではありません。--noproxy ""は、環境内のプロキシ除外リストがテストに影響するのを防ぎます。明示的なプロキシを経由しない通信を調べる場合は、TUNをオフにして次を実行します。

curl.exe --noproxy "*" --connect-timeout 10 --max-time 20 -I https://example.com
結果の見方次に確認すること
127.0.0.1:7890に接続できない待受ポート、コアが終了していないか、クライアントが現在の設定を適用しているか確認します。
明示的なプロキシ接続は成功するが、ブラウザーでは失敗するシステムプロキシ、拡張機能、ブラウザー独自のプロキシ、セキュアDNSを確認します。新しいブラウザープロファイルでも再テストしてください。
407応答が返るローカルプロキシの認証設定と、リクエストで使用しているユーザー名・パスワードを確認します。
接続後にタイムアウトする、またはTLSエラーが発生する出口ノード、接続先への通信、システム時刻、証明書エラーの詳細を確認します。

HTTPSプロキシのログにある200 Connection establishedは、CONNECTトンネルが受け付けられたことだけを示します。その後のTLSハンドシェイクと接続先サーバーの応答も確認してください。接続先から403や405が返る場合、少なくともHTTP応答は受信できていますが、サイトの機能が使えるとは限りません。必要に応じて通常のGETリクエストでも確認してください。

手順3：モード、ルール、最終的な出口を確認する

クライアントの接続一覧を開き、問題が起きるWebページを再読み込みして、ドメイン名またはプロセス名で該当する接続を探します。ホーム画面で選択されているノード名だけでなく、適用ルール、ポリシーグループ、最終的なノードを確認してください。ルールによって、そのドメインの接続先がDIRECT、REJECT、または別のポリシーグループになることがあります。

  • rule：ルールを上から順に評価し、最初に一致した項目でポリシーが決まります。前方にあるドメインルール、ルールセット、末尾のMATCHを確認してください。
  • global：一時的な比較テストに使い、GLOBALポリシーで想定したノードが実際に選択されているか確認します。グローバルモードに切り替えても、ノードが利用可能になるとは限りません。
  • direct：コアに入った接続を直接接続として扱います。プロキシノードの疎通確認には使えません。

同じURLがグローバルモードでは開けて、ルールモードでは開けない場合、ルールモードで実際に使われた出口を確認してください。よくある原因は、サブスクリプションのルールで対象が直接接続になっていることや、入れ子のポリシーグループで利用できないノードが選択されたままになっていることです。変更後はruleに戻し、新しい接続が想定したポリシーに一致するか確認します。

接続一覧に記録がない場合

まず一覧にフィルターが適用されていないか、Webページがキャッシュから読み込まれていないか、コアのログにテスト時刻の記録があるか確認します。それでもリクエストが見つからない場合は、ルールを書き換える前に、アプリのプロキシ設定とTUNによる通信の取り込みを確認してください。ブラウザー独自のプロキシ、VPN、その他のネットワーク拡張機能を使っていると、リクエストが現在のコアに届いていないことがあります。

手順4：遅延の数値だけで判断せず、ノードを検証する

ノードに遅延が表示されるのは、クライアントが指定したチェック用リクエストに応答したことを示します。すべてのドメイン、UDP通信、IPv6経路、長時間接続での疎通を保証するものではありません。チェック先には接続できても、出口で対象サイトへのアクセスが制限されていれば、「遅延は正常なのにWebページが開かない」ことがあります。

  1. 同じURLを固定し、2つのノードでそれぞれテストします。ノードとサイトを同時に変更しないでください。
  2. サブスクリプションの有効期限、データ残量、ノード情報が更新されているか確認します。信頼できる既存のサブスクリプションURLからのみ更新し、オンライン診断サイトにURLを送信しないでください。
  3. ログに記録された具体的なエラーを確認します。例：ノードへの接続タイムアウト、認証失敗、TLSハンドシェイク失敗、ドメイン名の解決失敗。
  4. システムの日付と時刻を確認します。時刻のずれで証明書検証に失敗することがあります。証明書検証を無効にして問題を隠さないでください。

すべてのノードでサーバーへの接続時にタイムアウトする場合は、現在のネットワークで該当する通信ポートが制限されていないか確認します。スマートフォンのテザリングに切り替えるとネットワーク経路を比較できますが、原因を絞り込むための手段であり、ノード設定が正しい証明にはなりません。

手順5：システムDNS、コアのDNS、ブラウザーのセキュアDNSを切り分ける

DNSの問題では、まず「どのコンポーネントが名前を解決しているか」を確認します。システムのリゾルバー、mihomoのDNSモジュール、ブラウザーの暗号化DNSは、それぞれ異なる経路を使う場合があります。システムのnslookupが成功しても、コアのDNSが正常とは限りません。コアのDNSが正常でも、ブラウザーが同じDNS経路を使っているとは限りません。

まず状況を確認し、その後でnameserverを変更する

Windowsでは、まずシステムDNSの応答を確認できます。コマンドの出力には使用したサーバーと応答アドレスが表示されます。タイムアウトする場合は、そのDNSサーバーにネットワーク経由で到達できるか引き続き確認してください。

nslookup example.com

mihomoを使用していて、コアのDNSだけを個別に確認したい場合は、ポートが使用中でないことを確認してから、以下の設定を既存のdnsセクションに統合します。これは診断用の設定例であり、ノード、ポリシーグループ、ルールは含まれていません。単独では完全な設定として動作しません。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1

ここでの1.1.1.1は一般的なDNS上流サーバーの例です。アクセスできるかどうかは現在のネットワークによります。企業や学校のDNSを使う必要がある場合は、ネットワーク環境に適した設定を維持してください。パブリックDNSが万能な解決策とは限りません。設定を適用したら、digをインストールしたターミナルで指定ポートを問い合わせます。

dig @127.0.0.1 -p 1053 example.com A

fake-ipモードでは、設定範囲内のマッピングアドレスが返されるのは正常な場合があります。これはドメインと後続の接続を関連付けるためのもので、接続先サイトの実際のグローバルIPアドレスではありません。アプリがマッピングアドレスを取得しても、その後の接続がコアを経由しなければWebページを開けないことがあります。Fake-IPは実際の通信経路と併せて確認してください。

  • ノードサーバーにドメイン名を使用している：まずサーバーのドメイン名が解決できるか確認します。mihomoのproxy-server-nameserverでノードサーバーのドメイン名を解決する上流を指定すると、プロキシ確立前からそのプロキシに依存するループを防げます。
  • fallbackを使用している：fallback-filterと連携して、DNS応答の選択に使われます。あらゆる接続タイムアウトに対応する汎用の予備設定ではありません。
  • ブラウザーのセキュアDNSを使用している：一時的にシステムDNSへ切り替えて比較し、確認後に必要な設定へ戻します。ブラウザーとコアの複数の上流DNSを同時に変更しないでください。
  • 一部のサイトだけ読み込みが遅い：AレコードとAAAAレコード、IPv6の接続状況を比較します。まずcurl -4とcurl -6で確認し、IPv6を無効にすることを最初の解決策にしないでください。

WindowsではDNS設定の変更後にipconfig /flushdnsを実行してシステムDNSキャッシュを消去し、ブラウザーを再起動できます。すべてのブラウザーキャッシュやコアのFake-IPマッピングが消去されるわけではなく、到達できないDNS上流も修復できません。

手順6：システムプロキシの動作を確認してから、TUNとファイアウォールを調べる

明示的なHTTPプロキシのテストは成功し、TUNを有効にすると失敗する場合は、通信の取り込みを重点的に確認します。TUNは仮想ネットワークアダプター、ルーティング、実行権限に依存します。クライアントのスイッチが有効になっていても、ルートが正常に設定されたとは限りません。まず起動ログを確認し、権限不足、デバイスの作成失敗、ルートの競合がないか調べてください。

通信の取り込み範囲とDNSリダイレクトを確認する

mihomoのtun.auto-routeはルートの自動設定に使われ、tun.auto-detect-interfaceは出口インターフェースの判定を補助します。実際の対応状況は、使用中のコアとプラットフォームで確認してください。複数のネットワークアダプター、別のVPN、仮想マシンのネットワークがある場合、自動判定が想定どおりにならないことがあります。

tun.dns-hijackを使うと、該当する従来型DNSリクエストをコアのDNSに渡せます。よく使われる項目はany:53です。TCP 53も対象にする場合は、コアの対応状況に応じてtcp://any:53を設定します。ブラウザーからHTTPS 443で送信される暗号化DNSが自動的に取り込まれるわけではなく、利用可能な上流リゾルバーの代わりにもなりません。

  1. ほかのVPN、通信高速化ツール、二重起動しているプロキシクライアントを一時的に終了し、通信を取り込むプログラムを一つだけ起動します。
  2. クライアントが必要とするサービスがインストールされ、実行中か確認します。または説明に従って必要な権限で起動し、その後ログを確認してください。
  3. Windowsではroute print、Linuxではip routeでルートを確認し、実際の出口を特定します。システムルートをむやみに削除しないでください。
  4. ファイアウォールで、現在のコア実行ファイルの通信が許可されているか確認します。クライアントの更新でファイルのパスが変わると、古いルールが一致しなくなる場合があります。
  5. TUN使用時に大きなファイルや一部のHTTPSページだけ読み込みが止まる場合は、MTU、Path MTU Discovery、UDPの対応状況を確認します。根拠がないままネットワークスタックを何度も切り替えないでください。

設定を戻す前に：適用状況と再現性を確認する

クライアントには、サブスクリプションの元データ、オーバーライド設定、最終的な実行設定がそれぞれ存在する場合があります。YAMLファイルを編集しても、そのファイルがコアに読み込まれているとは限りません。まずクライアントで現在の設定ソースを確認し、実際に適用されたポート、DNS、TUNの設定を調べてください。

mihomoを単独で使用している場合は、設定ディレクトリで以下のWindowsコマンドを実行して構文を確認できます。このコマンドは、現在のディレクトリにmihomo.exeとconfig.yamlがあることを前提としています。GUIクライアントを使っている場合は、まずクライアントの設定チェック機能を使用してください。別のコアを起動してポートを競合させないようにします。

.\mihomo.exe -t -f .\config.yaml

構文チェックに成功しても、設定を読み込めることがわかるだけで、ノードやDNS、ネットワークへの到達性が保証されるわけではありません。修復後は次の順に確認してください。

  • 通常使用するルールモードに戻し、直接接続先とプロキシ接続先を一つずつ選んで、実際の出口を確認します。
  • ブラウザーを再起動し、以前開けなかったURLを再テストして、同じ時間帯の接続記録を確認します。
  • 一時的なデバッグログを通常のレベルに戻し、不要になったテスト用の待受ポートを削除します。
  • 最終的なポート、変更したフィールド、設定の適用方法を記録し、次回のサブスクリプション更新で修正が上書きされないようにします。

原因を特定できない場合は、クライアントとコアのバージョン、OSのバージョン、発生時刻、システムプロキシとTUNの状態、機密情報を伏せた1回分のリクエストログを共有してください。「接続済み」と表示されたスクリーンショットより、最小限で明確な再現手順のほうが問題の把握に役立ちます。基本的な設定は使い方ガイドを、各フィールドの意味はmihomoの上級設定を参照してください。