プロキシ利用時に HTTPS 証明書エラーが表示される?よくある原因と Clash 関連の切り分け手順

証明書エラーの種類と意味

ブラウザが表示する証明書エラーは種類が多く見えますが、実際にはいくつかの方向に整理できます。証明書が信頼されていない(NET::ERR_CERT_AUTHORITY_INVALID)、証明書の期限切れまたは未発効(NET::ERR_CERT_DATE_INVALID)、ドメイン不一致(NET::ERR_CERT_COMMON_NAME_INVALID)、そして通信のハイジャックに関連する汎用警告です。これらの表示自体は、ブラウザが本来やるべき仕事——TLS ハンドシェイク時にサーバー証明書チェーンの信頼性、有効期限、アクセス先ドメインとの一致を検証すること——をしているだけです。プロキシを使う前は出ず、使った後に頻発するなら、問題は端末側の時刻、DNS 解決経路、または証明書の信頼チェーンにある可能性が高く、アクセス先サイト自体の障害ではないとほぼ確定できます。

切り分けの際はまず次の点を明確に記録してください。すべてのサイトでエラーが出るのか、一部のサイトだけなのか。すべてのノードでエラーが出るのか、ノードを切り替えると消えるのか。プロキシをオフにすると即座に直るのか、オフにしても直らないのか。この3つの対比で、問題がシステム層、プロキシ層、ローカルソフト層のどこにあるかを一気に絞り込めます。

システム時刻のズレによる証明書エラー

TLS 証明書の検証では、現在のシステム時刻が証明書の有効期間内かどうかをチェックします。端末の時刻が実際の時刻から数分以上ズレていると、証明書自体は完全に正常でも「まだ有効になっていない」または「期限切れ」と判定される場合があります。これは仮想マシン、デュアルブート環境、長期スリープからの復帰後の端末で特に起こりやすく、プロキシの利用有無とは直接関係ありませんが、ノードの切り替えやクライアントの再起動をしたタイミングで初めて気づかれることが多く、ノードの問題と誤認されがちです。

1. システム時刻の自動同期を確認

   Windows では「設定 → 時刻と言語」で「時刻を自動的に設定する」がオンになっているか確認します。macOS では「システム設定 → 一般 → 日付と時刻」で自動設定にチェックが入っているか確認します。

2. タイムゾーンを手動で確認

   時刻同期がオンでもタイムゾーンの選択が間違っていると、同様に証明書の有効期間判定にズレが生じます。地域設定を変更したばかりの端末では特に注意が必要です。

3. 強制的に再同期する

   自動同期をオフにして再度オンにするか、システムの時刻サービスで手動同期を実行し、端末の時刻をネットワークタイムサーバーに即座に合わせます。

ノードのハイジャックと中間者攻撃のリスク

特定のノードに切り替えたときだけ証明書エラーが発生し、別のノードに変えるとすぐ正常に戻る場合、このシグナルは軽視せず注意深く扱う必要があります。正常なプロキシ転送は TLS ハンドシェイクの過程に介入しません。クライアントとアクセス先サイトの間にはエンドツーエンドの暗号化通信が確立され、中間のプロキシサーバーは暗号化済みのパケットを転送するだけで、理論上は証明書を確認したり差し替えたりする能力も必要もありません。あるノードの出口が通信レベルで中間者的な干渉を行っている場合——例えば自己署名証明書を挿入して通信を復号しようとしている場合——ブラウザは即座に証明書の信頼エラーを報告します。提示された証明書の発行者が、システムの信頼済みルート証明書リストにまったく存在しないためです。

このような事例は、出所不明で異常に安い無料ノードや、審査を経ていない第三者共有ノードで多く見られ、信頼できる正規サービスのノードではほとんど発生しません。切り分け方法は明快です。

• エラーが発生したときに使用していたノード名を記録し、同じサブスクリプション内の別のノードに切り替えて再現するか確認します。
• エラー詳細に表示された証明書の発行者を確認します(ブラウザのアドレスバーの鍵アイコン → 証明書情報)。発行者が見覚えのない自作 CA で、そのサイトが本来使っている有名な証明機関ではない場合、ノード側での中間者的な挙動があるとほぼ確定できます。
• 問題のあるノードを特定したら、クライアントの選択グループから除外し、信頼できるサブスクリプションに切り替えます。

TUN モードにおける DNS 汚染フォールバック問題

