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

プロキシ使用時に「接続はプライベートではありません」と表示される原因と対処法

プロキシ利用中に表示される証明書警告の原因を、システム時刻のずれ、MITM設定の残存、不審なノード、DNS汚染に分けて解説。確認方法と対処手順も紹介します。

証明書エラーとプロキシ接続エラーを切り分ける

HTTPS の証明書警告が表示されたら、パスワードや決済情報の入力を中止し、システム時刻、証明書の発行者、実際の接続経路を確認してください。「このまま続行」を修復手段として使わないでください。通常のプロキシ転送で、新しいルート証明書をブラウザーに信頼させる必要はありません。サブスクリプションを追加しただけで、サイト提供の証明書のインストールを求められることもありません。

ClashX や mihomo コアを使用するクライアントは、通常、通信を転送する役割を担います。ブラウザーが HTTP CONNECT トンネル、SOCKS、TUN 経由で HTTPS サイトにアクセスする場合も、サイト証明書を検証するのはブラウザーです。TUN で通信を取り込むことは HTTPS の復号を意味しません。また、mihomo の通信スニッフィング機能も、サイト証明書を再発行する機能ではありません。

よくある表示 まず確認すること この表示だけでは判断できないこと
NET::ERR_CERT_DATE_INVALID 端末の時刻、証明書の有効期間 必ずしもノードの障害とは限らない
NET::ERR_CERT_AUTHORITY_INVALID 発行者、ルート証明書の信頼状態、証明書チェーン 不明な証明書をインストールすべきという意味ではない
NET::ERR_CERT_COMMON_NAME_INVALID URL と証明書の SAN、DNS、リダイレクト DNS キャッシュの問題とは限らない
ERR_PROXY_CONNECTION_FAILED プロキシの待ち受けポート、クライアントの動作状態 サイト証明書の検証エラーではない
ERR_SSL_PROTOCOL_ERROR TLS ハンドシェイク、ポートの誤り、中間機器 ルート証明書の不足と同じとは限らない

ブラウザーによってエラー名が異なる場合があります。エラーコード、アクセス先のドメイン、発生時刻、証明書の発行者を記録し、その後は一度に一つの条件だけを変更してください。記録するのはドメイン名だけにし、ログイントークンを含む完全なURLは公開しないでください。

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

システム時刻が誤っていると、正常な複数のサイトで証明書の期限切れや有効期間前の警告が表示されます。仮想マシンのスナップショット復元、長期間の電源オフ、デュアルブートの切り替え後は、特に最初に確認してください。タイムゾーンの表示が異なるだけで検証に影響するとは限りません。重要なのは、システムに記録された実際の時刻が正しいかどうかです。

  1. Windows 11：「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」をオンにします。「その他の設定」で「今すぐ同期」を実行してください。
  2. macOS：「システム設定」→「一般」→「日付と時刻」を開き、日付と時刻の自動設定をオンにします。旧バージョンでは項目名が異なる場合があります。
  3. ブラウザーを再起動し、エラーページの証明書詳細で「有効期間の開始」と「有効期間の終了」を確認します。システム時刻が正しく、特定のサイトだけ証明書の期限が切れている場合は、サイト管理者による証明書の更新が必要です。

ターミナルでは次のコマンドで UTC 時刻を確認し、信頼できる別の端末と比較できます。このコマンドは時刻を読み取るだけで、システム設定は変更しません。

# macOS / Linux
date -u

# Windows PowerShell
(Get-Date).ToUniversalTime().ToString("o")

手順2：直接接続と明示的なプロキシ接続で影響範囲を特定する

「システムプロキシをオフ」にしても、必ずしも直接接続になるとは限りません。TUN が引き続き接続を取り込む場合や、ブラウザー拡張機能が独自にプロキシを設定している場合があります。企業ネットワークが端末の外部で通信を検査している可能性もあります。まず現在のモード、選択中のノード、設定ファイルを記録し、再現可能な条件で比較してください。

