まず失敗した段階を特定し、次にエラーのキーワードを確認

dial tcpは「TCP接続を試みた」という意味で、障害の原因そのものではありません。確認すべきなのは、その後に続くアドレスやポート、末尾のエラーです。i/o timeoutはネットワークの読み書きが制限時間内に完了しなかったこと、no such hostは名前解決で有効なホストアドレスを取得できなかったことを示します。この3つの語を、それぞれ「ノードの故障」「ネットワークが遅い」「DNSを変更すればよい」と決めつけることはできません。

プロキシ経由の通信は通常、「アプリ → ローカルプロキシの入口 → ルールとプロキシグループ → ノードサーバー → 接続先サイト」の順に進みます。DNS問い合わせは、ノードのホスト名解決や接続先の名前解決など、複数の段階で発生することがあります。エラーのアドレスがどの段階のものかを見極めてから、ローカルポート、ノードの選択、DNS設定のどれを確認するか決めましょう。

1回のリクエストで、必要最小限の調査記録を残す

  1. クライアントの「ログ」画面を開き、発生時刻を記録します。画面名は「実行ログ」や「Logs」の場合もあります。
  2. 現在のモード、有効な設定名、プロキシグループで実際に選択されているノード、システムプロキシとTUNの有効・無効を記録します。
  3. ログレベルを一時的にdebugに設定し、エラーを1回だけ再現します。調査後はinfoに戻し、ログが増え続けないようにしてください。
  4. 同じ時刻付近のルール照合結果、出口の選択、最終的なエラーを残します。赤字のキーワードだけを切り取らないでください。

よくあるエラー一覧：原因を特定してから設定を変更

ログの末尾またはキーワード意味最初に確認すること
connection refused接続が明示的に拒否された接続先のアドレスとポート、サービスが待ち受けているか
i/o timeoutネットワーク処理が制限時間を超えたタイムアウトがDNS、ノード接続、接続先応答のどこで起きたか
no such hostホスト名を解決できなかった対象のホスト名、スペル、使用中の名前解決経路
address already in useローカルの待ち受けアドレスが使用中競合しているポートと使用中のプロセス
network is unreachable現在のネットワークに利用可能な経路がないIPv4/IPv6のルート、ネットワークインターフェース、トンネルの状態
certificate has expired証明書の有効期間を確認できなかったシステム時刻、ノード証明書、サーバーのメンテナンス状況

1つのエラーに複数の原因が含まれることもあります。たとえば、外側にdial failedと表示され、その内側にDNS問い合わせのタイムアウトが記録されている場合です。まず最も内側の具体的なエラーを確認し、次にどの接続で発生したのかを外側に向かってたどります。

dial tcpとconnection refused：接続先を特定する

dial tcp 192.0.2.10:443: connect: connection refused

このログは、192.0.2.10:443へのTCP接続が拒否されたことを示しています。よくある原因は、サービスが起動していない、ポートの指定ミス、ネットワーク機器による接続拒否です。このアドレスがノードサーバーなら、現在のノードのserverとportを確認します。直結先のアドレスなら、ルールによってリクエストがDIRECTに送られていないか確認してください。

127.0.0.1が表示されたら、まずローカルのプロキシ入口を確認

Failed to connect to 127.0.0.1 port 7890: Connection refused

このエラーはClashのログではなく、ブラウザーやコマンドラインツールに表示されている場合もあります。通常は、アプリがローカルのプロキシ入口に接続できていません。コアが起動していない、入口のポートが変わった、アプリが古いポートを使っている、といった原因が考えられます。クライアントのポート設定で実際の待ち受けポートを確認し、システムプロキシのアドレスとポートも照合してください。

  • mixed-port: 7890：同じポートでHTTPプロキシとSOCKSプロキシの通信を受け付けます。
  • port：HTTPプロキシの入口。socks-port：SOCKSプロキシの入口。ポート番号だけでプロトコルを判断しないでください。
  • external-controller：操作用のコントロールインターフェースで、ブラウザーが使うプロキシ入口ではありません。

