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

まず切り分ける：Webサイトの証明書エラーか、プロキシノードのハンドシェイク失敗か

Clash の起動後にHTTPSエラーが発生しても、Clash がWebサイトの証明書を書き換えたとは限りません。通常のHTTP CONNECT、SOCKSプロキシ、TUN転送は接続を中継するだけで、ブラウザーと接続先サイトのHTTPS通信を復号しません。まず、どの区間で失敗しているかを確認し、ブラウザー、システムの証明書ストア、ノード設定のどれを調べるか判断しましょう。

ブラウザーのエラーコードだけでは原因を特定できません。たとえば ERR_SSL_PROTOCOL_ERROR はTLSプロトコル層のエラーであり、証明書が置き換えられた証拠にはなりません。HTTPSリクエストを通常のHTTPサーバーに送信した場合や、サーバーのTLS設定異常、ネットワーク機器によるハンドシェイクの中断でも発生します。

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

証明書には有効期間の開始日時と終了日時が記録されています。PCの時刻がこの期間外だと、正しいサーバーに接続していてもエラーになることがあります。スリープからの復帰、マザーボードの電池切れ、仮想マシンの時刻未同期などが原因でずれが生じます。DNSの変更やクライアントの再インストールを急ぐ前に、まず時刻を確認しましょう。

1. Windows 11：「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」をオンにします。タイムゾーンを確認してから「今すぐ同期」をクリックしてください。
2. macOS：「システム設定」→「一般」→「日付と時刻」を開き、日付と時刻の自動設定を確認します。変更が必要な場合は、システムの指示に従って認証してください。
3. Android：システム設定で「日付と時刻」を検索し、時刻とタイムゾーンの自動設定をオンにします。メニューの場所はメーカーによって異なります。
4. iOS：「設定」→「一般」→「日付と時刻」を開き、「自動設定」を確認します。デバイス管理ポリシーで変更が制限されている場合は、管理者に確認してください。

ブラウザーの証明書警告の詳細から証明書の表示画面を開き、「有効期間の開始」「有効期間の終了」「発行者」を記録します。デスクトップ版Chromiumブラウザーでは、開発者ツールの「セキュリティ」パネルから確認できる場合もあります。表示名や場所はブラウザーのバージョンによって異なります。

端末の日付が正しいのに、特定のサイトだけで証明書の期限切れが表示される場合は、サイトの管理者による更新が必要です。ノードを切り替えても期限切れの証明書は有効になりません。特定のノードだけで古い証明書が表示される場合は、その出口が別のサーバーに接続していないか、さらに確認してください。

手順2：同じURLで直接接続とプロキシ接続を比較する

比較テストでは、ドメインとパスを含むURL全体を同じにします。各テストで変更する条件は1つだけにし、エラーコード、証明書の発行者、適用されたルールを記録してください。ノード、DNS、ブラウザー、ネットワークを同時に変更すると、復旧しても原因を特定できません。

おすすめの4段階チェック

1. 現在の状態を記録：クライアントのモード、選択中のノード、システムプロキシ、TUNの有効・無効を記録します。「接続」一覧で対象ドメインを探し、実際に適用されているポリシーを確認してください。
2. 直接接続をテスト：システムプロキシとTUNをオフにし、ブラウザーのプロキシ拡張機能、手動プロキシ、ほかのVPNが通信を中継していないか確認します。同じURLにアクセスし、結果を記録してください。
3. プロキシを再度有効化：元の状態に戻してノードAを選びます。「接続」一覧で、リクエストが DIRECT ではなく実際にノードAを経由していることを確認してください。
4. ノードだけを切り替える：ノードBに変更し、ほかの設定はそのままにして、エラーコードと証明書情報を確認します。

直接接続は正常でノードAでは異常、ノードBでは正常なら、問題はノードAの出口経路、名前解決の結果、またはサーバー設定に絞られます。ただし、この結果だけで第三者による傍受とは断定できません。直接接続とプロキシ接続の両方で異常が出る場合は、端末の時刻、サイトの証明書、システムの証明書ストア、利用中のネットワークを優先して確認してください。

