まず状況を記録する：ログの時刻、接続先、実際に使われているコア

Clashで「接続済み」と表示されても、通常はコアが動作中、またはローカルプロキシの入口が有効であることを示すだけで、すべてのサイトへの接続を保証するものではありません。原因を調べるときは、アプリがプロキシに接続しているか、ドメインを解決できているか、どのルールとポリシーが選ばれたか、ノードに接続できたか、接続先から応答があったかを順に確認します。

Clash、Clash Meta（現在は一般にmihomoコアとしてメンテナンスされています）、各種GUIクライアントでは、ログの形式が完全には統一されていません。以下は項目やエラー表示の例であり、特定バージョンの出力をそのまま再現したものではありません。まずクライアントの「バージョン情報」またはコア情報で、コア名とバージョンを記録してください。外側のクライアントのバージョンだけで判断せず、該当するコアの設定ドキュメントに沿って確認しましょう。

  1. 再現時刻を記録：14:32:10のように秒単位で記録します。ログ表示を消去する前に、重要なエラーを保存してください。
  2. リクエストを絞る：ダウンロードやバックグラウンド更新を一時停止し、問題のあるURLだけを開きます。多数の接続が同時に発生して、ログが混ざるのを防げます。
  3. 利用環境を記録：OS、クライアントとコアのバージョン、ルールモードまたはグローバルモード、システムプロキシとTUNの状態、現在のプロキシグループとノードを記録します。
  4. 変更は一度に1項目：変更のたびに新しいリクエストを送り、同じ接続先で結果を比較します。DNS、ノード、ルールを同時に変更しないでください。

ログレベルの設定：普段はinfo、再現時のみ一時的にdebug

クライアントのサイドバーにある「ログ」または「実行ログ」で出力を確認します。ログレベルの設定場所や名称はクライアントによって異なり、「設定」や「コア設定」にある場合があります。画面上のログフィルターは、コアの出力レベルを変更する設定とは限りません。「デバッグ」で絞り込んでも、コアが生成していないログは表示できません。

Clashとmihomoでは、通常、トップレベルの設定項目 log-level に silent、error、warning、info、debug を指定します。以下は現在の設定に追加して使う設定例で、単独で使えるサブスクリプションではありません。

# トップレベルの項目。mode、rulesと同じ階層
log-level: debug

保存後、クライアントの案内に従って設定を再読み込みするか、コアを再起動し、新しい設定が反映されたことを確認します。サブスクリプションの更新で直接編集した内容が上書きされる場合があります。クライアントがオーバーライドや設定のマージに対応している場合は、そちらを優先してください。再現確認が終わったら info に戻し、大量のデバッグログを出し続けないようにしましょう。

接続ログの読み方：接続先、ルール、出力先の順に確認

1件のログには、送信元アドレス、接続先ドメイン、適用ルール、プロキシグループ、最終的なノード、エラーの原因が同時に表示される場合があります。読む順序が重要です。エラーの直前にある DIRECT やプロキシノード名を確認すると、次に調べるべき経路がわかります。

# 項目の例。ログ形式は固定ではありません
[TCP] 127.0.0.1:53124 --> example.com:443
match DomainSuffix(example.com)
using Proxy[ノード A]
error: dial tcp 203.0.113.10:443: i/o timeout

ここでの 53124 は、アプリが今回の接続で使った一時的な送信元ポートです。システムプロキシの待ち受けポートに設定する値ではありません。example.com:443 は接続先、Proxy はポリシー名です。例にある文書用予約アドレス 203.0.113.10 は説明専用で、接続テストには使用できません。

ログから読み取れる手がかりまず確認すること対応する設定・画面
新しい接続ログがまったくないリクエストがローカルプロキシに届いているかシステムプロキシ、mixed-port、TUN、アプリの設定
接続先ドメインの名前解決に失敗どの名前解決処理で失敗したかdns、ノードのドメイン解決、システムリゾルバー
DIRECTが適用されている想定どおりの振り分けかmode、rules、ルールセット
プロキシ経由の接続がタイムアウトノードへの接続か、最終的な接続先への接続かproxies、proxy-groups、ノード側の稼働状況
待ち受けポートの起動に失敗ポートがすでに使用されていないかmixed-port、port、socks-port、コントロールポート

dial timeout：ノードへの接続と接続先への接続を切り分ける

dial timeout、i/o timeout、context deadline exceeded は、いずれも処理が制限時間内に完了しなかったことを示します。ただし、「タイムアウト」という表示だけでDNSの問題とは判断できません。同じ行のアドレスと前後のログを確認してください。失敗したアドレスがノードサーバーなら、まず端末からノードまでの経路を調べます。接続先への直接接続なら、直結経路とルールによる振り分けが正しいか確認します。

