プロキシ利用後のHTTPS証明書エラー：主な原因・切り分け方法・解決手順

Clash、Clash Meta（mihomo）クライアントを起動すると、ブラウザに突然「接続はプライベートではありません」「証明書が信頼されていません」「証明書とドメインが一致しません」と表示されたり、アプリでTLSハンドシェイクの失敗が報告されたりすることがあります。こうした現象はプロキシノードが原因だと思われがちですが、HTTPSの検証にはシステム時刻、対象サイトの証明書、DNS解決、OSの信頼ストア、上流ネットワーク機器、アプリ独自の証明書ポリシーなどが関係します。プロキシが変えるのは、その接続経路の一部にすぎません。

標準的なHTTP CONNECT、SOCKS5、TUNによる転送では、HTTPSの内容が自動的に復号されることはありません。通常、クライアントは暗号化された通信を選択した出口へ転送するだけで、Webサイトの証明書は対象サーバーが提供します。mihomoのドメインスニッフィングは通信に対応するホスト名を識別する機能であり、Webサイトの証明書を置き換えるものではありません。したがって、サブスクリプションを何度も読み込み直したり、むやみにプロキシモードを切り替えたりするのではなく、まずエラーの種類を確認し、比較テストでどの層に異常があるかを絞り込むことが重要です。

HTTPS証明書エラーの種類を見分ける

HTTPS接続の確立時、クライアントは証明書の有効期間、アクセス先ドメイン、発行チェーン、用途を確認します。エラーごとに原因は異なります。ブラウザのエラーコード、エラーが出たドメイン、証明書の発行者、有効期間を記録しておくと、「開けない」とだけ分かるスクリーンショットを保存するよりも原因究明に役立ちます。

証明書がまだ有効でない、または期限切れ

まずパソコンやスマートフォンの日付、時刻、タイムゾーンを確認します。システム時刻が数か月ずれていると、多くの正常なWebサイトで同時にエラーが発生します。1つのサイトだけで失敗する場合は、サイトの証明書期限切れ、サーバーへの反映漏れ、または特定の出口から未更新の証明書を持つエッジノードへ接続している可能性が高くなります。自動時刻合わせを有効にしても正しくならない場合は、時計に表示される時刻だけでなく、システムで選択されているタイムゾーンも確認してください。

証明書のドメインが一致しない

証明書に記載されたホスト名とアドレスバーのドメインが異なる状態です。別のWebサイト、ネットワークのログインページ、内部ゲートウェイ向けに発行された証明書が表示されるケースがよくあります。原因として、DNSが誤ったアドレスを返している、ローカルのhosts設定が上書きしている、透過型ゲートウェイがリダイレクトしている、対象サイトの仮想ホスト設定に誤りがある、プロキシの出口が異常なサーバーへ接続している、といった可能性が考えられます。ルーターの管理ドメイン、公衆Wi-Fiのログインドメイン、見覚えのない企業ゲートウェイ向けの証明書が表示された場合は、現在のネットワークで認証が必要かどうかを優先的に確認してください。

証明書の発行者が信頼されていない、または証明書チェーンが不完全

サーバーはサイト証明書から中間証明書までの完全なチェーンを提供し、システムは内蔵された信頼済みルート証明書を使って検証します。古いシステムでルート証明書ストアが長期間更新されていない、サイトが中間証明書を送信していない、企業のセキュリティゲートウェイがHTTPS検査を行っている、といった状況でこのエラーが発生します。ブラウザによっては独自の証明書ストアを使用するため、同じサイトでもブラウザごとに結果が異なる場合があります。これは信頼ストアの問題を特定する重要な手がかりです。

TLSハンドシェイクに失敗するが、明確な証明書画面が表示されない

コマンドラインツールやアプリでは、handshake failed、certificate verify failed、unknown CAなどの短いメッセージしか表示されないことがあります。クライアントが対応するTLSバージョン、サーバー名表示、アプリの証明書ピンニング、上流プロキシのプロトコルエラー、接続の途中切断などが関係する場合もあります。この場合はClashのログとアプリのログを照合し、ノードへの接続時、対象アドレスへの接続時、対象サーバーの証明書を受信した後の検証時のどこで失敗したのかを確認します。

比較テストで問題が端末・ネットワーク・プロキシ経路のどこにあるか特定する

効果的なトラブルシューティングでは、一度に1つの条件だけを変更します。ノード、DNS、TUN設定、ブラウザを同時に変更すると、どの変更が結果に影響したのか分からなくなります。まず安定して再現できるドメインを1つ選び、現在の設定名、プロキシモード、ポリシーグループ、選択中のノードを記録してください。

