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

HTTPS証明書エラー：まず問題が起きている層を特定する

Clashクライアントを起動した後に「この接続ではプライバシーが保護されません」と表示されても、ブラウザーが接続先の身元を確認できないことを示すだけで、プロキシノードがWebページを改ざんしたとは限りません。端末の時刻ずれ、Webサイトの証明書切れ、公衆Wi-Fiのログインページ、企業ネットワークのHTTPS検査、DNSによる誤ったサーバーへの名前解決などでも、同様の警告が表示されます。

HTTPSでは通常、接続先サーバーの443番ポートに接続します。TLSハンドシェイクの際、ブラウザーは証明書の有効期間、証明書チェーン、アクセス先ドメインとの一致を確認します。プロキシによって変わるのは通信経路であり、ブラウザーによるこれらの本人確認は引き続き必要です。調査の第一歩は検証を無効にすることではありません。エラーコード全文、アドレスバーのドメイン、証明書の発行者と有効期間を記録しましょう。

ClashクライアントによるHTTPS通信の転送方法

通常のプロキシ転送でWebサイトの証明書を置き換える必要はない

ブラウザーがローカルHTTPプロキシ経由でHTTPSサイトに接続する場合、通常はまずCONNECT 接続先ドメイン:443を送信し、確立したトンネルを通じて接続先サイトとTLSハンドシェイクを行います。SOCKSプロキシやTUNモードでも、暗号化された接続を転送できます。通常の転送では、ブラウザーに表示されるのは接続先サイトの証明書であり、「Clashの証明書」ではありません。

Clashクライアントのルールによって、接続が直接接続になるかプロキシ経由になるか、どのポリシーグループを使うかが決まります。ドメインスニッフィングを有効にしても、参照できるハンドシェイク情報を読み取ることと、HTTPSの本文を復号することは別です。TUN、Fake-IP、スニッフィングが有効というだけで、ブラウザーの証明書が置き換えられたとは判断できません。

接続先サイトの証明書とプロキシノードの証明書を区別する

プロキシプロトコル自体にTLSを使用するものもあります。この場合、検証は2段階に分かれます。コアがプロキシノードのTLS証明書を検証し、ブラウザーが接続先サイトのHTTPS証明書を検証します。コアのログに、プロキシサーバーへの接続時のx509: certificate has expired or is not yet validというエラーがあれば、ノード側に問題がある可能性があります。一方、ブラウザーに接続先サイトの証明書が表示され、ドメイン不一致のエラーが出る場合は、Webサイトへの接続側を確認してください。

mihomoの設定では、一部のTLSノードでskip-cert-verifyを使用できます。この項目が対象とするのは該当ノードの証明書検証であり、接続先サイトに対するブラウザーの検証を無効にするものではありません。値をtrueにしてもWebページの証明書エラーが確実に直るわけではなく、ノードの身元確認が弱まります。設定の提供元に、ノードの証明書、サーバー名、接続先アドレスの修正を依頼してください。

1段階目の確認：時刻、ドメイン、証明書の詳細

1. エラー情報を記録する。URLとエラーコード全文を控えます。ブラウザーのサイト情報または証明書ビューアーで、発行者、有効期間、「サブジェクトの別名」（SAN）を確認してください。画面の開き方はブラウザーのバージョンによって異なるため、証明書の詳細画面を確認します。
2. 端末の時刻を合わせる。Windows 11では「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」を有効にして「今すぐ同期」を実行します。macOSでは「システム設定」→「一般」→「日付と時刻」を開き、日付と時刻の自動設定を確認します。
3. 実際のドメインを確認する。入力ミスがないか、古いブックマークから新しいサブドメインに転送されていないか確認します。証明書のSANにある*.example.comは通常、www.example.comには対応しますが、a.b.example.comには対応せず、ルートドメインのexample.comも自動的には含みません。
4. 証明書の有効期間と比較する。たとえば端末の日付が2025年で、証明書の有効期間が2026年から始まる場合、証明書はまだ有効ではないと判定されます。端末の日付が2030年に進んでいる場合も、有効な証明書が期限切れと判定されることがあります。これは判定例であり、現在のWebサイトの証明書情報ではありません。

