Clashプロキシ使用時のHTTPS証明書エラー：原因の切り分けと段階的な対処法

ClashのシステムプロキシまたはTUNモードを有効にした後、ブラウザーに突然「接続はプライベートではありません」「認証局が不明です」「証明書の名前が一致しません」などの警告が表示されると、原因をすぐクライアントに求めがちです。実際の切り分けでは、まず2つの点を分けて考える必要があります。通信がプロキシによって別の経路を通ったのか、そしてHTTPS接続がどの層で終端されたのかです。通常のClashやClash Meta（mihomo）カーネルは、接続の転送とルールに応じた出口の選択を担うもので、一般的なWebサイトのTLS通信を本機上で復号するわけではありません。設定に追加の通信スニッフィング、スクリプト、または中間者プロキシがなければ、ブラウザーが受け取る証明書は原則として接続先サイトが提示するものです。

そのため、証明書エラーの主な原因としては、システム時刻のずれ、Webサイトの証明書チェーン設定、DNSの誤った応答、プロキシ出口から返される遮断ページ、組織ネットワークによるHTTPS検査、セキュリティソフトが挿入するローカル証明書、ブラウザー独自の証明書ストアなどが考えられます。正しい手順はノードを何度も切り替えることではなく、まずエラーの状況を記録し、比較テストで問題の範囲を特定することです。

1. HTTPS証明書とClashの役割を理解する

HTTPSサイトにアクセスすると、ブラウザーは証明書のドメイン名、有効期限、発行チェーン、用途を確認します。証明書にはアクセス中のホスト名が含まれていなければならず、現在時刻は有効期間内でなければなりません。さらに証明書チェーンは、システムまたはブラウザーが信頼するルート証明書までつながる必要があります。どれか1つでも条件を満たさない場合、ブラウザーは接続を遮断するか警告を表示します。

Clashのシステムプロキシは通常、システムプロキシに対応したアプリからHTTPまたはSOCKS接続をローカルの待受ポートへ渡します。TUNモードは仮想ネットワークインターフェースを通じて、より多くのIP通信を取り込みます。どちらも変わるのは接続の入口とルーティング範囲であり、Webサイトの証明書を自動的に置き換えるものではありません。ただし、プロキシノードや上流ネットワークによって名前解決の結果が変わったり、接続先が遮断されたり、認証ページや警告ページが返されたりすることはあります。この場合、ブラウザーがアクセスしているドメイン名は変わらなくても、別のサーバーから内容が返されるため、証明書名の不一致や発行者の異常として表示されることがあります。

TLS証明書とサブスクリプションURLの関係も分けて考えましょう。サブスクリプションは、プロキシノード、プロキシグループ、ルールなどの設定をクライアントに提供するものです。サブスクリプションの取得時に証明書エラーが表示された場合は、サブスクリプションのドメイン、システム時刻、ネットワーク経路を個別に確認してください。それだけで全ノードが使えないと判断することはできません。逆に、サブスクリプションの更新に成功しても、そのURLにアクセスできたことを示すだけで、すべての接続先サイトのTLSチェーンが正常だとは限りません。

2. 4つの比較テストで問題の範囲を絞り込む

切り分けを始める前に、アカウントへのログイン、決済、管理画面での操作は一時停止してください。そのうえで、普段安定しているHTTPSサイトと、エラーが発生したサイトを1つずつ選び、以下の比較テストを行います。ブラウザー、ノード、DNS、TUNを同時に変更すると結果を解釈できなくなるため、毎回変更する条件は1つだけにしてください。

