Clashのノードがタイムアウトして接続できない場合：クライアント設定からローカルネットワークまでの確認手順

まず、どの種類の「タイムアウト」かを見極める

Clashでタイムアウトと表示されても、原因が必ずノードサーバーにあるとは限りません。速度テストのリクエストは、クライアントのコア、名前解決、ローカルネットワーク、ノードの入口、テストURLを順に経由します。どこか一つでも制限時間内に応答しなければ、Timeoutと表示されることがあります。まず範囲を絞り込んでから設定を変更しましょう。サブスクリプションを何度も更新するより効果的です。

症状	優先して疑う箇所	最初の確認項目
すべてのノードが同時にタイムアウトする	コアが動作していない、入口ドメインを解決できない、ローカルネットワークまたはファイアウォールによる遮断	コアの状態と直接接続を確認する
1つのノードだけタイムアウトする	ノードが停止している、ポートが閉じている、またはそのノードのプロトコルパラメータに誤りがある	同じサブスクリプションから別のノードに切り替える
速度テストはタイムアウトするがウェブページは開ける	遅延テストのURLに到達できない、またはテストのタイムアウト時間が短すぎる	実際の接続ログを確認する
ブラウザーは使えるが、ほかのアプリは使えない	システムプロキシの適用範囲、アプリによるプロキシのバイパス、またはTUNがトラフィックを取得していない	システムプロキシとTUNモードを確認する
TUNを有効にするとすべてオフラインになる	仮想ネットワークアダプター、ルーティング、DNSハイジャック、または権限の問題	TUNを無効にして基本的なプロキシテストに戻す

比較テストでノードの問題とローカル環境の問題を切り分ける

現在のサブスクリプションは変更せず、地域と入口の異なるノードを少なくとも3つ連続でテストします。
ClashのシステムプロキシとTUNを無効にし、普段アクセスできるウェブサイトを直接開いて、基本的なネットワークが正常か確認します。
Clashのコアを再起動し、システムプロキシだけを有効にしてから、ブラウザーでアクセスをテストします。
同じサブスクリプションを別のデバイスまたは別のネットワーク（スマートフォンのテザリングなど）に一時的に読み込み、結果を比較します。

同じノードが自宅のブロードバンドではタイムアウトし、スマートフォンのテザリングでは使える場合、原因はローカル環境、ルーター、または現在のネットワーク出口にある可能性が高くなります。複数のデバイスと異なるネットワークで、同じノードだけが失敗し、同じサブスクリプションのほかのノードは正常なら、原因をそのノードの入口、ポート、またはプロトコルパラメータに絞り込めます。

手順1：クライアントのコア、設定、プロキシポートを確認する

すべてのノードがタイムアウトするときは、まずClash Meta（mihomo）コアが正常に起動していることを確認します。グラフィカルインターフェースが開けても、コアがポートをリッスンしているとは限りません。ログにaddress already in use、configuration file test failed、または再起動の繰り返しが表示される場合は、先にポート競合と設定エラーを解消してください。

コアの状態と現在の設定を確認する

Clash Verge Rev 2.4.2の一般的な画面を例にすると、「設定」→「Clash 設定」で現在のコアとポートを確認し、「サブスクリプション」で使用中の設定を確認できます。クライアントによって「コア」「設定」「Profiles」など名称は異なりますが、判断基準は同じです。設定が有効で、コアが実行中であり、ログにエラーのループがないことを確認します。

Mixed Port：一般的には7890で、HTTPとSOCKS5のリクエストを同時に受け付けます。
HTTP Port：旧設定では7890がよく使われます。
SOCKS Port：旧設定では7891がよく使われます。
External Controller：一般的な待受アドレスは127.0.0.1:9090です。これは制御インターフェースであり、アプリ用のプロキシポートではありません。

ブラウザーのプロキシに制御ポート9090を設定しないでください。設定でmixed-port: 7890だけが指定されている場合、ブラウザーまたはシステムプロキシは127.0.0.1:7890を指定します。ポートを変更したら、システムプロキシ、ブラウザー拡張機能、その他の手動設定も更新してください。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

ポート競合を解消する

WindowsではPowerShellで7890番ポートを別のプロセスがリッスンしていないか確認できます。

Get-NetTCPConnection -LocalPort 7890 -ErrorAction SilentlyContinue
Get-Process -Id (Get-NetTCPConnection -LocalPort 7890).OwningProcess

macOSとLinuxでは次を使用できます。

