プロキシ接続時のHTTPS証明書エラー｜主な原因と確認手順

1. まず切り分ける：Webサイトの証明書エラーか、ノードのTLS接続エラーか

certificateと表示されていても、エラーが起きた場所によって対処すべき対象は異なります。ブラウザーが検証するのは接続先Webサイトの証明書です。一方、TLSを使うプロキシプロトコルでは、コアがノードサーバーの証明書を検証することもあります。この2つを混同しないでください。

ログのTLSエラーはノードではなく、サブスクリプションの取得先、速度測定先、暗号化DNSサービスに起因する場合もあります。接続先のホスト名、発生時刻、操作内容を記録し、x509の1行だけを切り取らないでください。ブラウザーにERR_PROXY_CONNECTION_FAILEDが表示された場合は、証明書を変更するのではなく、まずローカルの待ち受けポートとクライアントの動作状況を確認します。

2. まずシステム時刻と証明書の有効期間を確認

時刻がずれていると、多くの正常なWebサイトでも同時にエラーが発生します。パソコンを長期間起動していなかった場合、仮想マシンをスナップショットから復元した場合、マザーボードの電池に問題がある場合は、優先して確認してください。タスクバーの時刻だけでなく、年・月・日とタイムゾーンも確認します。

1. Windows 11：「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」をオンにして、タイムゾーンを確認したら「今すぐ同期」をクリックします。
2. macOS：「システム設定」→「一般」→「日付と時刻」を開き、「日付と時刻を自動的に設定」とタイムゾーンの自動設定を確認します。
3. Android：標準的なAndroidでは通常、「設定」→「システム」→「日付と時刻」にあります。メーカーによっては「その他の設定」などに配置されています。日付と時刻、タイムゾーンの自動設定を確認してください。
4. ブラウザーのエラーページにある「詳細設定」や証明書の表示機能から有効期間を確認します。画面の項目名はブラウザーのバージョンによって異なります。「有効期間の開始」と「有効期間の終了」を記録してください。

端末の時刻が正しく、ほかのWebサイトも正常なのに1つのサイトだけ期限切れと表示される場合は、サイトの管理者による証明書の更新が必要な可能性が高いでしょう。ノードを切り替えても期限切れの証明書は有効になりません。複数のサイトで同じ時刻にエラーが発生した場合は、サブスクリプションを何度も更新するより、まずシステム時刻や共通の通信検査ソフトを確認してください。

3. テスト条件をそろえて、直接接続とプロキシ経由を比較

毎回同じ完全なHTTPS URLを使い、変更する条件は1つだけにしてください。ノードの切り替え、DNSの変更、TUNの有効化を同時に行うと、どの操作で状況が変わったのか判断できません。最初にルールモード、選択中のノード、システムプロキシとTUNの状態を記録します。

次の4ステップで比較する

1. ClashクライアントのシステムプロキシとTUNを無効にします。ほかのVPNやブラウザーのプロキシ拡張機能が通信を処理していないことを確認してから、対象サイトにアクセスします。
2. システムプロキシだけを有効にし、TUNは無効のまま、同じノードで再試行します。クライアントの「接続」画面で、対象ドメインがノード経由かDIRECTかを確認します。
3. ほかの設定は変更せず、正常に使えることが分かっている別のノードに切り替えて、同じURLにアクセスします。
4. 同じクライアント設定のままスマートフォンのテザリングに切り替えて再テストします。主に現在のLAN環境と端末自体の問題を切り分けるための手順です。

直接接続ではもともとアクセスできない場合、接続失敗を証明書レベルの比較に使うことはできません。タイムアウトと証明書エラーを同じ結果として扱わないでください。通常のシークレットウィンドウも、証明書環境が初期化された状態ではありません。システムのルート証明書を引き続き使うため、企業向けセキュリティソフトの影響を除外できません。

コマンドでTLSハンドシェイク情報を確認

以下はWindows PowerShellの例です。7890はサンプルのポート番号です。実行前に、クライアントで現在使用しているHTTPポートまたは混合ポートに置き換えてください。SOCKS専用ポートには使用できません。2つ目のテストでは、クライアントがそのポートで待ち受けている必要があります。また、環境変数NO_PROXYによってテスト対象のドメインがプロキシを迂回しないことを確認してください。

