Clashを有効にするとウェブサイトでHTTPS証明書エラーが表示される原因と対処法

まず、証明書エラーが本当にClashによるものか確認する

HTTPS証明書エラーは、Clashクライアントの破損を意味するわけではありません。ブラウザはHTTPSサイトにアクセスすると、証明書のドメイン名、有効期限、発行者、証明書チェーンを確認します。Clashは通常、暗号化された通信を転送するだけで、確立済みのTLSセッションの内容を読み取ることはできません。接続先、システム時刻、証明書チェーンが正常であれば、ルールプロキシやTUNモードを有効にしただけで、サイト証明書を追加インストールする必要はありません。

問題は、転送経路が変わった後に起きることが多くあります。プロキシノードが接続を誤ったサーバーへ転送した、DNSが異常なアドレスを返した、LAN内のHTTPプロキシが通信の復号を試みた、あるいは端末の時刻ずれによって有効期限の判定を誤った、といったケースです。Clashを有効にした直後にこれらが表面化するため、時間的には関連して見えますが、切り分けではクライアント、設定、ノード、アクセス先サイトを分けて確認しましょう。

まずはオン・オフで比較する

1. エラーが出たサイトの完全なドメイン名、たとえば accounts.example.com を記録します。トップページの名前だけでは不十分です。
2. 警告画面に表示されたエラーコード、証明書の発行者、有効期限を控えます。Safariでは「この接続はプライベートではありません」と表示されることがあり、Chromium系ブラウザでは NET::ERR_CERT_DATE_INVALID、NET::ERR_CERT_COMMON_NAME_INVALID、NET::ERR_CERT_AUTHORITY_INVALID などがよく見られます。
3. ClashのシステムプロキシまたはVPN接続を無効にし、ブラウザを完全に終了してから再起動し、同じHTTPSアドレスにアクセスします。
4. Clashを再び有効にし、そのドメインを一時的に DIRECT に設定します。直接接続では正常で、プロキシグループでエラーになる場合は、現在のノードと上流経路を重点的に確認します。
5. Wi-Fiとモバイル通信をそれぞれ使ってテストします。特定のWi-Fiだけでエラーが出る場合は、ルーター、公衆ネットワークの認証ページ、手動プロキシを優先して確認します。

ノードが乗っ取られている、または上流から誤った証明書が返される

ルールによってドメインがプロキシノードに渡されると、ノードが端末の代わりに対象サーバーへ接続します。ノードの出口が透過プロキシ、悪意のあるゲートウェイ、異常な上流経路に乗っ取られると、ブラウザが受け取る証明書が別のドメインのものになったり、端末が信頼していない機関によって発行されたものになったりします。この問題は通常、特定のノードまたは特定の経路でだけ発生します。

典型的な症状

• 同じサイトが DIRECT では正常なのに、特定のプロキシノードへ切り替えるとドメイン不一致になる。
• 証明書の「発行先」欄がアドレスバーのドメインとまったく関係ない。たとえばアカウント用ドメインにアクセスしたのに、ルーターの管理画面や見覚えのないドメインの証明書が返される。
• 同じサブスクリプション内の別地域のノードへ切り替えると復旧し、元のノードでは再テストしてもエラーが続く。
• HTTPサイトが広告ページ、認証ページ、見覚えのない検索ページへリダイレクトされ、同時にHTTPSサイトでも証明書異常が発生する。

Clashのグローバルモードは、すべての該当通信を現在のプロキシグループへ送るため、ノード比較に適しています。テスト後は元のルールモードに戻してください。特定のノードだけが異常なら、サブスクリプション全体を削除する必要はありません。まずプロキシグループからそのノードを外し、サブスクリプションを更新して提供元が経路を調整したか確認します。

証明書の3項目を確認する

1. Subject Alternative Name：アクセス中の完全なドメイン名が含まれている必要があります。ワイルドカード *.example.com は通常、1階層下のサブドメインまでしかカバーしません。
2. Issuer：発行者が一貫しているか確認します。テスト前後で公開CAから企業ゲートウェイ、ルーター機器、見覚えのない名称へ突然変わった場合は注意が必要です。
3. Validity：現在時刻が「有効期間の開始」と「有効期間の終了」の間にあることを確認します。証明書の期限切れは、サイト側のメンテナンスが原因の場合もあります。

