プロキシ接続時の証明書エラー対処

まず証明書エラーが発生している箇所を特定する

プロキシ接続後に証明書の警告が表示されても、Clashにルート証明書をインストールする必要があるとは限りません。一般的なHTTP CONNECT、SOCKS、TUNによる転送は通信経路を変えるだけです。ブラウザーは引き続き接続先サイトとTLSハンドシェイクを行い、サイト証明書を検証します。エラーコード、証明書のドメイン名と発行者を確認してから、システム時刻や実際の出口を調べましょう。クライアントを再インストールするより、原因を順に切り分けるほうが効果的です。

ここでは、異なる2つの暗号化接続が関係します。1つはブラウザーと接続先サイト間のHTTPS、もう1つはプロキシのコアとノードサーバー間のTLSです。ブラウザーに表示される NET::ERR_CERT_AUTHORITY_INVALID と、コアのログに記録される x509: certificate signed by unknown authority は、同じ障害として扱えるとは限りません。

NET::ERR_CERTの末尾まで記録する

「この接続ではプライバシーが保護されません」は警告の見出しにすぎず、原因の特定には後ろに表示されるエラーコードが重要です。ChromeとEdgeのコードは似ていますが、Firefoxでは名称が異なります。調べるポイントは共通しています。ブラウザーのバージョン、システムの信頼ストア、組織のポリシーによって、表示内容が変わることもあります。

• NET::ERR_CERT_DATE_INVALID：端末の時刻が正しくないか、証明書の有効期限が切れている、または有効期間の開始前です。端末の日付と証明書の有効期間を照合してください。画面右下の時刻だけを見て判断しないようにしましょう。
• NET::ERR_CERT_AUTHORITY_INVALID：信頼できる発行チェーンを構築できません。自己署名証明書、中間証明書の不足、端末の信頼ストアの異常、HTTPS検査ツールなどが原因として考えられます。
• NET::ERR_CERT_COMMON_NAME_INVALID：アクセス先のドメインが証明書のSAN（サブジェクト代替名）に含まれていません。旧エラー名にCommon Nameとあっても、現在のブラウザーがCNだけを確認しているわけではありません。
• NET::ERR_CERT_REVOKED：証明書が失効していると判定されました。サイト運営者または管理者が証明書を更新する必要があります。ブラウザーの検証要件を緩めて対処するのは避けてください。

証明書の詳細で最低限確認する4項目

警告画面の証明書リンク、またはブラウザーのアドレスバーにあるサイト情報から、アクセス先ドメイン、SAN、発行者、有効期間を確認します。確認手順はブラウザーのバージョンによって異なります。詳細を開けない場合は、エラーコードとアクセスした時刻を控えてください。互いに関係のない複数のサイトで、突然同じ見慣れない組織が証明書の発行者として表示された場合は、各サイトで同時に証明書の設定を誤ったと考えるより、中間者によるHTTPS復号をまず疑いましょう。

一方、発行者が同じというだけで問題と断定することもできません。多くのサイトは同じパブリックCAを利用しています。証明書チェーン、アクセス先ドメイン、ネットワーク環境、HTTPS検査ソフトの導入状況を合わせて判断してください。

手順1：時刻を合わせて比較する

まずシステム時刻を同期する

Windows 11では「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」を確認してから「今すぐ同期」をクリックします。macOSでは「システム設定」→「一般」→「日付と時刻」で自動設定を確認します。年月日、タイムゾーン、同期が正常に完了したかを確認してください。表示上のタイムゾーンを別の地域に変更しても、システム時計のずれは直りません。

スリープからの復帰、デュアルブートの切り替え、仮想マシンの時刻ずれによって、証明書が「有効期間前」と判定されることがあります。時刻を修正したら接続し直して確認してください。1つのサイトだけで期限切れの警告が続き、ほかのHTTPSサイトが正常なら、そのサイトの証明書を調べましょう。システム全体の設定を変更し続ける必要はありません。

同じURLで4通りのテストを行う

1. 完全なURL、エラーが発生した時刻、クライアントのモード（ルールまたはグローバル）を記録します。
2. URLは変えずにシステムプロキシを無効にします。TUNも有効になっている場合は、明示的に無効にしてから再テストします。
3. 元のプロキシ経路を再び有効にし、ノードだけを1つ切り替えて、証明書エラーがノードに応じて変わるか確認します。
4. 可能であれば、スマートフォンのテザリングまたは別の端末で同じURLにアクセスし、端末側とネットワーク側のどちらに問題があるかを切り分けます。

