プロキシ使用後にHTTPS証明書エラーが発生する原因・確認方法・対処手順

Clash、Clash Meta（mihomo）、または他のプロキシクライアントを有効にすると、ブラウザーに「接続はプライベートではありません」「証明書が無効です」「証明書の有効期限が切れています」、あるいは NET::ERR_CERT_AUTHORITY_INVALID と表示されることがあります。これらはすべてHTTPSに関係する警告に見えますが、発生箇所は同じとは限りません。パソコンの日付のずれによって証明書がまだ有効でないと判断される場合もあれば、対象サイトの証明書チェーンが不完全な場合、現在のネットワークがTLS接続を検査している場合、プロキシルールによってリクエストが不適切な出口へ送られている場合もあります。

確認の際は、証明書警告が出たからといって、すぐに「続行」をクリックしないでください。HTTPS証明書は、アクセス先のドメイン、暗号化接続の身元、証明書の発行関係を確認するために使われます。警告を無視すると、実際のネットワーク傍受、誤った出口、ドメインハイジャックを見落とすおそれがあります。効率よく調べるには、まずエラーの原文と問題が起きたドメインを記録し、「プロキシを無効にした場合」と「有効にした場合」の結果を段階的に比較します。クライアントの証明書関連オプションを確認するのは最後です。

まず確認：証明書エラーが示す内容

ブラウザーでHTTPSサイトにアクセスすると、証明書が現在のドメインを対象としているか、有効期間内か、信頼された証明書チェーンをたどってルート証明書に到達できるか、接続中のホスト名が証明書と一致しているかが検証されます。プロキシクライアントは通常、接続の転送とポリシー選択を担うもので、HTTPS復号ツールと同義ではありません。通常のHTTPプロキシやSOCKSプロキシは接続を転送できます。ブラウザーがプロキシ経由で対象サイトへのTLS接続を確立する場合でも、ブラウザーが受け取るのは通常、対象サイトが提示した証明書です。

したがって、「Clashを起動したら証明書エラーが出た」からといって、「Clashが証明書を変更した」とは限りません。接続方式を2つに分けて考える必要があります。1つ目は、プロキシがTCPを転送するだけ、またはトンネルでHTTPSを運ぶ方式です。この場合、証明書は通常、対象サイトから直接返されます。2つ目は、ネットワーク機器、企業向けセキュリティソフト、一部のデバッグツールがHTTPSの内容を検査する方式です。これらはローカルに信頼されたルート証明書をインストールし、アクセス先ドメイン用の代替証明書を生成することがあります。そのルート証明書を現在のブラウザーが信頼していなければ、証明書の発行者を信頼できないという警告が表示されます。

Clash MetaのTUNモードも、すべてのHTTPS証明書を自動的に変更するわけではありません。TUNは主に仮想ネットワークアダプターでシステム通信を受け取り、設定されたルーティング、DNS、プロキシルールに基づいて接続を処理します。変わるのは通信がプロキシコアへ入る経路です。実際に確認すべきなのは、最終的な出口、DNS解決、ルールのマッチ状況、追加のTLS検査コンポーネントの有無です。

手順1：システム時刻とタイムゾーンを確認する

証明書の有効期間は、デバイスの現在時刻を基準に判定されます。システムの日付が数時間、数日進んでいたり遅れていたりすると、ブラウザーが正常な証明書を「まだ有効ではない」または「期限切れ」と判断することがあります。タイムゾーンの設定ミスでも同じ現象が起こります。特にデュアルブート、仮想マシン、スリープ復帰後、マザーボードの時計異常がある環境では注意が必要です。この問題はプロキシルールとは無関係ですが、ネットワーク環境を切り替えた直後に気づくことが多く、Clashが原因だと誤認されがちです。

1. システムの日付と時刻の設定を開き、自動時刻設定を有効にして、タイムゾーンが現在地と一致していることを確認します。
2. 時刻を手動で一度同期し、同期成功と表示されるまで待ってから、ブラウザーを完全に終了して再起動します。
3. 異なる証明書サービスを利用している2つのサイトにアクセスして比較します。複数のサイトで同時に「まだ有効ではない」または「期限切れ」と表示される場合は、まずシステム時刻を修正してください。

