目次
プロキシアプリの「接続済み」という表示は、調査の出発点にすぎません。確認したいのは、直前にアクセスした接続先から結果が返ったかです。ページですぐにプロキシエラーが出る場合、ドメイン名を使うときだけ失敗する場合、仮想アダプターを有効にして端末全体が接続できなくなる場合では、調べる場所が異なります。具体的な症状を記録し、ルール、ノード、システム設定をまとめて変えないようにしましょう。
接続済み表示だけでは通信の成功は分からない
接続に失敗した対象、エラーの原文、現在のモードを記録してから、下の表で確認項目を選びます。コアが動いていてもプロキシポートが使えるとは限らず、ノードに接続できても DNS が正常とは限りません。それぞれを個別に確認してください。
以下のシステムプロキシ比較とポート確認は Windows/macOS 用です。Android では、スマートフォン向けの手順で VPN の許可とアプリ別設定を確認してください。接続記録がある場合は、後半の DNS、ルール、ノードの確認も参考になります。
症状ごとに最初に確認する箇所
| 症状 | 最初に確認する項目 |
|---|---|
| すべてのサイトですぐにプロキシ接続エラーが出る | システムプロキシに設定されたローカルアドレスとポート |
| ドメインでは開けないが、IP へ直接アクセスすると応答がある | DNS とブラウザのセキュア DNS |
| 国内サイトは正常だが、プロキシが必要なサイトはタイムアウトする | ノード、ポリシーグループ、一致したルール |
| システムプロキシは正常だが、TUN を有効にするとすべて切断される | サービス、仮想ネットワークアダプター、デフォルトルート、他の VPN |
| 特定のアプリだけが失敗する | そのプロセスが Clash に入っているか、アプリ自身のステータスコードは何か |
システムプロキシ、TUN、直接接続の比較
TUN を無効にし、Rule モードとシステムプロキシだけを残して、同じウェブページを開き直します。システムプロキシは使えるのに TUN では切断される場合、サブスクリプションとノードには少なくとも一つの基本経路があるため、サービス、ルート、DNS を重点的に確認します。どちらのモードでも失敗するなら、仮想ネットワークアダプターにはまだ手を加えません。
直接接続のテストでは、今のネットワークで普段は開けるページを使い、プロキシが必要な宛先は使い続けないでください。システムプロキシを無効にしてもそのページが開けない場合は、Wi-Fi、回線、企業ネットワークの認証、ルーターを確認します。Clash は元からインターネットにつながらないネットワークを修復できません。
Web リクエストは接続ページに表示される?
接続記録を消去し、固定した一つのドメインへアクセスします。新しいリクエストがまったく現れない場合は、ブラウザがシステムプロキシを使用していない、ポートが誤っている、またはアプリが現在の取り込み方式を迂回している可能性があります。ルールやノードを変更し続けても、この状態は変わりません。
リクエストが表示されたら、宛先、一致したルール、グループ、エラーを記録します。意図しない 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 を無効にすると結果が変わる場合は、名前解決の経路を確認します。比較のためブラウザーの DoH を一時的に無効にし、OS と Clash が実際に使う経路と、nameserver に到達できるかを調べてください。一つのスイッチを無効にしても、両者の名前解決の設定が自動的にそろうわけではありません。
復旧後、ブラウザー独自の名前解決を再び有効にするか判断します。ルーターとブラウザーが別々に名前解決を行うと、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 との競合
対処方法:システムプロキシへ戻して一項目ずつ確認し、コンピューター全体のネットワークはリセットしません。