macOSでは、標準搭載のコマンドでリモートサーバーとのハンドシェイク結果を確認できます。以下の example.com は実際にエラーが出たドメインに置き換えてください。ポート 443 は標準のHTTPSポートです。

openssl s_client -connect example.com:443 -servername example.com -showcerts
curl -Iv https://example.com/

-servername はSNIを送信するオプションです。これがないと、同じサーバーからデフォルト証明書が返され、誤判定につながることがあります。コマンド出力の証明書情報は直接接続とプロキシ接続の比較に使えますが、「ハンドシェイク成功」と表示されたからといって、サイトの内容まで安全だとは限りません。ドメイン名と発行チェーンを必ず確認してください。

システム時刻のずれで証明書の有効期限判定に失敗する

証明書には明確な有効期間の開始日時と終了日時があります。iPhoneの時計が数日遅れていると、新しい証明書を「まだ有効ではない」と判定することがあります。逆に数か月進んでいると、正常な証明書を「期限切れ」と判定する可能性があります。この種の障害では、1つのサイトだけでなく、複数のHTTPSサービス、アプリへのログイン、システムアカウントが同時に使えなくなることがあります。

iPhoneとiPadでの確認手順

「設定」→「一般」→「日付と時刻」を開き、「自動設定」を有効にします。続いて、タイムゾーンが現在地と一致しているか確認してください。スイッチがグレー表示の場合は、スクリーンタイムの制限、キャリア設定、端末管理ポリシーが原因の可能性があります。該当する制限を先に確認しましょう。

• 時刻のずれが5分を超えると、一部のログイン用トークンやワンタイムコードも同時に無効になることがあります。
• 時刻を修正したら、Safariで問題のタブを閉じて開き直し、古い接続を再利用しないようにします。
• 端末を長期間電源オフにしていた場合は、まず安定したネットワークに接続し、システムがネットワーク経由の時刻調整を完了するまで待ちます。
• 管理対象の会社端末では管理者に連絡し、組織から配布された管理プロファイルを自分で削除しないでください。

証明書エラーに表示される日付にも注意してください。ブラウザでは証明書が期限切れと表示される一方、システム日時が正確で、直接接続、別ノード、別ネットワークでも同じ結果になるなら、問題はサイト側にある可能性が高くなります。この場合、Clashの設定を切り替えても解決できず、サイト運営者が証明書を更新するのを待つ必要があります。

DNS汚染によってドメインが誤ったサーバーへ送られる

HTTPS接続を開始する前に、端末はドメイン名をIPアドレスへ解決する必要があります。DNSが誤ったアドレスを返すと、TLSリクエストが別のサーバーへ到達し、そのサーバーからドメイン不一致の証明書が返されることがあります。この場合、ブラウザには単なる接続タイムアウトではなく、証明書が現在のドメインに対応していないという警告が表示されることがよくあります。

Clashまたはmihomoの設定では、DNSの動作が nameserver、fallback、nameserver-policy、Fake-IPマッピング、さらにルール内の DOMAIN、DOMAIN-SUFFIX から影響を受けることがあります。TUNモードではシステムのDNSリクエストを引き受ける場合もあります。切り分けでは、すべての項目を一度に変更しないでください。どの設定が影響したのか分からなくなります。

変更する項目を絞ってDNSを確認する

1. まずサブスクリプションと設定を更新し、YAMLが正常に読み込まれ、インデントやフィールドに誤りがないことを確認します。
2. エラーが出るドメインを一時的に直接接続ルールへ追加し、そのルールが MATCH より前にあることを確認します。
3. クライアントのDNSキャッシュを消去します。クライアントに専用の操作項目がない場合は、システムVPNを約10秒切断してから再接続します。
4. 機内モードをいったんオンにしてからオフにし、モバイルネットワークとDNSの状態を再取得します。
5. 別のWi-Fiまたはモバイルネットワークに切り替えて再テストし、ローカルルーターのDNSとClash内蔵DNSのどちらに原因があるかを切り分けます。