1つのサイトだけでエラーが発生し、他のHTTPSサイトが正常なら、時刻が原因である可能性は下がります。その場合は、プロキシモードを何度も切り替えるのではなく、証明書の詳細を確認します。モバイルホットスポット、自宅回線、社内ネットワークも比較環境として使えますが、比較時はできるだけ同じデバイスの時刻とブラウザー設定を使用してください。

手順2：証明書のドメイン、有効期間、発行者を確認する

ブラウザーのアドレスバーにあるセキュリティ情報から証明書の詳細を開き、3つの項目を重点的に確認します。1つ目はサブジェクトまたは使用者名で、証明書が現在アクセスしているドメインを対象としているかを確認します。ワイルドカード証明書は規則に合うサブドメインだけを対象とし、まったく異なるメインドメインまではカバーしません。2つ目は有効期間で、現在時刻が開始日時と終了日時の間にあることを確認します。3つ目は発行者と証明書チェーンで、中間証明書がそろっているか、ルート証明書をOSまたはブラウザーが信頼できるかを確認します。

証明書に表示されたドメインとアドレスバーのドメインが完全に一致しない場合、DNSが誤ったサーバーを指している、プロキシ出口が異常なページを返している、またはネットワーク経路に傍受が存在する可能性があります。ドメインは一致しているものの、発行者が企業ゲートウェイ、ウイルス対策ソフト、ローカルデバッグツールの名称になっている場合は、それらのHTTPSスキャンが有効か、ルート証明書が正しく配布されているかを確認します。警告を消すために、見知らぬルート証明書をむやみにインストールしないでください。ルート証明書には強い信頼権限があるため、入手元と用途を明確にする必要があります。

手順3：プロキシと直接接続を最小限の変数で比較する

プロキシの問題を調べるときは、変数が少ないほど結論を出しやすくなります。まずシステムプロキシを無効にするかクライアントを一時停止し、同じブラウザーで同じURLにアクセスして、エラーが続くか記録します。次にプロキシを再び有効にしますが、同じノード、同じDNS設定、同じブラウザーウィンドウを維持してください。エラーがプロキシ有効時だけ発生する場合は、動作が確認されている別のノードへ切り替えます。ルールモード、TUN、DNS、ブラウザー拡張機能を同時に変更せず、毎回1つの条件だけを変えてください。

クライアントの接続画面またはログ画面で、対象ドメインが想定どおりのルールにマッチしているか、実際にどのプロキシグループとノードが使われたかを確認します。ルールモードでは、ドメインが特定ルールに先にマッチし、その後プロキシ、直接接続、拒否のいずれかへ渡されることがあります。グローバルモードでは、より多くのリクエストが選択したプロキシグループへ送られるため、短時間の比較に適しています。直接接続モードはサイト自体が正常かを確認するのに役立ちますが、ネットワークポリシーを恒常的に回避する方法として使うべきではありません。

DNSの解決経路にも注意してください。ブラウザー、システム、Clashコア、リモートプロキシが異なる名前解決経路を使うことがあります。解決結果が異なると、別のCDNノードや誤ったアドレスへ接続される可能性があります。特定のドメインだけが異常な場合は、まずブラウザーのDNSキャッシュを消去し、設定内のDNSモード、nameserver、fallback、fake-ip関連の設定が現在のネットワーク環境に合っているか確認します。設定を変更した後は、実際に有効なのがそのファイルであり、読み込まれていないコピーを編集していないことを確認してください。

手順4：TLS、証明書ストア、HTTPSスキャンを確認する

証明書の発行者がローカルソフトウェアや組織のゲートウェイを示している場合は、システムのセキュリティソフト、企業プロキシ、ペアレンタルコントロール、デバッグプロキシのHTTPSスキャン機能を確認します。ソフトウェアによっては、ブラウザーと対象サイトの間に2つのTLS接続を確立し、独自のルート証明書でローカル用の代替証明書を発行します。管理対象デバイスで明確なネットワークポリシーとして運用されている場合は、管理者にルート証明書の配布状況と証明書の更新状況を確認してください。個人所有のデバイスでソフトウェア機能として有効になっている場合は、影響を理解したうえでHTTPSスキャンを無効にし、再テストできます。

