Clash利用中にブラウザがHTTPS証明書エラーを表示する原因と対処法

なぜプロキシが証明書検証に関わるのか

HTTPS接続の証明書検証はTLSハンドシェイクの段階で行われ、クライアント(ブラウザやOS)側が処理するものであり、プロキシを使っているかどうかとは直接の因果関係がありません——プロキシはデータパケットを目的のサーバーへ届ける役割を担うだけで、証明書はサーバー側が返し、クライアント側が検証するものです。多くの場合、ClashやMihomoコアは純粋な転送モードで動作します。ルールに従ってTCP/UDP通信を対応するノードへ振り分けるだけで、データはトランスポート層でそのまま透過され、証明書を解体・再発行することはありません。ブラウザに表示されるのは、あくまでウェブサイトのサーバー自身が持つ証明書チェーンです。このモードでプロキシを有効にした際に発生する証明書エラーは、ほとんどが「プロキシが接続経路を変えたことで、もともと隠れていた別の問題が表面化した」だけであり、プロキシ自体が証明書を偽造しているわけではありません。

ただし例外もあります。一部のクライアントには、リクエストの詳細を確認したりルールをデバッグしたりするための「HTTPキャプチャ/MITM復号」機能が用意されています。この機能を有効にすると、ローカルで生成されたルート証明書が使われ、プロキシプロセスがそれを使って復号した接続に対して証明書を再発行し、内容を転送します。このスイッチがオンになっている状態で、そのルート証明書がシステムやブラウザに信頼されていない場合、証明書チェーンは検証段階でそのまま失敗し、エラーメッセージには「信頼されていない発行者」「不明な機関により発行された証明書」といった記述が表示されるのが一般的です。これはプロキシソフト自身の証明書機構が直接エラーを引き起こす唯一のケースであり、これを見分けることが調査の第一歩になります。

調査前に確認すべき3つのこと

具体的なケースを検討する前に、次の3点を順番に確認すると、問題の範囲を素早く絞り込めます。

1. システムの時刻とタイムゾーンが正確か

   TLS証明書の検証では、現在のシステム時刻と証明書の有効期間が比較されます。システム時刻が証明書の発効日より前であったり、失効日より後であったりすると、プロキシとは無関係にそのまま証明書が無効と判定されます。ネットワーク時刻の自動同期を有効にするか、時刻とタイムゾーンを手動で確認することが、見落とされがちですが最も一般的な原因の一つです。

2. プロキシがシステム全体レベルかブラウザのみのレベルか

   システムプロキシモードでは、すべてのアプリの通信がプロキシルールの判定を受けますが、ブラウザ拡張機能のみでプロキシを使っている場合は他のアプリには影響しません。証明書エラーがブラウザだけで発生し、他のプログラムから同じサイトへ正常にアクセスできる場合、問題はClashクライアントではなく、ブラウザ拡張機能やブラウザ自体のプロキシ設定に絞り込むべきです。

3. ノードやサブスクリプションを切り替えた直後かどうか

   新しいサブスクリプションを取り込んだ直後や、新しいノードに切り替えた直後に証明書エラーが出た場合は、そのノードのサーバー側で通信の乗っ取り、証明書の改ざん、強制リダイレクトなどが行われていないか検討する必要があります。この種の問題は特定のノードでのみ発生することが多く、別のノードに切り替えて同じサイトにアクセスすれば確認できます。

よくあるケースの分析

ケース1:公共ネットワークのポータル乗っ取り(キャプティブポータル)

空港、ホテル、キャンパスなどの公共Wi-Fiでは、「先にログインしてからネットを使う」というポータルページの仕組みがよく採用されています。ネットワーク層は認証が完了するまですべてのHTTPSリクエストを横取りし、独自のログインページの証明書を返します。これは目的のサイトの本来の証明書とは全く一致しないため、ブラウザは証明書を信頼できないと判定します。この場合はまずプロキシを切断してポータルページのログインを完了し、任意のサイトに正常にアクセスできることを確認してから再度プロキシをオンにすれば、エラーは通常解消します。プロキシをオンにするとログインページが全く表示されない場合は、一時的にプロキシをオフにして認証を済ませてから、プロキシをオンに戻して通常利用してください。

ケース2:MITM復号スイッチが誤ってオンになっている

前述の通り、クライアントのキャプチャ/リライト機能が有効になっている状態で、対応するルート証明書がシステムまたはブラウザの信頼リストにインストールされていない場合、ほぼすべてのHTTPSサイトでエラーが発生します。これは一つや二つのサイトに限らず「一括して」現れる現象です。対処法はクライアントの設定からキャプチャやリライト関連のオプションを探して無効化することか、クライアントの説明に従ってルート証明書をインストールし信頼設定を行うことです。振り分けプロキシとしてだけ使い、リクエスト内容の確認が不要な場合は、この機能をオフにしたままにしておくのが一番手間がかかりません。

ケース3:証明書チェーンが不完全

