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

まずエラーの種類を確認：証明書検証エラーと接続エラーは別

Clashを起動した後に「この接続ではプライバシーが保護されません」と表示されても、クライアントがWebサイトの証明書を書き換えているとは限りません。通常のHTTP CONNECT、SOCKS、TUNによる転送では、接続先サイトの証明書は発行されません。ブラウザーは引き続き証明書チェーン、有効期間、ドメイン名を検証します。プロキシによって変わるのは通信経路です。経路上のDNS、出口、認証ゲートウェイ、通信解析ツールなどが、ブラウザーに別の証明書を返すことがあります。

まずアドレスバーに表示されているホスト名全体とエラーコードを控え、警告ページから証明書の詳細を開きます。表示場所はブラウザーによって異なりますが、「発行者」「有効期間」「サブジェクト代替名（SAN）」を記録してください。証明書の表示名だけで判断せず、ドメイン名の一致はSANを基準に確認します。

システム時刻と信頼ストア：まず端末側の検証条件を確認

日付、時刻、タイムゾーンを確認

証明書には有効期間が設定されています。スリープからの復帰後、マザーボードの電池切れ、手動での時刻変更などにより、システム時刻が実際の時刻とずれることがあります。複数の無関係なサイトで日付エラーが出る場合は、ノードを次々に切り替える前に端末側を確認してください。

1. Windows 11では「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」とタイムゾーンを確認してから、「今すぐ同期」を実行します。
2. macOSでは「システム設定」→「一般」→「日付と時刻」を開き、日付と時刻の自動設定を確認します。管理対象の端末では管理者権限が必要な場合があります。
3. ブラウザーを再起動し、同じドメインにアクセスします。エラーが1つのサイトだけに残る場合は、そのサイトの証明書が実際に期限切れか確認してください。

Windowsでは次のコマンドで現在の時刻とWindows Timeサービスの状態を確認できます。2つ目のコマンドでサービスが実行されていないと表示された場合、時刻同期の状態をこの方法では確認できていません。HTTPS自体の障害を示すわけではありません。

Get-Date
w32tm /query /status

証明書チェーンの不足と信頼ストアの古さを見分ける

古いOS、長期間更新していないブラウザー、Webサイト側での中間証明書の設定漏れなどが、証明書チェーンのエラーにつながることがあります。まずOSとブラウザーを通常の方法で更新し、同じ端末の別のブラウザーでも確認してください。ブラウザーごとにルート証明書の仕組みが異なる場合があるため、「別のブラウザーなら開ける」ことだけでサーバー証明書が正しいとは証明できません。

複数の端末・ネットワークで同じサイトだけエラーになり、ほかのサイトは正常な場合は、サイト管理者による証明書設定の修正が必要かもしれません。検索結果やエラーページから入手した出所不明の証明書を、「信頼されたルート証明機関」にインポートしないでください。

HTTPS通信の解析・検査：証明書の発行者を確認

Fiddler、Charles、mitmproxyなどの通信解析ツールでHTTPS復号を有効にすると、ローカルで信頼されたルート証明書を使ってWebサイトの証明書を動的に発行します。企業のセキュリティゲートウェイや一部のセキュリティソフトにある「HTTPSスキャン」も、同様の仕組みを使うことがあります。ルート証明書が正しくインストールされていない、期限切れになっている、またはブラウザーがその信頼元を受け入れない場合、証明書警告が表示されます。

プロキシ設定と通信解析プロセスを照合

• 通信解析ツールが起動したままになっていないか、HTTPS復号が有効か、システムプロキシが設定されているかを確認します。
• Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」を開き、「プロキシサーバーを使う」のアドレスとポートを控えて、Clashクライアントの現在の待ち受け設定と照合します。
• 証明書の「発行者」が通信解析ツール名や組織名に変わっていないか確認します。見慣れない名前があっても、名前だけで攻撃と判断せず、追加で調査してください。
• 個人利用の通信解析ツールを終了し、クライアントのシステムプロキシを再度有効にして確認します。企業管理端末では管理者に相談し、組織の証明書やセキュリティポリシーを勝手に削除しないでください。

127.0.0.1:7890はよく使われるローカルプロキシの例で、すべてのクライアントに共通する固定ポートではありません。通信解析ツールとClashが順番にシステムプロキシを書き換えると、後から設定した値が前の設定を上書きすることがあります。また、ポートが別のプロセスに使われていると、想定外のローカルサービスに接続される場合があります。