同じドメインで3パターンを比較する

  1. 直接接続：クライアントのシステムプロキシと TUN をオフにし、ブラウザーのプロキシ拡張機能も一時的に無効にします。直接接続が許可され、対象サイトにアクセスできるネットワークで、同じ HTTPS ドメインを開いてください。
  2. ノード A：元の設定に戻し、元のノードを選択して、証明書の発行者とエラーコードを記録します。
  3. ノード B：ノードだけを切り替え、ブラウザー、対象ドメイン、その他の設定は変えずに、もう一度テストします。

直接接続できない場合、タイムアウトを「証明書に問題なし」と判断することはできません。必要に応じて、スマートフォンのテザリングなど別の信頼できるネットワークでも比較してください。DNS、ノード、ブラウザー、ルールを同時に変えると、結果が変わった原因を特定できません。

curl で HTTP CONNECT 経由の接続を確認する

ここではクライアントの実際の待ち受けポートが 7890 の場合を例にします。現在有効な設定で mixed-port の値を確認し、7890 以外の場合はコマンドのポートも変更してください。Windows では、PowerShell 環境によって同名のエイリアスが使われることがあるため、curl.exe と記述するのがおすすめです。

# macOS / Linux：環境変数に設定された HTTP/SOCKS プロキシを除外する
# TUN がオフで、他の透過プロキシもない場合に限り、直接接続の比較に使用できます
curl -Iv --connect-timeout 10 --max-time 20 --noproxy '*' https://example.com/

# ローカル HTTP プロキシを明示的に指定し、no_proxy の除外リストをクリアする
curl -Iv --connect-timeout 10 --max-time 20 --noproxy "" \
  --proxy http://127.0.0.1:7890 https://example.com/

# Windows PowerShell：ローカル HTTP プロキシを明示的に指定する
curl.exe -Iv --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/

200 Connection established は、プロキシが CONNECT リクエストを受け付けたことを示すだけで、その後の TLS 検証が成功したことを意味しません。証明書の検証結果と最終レスポンスも確認してください。例のドメインはコマンドの説明用です。実際の調査ではエラーが発生したドメインに置き換え、非公開のパスを含める必要はありません。

curl とブラウザーでは、TLS のバックエンドや信頼ストアが異なる場合があります。そのため、「curl は成功、ブラウザーは失敗」は原因を絞る手がかりであり、最終的な判定ではありません。確認したい検証を無効にしてしまうため、コマンドに -k や --insecure を追加しないでください。

手順3：MITM、パケットキャプチャツール、残存するルート証明書を確認する

MITM は中間者による傍受を指します。許可を得たデバッグ環境や企業環境では、パケットキャプチャツールが元の TLS 接続を終端し、ローカルのルート証明書でサイト証明書を発行する場合があります。プロキシ設定が残っている、ルート証明書が削除済み、またはアプリがその証明書ストアを信頼していない場合、証明書エラーが発生します。

まず発行者を確認し、次に設定元を調べる

  • ブラウザーのエラーページまたはサイト情報パネルから証明書の詳細を開き、発行者、有効期間、「サブジェクト代替名」（SAN）を確認してください。SAN に現在アクセスしているドメインが含まれている必要があります。
  • 関係のない複数のサイトで同じ見慣れない組織名やローカルツール名が表示される場合は、パケットキャプチャツール、HTTPS スキャン機能、ブラウザー拡張機能、デバイス管理ポリシーを確認してください。
  • Windows では「設定」→「ネットワークとインターネット」→「プロキシ」で、手動プロキシと設定スクリプトを確認します。macOS では「システム設定」→「ネットワーク」→現在のネットワーク→「詳細」→「プロキシ」で、設定が残っていないか確認してください。
  • 環境変数 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY、NO_PROXY も確認してください。ブラウザーとターミナルで、同じプロキシ設定が使われているとは限りません。

証明書を削除する前に用途を確認する

