まず失敗した段階を特定する
クライアントの「サブスクリプションを更新」は、単一の処理ではありません。少なくとも、ドメインの名前解決、接続の確立、HTTPリクエストの送信、レスポンスの受信、設定の解析、ローカルファイルへの保存、カーネルの再読み込みという段階があります。画面に「更新に失敗しました」とだけ表示された場合は、まずログやレスポンス内容から該当する段階を確認します。何度もクリックしても通常は結果が変わらず、サブスクリプションサービスのレート制限にかかる可能性もあります。
一般的なデスクトップクライアントでは、サブスクリプションは「設定」「サブスクリプション」または「Profiles」ページで管理します。mihomoカーネルを採用したクライアントなら、まず「設定」→「サブスクリプション」で対象設定を手動更新し、同じ時刻に記録されたログを「ログ」ページで確認します。ログレベルを選べる場合、調査中はInfoを使用します。エラー情報が少ない場合だけ、一時的にDebugへ切り替えてください。
| ログまたは現象 | 通常該当する段階 | 優先して確認する項目 |
|---|---|---|
no such host、ドメインの名前解決に失敗 |
DNS名前解決 | DNS設定、ネットワーク接続、サブスクリプションのドメインが有効か |
timeout、接続タイムアウト |
接続の確立またはレスポンス待機 | 直接接続とプロキシ経路、ファイアウォール、サーバー状態 |
401 または 403 |
サーバー側の認証 | トークン、リンクの有効期限、User-Agent、アクセス制限 |
404 または 410 |
サブスクリプションURLの無効化 | 完全なサブスクリプションURLを再取得 |
| YAML、Base64、またはフィールドの解析エラー | 設定の解析 | レスポンス形式、変換タイプ、クライアントの互換性 |
| ダウンロードは成功したが設定が変わらない | 保存または再読み込み | ローカルキャッシュ、現在有効な設定、ファイル書き込み権限 |
サブスクリプションのダウンロードとノード接続性を分けて考える
サブスクリプションの更新に成功したことは、クライアントが設定を取得して解析できたことを示すだけで、含まれるプロキシノードが接続できるとは限りません。逆に、現在のノードが使えても、サブスクリプションURLが有効とは限りません。ローカル設定が数日前に保存されたキャッシュで、ノードは動作していても、元のサブスクリプションのトークンが期限切れになっている場合があります。
- 更新に失敗したが古いノードは使える：サブスクリプションURL、認証、更新経路を重点的に確認します。
- 更新は成功したが全ノードがタイムアウトする：ノードのパラメータ、ネットワーク制限、システム時刻を確認します。
- ノード数が0になった：HTTPステータスコードだけでなく、まずサーバーのレスポンス内容を確認します。
- 設定をダウンロードした後に有効化できない：YAML構文、フィールドの互換性、カーネルのバージョンを確認します。
サブスクリプションURLの期限切れ・欠落・認証失敗
サブスクリプションURLには通常、アクセス用トークンが含まれます。トークンのリセット、プラン状態の変更、リンクの有効期限切れ、サーバー側のパス移行などにより、古いURLが401、403、404、410を返すことがあります。サービスによってはステータスコードが200でも、本文がログインページやJSON形式のエラー情報になっているため、「ダウンロード完了」と表示されても解析段階で失敗する場合があります。
完全なURLをコピーしたか確認する
長いURLは、チャットアプリへの貼り付け、QRコードの読み取り、手動改行によって末尾の文字が欠落しやすくなります。クエリパラメータ内の & にも注意してください。Webページからコピーする場合は、HTML上のエスケープ文字列ではなく、ブラウザのアドレスバーに表示された実際のURLを取得します。URLの前後に空白、日本語の引用符、改行を含めないでください。
- サブスクリプションサービスの管理ページに戻り、Clashまたはmihomo用のサブスクリプションURLを再度コピーします。
- クライアントで一時的なサブスクリプションを新規作成し、古い設定は急いで削除しません。
- 手動更新を実行し、ノード数、プロキシグループ名、更新日時を比較します。
- 新しい設定を読み込めることを確認してから、無効になった古いサブスクリプションを停止します。
サブスクリプションURLはアクセス認証情報に相当するため、公開ログ、スクリーンショット、オンラインのYAMLチェッカーに貼り付けないでください。エラー情報を共有する場合はドメインとステータスコードだけを残し、パス内のトークンとクエリパラメータを隠します。
コマンドラインでステータスコードとレスポンスの種類を確認する
ブラウザはログインページへ自動転送することがあり、Clashとは異なるリクエストヘッダーを使う場合もあります。コマンドラインでテストすると、ステータスコードとレスポンスヘッダーを確認しやすくなります。WindowsではPowerShellから curl.exe を呼び出し、macOSとLinuxでは curl を直接使用できます。以下は予約済みドメインによる例で、実際のサブスクリプション認証情報は含みません。
curl -I -L --max-time 15 "https://sub.example.com/clash/demo-token"
curl -L --max-time 15 -o subscription.yaml "https://sub.example.com/clash/demo-token"-I はレスポンスヘッダーだけを取得しますが、一部のサブスクリプションサーバーはHEADリクエストを受け付けません。最初のコマンドが405を返した場合は、2つ目の実際のGETリクエストを基準にします。ダウンロード後はまずファイルの先頭を確認します。HTMLは通常 <!doctype html> または <html で始まり、JSONエラーは中括弧で始まることが多く、Clash YAMLでは通常 proxies:、proxy-groups:、rules: などのフィールドを確認できます。
User-Agent検証と形式の互換性
サブスクリプションサービスによっては、User-Agentに応じて異なる形式を返したり、特定のクライアント識別子だけを許可したりします。ブラウザでは正常にアクセスできるのにクライアントの更新が403になる場合や、同じURLでもクライアントによって内容が異なる場合は、UAを確認します。一般的な識別子には clash、Clash.Meta、クライアント独自の名称がありますが、どれを受け付けるかはサーバー側の設定次第です。無作為に変更し続けても判断材料にはなりません。
まずサブスクリプションサービスの案内で推奨UAを確認します。クライアントに設定項目がある場合は、「設定」→「パラメータ設定」またはサブスクリプション編集画面で、「User-Agent」「サブスクリプションリクエストヘッダー」などの項目を探します。メニュー名はクライアントのバージョンによって変わります。その項目がない場合、推測でコア設定を直接変更しないでください。メイン設定のプロキシルールは、サブスクリプションマネージャーのHTTPリクエストヘッダーとは別物です。
curl -L --max-time 15 \
-A "Clash.Meta" \
-o subscription.yaml \
"https://sub.example.com/clash/demo-token"デフォルトのリクエストが403を返し、サービス側が明示したUAを使うと200と有効なYAMLが返るなら、問題はリクエストヘッダーの検証に絞り込めます。どちらのリクエストも同じエラーになる場合は、トークン、送信元IP、リクエスト頻度、サービス状態を引き続き確認します。
Base64形式のノード一覧とClash YAMLは別の形式
汎用サブスクリプションはBase64テキストで、デコードすると複数行のURIが含まれることがあります。一方、Clash設定は通常、構造化されたYAMLです。クライアントがClash YAMLしか受け付けない場合、汎用サブスクリプションをインポートすると「proxiesがない」「設定を解析できない」「ノード数が0」といった状態になることがあります。その場合はサーバー側でClash、Clash Meta、またはmihomoの出力形式を選び、ファイルの拡張子を手動で変更しないでください。
mihomoはClash設定との幅広い互換性を維持していますが、拡張フィールドが古いClashカーネルで認識されるとは限りません。たとえば新しいプロトコルのパラメータ、ルールプロバイダーのオプション、DNSフィールドなどが、古いカーネルで未知のフィールドや読み込みエラーになる場合があります。この場合はまずクライアントのカーネルバージョンを確認し、対応するサブスクリプションテンプレートを選びます。グラフィカルクライアントを更新しても、カーネルまで自動的に切り替わるとは限りません。カーネルのバージョンは「設定」→「カーネル」または「バージョン情報」ページで個別に確認してください。
YAMLを開けても読み込めるとは限らない
- 同じ階層のインデントは統一し、Tabとスペースを混在させないでください。
- プロキシグループが参照するノード名またはプロバイダー名が存在している必要があります。
rulesで使用する対象プロキシグループは、あらかじめ定義されている必要があります。- ポートは有効な整数でなければならず、引用符、日本語の記号、コメントによって壊れていないことを確認します。
- サーバーが空のファイルを返すと、クライアントが古い設定を保持する場合もあれば、解析完了と表示されてもノードがない場合もあります。
サブスクリプション自体がサーバー側で生成される場合、ダウンロードしたファイルを長期的に手動編集することは通常おすすめしません。次回の自動更新で変更が上書きされます。ローカルのDNS、TUN、ルール設定を保持したい場合は、クライアントのオーバーライド、設定のマージ、スクリプト機能を優先して使用し、クライアントを更新するたびにマージ結果を確認してください。
更新時は直接接続とプロキシのどちらを使うか
サブスクリプションリクエストがどの経路を通るかは、見落とされやすい要素です。サブスクリプションのドメインに直接アクセスできるなら、直結が最も簡単で、既存ノードにも依存しません。プロキシ経由でしかアクセスできない場合は、クライアントの「プロキシ経由で更新」オプションを有効にするか、更新処理で現在のプロキシを使う必要があります。この項目の実装はクライアントによって異なり、システムプロキシを使うものもあれば、現在のカーネルポートを直接呼び出すものもあります。
起動可能な更新経路を優先する
サブスクリプションの更新に、そのサブスクリプション内のノードが必要だと、起動時の依存関係が生じます。利用できる古いノードがローカルにないとサブスクリプションサーバーへ接続できず、更新できないため新しいノードも取得できません。より安全なのは、直近で使えた設定を保持し、更新に失敗したときにローカルファイルを空にしないことです。
| ネットワーク条件 | 推奨する更新経路 | 理由 |
|---|---|---|
| サブスクリプションのドメインに直接アクセスできる | 直接接続 | 現在のノードとプロキシポートへの依存を減らせる |
| 直接接続はタイムアウトするが、現在のプロキシからはアクセスできる | プロキシ経由で更新 | ローカルネットワークからサブスクリプションサイトへの接続問題を回避できる |
| プロキシを有効にすると更新に失敗する | 一時的に直接接続へ戻してテスト | ノード障害、ルールによる誤った振り分け、プロキシ認証の問題を切り分ける |
| 新しいデバイスで、まだ使える設定がない | サービス側が提供する直接接続用の入口を使う | まだ確立していないプロキシ接続への依存を避ける |
注意が必要なのは、サブスクリプション管理のリクエストが必ずしもClashのルールを通るとは限らないことです。クライアント自身のプロセスで直接サブスクリプションをダウンロードするものもあれば、リクエストをローカルのmixed-portへ送るものもあります。ルールでサブスクリプションのドメインをDIRECTに指定していても、更新処理が必ずそのルールを使うとは限りません。クライアントのドキュメント、更新設定、ログに記録された実際の接続経路を基準にしてください。
ローカルポートとシステムプロキシを確認する
一般的な設定ではmixed-portに 7890、外部コントロールポートに 9090 を設定しますが、これはよくある値にすぎず、固定要件ではありません。7890を別のプロセスが使用していると、システムプロキシが古いポートを指したままになり、ブラウザや更新処理が接続に失敗することがあります。まずクライアントの「一般」または「ネットワーク」ページで、現在のHTTP、SOCKS、mixedポートを確認し、OSのプロキシアドレスが一致しているか照合します。
TUNモードは通常、システムプロキシより広い範囲をカバーしますが、TUNを有効にしても無効なリンク、誤ったUA、YAML形式の問題は修復できません。TUNを有効にしたときだけ更新に失敗する場合は、TUNを一時的に無効にし、システムプロキシを残した状態でテストします。そのうえでDNSハイジャック、ルートの除外設定、サブスクリプションのドメインが利用できないプロキシグループへ誤って送られていないか確認します。
自動更新間隔の設定方法
自動更新は頻繁にするほどよいわけではありません。ノードやポリシーの変化が少ないサブスクリプションなら、6時間に1回で通常は十分です。秒単位では 21600 です。変化が速く、サーバーが高頻度のリクエストを許可している場合は1時間、つまり 3600 秒に設定できます。1日1回なら 86400 秒です。15分未満の間隔は不要なリクエストを増やし、429のレート制限を受ける可能性もあります。
| 利用状況 | 推奨間隔 | 秒数 |
|---|---|---|
| 一般的な個人利用で、ノードの変更が少ない | 6時間 | 21600 |
| ノードが頻繁に変更され、サーバーが高頻度更新を許可している | 1時間 | 3600 |
| 設定が長期間安定しており、定期的な同期だけが必要 | 24時間 | 86400 |
| 一時的な調査中 | 自動更新を停止して手動更新にする | 誤ったリクエストの繰り返しを防ぐ |
グラフィカルクライアントでは通常、サブスクリプション編集画面で更新間隔を設定できます。単位は時間、分、秒のいずれかです。変更前に項目の説明を確認し、「時間」単位の入力欄に 3600 を入力しないでください。クライアントによっては、プログラムの実行中だけ時間を計測します。デバイスがスリープした後、復帰時に次回の更新がすぐ実行される場合があります。
mihomoのproxy-provider更新例
設定で proxy-providers を使用している場合、各プロバイダーに個別の interval を設定できます。この値の単位は秒です。以下の例では、プロバイダーファイルを6時間ごとに取得し、10分ごとにヘルスチェックを実行します。ヘルスチェックとサブスクリプション更新は別々のタイマーで動作するため、互いに代用することはできません。
proxy-providers:
service-a:
type: http
url: "https://sub.example.com/provider/demo-token"
path: ./providers/service-a.yaml
interval: 21600
health-check:
enable: true
url: "https://www.gstatic.com/generate_204"
interval: 600interval: 21600 はリモートプロバイダーファイルの更新間隔を制御し、health-check.interval: 600 はノードの可用性チェックだけを制御します。ヘルスチェックを600秒に設定しても、サブスクリプションが10分ごとに再ダウンロードされるわけではありません。逆に、サブスクリプションの更新に成功しても、すべてのノードがヘルスチェックを通過したことにはなりません。
順番に一通りの調査を行う
サブスクリプションの障害は、外側から内側へ確認するのが適しています。まずURLとサーバーのレスポンスを確認し、次にリクエストヘッダーとネットワーク経路、最後に形式とローカルでの読み込みを確認します。こうすれば、URLがすでに無効なのにDNS、TUN、ルールを何度も変更する事態を避けられます。
- エラー時刻を記録する。手動更新を1回実行し、すぐにログでステータスコード、ドメイン、タイムアウト、解析エラーを確認します。
- URLが完全か確認する。サービス側からClashまたはmihomo形式のURLを再コピーし、クライアントで一時的なサブスクリプションを新規作成します。
- 直接接続のレスポンスをテストする。「プロキシ経由で更新」を無効にして1回試し、結果を記録します。
- プロキシ経由のレスポンスをテストする。既知の利用可能なノードに戻し、「プロキシ経由で更新」を有効にして再度試します。
- User-Agentを確認する。サービス側が明確に対応している識別子だけを使い、403、200、レスポンス本文を比較します。
- 内容の形式を確認する。レスポンスがHTML、エラーJSON、空ファイル、互換性のないBase64リストではないことを確認します。
- カーネルとフィールドを確認する。mihomoまたはClashカーネルのバージョンを確認し、未知のフィールド、プロキシグループの参照、YAMLのインデント問題を特定します。
- 設定を再読み込みする。新しいファイルの保存に成功したことを確認し、設定ページで更新後の項目を明示的に選択します。
- 適切な間隔に戻す。通常は6時間、頻繁に変化する場合は1時間に設定し、429が発生しないか確認します。
更新成功後の確認
更新完了後は、緑色の通知だけを確認して終わりにしないでください。まずノード総数とプロキシグループ名を記録し、次に1つのノードを選んで遅延テストを実行します。その後、出口アドレスの確認に適したページへアクセスし、Clashの接続ログで想定したルールに一致していることを確認します。クライアントが更新成功と表示しているのに、ノード一覧とファイルの更新日時が変わらない場合は、無効なサブスクリプション項目を更新していないか確認します。
自動更新が時々失敗する一方、手動更新はすぐ成功する場合、デバイスがスリープから復帰した直後、ネットワークの準備が整っていない、プロキシカーネルの起動がサブスクリプションタスクより遅い、サーバーが一時的にレート制限している、といった原因が考えられます。更新間隔を少し延ばし、失敗時のログを保存してください。特定のネットワーク環境で毎回失敗する場合は、更新間隔をさらに短くするのではなく、直接接続、システムプロキシ、TUNの3経路を比較します。
最終的に安定した状態では、4点を満たしている必要があります。サブスクリプションURLが有効であること、更新リクエストの経路が明確であること、レスポンス内容が現在のカーネルと互換性を持つこと、自動更新の頻度がサービス側の制限に適合していることです。この4項目を個別に確認すれば、サブスクリプション更新の失敗は通常、具体的な層まで特定できます。クライアントを再インストールしたり、設定をすべて消去したりする必要はありません。