プロキシ接続時のHTTPS証明書エラー｜原因と対処法

まずエラーの種類を確認し、証明書の警告を無視しない

Clashを有効にしたあと、ブラウザーに「接続はプライベートではありません」と表示されても、プロキシソフトに証明書をインストールする必要があるとは限りません。警告画面から先へ進まず、アクセス先の完全なドメイン名、エラーコード、発生時刻を記録してください。アカウントへのログインや支払いはせず、エラー画面から「証明書修復ツール」をダウンロードすることも避けましょう。

通常のHTTP CONNECTプロキシやSOCKS5プロキシは、主に通信を中継します。ブラウザーと接続先のWebサイト間ではTLSハンドシェイクが行われ、ブラウザーが証明書のドメイン名、有効期間、信頼チェーンを検証します。ClashやClash Meta（mihomo）で一般的なプロキシ中継を使う場合、新しいローカルルート証明書をブラウザーに信頼させる必要はありません。

「証明書エラーを無視」は、接続を復旧させる万能な方法ではありません。まず証明書が信頼されない理由を確認し、時刻、ネットワーク、プロキシ経路を見直しましょう。検証を無効にしたまま使うのは避けてください。

ブラウザーによって表示される文言は異なり、FirefoxではSEC_ERROR_UNKNOWN_ISSUERなどのコードが使われることもあります。プロトコルエラーや接続タイムアウトでは、証明書を受信していない場合もあります。「証明書の期限切れ」と一括りにしないでください。

手順1：システム時刻を合わせ、証明書情報を記録する

時刻を同期してからページを開き直す

1. Windows 11：「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」をオンにします。タイムゾーンを確認してから「今すぐ同期」をクリックしてください。
2. macOS：「システム設定」→「一般」→「日付と時刻」を開き、日付と時刻の自動設定を有効にして、タイムゾーンも確認してください。
3. Android：通常は「設定」→「システム」→「日付と時刻」で自動設定を有効にします。メーカーによっては「その他の設定」などの名称になっています。
4. iPhone：「設定」→「一般」→「日付と時刻」を開き、「自動設定」をオンにします。

日付が数か月ずれていると、多くの正常なWebサイトで同時にエラーが発生します。タイムゾーンの表示が異なるだけで、TLS検証に失敗するとは限りません。重要なのは端末の実際の時刻が正しいことです。同期後はエラーが出たタブを閉じ、同じドメインに再アクセスしてください。古い警告画面を何度も再読み込みするだけでは解決しません。

証明書の3項目を記録する

ブラウザーの「証明書を表示」機能から、有効期間、発行者、「サブジェクトの別名」（SAN）を記録します。新しいブラウザーでは、アドレスバー左側のサイト情報や、警告画面の詳細情報から確認できます。証明書を見るために「続行」を選ばないでください。

• 有効期間：現在の日付が開始日から有効期限までの範囲内か確認します。
• SAN：アドレスバーに表示されている実際のホスト名が対象に含まれているか確認します。証明書の*.example.comは通常、ルートドメインのexample.comや、さらに階層の深いa.b.example.comには適用されません。
• 発行者：ホテル、社内ゲートウェイ、セキュリティソフトなどの名称が表示されていないか確認します。名称だけで信頼できるかどうかは判断せず、利用中のネットワーク環境と照らし合わせてください。

時刻が正しく、特定のWebサイトだけで証明書の期限切れが発生する場合は、サイト管理者による証明書の更新が必要です。ノードを切り替えると、たまたま正常な接続先に到達できることはありますが、サイト側の修正の代わりにはなりません。検証を弱めて回避するのも避けてください。

手順2：公衆Wi-Fiの認証と端末上のHTTPS検査を確認する

空港、ホテル、学校のゲストWi-Fiでは、Webページからの認証が必要な場合があります。認証前はゲートウェイが通常のHTTPリクエストをリダイレクトすることがあります。HTTPS通信が誤って遮断されると、接続先サイトではなく認証ゲートウェイの証明書が返される場合もあります。このとき、プロキシノードをやみくもに切り替えても解決しないことがあります。

1. 現在のWi-Fi接続は維持したまま、システムプロキシとTUNを一時的に無効にします。片方だけを無効にしても、もう片方が通信を処理し続ける場合があります。
2. まず、システムに表示される「ネットワークにログイン」ウィンドウを使います。表示されない場合は、http://example.com/にアクセスすると認証ページへのリダイレクトを促せます。このURLは認証ページを表示するためのものであり、機密情報の入力には使わないでください。
3. 認証ページが利用中のネットワーク事業者のものか確認し、必要な認証を完了します。認証ページ自体に証明書の警告が出る場合は、現地の担当者に確認してください。
4. プロキシを使わずに通常のHTTPSサイトへ接続できることを確認してから、元のプロキシ設定を有効に戻して再テストします。

