目次
Clash に接続済みと表示されてもインターネットを使えない場合は、まず失敗の種類を特定する
「Clash に接続済み」という同じ表示でも、コアプロセスが動作しているだけかもしれず、システムプロキシのポート、ノードへの到達性、DNS の正常性までは証明できません。具体的なエラーを一つ、接続先アドレスを一つ、現在のモードを記録して、調査の起点を作ります。
症状ごとに最初に確認する箇所
| 症状 | 最初に確認する項目 |
|---|---|
| すべてのサイトですぐにプロキシ接続エラーが出る | システムプロキシに設定されたローカルアドレスとポート |
| ドメインでは開けないが、IP へ直接アクセスすると応答がある | DNS とブラウザのセキュア DNS |
| 国内サイトは正常だが、プロキシが必要なサイトはタイムアウトする | ノード、ポリシーグループ、一致したルール |
| システムプロキシは正常だが、TUN を有効にするとすべて切断される | サービス、仮想ネットワークアダプター、デフォルトルート、他の VPN |
| 特定のアプリだけが失敗する | そのプロセスが Clash に入っているか、アプリ自身のステータスコードは何か |
二つのスイッチで障害範囲を先に切り分ける
TUN を無効にし、Rule モードとシステムプロキシだけを残して、同じウェブページを開き直します。システムプロキシは使えるのに TUN では切断される場合、サブスクリプションとノードには少なくとも一つの基本経路があるため、サービス、ルート、DNS を重点的に確認します。どちらのモードでも失敗するなら、仮想ネットワークアダプターにはまだ手を加えません。
次にシステムプロキシを無効にして直接接続へ戻し、通常のネットワーク自体が使えることを確認します。直接接続でも失敗する場合は、Wi-Fi、ブロードバンド、企業認証、ルーターの問題を先に修正してください。Clash は、元から外部ネットワークへ接続できない下位レイヤーを修復できません。
今回のリクエストが接続ページにあるかどうかが、最も重要な分岐点
接続記録を消去し、固定した一つのドメインへアクセスします。新しいリクエストがまったく現れない場合は、ブラウザがシステムプロキシを使用していない、ポートが誤っている、またはアプリが現在の取り込み方式を迂回している可能性があります。ルールやノードを変更し続けても、この状態は変わりません。
リクエストが現れた場合は、接続先、一致したルール、ポリシーグループ、エラーを記録します。想定外の DIRECT、REJECT、timeout、connection refused は、それぞれ異なる層を示します。トレイアイコンの色だけを見ると、原因を最もよく示す証拠を失います。
一回の最小再現
設定とノードを固定する
自動切り替えを一時的に無効にし、出口を一つだけ残します。
接続ビューとログビューを消去する
バックグラウンド更新を、直前のウェブリクエストと取り違えないようにします。
同じ HTTPS アドレスへアクセスする
Clash に入ったか、一致したルール、発生したエラーを記録します。
変数を一つだけ変更して再試行する
ノード、ルール、DNS、TUN を同時に変更しないでください。
すぐにエラーになる場合は、システムプロキシとリッスンポートを確認する
ブラウザを開いた直後にプロキシサーバーへ接続できないと表示される場合、Windows または macOS が 127.0.0.1 の古いポートを参照し、現在のクライアントがそのポートで待ち受けていない可能性があります。クライアントの設定から実際の mixed-port を確認し、netstat、lsof、ss で検証してください。
ポートが存在する場合は curl -x で明示的にリクエストし、ローカルプロキシの入口とシステムプロキシの設定を切り分けられます。明示したプロキシでは成功し、ブラウザでは失敗する場合、問題は OS またはブラウザの設定にあります。明示したプロキシでも失敗する場合に、コア、ノード、ログを見直します。
# 将 7890 换成客户端实际端口
curl -I -x http://127.0.0.1:7890 https://example.com
# Windows
netstat -ano | findstr :7890
# macOS / Linux
lsof -nP -iTCP:7890 -sTCP:LISTEN名前解決だけに異常がある場合に、DNS の調査へ進む
ドメインリクエストに長時間接続先アドレスがない、nslookup が失敗する、またはブラウザのセキュア DNS を無効にすると症状が変わる場合に限り、DNS を優先して確認します。まずブラウザ、システム、Clash の名前解決入口を一つに統一し、その後 nameserver へ到達できるかを確認してください。
システムがルーターの DNS を使い、ブラウザでは別にセキュア DNS を有効にしていると、Clash が完全なドメイン名を取得できない場合があります。トラブルシューティング中はブラウザの DoH を一時的に無効にし、同じドメインがシステムから Clash まで一つの名前解決経路だけを通るようにしてください。復旧後に再び有効にするかを決めます。
Fake-IP 使用時は、正常な仮想アドレスと古いキャッシュを先に区別する
Fake-IP モードでドメインが 198.18.0.0/15 のようなアドレスへ名前解決されるのは、通常の動作です。アプリが最初にこの仮想アドレスへ接続し、その後 Mihomo がドメインへ戻してルールと照合します。198.18.x.x が見えるだけで DNS 汚染とは判断できません。接続ページに元のドメインが残り、想定したポリシーへ一致するかが重要です。
実際に対処が必要なのは、設定やルールを変更した後、または Redir-Host から Fake-IP へ変更した後も、システムとアプリが古い結果を保持している状態です。この場合はテスト用アプリを閉じ、システムの DNS キャッシュを消去し、Mihomo コアを再起動してから再テストしてください。古い接続を残したまま拡張モードを何度も切り替えないでください。
NAS、プリンター、ルーター管理画面、社内ドメインで実際の内部アドレスを返す必要がある場合は、現在の設定の fake-ip-filter へ追加するか、対応する社内 DNS へ渡します。これらのローカルドメインが引き続き実際の LAN アドレスへ名前解決され、公開ドメインは接続ページでドメイン名に戻って正しく振り分けられることを確認してください。
ipconfig /flushdnsリクエストが入った後で、ルール、ノード、TUN の問題を分けて対処する
リクエストが DIRECT に一致した後でタイムアウトする
主な原因：具体的なルールより先に、広い直接接続ルールへ一致している
対処方法：最終的なルール順を確認し、正確なルールを GEOIP と MATCH より前に置きます。
プロキシグループへ一致するが dial timeout になる
主な原因：現在のノード、プロトコル、リモートの接続先へ到達できない
対処方法：DNS を変更する前に、既知の別の利用可能なノードを固定して比較します。
ローカルプロキシで connection refused になる
主な原因：ポートが待ち受けていないか、システムプロキシの設定が誤っている
対処方法：mixed-port、プロセスの状態、ポートの競合を確認します。
TUN の場合だけすべて切断される
主な原因：サービス権限、デフォルトルート、仮想ネットワークアダプター、他の VPN との競合
対処方法：システムプロキシへ戻して一項目ずつ確認し、コンピューター全体のネットワークはリセットしません。
最終的には「リクエストは Clash に入り、PROXY に一致し、固定ノードが dial timeout を返した」のように、障害を具体的な一文で説明できる必要があります。「アプリは緑なのにインターネットへ接続できない」では不十分です。この一文には、次に対処すべき層がすでに含まれています。