まず確認：証明書エラーは通常の接続タイムアウトとは別の問題
まずシステム時刻を確認し、証明書の情報を記録してから、プロキシ経由とTUN経由を比較しましょう。ブラウザーに NET::ERR_CERT_AUTHORITY_INVALID と表示されるのは、受信した証明書の信頼性を確認できなかったという意味です。ノードのタイムアウトやサブスクリプションの期限切れとは別の問題です。ノードを切り替えると症状が変わることはありますが、証明書の確認にはなりません。
通常のClashまたはClash Meta（mihomo）によるプロキシ接続では、HTTPS通信はそのまま転送され、接続先サイトの証明書が再発行されることはありません。HTTPプロキシでは、ブラウザーがCONNECTでトンネルを確立した後、接続先サイトとTLSハンドシェイクを行います。サイトの証明書は引き続きブラウザーが検証します。Clashクライアントを通常どおり使うために、いわゆる「Clashルート証明書」をインストールする必要はありません。
まず次の5項目を記録
- アドレスバーに表示された完全なドメイン名と、エラーページのエラーコード。共有する際は、URLからトークンや個人情報を含むパラメーターを削除してください。
- 証明書の発行者、有効期間、サブジェクト代替名（SAN）。ブラウザーによって、エラーページの詳細情報または証明書ビューアーから確認できます。
- 影響範囲：1つのドメイン、同じ組織の複数のドメイン、それともほぼすべてのHTTPSサイトか。
- Clashの現在のモード、実際に選択されているノード、システムプロキシとTUNモードの有効・無効。
- 発生前にパケットキャプチャーツールを有効にしたか、セキュリティソフトを更新したか、ホテルや空港など認証が必要なネットワークに接続したか。
エラーコードから確認範囲を絞る
ChromeやEdgeなどChromium系ブラウザーでは似たコードが使われますが、Firefoxでは表示が異なる場合があります。エラーコードは検証に失敗した段階を示すもので、原因となったソフトを特定するものではありません。まず下の表を確認してから、次の手順に進みましょう。
| エラーコード | 主な原因 | 優先して確認する項目 |
|---|---|---|
NET::ERR_CERT_DATE_INVALID | 証明書の期限切れ・有効期間前、または端末の時刻が不正 | システムの日付と時刻、時刻同期、証明書の有効期間 |
NET::ERR_CERT_AUTHORITY_INVALID | 証明書チェーンが信頼されたルート証明書につながらない | パケットキャプチャープロキシ、セキュリティソフト、組織の証明書、サーバーの中間証明書チェーン |
NET::ERR_CERT_COMMON_NAME_INVALID | 証明書の対象名とアクセス先ドメインが一致しない | アドレスの入力ミス、DNS、hosts、認証ゲートウェイ |
NET::ERR_CERT_REVOKED | 証明書が失効している | サイト証明書の状態、発行元、サーバー側の更新状況 |
ERR_SSL_PROTOCOL_ERROR は、必ずしも証明書の信頼性に関するエラーではありません。ポートのサービスが正しくない、TLSネゴシエーションに失敗した、ネットワーク機器が干渉した、といった可能性もあります。「SSL」を含むエラーをすべて「ルート証明書不足」と決めつけないでください。
手順1：システム時刻と証明書の有効期間を確認する
端末の時刻が過去や未来にずれていると、本来有効な証明書が「有効期間前」または「期限切れ」と判定されることがあります。関係のない複数のサイトで同時に日付関連のエラーが出る場合は、ルールをまとめて変更するのではなく、まず端末を確認しましょう。
- Windows 11では「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」を確認してから「今すぐ同期」をクリックします。日付、年、表示時刻が正しいことも確認してください。
- macOSでは「システム設定」→「一般」→「日付と時刻」を開き、日付と時刻の自動設定、およびタイムゾーンの設定を確認します。
- 同期後はブラウザーを完全に終了して再起動し、元のURLを開き直してください。エラーページを再読み込みするだけでは不十分です。
- 1つのサイトだけ引き続き失敗する場合は、そのサイトの証明書の有効期間を確認してください。サーバー証明書が実際に期限切れなら、サイト管理者による更新が必要です。
Windowsのコマンドラインで確認する
Get-Date
w32tm /query /status次のコマンドはPowerShellで現在時刻とWindowsの時刻サービスの状態を確認するために使います。2つ目のコマンドは、サービスが動作していない場合にエラーになることがあります。タイムゾーンは主に表示に影響します。証明書の検証で重要なのは実際のシステム時刻なので、年月日を確認せずタイムゾーンだけ変更しないでください。電源を切るたびに時刻がリセットされる場合は、ファームウェアの時刻とハードウェアクロックも確認が必要です。
手順2：パケットキャプチャープロキシとHTTPSスキャンを確認する
CharlesやFiddlerなどのデバッグツールでHTTPS復号を有効にすると、ツールのローカルルート証明書で署名されたサイト証明書がブラウザーに提示されます。一部のセキュリティソフトによるHTTPSスキャンや企業ゲートウェイも、同様の仕組みを使う場合があります。ルート証明書が現在のブラウザーで信頼されていない、期限切れになっている、またはツールのアンインストール後もプロキシ設定が残っていると、警告が表示されることがあります。
まず証明書の発行者を確認する
- 複数の異なるサイトの証明書が、同じローカルデバッグツールや組織名で発行されている場合は、サイトではなく途中のプロキシを優先して確認してください。
- 自分でインストールしたパケットキャプチャーツールとHTTPS復号機能を一時停止し、システムプロキシがそのツールの待ち受けポートを引き続き参照していないか確認します。
- Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」で手動プロキシを確認できます。macOSでは「システム設定」→「ネットワーク」→現在の接続→「詳細」→「プロキシ」を確認してください。
- Clashで実際に使われている混合ポートも記録してください。
7890はよくある例にすぎず、別のプロセスが使用していることもあります。システムプロキシのアドレスは、現在のクライアントに表示されている待ち受けアドレスと一致している必要があります。
個人の端末で特定のブラウザーだけエラーになる場合は、別の最新ブラウザーでも比較できます。ブラウザーのバージョンやルート証明書の保存先、管理ポリシーは異なるため、別のブラウザーで開けても、異常な証明書をそのまま信頼してよいわけではありません。
手順3：DNS、hosts、ネットワーク認証ページを確認する
DNS自体がHTTPS証明書を発行することはありませんが、名前解決を誤ると接続先が別のサーバーになることがあります。あるドメインに接続したのに別のドメインの証明書が返されると、名前の不一致が発生します。公衆Wi-Fiの認証ゲートウェイ、古いhostsエントリー、誤ったDNSの割り当てを確認しましょう。
認証ネットワークを先に確認し、その後で名前解決を調べる
- ホテルや空港のWi-Fiに接続した直後なら、システムが案内するネットワークログインページで認証を済ませてください。証明書エラーのページでアカウント情報を入力しないでください。
- hostsファイルに対象ドメインの古い割り当てがないか確認します。Windowsのファイルパスは
C:\Windows\System32\drivers\etc\hosts、macOSとLinuxでは通常/etc/hostsです。 - Windowsでは次のコマンドでシステムのDNS検索結果を確認し、システムのキャッシュを消去できます。消去後はブラウザーを再起動し、Clash側のDNSキャッシュと接続も確認してください。
nslookup example.com
ipconfig /flushdnsexample.com はコマンド書式の例です。実際の確認では、エラーが起きたドメインに置き換えてください。なお、nslookup の検索経路はブラウザーと異なる場合があります。ブラウザーのセキュアDNS、プロキシ側の名前解決、TUNのDNSリダイレクトによって結果が変わることがあります。コマンドの出力だけでは、ブラウザーがどのアドレスに接続したかは判断できません。
Fake-IPアドレスを見ただけでDNS汚染と判断しない
mihomoでFake-IPモードを使用すると、アプリに 198.18.0.0/16 の範囲のマッピングアドレスを返し、カーネルが元のドメインに対応付けることがあります。この範囲は一般的な設定例であり、すべてのクライアントで同じとは限りません。この範囲のアドレスが表示されても、偽サイトに接続したとは限りません。有効な設定の dns.enhanced-mode、fake-ip-range、接続ログを合わせて確認してください。
直結経路でのみ誤った証明書が返され、プロキシ経由では正常にアクセスできる場合に限り、ローカルの名前解決、利用中のネットワーク、直結先サーバーをさらに調べます。確認のためにHTTPSのURLをIPアドレスに置き換えないでください。証明書は通常ドメイン名に対して発行されるため、IPアドレスへの直接アクセス自体が名前の不一致を招くことがあります。
手順4：システムプロキシとTUNモードを分けて検証する
TUNモードは通常、ネットワーク層で通信を取り込みますが、TLSを自動的に復号するわけではありません。有効にしたときだけエラーが起きる場合は、ルーティングやDNSの処理、ルール判定が変わり、接続経路が切り替わった可能性があります。他のVPN、仮想ネットワークアダプター、セキュリティソフトとの競合も考えられます。
一度に1つずつ条件を変えてテストする
- 基準となる状態を記録：現在のモード、ノード、DNS設定、エラーになった証明書の情報を保存します。テスト中はノードを固定し、サブスクリプションの更新やルール変更を同時に行わないでください。
- システムプロキシをテスト：TUNを無効にしてシステムプロキシを有効にし、ブラウザーを完全に終了してから再起動します。拡張機能や組織のポリシーで別のプロキシが指定されていないことも確認してください。
- TUNをテスト：システムプロキシを無効にしてからTUNを有効にします。同じドメインとノードを使い、Clashの接続ログでルール、アウトバウンドの処理、接続先の情報を確認してください。
- ローカルで直接接続してテスト：システムプロキシとTUNを無効にし、他のVPNや手動プロキシも接続を取り込んでいないことを確認します。接続を確立し直して、サイトが開くかどうかだけでなく、証明書も比較してください。
TUN経由だけで失敗する場合は、まずDNSリダイレクト、他のVPN、仮想ネットワークアダプターとの競合を確認します。システムプロキシ経由でも失敗する場合は、証明書の発行者と実際に使われたノードを比較してください。設定を変更する前にバックアップを取り、一度に1項目だけ変更します。サブスクリプションの更新で直接編集した内容が上書きされることがあります。設定を維持するには、クライアントが対応するオーバーライドまたはマージ機能を使い、項目の詳細は使用中のmihomoのバージョンに合わせて確認してください。
curlで接続経路を比較し、検証結果を記録する
以下では、ローカルのHTTPまたは混合プロキシのポート 7890 を例にします。コマンドを実行する前に、クライアントの設定画面でポートを確認してください。Windows PowerShellでは curl.exe を使うと、環境によって同名の別名コマンドが使われるのを避けられます。
curl.exe -Iv --proxy http://127.0.0.1:7890 https://example.com/
curl.exe -Iv --noproxy "*" https://example.com/macOSとLinuxでは curl.exe を curl に置き換えてください。1つ目のコマンドはアプリケーション層のプロキシを明示し、2つ目はcurlのアプリケーション層のプロキシ設定を使いません。2つ目のコマンドでもTUNや、システム内の他のネットワーク層による通信の取り込みは回避できません。ローカルでの直接接続と比較するには、これらの機能を先に無効にしてください。
- TLSの検証結果、証明書のサブジェクト、発行者を比較します。出力される証明書情報の量は、curlのバージョンやTLSバックエンドによって異なります。
- curlのエラーコード
60は通常、証明書の検証失敗を示します。後続の具体的なエラー内容も確認してください。これだけでDNSの問題と判断することはできません。 -kや--insecureを追加しないでください。現在調査している検証をスキップしてしまいます。- curlとブラウザーでは信頼する証明書の保存先が異なる場合があります。curlで成功しても、ブラウザーのポリシーに問題がないとは限りません。HEADリクエストが
405を返しても、TLSハンドシェイクの失敗を意味するわけではありません。
ログを共有する前に、プロキシの認証情報、Cookie、サブスクリプションURL、トークン付きのリクエストパラメーターを削除してください。設定全体を送るより、テスト時刻、エラーコード、証明書の発行者を伝えるほうが原因究明に役立ちます。
影響範囲に応じて次の対応を決める
すべてのサイトでエラーが出る
まずシステム時刻、ルート証明書の更新状況、パケットキャプチャーツール、ネットワーク認証を確認します。OSとブラウザーはサポート対象の最新状態に保ってください。古いOSでは、信頼ストアに新しい証明書チェーンが含まれていない場合があります。提供元不明のルート証明書「修復パッケージ」はダウンロードしないでください。
特定のサイトだけエラーが出る
別の端末と別のネットワークでも比較してください。どちらでも同じ期限切れ証明書や名前の不一致が表示される場合は、サイト管理者に連絡します。特定のノードでのみ起きる場合は、そのノードと証明書の情報を記録し、別の信頼できるノードに切り替えて再確認したうえで、サービス提供者に報告してください。
復旧後に確認すること
- エラーが起きたドメインと、少なくとも異なる2つのサイトで、証明書の検証が正常に完了する。
- 証明書が現在アクセスしているドメインをカバーし、有効期間に問題がなく、出所不明のルート証明書が追加されていない。
- 通常のルールモードに戻した後、接続ログのアウトバウンド処理が想定どおりである。クライアントとブラウザーを再起動しても結果が変わらない。
最終的に直すべきなのは、ブラウザーの警告を隠すことではなく、時刻、証明書チェーン、名前解決、接続経路の具体的な問題です。モードやサブスクリプションの操作を確認する場合は、Clash設定マニュアルをご覧ください。クライアントのインストールや初期設定については、使い方ガイドをご確認ください。