Clashの証明書エラー対処法｜システム時刻・中間者・TUNの確認手順
Clash利用中にNET::ERR_CERTが表示される場合、時刻のずれ、ノード経由の通信、TUNとセキュリティソフトの競合が考えられます。原因を絞り込む手順と確認方法を解説します。
エラー内容を記録し、時刻・ノード・TUNの順に確認
「続行してアクセス」はクリックせず、相手から送られたルート証明書もインストールしないでください。HTTPSの証明書エラーは、ブラウザーが接続先の身元を確認できないことを示します。「プロキシが遅い」という意味ではありません。通常のClashによるプロキシ転送で、ブラウザーの証明書検証を無効にする必要はありません。mihomoのTUNによる通信の取り込みも、HTTPSの復号を意味するものではありません。
メール、決済サービス、管理画面を開いている場合は、まずパスワードの入力を中止してください。エラーコード、アクセス先のドメイン、証明書の発行者、発生時刻を記録してから比較します。この記事に登場するポート番号とドメインは確認方法を説明するための例であり、クライアントの初期設定や当サイトでの検証結果を示すものではありません。
- システムの日付・時刻、タイムゾーン、証明書の有効期間を確認し、端末の時計のずれを除外します。
- プロキシを完全に終了した状態で確認し、その後2つのノードを比較します。
- 証明書のドメイン名と発行者を確認し、ポータル画面やHTTPS検査の有無を判断します。
- TUNだけを切り替え、DNS・ルーティング・セキュリティソフトを確認します。
- コマンドラインでも確認し、根拠に基づいて設定を戻す項目を決めます。
エラーコードを確認：証明書エラーとTLSハンドシェイク失敗は別
Chromium系ブラウザーのエラーコードには、通常NET::ERR_CERT_という接頭辞が付きます。Firefoxでは表示文言やコードが異なりますが、確認するのは時刻、証明書チェーン、ドメイン名、信頼元です。「安全な接続を確立できません」とだけ覚えるのではなく、コード全体を記録してください。
| エラーの例 | 主な意味 | まず確認する項目 |
|---|---|---|
NET::ERR_CERT_DATE_INVALID |
端末の時計が証明書の有効期間外と判定 | システム時刻、証明書の有効開始日・終了日 |
NET::ERR_CERT_AUTHORITY_INVALID |
証明書チェーンを信頼できるルートまでたどれない | 発行者、チェーンの完全性、HTTPS検査 |
NET::ERR_CERT_COMMON_NAME_INVALID |
証明書が現在のホスト名に適用されない | 証明書のSAN、ポータルへのリダイレクト、DNS、hosts |
NET::ERR_CERT_REVOKED |
証明書が失効済みと判定 | 証明書の情報、サイト、セキュリティ製品の状態 |
ERR_SSL_PROTOCOL_ERROR |
TLSの通信に問題があり、有効な証明書を取得できたとは限らない | プロキシのポート・プロトコル、経路上の機器、サーバー |
エラーが発生する範囲も重要です。1つのドメインだけで起きる場合は、そのサイトまたは適用されているルールを優先して疑います。関係のない複数のHTTPSサイトで同時に起きる場合は、端末の時刻、信頼ストア、共通して経由するネットワーク機器を確認してください。どちらの場合も、「Clashを起動した直後」というだけでコアの破損と決めつけることはできません。
手順1：システム時刻と証明書の有効期間を確認
システムの自動時刻同期を行い、同じURLを再度開く
Windows 11では「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」を確認して「今すぐ同期」を実行します。macOSでは「システム設定」→「一般」→「日付と時刻」を開き、日付と時刻の自動設定を確認します。組織管理の端末で変更が制限されている場合は、管理者に問い合わせてください。
- まず年・月・日を確認します。スリープからの復帰時やマザーボードの電池の不具合で、時計が過去に戻ることがあります。
- 次にタイムゾーンを確認します。現地時刻が正しく表示されていても、UTCが正しいとは限りません。時計を目視するだけで判断しないでください。
- ブラウザーの証明書ビューアーを開き、「有効期間の開始」と「有効期間の終了」を記録して、システム時刻と比較します。
たとえば、証明書の有効期限が今日より前で、そのサイトだけでエラーが起きる場合は、サイトの管理者による証明書の更新が必要です。システムの日付が証明書の有効開始日より前なら、複数のサイトで接続に失敗することがあります。期限切れの証明書に合わせて時計を過去に戻さないでください。ログイン用トークン、ソフトウェア更新、ほかの通信にも影響します。
Linuxではコマンドで時刻同期の状態を確認
timedatectl status
date -usystemdを使用するディストリビューションでは、1つ目のコマンドで時刻・タイムゾーン・同期状態を確認でき、2つ目でUTC時刻を表示できます。時刻同期が有効なのに長時間同期されない場合は、利用中の時刻同期サービスとネットワークへの接続を確認してください。修正後に対象ページを開き直し、プロキシ設定の変更が必要か判断します。
手順2：直結とノードを比較し、問題の範囲を確認
「システムプロキシを無効にする」だけでは、必ずしも直結にはなりません。TUNが引き続き通信を取り込んでいたり、別のVPNがルートを保持していたりする場合があります。現在のモード、ノード、DNS設定を保存してからクライアントを終了し、TUNが無効でシステムプロキシが解除されていることを確認してください。テスト目的で、見覚えのないログインページにアクセスしないでください。
| テスト条件 | 確認する内容 | 判断の手がかり |
|---|---|---|
| クライアントを終了し、ほかのVPNも無効にする | 同じURLで同じエラーコードが出るか | 引き続きエラーが出る場合は、サイト・端末・現在のネットワークを確認 |
| システムプロキシを有効、TUNを無効にしてノードAを使用 | 適用されたルール、実際の出口、証明書の発行者 | 通常のプロキシ転送の基準を確認 |
| 同じモードのままノードBに切り替える | エラーが解消するか、証明書が変わるか | ノードを変えたときだけ発生するなら、ノードの通信経路を重点的に確認 |
| ノードAに戻し、TUNだけを有効にする | TUNを有効にしたときだけエラーが出るか | ルーティング、DNS、ドライバーの共存状態を確認 |
ノードを切り替えたら、クライアントの「接続」パネルで新しい接続が実際にそのノードを通っているか確認してください。プロキシグループが別のメンバーを自動選択したり、ルールによって対象ドメインがDIRECTに送られたりすることがあります。比較の際はエラーが出たタブを閉じて開き直し、必要に応じてブラウザーも再起動して、古い接続の再利用を避けてください。
手順3：証明書の発行者を確認し、ポータル画面と中間者を見分ける
通常のプロキシ転送でWebサイトの証明書を差し替える必要はない
ブラウザーがHTTP CONNECT、SOCKS、またはTUN経由で通信しても、通常はブラウザーとWebサイトの間でTLS接続が確立されます。Clashやmihomoは、プロキシを有効にしただけで、すべてのサイトの証明書を再発行する必要はありません。複数の無関係なサイトで、同じローカルセキュリティ製品名や企業名が発行者として突然表示される場合は、HTTPS検査機能と端末の管理ポリシーを確認してください。
企業のゲートウェイは、組織のポリシーに基づいてHTTPSを復号・検査することがあります。一部のセキュリティソフトにも同様の機能があります。そのルート証明書が現在のブラウザーで信頼されていないと、証明書チェーンのエラーが起きる場合があります。FirefoxとChromiumでは、証明書の信頼設定、OSとの連携、企業ポリシーが異なります。そのため「別のブラウザーなら開ける」ことで原因を絞り込めても、通信経路が正常だと証明されたわけではありません。
- ドメイン名の一致：証明書のサブジェクト代替名（SAN）に、アクセス先のホスト名が含まれているか確認します。ワイルドカード
*.example.comはルートドメインexample.comや、階層が複数あるサブドメインには適用されません。 - 発行者が不自然：ルーター、見覚えのない組織名、ローカル製品名などに変わっている場合は、まず発行元を確認してください。安易に信頼する証明書へ追加しないでください。
- 証明書が変わった：CDNは地域によって異なる証明書を提供することがあります。証明書が違うだけで中間者攻撃とは限りません。ドメイン名、有効期間、信頼チェーンも確認してください。
公衆Wi-Fiでは、まずネットワーク認証を完了
ホテルや空港のネットワークでは、ポータル認証がまだ完了していないことがあります。OSに表示されるネットワークログイン画面を優先して使い、接続先のネットワーク名を確認してください。必要であれば、既知の通常のHTTPページにアクセスしてポータルを表示します。HTTPSの証明書警告ページでアカウント情報を入力したり、ポータルを通過するために見知らぬ証明書をインストールしたりしないでください。認証後も証明書が一致しない場合は、機密情報を扱う通信にその経路を使わないでください。
特定のノードだけで証明書の不一致が続き、ほかのノードでは正常な場合は、そのノードを無効にして、発生時刻・ドメイン・証明書の情報をサービス提供元に伝えてください。ノードの障害、出口側のDNS異常、転送経路上の干渉などが考えられますが、1回のエラーだけで、どの相手が中間者攻撃を行ったか断定することはできません。
手順4：TUN利用時だけエラーが出る場合は、DNSとルーティングを確認
TUNは仮想ネットワークインターフェースを通じてシステムの通信を転送する方式であり、それ自体がWebサイトの証明書を発行するわけではありません。有効にしたときだけエラーが出る場合は、これまでプロキシを経由していなかった通信が取り込まれたか、DNS・ルーティング・セキュリティ製品による処理経路が変わった可能性があります。同じノードとルールモードを維持したままTUNだけを無効にして、結果を比較してください。
fake-ipのアドレスは、Webサイトが返した証明書ではない
一般的なfake-ip設定では、コアがドメイン名を198.18.0.0/16の範囲のアドレスに割り当て、その対応関係に基づいて接続を処理することがあります。実際の範囲は有効な設定を確認してください。このようなDNS応答があっても、証明書が差し替えられたことにはなりません。確認すべきなのは、その接続が対応関係を管理するコアに届いているか、対象ドメインが最終的にどこへ転送されたかです。
- 接続ログを開いて対象ドメインを検索し、適用されたルール、プロキシグループ、出口を記録します。
- 有効な設定で
dns.enhanced-mode、tun.dns-hijack、ルーティング関連の項目を確認します。サブスクリプションの元ファイルだけを見て判断しないでください。GUIクライアントが設定を上書きしている場合があります。 - ブラウザーの「セキュアDNS」設定を確認します。ブラウザー内蔵のDoHとシステムDNSでは、異なる経路を使うことがあります。設定を変更する際は、元の値を記録してください。
- 端末のhostsファイルでドメイン名が古いアドレスに割り当てられていないか確認します。Windowsの一般的な場所は
C:\Windows\System32\drivers\etc\hosts、LinuxとmacOSでは/etc/hostsです。 - ほかのVPNやネットワークフィルタリングツールを1つずつ停止して比較します。企業管理端末では、事前に管理者の許可を得てください。複数のコンポーネントを一度にアンインストールしないでください。
DNSが誤ったサーバーを指していても、ブラウザーがTCP接続を確立し、別のドメイン向けの証明書を受け取ることがあります。その結果、ドメイン名の不一致エラーになります。一方、ルーティングの競合ではタイムアウトや接続リセットが起きやすく、TUNの異常をすべて証明書エラーと呼ぶべきではありません。エラーコードと証明書の詳細が一致する場合に限り、証明書の観点から調査を続けてください。
手順5：curlとブラウザーの結果を比較し、ポート番号の誤りを防ぐ
ここではローカルのHTTPプロキシ、または混合プロキシの待ち受けアドレス127.0.0.1:7890を例にします。まずクライアントの待ち受け設定または有効な設定ファイルで実際のポートを確認してください。7890がすべてのクライアントで使われる固定値というわけではありません。WebサイトがHTTPSだからといって、ローカルプロキシのアドレスをhttps://127.0.0.1:7890とする必要はありません。
Windowsで2種類のリクエストを実行
curl.exe -v --noproxy "*" --connect-timeout 10 --max-time 30 https://example.com/
curl.exe -v --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 https://example.com/1つ目はcurlで明示的に設定したプロキシを使わず、2つ目はローカルのHTTPプロキシを強制的に使い、プロキシを使わないホストの一覧を空にします。実際の不具合を調べる場合は、例のドメインをエラーが起きるサイトの公開トップページに置き換え、ログイン用トークンは含めないでください。macOSまたはLinuxではcurl.exeをcurlに置き換えます。
- 直結を試す前にTUNを終了：
--noproxy "*"では、OSレベルのTUNルートを回避できません。 - CONNECTとTLSを区別：
200 Connection establishedが表示されても、プロキシトンネルが確立しただけです。Webサイトの証明書検証に成功したことを示すものではありません。 - 返されたエラーを確認：curlのエラー60は通常、接続先の証明書検証失敗を示します。エラー7や28は、接続失敗またはタイムアウトを示すことが多いです。
- 検証スキップのオプションを付けない：ここで確認するのは検証が失敗する理由であり、リクエストを強制的に成功させることではありません。
curlとブラウザーではTLSバックエンドや信頼元が異なる場合があります。そのため、結果が一致しない場合は、証明書の発行者、システムプロキシ、ブラウザー拡張機能、管理ポリシーを引き続き確認し、どちらか一方の結果が必ず正しいと決めつけないでください。詳細ログには接続先アドレスや認証情報が含まれることがあります。共有する前に機密情報を伏せてください。
設定を元に戻して再テスト：変更は一度に1項目
関係する要因が見つかったら、まずテスト用に変更したほかの設定を元に戻し、必要な修正だけを残します。たとえば、時刻を合わせて解決したならDNSを変更する必要はありません。特定のノードだけに問題がある場合は、まずそのノードを無効にします。企業のHTTPS検査時だけ失敗する場合は、管理者に証明書の配布とポリシーを確認してもらってください。
- 最初にエラーが出たURLを再テストし、同じ証明書エラーが起きないことを確認します。
- さらに、関連のないHTTPSサイトを2つテストし、信頼設定に全般的な問題がないか確認します。
- 接続パネルで対象通信の実際の出口を確認し、直結に戻っただけなのにプロキシが修復されたと誤認しないようにします。
- 一時的に無効にしたセキュリティ機能やDNS設定を元に戻し、設定ごとに問題が再発しないことを確認します。
- エラーコード、ノード名、コア名、TUNの状態、実施した修正を記録し、後から再現できるようにします。
問い合わせる際は、クライアントの実際のバージョン、コアのバージョン、OSのバージョン、機密情報を伏せたログを添付できます。サブスクリプションURL、プロキシのパスワード、プライベート設定全体は公開しないでください。クライアント名とコア名は分けて記録してください。GUIが似ていても、同じClashまたはmihomoコアを使っているとは限りません。
設定の詳細はマニュアルのDNS解説とプロキシモードの解説をご覧ください。判断の要点は、現在時刻が正しいか、証明書が誰に発行されたか、その接続が実際にどの経路を通ったかの3点です。