プロキシ接続時にブラウザで証明書エラーが出る原因と対処法

証明書エラーとプロキシ接続失敗を切り分ける

ブラウザに「接続はプライベートではありません」と表示される場合、HTTPSの本人確認に失敗しています。ノードのタイムアウトやプロキシポートの未起動とは別の問題です。Clash Vergeはクライアントの画面を提供し、実際の通信転送は使用中のコアが行います。ClashやClash Meta（mihomo）は通常のHTTP CONNECTやSOCKSによる転送では、接続先サイトのHTTPS通信を復号しません。また、サイト証明書を発行するためのルート証明書をシステムにインストールする必要もありません。

つまり、「プロキシを有効にした後に発生した」というだけでは、通信経路の変化が関係している可能性を示すにとどまり、「プロキシクライアントに証明書のインストールが必要」とは限りません。ブラウザのエラーコード、アクセス先ドメイン、証明書の発行者と有効期間を記録し、経路を変えて比較しましょう。クライアントを何度も再インストールするより、原因を特定しやすくなります。

エラーコード・症状	優先して確認する項目	記録しておく情報
`NET::ERR_CERT_DATE_INVALID`	システム時刻、証明書の有効期間	端末の日付と証明書の有効期間
`NET::ERR_CERT_AUTHORITY_INVALID`	不明な発行者、証明書チェーンの欠落、信頼ストア	発行者と証明書チェーン
`NET::ERR_CERT_COMMON_NAME_INVALID`	ドメイン不一致、誤った名前解決、認証ページ	アドレスバーのドメインとSANのドメイン一覧
`ERR_PROXY_CONNECTION_FAILED`	端末のプロキシアドレス、ポート、コアの状態	実際の待ち受けポートとログ

手順1：システム時刻と証明書の有効期間を確認する

証明書には有効期間の開始日時と終了日時が記録されています。パソコンを長期間起動していない場合、マザーボードの電池に問題がある場合、仮想マシンを古いスナップショットに戻した場合などは、端末の日付が実際の日付とずれることがあります。タスクバーの時刻だけでなく、年・月・タイムゾーンも確認してください。複数の無関係なサイトで日付エラーが出る場合は、まずシステム時刻を修正しましょう。

Windows 11：「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定」をオンにして、タイムゾーンを確認したうえで「今すぐ同期」をクリックします。組織管理の端末では、管理者が指定した時刻同期先を使用してください。
macOS：「システム設定」→「一般」→「日付と時刻」を開き、日付と時刻の自動設定を有効にして、タイムゾーンも確認してください。
証明書の確認：ブラウザのエラーページで証明書の詳細を確認します。開発者ツールの「セキュリティ」パネルで確認できる場合もあります。「有効期間の開始」と「有効期間の終了」を記録し、修正後の日付と照らし合わせてください。

証明書の期限が切れているのが特定のサイトだけで、ほかのサイトに問題がなければ、サイト運営者による更新やCDN設定の修正が必要なケースが一般的です。端末の日付を証明書の有効期間内に戻すと、ほかのサイトやログイントークンに影響するため、解決策として使わないでください。ブラウザは時刻を基準に検証します。タイムゾーンの表示だけを変更しても、誤ったシステム時刻が直るとは限りません。

手順2：中間者による復号と不審な証明書発行者を確認する

企業のゲートウェイやセキュリティソフトの「HTTPSスキャン」、端末上のパケットキャプチャツールは、元のTLS接続をいったん終端し、独自の証明書を使ってブラウザに通信を返すことがあります。そのルート証明書が使用中のブラウザで信頼されていないと、不明な発行者のエラーが発生します。また、公衆Wi-Fiの認証ページがHTTPS接続に誤って返されると、ドメインや発行者の異常につながることがあります。

プロキシ接続時と直接接続時の証明書を比較する

同じブラウザで同じドメインにアクセスし、2つの経路それぞれについて証明書のサブジェクト、SAN、発行者、有効期間を記録します。CDNが正規に異なる証明書を使う場合もあるため、「証明書が変わった」だけで通信の傍受と判断しないでください。
プロキシ経由で発行者が見覚えのない組織名、ルーター名、端末のセキュリティ製品名に変わる場合は、該当するHTTPS検査機能やネットワーク管理ポリシーを確認してください。
すべてのHTTPSサイトで無関係な同じドメインの証明書が表示される場合は、誤ったゲートウェイ、認証ポータル、または通信が別のサービスに転送されている可能性を優先して調べてください。