lsof -nP -iTCP:7890 -sTCP:LISTEN
ss -lntp | grep 7890

旧バージョンのClash、ほかのプロキシツール、または残ったバックグラウンドプロセスが同じポートを使用している場合は、競合するプログラムを終了してから現在のクライアントを再起動します。2つのプログラムで同時にシステムプロキシを設定しないでください。画面に表示されるポートと、OSが実際に使用するポートが一致しなくなる可能性があります。

手順2：システムプロキシからTUNモードへ範囲を広げる

基本的な切り分けでは、最初からTUNを有効にせず、まずシステムプロキシを使います。システムプロキシの経路は短く、ノードが接続を確立できるか確認しやすいためです。Clash Verge Rev 2.4.2を例に、「設定」→「システム設定」→「システムプロキシ」を開き、有効化後にシステムプロキシサーバーが127.0.0.1で、ポートがMixed Portと一致しているか確認します。

ブラウザーは正常だが、アプリは直接接続している

システムプロキシが適用されるのは、OSのプロキシ設定を自動的に読み取るアプリだけです。一部のゲーム、コマンドラインツール、仮想マシン、独自のネットワークスタックを使うソフトウェアはシステムプロキシを無視します。そのため、ブラウザーが正常にアクセスできても、すべてのアプリがプロキシ経由になっているとは限りません。

まずClashの「接続」パネルで対象のドメインまたはプロセスを検索します。
記録がまったく表示されない場合、通常はトラフィックがClashに入っていません。
記録はあるものの状態が「接続中」のまま繰り返される場合は、ノードの入口とDNSを続けて確認します。
記録にDIRECTと表示される場合は、ノードを変更するのではなく、ルールのマッチ結果を確認してください。

TUNを有効にするとすべてタイムアウトする

TUNモードは仮想ネットワークアダプターとルーティングルールを通じて、より多くのトラフィックを取得します。Windowsでは通常、管理者権限と正常に読み込める仮想ネットワークアダプターのドライバーが必要です。macOSでは初回有効化時にネットワーク拡張機能の許可が必要です。Linuxでは/dev/net/tunと適切なネットワーク管理権限が必要です。

TUNを無効にするとシステムプロキシが使える場合、ノード自体は正常である可能性が高いでしょう。この場合はサブスクリプションを変更し続けるのではなく、TUNを個別に確認します。次の順序で復旧してください。

TUNを無効にしてクライアントを終了し、システムネットワークが復旧したことを確認します。
クライアントを再起動し、まずMixed Portのプロキシが使えることを確認します。
必要な権限でクライアントを起動してから、TUNを有効にします。
VPN、仮想マシンのブリッジ接続、トラフィックフィルター、別のTUNソフトウェアが同時に動作していないか確認します。
ドメインは開けないがIPアドレスにはアクセスできる場合は、DNSの確認に進みます。

手順3：DNSとノード入口のドメインを確認する

ノードアドレスはIPアドレスの場合もあれば、ドメイン名の場合もあります。サーバーアドレスにドメイン名を使う場合、Clashはまずローカルリゾルバーまたは設定されたデフォルトリゾルバーで入口IPを取得する必要があります。入口ドメインの名前解決に失敗すると、プロキシプロトコルのパラメータが正しくても、同じ入口に依存するノードがすべてタイムアウトします。

まずOS側で名前解決を確認する

Windowsでは次を実行します。

nslookup node.example.com
Resolve-DnsName node.example.com

macOSまたはLinuxでは次を実行します。

dig node.example.com
nslookup node.example.com

node.example.comは、設定内のノードの実際のserver値に置き換えてください。NXDOMAIN、タイムアウト、またはA/AAAAレコードなしが返る場合は、サブスクリプション内の入口ドメインがまだ有効か確認します。複数の失敗ノードが同じ入口ドメインを共有している場合、この確認は特に重要です。

入口の名前解決とプロキシ経由のDNSを切り分ける

ClashのDNS設定は、アプリのドメイン解決を担うだけでなく、ノード入口の名前解決にも関わる場合があります。mihomo設定のdefault-nameserverは、DNSサーバー自身やノード入口などの基礎的な宛先を解決するために使われます。通常は直接アクセスできるIP形式のDNSアドレスを指定し、「プロキシ経由でなければプロキシ入口を解決できない」という循環依存を避けます。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  default-nameserver:
    - 1.1.1.1
    - 8.8.8.8
  nameserver:
    - https://1.1.1.1/dns-query

