1. ログの採取：リクエストを固定してからログレベルを上げる

Clashクライアントの画面ログとコアの実行ログは、記録する内容が異なります。画面ログにはサブスクリプションのダウンロード、サービスの起動、設定のマージなどが記録されることがあります。一方、コアのログには待ち受けポート、DNS、ルールの照合、出方向け接続などが記録されます。Webページが開けない場合は、まずコアが起動していることを確認し、該当リクエストがコアに届いているか調べてください。クライアント画面のエラー画像だけでは、ノードやルールの問題を判断できないことがほとんどです。

再現時に記録する項目

  1. クライアント名とバージョン、コア名と完全なバージョン番号を記録します。Clashオリジナル版とmihomoでは対応する設定項目が異なるため、「最新版」とだけ書くのは避けてください。
  2. 現在の設定名と動作モード、システムプロキシまたはTUNの有効・無効を記録します。ルールを調べるときはルールモードを使い、想定したルールが適用されないグローバルモードは避けてください。
  3. ログ表示を消去して時刻を記録し、問題のあるアドレスだけにアクセスします。約10秒待ってから再読み込みを止め、同じ時間帯のログを保存してください。
  4. 接続一覧で宛先、適用ルール、プロキシグループ、最終的なノードも確認します。ログに出ていない出方向け情報は、接続一覧で補えます。

詳しいログが必要な場合は、使用中のクライアントのログ画面でレベルを変更します。画面に設定項目がないときは、対応する設定編集またはオーバーライド機能で以下の項目を指定してください。サブスクリプションクライアントは実行時の設定を再生成することがあります。後で上書きされるキャッシュ済みのサブスクリプションファイルだけを編集せず、最終的に適用された値を確認してください。

log-level: debug
レベル主な用途確認するポイント
debug短時間での障害再現と調査DNS、接続、コアが出力する詳細なデバッグ情報
info通常時の動作確認起動情報、ルールの照合、接続記録
warning異常なイベントの絞り込み接続失敗、リソース読み込みエラー
error重大なエラーの確認設定の読み込みや主要コンポーネントのエラー
silent通常のログ出力を停止障害の再現時には不向き

メッセージのレベルはコアによって異なり、warning が出てもプロキシ全体が停止したとは限りません。問題を再現できたら、レベルを info に戻してください。ログを共有する前に、サブスクリプションURLのトークン、ノードのパスワード、コントローラーのAPIキー、個人用アクセスドメインを伏せます。ポート、エラーの種類、ルールの順序は残してください。

2. dial tcpのタイムアウト：ノードへの接続か宛先への接続かを見分ける

dial tcp はTCP接続を開始していることを示します。「DNSエラー」と同義ではなく、この文字列だけでノードの障害とも断定できません。重要なのは、その後に表示されるアドレスがプロキシサーバー、接続先、プロキシチェーンの次のホップのどれかを見極めることです。以下のログ例はエラーの形式を示すもので、アドレスにはドキュメント用の例を使っています。実際に使えるノードではありません。

dial tcp 192.0.2.10:443: i/o timeout
dial tcp 192.0.2.10:443: connect: connection refused
dial tcp [2001:db8::10]:443: connect: network is unreachable

代表的な3種類のエラーと確認箇所

  • i/o timeout：制限時間内に接続または読み書きが完了しなかった状態です。該当行のノードアドレス、ポート、送信インターフェース、ネットワーク経路を確認してください。タイムアウト時間を延ばして問題を隠すのは避けましょう。
  • connection refused：接続先から明示的に拒否された場合によく見られます。まずポートの設定、リモート側サービスの待ち受け状態、PCまたは中継機器の拒否ポリシーを確認してください。
  • network is unreachable：現在のネットワークスタックに利用可能な経路がありません。宛先がIPv6アドレスなら、まずOSのIPv6ルートを確認してください。すぐにノードのパスワードが原因だと決めつけないようにしましょう。

エラーにノードサーバーが表示される場合は、同じプロキシグループ内の別の既知の正常なノードに切り替え、同じ宛先で再現するか確認してください。特定のノードだけ失敗するなら、そのノードのサーバー名、ポート、プロトコル設定を確認します。複数のノードで同時に失敗するなら、ローカルネットワーク、ノードの名前解決、プロキシのループを調べてください。ノードの速度テストに成功しても、テスト対象のリクエストが成功したことしか分かりません。すべてのWebサイトやUDP通信が正常とは限りません。

接続一覧に DIRECT と表示される場合、接続先サイトへの直結経路が失敗している可能性があります。まず適用されたルールを確認し、根拠がないままクライアントを再インストールしないでください。ルールは上から順に評価されるため、先行する DOMAIN-SUFFIX やルールセットで出方向け経路が決まっていると、後続の MATCH は結果を変えません。

3. DNS解決失敗：名前解決の経路を順に確認する

no such host は、名前が存在しない場合や名前解決の経路から否定応答が返された場合によく見られます。lookup ... i/o timeout はDNS応答が時間内に返らなかった状態を示します。SERVFAIL はDNSサーバーが問い合わせを完了できなかったことを表します。それぞれ意味が異なるため、どのエラーもプロキシノードの変更だけで解決しようとしないでください。