通常のClash/mihomoによる転送では、ブラウザーにルート証明書をインストールする必要はありません。「プロキシの修復方法」と称する案内で不明なルート証明書のインストールを求められたら、操作を中止してください。ルート証明書のインストールは信頼の付与であり、速度向上の設定ではありません。

Fake-IPとDNSキャッシュ：マッピングをカーネルが管理しているか確認

mihomoのFake-IPモードでは、ドメインに対してマッピング用のIPアドレスを返します。よく使われる設定範囲は198.18.0.1/16です。カーネルはマッピングからドメインを復元し、ルール判定と接続を行います。このアドレスはWebサイトの実際のグローバルIPではなく、HTTPSのテスト用URLにそのまま使うものでもありません。

Fake-IP自体が証明書を発行したり、ブラウザーの信頼ストアを書き換えたりすることはありません。よくあるのは、ブラウザーやシステムに古いFake-IPアドレスが残ったまま、TUN、DNSハイジャック、クライアントが停止し、マッピングを管理するカーネルに通信が戻らなくなるケースです。通常は接続エラーになりますが、通信が誤ったTLSサービスに届くと、ドメイン不一致などの証明書エラーにつながることがあります。

順番にDNSと接続状態を復旧

1. 現在の「システムプロキシ」と「TUNモード」の状態、および使用中の設定にあるdns.enhanced-mode、fake-ip-range、fake-ip-filterを記録します。すべての設定を一度に変更しないでください。
2. エラーが出たページを閉じ、クライアントのカーネルが動作中であることを確認して、現在の設定を読み込み直します。クライアントにDNSまたはFake-IPキャッシュの削除機能がある場合は、作用を確認してから実行してください。
3. Windowsではコマンドプロンプトでipconfig /flushdnsを実行し、ブラウザーを完全に終了してから再起動します。システムのキャッシュを消去しても、ブラウザーやルーターのキャッシュがすべて自動的に消えるわけではありません。
4. 元のドメインに再度アクセスし、クライアントの「接続」または「ログ」で、そのドメインが表示されるか、適用されたルールとプロキシ経路を確認します。

ブラウザーの「セキュアDNS」によって、ドメインの名前解決経路が変わることがあります。Chromeでは「設定」→「プライバシーとセキュリティ」→「セキュリティ」→「セキュアDNSを使用する」から確認できます。項目はバージョンや組織のポリシーによって異なります。調査する場合は元の設定を記録して一時的に無効にし、確認後に元へ戻してください。セキュアDNSの無効化を、あらゆる証明書エラーに効く対処法と考えないでください。

ノード、出口、認証ゲートウェイ：条件を1つずつ変えて原因を絞る

端末の時刻が正しく、HTTPS復号ツールも見つからない場合は、次に通信経路を比較します。ノードの障害、出口側DNSの異常、公衆Wi-Fiのログインゲートウェイ、誤ったルールによる振り分けなどで、接続先が別のサーバーになることがあります。通常、プロキシノードがブラウザーに信頼される接続先サイトの証明書を偽造することはできません。証明書警告は重要な安全境界です。「とりあえずページを開く」ために検証を回避しないでください。

一度に変更する条件は1つだけ

1. 同じ端末、同じブラウザー、同じURLを使い、現在のモード、適用されたルール、実際に選択されたノードを記録します。プロキシグループで自動選択を使っている場合、テスト中にノードが切り替わっていないかも確認してください。
2. ほかの設定は変えずに、別の信頼できるノードへ切り替え、エラーコードと発行者が変わるか確認します。
3. ネットワークの利用条件に問題がない場合は、直接接続もテストします。TUNが有効なままでは、「システムプロキシ」を無効にしただけで直接接続になるとは限りません。該当する通信の取り込みを明示的に停止するか、接続先がDIRECTになっていることを確認してください。
4. 可能であればスマートフォンのテザリングでも試します。特定のWi-Fiだけで発生する場合は、ネットワークのログイン認証が必要か確認してください。システムのネットワークログイン画面を使い、証明書警告ページに認証情報を入力しないでください。