一時ルールは次のように記述できます。ルールは上から順に評価されるため、具体的なドメインは広範囲のルールより前に置きます。

rules:
  - DOMAIN,accounts.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,PROXY

直接接続ルールでもClashのDNSモジュールを使っている場合、テスト結果から分かるのは出口方式が変わったことだけで、DNSを完全には切り分けられません。より厳密に比較するには、システムDNSと設定上のDNSを同時に比較します。変更前に元の設定を保存し、テスト後は必ず戻してください。一時ルールを長期間残すと、既存の振り分けに影響します。

Fake-IPは証明書の偽造ではない

Fake-IPモードでは、端末上のアプリに予約アドレスを返し、カーネルがドメインとのマッピングに基づいて接続を転送します。アプリからは 198.18.0.0/15 の範囲に似たアドレスが見えることがありますが、TLSハンドシェイクは元のドメイン名を使って行われる必要があります。Fake-IPアドレスが表示されただけで、証明書が置き換えられたことにはなりません。実際に確認すべきなのは、ドメインマッピングの欠落、DNSリクエストのカーネル回避、または対象アプリがFake-IPに対応しておらず誤った宛先へアクセスしていないかどうかです。

LAN内の端末、ゲーム機、一部の非対応アプリだけで問題が起きる場合は、DNS全体を無効にするのではなく、ドメイン単位でFake-IPフィルターを設定できます。具体的な項目はClash Metaまたはmihomoの設定バージョンによって異なるため、編集後は設定の検証に成功したことを確認してからTUNを起動してください。

HTTPプロキシ、パケットキャプチャツール、証明書インストールの影響

通常のClashによるHTTPS転送では、接続経路を確立するだけで、サイト証明書を発行する必要はありません。パケットキャプチャ、デバッグ、ペアレンタルコントロール、企業ゲートウェイ、コンテンツフィルタリングなどのツールがTLSを復号する場合に限り、端末にはローカルCAまたはゲートウェイCAが再発行した証明書が表示されます。このCAがシステムから信頼されていないと、復号対象になったすべてのサイトで「発行元が信頼されていない」という警告が出る可能性があります。

Wi-Fiの手動プロキシを確認する

iPhoneで「設定」→「Wi-Fi」→接続中のネットワーク右側にある情報ボタン→「プロキシを構成」を開きます。ClashのシステムVPNまたはネットワーク拡張機能を使う場合、LAN内のプロキシへ接続する明確な理由がない限り、通常は「オフ」にします。

ローカルHTTPまたはmixedのリスニングポートには 7890、SOCKSポートには 7891 がよく使われますが、設定によって変更できます。Wi-Fiプロキシが 192.168.1.20:8080 のような見覚えのないLANアドレスを指している場合は、まず設定を記録してからプロキシを無効にして再テストします。ある端末の 127.0.0.1 を別のコンピューターだと思わないでください。ループバックアドレスは常に現在の端末自身を指します。

構成プロファイルと証明書の信頼設定を確認する

1. 「設定」→「一般」→「VPNとデバイス管理」を開き、見覚えのない構成プロファイルがないか確認します。
2. 「設定」→「一般」→「情報」→「証明書信頼設定」を開き、完全に信頼する設定になっているルート証明書を確認します。
3. 警告を消すためにウェブページから一時的に提供されたCAをインストールしたり、見覚えのないルート証明書の完全な信頼を有効にしたりしないでください。
4. 会社や学校が管理する端末では、検査用証明書が正当に配布されている場合があります。名称、用途、有効期限をネットワーク管理者に確認してください。

Clashの設定だけを削除しても、他のツールがインストールした構成プロファイルやルート証明書まで削除されるとは限りません。逆に、企業の証明書をむやみに削除すると、社内Wi-Fi、内部サイト、メールが使えなくなる可能性があります。証明書を処理する前に出所を確認し、パケットキャプチャツールを停止するのか、手動プロキシを無効にするのか、管理者に証明書を再配布してもらうのかを判断してください。

Clashの設定とルールを重点的に確認する

