クライアントに「接続済み」と表示され、ノードの横に遅延時間が出ていても、確認できるのはClashコアが起動していること、またはテストリクエストに応答したことだけです。ブラウザーでWebページを開けるかどうかは、アプリの通信がリッスンポートに入っているか、ルールが正しい出口を選んでいるか、DNSが利用可能な結果を返すか、選択したノードで実際のTLS接続を確立できるかにも左右されます。切り分けでは複数のスイッチを続けて切り替えず、通信の入口から順番に確認してください。
ステップ1：ネットワーク障害とプロキシ経路の障害を切り分ける
まずClashを完全に終了します。ウィンドウを閉じるだけでは不十分です。システムプロキシがオフに戻っていることを確認し、ローカルネットワークと通常のWebサイトにアクセスします。直結でもページを開けない場合、原因はWi-Fi、LANケーブル、ルーター、認証ポータル、通信事業者の接続にある可能性が高いため、Clashの設定を変更し続けないでください。
3つの基本テストを実行する
- ルーターの管理アドレス（例：
192.168.1.1）を開きます。開ければ、端末からLANゲートウェイまでの経路は正常です。 - ターミナルで
ping 1.1.1.1を実行します。ネットワークによってはICMPが破棄されるため、タイムアウトだけで切断とは判断できません。ただし、継続的に応答が返れば、基本的なIP経路が利用可能だと確認できます。 nslookup example.comを実行します。IPアドレスには到達できるのに名前解決がタイムアウトする場合は、まずシステムDNSまたはルーターのDNSを確認してください。
ホテル、空港、学校などのネットワークでは、Webページ上で認証が必要なことがあります。このようなネットワークに接続したら、一時的にプロキシをオフにして通常のHTTPページへアクセスし、認証ポータルを表示します。認証完了後にClashを起動してください。認証前でもノードの遅延時間だけは表示されることがありますが、その後のHTTPSリクエストはゲートウェイに遮断されます。
ステップ2：システムプロキシがClashのポートを指していることを確認する
「システムプロキシ」は、OSのプロキシ設定に従うブラウザーやアプリの通信をClashへ送ります。コアが動作していてもシステムプロキシがオフなら、ログにブラウザーからの新しい接続は通常現れず、Webページは直結のままです。Clash Verge Rev 2.xでは「設定」→「システム設定」→「システムプロキシ」を確認します。旧版のClash for Windows 0.20.39では、メイン画面の System Proxy を確認してください。クライアントによって表示は多少異なりますが、最終的にはローカルループバックアドレスと実際のリッスンポートが設定されている必要があります。
リッスンアドレスとポートを照合する
一般的な設定では mixed-port: 7890 を使い、HTTPとSOCKS5の両方を受け付けます。port: 7890 と socks-port: 7891 を個別に設定する場合もあります。これらはよくある値にすぎないため、現在の設定とクライアントの設定画面に表示されるポートを基準にしてください。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: infomacOS 15では「システム設定」→「ネットワーク」→現在のネットワークインターフェース→「詳細」→「プロキシ」で、Webプロキシと保護されたWebプロキシを確認できます。サーバーは通常 127.0.0.1、ポートはClashのHTTPポートまたは混合ポートと一致している必要があります。Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」で手動プロキシを確認します。ここに、すでに終了した別のクライアントのポートが残っていると、ブラウザーのリクエストは直接失敗します。
ブラウザーを介さずローカルプロキシをテストする
混合ポートが 7890 だと仮定し、macOSまたはLinuxのターミナルで次を実行します：
curl -I -x http://127.0.0.1:7890 https://cp.cloudflare.com/generate_204
curl -I --socks5-hostname 127.0.0.1:7890 https://example.comWindows PowerShellでは、コマンドエイリアスによる引数の違いを避けるため、curl.exe を明示的に呼び出します：
curl.exe -I -x http://127.0.0.1:7890 https://cp.cloudflare.com/generate_204127.0.0.1 への接続が直ちに拒否された場合、ポートがリッスンされていない、ポート番号が間違っている、またはコアが停止しています。リクエストがログに入ってからタイムアウトする場合は、ローカルの入口は正常です。ノード、DNS、ルールの確認に進んでください。
ステップ3：ポート競合とコアの起動異常を除外する
複数のプロキシクライアントを同時に起動したとき、最もよくある競合は、すべてが 7890 のリッスンを試みるケースです。画面上のプロセスは正常に見えても、コアのログには address already in use、bind failed、またはリッスン失敗のメッセージが現れます。この場合、システムプロキシが 127.0.0.1:7890 を指していても、そのポートは別のプログラムが使用している可能性があります。
ポートの使用元を確認する
macOSとLinuxでは次を実行します：
lsof -nP -iTCP:7890 -sTCP:LISTEN
lsof -nP -iTCP:9090 -sTCP:LISTENWindowsではPowerShellで次を実行します：
Get-NetTCPConnection -State Listen -LocalPort 7890
Get-Process -Id (Get-NetTCPConnection -State Listen -LocalPort 7890).OwningProcess7890 は通常プロキシの入口で、9090 は外部コントロールインターフェースに使われます。用途は異なるため、システムプロキシにコントロールポートを入力しないでください。競合を確認したら、古いプロセスを終了するか、現在の設定の混合ポートを 7897 などに変更し、システムプロキシも同じ値に更新します。YAMLだけ変更してOS側のプロキシを更新しないと、別のポート不一致が起きます。
ステップ4：ノードが実際のWebリクエストを処理できるか確認する
遅延テストは、完全な利用可能性を意味しません。クライアントはテストURLに小さなHTTPリクエストを1回送るだけかもしれませんが、Webページの読み込みではDNS、TLS 1.3、HTTP/2、複数ドメイン、継続的なデータ転送が発生します。ノードに 82 ms と表示されても、高いパケットロス、出口回線の混雑、証明書ハンドシェイクの中断、対象サイトによる制限が残っている可能性があります。
出口を順番に切り替える
- プロキシモードを一時的に「グローバル」にし、明確なノードを1つ選びます。自動選択のプロキシグループは使わないでください。
https://cp.cloudflare.com/generate_204にアクセスします。正常時の結果は通常HTTP204です。- さらに、異なる通信事業者のWebサイトを2つ開きます。1つのサイトがメンテナンス中であることによる誤判定を避けられます。
- 別の地域または別回線のノードに切り替えてテストを繰り返します。1つのノードだけ失敗するなら、まずノード側の問題を疑ってください。
すべてのノードが接続段階でタイムアウトする場合は、サブスクリプションの期限、ノードのドメイン解決、端末の時刻、現在のネットワークによるプロトコル制限を確認します。システム時刻が数分ずれるだけでも、TLS証明書の検証に失敗することがあります。macOSでは「システム設定」→「一般」→「日付と時刻」で自動設定を有効にします。Windows 11では「設定」→「時刻と言語」→「日付と時刻」から今すぐ同期を実行してください。
ログの connection refused は通常、リモートポートが接続を拒否したことを示します。i/o timeout は経路のタイムアウトに近く、TLS handshake timeout はTCP接続後の暗号化ハンドシェイクが時間内に完了しなかったことを示します。3種類のメッセージは障害の層が異なるため、すべてをクライアントの問題と一括りにしないでください。
ステップ5：ルールの判定結果とプロキシグループの選択を確認する
ルールモードでは、リクエストがClashに入った後でも DIRECT、REJECT、または誤ったプロキシグループに割り当てられることがあります。よくある症状は、日本国内のWebページは正常なのに特定の海外サイトだけ失敗する、またはトップページは開くのに画像、ログインAPI、認証コードが読み込めないというものです。Webページは複数のドメインに依存することが多いため、アドレスバーのドメインだけではルール全体を確認できません。
接続履歴で実際の出口を特定する
クライアントの「接続」または Connections ページを開き、対象ページを更新します。ドメインに対応するルール、ルールの動作、プロキシチェーンを確認してください。mihomoコアでは通常、ヒットしたルール種別と最終経路が次のように記録されます：
example.com
Rule: DomainSuffix
Payload: example.com
Chains: Proxy Group → Singapore 01対象リクエストが MATCH → DIRECT に一致する場合、前のルールではそのドメインをカバーできていません。プロキシグループに一致していても、そのグループで現在選ばれているノードが無効なら、グループ内で別のノードを選び直します。REJECT に一致した場合は、広告ブロックやプライバシー用のルールセットかどうかを確認してから、ルールグループ全体を削除してください。
一時的にグローバルモードへ切り替えて正常に戻るなら、原因はほぼルールまたはプロキシグループに絞れます。修正時は、グローバルモードを常用するのではなく、正確な DOMAIN、DOMAIN-SUFFIX、または適切なルールセットを追加します。例：
rules:
- DOMAIN,api.example.com,PROXY
- DOMAIN-SUFFIX,example.com,PROXY
- MATCH,DIRECTルールは上から順番に照合され、通常は最初に一致した時点で処理が止まります。範囲の広い DOMAIN-SUFFIX や GEOIP ルールを不適切な位置に置くと、後続の精密なルールを先に処理してしまうことがあります。変更後はProfileを再読み込みし、接続履歴で新しいルールが実際に適用されたことを確認してください。
ステップ6：DNS汚染、Fake-IP、IPv6の問題を特定する
IPアドレスにはアクセスできるのにドメインが開けない、またはブラウザーが「ホストを解決しています」のまま長時間進まない場合は、DNSを確認します。Clash Meta、つまりmihomoでは、一般に fake-ip または redir-host の拡張モードを使います。Fake-IPは予約済みアドレス帯からマッピング用アドレスを返し、コアが元のドメインに戻します。アプリの通信がClashを経由していないのにClashのFake-IPを使うと、実際の宛先へ到達できないことがあります。
システムDNSとプロキシ経由DNSを比較する
nslookup example.com
dig example.com
curl -v -x http://127.0.0.1:7890 https://example.comnslookup が 198.18.0.0/16 の範囲のアドレスを返す場合、通常はFake-IPのマッピングであり、実際のインターネット上のアドレスではありません。この場合、システムプロキシまたはTUNがまだ動作しているかを確認します。Clashを終了する前にシステムプロキシをオフにし、クライアントが管理しているDNS設定を解除してください。停止したローカルDNSポートへ問い合わせが送られ続けるのを防げます。
mihomoの設定では、上流DNSのドメイン名を処理する独立したデフォルトリゾルバーを指定し、暗号化DNSによって従来のUDP問い合わせが妨害される可能性を下げられます。設定例は次のとおりです。使用するサーバーはネットワーク環境に合わせてテストしてください：
dns:
enable: true
listen: 127.0.0.1:1053
enhanced-mode: fake-ip
default-nameserver:
- 223.5.5.5
- 1.1.1.1
nameserver:
- https://dns.alidns.com/dns-query
- https://1.1.1.1/dns-query問題がIPv6対応サイトの一部だけで発生する場合は、切り分けのため設定のIPv6機能を一時的に無効にします。端末がIPv6アドレスを取得していても、出口経路が不安定だと、アプリが利用できないAAAAレコードを優先し、タイムアウト後にIPv4へフォールバックすることがあります。原因を確認したら、すべてのタイムアウトをDNS汚染と決めつけず、ルーターまたは上流のIPv6経路を修正してください。
ステップ7：TUNモードを有効にしてもインターネットに繋がらない場合
TUNモードは仮想ネットワークインターフェースを作成し、システムプロキシに従わないアプリや一部のUDP通信をカバーします。動作にはシステムサービス、管理者権限、ルーティングテーブル、DNSハイジャックの連携が必要です。画面上のスイッチがオンでも、仮想インターフェースとルートが正常に作成されたとは限りません。
まずTUN固有の障害かどうかを判断する
- TUNだけをオフにし、システムプロキシのみを有効にします。
- ブラウザーでテストページを開き、接続履歴を確認します。
- システムプロキシでは通信できるのにTUNを有効にすると全体が切断される場合は、サービスのインストール、仮想ネットワークアダプター、ルート競合、ファイアウォールを重点的に確認します。
- 両方のモードで失敗するなら、ポート、ノード、DNSの手順に戻り、TUNサービスの再インストールを繰り返さないでください。
Clash Verge Revなどのクライアントでは、「設定」→「サービスモード」または「設定」→「システム設定」でサービスの状態を確認できます。クライアントのアップグレード後にサービスのバージョンと画面プログラムが一致しない場合は、サービスを停止してから、クライアントのサービス管理画面から再インストールします。Windowsでは「デバイス マネージャー」→「ネットワーク アダプター」で仮想アダプターの状態も確認し、他のVPN、仮想マシンのネットワーク、セキュリティソフトが同時にルートを変更していないか確認してください。
macOSでは route -n get default でデフォルトルートを、ifconfig で仮想インターフェースの存在を確認できます。Windowsでは route print と Get-NetAdapter を実行します。クライアント終了後も仮想ルートが残る場合は、関連サービスまたはOSを再起動してから次のテストを行います。対象ネットワークを把握しないままルートを一括削除しないでください。
最後の確認：ログの結果で分類し、すぐに再インストールしない
クライアントを再インストールしても、無効なノード、誤ったサブスクリプションルール、システムに残ったプロキシ設定、上流DNSを自動で修復することはできません。ここまでの段階的なテストを終えれば、障害の範囲を明確に絞り込めるはずです。次の一覧を最終確認に利用してください。
| 確認結果 | 主な範囲 | 次の対応 |
|---|---|---|
| Clash終了後も直結できない | ローカルネットワークまたはOSのネットワーク設定 | ゲートウェイ、認証ポータル、システムDNS、ルーターを確認する |
| 127.0.0.1:7890へのアクセスが拒否される | コアまたはリッスンポート | ポート、コアのログ、ポートを使用しているプロセスを確認する |
| プロキシリクエストがログに入った後でタイムアウトする | ノードまたは上流経路 | プロトコル、地域、回線の異なるノードへ切り替える |
| グローバルモードは正常だが、ルールモードで失敗する | ルールとプロキシグループ | Connectionsでヒットしたルールと最終経路を確認する |
| IPにはアクセスできるが、ドメインの名前解決に失敗する | DNS | ローカルDNSのリッスン、Fake-IP、上流リゾルバーを確認する |
| システムプロキシは正常だが、TUNモードで通信できない | サービス、仮想インターフェース、またはルート | サービス権限、アダプターの状態、ルート競合を確認する |
最も効果的な切り分け順は、直結ネットワークの確認、ローカルプロキシポートの検証、ノード・ルール・DNSの確認、最後にTUNの確認です。各段階でターミナルの結果とクライアントの接続ログを同時に確認してください。リクエストがどの層で消えているかを特定できれば、目的なくノードを切り替えたり、設定をリセットしたり、クライアントを何度も再インストールしたりせずに済みます。