ブラウザーが必ずしもシステムの証明書ストアを完全に使うとは限りません。ブラウザーによっては独自の証明書管理、暗号化DNS、セキュリティポリシーを有効にしているため、システムでは信頼されている証明書がブラウザーでは受け入れられないことがあります。テストでは、別のクリーンなブラウザープロファイルを使って比較できますが、「別のブラウザーなら開ける」ことを解決済みと判断しないでください。2つのブラウザーで証明書ストア、拡張機能、ネットワーク設定が異なることを示しているだけです。

エラーが証明書の発行者を信頼できないという内容ではなく、TLSバージョン、ハンドシェイク失敗、接続リセットに関するものなら、確認の重点を出口ノード、対象サイトとの互換性、中間ネットワーク機器に移します。この場合、ルート証明書を何度もインポートしても解決しないことがほとんどです。クライアント証明書が必要なサイト、企業内ネットワーク、相互TLSを使用するサービスでは、プロキシ経路がサイトの認証方式に対応しているかも確認してください。

TUNモードの重点確認項目

TUNモードではシステム通信が仮想ネットワークインターフェースへ取り込まれるため、ブラウザーに従来型のHTTPプロキシを設定していなくても、コアのルールの影響を受けることがあります。証明書エラーが発生したら、TUNだけを一時的に無効にしてシステムプロキシとの結果を比較できます。またはTUNを有効にしたまま直接接続ポリシーへ切り替えてテストします。目的は通信経路を特定することであり、特定のモードを固定的に推奨することではありません。

• TUNの仮想ネットワークアダプターが正常に作成され、他のVPN、仮想マシンのネットワークアダプター、ネットワーク高速化ソフトと競合していないことを確認します。
• DNSを現在のコアが引き受けているか、fake-ipのマッピングがブラウザー、システムのセキュリティソフト、LAN機器によって異常に処理されていないか確認します。
• 対象ドメインのルールマッチ履歴を確認し、ルールセットの期限切れによってリクエストが誤ったポリシーグループへ送られていないことを確認します。
• TUNを無効にすると正常に戻る場合は、すべての設定を直接リセットするのではなく、DNS、ルーティング、ネットワークアダプターの優先順位を引き続き比較します。

推奨される対処手順と安全上の注意

一連の流れは、安定した確認チェーンとして次のようにまとめられます。まずエラーを記録し、時刻を校正します。次に証明書のドメイン、有効期間、発行者を確認します。その後、同じサイトで直接接続とプロキシ接続を比較し、ノード、ルール、DNS、TUNの経路を確認します。最後に、ブラウザー、システム、セキュリティソフトの証明書ストアを確認します。各手順を終えるたびにページを再読み込みして結果を記録すると、どの変更が接続に実際の影響を与えたのかが分かります。

対処の常套手段として「証明書エラーを無視する」を選ばないでください。また、ページを開くためだけに見知らぬルート証明書をシステムへインポートしないでください。会社のデバイスでは、証明書やプロキシポリシーが管理者によって一元設定されている可能性があり、個人で変更するとコンプライアンスやアクセスに問題が生じます。公共ネットワークで証明書の発行者が異常な場合は、まず信頼できるネットワークに切り替えて検証してください。特定サイトの異常が長く続く場合は、サイト管理者にサーバー証明書チェーンとドメイン設定を確認してもらいます。

エラーコードを記録
  → システム時刻とタイムゾーンを校正
  → 証明書のドメイン / 有効期間 / 発行者を確認
  → 直接接続とプロキシで同じサイトを比較
  → ノード、ルールマッチ、DNSを確認
  → TUNの切り替えとブラウザーの証明書設定を比較
  → 入手元が明確な場合のみHTTPS検査証明書を処理

確認が終わったら、元のプロキシモードとセキュリティ設定に戻し、テストのため一時的に追加した証明書、ブラウザー拡張機能、ルールを削除することをおすすめします。問題が特定のノードだけで発生する場合は、一時的にノードを変更してサービス提供者へ報告してください。すべてのノードと複数のネットワークで同じエラーが発生するなら、デバイスの時刻、ブラウザー環境、対象サイトの証明書を優先して確認します。このように層ごとに切り分ければ、HTTPSエラーを漠然とした「プロキシが使えない」という状態から、証明書、名前解決、ルール、ネットワークのどの段階に問題があるのかまで絞り込めます。