タイムゾーンは主に現地時刻の表示に影響します。タイムゾーンの表示が異なっても、端末の実際の時刻が正しければ、通常は証明書検証の失敗につながりません。修正が必要なのは実際の日付と時刻であり、タイムゾーン名を居住地域に変更するだけでは不十分です。

エラーが1つのWebサイトだけで発生する場合

同じネットワーク上のほかのHTTPSサイトが正常で、直接接続時とプロキシ経由の両方で同じ期限切れ証明書が表示されるなら、Webサイト側の証明書更新漏れや証明書チェーンの設定不備が考えられます。ノードをいくつ変えても、期限切れの証明書が有効になることはありません。エラー情報を記録してサイトの管理者に連絡し、サーバー側の修正を待ちましょう。

2段階目の確認：接続経路を比較してプロキシの影響を調べる

テストでは一度に1つの条件だけを変更し、同じURL、同じブラウザー、近い時間帯で比較してください。まず現在のルールモード、ポリシーグループ、ノードを記録してから、次の比較を行います。接続経路によって異なるCDNエッジサーバーにつながることがあるため、証明書が異なるだけでは通信の改ざんを示す十分な根拠になりません。ドメインの対応範囲と証明書チェーンの信頼性も確認してください。

システムプロキシをオフにしても直接接続になるとは限らない

TUNモードが有効なままだと、仮想ネットワークインターフェースが引き続き通信を処理する場合があります。また、ブラウザーの拡張機能が独自のプロキシを設定していることもあります。直接接続と比較する前に、ClashクライアントのシステムプロキシとTUNを無効にし、ブラウザーが独自のプロキシを使っていないことを確認してください。テスト後は設定を元に戻します。組織の管理下にある端末では、ネットワークの要件に従い、強制されたポリシーを独自に回避しないでください。

Clashクライアントの接続一覧で対象ドメインの接続を探し、適用されたルールと最終的なポリシーを確認します。画面で特定のノードが選択されていても、すべてのリクエストがそのノードを通るとは限りません。ルールによって対象がDIRECTや別のポリシーグループに割り当てられている場合があります。ルールの詳しい仕組みは設定の詳細をご覧ください。

curlでローカルプロキシとの接続を比較する

以下ではexample.comを例にコマンドの形式を示し、ローカルのHTTPポートまたは混合ポートを7890と仮定します。実際のポートはClashクライアントの現在の設定を確認してください。Windowsではcurl.exe、macOSまたはLinuxではcurlを使用します。

# プロキシ環境変数を明示的に無視して、直接接続を比較する
curl --noproxy "*" -Iv https://example.com/

# ローカルのHTTPプロキシを明示的に使用する
curl --proxy http://127.0.0.1:7890 -Iv https://example.com/

TUNが動作したままの場合、1つ目のコマンドの通信もTUNに処理される可能性があるため、先に前述の手順で無効にしてください。-Iはレスポンスヘッダーを取得し、-vは接続とハンドシェイクの情報を表示します。今回確認する証明書検証をスキップしてしまうため、-kや--insecureは付けないでください。curlとブラウザーではTLSの実装や信頼ストアが異なる場合があります。結果は比較の手がかりとして使い、ブラウザーでの検証の代わりにはしないでください。

DNS、Fake-IP、ネットワークのログインページが証明書に与える影響

接続先アドレスが誤っていると、別の証明書が返されることがある

DNSがドメインを誤ったサーバーに名前解決しても、ブラウザーは元のドメインで証明書を検証します。たとえばwww.example.comにアクセスした際、ネットワークのログインポータルにしか対応しない証明書が返されると、ドメイン不一致のエラーが発生します。まったく異なる複数のサイトで同じ見慣れない発行者やポータルのドメインが表示される場合は、公衆Wi-Fiの認証、ルーターの設定、端末のHTTPS検査ソフトを優先して確認してください。

Fake-IPはドメインと接続先の対応付けに使う仕組みであり、HTTPS証明書を偽造する機能ではありません。mihomoでよく使われる例では、198.18.0.1/16をFake-IPの範囲として設定します。実際の範囲は設定に従ってください。この範囲に名前解決されたからといって、ただちにDNS汚染とは限りません。DNS拡張モード、TUNによる通信の処理状態、ドメインとの対応付けが正しいかをあわせて確認します。