証明書エラーは、ルールによって誤った出口が選ばれた場合にも発生します。たとえば、本来は直接接続すべきドメインが広すぎる DOMAIN-SUFFIX ルールによって不安定なノードへ送られている、またはサブスクリプションで使われているポリシーグループ名が変わり、最終的な MATCH ポリシーに落ちているケースです。この場合は現在のモード名だけで判断せず、実際に適用されたルールの記録を確認します。

モードとポリシーグループを確認する

• ルールモード：ルールに基づいて直接接続、プロキシ、拒否を決めます。特定ドメインにどのルールが適用されたかを確認するのに適しています。
• グローバルモード：現在選択中のグローバルノードを一律に使用します。ノード比較に便利ですが、テスト後は元に戻してください。
• 直接接続モード：プロキシノードを経由しません。異常がプロキシチェーンに伴って発生するかを確認できます。

クライアントの接続ログを開き、エラーが出たドメインとそのサブドメインを探します。現在のウェブサイトでは、ログイン用ドメイン、静的リソース用ドメイン、API用ドメインへ同時にアクセスすることがあります。メインページが直接接続でも、すべてのリクエストが直接接続とは限りません。適用されたルールの種類、ポリシーグループ名、最終的なノードを重点的に確認してください。

ポートとプロキシチェーンの混在を避ける

デスクトップのパケットキャプチャツール、ブラウザのプロキ拡張機能、Clashを同時に動かすと、多重プロキシになることがあります。たとえば、ブラウザ拡張機能が 127.0.0.1:8080 を指し、キャプチャツールがさらにClashの 127.0.0.1:7890 へ転送するケースです。いずれかの層でHTTPS復号が有効になると、証明書が変わる可能性があります。

切り分け中は経路を1つだけにします。ブラウザのプロキシ拡張機能を無効にし、パケットキャプチャツールを停止してから、システムプロキシまたはTUNからClashへ直接渡します。元に戻すときも、コンポーネントを一度に1つだけ有効にし、毎回同じドメインでテストしてください。これにより、どの層で証明書が置き換えられたのかを特定できます。

低リスクから高リスクへ進める対処手順

1. エラー情報を保存：ドメイン、時刻、エラーコード、証明書の発行者、現在のノードを記録します。
2. 機密情報の入力を停止：原因が明確になるまで、アカウントにログインしたり決済情報を送信したりしません。
3. システム時刻を調整：「設定」→「一般」→「日付と時刻」で自動設定を有効にします。
4. Clashを無効にして比較：ブラウザを終了してから再テストし、古い接続の再利用を除外します。
5. 直接接続とノードを切り替え：エラーが特定のプロキシ出口だけで起きるか確認します。
6. ネットワークを変更：Wi-Fiとモバイル通信を比較し、ルーターや公衆ネットワークの認証による干渉を見分けます。
7. 適用ルールを確認：ドメインが実際に使用しているポリシーグループとノードを確認します。
8. DNSを確認：キャッシュを消去し、Fake-IP、nameserver、ドメインポリシーを確認します。
9. 手動プロキシを確認：Wi-Fiの「プロキシを構成」とブラウザのプロキシ拡張機能を確認します。
10. ルート証明書を確認：構成プロファイルと完全に信頼された証明書の出所を確認します。

エラーが1つのノードだけで発生し、証明書のドメインも明らかに一致しない場合は、そのノードの利用を停止し、発生時刻、対象ドメイン、証明書の発行者をサブスクリプションサービスの提供元へ報告してください。すべてのネットワーク、すべての端末で同じサイトに同一の期限切れ証明書が表示されるなら、通常はサイト運営者の修正を待つべき状況です。

見覚えのないプロキシを削除したり、異常なノードを無効にしたりしても、多くのHTTPSサイトでエラーが続く場合は、重要なデータをバックアップしてからネットワーク設定のリセットを検討します。iPhoneでは「設定」→「一般」→「転送またはiPhoneをリセット」→「リセット」→「ネットワーク設定をリセット」の順に進みます。保存済みのWi-Fiネットワーク、VPN、一部のネットワーク設定が消去されるため、通常の確認を終えた後に行い、最初の手段にはしないでください。

よくある質問