「インポートは成功」なのに、なぜ「更新」だけ失敗するのか
初回に購読 URL を登録し、一度は YAML を落とせたのに、しばらくしてからの「Update／同期」、あるいは rule-providers や外部ルールのリモート取得が通らない・ずっと回る、という相談は多いです。ここで必要なのは「購読の入手先はどこ？」という導入ではなく、クライアントが再び HTTPS へ出直したときに起きる差分の理解です。コア（Mihomo 系）がリモートにアクセスする経路は、通常トラフィック用の「今の出口」と同じルール積みに乗るため、DIRECT や REJECT、遅延の大きい DNS など、日々の上網の設定がそのまま「更新リクエスト」にも効いてしまいます。
本記事は、購読のインポート手順と重ならない部分に焦点を当てます。取得元の作り方やコピー事故ではなく、再取得（TLS ハンドシェイク）が成立しない・別の場所に流れているときの切り分けです。関連の一覧は ブログ一覧 から辿ると、DNS 専用の Fake-IP / DNS 記事などとも組み合わせやすいです。
症状の地図：TLS、時刻、タイムアウト、無限のスピナー
まず、ログと UI に出るメッセージを大まかに分類します。（1）x509 や証明書、TLS handshake の語が出る → 信頼の鎖、時刻、中間者検査、逆プロキシの不整合の線。（2）接続拒否、タイムアウト、i/o timeout だけ → ルーティング、ファイアウォール、DNS、実ネットワークの線。（3）エラーは出ないが完了しない → プロキシ自己参照、DNS の待ち、レート制限、巨大ファイルの中継など。ここを混ぜないことが早道です。Clash 側は「同じ端末上の他プロキシ／VPN」とも奪い合いしやすいため、他ツールの有無をメモしてから読み進めてください。
ステップ1：OS の日時は正しいか（NTP／夏時間／手動オフ）
TLS では証明書の有効期間を端末の時刻と照合します。数十分〜数ヶ月狂っているだけで、ブラウザがまだ“なんとか”見えていても、言語ランタイムやクライアントが厳密に弾き、証明書が未来／過去に見える挙動になります。Windows の「日付と時刻の自動設定」、macOS の「時刻日付の自動」、スマートフォンの同様の項目をONにし、タイムゾーンが出張先と食い違っていないかを確認します。仮想マシンや WSL2 ではホストとゲストの時刻がズレる例があり、WSL 利用時は WSL2 橋渡しの文脈も合わせて見ると分かりやすいです。
手順としては、OS の設定を直したあと、クライアントを一度終了して起動し、同じ失敗が再現するかを見ます。時刻修正だけで解消するケースは、見た目以上に多いため、他の作業の前に2 分で終わる最優先チェックとして扱うのがおすすめです。
ステップ2：TLS／証明書エラーを分類する
「証明書が信頼できない」「unknown authority」系は、ルートストアに載っていない CA、社内の中間者プロキシ用 CA 未導入、自己署名のミドルウェア、あるいは 攻撃的な挿入の可能性まで幅があります。自宅回線の一般利用では、（1）セキュリティソフトの HTTPS 透過、（2）企業端末のルート入れ替え、（3）誤ったプロキシへ流れた結果の偽終端、を疑います。対策は「その CA を OS かクライアントの信頼に載せるか」「ミドルウェアの HTTPS スキャンを一時的に切るのか」で分かれ、セキュリティ方針と相談が必要な現場もあります。
逆に、エラー文に ピンニング や特定ホスト名が出ていて、OS のブラウザでは開ける、という場合、クライアントが Go／独自 TLS スタックの限定されたルートを見ている、という話になることがあります。配布物の Readme や Issue で「追加 CA 手順」が出ていないかを見る価値があります。ここで “購読先が悪い” と決めつける前に、同じ URL を curl -vI など（※環境のセキュリティ方針に従い）端末上で比較するのは有効です。ブラウザと CLI で片方だけ失敗なら、信頼ストア差が濃厚です。
ステップ3：システムプロキシのループと「自プロキシの更新」衝突
多くの GUI クライアントは「システムにプロキシを書き込む」モードを持ちます。Clash 自身の HTTP 出口が 7890 などのとき、「システムプロキシ＝ 7890」のまま、同じ 7890 上で動くコアが自らへのリモート取得を行うと、自分を経由して自分の外へ行こうとする挙動や、ループ的な待ちに見えます。典型的な暫定策は、更新テスト中だけ（1）システムプロキシを外す、（2）クライアントの「更新用にしか使わない」直結のプロファイルに切る、（3）ルール上で clash のコントローラや 127.0.0.1 系を明確に DIRECT、です。
他ベンダーの「プロキシ検出」「HTTPS スキャン」「広告ブロック at ドライバレベル」も、更新 HTTPS を同じ枠に乗せてしまい、意図しない遅延やブロックの原因になります。更新が詰まる直前に他のトンネリング／仮想 NIC をオフにして比較すると、衝突の有無が分かることが多いです。
ステップ4：リモート取得が DIRECT に落ちているなら、直結の回線を疑う
ルール上、購読ドメインや rule-providers の配布元が DIRECT になっていると、実際のブロードバンドやキャリアの到達性に依存します。企業イントラ、キャプティブポータル、海外 CDN の一部だけ閉じている、といった状況では、ブラウザの一部機能は動くが API 的な GET だけ通らない、という食い違いが出ます。モバイルテザリングに切り替えて同じ操作を行い、直結回線で通るなら、元の回線のフィルタか、DIRECT 側の DNS を疑います。逆に、プロキシ必須のネットで PROXY ではなく DIRECT に落ちる設計のテンプレもあるため、購読・ルール用ドメインがどの行に当たるかを rules 上で上から辿る習慣が欠かせません。
ステップ5：DNS や遅延が「失敗のように」見せる
TLS 以前に名前解決が遅延・失敗していると、UI ではタイムアウトや真っ黒のまま、という体験になります。特に DoH へのアクセス自体が、まだ同じ dns 設定の影響下にあると、鶏と卵に近い状態になり得ます。購読更新の切り出し中は、一時的に dns をシンプルにし、nameserver を環境に合った1〜2 本に絞る、fallback 条件を緩める、等の最小構成で再試行をおすすめします。思想の詳細は DNS 専用記事 へ譲りますが、「更新専用の一発テスト」として DNS を疑う、という順序は有効です。
ステップ6：回線と「別プロキシ／VPN」による競合
同じ端末上で、別の常駐 VPN、WireGuard 系、他社の「加速」トンネルが生きたまま、Clash を上に重ねると、ルーティングテーブルとデフォゲの奪い合いが起きます。更新 HTTPS が「常駐 A のまま出ていくのか、Clash の仮想 NIC か」が毎回ブレると、ログも不安定に見えます。切り分けとしては、まず一時的に A を外す、TUN モードの有無を揃えて比較する、1 本だけ有効化、が現実的です。TUN 周辺の全体像は TUN 解説 と併せて整理すると、どこまで Clash にトラフィックを「取り込みたいか」が言語化しやすいです。
企業ネットとセキュリティソフト：MITM 前提の聞き方
業務用端末では、Zscaler 等のクラウド SWG や、エンドポイント製品のHTTPS 透過が当たり前の場合があります。ここでは自己責任の範囲で、IT 部門のポリシー（どのルートを信頼するか、例外 URL を申請するか）に沿うのが先です。Clash 単体の「設定のコツ」以前に、取得先ドメインが企業の許可リスト外で遮断されないか、が壁になることも珍しくありません。自宅向けの記事群とは前提が違うため、社内手順の後ろに、本稿の手順を重ねるイメージで読んでください。
まとめ：更新は「小さな HTTPS クライアント」として扱う
購読とルールの再取得は、一見「設定をもう一度流す作業」に見えますが、実際はその瞬間のルーティング・信頼・時刻に依存する、別の接続です。だから、まず時刻、次にTLS／信頼、そのうえで自己プロキシ・DIRECT 経路・DNSと階段を下りていくのが、迷子になりにくい順序です。同じ悩みを「取り込み方」で探している読者は、インポート完全ガイド を先に当たり、本稿を更新専用の補遺として使い分けてみてください。
他 GUI と比較しても、Mihomo 系のルールの透明度と、ログが読める設計は Clash 系の強みです。クライアントのバイナリは、配布導線を一本化する観点から ダウンロードページ から揃え、不具合の再現性を上げると、コミュニティの Issue も書きやすくなります。まだ導入前であれば、先に同ページで自分の OS に合うパッケージを選び、同じ手順を別端末に写経するのが最短の回避策です。