• DNS拡張モードを切り替えたりTUNを無効にしたりすると、古いDNSキャッシュに以前のアドレスが残る場合があります。まず新しい設定が反映されていることを確認してから、キャッシュを更新し、ブラウザーを再起動してください。
• Windowsではipconfig /flushdnsを実行してシステムのDNSキャッシュを消去できます。ただし、ブラウザーが独自のキャッシュを持つ場合があります。また、キャッシュを消去しても期限切れの証明書は修復されません。
• ブラウザーのセキュアDNS設定によって、ドメインの名前解決経路が変わることがあります。まず現在の設定を記録し、クライアント側のDNS方式に合わせて一貫した条件でテストしてください。ノードとDNSリゾルバーを同時に変更するのは避けましょう。

公衆Wi-Fiでは正規の認証を先に済ませる

ホテル、空港、学校のネットワークでは、ログインポータルでの認証が必要な場合があります。まずOSに表示されるネットワークログイン画面、またはネットワーク事業者が案内する認証ページを使用してください。HTTPSページがリダイレクトされて証明書の警告が出た場合は、その警告画面でアカウントのパスワードを入力しないでください。信頼できる入口で認証を済ませた後、プロキシを再び有効にして目的のWebサイトにアクセスします。

企業のルート証明書、Webサイトの証明書チェーン、安全性の境界

企業のゲートウェイ、セキュリティソフト、デバッグツールがHTTPS通信を検査することがあります。端末とゲートウェイの間でTLS接続を確立し、ゲートウェイからWebサイトに接続する仕組みです。この場合、ブラウザーには組織のルート証明書が発行したWebサイト用の証明書が表示されることがあります。管理対象の端末では、明示的に設定されたネットワークポリシーの可能性があります。一方、個人の端末で見慣れない発行者が突然表示された場合は、慎重に確認してください。

1. 管理元を確認する。組織の管理者にHTTPS検査が導入されているか問い合わせ、ルート証明書の入手元と端末の管理記録を照合してください。フォーラムの添付ファイルや見知らぬメッセージから証明書を入手しないでください。
2. ネットワークを切り替えて比較する。許可されている場合は、信頼できる個人用ネットワークに切り替えてください。特定のネットワークでのみ見慣れない発行者が表示されるなら、そのネットワークのゲートウェイを重点的に確認します。すべてのネットワークで表示される場合は、端末のソフトウェアと信頼設定を確認してください。
3. Webサイトの証明書チェーンを確認する。Webサイトで中間証明書が不足していると、キャッシュがあるブラウザーでは正常にアクセスできても、別の端末では失敗することがあります。閲覧者にリーフ証明書を信頼させるのではなく、サイトの管理者がサーバー側の証明書チェーンを適切に設定してください。
4. サポート対象の環境に戻す。OSとブラウザーを更新し、必要なセキュリティ修正と信頼ストアの更新を適用してください。管理対象の端末では、管理者がポリシーに従って更新や証明書の変更を行います。

接続を再開する前の確認リスト

• 時刻が正確：システムの時刻を同期し、証明書が現在の有効期間内にある。
• ドメインが一致：アドレスバーのドメインが証明書のSANに含まれ、エラーを手動で無視してアクセスしていない。
• 通信経路が明確：システムプロキシ、TUN、ブラウザー独自のプロキシ、実際に適用されたルールの状態を確認した。
• 発行者が信頼できる：見慣れない証明書の入手元を特定し、組織の証明書は正式な管理窓口で確認した。
• 変更を元に戻せる：元の設定を保存し、証明書検証のスキップで問題を隠していない。

サポートを依頼する際は、エラーコード、OSとブラウザーのバージョン、Clashクライアントとコアのバージョン、TUNの使用状況、直接接続とプロキシ接続の比較結果を伝えると役立ちます。証明書のスクリーンショットにはドメイン、発行者、有効期間を残し、ログからはサブスクリプションURL、ノードのパスワード、アクセストークン、個人用URLを隠してください。基本的な接続の確認方法はよくある質問もご覧ください。

調査の順序は、まずエラーが発生している層を特定し、次に時刻と証明書の身元を確認してから、接続経路を比較し、最後にDNS、ゲートウェイ、Webサイト側の設定を調べることです。目指すのは警告を消すことではなく、信頼できるHTTPS接続を回復することです。