プロキシ使用時にHTTPS証明書エラーが出る原因:ノードの問題か端末設定か
ブラウザに NET::ERR_CERT_AUTHORITY_INVALID や「この接続ではプライバシーが保護されません」と表示されると、多くの人はまずプロキシをオフにしようとします。しかし証明書エラーの原因は、システム時刻・ノードの挙動・端末に残った証明書という3つの全く異なる層に分散しており、それぞれ対処法も異なります。本稿ではエラー種別ごとに切り分け方法を解説し、ノードを即停止すべき判断基準も示します。
まずエラー種別を見分ける
HTTPS証明書エラーは単一の問題ではなく、ブラウザが表示するエラーコード自体が最初の手がかりになります。プロキシを開始した直後に証明書エラーが出た場合、まずどの種類のエラーかを正確に確認してから調査方向を決めることで、無駄な作業を大幅に減らせます。
代表的なエラーコードの意味は次の通りです:
- NET::ERR_CERT_DATE_INVALID —— 証明書の有効期間の判定に失敗しています。通常は端末のシステム時刻やタイムゾーン設定の誤りが原因で、ノード自体とはあまり関係がありません。
- NET::ERR_CERT_AUTHORITY_INVALID —— 証明書の発行元が信頼されていません。最も警戒すべきパターンで、通信経路上で証明書が差し替えられている可能性があります。
- NET::ERR_CERT_COMMON_NAME_INVALID —— 証明書に記載されたドメインと実際にアクセスしたドメインが一致しません。ノードの振り分けルールの誤りにより、リクエストが別のサーバーに送られている場合によく見られます。
- NET::ERR_SSL_PROTOCOL_ERROR —— トランスポート層のハンドシェイクに失敗しています。ノードの切断、プロトコルの非互換、または中間機器による強制切断が考えられます。
Clash自体はトランスポート層で通信を転送するだけで、HTTPS証明書を能動的に復号したり再発行したりすることはありません。つまり、正常な設定でのノード転送であれば、サイト本来の証明書情報が変わることはないはずです。証明書の発行元・有効期間・フィンガープリントに変化があれば、原因は必ずノードの異常な挙動、または端末に別途インストールされた証明書にあり、Clashクライアントの通常機能によるものではありません。
システム時刻のズレ:最も見落とされやすい原因
HTTPS証明書には有効期間が設定されており、システムは現在時刻がその範囲内かどうかを検証します。時計のドリフト、電池交換、デュアルブート環境での起動時の不整合などで端末の時刻が実際の時刻からズレていると、ほぼすべてのサイトの証明書が「まだ有効になっていない」または「期限切れ」と判定されてしまいます。証明書自体は正常であっても発生します。
この種の問題の典型的な特徴は、複数の異なるサイトで同時にエラーが発生することです。プロキシのオン・オフとは関係なく起こりますが、プロキシを使い始めてからアクセスするサイトが増えるため、プロキシが原因だと誤解されやすいのです。判別方法は簡単です:
システム時刻とタイムゾーンを確認する
システムの時刻設定を開き、「自動的に時刻を設定する」や「インターネット時刻と同期する」が有効になっているか、タイムゾーンが実際の地域と一致しているかを確認します。仮想マシンやデュアルブート環境では時刻が上書きされやすいので特に注意が必要です。
プロキシを切って単独検証する
一時的にClashをオフにし、信頼できるサイトを1つ開いて証明書エラーが出るか確認します。プロキシをオフにしても問題が残る場合、プロキシとは無関係で、システム時刻が原因だとほぼ確定できます。
時刻同期後にキャッシュを消す
時刻を修正した後、ブラウザのHSTSキャッシュや証明書の透明性ログキャッシュ(ブラウザによってパスが異なります)をクリアし、以前の誤った判定結果が再利用されるのを防ぎます。
時刻のズレによるエラーはノードとは無関係で、ノードの変更やクライアントの再インストールは不要です。システム時刻を修正すれば解決します。
ノードによる中間者攻撃:即刻停止すべきサイン
プロキシをオフにすると証明書が完全に正常で、ある特定のノードを使ったときだけ NET::ERR_CERT_AUTHORITY_INVALID が出る場合、その経路上で中間者(MITM)行為が行われている可能性が高いです。つまり中継ノードが暗号化された通信を単純に転送するのではなく、TLS接続を傍受して自前の証明書で再発行し、それを本来のサイトへ転送しているという状態です。
これは正常なプロキシ転送では起こらない挙動です。該当するかどうかは、ブラウザに表示される証明書の詳細情報で確認できます:
- 発行元が不自然——正規サイトの証明書は通常Let's Encrypt、DigiCert、GlobalSignなど広く認知されたCAから発行されます。発行元が見知らぬ名称や自己署名になっている場合は、経路が傍受されている可能性を強く疑うべきです。
- 有効期間が極端に短い——一部の中間者証明書は実行時に動的生成されるため、有効期間がわずか数日、数時間ということもあります。対象サイトの公式証明書は通常1年以上の有効期間があるため、明らかに矛盾します。
- 特定のノードでのみ再現する——同じサブスクリプション内の別のノードに切り替えるとエラーが消える場合、問題はその特定のノードや中継サーバーにあり、端末側やサブスクリプション全体の問題ではないことがわかります。
あるノードで証明書が差し替えられていることを確認したら、そのノードを即刻停止してください。アカウントログイン、決済、本人確認が関わるサイトへのアクセスに使い続けてはいけません。中間者ノードは通信を復号して平文を読み取る能力を持っており、使い続けることは機密情報をそのノードの運営者に晒すことと同じです。該当ノードのサブスクリプション提供元が信頼できるかも併せて確認し、必要であればサブスクリプションを変更することをお勧めします。
補足として、この種の傍受行為は「有料」か「無料」かとは直接関係ありません。出所不明の無料ノードのリスクは高い傾向にありますが、すべての無料ノードにこの問題があるとは限らないという逆の思い込みも避けるべきです。判断基準は常に証明書の詳細情報そのものであり、ノードの価格帯ではありません。
残存したパケットキャプチャ証明書:忘れられがちな第三の可能性
もう一つ見落とされやすい原因があります。以前、パケットキャプチャや通信解析のために端末に証明書をインストールしたことがある場合(一部の通信解析ツールはHTTPS通信を復号するために独自のCA証明書のインストールを要求します)、調査終了後に完全に削除していないと、その証明書がシステムやブラウザの信頼リストに残り続けます。
この種の残存証明書自体が能動的に悪さをすることはありませんが、次の2つの典型的な問題を引き起こします:
- その証明書に対応する秘密鍵が不適切に保管されたり漏洩したりしている場合、悪用されるリスクが理論上存在し、ブラウザがセキュリティポリシー上、その証明書チェーンを使った接続に警告を出すことがあります。
- 一部のシステムレベルの通信解析ツールが異常終了した際、設定したシステムプロキシや証明書の信頼状態を正しくクリーンアップしないことがあります。その後Clashのノードを有効にすると、2つの証明書信頼機構が競合し、証明書チェーンを検証できないというエラーが発生します。
確認方法は、システムとブラウザの証明書管理画面を開き、あまり知られていないCAから発行され、かつインストール日時が過去のパケットキャプチャ調査の時期と一致する証明書がないか探すことです:
- Windows:
certmgr.mscを実行し、「信頼されたルート証明機関」の一覧を確認して、見慣れない名称やインストール日が不自然な項目に注意します。 - macOS:「キーチェーンアクセス」を開き、「システム」または「ログイン」カテゴリで証明書の信頼設定を確認し、「常に信頼」に設定された非標準の証明書を探します。
- ブラウザ内蔵の証明書管理:Chrome、Edgeなどのブラウザには独立した証明書管理画面があり、システムレベルの証明書リストとは別に管理されています。両方を確認する必要があります。
不要な調査用証明書を確認したら、単に「信頼しない」に設定するのではなく、直接削除してください。一部のシステムでは証明書が残存したまま信頼しない設定にすると、検証プロセスの一部であいまいなエラー表示が続くことがあります。
切り分け手順と対処のタイミング
3つの原因はそれぞれ調査コストとリスクレベルが大きく異なります。以下の順序で切り分けを行うことで、いきなりノードを疑って何度も切り替えるだけで根本原因を解決できない状態を避けられます。
まずシステム時刻を確認する
コストが最も低く、追加ツールも不要で、1分以内に確認・除外できます。
プロキシをオフにして再現確認
エラーがプロキシのオン・オフ状態と連動しているかを確認します。「端末環境の問題」と「経路の問題」を区別する重要な分岐点です。
ノードを切り替えて相互検証
プロキシを有効にしたときだけエラーが出る場合、同じサブスクリプション内の別のノードに切り替えて、問題が特定のノードに追従するのか、それともすべてのノードで発生するのかを確認します。
証明書詳細と端末の証明書リストを確認する
問題が特定のノードに追従する場合は、そのサイトの証明書の発行元と有効期間に異常がないか確認します。すべてのノードで問題が発生する場合は、端末に残った古い調査用証明書の有無を確認します。
TUNモードについて補足します。TUNモードを有効にすると、システムレベルの通信の取り扱い方が変化するため、一部のセキュリティソフトやシステムのファイアウォールが追加の証明書検証ポリシーを発動することがあります。これはシステムの互換性の問題であり、ノードの安全性とは無関係です。TUNモード使用時のみ証明書エラーが出て、通常のシステムプロキシモードでは正常な場合は、一時的にTUNモードをオフにして問題範囲を特定し、その上でクライアントのネットワークアダプタ設定を調整するかどうかを判断してください。
ノードを即刻停止すべきかどうかの判断基準は簡単です:プロキシをオフにするとエラーが消え、特定のノードでのみ再現し、かつ証明書の発行元や有効期間に明らかな異常がある——この3条件が揃った場合のみ、ノードを停止すべき強いサインとなります。システム時刻がズレているだけ、あるいは調査用証明書が残っているだけでは、現在使用中のノードにセキュリティ上の問題があるとは限りません。
最後に、良い習慣として次の点をおすすめします:サブスクリプションを変更したり、見知らぬ提供元のノードを追加した後は、まず機密性の低いサイトで証明書が正常かテストしてから、アカウントや決済に関わる操作を行うことで、リスクを最小限に抑えられます。