管理対象の業務用端末では、組織のルート証明書の入手元、配布方法、適用範囲を管理者に確認してください。個人端末でデバッグ用プロキシを使ったことがある場合は、ツールがまだ動作していないか、システムプロキシ設定が残っていないか確認します。不要になった設定は、ツールの手順に従って解除してください。システム証明書を一括削除したり、組織管理の信頼設定を独断で削除したりしないでください。

異なる2種類の証明書検証を区別する

ブラウザによる接続先サイトの証明書検証と、mihomoによる上流TLSノードの証明書検証は別の層で行われます。クライアントログに x509: certificate has expired などのノード接続失敗が記録され、ブラウザにはプロキシ接続の中断が表示される場合は、ノード提供元に証明書やサーバー名の設定を確認してもらってください。ノード設定の skip-cert-verify は、接続先サイトに対するブラウザの証明書警告を解決しません。有効にすると、上流の本人確認を回避することになります。

手順3：DNSの改ざん、誤った名前解決、ルールによる経路を特定する

HTTPS接続には「サーバーを探す」段階と「サーバーの本人確認をする」段階があります。DNSが誤ったアドレスを返すと、ブラウザが別のサーバーに接続し、そこで別ドメインの証明書が返されて名前不一致になることがあります。サイト側のCDN設定ミスでも名前不一致が起こり得るため、DNSを変更しただけで結論を出さず、信頼できる別のネットワークでも確認してください。

Clash Vergeの「接続」ページでエラーが出たドメインを絞り込み、該当する通信のルール、プロキシグループ、出口を確認します。ページ名はバージョンによって異なる場合があるため、現在の画面を確認してください。
テスト中は利用可能なノードを1つ選び、自動切り替えによる影響を避けてください。ルールモードとグローバルモードのどちらを使っているか記録し、調査後に元の設定へ戻します。
有効な設定内の dns、nameserver、fallback、hosts を確認します。サブスクリプション、オーバーライド、スクリプトによって最終設定が変わることがあるため、サブスクリプションの元データだけを見て判断しないでください。
システムのhostsファイルに、該当ドメインの古い割り当てが残っていないか確認します。Windowsの一般的なパスは C:\Windows\System32\drivers\etc\hosts、macOSとLinuxでは /etc/hosts です。

fake-ipを使用している場合、アプリに 198.18.0.0/16 の範囲内のアドレスが表示されても、正常なことがあります。実際の範囲は設定によって異なります。コアはドメインと仮想アドレスの対応を管理します。仮想アドレスが表示されてもDNS改ざんとは限らず、fake-ipのアドレスをブラウザの信頼リストに追加する必要もありません。

Windowsでは次のコマンドを実行し、システムの名前解決結果を確認してキャッシュを消去できます。ただし、ブラウザのセキュアDNS、コアのDNS、プロキシ側の名前解決は別の経路を使うことがあります。nslookup の結果だけでは、プロキシ接続で実際に使われたアドレスは特定できません。

nslookup example.com
ipconfig /flushdns

スマートフォンのテザリングに切り替えると正常に戻り、元のネットワークで問題が続く場合は、そのネットワークのDNS、ゲートウェイ、認証状態を確認してください。公衆ネットワークで認証が必要な場合は、システムが表示するネットワークログイン画面から認証します。証明書に異常があるHTTPSページにはアカウント情報を入力しないでください。

手順4：ルート証明書を更新し、サーバーの証明書チェーンを確認する

長期間更新されていないOSには、現在のサイトで使われている信頼済みルート証明書が含まれていないことがあります。ブラウザによって独自の信頼機構や混合型の仕組みを使用するため、同じ端末でも「一方のブラウザでは正常、もう一方ではエラー」ということは珍しくありません。古いブラウザでは、サイトが現在採用している証明書チェーンやTLS機能に対応していない場合もあります。