特定のノードだけで問題が起きる場合は、そのノードで機密性の高い通信を行わず、ドメイン、発生時刻、エラーコード、証明書の発行者をサービス提供元に伝えてください。1回のドメイン不一致だけで「ノードによる通信の乗っ取り」とは断定できません。ただし、無関係な複数のサイトで突然同じ見知らぬ証明書が表示された場合は、その経路をすぐに使用停止し、確認すべき兆候です。

実際の経路はルールで確認する。モード名だけでは判断できない

ルールモードでは、ログでDOMAIN-SUFFIX、GEOIP、末尾のMATCHのどれが適用されたかを確認し、最終的なポリシーも確認してください。プロキシグループの名前が「自動選択」や「Proxy」でも、想定した出口を通るとは限りません。グループ内でDIRECTが選ばれる場合もあります。TUNは通信を取り込む機能であり、誤った証明書を修正するものではありません。全般モードへの切り替えも、ルールの確認に代わるものではありません。

コマンドラインで再確認：ポートと検証の範囲を明確にする

以下では、Windows標準のcurl.exeを使い、公開されているドメインを比較します。クライアントのHTTPまたはmixed待ち受けポートが7890であると仮定しています。実行前に実際のポート番号へ置き換えてください。SOCKS専用ポートはHTTPプロキシとして使えません。-Iはレスポンスヘッダーを要求し、-vは接続とTLSの診断情報を表示します。

curl.exe -Iv --proxy http://127.0.0.1:7890 https://example.com/
curl.exe -Iv --noproxy "*" https://example.com/

2つ目のコマンドはcurlで明示的にプロキシを使わないだけで、動作中のTUN、透過型ゲートウェイ、企業ネットワーク機器を迂回するものではありません。通信経路を実際に比較するには、まず通信の取り込み状態を確認してください。curlのビルドによってTLSバックエンドや証明書ストアが異なる場合もあります。コマンドでは成功してブラウザーで失敗する場合も、ブラウザーの証明書ポリシー、拡張機能、キャッシュを確認してください。

• 127.0.0.1に接続できないと表示される場合は、まずカーネルの動作状態と待ち受けポートを確認してください。すぐにDNSを変更する必要はありません。
• プロキシトンネルの確立後に証明書エラーが発生する場合は、その後のTLS検証を重点的に確認します。トンネルが確立しても、証明書が信頼できるとは限りません。
• 証明書検証に成功して403または429が返る場合は、HTTPアクセス制限またはリクエスト頻度制限です。証明書エラーではありません。
• 証明書検証に失敗した場合は、エラー全文を記録し、時刻、ドメイン、信頼チェーン、通信経路を引き続き確認してください。-kや--insecureで問題を隠さないでください。

設定を元に戻し、障害情報を共有

調査が終わったら、一時的に無効にしたセキュアDNS、変更したプロキシモード、テスト用ノードを、使用予定の状態に戻します。設定を変更した場合は、元のファイルと変更内容を保存してください。次回のサブスクリプション更新でローカルの変更が上書きされ、同じ問題が再発するのを防げます。サブスクリプションURLを問い合わせ窓口や公開フォーラムに直接貼り付けないでください。

クライアントの開発者、Webサイト管理者、ネットワーク管理者に報告する際は、次の情報を伝えると、「Clashを起動するとエラーになる」だけの場合より原因を特定しやすくなります。Clash配布ステーションではクライアントのダウンロードと使い方を案内していますが、クライアントの公式開発チームではありません。具体的な不具合は該当プロジェクトまたはサービス提供元に報告してください。

• OS、ブラウザー、クライアント、mihomoカーネルの完全なバージョン番号。各ソフトの「バージョン情報」またはバージョン表示画面で確認します。
• エラーが発生したホスト名、発生日時とタイムゾーン、ブラウザーのエラーコード、証明書の発行者と有効期間。
• システムプロキシとTUNの状態、実際の待ち受けポート、適用されたルールの種類と最終ポリシー。ノード名は匿名化できます。
• ノードの切り替え、直接接続の確認、ネットワークの変更後に同じURLでどうなったか。それぞれの手順で変更した条件を明記します。

推奨する確認順は、エラーを記録 → 時刻を確認 → 証明書チェーンと復号ツールを確認 → 不整合のあるDNS状態をクリア → ノードとネットワーク経路を比較、です。通信の取り込み方法を確認する場合は、システムプロキシの設定、ルール設定ガイド、トラブル対処を参照してください。証明書検証が正常に戻ってから、ログインなどの機密性の高い操作を行ってください。