この設定例はDNSの階層を説明するためのもので、すべてのネットワークに同じリゾルバーが適していることを示すものではありません。企業ネットワーク、学校ネットワーク、または内部ドメインを使う環境では、LANのDNSを残す必要がある場合があります。変更前に元の設定を保存し、変更後に再読み込みして、ログにlookup、no such host、またはDNSリクエストのタイムアウトが出ていないか確認してください。

IPv6の入口だけが失敗する場合は、現在のネットワークに利用可能なIPv6ルートがあるか一時的に確認できます。AAAAレコードが解決できても、ローカル環境からIPv6に接続できるとは限りません。問題を隠すためにIPv6を安易に無効化したままにせず、ルーター、通信事業者の経路、ノード入口が実際に対応しているか確認してください。

手順4：単一ノードのタイムアウト時にプロトコルパラメータを確認する

1つのノードだけが失敗し、同じサブスクリプションのほかのノードが使える場合、ローカルのシステムプロキシと基本DNSに大きな問題はないことが多いでしょう。対象ノードのサーバーアドレス、ポート、プロトコル項目を重点的に確認します。サブスクリプションを再読み込みすれば手動編集による項目欠落は切り分けられますが、サーバー停止や配信元データの誤りは修正できません。

プロトコルまたはトランスポート	確認する主な項目	よくあるエラーの症状
Shadowsocks	server、port、cipher、password	暗号化方式またはパスワードが一致せず、接続確立直後に失敗する
VMess	uuid、alterId、cipher、network、tls	UUID、トランスポート層、TLS設定が一致していない
VLESS	uuid、flow、servername、network	SNI、flow、またはトランスポート方式が誤っている
Trojan	password、servername、skip-cert-verify	証明書名とSNIが一致していない
WebSocket	path、Hostヘッダー、TLS	パスまたはHostが一致せず、ハンドシェイクを拒否される
gRPC	service-name、servername、TLS	サービス名が一致していない、または中間ネットワークが対応していない
Reality	servername、public-key、short-id、fingerprint	ハンドシェイクパラメータが一致せず、ログにTLS関連エラーが出る

経験だけを頼りにtls、udp、skip-cert-verifyを切り替えないでください。これらの項目はサーバー側の設定と一致している必要があります。特に証明書検証のスキップを万能な解決策として使うべきではありません。一時的にエラーを隠せても、SNI、証明書の有効期限、システム時刻の誤りは解決できません。

ローカルの時刻を確認する

TLSハンドシェイクには正確な時刻が必要です。Windowsでは「設定」→「時刻と言語」→「日付と時刻」を開き、自動設定を有効にして「今すぐ同期」を実行します。macOSでは「システム設定」→「一般」→「日付と時刻」を開き、自動設定を有効にします。システム時刻が数分ずれるだけでも、証明書がまだ有効でない、または期限切れだと判定されることがあります。

ノードのポートに到達できるか確認する

WindowsのPowerShellでは、ノードのサーバーとポートを対象にTCP疎通を確認できます。

Test-NetConnection node.example.com -Port 443

macOSまたはLinuxでは次を使用できます。

nc -vz node.example.com 443

TCPテストの成功は、入口ポートへの接続を確立できることだけを示し、UUID、パスワード、TLS、トランスポートパラメータが正しいとは限りません。テストに失敗する場合は、サーバーがリッスンしていない、入口アドレスが無効、ファイアウォールが破棄している、現在のネットワークに制限があるなどの可能性があります。一部のUDPプロトコルはTCPテストだけでは判断できないため、コアのログや別ネットワークでの比較テストも確認してください。

手順5：ファイアウォール、ルーター、現在のネットワークを確認する

すべてのノードが失敗し、別のデバイスでは設定を正常に使える場合は、ローカルのセキュリティポリシーを確認します。Windowsファイアウォールがグラフィカルインターフェースの通信は許可しても、実際に動作するmihomoコアを遮断することがあります。サードパーティ製セキュリティソフトもプロセスパス単位でルールを作成する場合があり、クライアント更新後にコアのファイルパスが変わると、以前の許可ルールが一致しなくなります。

Windowsでの確認手順

「Windows セキュリティ」→「ファイアウォールとネットワーク保護」→「ファイアウォールによるアプリの許可」を開きます。
現在のClashクライアントとmihomoコアが、使用中のネットワークの種類でアクセスを許可されていることを確認します。
「設定」→「ネットワークとインターネット」→「プロキシ」を開き、無効な手動プロキシが残っていないか確認します。
ほかのVPN、プロキシ、ネットワークフィルタリングソフトを終了してから、Clashを再起動します。
スマートフォンのテザリングで再テストし、問題が現在のルーターまたはブロードバンド回線だけで発生するか確認します。