4つの手順で原因を絞り込む

  1. プロキシグループで別のノードを手動選択し、同じリクエストを再試行します。別のノードで成功した場合、元のノードまたはその経路に原因がある可能性が高まりますが、プロトコル自体の問題とは限りません。
  2. 別のWebサイトにも接続してみます。特定の接続先だけ失敗する場合は、サイトの稼働状況、出口の地域制限、ノードから接続先までの経路を確認してください。
  3. ノードはそのままにして、Wi-Fiからスマートフォンのテザリングへ切り替えるなど、ネットワークを変更してみます。結果が変わる場合は、ローカルネットワーク、ファイアウォール、または通信事業者の経路を重点的に確認します。
  4. ノード設定にあるサーバーアドレス、ポート、プロトコルのパラメーターを確認します。サブスクリプションの期限切れやサーバー側のポート変更でも接続に失敗することがあります。変更する前にサブスクリプションを更新し、アカウントの状態を確認してください。

遅延テストの成功が示すのは、その時点でテスト対象への所定の確認が完了したことだけです。ストリーミング、ファイルのダウンロード、UDP通信も利用できるとは限りません。テスト結果が80 msだからといって、Webページが必ず80 ms以内に読み込まれるわけではありません。

connection refusedはtimeoutとは異なる

connection refused は通常、接続先から明示的な拒否が返されたことを示します。たとえば、接続先ポートでサービスが待ち受けていない場合や、ファイアウォールが拒否応答を返した場合です。アドレスが 127.0.0.1:7890 なら、まずローカルプロキシがそのポートで待ち受けているか確認します。ノードサーバーのアドレスなら、ノードのポートとサービスの状態を確認してください。タイムアウト時間をむやみに延ばしても、ポートへの拒否は解決しません。

DNS解決失敗：接続先ドメイン、ノードのドメイン、上流DNSを切り分ける

no such host、lookup ... failed、DNS query timeout などは名前解決の問題を示しますが、どの名前の解決に失敗したかを確認する必要があります。接続先のドメインだけでなく、プロキシサーバーをドメイン名で指定している場合はその名前も解決が必要です。また、暗号化DNSの上流をドメイン名で設定している場合、上流DNS自体のアドレスをどう解決するかも関係します。

Windowsではまず nslookup example.com を実行します。macOSまたはLinuxでは、対応するツールをインストールしたうえで dig example.com を実行できます。これらのコマンドが確認するのは通常、システムが使用する名前解決経路であり、Clash内蔵DNSを経由するとは限りません。システムでの解決とコアでの解決は、それぞれ個別に検証してください。

Fake-IPアドレスだけではDNSエラーとは判断できない

Fake-IPモードでは、アプリに合成アドレスが返ることがありますが、これは正常な動作の場合があります。よく使われる設定では 198.18.0.0/16 の範囲が利用されます。これは実際のWebサイトのグローバルIPアドレスとは異なります。このアドレスが表示されただけでノードを切り替えるのではなく、その後の接続がコアに届き、ドメインとの対応関係が復元されているか確認してください。

DNSモードの切り替え後に問題が発生した場合は、まずアプリの接続を再確立し、必要に応じてシステムのDNSキャッシュを消去します。すぐにすべてのドメインを fake-ip-filter に追加せず、実際に互換性の問題があるドメインを1つ使って検証してから、必要最小限の変更を行ってください。項目の説明はDNS設定リファレンスとFake-IPの解説を参照してください。

ルール未一致：モード、順序、ドメイン情報を確認

想定したノードを経由しない場合でも、必ずしもエラーログが出るとは限りません。上位にあるDIRECTルールが正常に適用されている可能性もあれば、グローバルモードになっていて、想定したルール一覧による振り分け自体が行われていない可能性もあります。まず動作モードを確認し、接続ログに表示された実際のルールとポリシーを調べてください。

# 振り分け設定の例。Proxyは設定済みのポリシー名である必要があります
mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