現在のネットワークから直接接続できないサイトもあります。直接接続時のタイムアウトは、証明書に問題がないことを示すものではありません。別の信頼できるネットワークや別の端末でも確認できますが、条件の違いを記録してください。別端末でアクセスできたからといって、この端末の設定に問題がないとは限りません。

コマンドでローカルプロキシ経由か確認する

クライアントの実際の混合ポートが 7890 の場合、Windowsターミナルで次のコマンドを実行できます。macOSとLinuxでは curl.exe の代わりに curl を使います。例のドメインはコマンドの書式を示すためのものです。調査時はエラーが発生したサイトのドメインに置き換えてください。

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

1つ目のコマンドはcurlの明示的なプロキシ設定を使いませんが、システムのTUNやほかのネットワークレベルの中継は回避できません。実行前にこれらの機能をオフにしてください。2つ目はローカルのHTTPプロキシを明示的に経由します。ポート番号はクライアントに表示されている値を使ってください。curlのビルドとブラウザーで異なる証明書ストアが使われる場合があるため、両者の結果が異なっても不自然ではありません。

手順3：中間者による傍受とルート証明書の入手元を確認する

企業のゲートウェイ、セキュリティソフトのHTTPSスキャン、パケットキャプチャツールなどは、端末またはネットワーク上でTLS通信を終端し、再発行した証明書をブラウザーに提示することがあります。そのルート証明書を端末が信頼していれば警告が出ない場合がありますが、証明書がない、期限切れ、または使用中のブラウザーに認識されない場合は、発行元が信頼されていないという警告が表示されることがあります。

まず証明書チェーンを確認し、証明書ストアへの対応を判断する

• ドメインを確認：証明書の「サブジェクトの別名」、つまりSANに、アドレスバーのホスト名が含まれているか確認します。証明書の表示名や組織名だけで判断しないでください。
• 発行者を確認：企業のゲートウェイ、パケットキャプチャツール、セキュリティソフトの名前が表示されている場合、インストール済みのツールや組織のポリシーと一致するか確認します。表示名だけでは証明書の信頼性を判断できません。
• 発生範囲を確認：無関係な複数のサイトで、同じローカル発行の証明書が突然表示され、特定の端末やネットワークだけで発生する場合は、共通のHTTPS検査機能を調べてください。

Windowsでは Win + R を押して certmgr.msc を実行し、現在のユーザーの「信頼されたルート証明機関」→「証明書」を確認できます。コンピューター単位の証明書は、該当する管理コンソールで確認してください。macOSでは「キーチェーンアクセス」で「システム」または「ログイン」キーチェーンを選び、証明書と信頼設定を確認します。

これらの画面は証明書の入手元を確認するためのもので、証明書を一括削除するためのものではありません。管理対象端末の証明書は業務上必要な場合があるため、管理者に確認してください。個人端末でパケットキャプチャツールを使った場合は、ツールの説明に従ってHTTPS復号を停止し、信頼設定を解除してから再テストします。見知らぬダウンロードページから「Clash専用ルート証明書」と称するものをインストールしないでください。通常のプロキシ転送にこの操作は必要ありません。

手順4：DNSの異常とノードのTLS設定ミスを切り分ける

DNSの名前解決エラーが証明書エラーに見える理由

DNSがドメインを誤ったアドレスに解決しても、ブラウザーは接続先に対して元のドメイン名を検証します。誤ったサーバーが別ドメインの証明書を返すと、名前の不一致が発生します。サーバーが接続を切断した場合は、ハンドシェイクエラーとして表示されることがあります。DNS自体が証明書を発行するわけではないため、名前解決結果、接続先、証明書のSANを合わせて確認してください。