curl.exe -I -v --noproxy "*" https://example.com/
curl.exe -I -v --proxy http://127.0.0.1:7890 https://example.com/

証明書の検証をスキップするオプションは使っていません。1つ目のコマンドで回避するのはアプリケーション層のプロキシだけです。TUNが動作中なら引き続き通信が処理される可能性があるため、直接接続を比較する前にTUNを無効にしてください。curlのビルドによって使用する信頼ストアは異なります。ブラウザーで表示される証明書の詳細と合わせて確認し、コマンドが1回成功しただけでブラウザーの信頼ストアの問題を除外しないでください。

4. Fake-IPとDNS：ドメインが誤ったサーバーに接続していないか確認

Fake-IP自体がWebサイトの証明書を置き換えることはありません。mihomoのFake-IPモードでは、DNSが合成アドレスを返し、コアがドメイン名とアドレスの対応を保存して、接続時にルーティングします。設定で198.18.0.1/16を使っている場合、この範囲のアドレスが返るのは想定どおりの可能性があります。これはインターネット上のサーバーの実アドレスではありませんが、それだけでDNS汚染とは判断できません。

DNSの改ざん、誤ったサービスへのルーティング、古い接続情報とマッピングの不整合などにより、ブラウザーが対象ドメインとは異なる証明書を受け取ることがあります。一方、誤ったマッピングではタイムアウトだけが発生し、証明書の警告が出ない場合もあります。証明書のドメイン名と実際の接続記録を照らし合わせて判断してください。

まず状況を確認し、それから名前解決の設定を変更

• Windows PowerShellでResolve-DnsName example.comを実行し、返されたアドレスを確認します。example.comは、実際にエラーが発生しているドメイン名に置き換えてください。
• クライアントの「接続」画面またはログを開き、ドメイン名、適用されたルール、出力先ノードを確認します。システムのコマンドで調べたDNSが、ブラウザーの使用するDNSと同じとは限りません。
• Chromeの「設定」→「プライバシーとセキュリティ」→「セキュリティ」で、「セキュアDNSを使用する」を確認できます。比較テストのために一時変更する場合は、元の設定を記録してください。DoHの通信もTUNを経由する場合があります。
• DNSモードを切り替えたばかりの場合は、関連するWebページとブラウザーの接続をいったん閉じ、必要に応じてクライアントを再起動します。Windowsではipconfig /flushdnsを実行して、システムのDNSキャッシュを消去できます。ただし、ブラウザーのキャッシュやコア内のマッピングがすべて消去されるわけではありません。

以下はmihomoのDNS設定例で、各項目を見分けるためのものです。証明書エラーを解決するための完全な設定ではありません。DNSの上流サーバー、ルーティング、クライアント側の上書き設定は、現在の環境に合わせてください。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

特定のアプリがFake-IPに対応していないことを確認できた場合は、原因を特定したうえでfake-ip-filterの利用を検討してください。すべてのドメインを除外するのは避けましょう。サブスクリプションで管理されている設定は、次回の更新で元に戻らないよう、クライアントが対応する上書き機能を使って変更してください。設定方法は詳細設定もご覧ください。

5. 中間者による通信解析、企業のHTTPS検査、公共Wi-Fi

関連のない複数のWebサイトで、同じローカル組織やセキュリティ製品が証明書の発行者として表示される場合は、HTTPS検査機能を確認してください。Fiddler、Charles、mitmproxyなどのデバッグツールは、ルート証明書をインストールして信頼させるとHTTPSを復号できます。企業のゲートウェイやエンドポイントセキュリティソフトにも同様の機能があります。これは、Clashクライアントが通常の方法でHTTPSを中継することとは異なります。

証明書の発行元を確認する

1. エラーページまたは証明書ビューアーで、サブジェクト代替名（SAN）、発行者、有効期間、証明書チェーンを記録します。SANには、アドレスバーに表示されているドメイン名が含まれている必要があります。
2. 通信解析ツールを終了し、システムプロキシが引き続きツールの待ち受けポートを指していないか確認してください。ウィンドウを閉じただけでは、システムプロキシの設定が元に戻らないことがあります。
3. Windowsではcertmgr.mscで現在のユーザーの証明書を確認できます。certlm.mscではローカルコンピューターの証明書を確認できますが、適切な権限が必要な場合があります。macOSでは「キーチェーンアクセス」で証明書と信頼設定を確認できます。
4. 個人所有の端末では、入手元を確認できたデバッグ用証明書だけを削除してください。組織の管理下にある端末では、企業のルート証明書をまとめて削除せず、まず管理者に相談してください。