同じ端末でもスマートフォンのテザリングに切り替えると正常に戻る場合は、元のWi-Fiの認証、ゲートウェイ、ネットワークポリシーが原因として考えられます。ただし、これは原因を絞る手掛かりであり、確定的な証拠ではありません。企業ネットワークでは規定に基づいてHTTPS検査を導入している場合があります。正規の証明書配布方法を管理者に確認し、組織のポリシーを独自に回避しないでください。

特定のPCだけで発生する場合は、端末上の通信検査を確認する

セキュリティソフトの「暗号化接続のスキャン」、パケットキャプチャツール、デバッグ用プロキシがHTTPS通信を復号している場合があります。最近これらの機能を有効にしていないか確認し、証明書の発行者が該当ソフトと一致するか調べてください。個人の端末では、ソフトの公式手順に従って該当機能を一時停止し、比較テストを行った後に元の状態へ戻します。管理対象の端末は管理者に相談してください。

システムのルート証明書をまとめて削除したり、ノード提供者から送られた見覚えのないルート証明書をインポートしたりしないでください。通常のプロキシ設定にはノード、プロキシグループ、ルールなどが含まれますが、Webサイトの信頼証明書をインストールしないと動作しないものではありません。

手順3：同じドメインで直結とプロキシを比較する

アクセス先のURLは完全に同じにし、変更する条件は一度に1つだけにします。ここでいう「直結」はシステムプロキシ、TUN、ブラウザー個別のプロキシ設定をすべて無効にした状態です。「プロキシ」はリクエストが実際に現在のクライアントを経由している状態を指します。サイトに直結できない場合は「タイムアウト」と記録してください。タイムアウトを証明書が正常な証拠とみなしてはいけません。

curlで証明書検証エラーと接続失敗を切り分ける

以下はクライアントの混合プロキシポートが7890の場合の例です。まずクライアントの設定でポート番号を確認してください。すべての環境で固定の値ではありません。Windows PowerShellではcurl.exeを、macOSまたはLinuxではcurlを使います。

# 明示的なプロキシ環境変数を無視して直結をテスト
curl --noproxy "*" -Iv --connect-timeout 10 https://example.com/

# ローカルのHTTP混合プロキシポートへ明示的に接続
curl --noproxy "" -x http://127.0.0.1:7890 -Iv --connect-timeout 10 https://example.com/

ここでのhttp://127.0.0.1:7890は、ローカルのHTTPプロキシに接続する指定です。接続先のWebページをHTTPに変更する意味ではありません。HTTPSサイトには通常、CONNECTトンネルを使って接続します。https://127.0.0.1:7890に安易に変更しないでください。こちらはローカルプロキシの入口自体がTLSに対応している必要があります。

直結をテストするときはTUNも無効にしてください。--noproxyでは、システムレベルの透過的な通信処理を回避できません。curlの終了コード60は通常、証明書検証の失敗、7は接続失敗、28はタイムアウトを示します。これらは本記事で実測したデータではありません。curlとブラウザーで異なる信頼ストアを使う場合があり、結果が違っても、どちらか一方だけで判断せず引き続き確認してください。

手順4：ルール、DNS、実際の出口を確認する

ルールの設定ミスがWebサイトの証明書を直接変更することは通常ありませんが、通信が誤った出口を通ったり、利用中の経路に適さないサーバーへ名前解決されたりする場合があります。まずクライアントの「接続」画面でエラーの出たドメインを絞り込み、もう一度アクセスして、マッチしたルール、プロキシグループ、最終的なノードを記録します。続いてログに名前解決エラーやハンドシェイクエラーがないか確認してください。

全体モードは短時間の比較テストに限る

ルールモードでエラーが出て、同じノードでも全体モードなら正常な場合は、そのドメインが先にDIRECTへマッチしていないか、別のプロキシグループに振り分けられていないか確認してください。テスト後はルールモードに戻します。ルールは上から順に適用されるため、1つのドメインのためにすべての通信を同じ出口へ長期間切り替えないでください。

以下はルールの順序を示す例であり、完全な設定ではありません。追加する前に、プロキシグループにProxyという名前のグループが実際にあることを確認し、例のドメイン名を問題が起きているドメインに置き換えてください。サブスクリプションで設定が管理されている場合は、次回更新時に変更が失われないよう、クライアントが対応する上書きまたはマージ機能を使ってください。

mode: rule
rules:
  - DOMAIN,example.com,Proxy
  - DOMAIN-SUFFIX,example.org,DIRECT
  - MATCH,Proxy

fake-ipのアドレスは証明書の偽造を意味しない