たとえば、コントロールインターフェースが127.0.0.1:9090でも、システムプロキシに9090を設定するという意味ではありません。プロキシ入口とコントロールインターフェースを混同すると、接続失敗や予期しない応答、ページを読み込めないといった問題が起こります。

i/o timeout：DNS・ノード・接続先を分けて確認

i/o timeoutは、あるネットワーク処理が制限時間内に完了しなかったことを示すだけです。DNSのUDP問い合わせ、ノードサーバーへの接続、接続後の読み書きなど、さまざまな段階で発生します。この語だけを見て次々とノードを切り替えると、本当の原因であるローカルネットワークの問題を見落としかねません。

手順1：プロキシの入口を明示して再現する

実際の混合ポートが7890の場合は、以下のコマンドを実行します。Windows PowerShellでは、一部の環境でcurlが別のコマンドとして扱われるのを避けるため、curl.exeを使います。macOSとLinuxでは通常curlを使います。

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

ここでの10秒は接続処理の上限、20秒はリクエスト全体の上限であり、コアのデフォルトタイムアウト値ではありません。-IはHEADリクエストを送信するため、サーバーが405を返す場合があります。有効なHTTPレスポンスを受信できていれば、このステータスコードをネットワークタイムアウトと見なすことはできません。レスポンス本文を確認する場合は-Iを外します。

手順2：変更する条件は一度に1つだけ

  1. 接続先URLとルールを変えず、同じプロキシグループ内で動作確認済みのノードに1つだけ切り替えて、リクエストを再実行します。
  2. ノードを変えず、アクセス可能な別の接続先を試します。1つの接続先だけ失敗する場合は、接続先側の制限や該当ルールを優先して確認します。
  3. クライアントの設定は変えず、スマートフォンのテザリングで試します。テザリングでは正常で元のネットワークでは失敗する場合に、元のネットワークのルートやフィルタリングを調べる根拠が得られます。

遅延テストに成功しても、すべてのWebサイトに接続できるとは限りません。テストURL、HTTPステータスの条件、実際に利用する接続先は異なる場合があります。反対に、テストに失敗してもノードがまったく使えないとは限りません。問題が起きたリクエストを使って、複数の条件から確認してください。

no such host：名前解決に失敗したホスト名を特定する

lookup node.example.net: no such host

エラーに表示されたホスト名がノードのserverなら、プロキシ経路がまだ確立していません。まずノードのホスト名の入力ミス、サブスクリプションの期限切れやプロバイダーによる変更を確認し、次にノードのホスト名を解決する経路を調べます。接続先サイトのホスト名が表示されている場合は、接続先の名前解決とルールを確認してください。サブスクリプションの失効とは限りません。

次の3点を順番に確認

  1. アドレスそのもの：serverにhttps://やパス、末尾の空白を含む完全なURLが設定されていないか確認します。通常、この項目にはホスト名またはIPアドレスを指定します。
  2. システムの名前解決：nslookup node.example.netを実行します。このホスト名は形式の例です。実際の確認ではログにあるホスト名に置き換え、使用中のDNSリゾルバーに問い合わせが送信される点に注意してください。
  3. コアの名前解決：実際に適用されている設定のdnsセクションを確認し、同じ時刻にリゾルバーへの接続タイムアウトや接続拒否が発生していないか調べます。

nslookupの結果は比較材料であり、コアのDNSが正常に動作している証明にはなりません。システムのリゾルバー、Clash内蔵DNS、ブラウザーのセキュアDNSでは、異なる経路を使うことがあります。TUNのDNSハイジャックによって問い合わせ経路が変わる場合もあります。

「プロキシ経由で暗号化DNSに接続する」設定にしていて、ノードのホスト名解決にもそのDNSが必要な場合、起動時に依存関係の循環が発生することがあります。まだ確立していないプロキシにすべてのDNS問い合わせを強制的に送るのではなく、まずノードのホスト名を解決できる経路を用意してください。

address already in use：ローカルポートの競合を調べる

listen tcp 127.0.0.1:7890: bind: address already in use

