Clashのノード接続タイムアウトを解消:サブスク・ポート・プロトコル設定の確認順序

ノードのタイムアウトは Clash や mihomo コア利用時に最も多く見られる不具合ですが、「タイムアウト」の裏にある原因は一つではありません。同じ赤い感嘆符や timeout 表示でも、サブスク自体の失効、ローカル側の測定方法が不適切、ポートやプロトコル設定の入力ミス、さらにはシステム時刻のズレやローカルファイアウォールによるハンドシェイクのブロックなど、様々な要因が考えられます。一つずつ切り分ける前に、まず現象を分類しておくことで無駄な作業を大幅に減らせます。

B-01全滅タイムアウトか一部だけかを見分ける

ノード一覧を開き、タイムアウトの発生範囲を確認します。この段階の判断が、以降どの方向を調べるべきかを決めます。

• すべてのノードがタイムアウト:多くはローカルのネットワーク環境、サブスク自体の失効、システム時刻のズレ、あるいはファイアウォールやセキュリティソフトによる一括ブロックが原因で、個別のノード故障とは考えにくいです。
• 一部のノードだけタイムアウトし、他は正常:該当ノードのサーバー側の停止、そのノードのプロトコル設定がサーバー側と一致していない、あるいは中継経路自体が不安定であることが多いです。
• 接続が不安定で一定しない:測定方法自体が不正確なケースや、サーバー側が混雑時間帯に速度制限をかけているケースが多く、ノードが完全に使えなくなったわけではありません。

B-02サブスクの有効性を確認

すべてのノードがタイムアウトしている場合は、まずサブスク自体が有効かどうかを確認します。ここは見落としやすいものの、発生頻度が最も高いポイントです。

1. クライアントのサブスク管理ページを開き、有効期限と残りの通信量を確認します。多くのサブスクは通信量を使い切るか期限が切れると、機場(プロキシ提供元)側がすべての接続要求を拒否するようになり、これが全ノードタイムアウトとして表れます。
2. 「サブスクを更新」を手動でクリックし、ノード数が変化するかを確認します。更新後にノード数が 0 になったり一覧が空になった場合は、サブスクのリンク自体が失効または削除された可能性があります。
3. ブラウザでサブスクのリンクを直接開き(クライアント専用のリクエストヘッダー制限を外した状態で)、正常な Base64 または YAML テキストが返るかを確認します。403、404、または空の応答が返る場合は、問題はクライアント設定ではなくサブスク元にあります。
4. サブスクのリンクに有効期限パラメータや一時的な認証トークンが含まれていないかを確認します。機場によってはリンクに有効期間があり、切れたら管理ページで再発行が必要です。

B-03ローカルの測定方法を検証

クライアント画面に表示される遅延値は、測定方法自体が適切かどうかに左右されます。測定方法が不適切だと、実際には使えるノードがタイムアウトと誤判定されることがあります。

• 測定先アドレスの選択:多くのクライアントはデフォルトで http://www.gstatic.com/generate_204 などの接続確認用アドレスを使用します。このドメインへのアクセス自体が不安定な環境では、測定結果がずれることがあるため、設定で別の測定先に変更して比較してみてください。
• 測定プロトコルの違い:TCP レベルの遅延測定と、実際のプロキシ通信で使われるプロトコル(Shadowsocks、VMess、Trojan、Hysteria2 など)のハンドシェイク方式は異なります。TCP レベルで正常でも、プロトコル層で必ず接続が確立できるとは限らず、「測定は正常なのにページの読み込みが遅い、またはタイムアウトする」という現象の典型的な原因になります。
• 一括測定による干渉:全ノードを一度に一括測定すると、ローカルの帯域幅と同時接続数が競合し、後から測定されるノードの結果が実際より悪くなることがあります。疑わしいノードは個別に測定してから判断することをおすすめします。

curl -x http://127.0.0.1:7890 https://www.gstatic.com/generate_204 -I -m 5

このコマンドはローカルのプロキシポートを経由して接続確認を行います。HTTP/1.1 204 が返れば、現在選択中のノードとローカルのプロキシ経路は正常で、タイムアウト表示はクライアント画面上の測定ロジック自体の問題である可能性が高いです。コマンド自体が固まったりエラーになる場合は、実際にプロキシ経路で問題が起きているため、次にポートとプロトコル設定の確認に進みます。