プロキシを無効にして同じドメインへアクセスします。クライアントのシステムプロキシとTUNによるトラフィックの横取りを無効にし、確実に直接接続へ戻っていることを確認します。直接接続でもエラーが出る場合は、システム時刻、サイトの証明書、現在のネットワークを優先的に確認してください。
設定を変えずに、ノードだけ切り替えます。特定のノードだけ失敗し、他のノードが正常なら、その出口のDNS、上流ネットワーク、透過型検査装置、または対象サイトが地域ごとに返すサーバーに原因がある可能性が高いです。
ノードを固定したまま、システムプロキシとTUNを比較します。TUNモードだけで異常が起きる場合は、DNSハイジャック、Fake-IPマッピング、ルート競合、他のネットワークフィルタリングソフトを確認します。システムプロキシだけで異常が起きる場合は、アプリが独自のプロキシ設定を読み込んでいないか確認してください。
別のブラウザまたはコマンドラインクライアントでテストします。特定のブラウザだけが失敗する場合は、ブラウザの証明書ストア、拡張機能、キャッシュされたHSTS状態、セキュリティ設定が関係している可能性があります。すべてのアプリで失敗する場合は、システムまたはネットワーク層の問題に近いと考えられます。
同じネットワークのまま別の端末で試します。1台だけが失敗する場合は、その端末の時刻、証明書ストア、ネットワークコンポーネントを確認します。同じネットワーク内の複数の端末で失敗する場合は、ルーター、公衆ネットワークの認証、上流ゲートウェイを確認してください。
同じ端末のままネットワークを変更します。家庭のネットワークでは失敗するがモバイルネットワークでは正常な場合、問題はクライアント設定そのものよりも、ローカルDNS、ゲートウェイ、通信事業者の経路にある可能性が高くなります。

システム時刻・証明書チェーン・中間プロキシを確認する方法

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

まずシステムを信頼できる時刻ソースと同期し、ブラウザを完全に終了して再起動します。証明書の詳細を開き、「発行先」「発行者」「有効期間の開始・終了日時」「証明書パス」を確認してください。現在の日付が有効期間内にない場合でも、ページの表示だけを根拠にサイト証明書が期限切れだと判断しないでください。システムの年が間違っていても同じ結果になります。

デスクトップOSの更新を長期間停止していると、ルート証明書ストアも古くなっている可能性があります。証明書の信頼情報は、身元不明のページからルート証明書をダウンロードして手動でインストールするのではなく、OSの正式な更新機能で更新してください。組織のネットワークで内部ルート証明書のインストールが必要な場合は、まずネットワーク管理者に証明書のフィンガープリント、対象端末、適用範囲を確認し、組織の手順に従って対応します。

HTTPS検査と中間プロキシを見分ける

企業ゲートウェイ、ペアレンタルコントロール、セキュリティソフト、デバッグプロキシは、元のTLS接続をいったん終端し、ローカルで信頼された証明書を使って対象ドメイン向けの一時証明書を発行することがあります。この場合、証明書のドメインは正しくても、発行者が組織名やローカルのセキュリティ製品名になります。対応するルート証明書がインストールされていない、期限切れである、またはシステムストアにしかインストールされておらずブラウザ独自の証明書ストアに入っていない場合、信頼されていない証明書のエラーが発生します。

通常のClashのルール分岐で、このような証明書の置き換えが行われることはありません。見覚えのない発行者が表示された場合は、同時に動作しているパケットキャプチャツール、フィルタリングプログラム、ウイルス対策ソフトのHTTPSスキャン、企業プロキシ、上流HTTPプロキシを確認してください。警告を消すために、ページで案内されたルート証明書を無条件にインポートしないでください。ルート証明書を信頼すると、あらゆるWebサイトの証明書発行に悪用される可能性があります。

コマンドでハンドシェイク結果を確認する

システムに対応するツールがインストールされていれば、レスポンスと証明書チェーンを確認できます。以下のコマンドのドメインは、実際にエラーが発生したサイトへ置き換えてください。実行時は証明書検証を維持し、検証をスキップするオプションは追加しないでください。

curl -Iv https://example.com/
openssl s_client -connect example.com:443 -servername example.com -showcerts