ローカルでの待ち受けに失敗しており、ノードの契約やリモートのホスト名とは直接関係ありません。別のプロキシクライアントが起動している、または古いコアのプロセスが正常に終了していない、といったケースがよくあります。まずポートを使用しているプロセスを確認し、古いプロセスを終了するかポートを変更するか判断してください。正体の分からないシステムプロセスを終了しないでください。

Windows：待ち受け中のプロセスを特定

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

1つ目のコマンドで対象ポートを含む記録が表示されます。ローカルアドレス、LISTENINGの状態、PIDを確認してください。2つ目のコマンドにある1234はプロセス番号の例です。実行時には検索結果で確認した実際のPIDを使います。接続記録があるだけでは、そのプログラムが待ち受けポートを使用しているとは限りません。

macOS / Linux：待ち受け中のプロセスを確認

lsof -nP -iTCP:7890 -sTCP:LISTEN

Linuxでlsofがインストールされていない場合は、ss -ltnp 'sport = :7890'を試してください。プロセス情報の表示には追加の権限が必要な場合があります。混合ポートを7890から7891に変更する場合は、システムプロキシ、ブラウザー拡張機能、ターミナルの環境変数、入口を手動設定している他のアプリもすべて更新してください。

画面に「起動済み」と表示されても、すべての入口が正常に待ち受けているとは限りません。起動後のログで、エラーがmixed-port、DNSの待ち受けポート、コントロールインターフェースのどれに関係するか確認し、異なる設定箇所を変更しないようにしてください。

TUN・証明書・接続切断：すべて同じタイムアウトとして扱わない

  • network is unreachable：まずアドレスがIPv6かどうかを確認し、現在のネットワークに利用可能なIPv6ルートがあるか調べます。これはルートの問題に近いエラーで、この1行だけでサーバーが停止しているとは判断できません。
  • permission deniedまたはoperation not permitted：TUNデバイスの作成時に発生した場合は、クライアントのサービスモード、システムの許可設定、他のVPNによる占有を確認します。現在使用中のクライアントのインストール手順に従って権限を設定し、プログラム全体の権限をむやみに引き上げないでください。
  • x509: certificate has expired or is not yet valid：まずシステムの日付、時刻、タイムゾーンを確認し、次にノードの証明書を確認します。skip-cert-verify: trueを恒久的な対処法として使わないでください。
  • connection reset by peerまたはEOF：接続がリセットされた、または読み取りが終了したことを示します。サーバー側、プロトコル設定、中継ネットワークなどが関係する可能性があります。この1行だけでパスワードの誤りとは判断できません。

TUNとの比較テストでは、最初に現在の状態を記録し、TUNを無効にして127.0.0.1:7890を明示したリクエストを試します。明示的なプロキシでは正常でTUNでは失敗する場合は、ルート、DNSハイジャック、他のVPNとの競合を重点的に確認してください。TUNを無効にしてブラウザーを直接開く方法は、同じテストにはなりません。ブラウザーがシステムプロキシを使う場合も、直接接続する場合もあります。

特定のアプリだけ失敗する場合は、TCPとUDPのどちらを使うか、システムプロキシを参照するか、独自のプロキシ設定があるかを確認してください。HTTPプロキシのリクエストが成功しても、UDP転送が正常とは限りません。そのためにすぐ全体モードやサブスクリプション全体の設定を変更しないでください。

修正後の再テスト：比較できる記録を残す

  1. 同じURL、同じリクエスト方法、同じプロキシグループを使って再テストし、元のエラーが再発しないことを確認します。
  2. ログで実際に適用されたルールと出口を確認し、意図せず直接接続に切り替わっていないか調べます。
  3. 一時的に変更したログレベルやテスト用スイッチを元に戻し、必要なローカル設定の変更を保存します。
  4. サポートを求める際は、コア名とバージョン、OSのバージョン、エラー発生時刻、エラーの全体、再現手順を伝えてください。

調査はローカルの入口 → ルールの出口 → ノードの名前解決と接続 → 接続先の応答の順に進めます。変更は一度に1項目だけにし、同じリクエストについて変更前後を記録すると、何度も再インストールするより原因を特定しやすくなります。ポート設定ははじめにのポート解説を、タイムアウトが続く場合はトラブル対処のタイムアウト解説を参照してください。