ルールは上から順に照合され、一致した時点で処理が終了します。MATCH,DIRECT を先頭に置くと、それより下のドメインルールは適用されません。例の Proxy は予約済みの組み込み名ではありません。設定済みのプロキシまたはプロキシグループの名前と完全に一致させる必要があります。

  1. ルールモードを確認：グローバルモードでは通常、グローバルポリシーで出力先が決まり、ダイレクトモードでは想定しているプロキシポリシーを経由しません。モードの説明はプロキシモードの設定を参照してください。
  2. 使用中の設定を確認：編集しているのが現在使用中の設定か確認します。サブスクリプション更新後もカスタムルールが保持されているか確認してください。
  3. ルールセットの状態を確認：RULE-SET を使っている場合は、対応するプロバイダーの読み込みに成功しているか、名前と内容の形式が定義と一致しているかを確認してください。
  4. ドメイン情報を確認：アプリがIPアドレスに直接接続している場合、ドメインルールに一致しないことがあります。スニッフィングでドメイン情報を補える場合もありますが、すべての接続でドメインを復元できるわけではありません。
  5. 接続を再確立：既存の長時間接続では、以前の出力先が使われ続けることがあります。対象のページやアプリの接続をいったん閉じてからテストし、古い接続の結果を新しいルールの結果と取り違えないようにしてください。

起動・権限エラー：ポート競合、設定ミス、TUN

address already in use：まずポートを使用中のプロセスを特定

コアの起動時に bind: address already in use と表示された場合は、使用中のポートがプロキシ用、DNS待ち受け用、コントロールインターフェース用のどれか確認します。以下では 7890 を例にしています。実際のポートは現在の設定で確認してください。クライアントによって既定値が異なる場合があります。

# Windows：待ち受けポートとプロセスIDを確認
netstat -ano | findstr :7890

# macOS：TCPの待ち受けプロセスを確認
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux：TCPの待ち受けソケットを確認
ss -ltnp 'sport = :7890'

プロセスを特定したら、重複して起動しているクライアントを終了するか、ローカルの待ち受けポートを変更します。mixed-port を 7890 から 7891 に変更した場合は、システムプロキシやアプリ内プロキシの設定も更新してください。プロセスIDが表示されても、正体のわからないシステムサービスを終了しないでください。

YAML構文とポリシー参照のエラー：まず設定を読み込める状態にする

yaml: line ... は、構文や構造に問題があることを示す場合が多いエラーです。インデントにはスペースを使い、Tabは使わないでください。特殊文字を含む値はYAMLの規則に従って引用符で囲みます。表示された行はパーサーが処理を続けられなくなった位置であり、実際の誤りが直前の行にある場合もあります。存在しないポリシーや誤ったルールセット名は設定参照の問題で、ネットワークを再起動しても解決しません。

TUN permission denied：システム権限とトラフィックの対象範囲を確認

TUNの作成に失敗する原因には、管理者権限、クライアントのサービスモード、OSのVPN許可などがあります。Windowsではサービスと管理者権限での実行状態を確認し、AndroidではVPN接続の許可を確認してください。具体的な手順はクライアントの説明に従います。TUNを有効にしても、すべての通信が自動的にプロキシへ送られるわけではありません。ルーティング、除外設定、既存のVPNが通信の取り込み結果に影響します。

通常の明示的なプロキシ接続は使えるのにTUNが使えない場合は、同じノードと設定を保ち、通信の取り込み方式だけを切り替えて比較します。これにより、サブスクリプションやノードを同時に疑うことなく、仮想インターフェース、ルーティング、DNSの取り込みに原因を絞れます。

修正を検証する：同じリクエストで変更前後を比較

ログが減っただけでは、問題が解消したとは限りません。修正後は、同じ接続先、同じネットワーク、同じノードで再テストし、リクエストが想定したポリシーに届いてアプリケーション層の応答を受け取れることを確認してください。ブラウザーにページがキャッシュされている場合があるため、リクエストを新たに送るのがおすすめです。端末からはローカルプロキシを明示して、環境変数の影響を避けられます。

# ローカルのmixed-portが7890の場合のHTTPプロキシテスト
# Windowsではcurlの代わりにcurl.exeを指定できます
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

# mixed-portまたはSOCKSの入口が7890の場合のSOCKSテスト
curl --proxy socks5h://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

socks5h は、ドメインの名前解決をSOCKSプロキシ側に任せる指定で、ローカルの名前解決経路との切り分けに適しています。テストでHTTP 403などが返った場合、何らかのHTTPエンドポイントから応答を受け取ったことはわかりますが、接続先サイトのポリシーによってアクセスが制限されている可能性は残ります。接続確立前のタイムアウトとは異なる問題です。

問題の報告を続ける場合は、OSとコアのバージョン、再現手順、発生時刻、機密情報を削除したログ、関連する設定部分、すでに行った項目別の比較結果をまとめてください。画面全体のスクリーンショットよりも、DNS、ルール、待ち受けポート、ノード接続のどこに問題があるかを特定しやすくなります。