一、症状：成功表示と空リストのギャップ
まず整理したいのは、「HTTP 的には最後まで届いた」と「コアがプロキシ定義として解釈できた」は別だという点です。購読 URL が ログイン画面・メンテナンス告知・JSON のエラーなどを返していると、ステータスコードは 200 でも proxies: が存在しないか空になり、GUI では「更新成功」に近い文言だけが残ることがあります。
また proxy-providers 方式では、親となるプロファイルに proxies: が直接書かれておらず、別ファイルの取得結果をマージします。このとき Provider 側の取得失敗やパース失敗が親の購読行とは別ログに出ると、「購読は緑、中身は空」に見えやすいです。
| 画面の様子 | 最初に疑う層 |
|---|---|
| 更新成功だが一覧ゼロ、ログに parse 系 | レスポンスが YAML ではない／BOM・文字化け／必須キー欠落 |
| 直書きはあるが Provider 由来だけ空 | proxy-providers の URL・パス・health-check 前後の失敗 |
| 一度は出たが更新後だけ消える | キャッシュされた古い空ファイル／間違った path への書き込み |
| 別 PC では正常、この端末だけ空 | 選択中プロファイルが違う／旧キャッシュディレクトリの残存 |
用語や全体像は ドキュメントも併せて参照すると、購読・ルール・DNS の境界が掴みやすくなります。
二、本文確認：YAML か HTML／403 か
ブラウザまたは curl で購読 URL を開き、先頭数行が proxies: や proxy-providers: を含むプレーンテキストかを確認します。DOCTYPE や <html> が見えたら、認証切れ・リンクのコピー漏れ・WAF によるブロックが典型です。本文が Base64 だけのリスト形式（一部の互換モード）になっている場合は、利用クライアントがその形式を 自動デコードするかどうかを release note で確認してください。
エンコーディングと不可視文字
UTF-8 以外で保存されたテンプレや、先頭に BOM が付いたファイルは、パーサによっては失敗または空扱いになります。エディタの「先頭バイト表示」や別ツールでの変換で一度クリーンにすると再現が止まることがあります。
三、proxy-providers と設定の参照関係
親 YAML で proxy-providers: を宣言し、proxy-groups から <providerName> 形式で引いている構成では、次を点検します。(1) 各 Provider の url が有効か、(2) path が書き込み可能なディレクトリか（コンテナや権限で失敗すると空のまま）、(3) type: http と interval が意図どおりか。
use: やパッチ機能で複数ファイルを合成している場合、マージ後の実効設定が GUI の単一タブと一致しないことがあります。一時的に最小構成（Provider 一つだけ）へ落として再現するか、ログで provider 名をキーに検索すると、どの段で止まっているかがはっきりします。
# Illustration only — field names follow your core docs
proxy-providers:
sub-nodes:
type: http
url: "https://example.com/sub"
path: ./providers/sub.yaml
interval: 3600
proxy-groups:
- name: "auto"
type: url-test
use:
- sub-nodes実際のキー（override や header など）は利用中のコアのドキュメントに合わせてください。
四、YAML 解析：空配列とインデント
Clash 系が期待するのは、多くの場合 マップの下にリストが並ぶ構造です。proxies: の直下が空、またはコメントアウトだけ、という購読は「パースは成功したがノード数ゼロ」になります。インデントがタブ混在・全角スペースだと、見た目は正しくてもパーサが別ブロックと解釈する例があります。
さらに、テンプレート変数が展開されずに残っている行（{{ のまま）は、環境によっては無効エントリ扱いになります。サーバ側の生成ミスか、ローカルで誤ったプレースホルダを残していないかを確認してください。
五、Provider キャッシュの更新と削除
path: に指定したローカルファイルが、一度失敗した空レスポンスのままキャッシュされていると、URL を直しても GUI が古いファイルを読み続けることがあります。クライアントに Provider の手動更新や キャッシュクリアがあれば実行し、なければ該当ディレクトリの YAML をバックアップのうえ削除してから再取得を試します。
更新間隔と手動トリガ
interval が長いと、プロバイダ側でノードを差し替えた直後でも手元は半日古いまま、という体験になります。運用では「購読本体」と「rule-providers」の更新タイミングを分けて考え、トラブル時だけ間隔を短くする、と整理すると切り分けが速くなります。ルール側のキャッシュ挙動は DNS とセットで効くため、名前解決まわりが怪しいときは fake-ip／DNS の切り分け記事も参照してください。
コンテナや macOS のサンドボックス環境では、マウントしたボリューム上の path に書き込めず、サイレントに失敗する例があります。ホスト側のパーミッションと、コンテナ内の作業ディレクトリを揃えてから再試行してください。
六、プロファイル選択と UI の見かけ
複数プロファイルを切り替えられるクライアントでは、更新したのは別名のファイルで、実際に動いているのは以前のプロファイル、というミスが非常に多いです。タイトルバーや設定画面の「現在有効なファイル」表示を必ず確認してください。
また プロキシグループの型（url-test／select など）によって、一覧の出方が変わります。Provider から読み込んだノードが hidden: true 相当の扱いや、別グループにのみ割り当てられていると、ホーム画面のリストだけ見て「空」と誤認することがあります。YAML 上で proxy-groups の proxies:／use: を追うと早いです。
コアを CLI で動かしている場合は、設定ファイルのパス引数と、systemd や launchd の Unit が参照しているパスが一致しているかも確認してください。不一致だと、手動テストでは直ったのに常駐だけ古い、というパターンになります。
七、まとめ
Clash で 購読の更新成功と出ても ノード一覧が空のときは、(1) レスポンス本文が本物の設定か、(2) proxy-providers の URL・パス・権限、(3) ローカルキャッシュされた空ファイル、(4) 有効プロファイルとグループ定義の順に見ると、原因の層を素早く絞れます。モバイルで URL 取得自体が不安定な場合は、先に Android 向け購読記事でネットワークと UA を固めるとよいでしょう。
同種ツールのなかでも、Clash 系はログとファイルベースの設定が追いやすく、一度手順を型化すると再発時の復旧が短くなります。ルールや DNS を広く押さえたい場合は ドキュメントの導線から全体像を確認してください。
クライアントの導入と更新は、配布元を確認したうえでサイト内の入手導線に揃えると設定ファイルのパスや権限の説明とも噛み合いやすくなります。