TUN モードはシステムのすべてのネットワーク通信、DNS 問い合わせも含めて引き継ぎます。Clash Meta(mihomo)コアは TUN モードでは通常、独自の DNS 解決ロジックを有効化し、暗号化 DNS(DoH/DoT など)を優先しつつ、fake-ip や redir-host 方式を組み合わせて、ローカルネットワークの DNS ハイジャックによる汚染を回避しようとします。しかし設定に漏れがあると——例えば enhanced-mode が正しく有効化されていない、あるいは nameserver のリストに汚染されやすい通常の DNS サーバーが混入している場合——TUN モードでの解決が失敗した際にシステムが密かに端末デフォルトの DNS にフォールバックしてしまうことがあります。端末デフォルトの DNS が汚染されたネットワーク環境下にある場合、解決される IP が誤ったサーバーを指してしまい、そのサーバーは当然対象ドメインに一致する正規の証明書を提示できないため、ブラウザはドメイン不一致や証明書の信頼エラーを報告します。

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://doh.example.net/dns-query
    - https://1.1.1.1/dns-query
  fallback:
    - https://dns.google/dns-query
tun:
  enable: true
  stack: system
  dns-hijack:
    - any:53

設定を確認する際は次の3点に注目してください。enhanced-mode が fake-ip(または利用シーンによっては redir-host)に設定されているか、nameserver がすべて暗号化 DNS で平文の udp:// アドレスになっていないか、dns-hijack が 53 番ポートをカバーしていて、すべての DNS リクエストがクライアントの解決ロジックに強制的に渡されるようになっているか。いずれか一つでも欠けていると、特定のネットワーク環境で信頼できない経路にフォールバックする可能性があります。

ローカルパケットキャプチャソフトの残存証明書

見落とされがちなもう一つの原因は、端末に以前インストールされていたデバッグ用プロキシやパケットキャプチャツールです。これらのツールは HTTPS 通信を復号して解析するために、自己署名のルート証明書を生成し、システムの信頼リストへ手動で登録するようユーザーに求めるのが一般的です。そうすることで、途中で「正当に」中間者として振る舞えるようになります。ツールをアンインストールする際にこの証明書を一緒に削除しなかったり、証明書が期限切れになっても信頼リストに残ったままだったりすると、その後プロキシを使う際に一部の通信経路が偶然その残存設定を経由してしまい、証明書警告が発生します。ブラウザ上の表示は本物の中間者ハイジャックとほぼ同じため、ノードの問題と誤認しやすい点に注意が必要です。

1. システムの証明書信頼リストを確認

   Windows では「証明書マネージャー」(certmgr.msc)で「信頼されたルート証明機関」を確認します。macOS では「キーチェーンアクセス」でログインおよびシステム証明書を確認し、デバッグツール名を含む自己署名エントリを探します。

2. 疑わしい証明書を削除または無効化

   ある証明書がすでに使用していないデバッグツールに由来することを確認したら、信頼リストから削除するか、信頼しない設定にします。

3. システムレベルのプロキシ設定に残存がないか確認

   一部のパケットキャプチャツールはシステムのネットワーク設定に固定のプロキシアドレスとポートを書き込みます。ツールをアンインストールした後は、これらの残存設定を手動で削除し、Clash クライアントのプロキシ設定と競合しないようにする必要があります。

切り分け手順の優先度リスト

証明書エラーに遭遇したら、次の順序で一つずつ確認し、コストが最も低く排除しやすい項目から優先的に対処してください。

1. システム時刻とタイムゾーンを確認

   これは最も速く排除できる項目で、数十秒あれば確認・排除できます。

2. プロキシをオフにして再テスト

   クライアントを完全に終了して同じサイトに再度アクセスし、問題がプロキシに関連するかどうかを判断します。オフにしてもエラーが出る場合は、問題はシステムの証明書信頼リストや端末の hosts 設定にあり、Clash とは無関係です。

3. ノードを切り替えて再テスト

   プロキシをオフにすると正常に戻る場合は、ノードを一つずつ切り替えて観察し、特定ノードのハイジャックかどうかを特定します。

4. TUN モードの DNS 設定を確認

   enhanced-mode、nameserver、dns-hijack の3項目がすべて設定されていて、暗号化 DNS を使用しているか確認します。

5. システムの証明書信頼リスト内の疑わしいエントリを確認

   以前インストールしたデバッグツールやパケットキャプチャソフトが残した自己署名ルート証明書を重点的に確認します。

6. クライアントとルールサブスクリプションを更新

   Clash Meta(mihomo)コアのバージョンが比較的新しいものであることを確認してください。古いバージョンにある TLS ライブラリや DNS 処理の既知の問題は、後続の更新で修正されている場合があります。