curlの出力では接続先、プロキシトンネルの確立結果、証明書検証の理由を確認できます。openssl s_clientではサーバーが返した証明書チェーンを確認できます。システムプロキシを使用する場合は、コマンドラインツールが実際にプロキシ環境変数を読み込んでいるかも確認してください。読み込んでいなければ、測定しているのは直接接続の経路かもしれません。テスト結果でノードごとに証明書の発行者が変わるなら、各出口から対象サイトまでの経路に違いがあります。発行者が常に同じで、特定のアプリだけが失敗するなら、アプリの信頼ストアと証明書ピンニングポリシーを確認します。

Clashのシステムプロキシ・TUN・DNSが証明書エラーに与える影響

システムプロキシモード

システムプロキシでは通常、プロキシ設定に対応したアプリがHTTPまたはSOCKSインターフェースを介して接続します。HTTPSサイトへアクセスする際、HTTPプロキシは一般にCONNECTで対象ホストへのトンネルを確立し、TLSハンドシェイクはアプリとWebサイトの間で行われます。CONNECTリクエストが上流プロキシに拒否・置換されたり、追加認証を要求されたりすると、アプリにプロキシ接続失敗と表示されることがあります。また、ゲートウェイが生成した証明書ページを受け取る場合もあります。

システムプロキシを読み込まず直接接続するアプリもあれば、独自のプロキシ設定を保持するアプリもあります。「ブラウザは正常だが特定のアプリだけ失敗する」場合は、そのアプリがシステムプロキシ、TUN、独自のネットワークスタックのどれを使っているかを確認してください。Clashのログに該当する接続記録がない場合、ルール選択の誤りではなく、通信がそもそもクライアントに入っていない可能性があります。

TUNモード

TUNモードはネットワーク層でより多くの通信を取り込み、システムプロキシに対応していないアプリにも適しています。ただし、パケットのルーティングとDNSの処理方法が変わるだけで、取り込む範囲が広いからといってTLSが自動的に復号されるわけではありません。TUNを有効にしてから証明書のドメイン不一致が発生した場合は、DNSモード、他の仮想NIC、ルートの優先順位、端末上で別のVPNやフィルタリングサービスが同時に動作していないかを重点的に確認します。

複数のネットワークコンポーネントが同時に通信を取り込むと、パケットが最初に1つのフィルターを通過してからmihomoへ入り、戻りの経路も一致しないことがあります。切り分け時はいったん通信を取り込むコンポーネントを1つだけ残し、問題が解消することを確認してから、1つずつ再び有効にしてください。モバイル端末では通常、主要なVpnServiceは1つしか使用できません。別のアプリにセッションを置き換えられると、明確な証明書エラーではなく通信断として現れることもあります。

Fake-IP・ドメインスニッフィングと証明書のドメイン

Fake-IPモードでは、まずアプリに予約アドレスを返し、その後カーネルがマッピングから元のドメインを特定して接続します。この処理自体によってWebサイトの証明書がFake-IPアドレスになることはありません。ブラウザは元のアクセス先ドメインに基づいて証明書を検証するためです。実際に確認すべきなのは、マッピングの期限切れ、DNSリクエストがクライアントを迂回していること、特殊なアプリが証明書や接続先アドレスを直接検証していること、不適切なhosts設定による上書きです。

ドメインスニッフィングはTLS ClientHelloなどの情報からホスト名を識別し、ルールのマッチングを助けます。しかし、スニッフィングは証明書を発行する機能ではなく、システムの信頼設定を変更するものでもありません。スニッフィングを無効にするとエラーが消える場合は、追加のルート証明書をインストールするのではなく、ルールのマッチ結果、対象アドレスの復元、特殊ドメインの除外設定を詳しく確認してください。LAN内サービス、プライベートドメイン、自署証明書を使用する機器については、用途に応じて直接接続とDNSの例外を設定できますが、証明書は組織または機器の正式な手順で配布する必要があります。

リスクと手間で優先順位を付ける解決手順

以下では、低リスクで確認しやすい操作から順に説明します。「プロキシを有効にするとHTTPS証明書エラーが出る」多くのケースに適した手順です。各ステップの完了後、同じドメインで再テストし、結果を記録してください。

