ノードの接続タイムアウトは、Clash 利用時に最もよく遭遇するエラーの一つですが、同じような症状の裏には全く異なる原因が隠れていることが多い——サブスクリプション自体が失効している場合もあれば、ローカル回線や DNS に問題がある場合、あるいはプロトコルパラメータやポート設定がサーバー側と一致していない場合もあります。手当たり次第にノードを切り替えたりクライアントを再起動したりしても根本的な解決にはならず、貴重な時間を浪費するだけです。本稿では固定の手順を提示します:まずサブスクリプションの有効性を確認し、次にローカル回線と DNS をテストし、最後にプロトコルとポートを確認する。階層順に一つずつ排除していけば、問題がどの段階にあるのか素早く判断できます。
ステップ1:サブスクリプション自体の有効性を確認する
ローカル設定や回線環境を疑う前に、まず最も基本的でありながら見落とされがちな「サブスクリプション失効」の可能性を排除しましょう。サブスクリプションリンクに対応するノードリストは業者側で管理されており、ノードの停止、期限切れによるサービス停止、トラフィック上限の消費などが起きると、すべてのノードが同時にタイムアウトします。この場合、ローカル側の設定をどう調整しても接続は回復しません。
- 有効期限とトラフィック残量を確認する:多くのクライアントはサブスクリプション管理画面に有効期限と残りトラフィックを表示します(業者がレスポンスヘッダーでこれらの情報を返している場合)。期限切れやトラフィック消費済みであれば、ノードは当然すべて使えなくなります。
- 手動でサブスクリプション更新を実行する:自動更新の周期に頼らず、手動で「サブスクリプション更新」を押すか対応するコマンドを実行し、新しいノードリストを正常に取得できるか確認します。更新に失敗しエラー(タイムアウト、403、404 など)が出る場合、サブスクリプションリンク自体にアクセスできない状態です。
- ノード数が急減していないか確認する:更新自体は成功しても、平常時よりノード数が明らかに減っている場合は、業者側でメンテナンス中か一部ノードが停止している可能性があります。まず他のノードに切り替えてテストしましょう。すべて失効したと決めつけるのは早計です。
サブスクリプションリンクにはアカウント認証情報が含まれています。無関係なツールやページに貼り付けてテストするのは避け、リンクの意図しない流出によるアカウント不正利用を防ぎましょう。
ステップ2:ローカル回線と DNS が正常かテストする
サブスクリプションの問題を排除したら、次はローカルの回線環境を確認します。ノード自体が完全に正常であっても、ローカル回線に異常があれば同様に「接続タイムアウト」として現れ、ノードの問題と誤判定されがちです。
まずプロキシを無効にして基本の回線をテストする
いったん Clash のシステムプロキシまたは TUN モードを無効にし、現在の回線でよく使う複数のサイトに直接アクセスしてみます。直接アクセスでもつながらない場合、問題はローカル回線そのもの(ルーター、ブロードバンド回線、プロバイダの制限)にあり、Clash の設定とは無関係です。まず基本的なネット接続の問題を解決する必要があります。
DNS 解決が正常か確認する
DNS 解決が失敗すると、ドメイン名を IP アドレスに変換できず、接続確立前の段階で止まってしまいます。これも見た目上は「タイムアウト」として現れます。コマンドラインツールで個別にテストできます:
nslookup example.com
ping 8.8.8.8ping で IP アドレスに通るのに nslookup でドメイン解決が失敗するか非常に時間がかかる場合、問題は DNS の段階に集中しています。Clash 設定ファイルの dns フィールドを確認し、リスニングポート、nameserver リスト、enhanced-mode(fake-ip や redir-host など)の設定が正しいか確認しましょう。必要に応じて公共 DNS サーバーに切り替えてテストします。
TUN モードが正常にトラフィックを引き受けているか確認する
TUN モードを使用している場合、仮想ネットワークアダプタが正しく作成されていない、あるいはルーティングテーブルが有効になっていないと、トラフィックが Clash の処理に入らず、クライアント画面上は「接続中」と表示されつつも常にタイムアウトします。システムのネットワーク設定に対応する仮想アダプタが表示されているか確認し、クライアントが管理者権限または root 権限で実行されているか確認しましょう(TUN モードは多くのシステムで権限の昇格に依存してネットワークインターフェースを作成します)。
直接接続は正常、DNS 解決も正常だが、プロキシを有効にすると依然アクセスできない場合、ローカル回線の問題はほぼ排除でき、プロトコルとポートの層に切り分けを移します。
ステップ3:プロトコルパラメータとポート設定を確認する
ローカル回線に問題がないことを確認したら、問題の範囲はノード設定自体に絞られます。プロトコルパラメータの誤り、ポートの不一致、暗号方式の不一致は、いずれもハンドシェイク段階でのタイムアウトを引き起こします——クライアントが接続要求を送信しても、サーバー側が識別できないか応答を拒否し、最終的に明確なエラーコードではなくタイムアウトという形で表れます。
重要フィールドを一つずつ確認する
| フィールド | よくある問題 | 確認方法 |
|---|---|---|
| server / port | サーバーアドレスやポートの入力ミス、業者側でのポート変更 | サブスクリプション元の設定と逐字比較し、余分な空白や全角文字がないか確認 |
| cipher / method | 暗号方式がサーバー側と一致していない | プロトコル仕様が要求する暗号アルゴリズムがローカル設定と一致しているか確認 |
| uuid / password | 認証情報のコピーが不完全、または期限切れ | サブスクリプションまたは業者の管理画面から完全なフィールドを再コピー |
| network / ws-path | トランスポート層設定(WebSocket パスなど)の欠落・誤り | パスや Host ヘッダーがサーバー側のリバースプロキシ規則と一致しているか確認 |
| skip-cert-verify | 証明書検証失敗による TLS ハンドシェイクの中断 | 証明書の有効性を確認し、テスト時は一時的に検証スキップを有効化して問題を特定 |
ログで具体的な失敗段階を特定する
ログレベルを debug に調整し、対象ノードに再接続して、ログがどの段階で途切れているか確認します:
- ログに TCP 接続確立の失敗が表示される場合、ポートの誤りかサーバーの停止である可能性が高い。
- TCP 確立は成功したが TLS ハンドシェイクが失敗する場合、証明書設定と SNI フィールドを確認する。
- ハンドシェイクは成功したがリクエストへの応答がない場合、プロトコルパラメータ(WebSocket パスなど)がサーバー側と一致していない可能性がある。
ログ内の具体的なエラー内容は、クライアント実行ログに関する解説と一つずつ照らし合わせることで、特定にかかる時間を大幅に短縮できます。
「ノード障害」と「ローカル設定の問題」を切り分ける判断基準
上記3段階の確認を終えたら、以下の基準で問題の性質を素早く分類できます:
- すべてのノードが同時にタイムアウトし、サブスクリプション更新が失敗またはトラフィックが消費済み —— サブスクリプション失効。業者に連絡するかサブスクリプションを乗り換える必要がある。
- 直接接続が不通、または DNS 解決に異常があり、プロキシの有無に関わらず結果が同じ —— ローカル回線の問題で、Clash とは無関係。
- 一部のノードは使えるが一部はタイムアウトし、直接接続と DNS はいずれも正常 —— 対応するノードのサーバー側障害である可能性が高く、他のノードに切り替えれば復旧する。
- 特定のノードが常にタイムアウトし、ログにハンドシェイクまたはパラメータ段階の失敗が表示される —— ローカル設定がサーバー側と一致していないため、プロトコルフィールドを確認する必要がある。
この分類に従うことで、「ノードがタイムアウトしたらサブスクリプションを全部再インポートする」や「設定に問題がなさそうならクライアントを何度も再起動する」といった非効率な対応を避け、本当の問題箇所に集中できます。
よくある誤判定のパターン
誤判定その1:DNS ポイズニングをノード障害と誤認する
一部の回線環境では DNS クエリがハイジャックまたはポイズニングされ、誤った IP アドレスが返されることで、接続要求が間違った宛先に送られタイムアウトとなります。この場合、ノードを切り替えても意味がなく、まず DNS 設定を修正し、fake-ip モードを有効にするか信頼できる DoH/DoT サーバーを指定するべきです。
誤判定その2:システムプロキシと TUN モードの競合を見落とす
一部のクライアントでシステムプロキシと TUN モードを同時に有効にすると、ルーティングの競合が発生し、トラフィックの流れが不安定になり、正常な時とタイムアウトする時が混在するといった症状になります。確認時はいずれか一方のトラフィック引き受け方式のみを有効にし、規則同士が競合しないようにしましょう。
誤判定その3:テストツール自体にキャッシュが残っている
ブラウザやシステムには DNS の結果や接続状態のキャッシュが残っており、設定変更後にキャッシュをクリアせずにテストすると、古い結果を得てしまいがちです。設定を調整するたびにクライアントを再起動し、コマンドラインツールで再テストすることをお勧めします。ブラウザの表示だけで判断するのは避けましょう。
固定の確認手順を身につけ、無駄な手間を減らす
ノード接続タイムアウトの問題は原因を一度に網羅的に整理するのが難しいものですが、確認する手順自体は固定しておくべきです:まずサブスクリプション自体が有効か確認し、次にローカル回線と DNS が正常か検証し、最後にプロトコルパラメータとポートを確認する。この順序のロジックは、影響範囲が最も大きく確認コストが最も低い段階から始め、徐々に具体的な設定の細部まで範囲を絞っていくというものです。大きな範囲の問題を排除せずに特定のノードのパラメータの細部にいきなり踏み込むことを避けられます。
サブスクリプションの更新時刻、よく使うテストコマンド(nslookup、ping など)を固定のチェックリストとしてまとめておき、接続トラブルが発生したらリストに沿って一つずつ実行することをお勧めします。当てずっぽうに試すのではなく、こうした方が長期的には毎回ゼロから調べ直すより時間の節約になり、自分の回線環境について正確な判断を積み重ねやすくなります。