Windowsでは Resolve-DnsName example.com でシステムの名前解決結果を確認できます。macOSとLinuxでは nslookup example.com が参考になります。ただし、ブラウザーの「セキュアDNS」、mihomo内蔵DNS、プロキシ側のリモート名前解決では経路が異なる場合があります。システムコマンドの結果がブラウザーの実際の名前解決結果とは限りません。

• クライアントの「接続」と「ログ」で対象ドメイン、適用ルール、出口ポリシーを確認し、リクエストの実際の接続先を特定してください。
• 現在有効な設定の dns、nameserver、nameserver-policy、TUNのDNSハイジャック設定を確認します。読み込まれていない設定ファイルだけを変更しないよう注意してください。
• fake-ipを使用している場合、198.18.0.0/16 の範囲のアドレスが表示されても、必ずしもDNS汚染ではありません。mihomoで一般的に使われるデフォルトのfake-ipアドレス範囲は 198.18.0.1/16 です。これらは内部マッピング用のアドレスで、Webサイトの実際の接続先アドレスではありません。
• 名前解決のポリシーを変更したら、接続を確立し直してテストしてください。既存の接続やキャッシュが以前の結果を使い続けることがあります。最初からすべてのDNS項目を同じパブリックDNSに置き換えるのは避けましょう。

ノードの証明書エラーは別の接続区間で発生する

TLSを使うプロキシプロトコルでは、クライアントもプロキシサーバーの証明書を検証します。これはブラウザーがWebサイトの証明書を検証する処理とは別です。ログの接続先がノードサーバーで、ブラウザーにトンネル接続の失敗が表示される場合は、サブスクリプション提供元のサーバーアドレス、ポート、TLSパラメーターを優先して確認してください。

mihomoで一般的なTLSノード設定を例にすると、server は接続先アドレス、port はサーバーの待ち受けポートです。プロトコルによっては servername でTLSサーバー名を指定し、別の設定形式では sni を使います。利用できる項目はプロトコルとコアの対応状況によって異なるため、あるプロトコルの設定を別のプロトコルにそのまま流用しないでください。

影響範囲に合わせて対処し、再現できる記録を残す

ここまでの調査結果をもとに、影響範囲に合わせて対応を絞り込みます。アクセスが復旧しただけでなく、誤った信頼設定や一時的に緩めた検証オプションが残っていないことも確認してください。

公衆Wi-Fiでは、先にポータルでの認証が必要な場合があります。OSに表示されるネットワークログイン画面を使い、HTTPS証明書の警告を無視してアカウント情報を入力しないでください。ネットワークの正当性を確認できない場合は接続を中止し、信頼できるネットワークに切り替えましょう。

問い合わせ時に添える情報

• OS、ブラウザーのバージョン、クライアントのバージョン、コアの名称。「バージョン情報」またはコア情報の画面で確認できます。
• 発生時刻、対象ドメイン、ブラウザーに表示されたエラーコード全体、証明書のSAN・発行者・有効期間。
• 直接接続、ノードA、ノードBでの比較結果と、システムプロキシおよびTUNの有効・無効。
• エラー発生前後の関連ログ。サブスクリプションURL、ノードのパスワード、トークン、アカウント情報、公開に適さないアドレスは伏せてください。

OSやブラウザーを長期間更新していない場合は、公式のOS更新機能とブラウザーの更新機能を使って、提供されているセキュリティ更新を適用してから証明書チェーンを再確認してください。クライアントを変更する場合は、現在のポート、ルールモード、TUNの状態を先に記録し、インストールの変更とネットワークの問題を混同しないようにしましょう。基本設定についてはシステムプロキシの設定方法を、名前解決の問題についてはDNSのトラブル対処を参照してください。

安全に対処するには、エラーを記録し、時刻を合わせ、接続経路を比較し、証明書の入手元を確認してから、DNSやノードの設定を調べます。証明書検証は有効なままにし、「Webページが開けた」ことだけを解決の基準にしないでください。