WindowsでClash購読更新失敗：TLS・DNSログ診断

1. 典型症状：ブラウザは成功・クライアントだけ失敗

症状の骨格は次のとおりです。Edge や Chrome で購読 URL を開くと YAML や Base64 の本文が返る一方で、GUI の「更新」ボタンやコアの自動更新だけが失敗する。このとき多いのは「ブラウザとコアが同じ DNS 解決器を使っていない」「ブラウザだけ DoH（DNS over HTTPS） 経由で名前解決している」「コア側は システムのプロキシ設定の影響を強く受けている」といったズレです。Clash / mihomo は購読取得のために HTTPS クライアントとして外向きコネクションを張りますが、その経路が意図せずローカルの mixed-port に向いてしまうと、更新処理が自分自身を経由してタイムアウトする、というパターンもあります。

したがって最初にやるべきは「感情で設定をいじる」ことではなく、一度ログを取り、失敗が DNS なのか TCP なのか TLS なのか HTTP なのかを分類することです。以降の節では、その分類に沿って具体的な確認と修正を並べます。購読 URL の取り込み手順そのものは、当サイトのサブスクリプション導入ガイドと併せて読むと、GUI 側の用語とコア側の挙動を対応づけやすくなります。

2. まずログを出す（レベルと見る場所）

mihomo / Clash Meta 系では、ログレベルを debug に上げると、購読ホストへの接続試行やルール適用の手前が追いやすくなります。GUI（例：Clash Verge Rev）ではログビューアにフィルタを掛け、購読ドメインや https:// で始まる URL の断片で絞り込みます。コンソールだけで動かしている場合は、標準出力に同様の行が流れます。ここで探したいのは、名前解決に失敗した行、TLS や certificate を含む行、timeout や i/o timeout、HTTP ステータス（403 など）のいずれが主役か、という分類です。

併せて、Windows の「設定 → ネットワークとインターネット → プロキシ」で、手動プロキシがオンになっていないか確認します。オンになっており、サーバが 127.0.0.1 と いま動かしている Clash の mixed-port を指している場合、コアの外向き通信までプロキシに吸い上げられる実装・構成があり得ます。これは後述の「ループ」節で扱います。初回セットアップの全体像は Windows 11 での Verge Rev 導入稿とも補完関係にあります。

# config.yaml fragment — increase log detail while troubleshooting (revert after)
log-level: debug

3. DNS 解決の切り分け

ログに lookup 失敗、no such host、NXDOMAIN、一時的な server misbehaving などが出る場合は、まず DNS です。ブラウザが DoH 経由で解決に成功していても、コアが使うリゾルバは OS のスタブリゾルバ経由であることが多く、社内 DNS や ISP のフィルタ、IPv6 優先の罠でコアだけ NXDOMAINになることがあります。切り分けとしては、管理者権限の PowerShell や nslookup 購読ホスト名 で、同じマシンから権威に近い応答が返るかを見ます。

Clash 側では dns セクションの enhanced-mode（redir-host / fake-ip）が有効なプロファイルでは、アプリケーションが見る IP と実サーバの証明書の SAN が一致しないことでブラウザ挙動とズレるケースがあります。購読取得は「HTTPS クライアントとしてドメインに接続する」処理なので、fake-ip と購読ホストの組み合わせで奇妙な失敗が出ていないかもログで確認します。DNS と fake-ip の思想自体は、例えば DeepSeek 向けの分流稿でも触れている通り、名前解決とルールの両方を一貫させるのが安定運用の鍵です。いったん購読だけが落ちているなら、購読用ドメインを nameserver-policy や適切な nameserver へ寄せる、あるいはテスト中だけ enhanced-mode を弱める、といった切り分けが有効です。恒久対策にする前に、必ず意図と副作用を理解したうえで戻してください。

4. TLS ハンドシェイクと証明書まわり

ログに tls: handshake、certificate、x509、unknown authority、host name mismatch などが出る場合は TLS です。典型原因は次の三つです。（1）企業プロキシやセキュリティ製品が HTTPS を中間者検査しており、ルート証明書が OS トラストストアに入っているブラウザとは別に、Go 製バイナリが参照するストアと一致していない。（2）購読サーバが期限切れ・誤設定の証明書を返している。（3）SNI や HTTP Host が期待と異なる経路に流れ、別ホストの証明書を見ている。

対処の優先度は、まず同じ PC から curl -v https://購読URL を実行し、証明書チェーンが緑かどうかを見ることです。curl でも失敗するなら Clash 以前の問題です。curl は成功するのにコアだけ失敗するなら、コアが別のプロキシ経路を踏んでいるか、古いルート証明書を同梱したビルドを使っている可能性を疑います。セキュリティ製品の HTTPS スキャンを一時停止して再試行し、成功するなら例外リストに購読ドメインを入れるか、製品の「アプリ別の検査」設定を見直します。

