1. よくある症状の整理
まずは「どの段階で止まっているか」を分けます。HTTP で購読本文が取れていないのか、本文は取れたが YAML として解釈できないのか、設定は読めたが期待したルールにマッチしないのか、では切り分けがまったく異なります。
例えばタイムアウトや TLS エラーばかりなら、URL そのものより経路・DNS・端末の接続制限を疑います。逆に「取得は成功」と出るのにすぐ解析エラーなら、中身が HTML のエラーページになっている、文字コードや先頭の不可視文字、プロバイダ側のテンプレート不整合など、コンテンツ側の問題が中心です。
用語の整理や全体像は ドキュメントの概要も参照してください。デスクトップ版との UI の違いはありますが、コアが期待する YAML の形は共通です。
| 画面やログの様子 | まず疑う層 | 次に試すこと |
|---|---|---|
| 取得中のまま止まる／タイムアウト | URL・ネットワーク・省電力 | ブラウザで同一 URL を開く、Wi‑Fi 切替 |
| 401／403 や「認証」系 | トークン期限・Referer 要件 | プロバイダの再発行、クエリの再確認 |
| parse error／YAML エラー | 中身が設定ファイルではない | 生データを確認、エンコーディング |
| ルールを変えたが挙動が同じ | 別プロファイルが有効／更新未反映 | 選択中プロファイル、手動更新、再起動 |
2. 購読 URL（リンク）の検証
購読リンクは、ブラウザのアドレス欄に貼るだけでは足りないことがあります。クエリに トークンや ユーザー IDが含まれるタイプでは、コピー漏れや改行混入で 404 や 403 になります。メールやチャットから貼った場合は、前後に空白が付いていないかも確認してください。
HTTPS であること、リダイレクトチェーンが異常に長くないこと、証明書エラーをブラウザが出さないこと、は最低限のチェックです。企業 Wi‑Fi ではキャプティブポータルの HTML が返り、一見「取れた」ように見えることがあります。
User-Agent とアクセス制限
一部のプロバイダは、クライアントの User-Agent や Referer を検査します。アプリ側で失敗するが PC ブラウザでは成功する、というときはこの線です。公式クライアントの更新で対応していることも多いので、古い APK を使い続けていないかを先に確認します。
3. Android 端末とネットワーク
Android では バッテリー最適化やバックグラウンド制限で、定期更新が静かに失敗することがあります。購読の自動取得タイミングと、OS のスリープや省電力モードの関係を疑ってください。また プライベート DNS（DNS over TLS）を有効にしていると、意図しないリゾルバへ向いて挙動が変わる例もあります。切り分けのため一時的にオフを試す価値はあります。
モバイルデータと Wi‑Fi を切り替えて、同じ失敗が再現するかも見ます。IPv6 だけ別経路になっているケースでは、ルータや APN 設定と組み合わさって不安定になることがあります。
VPN の二重化に注意
すでに別の VPN アプリを常時オンにしていると、Clash Meta のトンネルと競合し、購読 URL への到達そのものが不安定になることがあります。テスト時は競合しそうなアプリを一時停止し、単一の出口に揃えてから再試行してください。
4. 取得後の YAML／プロファイル確認
購読で落ちてくるのは、多くの場合 Clash 形式の YAML です。proxies:、proxy-groups:、rules: などのキーが期待どおりか、インデント（半角スペース）が崩れていないかをざっと見ます。全文が HTML や「お知らせ」テキストだけなら、購読 URL が間違っているか、認証が必要な状態です。
外部ルールセット（rule-providers や RULE-SET）を参照している構成では、本体の YAML は正しくても、取得先のルールファイルが失敗していることがあります。エラーメッセージが provider や download に関するものなら、その行を優先して直します。
コアのバージョン差
Mihomo／Clash Meta 系では、古いコアが未知のキーを嫌う、というより「スキーマが拡張されている」側の話が多いです。クライアントを最新に寄せたうえで再インポートすると解消することもあります。逆に、デスクトップ専用の記述をそのまま流用して失敗する例では、該当キーを削る・置き換える必要があります。
# Structure example — keys vary by provider and core version
port: 7890
proxies:
- name: "example"
type: ss
server: example.com
port: 443
proxy-groups:
- name: "auto"
type: url-test
proxies:
- "example"
rules:
- MATCH,auto実際のキー名や必須フィールドは、利用中のプロバイダとコアのドキュメントに合わせてください。上記は構造のイメージ用です。
5. ルール更新が反映されないとき
「購読は成功したが、期待したサイトだけ直結のまま」という場合は、まず現在アクティブなプロファイルがどれかを確認します。複数プロファイルを保存していると、更新したのは別名で、実際に適用されているのは以前のもの、というミスがよくあります。
次に ルールの優先順位です。Clash 系は上から評価され、先にマッチした行が勝ちます。細かい DOMAIN ルールを足したつもりでも、より上にある MATCH や広い GEOIP に吸われていると、体感は変わりません。GUI のログで、対象ホストがどの行にヒットしたかを確認してください。
ルールプロバイダを使っている場合は、更新間隔と手動更新の有無を確認します。ローカルにキャッシュされた古いルールセットが残っていると、購読自体は新しくてもルールだけ古い、という状態になり得ます。キャッシュ削除やアプリの「ルールを更新」に相当する操作を試します。
DNS モードとの関係
Fake-IP を有効にしている構成では、名前解決とルール評価の関係が複雑になります。ブラウザの開発者ツールでは見えているホストと、コアが評価している名前が一致しないように見えることがあります。DNS 関連の設定を変えた直後は、一度コアの再起動や接続のリセットを挟むと切り分けが早いです。
6. ログで見るべきポイント
アプリが提供するログ画面では、購読取得の HTTP ステータス、TLS の失敗、YAML パースの行番号、ルールプロバイダの取得結果が分かる場合があります。検索しやすいクライアントなら、subscription、fetch、parse、provider などの語で絞り込むと早いです。
接続ログ側では、問題のドメインに対してどのポリシー（PROXY／DIRECT 等）が選ばれたかを追います。ここが期待と違うときは、ルール側の修正ポイントがはっきりします。ノードのレイテンシではなくポリシー選択が問題なのか、を混同しないことが重要です。
長期運用では、購読の失敗が続くときに備えてバックアップした YAMLをローカル保存しておくと復旧が早くなります。クラウド同期に頼る場合は、個人情報の取り扱いに注意してください。
7. まとめ
Clash Meta for Android で 購読インポートが不安定なときは、URL が本当に設定本文を返しているか、端末とネットワークが取得を阻んでいないか、取得できた YAML がコアの期待と一致しているか、の順に見ると迷子になりにくいです。そのうえで ルール更新は、正しいプロファイルが有効か、ルールの当たり順、ルールプロバイダのキャッシュをセットで確認してください。
同種のアプリのなかでも、Clash 系はログと設定の見え方が比較的明瞭で、試行錯誤のコストを抑えやすい傾向があります。スマホでも、一度切り分けの型を身につけると再発時に数分で戻せるようになります。
クライアントの入手と更新は、配布元を確認したうえで 公式サイトのダウンロードページから行うと、導線がぶれにくくなります。
