· トラブル対処 · 読了時間：約12分

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

プロキシ接続時のHTTPS証明書エラーについて、Macの時刻設定、TLSインスペクション、ノードやDNSの異常、サイト側の証明書設定を切り分ける方法を解説します。

1. エラー情報を記録し、警告を無視しない

Clash系クライアントを有効にした後、ブラウザに「この接続ではプライバシーが保護されません」などの警告が表示された場合、ブラウザが接続先サイトの正当性を確認できていません。ノードのタイムアウトやサブスクリプションの失効とは別の問題です。サーバーには接続できていても、提示された証明書や証明書チェーン、またはMacの信頼設定に問題がある可能性があります。

調査中は、そのページでパスワード、決済情報、認証コードを入力しないでください。アドレスバーのホスト名全体、ブラウザのエラーコード、証明書の発行者と有効期間を記録します。問い合わせ用にスクリーンショットを撮る場合は、アカウント情報、サブスクリプションURL、トークンを含むクエリパラメーターを隠してください。

エラーの例意味と優先して確認する項目
NET::ERR_CERT_DATE_INVALIDMacの時刻が正しくないか、証明書がまだ有効でない、または期限切れです。まず時刻を確認し、次に証明書の日付を確認します。
NET::ERR_CERT_AUTHORITY_INVALID信頼できる証明書チェーンを構築できません。発行者、ルート証明書の入手元、サーバーの中間証明書を確認します。
NET::ERR_CERT_COMMON_NAME_INVALIDアクセス先のホスト名が証明書の対象範囲と一致しません。証明書のサブジェクト代替名を確認します。
Safariの「この接続ではプライバシーが保護されません」これは複数の原因をまとめた警告です。詳細を開いて証明書と具体的なエラーを確認し、警告の見出しだけで判断しないでください。

2. HTTPS接続でClashプロキシが担う役割

通常の転送ではサイトの証明書は置き換わらない

ブラウザがローカルのHTTPプロキシ経由でHTTPSサイトにアクセスする場合を例にします。ブラウザはまずプロキシに CONNECT example.com:443 を送信し、プロキシが転送用トンネルを確立します。その後、ブラウザと接続先サイトの間でTLSハンドシェイクが行われます。サイト証明書を検証するのはブラウザです。ローカルの待ち受けポートが 7890 でも、HTTPSの内容が平文になるわけではありません。

SOCKSプロキシとTUNでは通信の取り込み方が異なりますが、それだけでHTTPSが復号されることはありません。ClashやClash Meta（現名称：mihomo）の通常のプロキシ転送では、Web通信を復号するためのルート証明書をインストールする必要はありません。設定のトラフィック嗅ぎ分けもHTTPS本文の復号とは別の機能です。確認できるハンドシェイクのメタデータを読み取ることと、代替証明書を発行することは異なります。

ノードのTLSとサイトのTLSは別々の接続

ノードのプロトコル自体がTLSを使用する場合もあります。その場合、クライアントとノードサーバー間、およびブラウザとサイト間で、それぞれ別のハンドシェイクが行われます。ログにノード側の証明書検証エラーが記録されている場合、プロキシ接続の失敗、タイムアウト、トンネルエラーなどが起きることが多く、必ずしもブラウザにサイト証明書の警告が表示されるわけではありません。

一部の設定にある skip-cert-verify は、該当するアウトバウンド接続の証明書検証に適用されます。サイトの証明書チェーンを修復したり、ブラウザにサイトを信頼させたりする設定ではありません。Webページのエラーを解決する目的で true に変更しないでください。ノードのアドレス、サーバー証明書、TLSサーバー名がサービス提供元によって正しく設定されているか確認します。

3. まずシステム時刻を確認し、条件を一つずつ変えて比較する

macOSの日付と時刻を確認する

macOS Ventura 13以降では、「システム設定」→「一般」→「日付と時刻」を開き、「日付と時刻を自動的に設定」が有効か確認します。日付、年、タイムゾーンも確認してください。古いmacOSでは「システム環境設定」→「日付と時刻」で確認できます。古いシステムのバックアップから復元した場合や、長期間オフラインだった場合は、年がずれていないか特に注意してください。

証明書の有効期間は時刻を基準に判定されます。Macの時刻がずれていると、正常なサイトでも証明書が未発効または期限切れと判定されることがあります。タイムゾーンを変えるだけでは、誤ったシステム時刻は直りません。自動同期後の実際の時刻を確認してください。修正後はブラウザを終了して開き直し、同じホスト名にアクセスします。

