Clash に繋がらない？ログで読む timeout と TLS エラー

画面は正常でも繋がらない：まずログを見る理由

「Clash に繋がらない」相談の多くは形が似ています。サブスクリプションは取り込める、プロファイルも読み込める、ノード一覧も長い——それでもページが開かない、動画が止まる、しばらくすると切れる。UI はしばしば 設定が存在するか だけを示し、実行時にどこで止まったか は示しません。コアは依然として名前解決・TCP 接続・トランスポートのハンドシェイク・ルールに沿った転送を行う必要があり、そのどれかが失敗しても画面は「一見正常」に見えることがあります。

クライアントログは、感覚と事実を分ける最短ルートです。接続がどの段階で止まったかが分かれば、ノードを変えるべきか、DNS 方針を直すべきか、TLS／SNI を疑うべきか、LAN 側の権限やセキュリティ製品を見るべきかが定まります。複数サーバーで同様の timeout が続く場合は、サブスクリプションとノードのメンテナンス とあわせて、恒久的な劣化と一時障害を区別すると判断が早くなります。

各クライアントでログを開く場所

メニュー名は製品ごとに違いますが、メンテされている Clash 系クライアントならどこかにログがあります。まずアプリ内コンソールを使うと、実行中のコアに合わせて既にフィルタされた出力が得られます。ハンドシェイクの細部が必要なときだけ一時的に debug や trace に上げ、終わったら info に戻してノイズを抑えます。複数製品を比較するなら、クロスプラットフォーム比較 で診断機能とカーネル更新の頻度も確認してください。ログの粒度はそのまま切り分けの速さに効きます。

フォーラムに貼るときはトークンやフルのプロキシ URL、個人ドメインは伏せます。タイムスタンプと行の順序は残してください。最初に失敗した行が、最後のエラー行より重要なことが多いです。「直近イベントのみコピー」に対応しているクライアントなら、巨大な履歴を貼らずに済みます。

timeout とコンテキスト期限切れの読み方

timeout は、許容時間内に応答が返らなかったことを意味します。表記はコアやトランスポートで違いますが、i/o timeout、止まったままの dial tcp、deadline exceeded、context deadline exceeded などが典型です。多くの場合ホストとポートが含まれ、ルーティング判断のあとソケット接続を試みた段階まで進んでいることが分かります。

解釈は文脈次第です。一つ のノードだけが timeout し他は動くなら、単一ノードの障害・輻輳・サブスクの不良行を疑います。地域を変える・プロバイダの差し替えを待つ・url-test があるなら活用します。すべて のノードが同時に timeout するなら「全サーバ同時ダウン」より、共通要因（ISP のポート制限、長寿命 TCP を抑えるゲスト Wi‑Fi、企業 FW、死んだプロキシ経由でサブスク更新だけが詰まるルールなど）を疑います。

特定サイトだけ timeout する場合は、QoS、地理経路、データセンター IP ブロックも候補です。失敗ドメインと成功ドメインを一つずつログで比較し、同じプロキシかも確認します。基礎接続が安定したあとのルール調整は ルールのベストプラクティス が参考になり、死んだノードのせいに誤認するのを防げます。

dial tcp 203.0.113.10:443: i/o timeout
proxy/DIRECT: connect failed: context deadline exceeded

TLS 失敗と証明書の手がかり

TCP は通るのに暗号層で失敗すると、ログは TLS 向けの語に変わります。tls: handshake failure、certificate の不一致、unknown authority、x509 検証、ClientHello 直後の EOF など。経路の一部は生きているがトンネルが確立／検証できない、という中間段の症状です。

まず端末の時刻ずれを再確認します。TLS の有効期限は厳しく、数分のズレでも紛らわしい証明書エラーになります。次に SNI（サーバ名表示） がノードの想定と一致するかを見ます。Trojan や TLS 上の VLESS では、証明書に出るホスト名とクライアントが送る名前が揃っている必要があります。表示名だけ変えて SNI が食い違うと、IP に届いても失敗します。

