一、TLS 握手タイムアウトが意味すること
HTTPS では、TCP が張れたあとにクライアントが Client Hello を送り、サーバが Server Hello と証明書チェーンを返すまでが「TLS 握手」の前半です。ここで応答が返ってこない、途中で黙る、別大陸の遅い経路で限界を超えると、ライブラリやコアはしばしば TLS Handshake Timeout、i/o timeout、context deadline exceeded などに近い表現で落ちます。Clash 系ではプロキシ経由の外向き TCP で握っていることが多いので、ログ上は「その接続がどのプロキシ（ノード）グループに載っていたか」とセットで読むのが近道です。
重要なのは、握手以前の DNS が既に破綻している場合も、見た目は同じタイムアウトに寄ることがある点です。名前解決が遅い・汚染されている・fake-ip と実アドレスの境界でアプリが迷うと、TLS に入る前から待ちが伸びます。逆に、DNS は正常でもノード側が 443 をドロップしていたり、SNI が期待と違うサーバに刺さっていると、やはり握手で詰まります。だからこそ「一度に全部いじる」のではなく、ノード → SNI／証明書 → スニッファ → ルール → DNSの順で仮説を置くと手戻りが減ります。
二、ログで押さえるべき行（ホスト・ノード・ルール）
まずログからホスト名（または復元されたドメイン）、実際に使われたプロキシ名、可能ならどのルールにマッチしたかの三点を抜き出します。ブラウザのアドレスバーに見えているドメインと、ログのホストがズレているときは、静的 CDN・API サブドメイン・ログインリダイレクトが別ホストになっている典型です。ここを取り違えると「メインサイトは通るのにログだけ落ちる」などの説明がつきません。
GUI によっては接続履歴に Policy や Rule の列があります。そこで DIRECT になっているのにブラウザはプロキシ前提で動いている、あるいは逆に REJECT 系に落ちているのに気づかないと、TLS の前で詰まっているのか後で詰まっているのかが混線します。fake-ip と DNS の切り分け記事と同様、名前解決のログとプロキシ接続のログを時間軸で対応づける癖をつけると長期的に楽になります。
よくあるログの読み取り例（表記はコアにより異なります）
- 同一ホストでノード A は失敗・ノード B は成功 → まずノード品質／地域／プロトコル（TLS フィンガプリント遮断など）を疑う。
- どのノードでも同じホストだけ失敗 → SNI・証明書ピンニング・CDN のエッジ選択、スニッファの誤検知を疑う。
- Wi-Fi では失敗・モバイル回線では成功 → ISP のブロックより、ローカル DNS や企業プロキシとの二重化を疑う。
三、ステップ 1：ノード品質とレイテンシ
最も単純で、かつ最初に潰すべき仮説が「出口が遅い・不安定・443 を落とす」です。クライアント付属の遅延テストやTCPing的なチェックで、問題ホストに近い地域のノードへ切り替えたときに握手が通るかを見ます。ここで改善するなら、ルールや DNS をいじる前にプロファイルのノード集合を見直す方が費用対効果が高いです。
複数アプリが同時に流れる環境では、帯域ではなくパケット損失やバッファブロートで握手が間に合わないこともあります。測定値がギリギリのノードを「遅延が低いから」で固定すると、ピーク時だけ TLS Handshake Timeout が出る、というパターンになりがちです。安定性を優先して別ノードへ寄せる、もしくは自動選択（URL Test）の閾値とフォールバック先を現実的な値に直すと再現が止まることがあります。
なお、TUN モードと併用している場合は、そもそもトラフィックが意図せず迂回していないかを先に確認してください。TUN・ルート・ファイアウォールの記事で述べたとおり、ループや除外漏れがあると「ノードのせい」に見える切断が出ます。TUN が健全なら、本節のノード切り分けに進むのが筋です。
四、ステップ 2：SNI・証明書・誤ったサーバ
TLS の Client Hello には SNI（Server Name Indication） が含まれ、サーバはそれに応じて証明書を選びます。プロキシや中間機器が別ホスト向けの証明書を返している、透明キャッシュが古い証明書を返している、あるいはドメインの取り違えで全然違うバーチャルホストに刺さっていると、クライアントは検証で止まるか、タイムアウトまで待ち続けます。Clash 側ではなくブラウザの開発者ツールや openssl s_client -servername example.com -connect host:443 などで、証明書の CN／SANが期待と一致するかを別経路から確認すると早いです。
一部の地域では、特定の SNI を含む接続が中間でリセットされ、結果として握手タイムアウトに見えることがあります。この場合は「証明書がおかしい」より到達性と検閲の問題に近いので、ノードの地理位置とプロトコル（TLS 1.3 の有無）を変えて比較します。同じサイトでもパスによって別ドメインになるケース（画像 CDN、API、WebSocket）では、ログに出るホストごとにこの確認を繰り返してください。
五、ステップ 3：スニッファと嗅探の副作用
スニッファ（sniffer）は、暗号化されたトラフィックから TLS の Client Hello などを解析してドメイン名を復元し、ルールやログを実用的にするための機能です。一方で、対象を広げすぎると、特定実装の TLS と相性が悪く接続が不安定化したり、復元結果が実際の SNI と食い違うことで誤ったポリシーに載ることがあります。握手周りの不調が出たら、(1) ログでスニッファ経由の表示があるか、(2) 対象ポートを 443 など必要最小限に狭める、(3) 短時間オフで対照、の順が安全です。
fake-ip とスニッファを同時に強く効かせるプロファイルでは、境界条件で「名前は合っているのに実体の経路がズレる」ことがあります。fake-ip／filter の記事で触れた fake-ip-filter の補完と合わせて見ると、スニッファを狭めたうえで安定する例がよくあります。嗅探は便利なので丸ごと無効化より、まず範囲の絞り込みを検討するのが運用では現実的です。
六、ステップ 4：ルール命中と意図しない DIRECT／REJECT
ルールは「最終的にどのプロキシに流すか」を決めますが、ここがズレると遅い経路や遮断に乗り、結果として握手が終わらないことがあります。特に GEOIP や巨大な geosite マージでは、意図しない早期マッチが起きやすいです。ログの rule match 行を見て、問題ホストが本当に想定の PROXY グループに入っているかを確認してください。
DIRECT に落ちているのに、ブラウザや OS はプロキシ前提で名前解決している、といった二重経路も典型的です。逆に REJECT 系や広告ブロックのドメインリストに誤って同一サフィックスが入っていると、TLS 以前で切れるはずが、クライアント表示や中間層の組み合わせでタイムアウトに見えることがあります。ルールを直すときは一行ずつ変え、毎回ログで命中を確認する癖をつけると安全です。
| ログや挙動の手がかり | まず疑う層 |
|---|---|
| ノードを変えるとすぐ直る | 出口品質、地域ブロック、輻輳 |
| 証明書警告や別ドメインの CN | SNI、CDN の取り違え、キャッシュ |
| スニッファ ON 時だけ不安定 | 嗅探範囲、TLS 実装との相性 |
| 命中ルールが DIRECT／REJECT | ルール順序、リスト誤爆、GEOIP |
| fake-ip や DNS 変更で変化 | 名前解決チェーン、filter 漏れ |
七、ステップ 5：ローカル DNS と fake-ip
ローカルで動いている Clash の dns セクションは、アプリが OS リゾルバを通じて問い合わせた結果と、コア内部の解決が別物になり得ます。特に enhanced-mode: fake-ip では、ブラウザが一度受け取ったアドレスと、実際に外向き接続で使う経路の間に時間差と変換が入ります。ここで詰まると、表向きは TLS のタイムアウトとして現れます。対照として redir-host に一時切替し症状が消えるなら、fake-ip-filter と DNS 上流を集中的に見直してください。
nameserver と fallback、nameserver-policy の優先順位が過剰に複雑だと、特定回線だけ解決が遅延し、その後の TLS まで連鎖してタイムアウトに見えることがあります。企業 LAN では DoH ドメイン自体がブロックされ、フォールバックが発火しないまま待ち続ける、というパターンもあります。上流 DNS を一つずつ切り替えて比較し、改善する組み合わせを残すのが確実です。
最後に、OS やブラウザの「セキュア DNS」、他社 VPN、フィルタリングソフトが二重に DNS を握っていないかも確認してください。Clash だけ整えても、上位で別解決が走っているとログが読みにくくなります。
八、まとめ
Clash のログに TLS Handshake Timeout が出たときは、すぐに設定全体を捨てず、ノードの実測 → SNI／証明書の妥当性 → スニッファの範囲 → ルール命中 → DNS／fake-ipの順で仮説を置くと、原因の層が素早く絞れます。典型エラー文字列は検索に強く、同じ語で辿り着く読者も多いので、自分用に「そのとき見たホスト名・命中ルール・切替で直った要因」をメモしておくと次回が楽になります。
クライアントの基本構成やテンプレの読み方は ドキュメントから確認できます。ログの出し方は GUI ごとに差があるため、まずは接続イベントが一行で追える表示に整えると、本稿の順序どおりの切り分けがしやすくなります。
Clash 系はルール・DNS・モードの組み合わせを文書化しやすく、一度読む順番を身につけると、断続的な不調でもパニックせずに戻せるようになります。他ツールに比べ、設定の見通しとログの対応づけがしやすい点は、長期運用の安心材料になります。