まず切り分ける：「購読の取得失敗」と「ノードへの接続失敗」は別問題

ユーザーから見るとどちらも「つながらない」に見えますが、Clash 系クライアントの内部では処理が分かれています。サブスクリプション更新 は、プロバイダが発行した 購読URL に対して設定ファイル（多くは Base64 やプレーンテキストのプロキシ一覧）を ダウンロードする工程 です。一方、ブラウジングやアプリ通信は、取得済みのノード定義に基づいて 実サーバーへプロキシ接続 する工程です。購読取得が 403 で止まっていても、古いキャッシュのノード定義が残っていれば「一応動く」ように見えることもありますし、逆に購読は成功しているのにノードだけ赤一色、という組み合わせも起こり得ます。

したがってトラブルシュートでは、クライアントのログや画面表示で まず「Subscription」「Update」「Fetch」 といった取得系のメッセージを探し、HTTP ステータスや TLS エラー、タイムアウトの有無を確認するのが近道です。以降のチェックリストは、この 購読取得フェーズ に絞っています。

ステップ1：システム時刻・タイムゾーン（タイムスタンプ検証）

多くの HTTPS 通信では、サーバー証明書の有効期間検証に端末の時刻が使われます。OS の時刻が大きくずれていると、証明書が「まだ有効ではない」「すでに期限切れ」と誤判定され、購読URLへの接続が失敗します。症状としてはブラウザでも同様の TLS エラーが出やすく、企業端末で NTP が遮断されている、デュアルブート後に時刻が狂った、仮想マシンのクロックがホストと同期していない、といった背景が考えられます。

対処はシンプルで、自動時刻同期（NTP）を有効 にし、タイムゾーンを実居住地域に合わせます。手動で時刻を合わせる場合も、秒単位まで正確に揃えると安心です。仮想環境やコンテナ内で Clash を動かしている場合は、ゲストOSのクロック を疑ってください。時刻修正後に一度クライアントを再起動し、購読の手動更新を試すと切り分けが早いです。

ログの見方 x509、certificate、handshake などの語が出ていれば TLS 周りです。時刻修正だけで消えることもあれば、次節の中間証明書やピンニングの問題に進みます。

ステップ2：HTTPS・TLS・証明書エラー（中間証明書・自社CA・プロキシのスキャン）

購読URL が https:// である場合、クライアントは通常のブラウザと同様に TLS ハンドシェイク を行います。ここで失敗する典型例は次のとおりです。第一に、サーバー側の 証明書チェーン不備（中間証明書の欠落）で、一部のクライアントだけ失敗する。第二に、企業ネットワークの HTTPS インスペクション により、OS が信頼していないローカルCA が挟まる。第三に、ウイルス対策やセキュリティ製品が自己署名の中間者（MITM）検査用証明書を提示する。

切り分けとしては、同じ端末のブラウザで 購読URLを直接開けるか を確認します。ブラウザでは通るが Clash だけ失敗する場合は、ランタイムの信頼ストアの差や、クライアントが参照する TLS 実装の違いが疑われます。逆にブラウザでも警告が出るなら、まずはネットワーク側またはプロバイダ側の証明書構成を疑うべきです。自宅回線で問題がなく、会社LANだけ失敗するなら、透明プロキシの可能性を考えます。

コアやクライアントのバージョンが古く、TLS 1.2 未満しか話せない、極端に古い暗号スイートしか使えない、というケースは減ってきましたが、長期間更新していない環境では Clash Meta（mihomo）への更新 も視野に入れてください。TLS の実装差は、取得失敗の形で表れます。

ステップ3：User-Agent と 403（ボット対策・WAF・ホットリンク防止）

購読サーバー側が User-Agent を検査し、特定の文字列以外を拒否する設定になっていることがあります。Clash 系クライアントはデフォルトで Clash や clash.meta など、実装ごとに決められた UA を送ります。プロバイダのドキュメントで「推奨UA」「カスタムUA」が指定されている場合は、プロファイルの 購読エントリ で UA を上書きできるか確認してください。空やブラウザに近い UA を要求されるケースも稀にあります。