一度に変更する項目は1つにしてください。システムプロキシを無効にしても、ブラウザーの拡張機能がプロキシを指定している場合があります。TUNを無効にしても、システムプロキシが有効なままのことがあります。本当に「直接接続」になっているかは、スイッチの状態だけでなく、クライアントの接続記録も確認してください。直接接続できない場合は比較結果が得られないだけで、プロキシ経路が安全とも問題があるとも証明できません。

手順2：中間者によるHTTPS復号と認証ネットワークを確認する

セキュリティソフトの「HTTPSスキャン」、パケットキャプチャツール、企業ゲートウェイ、一部のデバッグ用プロキシは、ブラウザーとのTLS接続をいったん終端し、接続先ドメイン向けのローカル証明書を発行することがあります。ブラウザーが対応するルート証明書を信頼していないと警告が表示されます。信頼済みの場合も、それが意図した管理ポリシーによるものか確認してください。

• 個人の端末：最近、パケットキャプチャツールを使ったか、ネットワーク保護ソフトをインストールしたか、証明書をインポートしたかを確認します。該当ソフトの設定からHTTPS検査の状態を元に戻してください。システムのルート証明書をまとめて削除しないでください。
• 会社・学校の端末：発行者名と組織からの説明を照らし合わせ、ルート証明書の配布やプロキシのポリシーについて管理者に確認してください。管理対象の証明書を無断で削除したり、組織のアクセス制御を回避したりしないでください。
• ホテル、空港、来訪者向けWi-Fi：まず、システムに表示されるネットワークのログイン画面で認証を完了してください。認証ゲートウェイがHTTPSを誤って遮断すると、ドメイン名が一致しない証明書が返されることがあります。乗っ取りが疑われるHTTPS警告画面でアカウント情報を入力しないでください。

手順3：ノード、DNS、実際に適用されたルールを確認する

ルールを変更する前に接続記録を確認する

ルールモードではルールの順序に従ってポリシーグループが選ばれます。ポリシーグループ名が最終的なノードとは限りません。クライアントの接続記録またはログから対象ドメインを探し、適用されたルール、ポリシーの経路、最終的な出口を確認してください。項目名はクライアントによって異なりますが、通常は「接続」または「ログ」にあります。ポリシーグループ名しか表示されない場合は、グループ内で現在選択されている項目も確認しましょう。

DNSの名前解決に問題があると、誤ったサーバーにリクエストが送られ、不一致の証明書が返されることがあります。ただし、DNSの異常は名前解決エラーやタイムアウトとして現れることも少なくありません。fake-ip利用時に 198.18.0.0/16 の範囲のアドレスが表示されても、それだけでDNS汚染とはいえません。mihomoはマッピングから元のドメインを復元して転送を続けられます。

特定のノードだけでエラーが起き、別のノードでは正常な場合は、両方の経路で実際に受信した証明書を比較してください。出口ネットワークの干渉、CDNエッジの設定、接続先サイトの地域別サービスなどが関係する可能性があります。「ノードを変えたら直った」ことは切り分けの手がかりですが、ノードが通信を盗み見ている証拠にはなりません。DNSの変更、グローバルモードへの切り替え、TUNの有効化、ルールの編集を同時に行うと、原因を再現しにくくなります。

コアのログにx509エラーがある場合はノード設定を確認する

Webページに接続できないだけで、クライアントがノードサーバーへの接続に x509 エラーを記録している場合は、ノードのTLS層を調べます。証明書のドメイン名、接続先アドレス、SNIは必ずしも同じではありません。たとえばIPアドレスでノードに接続し、サービス提供元のドメイン名でサーバー名を検証する場合があります。サービス提供元の正しい設定と照らし合わせ、よく使われるドメイン名を推測で入力しないでください。

mihomoのノードTLS設定には skip-cert-verify がある場合があります。これを true にすると、該当ノードの証明書検証がスキップされます。ブラウザーが受信する接続先サイトの証明書は修復できず、ノードの本人確認も弱くなります。証明書チェーン、サーバー名、またはサーバー側の証明書を修正するのが基本であり、この項目を汎用的な解決スイッチとして使わないでください。

手順4：curlでトンネルと証明書の問題を切り分ける

コマンドラインでの比較はブラウザーの表示を補う手段になりますが、実際に待ち受けているポートを先に確認してください。以下ではローカルのHTTPまたはmixedポート 7890 を例にしています。これは例示用のポートで、すべてのクライアントの既定値ではありません。接続先は https://example.com/ です。実際の問題を再現する場合は、トークンを含まない対象URLに置き換えてください。

# 明示的なプロキシを使用しない。TUNが有効な場合は、引き続き通信が取り込まれることがあります
curl -Iv --noproxy "*" https://example.com/