ログに MITM 機器・企業の SSL インスペクション・未知の CA と明示される場合は、Clash 単体の不具合ではなく経路上で TLS が終端されています。ネットワークを離れる、方針の範囲で信頼ルートを入れる、許可されたトランスポートに切り替える、といった対処になります。公共 Wi‑Fi だけで出るなら、ブラウザ認証前に DNS／HTTP が乗っ取られるキャプティブポータルを疑います。

DNS エラーがログに出るとき

接続は名前から始まるため、DNS の不調はプロキシ障害に見えがちです。lookup 失敗、no such host、NXDOMAIN、dial の 前 に出るリゾルバ timeout に注意します。プロキシのホスト名が解けない限り、ノードを替えても改善しません。OS DNS の汚染、トンネル未確立なのにリモート DNS へ流す設定、会社 VPN の split DNS などが典型です。

対処は段階的で、まず Clash を介さず同じ名前が解けるかを OS レベルで確認します。次にクライアントの DNS 設定やポリシーを変え、ブートストラップ問題（プロキシ自身のドメインを先に直解決する必要）を避けます。併せて DNS・接続に関する FAQ とプロバイダ資料を読むと、必須 DNS モードや禁止リゾルバの記載に気づけます。

プロキシサーバ名は解けるのに特定ドメインだけ失敗する場合は、ブロックリストやルールプロバイダが解決経路を誤って潰していないか、国内解決が要る特殊ドメインかを疑います。DIRECT でも失敗するかを比較し、DIRECT では解けるのに PROXY では解けないなら、トンネル内リゾルバと OS リゾルバの整合を取ります。

LAN・ファイアウォール・キャプティブポータル

permission denied、仮想アダプタ作成失敗、TUN の attach 反復エラーなどはローカル側のシグナルです。Windows のセキュリティ製品や「スマート」ルータ、学校ネットワークは仮想 NIC や透明モードを壊しがちです。TUN を有効にした直後なら、ノードを疑う前に TUN の前提条件 をプラットフォームごとに再確認してください。

ファイアウォールが Clash 本体やヘルパーサービスを止めているケースもあります。リモート IP が一度も出ない即死、ローカル bind エラーなどが手がかりです。スマホテザリングなど別物理回線で一時試験すると、ISP 要因と端末設定要因をすぐ分離できます。試験後は緩めた FW ルールを元に戻すのを忘れないでください。

そのまま使えるチェックリスト

ループしない順序です。各ステップで問題の「型」を一つずつ潰します。

1. 時刻・タイムゾーンを確認し、自動同期のずれを直す。
2. 安定した回線でサブスクリプションを更新し、無関係なノードを三つ試す。
3. ログの最初のエラーの塊を読み、DNS／dial／TLS のどれかを特定する。
4. 別の物理ネットワークで試し、ポート制限とキャプティブポータルを除外する。
5. モードを単純化し、TUN とポートプロキシを一時的に切り替えて層を特定する。
6. 既知の良ノード一つだけの最小プロファイルと比較し、ルール／プロバイダ破損を疑う。
7. 運用習慣を見直し、古いエンドポイントは更新・差し替えまで繰り返し timeout しがち、と心得る。

複数回線で一貫して TLS で終わるなら、伏せたログをプロバイダに渡し証明書やエッジ互換の確認を仰ぎます。常に DNS で終わるなら、暗号スイートをいじる前にリゾルバ方針を直します。

まとめ：感覚ではなくログで判断する

表面症状はいつも「読み込めない」に見えますが、裏では多くの場合 DNS → TCP → TLS の順に痕跡が残ります。その語彙を覚えると、プロファイルを何度入れ替えても同じ切り分けが使え、ルールを壊す無目的な変更を減らせます。

診断を隠すワンクリック製品に比べ、読めるログとメンテされた Meta 系コアをセットで使えるクライアントは、透明性と長期利用の両方に効きます。再インストールに費やす時間を減らし、自環境で本当に効いた一設定に集中できます。

→ ログで原因が見えたら、Clash を無料ダウンロードし、日々の運用も軽くしてみてください。