ブラウザーとコマンドラインツールでは、証明書の信頼元が異なる場合があります。そのため、ブラウザーでは正常でもcurlでエラーが出たり、その逆が起きたりします。ルート証明書を追加する前に、そのHTTPS検査が端末管理ポリシーの一部か、証明書の入手元を信頼できるかを確認してください。

6. 特定のノードだけでエラーが起きる場合：SNIと証明書チェーンを確認

端末、Webサイト、DNS設定が同じなのに、特定のノードに切り替えたときだけエラーが発生する場合は、そのノードの使用をいったん中止してください。クライアントがノードに接続できないのか、ノードへの接続後にブラウザーが異常なWebサイト証明書を受信しているのかを切り分けます。

クライアントログにノードのTLSエラーが出る

TLSを使うノードでは、接続先アドレスと証明書検証に使う名前が異なる場合があります。mihomoではプロトコルによって設定項目も異なります。たとえばVMessやVLESSではservername、Trojanではsniが使われることがあります。各プロトコルのドキュメントとサービス提供元の案内に従って確認し、すべてのノードに同じ項目名を当てはめないでください。

• 接続先アドレスにIPアドレスを指定している場合、証明書のSANにそのIPアドレスが含まれていないことがあります。正しいサーバー名と接続パラメーターは、サービス提供元に確認してください。
• ログに証明書の期限切れやチェーンの不完全が記録されている場合は、ノードの管理者が証明書を更新し、中間証明書を補う必要があります。ユーザー側でルールを変更しても、サーバーの証明書は修復できません。
• skip-cert-verifyが影響するのは該当ノードへの接続検証だけで、対象Webサイトの証明書に対するブラウザーの検証は修復できません。エラーを隠すためにtrueへ変更しないでください。

ブラウザーが異常なWebサイト証明書を受信する

通常のプロキシ中継ノードは対象Webサイトの秘密鍵を持たないため、ブラウザーが信頼する証明書を勝手に発行することはできません。異常な証明書が返される原因には、DNSの誤り、出口ネットワークの認証や通信検査、接続先の設定ミスのほか、悪意ある干渉も考えられます。1回のエラーだけで干渉と断定はできませんが、その経路では機密情報を扱う操作をいったん控えてください。

そのノードで表示された証明書情報を記録し、別の信頼できるネットワークまたはノードでも比較してください。CDNの出口によって異なる証明書や認証局が正当に使われることがあるため、発行者が異なるだけで干渉とは判断できません。ドメイン名が含まれているか、有効期間内か、証明書チェーンが信頼できるか、再テストでも同じ結果になるかが重要です。

7. 結果に応じて対応する：修復、再テスト、問い合わせ情報の整理

対処を1つ行ったら、最初にエラーが出た完全なURLで再テストし、別の独立したWebサイトでも確認してください。ページが開けることは最初の確認にすぎません。ルールモード、システムプロキシ、TUNが想定どおりの状態に戻っており、テストのために有効化したグローバルルーティングや一時的なDNS設定が残っていないことも確認します。

問い合わせには次の情報を添える

• OSのバージョン、Clashクライアントの名称とバージョン、mihomoコアのバージョン。「最新版」とだけ書かないでください。
• エラーコード全文、発生時刻、エラーがブラウザーとクライアントログのどちらに表示されたか。
• 対象ドメイン、証明書のSAN、発行者、有効期間。URLのクエリパラメーターに含まれる個人情報は伏せてください。
• システムプロキシとTUNの状態、実際の待ち受けポート、ルールモード、直接接続・ノードA・ノードBの比較結果。
• 問題に関連する最小限のログ。サブスクリプションURL、アクセストークン、ノードのパスワード、外部コントローラーのシークレットは事前に削除してください。

確認の順序はエラーが起きた場所 → システム時刻 → 接続経路の比較 → DNSと証明書の発行元 → ノードの設定にするとよいでしょう。各手順で根拠を確認できるため、最初からクライアントを再インストールしたり、YAMLを大幅に変更したりする必要はありません。基本的な設定のインポートとプロキシ設定は使い方ガイドをご覧ください。よくある接続トラブルはヘルプセンターで確認できます。