Clash で TLS ハンドシェイクに失敗する場合は？証明書、時刻、SNI の確認手順

証明書エラー、システム時刻のずれ、SNI の設定ミスはいずれも TLS ハンドシェイク失敗として表示されますが、対処方法はまったく異なります。まずログにある原文全体をコピーし、エラーがサブスクリプションのダウンロード、プロキシノードとのハンドシェイク、対象 Web サイトを開く処理のどこで発生したかを確認してください。この二点を特定して初めて、時刻、証明書チェーン、ノードのフィールドのどれを調べるべきか判断できます。

エラーの前後数行をコピーし、時刻、対象ドメイン、ポートは残したまま、サブスクリプションの token、UUID、パスワードを伏せます。「TLS failed」だけを切り取ると、原因の判別に必要な部分が失われます。

まず簡単な比較を行います。既存のノードでほかの HTTPS サイトへアクセスできるか、サブスクリプションを手動更新できるかを確認してください。この二つの結果を組み合わせれば、通常はハンドシェイクがどの区間で失敗したかを判断できます。

証明書には Not Before と Not After があります。デュアルブートの切り替え、仮想マシンのスナップショット、長期間電源を切っていた OpenWrt、自動時刻合わせの無効化によって、時刻がずれることがあります。日付、タイムゾーン、NTP 同期を直した後、Mihomo を再起動してもう一度再現してください。エラーがまったく同じ場合に限り、ハンドシェイクのフィールドを引き続き確認します。

TLS ノードの接続先となる server が IP で、証明書はドメイン向けに発行されている場合があります。この場合、通常は正しい servername または sni を設定する必要があります。値はサーバー側の設定に基づく必要があり、インターネット上でよく見かけるドメインを推測で指定してはいけません。ポート、転送方式、ALPN、Reality public-key/short-id などのフィールドも、一式を正しく対応させる必要があります。

openssl の出力では、subject、issuer、有効期間、Verify return code を確認します。-servername の有無で異なる証明書が返るなら、サーバー側が SNI に依存しています。スマートフォンのテザリングでは正常な証明書が返り、社内ネットワークでは企業 CA に変わる場合は、SSL 検査または中間ゲートウェイが存在します。

プロキシプロトコルのポートが通常の HTTPS ページを提供するとは限らないため、curl の失敗だけでノードの故障とは判断できません。openssl が示す証明書とハンドシェイク情報のほうが有用です。Reality などのプロトコルも通常の Web サイト証明書と同じ項目で判断せず、対応するプロトコルのドキュメントを確認してください。

企業プロキシ、セキュリティゲートウェイ、一部のウイルス対策ソフトは、HTTPS 証明書を再発行します。管理対象端末では、管理者が組織の CA をインストールし、検査を許可する通信の範囲を説明する必要があります。個人の判断でエラーページから見覚えのないルート証明書をダウンロードしたり、Clash の更新を成功させるためにシステム全体の証明書検証を無効にしたりしないでください。

スマートフォンのテザリングへ切り替えると同じサブスクリプション URL がすぐ正常になる場合は、ネットワーク経路の違いを示す証拠になります。社内ネットワークで確認した issuer、エラー時刻、対象ドメインを管理者へ伝えるほうが、ノードを次々に切り替えるより有効です。

「ほかのサイトも開ける」だけで検証を済ませないでください。最初にエラーが出たサブスクリプション、ノード、対象 Web サイトへ戻り、同じネットワークでもう一度試して、ログから元のエラーが消えたことを確認します。