一部の自前構築プロキシノードや自己署名証明書を使ったサービスでは、中間証明書の設定が欠けていることがあります。ブラウザはリーフ証明書までは検証できても、ルート証明書までの完全なチェーンを補完できず、「不明な発行者」や「証明書チェーンが不完全」といったエラーが表示されます。この種の問題はサーバー側の設定に起因し、ローカルのClashクライアント設定とは関係ありません。できる調査方法は、別のノードに切り替えて同じサイトにアクセスして比較することです。特定のノードでのみ発生する場合は、そのノード自体の証明書設定の問題であるため、別の経路に切り替えるか、サブスクリプション提供元に連絡することをお勧めします。

ケース4:DNS汚染や乗っ取りにより誤ったサーバーに接続してしまう

ドメイン名の解決が偽のアドレスに乗っ取られている場合、そのアドレスが返す証明書は当然目的のサイトの本来の証明書とは一致しません。判定方法は、プロキシをオンにし、ルールを「リモート解決」(ローカルDNSではなくプロキシサーバー側でDNSクエリを行う設定)にした状態で再度アクセスすることです。エラーが消えれば、ローカルネットワークのDNS環境に問題があると判断できます。それでもエラーが出る場合は、ケース1〜3に戻って調査を続けてください。

プラットフォーム別の具体的な対処手順

問題の種類を確認したら、以下のプラットフォーム別の手順に沿って対応してください。

Windows / macOS

1. システム時刻を確認する

   システム設定の日付と時刻のオプションを開き、「時刻を自動設定」が有効になっていること、タイムゾーンが実際の所在地と一致していることを確認してください。

2. クライアントの復号関連機能をオフにする

   ClashまたはMihomoクライアントの接続/スクリプト設定内でキャプチャ、リライト、MITM関連のスイッチを探し、リクエスト内容のデバッグが本当に必要な場合を除いて、オフになっていることを確認してください。

3. ノードを切り替えて比較テストを行う

   同じブラウザタブのまま別の利用可能なノードに切り替え、エラーが出たサイトに再度アクセスして、問題がノードによって変わるかどうかを確認してください。

Android / iOS

1. システムプロキシとVPNモードの競合を確認する

   モバイル向けクライアントの多くはローカルVPNインターフェースを通じて通信を引き受けます。他のプロキシ系アプリも同時にインストールされている場合、両者が互いに干渉して接続異常を起こす可能性があるため、調査の際はプロキシアプリを1つだけ動作させることをお勧めします。

2. 自動時刻同期が有効になっているか確認する

   モバイル端末のシステム設定にも「日付と時刻を自動設定」というオプションがあり、これをオフにすると時刻のズレが発生しやすくなります。

3. アプリを再起動するかサブスクリプションを再インポートする

   ノードを切り替えても効果がない場合は、クライアントアプリを再起動するか、いったん削除してからサブスクリプションのリンクを再インポートし、ローカルのキャッシュ設定に異常がないか確認してください。

TUNモードでの証明書エラーは別に考える必要がある

TUNモードはシステムのネットワーク層に仮想ネットワークアダプタを作成し、アプリ層のプロキシ設定を回避するプログラムも含めてグローバルな通信を引き受けます。この引き受け方式自体は証明書の再発行を伴わないため、原理的には追加の証明書問題を引き起こしません。ただし、TUNモードでは通信経路の変化がより徹底しているため、これまでシステムプロキシルールから見落とされていたアプリ(一部のバックグラウンドサービスやシステムコンポーネントの通信など)もプロキシ経路に組み込まれます。これらのリクエストが、ノード側で振り分けルールの設定が不完全な範囲に該当した場合、前述の証明書チェーンやDNS解決の問題が同様に表面化する可能性があります。調査方法は前述と同じで、一時的にTUNモードをオフにしてシステムプロキシモードに戻し、同じサイトでテストすることで、エラーが通信の引き受け範囲の拡大と関係しているかどうかを判断できます。

問題が証明書自体ではなくルール設定にある場合

証明書エラーと誤判定されやすい現象があります。あるサイトがルールによって誤ってそのサイトへのアクセスに適さないノードへ振り分けられ、相手のサーバーが想定外のレスポンス内容(通信事業者のブロックページなど)を返してくることがあります。ブラウザがこの想定外のレスポンスを解析する際にも、接続が安全でないという表示が出ますが、根本原因はルーティングのルールにあり、証明書検証のロジック自体に問題があるわけではありません。この場合は、サブスクリプションやローカル設定ファイル内でそのドメインがヒットしているポリシーグループを確認し、対応するノードが利用可能か、ポリシーグループの速度測定結果が正常かを確認する方が、証明書の細部にこだわるより早く問題を特定できることが多いです。ルール設定の文法やフィールドの説明については、完全なドキュメントのルール項目の説明を参照してください。

全体として、HTTPS証明書エラーの調査は「引き算」で進めるのが基本です。プロキシをオフにして問題が消えるか確認し、MITM関連機能をオフにして復号との関係を確認し、ノードを切り替えて特定の経路との関係を確認し、DNS解決方式を切り替えてローカルネットワークの汚染との関係を確認する。それぞれのステップで一つの原因を除外できるため、通常は4ステップ以内で問題を特定でき、一つ一つ当てずっぽうで推測する必要はありません。