ファイアウォールを一時的に無効化するのは、短時間の比較テストに限ってください。ルールが原因だと確認できたら、ファイアウォールを元に戻し、実際のコアプログラムに明確な許可ルールを作成します。無効化したまま運用しないでください。

ルーターとネットワーク出口

ルーターのペアレンタルコントロール、ゲストネットワークの分離、企業ネットワークのACL、公共Wi-Fiの認証ページは、ノード接続に影響することがあります。まず通常のHTTPとHTTPSサイトを開き、認証が完了していることを確認します。スマートフォンのテザリングですぐ復旧する場合は、ルーターのDNS、IPv6、MTU、アクセス制御、上流ネットワークの制限を順に確認します。

MTUの問題は、TCP接続は確立できるものの、TLSまたは大きなパケットの段階で停止する形で現れることがあります。TUN環境で小さなウェブページは時々開くのに、画像やダウンロードが長時間止まる場合は、追加の確認項目としてMTUを調べます。ただし比較結果がないまま、むやみに変更しないでください。まず現在値を記録し、クライアントがサポートする設定に従って少しずつ調整します。変更幅は毎回小さくしてください。

ログの読み方：エラーキーワードで段階を特定する

ログレベルを一時的にinfoに設定すれば、通常は十分です。ルールやハンドシェイクの詳細を追跡する必要がある場合だけ、短時間debugを使い、終了後は元に戻してください。ログが急速に増えるのを防げます。問題を再現するときは、正確な時刻、ノード名、対象ドメインを記録し、同じ時刻付近の情報を検索します。

ログのキーワード	示唆される原因	次の手順
no such host	ドメインの名前解決に失敗	入口ドメインとDNSを確認する
i/o timeout	制限時間内にネットワーク処理が完了しない	入口への到達性、ファイアウォール、ネットワーク比較の結果を確認する
connection refused	対象ホストが明示的に接続を拒否	サーバーのポートとノードの状態を確認する
network is unreachable	ローカルに対応するルートがない	IPv4、IPv6、TUN、デフォルトルートを確認する
certificate	TLS証明書の検証に異常	システム時刻、servername、証明書の状態を確認する
address already in use	ローカルの待受ポートが競合	占有プロセスを終了するかポートを変更する

i/o timeoutは結果を示すだけで、原因の担当箇所を直接示すものではありません。直前に表示された対象アドレスと組み合わせて判断してください。タイムアウトの対象がノード入口なら、ノードとローカルのネットワーク出口を確認します。DNSサーバーなら名前解決の経路を確認します。遅延テストのURLでだけ発生し、ほかの接続が正常なら、速度テスト先を確認してください。

確認手順と復旧基準を固定する

完全な手順は8段階にまとめられます。順番に実行し、各段階の結果を記録してください。

直接接続を確認：システムプロキシとTUNを無効にし、基本ネットワークが正常か確認します。
コアの動作を確認：設定の読み込み、ポートのリッスン、起動ログを確認します。
システムプロキシだけを有効化：127.0.0.1:7890など、実際のMixed Portでテストします。
複数ノードを比較：少なくとも3つのノードをテストし、単一ノードの障害か全体の障害かを切り分けます。
入口の名前解決を確認：ノードのドメインを調べ、IPv4、IPv6、DNSログを確認します。
プロトコル項目を確認：単一ノードを対象に、ポート、TLS、SNI、トランスポートパラメータを確認します。
ネットワークを変更して再テスト：スマートフォンのテザリングを使い、ローカル環境、ルーター、現在のネットワーク出口を切り分けます。
最後にTUNを復旧：基本プロキシが安定してから、仮想ネットワークアダプター、ルーティング、DNSの取得状態を確認します。

復旧の基準は、ノードの遅延に数字が表示されることだけではありません。少なくとも、クライアントのコアが安定して動作している、ウェブリクエストが接続パネルに表示される、ルールが想定どおりにマッチする、複数の対象を連続して開いても断続的なタイムアウトがない、ノード切り替え後の新しい接続が新しいポリシーを使う、という条件を同時に満たす必要があります。速度テストだけが復旧し、実際の接続が失敗するなら、確認はまだ終わっていません。