403 Forbidden は「認証はできたがアクセス拒否」であり、リンクのパスが存在しても権限がない状態です。UA 以外では、Referer 必須、同一オリジン以外からの取得禁止、特定リージョンの IP のみ許可、レート制限 などが原因になり得ます。短時間に大量の更新を繰り返すと WAF に弾かれることもあるため、手動更新の連打は避け、間隔を空けて再試行します。

プロバイダが トークン付きURL（クエリに期限や署名を含む）を発行している場合、古いブックマークを貼り直していると 403 になりやすいです。ダッシュボードで 最新の購読URLを再発行 し、Clash に取り込み直すのが確実です。

ステップ5：キャッシュ・更新間隔・手動更新

取得に成功した購読内容は、クライアント側に キャッシュ され、一定間隔で自動更新されます。間隔はクライアントやプロファイルの auto-update-interval 等で変わります。更新が「失敗している」のか「まだ間隔が来ていないだけ」なのかを混同しないでください。ログに最終取得時刻と次回予定、あるいは直近のエラーが出ていれば判断しやすいです。

手動更新ボタンを押しても失敗する場合は、以降のネットワーク・ルールの項へ進みます。成功するが反映が遅いと感じるだけなら、間隔設定を短くするか、プロバイダ側の推奨更新頻度（過剰取得禁止）に従います。ディスク容量不足でキャッシュ書き込みに失敗している、という珍しいケースもゼロではないため、端末の空き容量も一瞥しておくとよいでしょう。

ステップ6：ルールやシステムプロキシが購読取得を迂回していないか

Clash は強力な ルール分流 を持つため、意図せず 購読URLのドメイン が特定のポリシーに乗り、遅延やブロックを受けている可能性があります。例えば、購読先が海外CDNなのに DIRECT 固定で到達できない、あるいは逆にプロキシ経由でプロバイダのジオブロックに引っかかる、といったパターンです。切り分けとして、一時的に システムプロキシをオフ にしてブラウザで購読URLを開けるか、別回線（テザリング）で試す方法があります。

長期的には、購読ドメインを 確実に到達できる出口 にマッチさせるルールを、GEOIP や MATCH より上に置くのが安全です。ルールの書き方全般は YAML ルール分流ガイド を参照してください。購読取得は「一般ブラウジング」と同じ出口に乗せるのがわかりやすいケースが多いですが、プロバイダの推奨（直結必須など）があればそれに従います。

HTTPステータスと疑うべき原因の早見

  • TLS エラー（証明書）：時刻ずれ、中間証明書、企業ミトM、クライアントの信頼ストア
  • 403：UA・Referer・IPレピュテーション・レート制限・トークン期限切れ
  • 404：URL誤り、プロバイダ側の失効、リダイレクト先消失
  • タイムアウト：DNS、経路、ファイアウォール、プロバイダ障害（別途 ping や別回線で確認）

これらはあくまで「購読HTTP取得」の話です。ノード自体への TCP／UDP 接続 がすべて失敗する状況は、別の記事で扱う Android のノード・DNS チェック と問題領域が異なります。両方のログを混ぜず、画面のどのエリアが赤いかを整理してください。

まとめ

Clash サブスクリプションの自動更新 が止まるとき、最初に疑うべきは 端末の時刻 と HTTPS／TLS、続いて User-Agent や 403、404 とリンク失効、キャッシュと更新間隔、そして ルールやネットワークによる購読URLへの到達性 です。ログに出る HTTP ステータスとエラー文言を手がかりに順に潰していけば、原因が「プロバイダ側」「端末の時刻・証明書」「クライアント設定」「分流ルール」のどこに寄っているかがはっきりします。

クライアントの種類や OS ごとに画面名称は違っても、購読取得の本質は同じです。長く使うほど、自分用の「購読が失敗したときのメモ」を残しておくと再発時に楽になります。実行ファイルの入手やバージョン選びは ダウンロードページ で一覧できます。

→ Clash を無料ダウンロード — 各 OS 向けクライアントを比較し、自分の環境に合うものから試せます。

関連：YAML ルール分流の全般、Clash Meta コア更新、技術コラム一覧。