同じURLで4つの条件を記録する

  1. 現在のノード：ブラウザのエラー、証明書の発行者、クライアントの接続一覧に表示されるルールとアウトバウンドを記録します。
  2. 別のノード：ポリシーグループのノードだけを切り替えます。DNS、ルール、ブラウザ設定は同時に変更しません。
  3. プロキシなし：システムプロキシとTUNを一時的に無効にし、ブラウザ拡張機能や個別のプロキシ設定が通信を引き続き処理していないか確認します。
  4. 別のネットワーク：可能であればスマートフォンのテザリングで再度アクセスし、現在のWi-Fi、ルーター、組織ネットワークの影響を切り分けます。

プロキシなしのテストに失敗しても、サイトの証明書に問題があるとは限りません。現在のネットワークからサイトに接続できない可能性があります。比較するには、具体的な証明書情報やエラーコード、または正常に表示されたページが必要です。テスト中はURLを変えず、リダイレクト後に別のサブドメインへ移動していないかも確認してください。

4. TLSインスペクションと見知らぬルート証明書を確認する

企業ネットワークのHTTPS検査、デバッグ用のパケットキャプチャツール、一部のセキュリティソフトは、ブラウザとサイトの間でTLS接続を終端し、再発行した証明書をブラウザに提示することがあります。この仕組みでは、対応するルート証明書をデバイスが信頼している必要があります。ルート証明書が正しく配布されていない、期限切れになっている、またはソフトウェアのアンインストールが不完全な場合、「信頼されていない」という警告が表示されることがあります。

  • 発行者を確認：ブラウザの警告詳細または証明書ビューアで証明書の発行者を記録します。関連のない複数のサイトで同じ見知らぬ組織名が表示される場合は、調査が必要な手がかりです。
  • 証明書ストアを確認：「アプリケーション」→「ユーティリティ」→「キーチェーンアクセス」を開き、「ログイン」と「システム」のキーチェーンにある証明書を確認します。システムのルート証明書をまとめて削除しないでください。
  • デバッグツールを確認：HTTPS通信のキャプチャツールをインストールしたことがある場合は、HTTPS復号とシステムプロキシによる通信制御を一度無効にして再テストします。複数のローカルプロキシが互いに設定を上書きするのを防げます。
  • 管理対象デバイスか確認：Macが組織の管理下にある場合、証明書はデバイス管理プロファイルを通じて配布されていることがあります。用途、有効期間、配布状況を管理者に確認し、組織の信頼設定を独断で変更しないでください。

発行者が変わっただけでは、攻撃の証拠にはなりません。大規模なサイトでは認証局が変更されることがあり、CDNのエッジノードによって異なる証明書が返される場合もあります。ホスト名の対象範囲、有効期間、信頼チェーン、複数のアクセス経路を合わせて判断してください。個人所有のデバイスで、出所不明のルート証明書をインストールしないと「プロキシを修復できない」と言われた場合は、作業を中断して入手元を確認してください。

5. ノードの異常、DNSのずれ、サイトの設定ミスを切り分ける

特定のノードだけでエラーが出る場合：まずそのノードを無効にする

ほかのノードでは同じホスト名に正常にアクセスできるのに、特定のノードで無関係なドメインの証明書が繰り返し返される場合、その出口のDNS、ネットワーク上の干渉、サーバー側のルーティングに問題がある可能性があります。まずそのノードで機密性の高いサイトにアクセスするのをやめ、発生時刻、接続先ホスト名、エラーコード、証明書の発行者をサービス提供元に伝えてください。一度のエラーだけでノード運営者による通信の乗っ取りと断定することはできません。

DNSが書き換えられると、接続先が誤ったサーバーになる可能性がありますが、通常の証明書検証により、そのサーバーが元のサイトになりすますことは防げます。mihomoのFake-IPモードは、ドメインをローカルで合成アドレスに割り当て、カーネルが接続を処理する仕組みです。合成アドレスが表示されても、DNS汚染とは限りません。接続詳細に表示されるドメイン、適用されたルール、実際のアウトバウンドを照合してください。

どの経路でも特定のサイトだけエラーになる場合：サイトの証明書を確認する

同じサイトで、複数のノード、プロキシなし、別のデバイスでも同様のエラーが出る場合は、サイト証明書の期限切れ、対象ドメインの不足、中間証明書チェーンの設定漏れが考えられます。たとえば *.example.com のワイルドカード証明書は通常 www.example.com に適用できますが、それだけで a.b.example.com に適用されるとは限らず、ルートドメインの example.com も自動的には対象になりません。

サーバーに中間証明書が設定されていない場合、キャッシュや証明書チェーンの補完機能の違いにより、ブラウザごとに動作が異なることがあります。そのため「Safariでは開けるが、別のブラウザでは開けない」場合でも、サーバー設定の問題は否定できません。Macの信頼設定を変更するより、証明書チェーンの情報を記録してサイト管理者に連絡するのが適切です。

