2026-11-03 · トラブル対処 · 読了目安 10 分

プロキシ接続で証明書エラーが出る原因と対処法｜HTTPS証明書の確認方法

プロキシ接続時のHTTPS証明書警告について、PCの時刻ずれ、HTTPS検査、DNSの誤解決、接続先の問題など原因別に確認方法を解説します。

まずエラーコードを記録し、証明書検証を無効にしない

Clashを有効にしたあとに「この接続ではプライバシーが保護されません」と表示されても、ブラウザーが現在の接続経路でサーバーの本人確認を完了できなかったことを示すだけで、ノードの障害とは限りません。HTTPSの検証には、アクセス先のドメイン、証明書の有効期間、証明書チェーン、端末の信頼ストアが関係します。プロキシによって接続経路が変わると、そのいずれかの問題が表面化することがあります。

まずアドレスバーに表示された完全なホスト名、ブラウザーのエラーコード、システム時刻、証明書ビューアーの「発行者」「有効期間」「Subject Alternative Name（SAN、サブジェクトの別名）」を記録します。通常はホスト名の記録だけで十分です。スクリーンショットを共有する場合は、URL内のログイントークンやメールアドレスなど、個人情報を隠してください。

エラー・症状	優先して確認する項目	この時点では断定できないこと
`NET::ERR_CERT_DATE_INVALID`	システムの日付、タイムゾーン、証明書の有効期間	サイトの証明書が期限切れとは限らない
`NET::ERR_CERT_AUTHORITY_INVALID`	ルート証明書の信頼性、中間証明書チェーン、HTTPS検査ツール	新しい証明書のインストールが必要とは限らない
`NET::ERR_CERT_COMMON_NAME_INVALID`	SANにアクセス先ドメインが含まれるか、DNSとリダイレクト	信頼設定を追加してもドメイン不一致は直らない
`SEC_ERROR_UNKNOWN_ISSUER`	Firefoxの信頼設定とサーバー証明書チェーン	ほかのブラウザーで使えるだけでは問題を否定できない
`ERR_SSL_PROTOCOL_ERROR`	サーバー側のTLS、ポートのプロトコル、ネットワーク上の中継機器	証明書が信頼されていないことと同じではない

証明書検証を無効にする、出所不明のルート証明書をインストールする、「続行」をクリックするといった操作で解決しようとしないでください。銀行、決済、メール、アカウントのログインページで証明書警告が出た場合は、パスワードの入力を中止し、信頼できるネットワークで接続を確認してください。

Clash・mihomoとHTTPS証明書の関係

通常のClashやmihomoの設定は、接続を中継するものです。ブラウザーがHTTPプロキシのCONNECTトンネル、SOCKS5、またはTUN経由でサイトに接続する場合も、サイトとのHTTPSのTLSハンドシェイクは通常、ブラウザーとサイトの間で行われます。システムプロキシを有効にしただけで、ウェブ通信を復号するルート証明書をシステムにインストールする必要はありません。

TLSの接続先を2つに分けて考えましょう。ノード設定のtls、servername、skip-cert-verifyは、「コアからプロキシノードまで」の接続を制御する場合があります。一方、ブラウザーの証明書警告は通常、「ブラウザーからサイトまで」の接続に関するものです。ノードのskip-cert-verifyを変更してもサイトの証明書は直らず、ノードの本人確認の信頼性が低下します。

症状ごとに確認する場所を切り分ける

ブラウザーに証明書警告が表示される：サイト証明書のドメイン、発行者、有効期間を確認します。
クライアントのログにx509が表示され、ブラウザーでプロキシ接続に失敗する：ノードのドメインと証明書、コアの実行環境の時刻と信頼ストアを確認します。
TUNを有効にしたときだけ発生する：実際に適用されるルール、DNSの経路、ほかのVPNを確認します。TUNがサイトに新しい証明書を発行するわけではありません。

ブラウザーのセキュアDNS、拡張機能のプロキシ、システムプロキシ、TUNが同時に使われている場合があります。診断では接続経路を一つに絞りましょう。「システムプロキシを無効にしたのに通信がTUN経由のまま」といった状態では、直接接続でも問題が起きると誤認するおそれがあります。

システム時刻のずれと証明書の有効期間

証明書には有効開始日時と有効期限があります。端末の時刻が有効開始日時より前、または有効期限より後だと検証に失敗します。デュアルブート、仮想マシンのスナップショット復元、マザーボードの電池切れ、時刻同期サービスの異常などにより、複数の正常なサイトで同時にエラーが発生することがあります。

まず現在時刻を確認し、次にタイムゾーンを確認

Windows 11：「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」を確認してから「今すぐ同期」を実行します。組織管理の端末では、時刻の同期先が組織のポリシーで管理されている場合があります。
macOS：「システム設定」→「一般」→「日付と時刻」を開き、日付と時刻の自動設定とタイムゾーンを確認します。
Ubuntu：次のコマンドで、現在の時刻、タイムゾーン、同期状態を確認します。

