まず証明書エラーがどの層で発生しているか確認
Clashを有効にした後、ブラウザに「接続はプライベートではありません」「認証局が不明です」「証明書名が一致しません」と表示されたり、TLSハンドシェイクに失敗したりしても、Clashクライアントがウェブサイトの証明書を直接変更したとは限りません。標準的なHTTP CONNECTまたはSOCKS5プロキシは通常、接続先サーバーまでの通信経路を確立するだけで、HTTPSの暗号化と証明書検証は引き続きブラウザと接続先サイトの間で行われます。正常であれば、ブラウザに表示される証明書は接続先サイトと、信頼された認証局によって発行されたものです。
Clash、Clash Meta（mihomo）、およびこれらのコアを使用するクライアントでは、システムプロキシやTUNモードを有効にしただけで、通常のHTTPSアクセス用に汎用ルート証明書をインストールする必要はありません。証明書の発行者が突然、企業ゲートウェイ、セキュリティ検査ソフト、ルーター、または見覚えのない組織に変わった場合は、サブスクリプションを削除したりクライアントを何度も再インストールしたりする前に、上流プロキシと端末側のネットワーク中間層を確認してください。
調査を始める前に、次の3点を記録します。エラーが出るウェブサイト、Clashを無効にするとすぐ復旧するか、同じネットワーク上の別の端末でもエラーが出るかです。特定のサイトだけ失敗する場合は、サイトの証明書、名前解決、ルールによる振り分けの問題が考えられます。多数のサイトで同時に失敗する場合は、システム時刻、証明書ストア、上流プロキシ、ネットワーク検査機器が原因であることが多く、特定のブラウザだけ失敗する場合は、そのブラウザの証明書ストア、拡張機能、セキュリティ設定を確認します。
よくあるエラーと優先して確認する項目
- 証明書の有効期間前または期限切れ：まずシステムの日付、時刻、タイムゾーン、自動時刻調整の状態を確認します。
- 認証局が信頼されていない：証明書チェーンが完全か、企業によるHTTPS検査や端末上のフィルタリングソフトが存在しないかを確認します。
- 証明書名が一致しない：DNSの名前解決、透過型ゲートウェイ、ログイン認証ページ、ルールによる振り分け結果を確認します。
- ハンドシェイク失敗またはプロトコルエラー：プロキシノードの可用性、上流プロキシのパラメーター、TLS Server Name、ネットワークによる遮断、クライアントログを確認します。
- 一部のサブリソースだけ失敗：ブラウザの開発者ツールで実際に失敗しているドメインを確認し、第三者APIの障害をメインサイトの証明書問題と取り違えないようにします。
システム時刻、タイムゾーン、自動時刻調整を確認
TLS証明書には明確な有効開始日時と有効期限があります。端末の時刻が数時間、数日、場合によっては数年ずれていると、ブラウザは有効な証明書を「まだ有効ではない」または「期限切れ」と判断します。ノートパソコンの長期放置、マザーボードの時計異常、仮想マシンの一時停止からの復帰、デュアルブート、手動でのタイムゾーン変更などが原因になることがあります。Clashを有効にした後、これまで接続していなかったサイトへアクセスしたことでエラーが一斉に現れ、Clashが原因だと思い込みやすくなります。
- システムに表示される日付、時刻、現在地のタイムゾーンが正しいか確認します。特にUTCオフセットが現在地と一致しているかを確認してください。
- システムの「時刻を自動的に設定する」と「タイムゾーンを自動的に設定する」を有効にし、手動で一度時刻を同期します。
- ブラウザを完全に終了してから再起動し、古いTLSセッションやエラーページがタブに残らないようにします。
- 自動同期に失敗する場合は、いったんプロキシを無効にして再度同期し、時刻サービスへの通信がルールによって誤って転送されていないか確認します。
Windowsで時刻を確認する
Windowsの設定で「時刻と言語」を開き、自動時刻設定とタイムゾーンを確認します。必要な権限を持つターミナルでは、次のコマンドで同期状態も確認できます。
w32tm /query /status
w32tm /resyncシステムから時刻サービスが実行されていないと表示された場合は、まずサービス管理画面でWindows Timeサービスを確認します。ドメイン環境の端末は組織のタイムサーバーで一元管理されている場合があるため、同期先を不用意に変更しないでください。
macOSとLinuxで時刻を確認する
macOSでは「システム設定—一般—日付と時刻」で自動設定を有効にできます。systemdを使用するLinuxディストリビューションでは、次のコマンドで現在の時刻状態を確認できます。
timedatectl status
sudo timedatectl set-ntp trueコンテナや仮想マシン上のアプリは通常、ホストマシンの時刻を引き継ぎます。仮想マシン内だけでエラーが発生する場合は、ホストとゲストの両方を確認し、スナップショットから復元した後に時刻が再同期されているか確認してください。
ブラウザが認識している証明書チェーンを確認
証明書チェーンは通常、サイト証明書、中間証明書、信頼されたルート証明書で構成されます。ブラウザは、アクセス先ドメインが証明書のサブジェクト代替名に含まれているか、有効期間内か、署名チェーンが端末で信頼されているルート証明書までつながるか、証明書の用途がサーバー認証に適しているかを検証します。調査ではエラーページの見出しだけで判断せず、証明書ビューアーを開いて具体的な項目を記録してください。
まずサイト証明書の「発行先」またはサブジェクト代替名を確認し、現在アクセスしているドメインが含まれているか確認します。次に「発行者」を確認し、Clashを無効にしたときの結果と比較します。両方の状態で証明書のサブジェクト、シリアル情報、発行者が明らかに異なる場合、通信経路内にTLSを終端して再確立できる中間層が存在します。企業ネットワークのコンプライアンス検査、ペアレンタルコントロール、セキュリティソフトのHTTPSスキャン、デバッグプロキシ、サブスクリプションに設定された上流プロキシサービスなどが考えられます。
証明書が常に同じなのに、特定のブラウザだけ信頼されていないと表示される場合は、ブラウザ間で結果を比較します。一部のブラウザは主にシステムの証明書ストアを使用しますが、別の環境では独自の証明書データベースを管理していることがあります。システム更新の未完了、長期間更新されていないルート証明書一覧、ブラウザ設定の破損などにより、同じ証明書でもプログラムごとに判定が異なる場合があります。
コマンドラインでTLSハンドシェイクを確認する
コマンドラインツールを使うと、ブラウザ設定の問題とシステムネットワークの問題を切り分けられます。以下では通常の接続と、端末のHTTPプロキシポートを経由した接続をそれぞれテストします。ポート番号はクライアントの実際の設定に合わせて変更してください。
curl -Iv https://example.com/
curl -Iv --proxy http://127.0.0.1:7890 https://example.com/出力された証明書のサブジェクト、発行者、有効期間、最終エラーを比較します。直接接続が成功して明示的なプロキシ接続だけ失敗する場合は、Clashで選択されたノード、プロキシグループ、上流経路を確認します。両方とも失敗する場合は、システム時刻、証明書ストア、DNS、現在のネットワークに問題がある可能性が高くなります。実際の障害ドメインをテストするときは、アカウント、トークン、クエリパラメーターを含む完全なURLを公開ログに残さないようにしてください。
Clashのプロキシ経路とルールによる振り分けを確認
Clashのルールモードでは、設定ファイルのルール順に従って、リクエストのプロキシグループ、具体的なノード、またはDIRECTを選択します。ブラウザが1つのページにアクセスすると、メインドメイン、静的リソース、ログインAPI、コンテンツ配信ドメインがそれぞれ異なるルールに一致することがあります。メインページはプロキシを経由する一方、認証APIが制限対象またはリダイレクト先へ直接接続されると、証明書エラー、ログインループ、一部リソースのハンドシェイク失敗として現れることがあります。
クライアントの接続履歴とコアのログを開き、エラー発生時刻付近の対象ドメインを探して、一致したルール、出口ポリシー、ノードを確認します。Clash Meta（mihomo）の設定では、パネルからリアルタイム接続を確認できることが多く、グラフィカルクライアントによってメニュー名は「接続」「ログ」「ルール」「プロキシ」など異なります。重要なのはグローバルモードを何度も切り替えることではなく、対象ドメインが実際にどの経路を通っているかを特定することです。
変更する要素を最小限にして切り替える
- ネットワーク環境を変えず、問題のドメインだけ一時的にDIRECTへ切り替えて、ブラウザで再度テストします。
- 直接接続が正常なら、そのドメインを別の動作確認済みノード経由にして、証明書が戻るか確認します。
- すべてのノードで失敗する場合は、サブスクリプションに共通のチェーンプロキシ、外部制御プログラム、追加の上流プロキシが設定されていないか確認します。
- 1つのノードだけ失敗する場合は、そのノードのサーバーアドレス、ポート、通信パラメーター、TLS Server Name、システム時刻を確認します。
- テストが終わったらルールモードに戻し、グローバル設定によって本来のルール順の問題が隠れないようにします。
ノードのプロトコル自体が、プロキシサーバーへの接続にTLSを使用する場合があります。この層の証明書と、ブラウザがウェブサイトへのアクセス時に表示する証明書は別のものです。ノードログの「certificate verify failed」「x509」「hostname mismatch」は通常、クライアントによるプロキシサーバー証明書の検証失敗を示します。一方、ブラウザの証明書警告は、接続先サイトとの通信を指します。この2つの層を区別すれば、ノードサーバーの証明書問題をウェブサイトの証明書問題と取り違えずに済みます。
ノード設定でサーバーアドレスにドメイン名を使用している場合、TLS Server Nameは通常、サーバー証明書の対象名と一致している必要があります。IPアドレスへ勝手に変更したり、別のドメインを入力したり、上流サーバーの証明書が更新されたりすると、ノードのハンドシェイクに失敗することがあります。これらのパラメーターはサービス提供者が公開した有効な設定に従い、ノードの証明書検証を無効にして接続を維持しないでください。
システムプロキシとTUNモードの違い
システムプロキシは主に、OSのプロキシ設定に従うプログラムへ影響します。TUNモードは仮想ネットワークインターフェースを通じて、より広範なIPトラフィックを取り込み、システムプロキシを参照しないアプリにもルーティングやDNS処理を適用します。TUNに切り替えた後、多数のプログラムで同時にエラーが出る場合は、DNS改ざん設定の競合、別のVPNによるルート変更、セキュリティソフトによる仮想インターフェースのフィルタリング、LAN認証通信の取り込みなどが原因として考えられます。
TUNモードは取り込む範囲が広いからといって、HTTPSを自動的に復号するわけではありません。TUNを有効にしたときだけ証明書名が一致しない場合は、いったんTUNを無効にしてシステムプロキシだけを残し、結果を比較します。そのうえでfake-ip、DNSリスナー、ルートの除外項目、他のVPNを確認してください。一度に1つだけ設定を変更すると、ルーティング、名前解決、上流ノードのどれが差異を生んだのか判断しやすくなります。
DNS異常、認証ページ、ネットワーク改ざんを見分ける
証明書名の不一致は、ブラウザが誤ったサーバーへ接続していることを示す場合が多くあります。公衆Wi-Fi、ホテル、学校のネットワークでは、最初にウェブ認証を完了するよう求められることがあります。初回接続時、ゲートウェイは通常のリクエストをログインページへ転送します。HTTPSリクエストまで遮断されると、認証ページは対象ドメインの正しい証明書を提供できず、ブラウザに証明書警告が表示されます。この場合はプロキシを無効にし、OSが提供するネットワーク検知ページまたは通常のHTTPページへアクセスして認証を完了してから、Clashを再び有効にしてください。
DNSが誤ったアドレスを返す場合も、同じような症状が起こります。Clashを無効にした場合と有効にした場合で、名前解決はシステムDNS、クライアントのDNSモジュール、リモートリゾルバー、fake-ipの仕組みなどに分かれることがあります。特定のドメインが一方の状態でだけ失敗するなら、それぞれの名前解決結果を調べ、信頼できるネットワークの結果と比較します。大規模サイトでは地域ごとに異なるアドレスが使われるため、IPが完全に一致しなくても必ずしも異常ではありません。重要なのは、アドレスの所在、証明書のドメイン名、アクセス結果が妥当かどうかです。
nslookup example.com
dig example.com A
dig example.com AAAA家庭用ルーターのセキュリティフィルター、通信事業者ネットワークの不正なリダイレクト、企業の出口にあるTLS検査、本機のデバッグプロキシなどによって接続経路が変わることがあります。最も有効な比較テストは、Clashの設定を変えずに同じ端末を別の信頼できるネットワークへ一時的に接続することです。ネットワークを変えるとすぐ復旧するなら、元のルーターのDNS、アクセス制御、ファームウェア設定、ネットワーク認証状態を確認します。どのネットワークでも失敗するなら、端末の証明書ストア、クライアント設定、セキュリティソフトの確認に戻ります。
端末上のフィルタリングソフトと企業証明書
企業環境によっては、管理されたルート証明書を使ってHTTPS通信を検査します。組織管理の端末では、この証明書が管理者によって一括配布され、ブラウザには組織指定の発行者が表示されます。証明書の期限切れ、配布対象の漏れ、ブラウザが独立した証明書ストアを使用していることなどにより、信頼エラーが発生する場合があります。この場合は証明書の指紋だけでなく、サブジェクト、発行者、有効期間を記録し、ネットワーク管理者に確認してもらってください。組織の証明書を自分で削除しないでください。
個人端末にパケットキャプチャや通信解析のツール、HTTPSスキャン機能を備えたセキュリティソフトをインストールしたことがある場合は、それらがまだ動作していないか確認します。画面を閉じただけでは、バックグラウンドサービスやローカルプロキシが停止していないことがあります。システムのプロキシ設定、プロセス一覧、証明書マネージャーを確認し、ソフトウェアの提供元と用途を確認したうえで、正式なアンインストール手順から関連するネットワークコンポーネントを削除してください。
手順に沿った復旧と結果の確認
証明書のトラブルは、影響が小さく、元に戻しやすい操作から始めます。ネットワーク設定をすべてリセットしたり、証明書を一括削除したりすると、既存環境を壊すうえ重要な手がかりも失われます。以下の順序は、Clashを有効にした後にHTTPSエラーが発生した多くのケースに適しています。
- エラーを記録：ブラウザのエラーコード、問題のドメイン、証明書のサブジェクト、発行者、有効期間、発生時刻を保存します。
- 時刻を調整：日付、タイムゾーン、自動同期の状態を確認し、その後ブラウザを再起動します。
- 設定のオン・オフを比較：Clashを無効にした状態、システムプロキシのみ、TUNのみ、元のモードをそれぞれテストし、毎回の結果を記録します。
- 接続ログを確認：対象ドメインに適用されたルール、プロキシグループ、ノード、DNSの名前解決経路を確認します。
- 出口を1つだけ変更：他の設定を変えずにノードを切り替え、障害がノードに追随するか確認します。
- 信頼できるネットワークに変更：ルーター、公衆ネットワークの認証、出口側の検査機器による影響を切り分けます。
- 中間プログラムを確認：他のVPN、ローカルデバッグプロキシ、セキュリティフィルター、企業の管理ポリシーを確認します。
- 設定を復元：最近DNS、TUN、ルールを変更した場合は、変更前に保存した設定へ項目ごとに戻します。
サイトまたはサービス提供者へ問い合わせるべきケース
同じサイトが複数の端末、複数のネットワーク、直接接続、プロキシ経由のいずれでも同じ期限切れ証明書や不完全な証明書チェーンを表示する場合、問題はサイト側にある可能性があります。サイトのメンテナンスを待つか、管理者へ問い合わせてください。特定のプロキシノードでだけエラーが発生し、ノードログにサーバー証明書の名前または有効期間の異常が明確に示される場合は、発生時刻、ノード名、ログの概要をノード設定の提供元へ伝えます。
問い合わせ時に、サブスクリプションの完全なURL、認証キー、アカウント情報を送る必要はありません。クライアントのコアバージョン、OS、接続モード、エラー発生時刻、対象ドメイン、適用されたルール、必要な情報だけを残したログを提供してください。「ノードのTLSハンドシェイク失敗」と「ブラウザでサイトへアクセスした際の証明書警告」を明確に区別すると、原因の特定を大幅に早められます。
復旧後も確認しておきたい設定
障害が解消しても、すぐに一時的な現象だと決めつけないでください。元のルールモードに戻し、普段使うサイト、ソフトウェア更新、ログインAPI、システムプロキシに従わないアプリをそれぞれテストします。TUNやDNSモジュールを一時的に無効にしていた場合は、項目ごとに元へ戻しながらログを確認します。カスタムルールによって認証ドメインとメインサイトが異なる出口を通っている場合は、関連ドメインを同じポリシーグループにまとめ、サブスクリプション更新後に再確認できるようルール順の説明を残します。
企業ネットワーク、家庭のネットワーク、公衆Wi-Fiを頻繁に切り替える端末では、比較用の基本設定を1つ用意しておくと便利です。安定したサブスクリプション、明確なDNS設定、少数のカスタムルールを使用します。問題が発生したら、まず基本設定で再現するか確認し、その後TUN、スクリプト、カスタムルールを段階的に追加します。この最小構成によるテストは、クライアントを何度も再インストールするより、実際の障害層を特定しやすい方法です。