日付・時刻・タイムゾーンを修正します。自動同期を有効にし、エラーが発生したアプリを再起動します。多くのサイトで同時に「期限切れ」や「まだ有効でない」と表示される場合は、この手順を最優先します。
エラーが1つのサイトだけで発生しているか確認します。単一サイトの異常であれば、サイト証明書の有効期間とドメインを確認し、サイト管理者の修正を待ちます。1つのサイトに合わせるために、全体の証明書検証を無効にしないでください。
公衆ネットワークのログインを完了します。プロキシを無効にして通常のネットワーク検知ページを開き、ホテル、学校、商業施設のネットワークで認証待ちになっていないことを確認します。ログインが完了してからプロキシを再び有効にしてください。
正常なことが確認できているノードへ切り替えます。特定の出口だけが失敗する場合は、そのノードを一時的に外し、対象ドメイン、発生時刻、ノード名を添えてサービス提供元へ報告します。
Clashのルールマッチとログを確認します。対象ドメインが想定したポリシーグループに入り、利用できない上流プロキシへ送られていないことを確認します。ログに出るDNS失敗、接続拒否、TLSエラーは、それぞれ分けて対処してください。
システムプロキシとTUNを比較します。どちらの取り込み方式で異常が発生するかを特定し、その方式に対応するプロキシ設定、仮想NIC、DNS、ルーティングを確認します。すべての設定を同時に変更するのは避けてください。
競合するネットワークフィルタリングコンポーネントを停止して再テストします。VPN、パケットキャプチャプロキシ、HTTPSフィルタリング機能は一度に1つだけ停止し、テスト後は必要に応じて元に戻してください。
OSとブラウザを更新します。ルート証明書ストア、TLSコンポーネント、ブラウザの信頼データをサポート対象の状態に保ちます。古いアプリでは新しい証明書チェーンを認識できないことがあります。
組織内証明書の配布方法を確認します。企業や学校のネットワークで内部CAを使用している場合は、管理者から正式なインストール方法を案内してもらいます。エラーページから証明書を一時的にダウンロードしてはいけません。
最後にクライアント設定の確認または再構築を行います。ログにDNS、ルール、上流プロキシ設定の異常が示されている場合に限り、YAML、サブスクリプション、設定ファイルを調整します。同じ問題のある設定を再インポートしても、証明書チェーンは変わりません。

よくある誤解と追加の切り分け

グローバル・ルール・直接接続を何度も切り替える

モード切り替えで変わるのは、通信がどのポリシーを使うかだけです。システム時刻やルート証明書ストアが修復されるわけではありません。比較テストとして、直接接続は正常でプロキシだけ失敗するなら出口とプロキシ経路を確認し、3つのモードすべてで失敗するなら端末またはネットワーク環境を先に確認します。テスト後は元のモードに戻し、その後の結果が混乱しないようにしてください。

すべてのTLSエラーをDNSのせいにする

DNSがドメインを誤ったサーバーへ向け、ドメイン不一致を引き起こすことはあります。しかし、「信頼されていない発行者」は証明書チェーンやHTTPS検査を示すことが多いです。まず実際の証明書の内容を確認し、そのうえでDNSキャッシュの削除、リゾルバーの切り替え、Fake-IPの確認を行うか判断してください。DNSだけを変更しても、期限切れの証明書や欠落した中間証明書は修復できません。

自署証明書を見つけたらすぐインストールする

家庭用ルーター、開発環境、企業内サービスでは自署証明書が使われることがありますが、インストール前にサービスの所有者と証明書の出所を必ず確認してください。公開Webサイトで突然自署証明書が表示されるのは通常の状態ではありません。見覚えのないゲートウェイから証明書が提示された場合は、アカウント情報の入力を中止し、ネットワーク認証、プロキシ設定、端末内のルート証明書の変更を確認してください。

特定のアプリだけが失敗する

銀行、決済、動画配信、一部の企業向けアプリでは証明書ピンニングを使用し、あらかじめ組み込まれたサーバー公開鍵や証明書チェーンだけを受け入れることがあります。システムが中間プロキシ発行の証明書を信頼していても、アプリは接続を拒否します。これは通常、通信経路にTLS検査が存在するか、対象接続が置き換えられていることを示します。関連する検査装置をそのアプリの経路から外すか、組織のネットワーク規程に従って設定してください。アプリの検証ロジックを変更しようとするのは適切ではありません。

切り分けの流れは、次の4つの問いにまとめられます。証明書の発行者は誰か、端末を変えるとエラーも変わるか、ネットワークを変えるとエラーも変わるか、ノードやトラフィックの取り込み方式を変えるとエラーも変わるか。これらに答えることで、システム時刻と信頼ストア、対象サイト、現在のネットワーク、特定のプロキシ出口、端末側のトラフィック制御コンポーネントのいずれに問題があるか、通常は絞り込めます。目指すのは警告ページを一時的に消すことではなく、正しい証明書チェーンと接続経路を復元することです。