macOS では「キーチェーンアクセス」で「ログイン」と「システム」のキーチェーンをそれぞれ確認できます。Windows では certmgr.msc で現在のユーザーの証明書を、certlm.msc でローカルコンピューターの証明書を確認できます。後者の変更には通常、管理者権限が必要です。「信頼されたルート証明機関」を確認する際は、証明書名、用途、配布元を先に確認してください。

個人の端末で、古いパケットキャプチャツールがインストールした証明書だと確認できた場合は、まずツールの HTTPS 傍受を停止し、プロキシ設定を元に戻してから、ツールのアンインストール手順に従って証明書を削除してください。システムのルート証明書をまとめて削除しないでください。組織管理の端末は、社内サービスへの影響やネットワーク管理上の問題を避けるため、管理者に対応を依頼してください。

手順4：不審なノード、DNS、接続先の誤りを調べる

特定のノードだけで証明書のドメイン不一致が発生し、ノードを切り替えるとすぐに解消する場合は、そのノードを切り分けて名前解決の経路を確認してください。ただし、一度のエラーだけでノードによる傍受と断定することはできません。出口付近のログインポータル、上流 DNS、リバースプロキシの設定ミスでも、別のサーバーに接続されることがあります。

DNS汚染で証明書警告が発生する仕組み

ドメインが誤ったサーバーに解決されても、ブラウザーはアドレスバーに表示されている元のドメインを基準に証明書を検証します。誤ったサーバーが別ドメインの証明書を返すと、名前が一致しないため警告が表示されます。攻撃者が DNS を変更しただけで、対象ドメインの有効な証明書を取得できるわけではありません。証明書警告は、維持すべきセキュリティ上の防波堤です。

まずアドレスバーのドメインに誤字がないか確認し、次に端末の hosts ファイル、ブラウザーのセキュア DNS、ルーターの DNS、クライアントの DNS 設定を調べてください。mihomo の fake-ip モードでは、198.18.0.0/16 の範囲にあるアドレスが割り当てられる場合があります。このネットワーク帯であること自体は、DNS汚染の証拠ではありません。一般的な nslookup も、ブラウザーのセキュア DNS やクライアントが実際に使う名前解決経路を通るとは限りません。

  • クライアントの「接続」または「ログ」画面で対象ドメインを検索し、適用されたルール、プロキシグループ、最終的なノードを確認してください。具体的な画面や項目名はクライアントによって異なります。
  • より上位にある DOMAIN、DOMAIN-SUFFIX、ルールセットによって、対象が DIRECT に振り分けられていないか確認してください。ルールは通常、上から順に判定されます。プロキシグループを切り替えても、すでに直結ルールに一致した通信の経路は変わらないことがあります。
  • 問題を隠すためにグローバルモードを常用しないでください。比較のために短時間使うことはできますが、テスト後は元のモードに戻し、ルールを修正してください。
  • 公衆 Wi-Fi では、まずシステムが案内するネットワークへのログインを完了してください。ポータルの証明書に置き換えられた HTTPS ページが表示された場合は、信頼できるネットワークで検証してください。ポータルを理由に、対象サイトの証明書警告を無視しないでください。

名前解決の設定を修正した後に、必要に応じてキャッシュをクリアしてください。Windows では ipconfig /flushdns を実行します。macOS では次のコマンドを実行してください。ブラウザーやクライアントが独自のキャッシュを保持している場合もあるため、必要なら完全に終了して再起動します。

# macOS：システムの DNS キャッシュを更新する（管理者権限が必要）
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

同じノードでドメイン不一致の証明書が繰り返し返され、別の信頼できるノードと直接接続では正常な場合は、そのノードの使用を中止し、個人情報を伏せた証拠をサービス提供元に報告してください。報告にはドメイン、発生時刻、発行者、エラーコードを含めます。サブスクリプション URL、ノードのパスワード、設定ファイル全体は送信しないでください。

手順5：サイトの証明書チェーンとクライアントの信頼ストアを切り分ける