設定で skip-cert-verify: true を購読プロバイダに付ける回避がコミュニティに散見されますが、中間者攻撃のリスクを飲み込むことになるため、根本原因の特定とセットでしか推奨しません。可能なら、正しいルートを OS に導入する・セキュリティ製品側で Go 製アプリも検査対象に含める・購読 URL を HTTPS で正しく配っているプロバイダに寄せるのが筋です。

5. mixed-port・システムプロキシと「ループ」

mixed-port は、HTTP と SOCKS を同居させるローカル・リスナーとしてよく使われます。LAN から同じポートを共有する話は LAN 共有の記事で整理している通りです。購読更新そのものは、実装によってはシステムのプロキシ環境変数や WinHTTP の設定を参照することがあります。ここで システムプロキシが 127.0.0.1:mixed-port を指していると、コアが購読 URL へ行こうとしても、再度自分の mixed リスナーに戻ってくる形になり得ます。ログではタイムアウトや接続の多重化が続き、原因が見えにくいです。

切り分けとしては、一時的に Windows の手動プロキシをオフにしてから購読更新を試す、GUI で 「システムプロキシをオフのまま更新だけ実行できるか」を試す、別プロファイルで最小構成（購読と DIRECT のみ）を用意して再現するか、の順が安全です。常時運用では、システムプロキシをオンにするタイミングと購読更新のタイミングを分ける、あるいは更新処理がシステムプロキシを参照しないようクライアント側のオプションを確認する、といった運用・設定の組み合わせが必要になります。ここはクライアント実装差が大きいため、手元のバージョンのドキュメントとログをセットで読むのが確実です。

6. 購読元（403・UA・レート制限）

TLS まで通ったのに失敗する場合は、HTTP レイヤで弾かれている可能性があります。ログや詳細表示に 403 Forbidden、429 Too Many Requests、451、あるいは本文に「期限切れ」「無効なトークン」などが出ていないかを確認します。購読プロバイダによっては、User-Agent や Referer、同一 IP からの短時間大量リクエストを制限しています。ブラウザでは成功しても、コアの UA がブラウザと異なるため 403というケースは実在します。その場合はプロバイダのドキュメントに従い、推奨 UA の指定や専用クライアントを使うか、更新間隔を伸ばしてレート制限に触れないようにします。

また、CDN や WAF の前で地理的ブロックが掛かっていると、ブラウザ（普段使いの回線）とコア（別プロファイルや別 DNS 出口）で結果が分岐することがあります。VPN や策略を切り替えた直後だけ失敗するなら、その経路が購読ドメインから拒否されていないかを疑ってください。自動フェイルオーバーの挙動は url-test / fallback の稿とも関連しますが、購読取得はそもそもノード集合が揃う前の段階である点に注意してください。

7. ログ文言クイック対照表

典型的なログ断片と、まず疑う方向を短く対照します。表は確定診断ではなく優先度付けです。環境により例外は常にあります。

ログに近い表現	まず疑う層	次の一手（例）
`lookup` / `no such host` / `NXDOMAIN`	DNS	`nslookup`、DoH と OS の差、`nameserver-policy` の見直し
`i/o timeout`（解決は成功）	TCP 経路・フィルタ・ループ	手動プロキシの自己参照、FW、中間装置、別回線での再試行
`certificate` / `x509` / `handshake`	TLS	`curl -v`、HTTPS スキャン、証明書期限、SNI の取り違え
HTTP `403` / `429`	購読サーバポリシー	UA・更新間隔・トークン期限、プロバイダのステータスページ

この表で「どの段で止まっているか」が一つに絞れたら、その層だけ最小変更で A/B テストします。複数のエラーが同時に出る場合は、時系列で最初に出た失敗を優先してください。後段の TLS エラーは、実は前段のプロキシループの副作用、ということもあります。

8. まとめ

Windows で Clash / mihomo の購読更新だけが不安定なときは、ブラウザとの差分に着目し、ログを DNS・TCP/TLS・HTTP の順に読むと早いです。mixed-port とシステムプロキシの組み合わせは見落としやすいので、タイムアウトが続く場合は早めに疑ってください。購読インポートの基本や用語はチュートリアル総覧にも集約されていますが、本稿の焦点はあくまで「取得パス」の実ログに基づく切り分けです。

原因が分かれば対処は単純になることが多く、DNS を揃える・TLS を邪魔する製品を調整する・プロキシの自己参照を解く・プロバイダのレート制限に触れないのいずれか、あるいはその組み合わせで収束します。長く使うほど、ログを読めるクライアントの価値は上がります。同種ツールのなかでも、Clash 系は表現力と可観測性のバランスが取りやすい、という評価をされることも多いでしょう。

まずは手元の Windows に合うビルドを選び、ログレベルを上げて一度だけ再現ログを取るのが最短です。パッケージの入手と各プラットフォーム向け一覧は → 無料で Clash をダウンロードし、快適な接続体験を試すからどうぞ。