1. プロキシの有効・無効を比較：ClashのシステムプロキシとTUNを無効にして、もう一度アクセスします。直接接続では正常でプロキシ経由だけエラーになる場合は、ノードの出口、ルールの適用、DNS、中間機器を重点的に確認します。どちらの状態でもエラーになる場合は、システム時刻、ブラウザーの証明書ストア、接続先サイトを優先して確認します。
2. 1つのサイトとすべてのサイトを比較：1つのドメインだけ失敗する場合は、サイトの証明書、ドメイン解決、特定ルールの問題である可能性が高いです。関係のない多数のサイトが同時に失敗する場合は、本機の時刻、ルート証明書ストア、組織ネットワークの検査、セキュリティソフトなど、共通する環境の問題が考えられます。
3. 1つのブラウザーとすべてのアプリを比較：特定のブラウザーだけ失敗する場合は、そのブラウザーのセキュリティ設定、拡張機能、DNS over HTTPS、独自の証明書ストアを確認します。ブラウザー、コマンドライン、ほかのアプリでも失敗する場合は、システムまたはネットワーク経路に問題がある可能性が高くなります。
4. 現在のネットワークと別のネットワークを比較：利用条件を満たす信頼できる別のネットワークへ切り替えて確認します。組織や学校のネットワークでエラーになり、別のネットワークでは正常な場合、認証ポータル、ゲートウェイ検査、出口ポリシーが関係している可能性があります。どのネットワークでも同じなら、本機と設定の確認に戻ります。

テスト時は、Clashのパネルで実際に適用されたルールも確認してください。あるドメインはプロキシ経由でも、関連する画像、API、ログイン用ドメインは直接接続になることがあります。Webページの本文が開けても、ページ内のすべてのHTTPSリクエストが同じ出口を通るとは限りません。開発者ツールで特定のサブドメインだけ証明書エラーになっている場合は、その完全なホスト名を記録し、どのルールとプロキシグループが適用されたかを確認します。

3. システム、ブラウザー、ネットワークの各層を確認する

1. システムの日付・時刻・タイムゾーンを調整する

証明書の検証には正確な時刻が必要です。マザーボードの電池切れ、仮想マシンの一時停止からの復帰、デュアルブート、手動でのタイムゾーン設定などにより、時刻が数時間、場合によっては数年ずれることがあります。まずシステムの日時自動設定を有効にし、時刻同期を一度実行します。同時にタイムゾーンも確認してください。タスクバーの時刻だけを見るのは不十分です。時刻を直した後はブラウザーを完全に終了して再起動し、新しいTLS接続を確立させます。

再起動のたびに時刻がずれる場合は、ブラウザーに例外を追加し続けるのではなく、システムの時刻ソースまたはハードウェアクロックを修復してください。証明書の「まだ有効ではありません」と「期限切れ」という警告は、本機の時刻が原因でも表示されます。ページの文言だけで証明書が実際に無効だと判断してはいけません。

2. 証明書のドメイン名と発行チェーンを確認する

ブラウザーの証明書ビューアーを開き、「発行先」「発行者」「有効期間」「証明書のパス」を確認して記録します。アクセス中のドメインと証明書の対象ドメインが一致しない場合、DNSが誤ったサーバーを指している、透過型ゲートウェイが認証ページを返している、またはサイト側の設定漏れなどが考えられます。発行者に組織名、セキュリティ製品名、ローカルネットワーク機器名が表示される場合は、HTTPS検査コンポーネントを経由している可能性があります。その証明書を信頼すべきかどうかは、機器またはネットワークの管理者に確認してください。

証明書パスに中間証明書が含まれていない場合、キャッシュによって補完して開けるブラウザーもあれば、すぐに失敗するアプリもあります。これにより、「ブラウザーでは開けるのにコマンドラインツールではエラーになる」、またはその逆の現象が起こります。この場合はサーバー側の証明書チェーンを修復するか、システムの証明書ストアとアプリの実行環境を更新してください。証明書検証を無効にすることを恒久的な対策にしてはいけません。

3. ブラウザーの設定と証明書ストアを比較する

ブラウザーによって、システムの証明書ストアを使う場合もあれば、独自の信頼ポリシーを持つ場合もあります。企業の管理ポリシー、保護者による制限、セキュリティソフトのHTTPSスキャン、古い実行環境なども結果に影響します。まずブラウザーのゲストプロファイルまたは新しいテストプロファイルを使って拡張機能の影響を切り分け、その後「組織によって管理されています」と表示されていないか確認します。組織の管理下にある端末では、管理者の正式な案内に従って対応し、組織の証明書を自己判断で削除しないでください。