まず、どのドメインを名前解決しているか確認する

  1. 接続先サイトのドメイン：コアのDNSが有効か、アプリがシステムDNSを使っているか、Fake-IPの問い合わせが実際にコアへ届いているかを確認します。
  2. ノードサーバーのドメイン：ノードのドメイン名を解決する経路を確認します。mihomoでは proxy-server-nameserver でノードの名前解決に使うDNSサーバーを指定できます。具体的な挙動は、使用中のコアのバージョンのドキュメントを確認してください。
  3. 暗号化DNSサーバーのドメイン：名前解決の開始に使う default-nameserver を確認します。上流DNSサーバー自体のドメインを解決できないと、名前解決の経路を開始できません。

以下は、ローカルの 1053 ポートで待ち受ける、最小限のDNS診断用設定例です。既存の dns マップが1つだけになるよう統合し、環境に応じた他の項目は残してください。切り分け用に通常のDNSを使う例であり、あらゆるネットワーク環境に適用できる最終設定ではありません。また、システムDNSを自動で変更するものでもありません。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: redir-host
  nameserver:
    - 223.5.5.5

dig がインストールされた環境では、この待ち受けポートに直接問い合わせできます。以下の2つのコマンドはIPv4レコードとIPv6レコードをそれぞれ調べます。AAAAレコードがなくても、Aレコードの名前解決に失敗したことにはなりません。

dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com AAAA

ローカルの待ち受けポートへの問い合わせが成功しても、アプリで名前解決エラーが続く場合は、アプリ独自のセキュアDNS、ブラウザーのDNSキャッシュ、実際の通信経路を確認してください。待ち受けポートへの問い合わせも失敗する場合は、上流DNSに到達できるか、respect-rules などの機能を有効にしたことで名前解決の依存ループが起きていないかを調べます。上流DNS、Fake-IP、ルーティングルールを一度に変更すると、どの変更が有効だったか分からなくなるため避けてください。

4. ポート競合：待ち受けプロセスと実際のプロキシポートを確認する

起動時に bind: address already in use と表示される場合、待ち受けアドレスとポートが競合している可能性が高いです。Windowsでは「通常、各ソケット アドレスに対してプロトコル、ネットワーク アドレス、またはポートを 1 つのみ使用できます」と表示されることもあります。permission denied は別の問題で、権限やセキュリティポリシー、ポートの予約を確認する必要があります。すべてを既存プロセスによる占有と判断しないでください。

エラー行から具体的なポート番号を確認し、対応する設定項目を調べます。たとえば mixed-port: 7890 はHTTPとSOCKSの両方のプロキシ入口を提供し、external-controller: 127.0.0.1:9090 は管理用インターフェースです。用途は異なります。以下のポート番号は診断用の例であり、実際に使われるポートは実行時の設定で確認してください。

Windows：7890番ポートの待ち受けプロセスを調べる

netstat -ano | findstr :7890
tasklist /FI "PID eq 1234"

1つ目のコマンドではリモートポートも一致する場合があるため、ローカルアドレスの列と LISTENING の状態を確認してください。2つ目のコマンドにある 1234 はPIDの例です。実行時には1つ目の出力に表示された実際のプロセス番号に置き換えます。まずクライアントから通常の手順で終了し、重複して起動したインスタンスを閉じてください。正体の分からないシステムプロセスを直接終了するのは避けましょう。

macOSとLinux：TCPの待ち受けだけを確認する

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -ltnp 'sport = :7890'

Linuxでは、他ユーザーのプロセス情報を表示するために管理者権限が必要な場合があります。ポートを 7891 に変更する場合は、システムプロキシ、ブラウザーの手動プロキシ設定、ターミナルの環境変数も合わせて変更してください。コアのポートだけを変えると、アプリは古いポートへの接続を続けます。allow-lan はLANからのアクセス範囲を制御する設定で、ローカルのポート競合を解決するスイッチではありません。

5. 設定の読み込みエラー：構文、項目、参照先を分けて確認する

設定を読み込めない場合は、まず起動時のエラーを解消してからネットワークを調べます。yaml: line ... はYAMLの構文エラーを示すことが多く、proxy ... not found のようなメッセージは参照名に関係する場合がほとんどです。プロトコルが未対応、または設定項目を認識できない場合は、コアとの互換性に問題がある可能性があります。エラー行は調査の出発点です。実際のインデントミスが直前のブロックにあることもあります。

  • インデント：Tabではなく半角スペースを使います。同じ階層のキーは同じ幅でインデントし、リスト項目では - の後にスペースを入れます。
  • キーの重複：同じ階層に2つ目の dns、rules、proxy-groups を追加しないでください。パーサーによってエラーになったり、内容が上書きされたりするため、結果を予測できません。
  • 名前の参照：ルールが参照するプロキシグループ、プロキシグループが参照するノード、RULE-SET が参照するルールプロバイダーの名前は、定義した名前と一致させてください。
  • コアの対応機能：VLESSやHysteria2などの設定を、Clashオリジナル版がすべて読み込めるとは限りません。クライアント名だけで判断せず、実際に起動しているコアを確認してください。
  • リモートリソース：ルールセットのダウンロード失敗はリソース読み込みの問題であり、YAML構文エラーとは限りません。該当プロバイダーのURL、ファイル形式、キャッシュ先、ダウンロード時の通信経路を確認してください。