公衆Wi-Fiでのみ発生する場合：まずネットワーク認証を完了する

ホテルや空港などのネットワークでは、ポータルページでのログインが必要なことがあります。ポータルがHTTPSリクエストを認証ページに転送しようとすると、ドメイン不一致のエラーが発生する場合があります。まずmacOSのネットワークログイン通知から認証を完了し、証明書の警告ページでサイトのパスワードを入力しないでください。認証後も問題が続く場合は、スマートフォンのテザリングで確認します。

6. curlでプロキシなしとローカルプロキシを比較する

ターミナルでのテストは、ブラウザのキャッシュや拡張機能に依存しない手がかりになりますが、ブラウザでの結果に代わるものではありません。まずクライアント設定でHTTPまたは混合ポートを確認してください。以下の 127.0.0.1:7890 はテスト用の例で、すべてのクライアントに共通する値ではありません。例のドメインを実際にエラーが発生するホスト名に置き換え、https:// はそのまま残してください。

# curlのバージョンとTLSバックエンドを記録
curl --version

# curlのプロキシ選択を回避する。TUNが有効な場合、通信は引き続き処理される可能性があります
curl -Iv --connect-timeout 10 --max-time 20 --noproxy '*' https://example.com/

# ローカルのHTTP / 混合プロキシポートを明示して使用
curl -Iv --connect-timeout 10 --max-time 20 --noproxy '' \
  --proxy http://127.0.0.1:7890 https://example.com/
  • プロキシなしの条件で正しく比較する：--noproxy '*' を指定するだけでなく、TUNを無効にし、ほかのVPNやネットワーク拡張機能が通信を処理していないことも確認してください。このオプションで回避できるのはcurl自身のプロキシ設定だけです。
  • トンネルとサイトを区別する：出力にある 200 Connection established は通常、プロキシがCONNECTリクエストを受け付けたことを示します。接続先サイトの証明書検証が成功したという意味ではありません。
  • エラーの種類を確認する：curl: (60) は通常、相手側の証明書検証に失敗したことを示します。curl: (7) は通常、接続に失敗したことを示します。ローカルプロキシが待ち受けていないのか、サイトのTLS検証に失敗したのかを切り分けてください。
  • 信頼ストアの違いに注意する：macOS標準のcurlと、別の方法でインストールしたcurlでは、TLSバックエンドやCAストアが異なる場合があります。一方だけ成功する場合は、バージョンと信頼ストアを確認してください。

これらのコマンドでは接続タイムアウトを10秒、全体の制限時間を20秒に設定し、テストが長時間止まるのを防いでいます。性能測定の値ではありません。-I はHEADリクエストを送信します。サイトによっては405が返されますが、TLS検証が完了していれば、HTTPメソッドがサポートされないことと証明書エラーは別の問題です。

7. 根拠に基づいて修正し、問題が隠れていないか確認する

  1. 時刻の誤り：自動時刻合わせを有効にしてブラウザを開き直し、元のホスト名の証明書が正常に検証されることを確認します。
  2. 組織のHTTPS検査に問題がある：管理者に証明書の配布やゲートウェイの修正を依頼します。チャットの添付ファイルで送られた不明なルート証明書を一時的にインストールしないでください。
  3. 特定のノードに問題がある：そのノードの使用を中止し、証拠を保存してサービス提供元に連絡します。別の信頼できる経路でも再テストしてください。
  4. サイトの証明書に問題がある：サイト側で証明書の更新、中間証明書チェーンの補完、ドメイン設定の修正が行われるのを待ちます。通常、クライアントを再インストールしても解決しません。
  5. ローカルソフトウェアの競合：各ソフトウェアの公式ドキュメントに従ってHTTPS復号やプロキシによる通信制御を解除します。一度に一項目だけ変更し、同じ条件で再テストしてください。

最後に、必要なルールモード、システムプロキシ、TUNの設定を元に戻し、対象サイトと普段使う別のHTTPSサイト2つを確認します。アドレスバーで予期しないリダイレクトがないこと、証明書が有効であること、クライアントの接続一覧に表示されるアウトバウンドが想定どおりであることを確認してください。ブラウザを変えたら警告が出なくなった場合も、信頼ストアや拡張機能の違いを調べてください。問題が解決したと決めつけないようにしましょう。

クライアントのインストールと基本設定はクイックスタートを、プロキシプロトコル、ルール、DNS設定の確認はプロトコルガイドをご覧ください。証明書エラーの調査では、時刻、ホスト名、証明書チェーン、アクセス経路を確認することが重要です。サブスクリプションを何度も更新したり、手当たり次第にポートを変更したりしても解決にはなりません。

Clash Mac版 インストーラー