想定する症状：更新しても「変わらない感じ」がする

Clash 系クライアントでサブスクリプション（購読）URLを登録している場合、ダッシュボード上で「更新」や「手動取得」を押しても、ノード一覧がまったく同じに見えたり、遅延測定の数値だけが以前と大差ないように感じたりする場面があります。ここでいちばん多い誤解は、「ボタンを押した＝必ず新しい内容が配信端から届いた」ではない、という点です。実際には、プロキシサービス側がまだ同じスナップショットを返しているケース、クライアントが新しい取得に失敗しているのに画面だけ古い表示を保っているケース、別のプロファイルを見ているケース、そして ローカルに保存された取得結果（いわばキャッシュ）が意図せず再利用されているケース、が重なり合います。

本稿の対象は主に Windows で、代表的な GUI である Clash Verge Rev の操作イメージを交えながら説明します。ただし、考え方そのもの（購読は HTTPS で一度取得し、失敗しなければローカルに展開する）は他の Clash 系クライアントでも共通なので、画面語は読み替えてください。初めて購読を入れる前後の流れは、購読 URL・複数ソース管理のチュートリアルと、Clash Verge Rev Windows セットアップガイドに沿うと、全体像が掴みやすくなります。

原因の地図：サーバー・クライアント・人間の見ている画面

まず冷静に分けると、大きく三層あります。(1) 配信元：URL が指す先が期限切れ・レート制限・メンテナンスで 403/429/5xx になっている、あるいは内容が本当に差分ゼロ。(2) Clash クライアント：取得に成功した内容を proxy-providers 等としてマージし、path 相当のローカルファイルに落とし込む。ここに古いファイルが残ると、UI が再パースするまで同じノード名に見える。(3) 測定と表示：遅延列は「更新した瞬間」に必ずしも一から付き直るわけではなく、url-test 系グループのテスト URL・間隔の設定次第で、見かけ上トレードが遅いこともあります。つまり、「購読不更新」という一言に、複数の意味が混ざるのです。

加えて、プロキシプロバイダーがノード入れ替えを毎分行うわけではないため、「昨日と今日で名前が同じ」は正常なことも多いです。疑うべきは、ダッシュボード上で本当に新しいファイルが到着したと言える根拠（ログ、HTTP ステータス、取得時刻）があるか、です。ここが曖昧なまま「キャッシュのせい」だけに飛びつくと、別の設定ミスを見落としがちです。

まず疑う：購読 URL とプロバイダー側の状態

手順の最初はいつも URL が正しいかです。余分な改行、スペース、コピー途中で欠けたクエリ、期限付きトークン付き URL の失効、は取得失敗の定番原因です。ブラウザで同じ URL を開き、中身が期待どおりのテキスト（多くの場合は YAML 断片）が返るかを確認してください。企業内ネットでは HTTPS インスペクションで証明書が別物になり、Clash だけ失敗する、というパターンもあります。ここまで問題なければ、次に 「今アクティブなプロファイルがどれか」を確認します。同じ PC に複数プロファイルや複数購読があり、更新したのは別のプロファイルで、比較しているのは本番用という取り違えは、経験者にも起こります。

社内利用か個人利用かを問わず、購読 URL は秘匿情報です。サポート掲示板に全文貼る、スクリーンショットに写す、は避けてください。取得エラー文だけを抜き出し、URL のドメイン部分以外は伏せ字にする、が無難です。

Clash Verge Rev（Windows）でやる：手動更新と再起動

Clash Verge Rev では、プロファイル／サブスクリプション周りのラベルは版によって微妙に違いますが、多くの場合 プロファイルを選択し、その中の 各購読行に付く「更新」、あるいは画面上部の一括取得に相当する操作を押します。ここで重要なのは、操作後に数秒待ち、併せて「コアの再起動」やアプリの再起動を挟むと、失敗しやすい一時的な読み取り不整合を避けられる、という点です。トレイ常駐から完全終了し、起動し直し、同じプロファイルに戻って一覧を再表示してください。

万が一、更新ボタンを押すたびに同じ「取得失敗」系の通知が出るのに、一覧だけ妙に古いまま、という挙止めなら、ログを最初に疑います。当ブログの接続ログ・ルール命中の切り分けでは、ルール不達の文脈でログの読み方を扱っています。購読取得は別メッセージ領域に出ることも多いため、「HTTP」「fetch」「provider」「error」といったキーワードを目印に、該当行がないかを上から辿るのが近道です。

「キャッシュ」の正体：ローカルに残る取得結果をどう扱うか