mihomoコアを直接実行する場合は、まず設定をテストできます。以下のコマンドを使うには、カレントディレクトリに対応する実行ファイルと設定ファイルが必要です。テストする設定は、クライアントが実際に生成した実行時設定にできるだけ合わせてください。

# macOS / Linux
./mihomo -t -f ./config.yaml

# Windows PowerShell
.\mihomo.exe -t -f .\config.yaml

設定テストに成功しても、そのテストで読み込みを妨げる問題が見つからなかったことを示すだけです。ノードへの接続や、すべてのルールセットの動作まで保証するものではありません。サブスクリプションの元ファイルはテストに通るのにクライアントの起動に失敗する場合は、オーバーライド、スクリプトによるマージ、クライアントが生成した設定の差を確認してください。変更前にバックアップを取り、一度に1種類のエラーだけを修正して再テストします。

6. システムプロキシとTUN：同じリクエストで通信経路を比較する

「ブラウザーでは開けるのに、ターミナルでは開けない」場合は、アプリがシステムプロキシに従うかを確認します。システムプロキシですべてのプログラムが自動的にプロキシ接続になるわけではありません。TUNでは仮想ネットワークアダプター、ルーティング、DNSの取り込みも関係するため、確認範囲が広がります。比較結果がないまま複数のプロキシツールやTUNインスタンスを同時に有効にしないでください。

まず明示的なプロキシ入口をテストする

実行時設定の混合ポートが 7890 であることを前提に、以下のリクエストでシステムプロキシを使うアプリと使わないアプリの違いを切り分けられます。Windows PowerShellでは、古い環境のコマンドエイリアスによる影響を避けるため curl.exe を使います。macOSとLinuxではコマンド名を curl に変更してください。

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

このコマンドでは接続フェーズのタイムアウトを10秒、合計時間の上限を20秒に設定しています。ログの時刻を照らし合わせるためのもので、実測の遅延時間ではありません。127.0.0.1:7890 にすぐ接続できない場合は、まず待ち受け状態を確認します。プロキシトンネルが確立してからTLSに失敗する場合は、その後のハンドシェイクを調べてください。HTTP応答が返ったらステータスコードを確認します。403 などの応答を、プロキシ入口の障害と単純に同一視しないでください。

次にTUNの通信経路を比較する

明示的なプロキシ接続は成功するのに通常のアプリからのリクエストが失敗する場合は、システムプロキシの設定、アプリ独自のプロキシ、TUNのルーティングを重点的に確認します。TUNを有効にしてから問題が起きた場合は、設定のバックアップを取ったうえで一時的にTUNを無効にし、明示的なプロキシでの結果と比較してください。確認する項目は tun.enable、auto-route、dns-hijack などです。ただし、対応状況や権限の要件はコア、クライアント、OSによって異なります。

dns-hijack がすべての暗号化DNSを遮断できると考えないでください。通常のDNSハイジャック設定が処理するのは、条件に一致するDNS通信が中心です。アプリ独自のHTTPS DNSリクエストは別の経路を通ることがあります。ログに該当する接続がまったくない場合は、まずリクエストがコアに届いているか確認します。届いているなら、ルール、出方向け接続、名前解決、ハンドシェイクの順に調べてください。

7. 修正後の確認：再現できる証拠を残す

問題を解決したと判断する前に、最初に失敗したものと同じアドレスで再テストし、ログの適用ルールと出方向けノードが想定どおりか確認します。トップページが一度開いただけでは、サブスクリプション更新、DNS、バックグラウンドアプリまで復旧したとは言えません。

  1. 起動確認：コアの読み込みが完了し、プロキシ入口が正常に待ち受けている。ポートのバインドエラーが繰り返し発生していない。
  2. リクエスト確認：元のリクエストが成功し、ログに同じリクエストのタイムアウトや名前解決エラーが繰り返し記録されない。
  3. 経路確認：直結とプロキシのルールがそれぞれ想定したポリシーに一致し、TUNの状態が用途に合っている。
  4. 設定の保持：クライアントの再起動後やサブスクリプションの更新後も変更が有効で、設定生成の過程で上書きされない。

問題が続く場合は、「クライアントとコアのバージョン、OSのバージョン、再現時刻、宛先の種類、関連する設定の抜粋、前後を含む連続したログ、実施済みの個別テスト」をまとめてください。最後の timeout だけを切り取るより、原因を特定しやすくなります。項目の意味はプロトコルリファレンスで確認できます。ルール、DNS、TUNの違いについては用語クイックリファレンスをご覧ください。