まず押さえる：TLS失敗と「ただの遅い」の見分け
TLS 握手 は、TCP が張れたあとに暗号スイートと証明書を交換してセッション鍵を合意する段階です。ここで落ちると、ログには tls・handshake・x509・certificate などの語が出やすく、アプリ側では「接続がリセットされた」「証明書が信頼できない」「タイムアウト」といった幅広い文言に化けます。一方、単なる経路遅延やDNSの失敗では、先に名前解決やTCPのタイムアウトで止まることが多く、メッセージのニュアンスが変わります。
そのため「テストは緑でも実利用はダメ」は、必ずしも矛盾ではありません。テスト用URLが軽量で、実トラフィックが別リージョンのCDNやHTTP/3を使う場合、見かけだけ健全に見えます。まずクライアントのログレベルを上げ、握手失敗 がプロキシ↔上流の間なのか、クライアント↔プロキシの間なのかを切り分けてください。DNS モードの話は Fake-IP と Redir-Host の解説 と役割が分かれます。購読URLそのものの更新失敗は 購読の自動更新チェックリスト を参照してください。
ステップ1：証明書チェーンとOSの信頼ストアを疑う
サーバー証明書はルートCAまで繋がったチェーンで提示される必要があります。中間証明書が欠けていると、一部のクライアントでは偶然通っても、Clash の検証実装やOSのストアでは 握手失敗 になります。ブラウザで同じホストを開いて鍵アイコンからチェーンを確認する、openssl s_client 相当の外部チェッカーを使う、といった別経路の確認が有効です。
次に端末側です。古い端末・社用機・カスタムROMではシステムの信頼ストアが古く、新しいルートに追従していないことがあります。日付・時刻が大きくずれていると、証明書の有効期限検証でも落ちます。企業ネットワークのHTTPSインスペクション（自社ルートを注入）では、個人用途のノード検証と衝突しやすいので、別回線で再現するか、信頼できる端末だけに絞って試してください。
切り分けのため一時的に skip-cert-verify を試す手はありますが、恒常運用はセキュリティ上おすすめできません。原因がチェーン欠落かSNIかを特定したら、早めに元に戻す前提で使ってください。
ステップ2：SNI（Server Name Indication）と接続名の一致
TLSでは接続先IPに対して、クライアントが拡張で提示するホスト名が SNI です。ここが証明書のコモンネーム／SANと一致しないと、サーバーは正しい証明書を選べず、クライアントは検証で失敗します。サブスクリプション由来の設定では、server や servername、sni、実際のTLSで見える名前がバラバラになっている例があります。
特にCDNやワイルドカード証明書の手前で、エッジの名前とオリジン用の名前が分かれている構成では、プロバイダが指定する「TLSで使うべきホスト名」に合わせる必要があります。手元で値をいじる場合は、公式例やサポート情報と突き合わせ、推測で別名を入れない方が安全です。ALPN（h2／http/1.1）の不一致が原因で落ちるケースはTLSより上位層に見えますが、ログの出方は近いことがあり、併せて確認すると早いです。
ステップ3：分アプリ代理と「対象外」のすれ違い
分アプリ代理（アプリ単位でプロキシ対象を絞る機能）は、省電力や銀行アプリの意図的な直結と相性がよい一方、検証中にだけトラフィックがトンネル外に逃げると、ログと体感がかみ合わなくなります。まずは全体プロキシや TUN で再現性が変わるかを見てください。TUN の基礎は Windows 11／macOS の TUN 解説 が参考になります。
Android では Clash for Android のDNS・分アプリ稿 と症状が重なることがあります。ブラウザ拡張が独自プロキシを握っている、別のVPNが競合している場合も同様に、Clashのルール以前の問題として表出します。切り分けの基本は「一度シンプルな構成に落とす」ことです。
ステップ4：スニッファー（嗅探）とルールの相互作用
Meta系ではTLSのClientHelloからドメインを推定し、ルールマッチを早める スニッファー 系の設定があります。便利な反面、誤推定や競合するスニッファー設定があると、意図しないポリシーに流れて別出口の証明書を見に行き、結果として 握手失敗 に見えることがあります。変更直後だけ不調が出る場合は、一旦スニッファーをオフに近い状態へ戻し、再現が消えるかを見ます。
ここは「嗅探を完全否定」ではなく、ログ上どのドメインにマッチしたかと、実際の接続先SNIが一致しているかを突き合わせる作業です。複雑化したら、まずはルールをシンプルにしてプロバイダ既定のプロファイルに近づけると、変数が減って原因が見えやすくなります。
ステップ5：UDP・QUIC・ノードtimeoutとの切り分け
TLSの問題と混同されやすいのが UDP 経路です。HTTP/3やQUIC、ゲーム・音声RTCはUDPに依存します。プロファイルやルールでUDPが意図せず直結・別ノードに流れていると、「TCPのテストは成功」「アプリだけ失敗」に見えます。ログにQUICやUDPドロップが出ていないか、TUNとシステムプロキシの組み合わせで挙動が変わるかを確認してください。ボイス向けの切り分けは Discord 音声とUDPの稿 が補助線になります。
また ノードタイムアウト はTLS以前のレイヤで起きます。高遅延やパケットロス、サーバーメンテ、ローカル防火壁の遮断が典型です。pingやICMPが通っても、TCP 443が閉じている環境ではテストと実通信が分岐します。出口でプロバイダがTLSフィンガープリンティングをしている場合も、握手前後で切断されることがあり、ログの文言はTLSに寄ります。最後に、ルール順で意図しない DIRECT 落ちしていないか、GEOIPやDOMAINの取りこぼしがないかを見直すと、見えない経路のずれが解けます。
チェックリスト早見表
| 症状の手がかり | まず見る場所 |
|---|---|
| 証明書／x509／unknown authority | チェーン欠落、OSストア、時刻、企業インスペクション |
| wrong host／name mismatch | SNI、servername、サブスクのホスト表記 |
| アプリだけ不通 | 分アプリ代理、ブラウザ拡張、別VPN、TUNの有無 |
| ルールとログの域名が食い違う | スニッファー設定、RULE順、プロファイルの簡素化 |
| HTTP/3やRTCだけ落ちる | UDPの扱い、TUN、ノードのUDP対応、防火壁 |
この表は「どのログ行を読めばよいか」の入口です。実際の運用では、問題が出たアプリのドメインを一つ決め、同じドメインでcurlやブラウザ、Clashのログを突き合わせると早く収束します。
よくある質問
遅延テストは通るのにTLS握手だけ失敗するのはなぜですか？
テスト対象のホスト／プロトコルと、実アプリが使うホスト／プロトコルが一致していないことが多いです。HTTP/3や別リージョンCDN、証明書が異なるミラーを踏むと、テストは成功しても本番だけ落ちます。ログで実際の接続先SNIと証明書エラーを確認してください。
skip-cert-verifyを有効にしてよいですか？
原因切り分けの短期利用にとどめ、原因が分かったら無効化することを強く推奨します。恒常的な無効化は、悪意ある出口に対する防御を失います。
SNIには何を入れるべきですか？
その接続で提示される証明書がカバーするホスト名に合わせます。サブスクリプションのIPとドメインが分離されている構成では、プロバイダ指定のservernameに揃えるのが安全です。
分アプリ代理を使っているとTLSエラーが増えますか？
エラーそのものが増えるというより、対象外アプリが別経路になりログと体感がずれます。全体適用で再現が消えるなら、適用リストの見直しが近道です。
まとめ
Clash で TLS 握手 や handshake timeout が出るとき、最初からサブスクやノード品質だけを疑うより、証明書チェーン・SNI・分アプリ代理・スニッファー・UDP／TUN を順に潰すと迷子になりにくいです。本稿の5手順は、特定サービス名に依存しない汎用の切り分け枠として使えます。YAMLの詳細な分流設計は ルール分流ガイド と併読すると、ルール順と証明書問題を同時に整理しやすくなります。
クライアントの入手と更新、購読リンクの管理は、公式配布に加えて自分の端末群で揃えやすい導線があると安心です。
ほかのチュートリアルは 技術コラム からどうぞ。