date -Is
timedatectl status

System clock synchronizedを確認してください。systemdで時刻を管理しており、ほかの時刻サービスや組織のポリシーによる制約がない場合は、次のコマンドでネットワーク時刻同期を有効にし、状態を再確認できます。

sudo timedatectl set-ntp true
timedatectl status

タイムゾーンが異なっていても、システムの絶対時刻が間違っているとは限りません。サイトの地域に合わせてタイムゾーンを変更する必要はありません。時刻が正しく、特定のドメインだけで証明書の期限切れが起きている場合は、通常、サイトの管理者が証明書を更新する必要があります。端末の日付を変更しても問題が隠れるだけで、ほかのサイトにも影響します。

HTTPS検査ツールと端末の信頼ストア

Fiddler、Charles、mitmproxyなどでHTTPS復号を有効にすると、アクセス先サイトの証明書が動的に発行されます。一部のセキュリティソフトや企業ゲートウェイも同様の検査を行います。そのため、ブラウザーに表示される発行者が、サイト本来の公開認証局ではなく、ツール名や組織名になることがあります。

証明書をすぐにインストールせず、発行者を手がかりに調べる

エラーページから証明書の詳細を開き、発行者と証明書チェーンを確認します。画面の操作手順はブラウザーのバージョンによって異なります。
HTTPS検査ツールが起動していないか、HTTPS復号が有効になっていないか、システムプロキシの接続先がそのツールのままになっていないか確認します。
個人のテストが終わったら、ツールのHTTPS復号を無効にし、説明に従ってプロキシ設定を元に戻します。テスト用ルート証明書は、そのツールのものだと確認でき、今後不要な場合に限って削除してください。
発行者が会社や学校のものであれば、端末管理と信頼設定の配布について管理者に確認してください。組織の証明書を自己判断で削除したり、ポリシーを回避したりしないでください。

すべてのアプリが同じ証明書の信頼方式を使うとは限りません。Firefox、システムのブラウザー、コマンドラインのcurl、コンテナー内のプログラムでは、参照する証明書ストア、バージョン、組織のポリシーが異なる場合があります。「ブラウザーでは開けるがcurlでは失敗する」場合は、ノードを何度も切り替えるのではなく、それぞれの信頼元を比較してください。

Ubuntuで公開CA証明書のパッケージが古いだけであれば、信頼できるソフトウェアソースからca-certificatesを更新できます。次の操作でシステムの信頼情報を更新できますが、サイトのドメイン不一致は自動で直らず、出所不明のプライベート証明書が信頼されるようになるわけでもありません。

sudo apt update
sudo apt install --only-upgrade ca-certificates
sudo update-ca-certificates

直接接続・固定ノード・証明書の詳細を比較する

比較テストでは、同じ端末とURLを使い、できるだけ近い時間に、変更する条件を一つに絞ります。まずHTTPS検査ツールやほかのVPNを一時的に無効にし、TUN、システムプロキシ、ブラウザー拡張機能の実際の状態を確認してください。ルールモードでは対象ドメインにDIRECTが適用されることがあります。クライアントが起動していても、そのリクエストが必ずノード経由になるとは限りません。

ローカルのmixed-port経由でリクエストを比較する

次の例では、ローカルのmixed-portが7890で、公開サンプルドメインexample.comを使うものとします。実際の障害を調べる場合は、問題のサイトのトークンを含まないURLに置き換え、クライアントに表示されたポートを指定してください。Windowsでは、PowerShell環境によって同名の別名が使われることがあるため、curl.exeを明示して実行するのがおすすめです。

# curlの明示的なプロキシ設定を使わない（TUNが接続を引き続き処理する場合があります）
curl -Iv --noproxy '*' https://example.com/

# mixed-portのHTTPプロキシを使う
curl -Iv --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/

--noproxy '*'で無視できるのはcurlのプロキシ設定だけです。TUN、透過型ゲートウェイ、システムのルーティングは回避できません。直接接続の基準を正しく得るには、許可された環境で、通信を横取りする関連機能も無効にする必要があります。上記のコマンドは証明書検証を無効にしません。出力にはリクエスト情報が含まれる場合があるため、共有する前に個人情報を伏せてください。

特定のノードだけで発生する：ほかの条件を固定してノードを切り替え、証明書のSAN、発行者、エラーコードを比較します。クライアントの接続履歴で、適用されたルールと実際の出口も確認してください。
どの出口でも特定のサイトだけで発生する：端末のプロキシポートよりも、サイトの証明書、証明書チェーン、CDNのエッジ設定を優先して疑います。
同じ端末で複数のサイトに発生する：時刻、信頼ストア、HTTPS検査ツール、管理対象ネットワークを優先して確認します。
同じネットワーク内の複数端末で発生する：ポータル認証、ルーターのDNS、ゲートウェイ、回線事業者のネットワークを確認します。必要であれば、信頼できる別のネットワークでも比較してください。