複数のサイトで発行者不明のエラーが出る：まずOSとブラウザのセキュリティ更新を適用し、ポリシーによって端末の信頼ストア更新が禁止されていないことを確認してから、ブラウザを再起動して試してください。
特定のサイトだけで問題が起きる：サーバーから中間証明書が送信されていない可能性があります。ブラウザによってはキャッシュを使うか証明書チェーンを補完できますが、新しい端末では失敗することがあります。サイト運営者に完全な証明書チェーンへの修正を依頼してください。
特定のブラウザだけで問題が起きる：ブラウザのバージョン、企業ポリシー、証明書の管理設定を確認してください。すべての証明書をすべてのブラウザにインポートしないでください。
古いOSでセキュリティ更新を受けられない：フォーラムからルート証明書パッケージをダウンロードして一括インポートするのではなく、サポート対象のOSへ移行することを優先してください。

「証明書の期限切れ」は、サーバー証明書自体の期限切れを指す場合も、中間証明書やルート証明書を含むチェーンの構築に問題がある場合もあります。エラーページの短いメッセージだけでは判別しにくいため、証明書チェーンのどの段階で失敗したか確認してください。通常のサイト閲覧で、そのサイトのサーバー証明書をユーザーが手動でインポートする必要はありません。

直接接続とプロキシ接続を比較して原因を絞り込む

以下では、端末上のHTTP混合ポート 7897 を例にします。インストール環境で必ずこのポートが使われるわけではありません。クライアントの設定画面または有効な設定の mixed-port フィールドで実際の値を確認してください。コアが動作していない場合、コマンドはまず接続失敗となり、接続先サイトの証明書検証にはまだ進みません。

Windows：証明書検証を有効にしたままテストする

curl.exe --noproxy "*" -I https://example.com/
curl.exe --noproxy "" --proxy http://127.0.0.1:7897 -I https://example.com/

example.com をエラーが出たドメインに置き換えます。1つ目のコマンドはcurlの明示的なプロキシ設定を迂回し、2つ目はプロキシ除外リストを空にして端末上のHTTPプロキシを指定します。macOSやLinuxでは curl.exe を curl に置き換えてください。TLS接続の詳細を確認するには -v を追加します。証明書検証を無効にする -k は追加しないでください。

比較結果	次に行うこと
直接接続は正常、プロキシ接続では証明書エラー	ノードの出口、プロキシ側の名前解決、HTTPS検査、実際に適用されたルールを確認する
どちらの経路でも日付エラーが出る	端末の時刻を確認し、サイト証明書の有効期間を確認する
curlでは正常だが、ブラウザではエラーが出る	ブラウザの信頼機構、セキュアDNS、拡張機能、企業ポリシーを確認する
どのテストでも端末のポートに接続できない	まずコアの動作状態やポート設定を修正する。証明書の問題として扱わない

curlとブラウザでは使用するTLSライブラリや信頼ストアが異なることがあるため、比較結果は原因を絞る手がかりであり、最終的な安全性の判断ではありません。ログを共有する前に、サブスクリプションURL、アクセストークン、プロキシ認証情報、個人用ドメインを削除してください。サブスクリプションのURLには、アクセスに使える認証情報が含まれていることがあります。

設定を戻して再確認するチェックリスト

変更する項目は一度に1つに絞ります。まず時刻を合わせ、次に証明書を比較し、その後に名前解決と出口を確認して、最後に信頼ストアやサーバーの証明書チェーンを調べます。ノードの切り替え、DNSの無効化、モード変更、証明書のインストールを一度に行うと、何が有効だったのか判断できなくなります。

普段使っているルールモード、プロキシグループ、TUN、システムプロキシの設定に戻し、調査中に追加した一時的なルールを削除します。
ブラウザを開き直し、問題が起きたドメインと無関係なHTTPSサイト2つにアクセスして、証明書警告が出ないことを確認します。
元のサイトの証明書にアクセス先ドメインがSANとして含まれていること、有効期間内であること、証明書チェーンが現在のブラウザで信頼されていることを確認します。
特定の出口だけで問題が起きる場合は、ドメイン、発生時刻、エラーコード、個人情報を伏せたログをサービス提供元に送ってください。特定のサイトだけで起きる場合は、証明書チェーンの問題をサイト運営者に報告します。

証明書エラーの対処では、警告画面を消すのではなく、サーバーの本人確認が正しく行われる状態に戻すことが重要です。システム時刻が正しいこと、接続先ドメインが一致すること、証明書チェーンが信頼できること、通信経路が想定どおりであることの4点がそろえば、今回の確認は完了です。プロキシモード、サブスクリプション、ルールの項目については設定リファレンスを、よくある接続の問題についてはよくある質問をご覧ください。