Clash 起動後に HTTPS 証明書エラーが出る原因と正しい対処法
ブラウザの証明書警告とプロキシの本当の関係を解説。ノードによる中間者行為、時刻ズレ、ローカル遮断ソフトのどれが原因か、クライアントと無関係なケースも含め対処法を整理。
ブラウザの証明書警告とプロキシの本当の関係を解説。ノードによる中間者行為、時刻ズレ、ローカル遮断ソフトのどれが原因か、クライアントと無関係なケースも含め対処法を整理。
ブラウザで「接続がプライベートではありません」や「証明書が無効です」という表示に初めて遭遇したとき、多くの人はまずプロキシクライアントを止めようとします。その反応は理解できますが、方向性としては大抵ずれています。HTTPS 証明書の検証はブラウザとアクセス先サイトの間で行われるものであり、検証対象はサイトの証明書チェーンが信頼された認証機関(CA)によって発行されているか、ドメインが一致しているか、有効期限が現在時刻をカバーしているかです。Clash や Clash Meta(mihomo)コアはプロキシ層として、リクエストをどのノード・どの経路に転送するかを担当するだけで、TLS ハンドシェイク中にやり取りされる証明書の内容を書き換えることはできません——中間で能動的な通信改ざんが行われていない限りは。
つまり証明書エラーは本質的に「ブラウザがこの証明書を信頼していない」という状態であり、信頼チェーンが崩れる原因は主に3パターンに分かれます。プロキシノードや着地ネットワーク自体に中間者的な挙動がある場合、ローカルのシステム時刻がネットワーク環境と同期しておらず証明書の有効期限判定を誤る場合、そしてセキュリティソフトや企業のゲートウェイが端末側で通信検査用の自己署名ルート証明書を組み込んでいる場合です。この3パターンの違いを理解することが、問題がどの層にあり誰に対処すべきかを判断する前提になります。
まず分類し、それから調査する方が、クライアントを闇雲に再インストールしたりノードを頻繁に切り替えたりするより効率的です。
これは最も警戒すべきパターンです。ブラウザで証明書が「信頼されていない発行元により発行されています」または「証明書とドメインが一致しません」と表示され、証明書の詳細を開いたときに発行者名が見慣れないもので、そのサイトが通常使っている CA と異なっている場合(銀行や大規模サービスの証明書は通常、いくつかの有名な CA に固定されています)、通信が目的のサイトへ到達する前に、何らかの中間ノードによって傍受され偽造証明書を再発行されている可能性があります——これが典型的な TLS 中間者(MITM)攻撃です。この挙動は着地サーバー側の通信事業者レベルで発生することもあれば、ノード自体が通信を能動的に検査するよう設定されていることもあります。
調査方法:同じサイトに対し、別のノードや別のサブスクリプション元に切り替えて再アクセスします。ノードを切り替えたら証明書表示が正常に戻る場合、問題は元のノードまたはその着地経路にあり、クライアントやローカル設定の問題ではないとほぼ確定できます。この場合は当該ノードの使用を停止することを推奨します。特にログインや決済が絡む場面では継続利用を避けてください。
証明書には明確な有効期間の枠があり、ブラウザは端末のシステム時刻がその枠内にあるかを確認します。パソコンが長期間ネットに接続しておらず時刻同期をしていない、仮想マシンの時計がずれている、あるいは日付を手動で変更したなどの理由でシステム時刻に明らかなずれが生じている場合(数時間のずれでも、発効直前や期限直前の証明書に当たると警告が出ます)、「証明書はまだ有効ではありません」や「証明書の期限が切れています」という表示が出ることがあります。これはプロキシとは全く無関係で、どのノードに切り替えても解決しません。
調査方法:システム時刻が自動同期になっているか、タイムゾーンが正しいかを確認します。Windows では「設定 → 時刻と言語 → 日付と時刻」から自動設定をオンにし、手動で「今すぐ同期」を一度実行します。時刻を修正した後にエラーが消えれば、問題は端末の時計にあったと分かり、クライアントやサブスクリプションを疑う必要はありません。
一部のウイルス対策ソフト、ペアレンタルコントロール、企業のネットワーク管理ポリシーは、システムやブラウザの証明書ストアに独自のルート証明書をインストールし、HTTPS 通信の内容検査を行います。この処理は本質的には「合法的な」中間者的挙動ですが、端末側で発生する点が遠隔ノードとは異なります。証明書の詳細で発行者があるセキュリティソフト会社の名前や、企業内部の認証機関になっている場合、その証明書エラーはプロキシノードや Clash クライアントとは無関係で、こうしたソフトの証明書挿入機能が原因です。
調査方法:該当のセキュリティソフトを一時的に終了するか、企業ネットワークから切断して同じサイトに再アクセスします。エラーが消えれば問題はローカルソフト側にあると特定でき、そのソフトの設定で「HTTPS 通信スキャン」のような項目を無効にする、または(信頼性を評価した上で)その証明書を信頼済みとして受け入れることができます。
TUN モードが全体の通信を引き受けている場合、調査の考え方を少し調整する必要があります。
Clash Meta(mihomo コア)がサポートする TUN モードは、システムのネットワーク層に仮想ネットワークカードを作成し、デバイス上のほぼすべての送信通信をプロキシに取り込みます。ブラウザや手動でプロキシを設定したアプリだけではありません。これは、あるノードに中間者的な挙動があった場合、影響範囲が「ブラウザでアクセスしたサイト」から「その仮想ネットワークカードを経由するすべての TLS 接続」に拡大することを意味します。システム更新や一部クライアントソフトの API リクエストなどが含まれますが、これらの場面ではブラウザのような明確な安全警告が出ないため、証明書エラーがユーザーに直接見えにくく、単に接続失敗や無音での再試行になることが多いです。
TUN モードを有効にした後で一部のアプリに接続異常、ハンドシェイク失敗、あるいは説明のつかないログイン状態の失効が発生し、それらのアプリがシステムプロキシモード(HTTP/SOCKS プロキシのみ経由)では正常に動作する場合は、一時的に TUN モードを無効にしてシステムプロキシモードに戻して再テストしてください。この手順で、問題が仮想ネットワークカードによる通信の取り込み範囲に関連するものか、それともノード自体の証明書問題かを確認できます。日常利用では、システムプロキシ設定に対応していないクライアントソフトなど、本当にグローバルプロキシが必要な場合に限って TUN モードを有効にすることで、調査すべき範囲を減らせます。
証明書エラーに遭遇したら、複数の設定を同時に変更するのではなく、以下の順序で一つずつ除外していくことを推奨します。
証明書表示のすべてがリスクを意味するわけではありませんが、機密性の高い操作を行う場面ではリスクを取らないことを推奨します。
ログインページ、決済ページ、アカウントのパスワード入力が必要なサイトにアクセスしている場合、発行元が見慣れない、ドメインが一致しないといった警告が出たら、まず操作を止め、ノードを切り替えるかプロキシを切って直接接続でテストし、サイト自体の証明書が正常であることを確認してから続けることを推奨します。乗っ取られた中間ノードを経由してアカウント情報が通過するリスクを避けるためです。
一般的な情報サイトへのアクセスで、証明書警告がノード切り替えやシステム時刻の同期後に消えた場合、問題は既に特定・解決済みであり、追加で心配する必要はありません。このような偶発的な中間者的遮断は、多くの場合ある着地経路のネットワーク環境に関連しており、ノードを変更すれば正常なアクセスに戻ります。
この場合はアクセス先サイト自体の証明書設定の問題である可能性が高いです。例えば証明書の期限がもうすぐ切れる、証明書チェーンが不完全、そのサイトの一部の CDN ノードの設定に誤りがあるなど、プロキシソフトとの関連は薄いです。まず(プロキシを一時的に切って)直接接続で同じサイトにアクセスしてみてください。直接接続でもエラーが出るなら、問題は完全にサイト側にあり、Clash とは無関係です。
別のブラウザで同じサイトをテストしてみてください。新しいブラウザでも同じエラーが出る場合、問題はブラウザキャッシュの層ではなく、ノードやシステムの証明書ストアにある可能性が高いです。前述の各パターンに沿って一つずつ調査してください。
欠陥ではなく、通信の取り込み範囲が異なることによる表れの違いです。TUN モードはより多くの種類の接続を取り込むため、あるノード経路に問題がある場合、影響を受ける接続数が多くなり、より目立って現れます。問題の根本原因はやはりノードであり、TUN モードという機能自体にあるわけではありません。