出口によって異なる証明書が表示されても、必ずしも通信が乗っ取られているとは限りません。CDNは地域に応じて、異なる有効な証明書や中間証明書チェーンを使うことがあります。ドメインが一致するか、証明書チェーンが信頼できるか、有効期間内か、発行者の違いに説明がつくかを確認してください。

DNSの誤解決、ノードの異常、ポータル認証を見分ける

DNSの誤解決により、ドメインが無関係なサーバーを指すと、証明書のドメイン不一致が発生することがあります。しかし、誤った解決先が対象ドメインの有効な証明書を自動的に持つわけではありません。DNSの結果を変更しただけでは、証明書検証が正常なHTTPS接続を通常は気付かれずに復号できません。ブラウザーの警告は、維持すべきセキュリティ境界です。

fake-ipのアドレスだけでは誤解決とは限らない

mihomoのfake-ipモードでは、アプリにマッピング用の合成IPアドレスが返されます。よく使われる設定範囲は198.18.0.0/16ですが、実際の範囲はfake-ip-rangeで確認してください。検索結果がこの範囲内というだけで、DNSが汚染されているとは断定できません。コアにドメインとの対応関係が保持されているか、接続にどのルールと出口が適用されたかを確認します。

まずdns.enhanced-mode、nameserver、設定されている場合はnameserver-policy、さらにTUNのdns-hijackを確認します。
ブラウザーでセキュアDNSが有効になっているか確認します。ブラウザー側で別のリゾルバーを選んでいると、想定と異なる経路でドメインが解決されることがあります。
2つのリゾルバーが返すIPアドレスが同じかどうかだけで判断しないでください。CDN、地理的な位置、負荷分散によって、正常でも結果が異なることがあります。
DNS設定を変更したら、設定を再読み込みしてテスト接続を作り直します。古い接続、DNSキャッシュ、fake-ipのマッピングが残り、結果が一時的に混在することがあります。

特定の出口を使ったときだけ異常が発生し、証明書のドメインが一致しない、または発行者を説明できない場合は、その出口を無効にし、個人情報を伏せた記録を残してください。問題がその経路に関係することは示せますが、それだけでノードによる意図的な通信の乗っ取りが証明されるわけではありません。出口側ネットワークのDNSや中継機器の異常も考えられます。

ホテルや空港などのネットワークでは、先にポータル認証が必要な場合があります。HTTPSリクエストがログインゲートウェイに転送され、証明書エラーになることもあります。システムに表示された「ネットワークにログイン」などの案内から認証してください。証明書に異常がある元のサイトではログイン情報を入力せず、ポータル用として出所不明のルート証明書をインストールしないでください。

修復後の確認とよくある誤解

HSTS対応サイトに「続行」が表示されないのはなぜ？

HSTS（HTTP Strict Transport Security）は、対象サイトでHTTPSを厳格に使うようブラウザーに求める仕組みです。証明書エラー時に回避手段が表示されないのは、想定どおりの動作である場合があります。HSTSの状態を消しても証明書は直りません。時刻、証明書チェーン、ドメイン、ネットワーク経路の問題を解決してください。

グローバルモードやTUNを有効にすれば直る？

どちらも出口や通信を処理する範囲を変えるため、条件を限定した比較テストには使えますが、期限切れの証明書や不明な発行者を修復するものではありません。グローバルモードは経路の選択を変え、TUNはネットワーク層の通信を処理します。どちらも、サイトの本人確認に関するブラウザーの基準を変えるものではありません。テスト後に正常になった場合は、元のルールや経路で異常が起きた理由を調べてください。

トラブル対処後のチェックリスト

必要なルールモードとプロキシの接続方法に戻し、一時的なテスト設定を削除して、証明書検証を有効に保ちます。
古いタブを閉じて再アクセスし、ホスト名が正しいこと、証明書が有効であること、エラーが再発しないことを確認します。
クライアントの接続履歴で実際に適用されたルールを確認します。キャッシュされたページや、想定した出口を経由していないリクエストで結果を判断しないでください。
問題を報告する場合は、OS、ブラウザーのバージョン、クライアントとコアのバージョン、エラーコード、発生時刻、個人情報を伏せた証明書情報を記載してください。サブスクリプションURL、ノードのパスワード、設定全体は送信しないでください。

確認の順序は、エラーコード → 時刻 → 証明書の詳細 → 端末上のHTTPS検査 → 直接接続と固定出口の比較 → DNSとネットワーク経路にするとよいでしょう。証明書検証を維持したまま一つずつ範囲を絞るほうが、複数の設定項目を同時に変えるより原因を特定しやすくなります。