B-04ポートとプロトコル設定を確認

一部のノードが長期的にタイムアウトし、サブスクと測定方法を確認しても解決しない場合は、そのノードの接続パラメータがサーバー側の設定と一致していないケースが多いです。

1. ポート番号の確認:ノードの詳細を開き、ポート番号が機場の管理画面で提供された情報と完全に一致しているかを確認します。手動でサブスクを設定したり自分でノードを構築した場合、コピー時に数字が一桁多い・少ないといった単純なミスが最も多い原因です。
2. プロトコルと暗号化方式の確認:Shadowsocks では暗号化方式(aes-256-gcm、chacha20-ietf-poly1305 など)がサーバー側と一致しているか、VMess では UUID・AlterId(新しいバージョンでは通常 0)・通信方式(TCP/WS/gRPC)を確認、Trojan と Hysteria2 では SNI と証明書検証オプションがサーバー側の設定と一致しているかを確認します。いずれかが誤っているとハンドシェイクに失敗し、タイムアウトとして表示されます。
3. トランスポート層設定の確認:WebSocket や gRPC を使うノードでは、Path と Host ヘッダーがサーバー側と一致しているかも確認が必要です。これらのパラメータは手動でサブスクリンクを解析する際に、途中で切れたりエスケープが誤ったりすることがあります。
4. TLS/SNI 設定の確認:TLS を有効にしたノードで SNI の入力が誤っていたり、未登録・ブロック済みのドメインを指していると、ハンドシェイク段階で即座にタイムアウトします。この現象はポート設定ミスと画面上ではほぼ区別できないため、設定ファイルを一項目ずつ確認する必要があります。

B-05システム時刻とローカルファイアウォールを確認

前段までの確認で問題が見つからないのに、依然として全滅タイムアウトが発生している場合、見落としがちな 2 つの環境要因があります。

• システム時刻のズレ:多くの暗号化プロキシプロトコル(特に Shadowsocks の AEAD 暗号化や VMess のタイムスタンプ検証)は、クライアントとサーバーのシステム時刻がほぼ同期していることを前提としています。ローカルのシステム時刻が一定範囲以上ズレていると、サーバー側がハンドシェイクを拒否し、全ノード同時タイムアウトとして表れます。「ネットワーク時刻の自動同期」が有効になっているか、タイムゾーン設定が正しいかを手動で確認してください。
• ローカルファイアウォールとセキュリティソフト:一部のセキュリティソフトやシステム標準のファイアウォールが、Clash がリスンするローカルポート(7890 混合ポートや TUN モードの仮想アダプタなど)をブロックまたは速度制限することがあります。セキュリティソフトのネットワーク保護機能を一時的に無効化して比較テストを行い、無効化後に正常になった場合は、必要な許可ルールを一つずつ追加してください。保護機能を長期間無効にしたままにしないよう注意しましょう。
• TUN モードのドライバー権限:TUN モードでグローバル通信を制御する場合、仮想アダプタのドライバーを正常に作成するには管理者権限(または root 権限)が必要です。権限が不足していると、通信が TUN 経由ではなくシステムプロキシ経路を通ってしまい、一部アプリの接続異常につながります。確認時はいったんシステムプロキシモードに切り替えて比較してみてください。
• ルーターや上位ネットワークの制限:一部の家庭用ブロードバンドや社内ネットワークでは、特定のポート範囲に速度制限やブロックがかかっている場合があります。ローカル側の設定に問題がないことを確認できたら、別のネットワーク環境(スマートフォンのテザリングなど)に切り替えて比較検証してみてください。

B-06確認手順のまとめ

表にまとめておくと、順番に一項目ずつ確認しやすく、見落としや重複作業を防げます。

上記の順序で一通り確認すれば、ほとんどのタイムアウト問題はどの段階が原因かを特定できます。最終的にサーバー側のノード自体が停止または速度制限されていると判明した場合は、機場を変更するかサービス提供元に連絡することが唯一の有効な解決策です。クライアント側の設定だけではサーバー側の問題は解決できません。