mihomoのfake-ipモードでは、ドメインに仮想アドレスが割り当てられます。よく使われるアドレス範囲は198.18.0.0/16ですが、実際の範囲は設定によって異なります。コアはマッピングを通じて元のドメインの通信を処理します。このアドレスが表示されても、HTTPS通信が復号されている証拠にはなりません。ブラウザーは引き続きドメイン名でTLS接続し、そのドメインの証明書を検証します。

• 証明書のテストで、アドレスバーのドメイン名を解決先のIPアドレスに置き換えないでください。証明書の照合条件が変わり、SNIや仮想ホストの選択にも影響する可能性があります。
• ローカルのhostsファイルと設定内のhostsセクションを確認し、問題のドメインが古いサーバーに固定されていないか調べてください。
• ブラウザーでセキュアDNSを有効にしている場合は、使用中のリゾルバーを記録してください。クライアントのDNSとは異なる経路を使っている可能性があります。影響を理解したうえで1項目だけ比較テストし、終了後は元に戻してください。
• DNSを変更したら、接続を作り直してください。Windowsではipconfig /flushdnsでシステムのキャッシュを消去できますが、ブラウザーやクライアントが独自のキャッシュを保持している場合があります。

DNS、ノード、ルールモード、TUNの設定を一度にすべて変更しないでください。変更は1項目ずつ行い、同じURLで再テストして、エラーコードと証明書の発行者が変わったか記録します。こうすることで、どの変更が効果をもたらしたか判断できます。

ブラウザーの証明書とノードの通信証明書を区別する

混同しやすい例として、ブラウザーにはWebサイトの証明書警告が出ていないのに、クライアントのログにx509: certificate signed by unknown authorityと表示されるケースがあります。コアがTLSを使ってプロキシノードに接続している場合に起こり得る問題で、「クライアントからノードまで」の証明書エラーであり、「ブラウザーからWebサイトまで」の証明書エラーとは限りません。

まずノードのアドレス、サーバー証明書の有効期間、証明書チェーン、ノード提供者が指定するサーバー名の設定を確認します。自前のサーバーなら証明書チェーンを修正するか、管理された方法で信頼設定を行ってください。サブスクリプションのノードなら提供者に確認します。推測でSNIを変更したり、無関係なWebサイトのドメイン名を入力したりしないでください。

ノード設定のskip-cert-verify: trueは、そのノードとのTLS接続における証明書検証をスキップします。接続先Webサイトの証明書を修正するものではありません。ブラウザー側の検証無視設定も、長期的な対処として使わないでください。

特定のノードだけで異常が繰り返される場合は、まずそのノードを無効にして、正常に使えると確認済みの出口へ切り替えます。そのうえで発生時刻、ノード識別情報、機密情報を伏せたログを提供者に送ってください。サブスクリプションURL、アクセストークン、ノードのパスワード、設定ファイル全体を公開しないでください。

復旧後の確認とトラブル記録

Webページが表示されたからといって、対応が完了したとは限りません。検証を一時的に緩めて警告を「消した」だけではないことも確認してください。次の順に確認すると、ネットワーク切り替え後の再発を防ぎやすくなります。

1. 通常のルールモードに戻し、システムプロキシとTUNの有効・無効状態が、普段の使い方に合っていることを確認します。
2. エラーが出たドメインをもう一度開き、証明書警告が再発しないこと、証明書のSANがホスト名と一致すること、有効期間内であることを確認します。
3. 普段使っているHTTPSサイトをさらに2つ確認し、特定のページだけキャッシュから表示されている状態ではないことを確認します。
4. 一時的に変更したDNS、ルール、デバッグ設定を元に戻します。必要な変更を残す場合は、対応する上書き設定に記録し、バックアップを取ってください。
5. 「システムの年が間違っていた」「Wi-Fiの認証が未完了だった」「特定ノードの出口に異常があった」など、最終的な原因を記録してください。「再起動したら直った」だけでは不十分です。

さらにサポートが必要な場合は、ブラウザー名とバージョン、OSのバージョン、クライアントとコアのバージョン、問題が起きたドメイン、エラーコード、直結とプロキシの比較結果、証明書の発行者を伝えてください。スクリーンショットを共有する前に、アカウント情報、個人用ドメイン、サブスクリプションの認証情報を隠します。正確な情報を伝えるほうが、サブスクリプションを何度もインポートするより原因の特定に役立ちます。

確認する順番は、時刻とエラーの種類、公衆Wi-Fiの認証と端末上の検査、出口の比較、ルールとDNSです。見覚えのない発行者が表示された場合や、重要なサイトで異常が起きた場合は、無理にページを開くより情報の送信を止めることが重要です。