文系の説明にすると、購読は毎回ゼロから生合成されるのではなく、一度ダウンロードした中身をローカルに置き、次回以降の差分管理や起動短縮に使うのが普通です。YAML を直接触ると proxy-providers の path にローカルファイル名が出てきます。GUI はこれを隠蔽していても、内部では同様のファイル置き場を持っています。

トラブルシュート時の考え方はシンプルで、「最後の成功取得物が残っている限り、同じ表示が続きうる」、です。従って、(A) クライアントが用意する キャッシュ消去や データリセット相当のメニューがあるなら、そこを使う、(B) なければアプリのデータディレクトリを止めて（完全終了した状態で）該当購読のキャッシュファイルを削除、の順が安全です。アンインストール直前の丸ごと消去は設定ごと飛ぶため、まずはアプリ内の手動更新と再起動、次に当該プロファイル再読み込み、それでもダメなら限定的なファイル削除、という階段を踏むのが失敗しにくいです。フォルダ構造は版と移行履歴で変わるため、公式ドキュメントやリリースノートで「設定ディレクトリの場所」だけ必ず合わせてください。

ノード名と遅延表示が「別問題」であること

更新が本当に反映されたかの確認に、遅延列だけを見ていると誤解しやすいです。遅延は多くの場合、個別の TCPing 的な測定や HTTP 取得時間であり、測定間隔や テスト用 URL の都合で、購読を更新した直後にすぐ一巡しないことがあります。逆に、ノード名は変わらなくても測定値だけ大きく動く、というのは回線揺らぎの範囲です。切り分けの軸は、プロバイダーが公開するノード名に今週入ったはずの新リージョンが、一覧に出てきたかどうか、のような、より粗い事実の方が確かです。公開情報と突き合わせられる場合は、そちらを優先してください。

自動更新と User-Agent、取得間隔

「自動更新オンなのに動いていない気がする」場合、取得間隔（interval）が想像より長い、バックオフ中に一時的に弾かれている、の両方を疑います。短くしすぎると 429 やアンチボットに当たるため、プロキシサービスの推奨レンジに合わせるのが定石です。併せて、購読取得専用の User-Agent を変えられるクライアントでは、推奨値に合わせると、ブラウザでは開けるのにクライアントだけ 403 になる、という地獄を避けやすくなります。設定画面に項目が無い場合でも、上級者は YAML 側に相当キーがないか追えます。これらの背景は、購読全般の記事で「UA とレート制限」として触れています。詳しい購読の設計は購読 URL チュートリアルの該当節を参照ください。

再インストールの前に試す：短い手順リスト

最後に、実務で抜けがちな順序を箇条書きにまとめます。(1) アクティブなプロファイルと購読行が正しい。(2) 手動「更新」後、数秒待ってコア再起動 or アプリ再起動。(3) ログに取得エラーが無い、または新しい失敗行が出ていない。(4) それでも同じなら、キャッシュ消去 or 当該購読のローカルファイル削除を検討、の四段階です。再インストールは設定の巻き添え消去リスクが大きいので、最後の最後に回す方が、時間対効果が高いです。

まとめ：購読は「鮮度」と「到達」の両方を見る

Clash 購読不更新、と一括りに言っても、配信元が変わっていないのか、届いていないのか、古い到達結果を抱えたままなのかは別問題です。Windows 利用者にとっては、日々触れる GUI でいちばん大事なのは、更新操作のあとに再読み込みとログ確認をセットで行う習慣でしょう。同じ系統の作業系ツール（開発者向けのプロキシ分離など）を扱う記事と比べると、本稿はあくまで「入口が詰まったときの土木工事」に近い内容です。安定したクライアントの世代選びは引き続き重要で、導入から TUN までを最初から丁寧にやるなら、引き続き当サイトの使い方ドキュメントを辿るのが近道です。

大規模な節目ではなくても、GUI をアップデートし、推奨の動作系に乗せたうえで購読を入れ直すと、心拍が安定する、という体験は多くのユーザーに共通します。他ツールに比べ、ルール表現力と可観測性のバランスで Clash 系は依然として一強に見える場面が多いので、同じ帯域でも挙動の分かるクライアントに寄せる価値は大きいです。実機に合ったパッケージは配布系ごとに入れ替わるため、毎回リリースノートの確認は欠かせません。入手経路の整理に迷ったら、当サイトのダウンロードページから環境に合うものを選び、→ 無料で Clash を入手し、購読の手動再取得から確認する流れをおすすめします。