# ローカルのHTTPプロキシを明示してCONNECTトンネルを確立する
curl -Iv --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/

Windows PowerShellでは、環境によって別のコマンドとして解釈されるのを避けるため、コマンド内の curl を curl.exe と記述してください。-I はレスポンスヘッダーを取得し、-v は接続診断情報を出力します。HEADメソッドに対応していないサイトでは、-I を外し、レスポンス本文をローカルの空デバイスにリダイレクトしてください。

「問題が解決した」と判断するために -k や --insecure を追加しないでください。これらのオプションは証明書検証をスキップし、テスト条件を変えるだけです。また、curlとブラウザーではTLSバックエンド、信頼ストア、DNSの経路が異なる場合があります。一方だけ成功してもう一方が失敗する場合は、その違いを引き続き確認し、どちらか一方の結果だけを信頼しないでください。

最後にブラウザーの状態とサイトの証明書チェーンを確認する

キャッシュは証明書エラーの主な原因とは限りません。閲覧履歴をすべて消去しても、期限切れの証明書、ドメイン名の不一致、信頼されていない発行者は直りません。まず関連するタブを閉じ、ブラウザーを完全に終了してから再試行してください。そのうえで、一時的な新しいプロファイルまたは別のブラウザーで比較します。

• 1つのブラウザーだけで失敗する：ブラウザーの更新状況、プロキシ拡張機能、組織のポリシー、証明書の信頼設定を確認します。シークレットウィンドウでも、システムプロキシ、組織のポリシー、許可された拡張機能の影響を受ける場合があります。完全に隔離された環境とは限りません。
• 古い端末だけで失敗する：OSのサポート状況と信頼ストアの更新を確認してください。フォーラムからルート証明書の修正ファイルを安易にダウンロードせず、OSやブラウザーの正式な更新手段を優先してください。
• 複数の端末・ネットワークで同じサイトだけ失敗する：サイト証明書の期限切れ、中間証明書の不足、CDNエッジの一部での設定ミスが疑われます。ドメイン名、発生時刻、証明書情報を記録してサイト管理者に連絡してください。
• 状態を消去した直後は直るが、再発する：接続の再利用、DNSの結果、実際に使われたノードの変化を引き続き確認しましょう。時間的に前後しただけのことを、キャッシュの削除による修復と誤認しないでください。

HSTSが有効なサイトではHTTPS接続が必須となり、ブラウザーにアクセスを続行するボタンが表示されないことがあります。これはセキュリティポリシーが適用されている状態です。エラーを回避するためにHSTSの状態を削除するのはおすすめできません。正常に修復されたと判断できるのは、通常の証明書検証を有効にしたまま接続でき、証明書が対象ドメインをカバーし、有効期間と発行チェーンに問題がない場合です。

切り分け結果と次の対応

1. 時刻を同期したらすべてのサイトが復旧した：時刻同期サービス、スリープ、デュアルブートの切り替えに問題がないか確認し、証明書検証の設定はそのまま維持してください。
2. 管理対象ネットワークでのみ、共通の発行者が表示される：HTTPS検査の導入について管理者に確認してください。出所不明のルート証明書を自分でインポートしないでください。
3. 特定のノードでのみエラーが発生する：ノードの識別情報と機密情報を伏せたログを保存し、検証に問題のない経路へ切り替えてサービス提供元に報告してください。
4. サブスクリプションの更新時だけエラーが発生する：サブスクリプションのドメインと証明書を確認し、更新リクエストがプロキシを経由しているか調べてください。秘密のサブスクリプションURLを公開の検査サイトに貼り付けないでください。
5. どの経路でも特定のサイトだけ失敗する：証明書の有効期間、SAN、再現した時刻をサイト管理者に伝え、証明書の設定が修正されるのを待ってください。

管理者への報告には、OSとブラウザーのバージョン、クライアントとコアのバージョン、完全なエラーコード、発生時刻、影響を受けるドメイン、ノードやネットワークを切り替えたときの比較結果を含めてください。クライアントとコアのバージョンは分けて記録します。画面が似ていても、証明書の処理経路が同じとは限りません。操作方法は使い方ガイドを、一般的な接続の問題はよくある質問をご覧ください。

まとめ：まず、エラーがブラウザー、ノードのTLS、サブスクリプションのリクエストのどこで発生しているかを特定し、時刻、証明書の発行者、実際の出口、端末の状態を順に確認してください。証明書検証を有効にした状態で接続できることが復旧の基準です。警告を無視したり検証を無効にしたりしても、解決にはなりません。