プロキシ有効化後にブラウザがHTTPS証明書エラーを表示する原因と対処手順
証明書検証チェーンとプロキシの関係を解説。システム時刻のずれ、MITM復号、ハイジャックページ、ノード異常のエラー特徴を分類し、症状別の対処法と復旧手順を紹介。
プロキシを有効化した直後にブラウザが証明書の警告を表示するのは、Clash や Clash Meta(mihomo)コアのクライアントを使っていて最も不安になるエラーの一つです。警告文は「この接続ではプライバシーが保護されません」「証明書が無効です」「NET::ERR_CERT_AUTHORITY_INVALID」などが多いですが、その裏にある原因は大きく異なります。単にシステム時計が数分ずれているだけの場合もあれば、ノード自体に問題がある場合もあります。本記事ではエラーの特徴ごとに、よくある4つの原因を分解し、そのまま実行できる対処手順を紹介します。
証明書検証チェーンとプロキシの関係
プロキシがなぜHTTPS証明書に影響するのかを理解するには、まずブラウザが証明書を検証する基本ロジックを知る必要があります。HTTPSサイトにアクセスするたびに、ブラウザはサーバーが返す証明書が次の3条件を満たしているかを確認します。証明書チェーンがシステムに信頼されたルート証明書まで遡れること、証明書上のドメインとアクセス先のドメインが一致すること、証明書が現在有効期間内であること。これら3項目すべてが通過して初めて、アドレスバーに安全な錠のアイコンが表示されます。
Clash系クライアントはほとんどの利用シーンでトランスポート層で動作し、TCP/UDPトラフィックをリモートノードへ転送するだけで、HTTPS証明書を復号したり再発行したりはしません。ブラウザが見るのは対象サイト自身の元の証明書のままです。つまり、通常であればプロキシを有効化しても証明書に変化が生じるはずはありません。証明書警告が出た場合、基本的には次の4種類の原因のいずれかだと判断できます。端末のシステム時刻が不正確、クライアントが復号機能を持つ特殊モードを有効化している、経路の途中でページハイジャックが発生している、あるいは現在接続しているノード自体に異常がある、のいずれかです。以下で一つずつ解説します。
システム時刻のずれ:最も見落とされやすい原因
証明書の有効期限チェックは端末のローカル時計に依存します。システム時刻が実際の時刻と大きくずれている場合(長期間ネットに接続していない仮想マシン、手動で時刻を変更したテスト機、あるいはバッテリー切れでマザーボードの時計がリセットされた古い機器などでよく見られます)、ブラウザは証明書を「まだ有効になっていない」または「期限切れ」と誤判定します。エラーメッセージには通常 ERR_CERT_DATE_INVALID という文字列が含まれます。この種のエラーの特徴は、どのサイトでも無差別にエラーが出ること、ノードやプロキシの有無を問わないこと、別の端末で同じサイトにアクセスすると正常であることです。
確認方法は簡単です。システムの時刻設定を開き、「ネットワーク時刻の自動同期」が有効になっているかを確認し、タイムゾーンが正しいかも確認してください。
Windowsユーザーは設定の「日付と時刻」ページで「今すぐ同期」をクリックできます。macOSユーザーはシステム設定の「一般 - 日付と時刻」で確認してください。Linuxユーザーは以下のコマンドでシステム時刻とネットワーク時刻が一致しているかを素早く確認できます。
timedatectl status出力の中の System clock synchronized が no と表示されている場合、同期サービスが有効になっていないことを意味します。ネットワークの接続状況を確認するか、時刻サーバーのアドレスを変更してください。
MITM復号とルールハイジャックによる証明書エラー
2つ目の原因はシステム時刻とは無関係で、クライアント自体の機能設定によるものです。Clash Meta(mihomo)コアをベースとする一部のクライアントは、特定ドメインのHTTPSトラフィックに対してスクリプト書き換えや広告フィルタリングを行うためのMITM(中間者)復号機能をサポートしています。この機能を使うには、クライアントが自己署名のルート証明書を生成してシステムの信頼リストに登録する必要があります。このルート証明書がシステムやブラウザに正しく信頼されていない場合、MITMルールに含まれるドメインへアクセスすると NET::ERR_CERT_AUTHORITY_INVALID が表示され、証明書の発行者が信頼されていないという警告が出ます。
この種のエラーの見分け方は、設定ファイルの mitm セクションに列挙された一部のドメインだけでエラーが発生し、他の大半のサイトは正常にアクセスできること、また証明書の詳細を見ると発行者がクライアント自身の名称になっていて、サイト本来の証明書機関ではないことです。
MITMが有効になっているか確認する
クライアントの設定または規則ページでMITM/スクリプト/書き換え関連のスイッチがあるか確認します。この機能が不要であれば、そのまま無効にするのが最も手間がかかりません。
ルート証明書を再インストールする
この機能を残す必要がある場合は、クライアントが提供する証明書エクスポート機能からルート証明書を再ダウンロードし、システムの案内に従って手動で信頼設定を行います(macOSではキーチェーンアクセスで証明書の信頼レベルを「常に信頼」に変更、Windowsでは「信頼されたルート証明機関」にインストールします)。
MITMの適用範囲を絞る
mitmの適用ルールを実際に処理が必要なドメインだけに絞り込み、銀行や決済など証明書に極めて敏感なサイトには適用しないようにすることで、リスクを減らします。
もう一つ、より警戒すべき状況があります。復号や書き換え機能を一切有効にしていないにもかかわらず、見知らぬページにアクセスした際に証明書警告が出て、しかもページの内容が期待していたものと全く違う(例えば通販サイトにアクセスしたはずが無関係な広告ページに転送される)場合です。これは通常、経路の途中でハイジャックが発生しており、トラフィックが目的のサーバーに到達する前に中間ノードによって改ざんまたはリダイレクトされていることを意味します。このような場合は直ちにそのノード上でのアカウントログインや決済操作を一切停止し、サブスクリプションやノードの入手元を変更してください。
ノード異常による接続・証明書エラー
4つ目の原因はノード自体の健全性に関わるものです。プロキシノードが既に無効になっている、対象サーバーからブロックされている、あるいはノードのサーバー側設定に誤りがある(自前で構築したノードで証明書の期限切れが更新されていない、TLSパラメータの設定ミスなどでよく見られます)場合、ブラウザは接続タイムアウトとして表示することもあれば、証明書チェーンが不完全というエラーとして表示することもあります。具体的な文言はブラウザによって異なりますが、よく見られるのは ERR_CERT_COMMON_NAME_INVALID(証明書のドメインとアクセス先ドメインが一致しない)や ERR_SSL_PROTOCOL_ERROR です。
この種のエラーの特徴は、別のノードに切り替えると問題が即座に解消すること、または同じノードでどのサイトにアクセスしても似たような接続異常が出て、特定のドメインだけに限らないことです。判断手順は以下の通りです。
- まずクライアントで遅延が正常な別のノードに切り替えて再試行します。問題が解消すれば元のノードの異常だとほぼ確定できるので、サブスクリプショングループ内でそのノードをスキップ設定にするか、サブスクリプションの更新を待つとよいでしょう。
- どのノードに切り替えても同じエラーが出る場合は、ノードの問題である可能性は低く、前述の2つの原因(時刻、MITM)を再確認すべきです。
- 自前で構築したノードを使っている場合は、コマンドラインツールでサーバー側の証明書の状態を直接確認し、期限切れやドメイン不一致がないか確認できます。
openssl s_client -connect example.invalid:443 -servername example.invalidコマンド出力の中の Verify return code が 0 以外の場合、サーバー側の証明書自体に問題があることを示しています。これはクライアント設定の問題ではなく、ノード提供者に連絡するか証明書を再発行してもらう必要があります。
TUNモードにおける特有の確認方法
TUNモード(仮想ネットワークカードで全トラフィックを引き受ける方式)を有効にした場合、証明書問題の確認手順は通常のプロキシモードとほぼ同じですが、トラフィックがシステムネットワークスタックの仮想インターフェースを経由するため、追加で2点確認が必要です。1つ目は仮想ネットワークカードのDNSが信頼できる解決サーバーを指しているかどうかです。DNS汚染やハイジャックが発生すると、ブラウザが誤ったIPに接続してしまい、対象ドメインと一致しない証明書を目にすることになります。2つ目はファイアウォールやセキュリティソフトが仮想ネットワークカードのトラフィックに対して追加のブロックやリダイレクトを行っていないかどうかです。一時的にTUNモードを無効化し、通常のシステムプロキシモードで同じサイトに再アクセスしてみてください。証明書警告が消えれば、問題の範囲をTUN関連のDNSまたはルーティング設定に絞り込めます。
クイックセルフチェックリスト
以上4種類の原因をまとめると、証明書警告が出た際は次の順序でセルフチェックすると、通常は数分以内に問題の範囲を特定できます。
システム時刻とタイムゾーンを確認する
自動同期が実際に有効になっているか、時刻の誤差が数分を超えていないか確認します。
MITMやスクリプト書き換えが有効になっていないか確認する
一時的にこの機能を無効化して再試行し、エラーが消えるか確認します。
エラーが特定のドメインに限られているか確認する
全サイトでエラーが出る場合は時刻やシステムレベルの問題を、単一ドメインのエラーはMITMルールやハイジャックの可能性を疑います。
ノードを切り替えて再テストする
遅延が正常な別のノードに変更し、問題がノードによって変化するか判断します。
サブスクリプションとノードの入手元を確認する
ハイジャックの疑いがある場合は、機密性の高い操作を停止し、サブスクリプションの入手元を変更してください。
ほとんどの証明書警告は、この5つの手順以内で明確な原因を特定できます。確認の結果、設定自体に問題があると分かった場合は、既存のルールを一つずつ修正するよりも、クリーンなサブスクリプション設定を再インポートするか、クライアントの初期設定に戻すほうが時間の節約になることが多いです。