暗号化DNSを有効にしたブラウザーでは、ClashのDNS設定を迂回するため、ほかのアプリとは異なる結果になることがあります。切り分け中は、ブラウザーが一時的にシステムの名前解決を使うようにし、ClashのDNSログと比較できます。ここでの目的は名前解決の経路を確認することであり、特定のDNS方式が常に優れていると決めつけることではありません。

4. 認証ポータルと中間機器を切り分ける

ホテル、空港、学校、ゲスト用ネットワークでは、最初にWeb認証を求められることがあります。端末がまだ認証されていないと、ゲートウェイがリクエストをログインページへ転送する場合があります。HTTPSリクエストは通常のHTTPのようにスムーズにリダイレクトできないため、ドメイン名の不一致が発生することがあります。まずプロキシを無効にし、ネットワークが信頼できることを確認したうえで、ネットワークが提供する認証ページを開いて認証を完了してからClashを再開してください。

ルーターのコンテンツフィルタリング、家庭向けセキュリティ機能、企業ゲートウェイ、エンドポイント保護ソフトも暗号化接続を検査することがあります。証明書の発行者が突然ローカル製品名になり、管理対象ネットワークを外すと正常に戻る場合は、その製品の管理ポリシーを確認してください。出所の不明なルート証明書をインストールすると信頼範囲が広がるため、応急処置として行うべきではありません。

4. Clashのルール、DNS、ノード、TUNを確認する

適用されたルールとプロキシ出口を確認する

Clashクライアントの接続履歴からエラーになったドメインを探し、DIRECT、PROXY、REJECTのどのルールが適用されたか確認します。ルールは上から順に評価されるため、先にあるドメイン指定、サフィックス指定、ルールセットが後の設定を上書きすることがあります。対象ドメインが不適切な出口へ送られている場合は、まず明示的なポリシーへ一時的に切り替えて検証し、その後設定内でルールの順序を修正します。ルールの問題を隠すために、グローバルモードへ常用で切り替えるのは避けてください。

1つのサービスが、ログイン、静的リソース、API、証明書ステータス確認などに複数のドメインを使うことは珍しくありません。ページのメインドメインだけを調整しても不十分な場合があります。接続ログで関連ドメインが別々の出口に振り分けられていないか確認し、特にログイン後のリダイレクトで初めてエラーが出るケースに注意してください。ルールの考え方とプロキシグループの詳しい説明は使用ガイドで確認できます。

DNSの名前解決結果を確認する

プロキシを有効にしたときだけ証明書名が一致しなくなる場合、DNSは重要な確認ポイントです。Clash Meta（mihomo）では、複数のDNS上流、ルールに基づく名前解決、fake-ipやredir-hostなどを設定できます。設定方式そのものが誤った証明書を生み出すわけではありませんが、上流からの誤った応答、汚染された結果、古いキャッシュ、経路分岐の不整合によって、ドメインが誤ったアドレスへ誘導されることがあります。

まずClashのログで名前解決と接続先を確認し、必要に応じてOSとブラウザーのDNSキャッシュを消去してから再テストします。fake-ipを使用している場合は、Clash内部のマッピングと最終的な接続記録を基準にしてください。予約アドレス形式のfake-ipを、そのままWebサイトの実サーバーだと考えてはいけません。DNSを変更した後はカーネルを再起動するか設定を再読み込みし、古い接続やキャッシュの影響をなくします。

ノードの切り替えは切り分けのために使う

同じ設定で特定の1ノードだけ証明書異常が起き、ほかの信頼できるノードでは正常な場合、障害はその出口または上流経路に関係しています。ノード、対象ドメイン、発生時刻を記録し、その経路の使用を一時停止してください。すべてのノードで失敗し、直接接続だけ正常なら、共通して使っているDNS、ルールプロバイダー、チェーンプロキシ、ローカルの中間ソフトウェアを確認します。