システム時刻が正しく、接続経路も安定している場合、証明書チェーンの不備や信頼ストアの違いが原因としてよく考えられます。サイトサーバーが中間証明書を送信していないと、キャッシュを使って補完できるブラウザーがある一方、別の端末やコマンドラインツールでは失敗することがあります。1台のパソコンで開けるからといって、サーバーの設定が正しいとは限りません。

OpenSSL で証明書チェーンとドメイン検証を確認する

これらのオプションに対応した OpenSSL 環境では、次のコマンドを実行できます。-servername は SNI を指定し、共有 IP 上のサーバーに対象サイトを選択させます。-verify_hostname はドメイン検証を明示的に有効にします。通常の s_client を実行して接続成功と表示されても、証明書全体の検証に合格したことにはなりません。

# 直接接続で確認する：テスト中は TUN や他の透過転送を無効にする
openssl s_client -connect example.com:443 \
  -servername example.com -showcerts \
  -verify_hostname example.com -verify_return_error < /dev/null

# ローカル HTTP CONNECT プロキシ経由で接続する：OpenSSL が -proxy に対応している必要があります
openssl s_client -proxy 127.0.0.1:7890 \
  -connect example.com:443 -servername example.com \
  -showcerts -verify_hostname example.com \
  -verify_return_error < /dev/null

出力に含まれる検証エラー、証明書チェーン、Verify return code を確認してください。OpenSSL の信頼ストアは、macOS のキーチェーン、Windows の証明書ストア、ブラウザーの信頼ストアと異なる場合があります。「ローカル発行者証明書を取得できません」と表示されても、ローカル CA の設定とサーバーによる中間証明書の未送信の両方を考慮してください。すぐにノードの問題だと断定しないでください。

  • 特定のサイトだけ失敗し、複数の端末やネットワークで同じ症状が出る：サイト管理者に連絡し、証明書の期限、SAN、証明書チェーンの完全性を確認してもらってください。
  • 古い端末1台だけで失敗する：サポート対象の OS とブラウザーに更新し、ルート証明書が更新されているか確認してください。出所不明の証明書パッケージをフォーラムからダウンロードしないでください。
  • 特定のアプリだけ失敗する：そのアプリが独自の CA ファイルや証明書ピンニングを使用していないか確認してください。検証を無効にして証明書ピンニングの失敗を回避しないでください。
  • 証明書の失効に関するエラーが発生する：具体的なエラーとネットワーク条件を記録し、失効確認サービスに接続できるか調べたうえで、管理者またはサイト管理者に確認してください。失効確認を恒久的に無効にしないでください。

修正後の確認とセキュリティ上の注意点

変更後は、別のサイトを開くだけで済ませず、エラーが発生したドメインでもう一度確認してください。ブラウザー、実際に使う必要のあるアプリ、クライアントログのルールとノードを順に確認します。元のルールモードに戻し、クライアントの再起動後も問題が再発しないことを確認できて初めて、設定が安定したと判断できます。

  1. システムの日付と時刻が正しく、証明書の有効期間に現在時刻が含まれている。
  2. 証明書の SAN が対象ドメインと一致し、端末が信頼するルート証明書まで証明書チェーンを構築できる。
  3. システムプロキシ、TUN、ブラウザー拡張機能、環境変数の用途が明確で、デバッグ用プロキシが残っていない。
  4. 証明書エラーを無視するブラウザー起動オプションを使用せず、コマンドラインでも TLS 検証をスキップしていない。
  5. 元のノードまたは代替ノードでもう一度テストし、障害範囲と修正内容が一致していることを確認する。

警告ページで続行し、機密情報を入力したことがある場合は、信頼できるネットワークから該当するパスワードを変更し、不審なセッションを無効にして、アカウントのログイン履歴を確認してください。証明書警告が出ても、情報が漏えいしたとは限りません。ただし、疑わしい接続を使って機密性の高い操作を続けないでください。

Clash をダウンロード