ブラウザでは開けるのに Clash だけ失敗する理由
購読（サブスクリプション）の更新は、見た目は「URL を開くだけ」に似ていますが、実際には HTTP クライアントとしての挙動が絡みます。ブラウザは最新の TLS、一般的な User-Agent、Cookie やリダイレクトの扱いを持ちます。一方、Clash コアや GUI は 別の UA 文字列で取得したり、システムプロキシやルールの影響を受けたり、古いレスポンスをキャッシュしたままにしたりします。だから「同じ URL をブラウザでは開けるのに、更新ボタンだけ 404／403」という状況が起きます。
切り分けの第一歩は、UI の「失敗」ではなく ログの HTTP ステータスと どのホストへリクエストしたかを揃えることです。接続段階の timeout や TLS ばかりを見がちですが、購読フェーズでは timeout と TLS の読み方 より先に、404／403 の意味と UA・経路を疑うと早いことが多いです。運用全般は 購読とノードの保守 と役割が分かれますが、本稿はあくまで取得フェーズの HTTP エラーとクライアント側の掃除に焦点を当てます。
HTTP 404：存在しない URL と期限切れパス
404 Not Found は「サーバがそのパスを知らない／もうない」と言っている状態です。典型例は、ダッシュボードで発行し直したあと古いリンクを Clash に残したまま、短縮 URL の先が変わった、CDN のキャッシュキーが変わって実体とズレた、といったケースです。ブラウザではブックマークの新しい方を開いているのに、Clash には古い文字列が残っている、という単純ミスも珍しくありません。
対処はまず コピー＆ペーストの再取得です。ダッシュボードで表示されている現在の URL を、そのまま購読欄に貼り直し、余計な空白や改行が入っていないか確認します。複数行に分かれた購読がある場合は、意図しない行だけが 404 になっていることもあるため、ログに出る完全な URL（ドメイン＋パス）をメモして比較してください。
404 が続くときは「サーバ側でパスが廃止された」のか「クライアントが別ホストへ向いている」のかを分けます。DNS の取り違えや企業プロキシの置換で、ブラウザと Clash で名前解決結果が違う例もあります。同一端末で curl やブラウザの開発者ツールと、Clash のログ行に出るホストを突き合わせると、どこで分岐したかが見えやすくなります。
HTTP 403：アクセス拒否・UA・レート制限
403 Forbidden は「接続はできたが、このリクエストは許可しない」という意味合いが強いです。認証が足りないのではなく、ポリシーで弾かれたイメージに近いことが多いです。購読 URL の文脈では、以下が典型です。
- User-Agent や Referer を見てブロックしている（「ブラウザからのアクセスのみ許可」など）
- 同一 IP からの短時間リクエストが多すぎる（レート制限・WAF）
- データセンター／ASN 由来の IP を拒否している
- トークン付き URL を共有用と誤解して何度も叩き、サーバ側ルールに引っかかった
403 は 401 のように「ログインし直せばよい」タイプではなく、条件を満たす別の取得方法が必要なことがあります。プロバイダの案内に「専用クライアント」「推奨の取得間隔」「Clash 向けの別 URL」などがあれば、それに従うのが最短です。
User-Agent とヘッダ差：サーバがブロックする典型
多くの購読サーバは、ブラウザの UA なら通すが、空に近い UA やツール名が入った UA をボット扱いする設定を持ちます。Clash／Mihomo 系は設定やバージョンによって送信ヘッダが変わるため、「アップデート直後だけ 403」は UA まわりを疑う価値があります。GUI に 購読専用の UA 上書きがある場合は、プロバイダ指定の文字列（または一般的なブラウザに近い UA）へ一時的に合わせて試し、改善するか観察します。
UA 以外にも、HTTP/2 と HTTP/1.1 の差、TLS フィンガープリント、IPv4 と IPv6 のどちらで出ているかで結果が分かれることがあります。ブラウザは成功しても、データセンター出口やホスティング ASN からだと 403 になる、という説明はよく聞かれます。自宅回線とモバイル回線で切り替えて試すと、IP 由来かどうかの当たりが付きます。
ログに出るイメージ（例）GET https://example.com/sub/token123 403
subscription update failed: unexpected status code 403更新だけがプロキシループに巻き込まれる
OS のシステムプロキシが Clash を指していて、かつ Clash 側のルールで購読取得もプロキシ経由になっていると、更新だけが不安定になることがあります。ブラウザは拡張や直結設定で「購読ドメインだけ直に行く」一方、Clash は自分自身へ戻るリクエストを作ってしまう、といったパターンです。対策の基本は、購読ドメインや更新先（GitHub Raw、ルール CDN など）に対して DIRECT か信頼できる低リスク経路を割り当てることです。
ルールの詳細は ルールのベストプラクティス で扱いますが、購読更新の文脈では「更新 URL がどのポリシーに乗るか」を一行ずつ確認するのが実務的です。購読管理のガイド にある「更新と日常トラフィックを分ける」という考え方と矛盾しません。
更新成功に見えてノードが空のとき
HTTP 200 が返っても、中身が空の YAML／空のプロキシ一覧だと、画面上は「更新した」に見えてノードがゼロのままです。原因は大きく分けて、(1) サーバが空の構成を返している、(2) クライアントが古いキャッシュファイルを読み続けている、(3) パースエラーでプロキシ行がすべて捨てられている、の三つです。(3) はログに parse や yaml 関連の警告が残りやすいので、まずそこを確認します。
パース以前に HTTP で失敗しているのに、UI が古い一覧を表示している場合もあります。これはローカルに前回成功分が残っているためで、見た目の「ノードがある」が最新性の保証にはなりません。更新直後にログのステータス行と、実際に取得したバイト数を見る習慣があると、誤解が減ります。
ローカルキャッシュの場所と削除の考え方
キャッシュを消す目的は、「サーバは直したのにクライアントが古い失敗を握りしめている」状態を終わらせることです。製品ごとに保存先は異なりますが、共通するのは アプリを終了してから該当ディレクトリを消すか、GUI の「キャッシュクリア」「データリセット」に相当する操作を使う手順です。Windows では %USERPROFILE%\.config 配下、macOS/Linux では ~/.config 配下に、プロファイル名や購読ハッシュのフォルダがあるケースが多いです。正確なパスは利用中のクライアントのドキュメントを優先してください。
消す前に プロファイルのエクスポートや、購読 URL の控えを取っておくと安全です。キャッシュ削除は「設定ごと飛ぶ」操作と隣接している製品もあるため、バックアップなしの全消去は避けます。削除後はアプリを起動し直し、購読を一度だけ手動更新してログを確認します。それでも同じ 404／403 なら、もうクライアントではなく URL・サーバ・ネットワーク側に原因が残っています。
併せて OS レベルの DNS キャッシュが古い名前を返している場合もあります。接続ログでは別記事の領域ですが、購読ホストが切り替わった直後だけ奇妙な挙動をするなら、端末の DNS キャッシュ flush や、一時的に別リゾルバへの切り替えも検討します。詳細は FAQ の DNS・接続の項 とあわせて読むと整理しやすいです。
切り分けチェックリスト
- ログに出る完全な URLと、ダッシュボードの現在の URL を文字列比較する。
- HTTP ステータスが 404 か 403 か、それ以外（timeout／TLS）かを分類する。
- 403 なら UA 上書き・別回線（IP）・取得間隔を順に試す。
- システムプロキシとルールを確認し、購読取得が意図せず PROXY になっていないか見る。
- 更新後もノードが空なら レスポンス本文とパース警告を確認する。
- 疑わしい場合はキャッシュ削除後に単一購読だけの最小プロファイルで再試行する。
- それでも解消しない場合は、マスクしたログをプロバイダに問い合わせる材料にする。
まとめ
購読更新のトラブルは、「ブラウザで開ける＝Clash でも成功」とは限りません。HTTP 404／403は URL の鮮度とサーバポリシーの問題、User-Agent や経路はクライアントとルールの問題、キャッシュはローカル状態の問題として切り分けると、設定を無闇に入れ替える回数が減ります。ノードの安全な運用やローテーションの話は引き続き 購読とノードの記事 に任せ、本稿のチェックリストで「取得段階」を潰すイメージを持ってください。
ログが読めて、ルールが追えるクライアントは、長期運用で最もコストが低いことが多いです。暗い再インストールルーレットより、ステータスコードとヘッダ差を一つずつ潰す方が早いです。
→ 原因の型が分かったら、Clash を無料ダウンロードし、安定したクライアントで購読更新から日常の接続まで一気通貫で試してみてください。