レイテンシーが正常でも、TLSが正常とは限りません。速度テストは通常、特定アドレスの応答速度だけを確認し、対象サイトの証明書チェーン、SNI、DNSの結果、ページ全体のリクエストまでは検証しません。そのため、「ノードにレイテンシーが表示される」ことを、証明書問題が解消した根拠にしないでください。

システムプロキシとTUNモードを個別にテストする

システムプロキシでは正常でTUNだけエラーになる場合は、TUNのDNSハイジャック、ルーティング、権限、ほかの仮想ネットワークアダプターを重点的に確認します。TUNでは正常でシステムプロキシだけエラーになる場合は、アプリがシステムプロキシを正しく読み取っているか、ブラウザーに独自のプロキシ設定がないか、ローカルの待受ポートを別のプログラムが使用していないかを確認します。モードを切り替える前に進行中のダウンロードやログインを停止し、切り替え後に接続を確立し直してください。

複数のプロキシクライアント、ブラウザーのプロキシ拡張機能、重複するTUNソフトウェアを同時に有効にしないでください。通信が複数のローカルポートを順番に通るプロキシチェーンやループが発生することがあります。切り分け時は入口を1つだけにし、クライアントでHTTP、SOCKS、mixedポートとシステム設定が一致していることを確認します。基本設定はClash使用チュートリアルを参照してください。

5. よくあるブラウザーエラーコードの見分け方

エラーコードの表記はChrome、Edge、Firefox、Safariで完全には一致しませんが、判断する観点は共通しています。コードを確認するときは、アクセス先と証明書情報も同時に記録してください。ページのURLが元のドメインから認証ページや別ドメインへ移動している場合は、ネットワーク認証の流れが原因かもしれません。URLが変わらないのに証明書がまったく無関係なドメインのものなら、アクセスを停止し、名前解決と中間機器を確認してください。

6. 安全な対処範囲と最終チェックリスト

証明書警告は、接続先の身元をブラウザーが判断した結果です。HTTPS検証を長期的に無効にして警告を消すのは適切ではありません。コマンドラインツールの検証スキップオプション、ブラウザーの強制続行、未知のルート証明書の手動信頼は、以後の接続から重要な保護を失わせる可能性があります。テストは原因の特定に役立ちますが、パスワード、確認コード、決済情報を入力することを代償にしてはいけません。

原因が接続先サイトの証明書期限切れやチェーン設定ミスであれば、クライアント側でできることは通常、サイトの修正を待つか管理者へ連絡することです。管理対象端末が原因の場合は、組織の管理者にルート証明書と検査ポリシーを確認してもらってください。特定のノードに問題が集中している場合は、その経路の使用を停止し、ドメイン、時刻、エラーの種類を添えてサービス提供者へ報告します。本機の時刻、DNSキャッシュ、重複プロキシ、誤ったルールが原因なら、修正して設定を再読み込みし、元のエラーサイトで再テストしてください。

利用を再開する前にもう一度確認する

• システムの日付、時刻、タイムゾーンが正しく、自動同期が正常に動作している。
• ブラウザーのアドレスバーのドメインが、証明書の対象範囲と一致している。
• 証明書の発行者が想定どおりで、証明書チェーンが信頼できるルートまでつながっている。
• Clashの接続ログにあるルール、プロキシグループ、実際の出口が設定の意図と一致している。
• DNSの名前解決経路が明確で、ブラウザーとシステムが意図せず別の上流を使っていない。
• システムプロキシとTUNが、ほかのプロキシツールや仮想ネットワークアダプターと重複して通信を取り込んでいない。
• ネットワークまたはノード切り替え後のテスト結果を記録し、安定して再現できるか、または復旧したことを確認できている。

修復後は、まず通常の公開ページで確認し、その後に元のエラーサイトをテストします。ログインが必要なページでは、情報を入力する前に、URL、証明書の発行者、接続状態がすべて正常であることを確認してください。証明書問題はブラウザーの警告ページに現れていても、実際には時刻、名前解決、ルール、出口、ネットワーク管理など複数の層にまたがっている可能性があります。一度に変更する条件を1つに保つほうが、クライアントを何度も再インストールするより早く原因を見つけられることが多いです。