Clashクライアントの「サブスクリプション更新」は、単一の処理ではありません。完全な更新には通常、サブスクリプションURLの読み取り、ネットワーク要求の開始、リモートコンテンツの受信、設定形式の判定、YAMLの解析、ローカルファイルへの保存、設定の再読み込みが含まれます。どこか一つでも失敗すると、画面上では更新のタイムアウト、ダウンロード失敗、設定が無効、ノード数が変わらない、更新後に接続できないといった症状として現れます。対処する際は、更新を何度もクリックしたり、すぐに既存設定を削除したりせず、まずどの層で問題が起きているかを特定しましょう。
サブスクリプション更新の実際の流れを理解する
一般的なGUIクライアントでは、サブスクリプションを「設定」「設定ファイル」「リモート設定」「Profile」などと呼びます。画面でURLを追加すると、クライアントは応答内容を自身の設定ディレクトリに保存し、その後Clashまたはmihomoコアに読み込ませます。ダウンロードと定期タスクはクライアントが担当し、設定の解釈とプロキシ、プロキシグループ、ルール、DNS、TUNなどの実行モジュールの構築はコアが担当します。役割が異なるため、「コアは正常に動作している」からといって、クライアントがリモートサブスクリプションをダウンロードできるとは限りません。逆の場合も同様です。
問題の位置を特定するには、更新処理を次の5段階に分けて考えます。
- アドレスの読み取り：クライアントが保存済みのサブスクリプションURLを取得し、HTTPまたはHTTPSアドレスとして使用できる形式か確認します。
- ネットワーク要求：システムDNSでサブスクリプションのドメインを解決し、接続を確立して、現在のネットワーク環境に応じた要求を実行します。
- コンテンツの返却：サブスクリプションサービスがYAMLや互換性のある設定テキスト、または変換が必要なノードデータを返します。
- 設定の解析：クライアントまたはコアが、インデント、フィールドの型、プロキシグループの参照、ルール形式、プロキシプロトコルのパラメーターを確認します。
- 保存と読み込み：新しいファイルで旧キャッシュを上書きまたは置き換え、クライアントが更新後の設定に切り替え、コアが関連モジュールを再起動します。
2段階目でエラーが起きると、接続タイムアウト、ドメイン解決失敗、証明書接続エラーなどが表示されます。3段階目では、ログインページやエラーメッセージ、空の内容がダウンロードされることがあります。4段階目の失敗では、YAML解析エラー、未対応フィールド、存在しないプロキシグループの参照などが表示されます。5段階目の失敗は、ファイル権限、設定ディレクトリ、ディスク容量、使用中の古いキャッシュに関係している可能性が高くなります。
サブスクリプションURLと返却内容を確認する
URLが完全で、現在も有効か確認する
サブスクリプションURLをコピーする際は、クエリパラメーター、アクセストークン、URL末尾の内容を欠落させないようにします。サービスによってはアカウントごとに専用URLが発行されるため、手動で途中まで切り取るとドメインにはアクセスできても、エラーページしか取得できません。URLの前後にスペース、改行、日本語の句読点が混入していないかも確認してください。サブスクリプションサービスでアクセストークンが再発行された場合は、クライアントに保存された古いURLも置き換える必要があります。
サブスクリプションの期限切れ、通信量の上限到達、アカウント状態の変更、サーバーのメンテナンスなどにより、以前のURLが設定ではない内容を返すことがあります。この場合、クライアントがサーバーの案内を認識できず、解析失敗として報告することもあります。信頼できるブラウザーからURLへアクセスし、テキストのダウンロードが始まるか、ログインページ、認証ページ、ステータス案内ページへ転送されるかを確認できます。サブスクリプションURLにはアカウント情報が含まれることが多いため、スクリーンショット、フォーラム、公開ログに載せないでください。
Clash設定と汎用サブスクリプションを区別する
完全なClash設定には、通常プロキシ一覧、プロキシグループ、ルールなどの構造が含まれます。一方、ノード一覧をエンコードしたデータだけを返し、サーバー側またはローカルツールでの変換が必要なサブスクリプションもあります。対応形式はクライアントのインポート処理によって異なります。他のプロキシソフトで認識できるURLでも、Clash YAMLとしてそのまま読み込めるとは限りません。
設定内容は少なくともYAMLの基本構文に準拠している必要があります。インデントを統一し、リスト項目とキー・値の階層を正しく保ってください。ノード名がプロキシグループから参照される場合、その名前も完全に一致していなければなりません。mihomoの拡張フィールドを使用する場合は、該当フィールドに対応したコアバージョンを使います。古いClashコアでは、未対応のプロトコル、ルールタイプ、DNSオプションに遭遇すると、読み込みを拒否することがあります。
proxies:
- name: "ノード A"
type: socks5
server: 192.0.2.10
port: 1080
proxy-groups:
- name: "ノード選択"
type: select
proxies:
- "ノード A"
- DIRECT
rules:
- MATCH,ノード選択上記の構造は参照関係を説明するためのものです。プロキシグループ内の「ノード A」はプロキシ名と一致し、最後のルールのターゲットは定義済みのプロキシグループまたは有効なポリシーでなければなりません。実際のサブスクリプションは通常サーバー側で生成されるため、エラーを消す目的だけで不明なフィールドを削除するのは避けてください。認証、DNS、ルーティングの仕組みを壊す可能性があります。
ネットワーク、システムプロキシ、DNS経路を確認する
サブスクリプションを更新するには、まずサブスクリプションをホストするドメインへアクセスする必要があります。現在の設定がすでに無効で、クライアントの更新要求も現在のプロキシに依存している場合、旧ノードで接続できないため新しいノードを取得できないという循環が起こります。対処時は一時的に直接接続へ切り替えるか、利用可能と確認済みの設定を使って一度更新してください。一部のクライアントには「プロキシ経由で更新」や「システムプロキシを使用」といった項目があります。サブスクリプションのドメインが現在のネットワークから到達可能かどうかに応じて選択し、特定のモードを長期間固定しないようにします。
基本ネットワークを確認してからプロキシチェーンを調べる
- ブラウザーで一般的なWebサイトにアクセスできることを確認し、Wi-Fi認証、通信断、モバイルネットワークの制限を切り分けます。
- システムの日付とタイムゾーンを確認します。時刻が大きくずれていると、HTTPS接続の検証に失敗することがあります。
- 一時的に無効なシステムプロキシを停止し、サブスクリプション要求を直接接続で完了できるか確認します。
- サブスクリプションのドメインにプロキシ経由でしかアクセスできない場合は、利用可能と確認済みのノードを選択してから、もう一度更新します。
- ファイアウォール、セキュリティポリシー、ローカルネットワークのDNSが、クライアントプロセスのネットワークアクセスを妨げていないか確認します。
TUNモードを有効にすると、サブスクリプション要求が仮想NIC、ルーティングルール、DNSハイジャックの影響を受けることがあります。TUN設定に問題がある場合、ブラウザーとクライアントプロセスで挙動が異なる可能性があります。ブラウザーは既存の接続や独自のDNSキャッシュによってアクセスできても、更新プロセスだけがドメインを解決できないことがあります。その場合は一時的にTUNを停止し、通常のネットワーク経路に戻して試してください。停止後に更新できたなら、TUNのルート除外、DNSのリッスンアドレス、システム権限、他のVPNソフトによる仮想NICの使用状況を確認します。
DNS障害は、ドメインを解決できない一方で、キャッシュ済みの別サイトには正常にアクセスできるように見えることがあります。まず信頼できるシステムDNSへ切り替え、OSのDNSキャッシュを削除してからクライアントを再起動してください。fake-ipを有効にしている場合、クライアントの起動初期にサブスクリプションのドメインを解決できるよう、ブートストラップリゾルバーも確認する必要があります。リモートDNSへのアクセス自体が、まだ確立していないプロキシに依存している場合も、名前解決の依存関係が循環することがあります。
解析エラー、古いキャッシュ、保存失敗に対処する
ネットワーク要求が成功したからといって、更新が完了したとは限りません。新しいファイルを取得できていても、構文や互換性の問題によって、クライアントが古い設定を使い続けることがあります。更新時刻だけが変わり、ノード、プロキシグループ、通信量の情報が変化しない場合は、この可能性が高いです。更新時刻付近のクライアントログを確認し、ダウンロード状態、保存先、解析行番号、コアからの返却情報を重点的に確認します。
エラー行番号をもとにYAMLを確認する
ログに行番号が示されている場合は、その行から上に向かって、同じ階層のインデントと引用符を確認します。YAMLエラーは、コロンの後のスペース、リスト項目のインデント、閉じられていない引用符、タブ文字が原因になることがよくあります。表示された位置が必ずしも根本原因の行とは限りません。前の行の文字列が閉じられていないため、次の行で解析が停止することもあります。
サブスクリプションサービスが設定を自動生成している場合は、まず再取得するか、サブスクリプション提供元へ修正を依頼してください。同期しにくい手動コピーを長期間管理するのは避けます。カスタムルールを追加する必要がある場合は、クライアントのオーバーライド、マージ、スクリプト機能を使い、個人ルールとリモートサブスクリプションを分離します。こうすればサブスクリプション更新でローカル変更が直接上書きされず、エラーがリモート設定由来かローカル拡張由来かも判断しやすくなります。
キャッシュは手順を守って削除する
クライアントによって設定の保存場所や命名方法は異なるため、場所の分からないディレクトリでファイルを一括削除してはいけません。安全な手順は、まず現在のアクティブ設定名を記録して使用可能なコピーをエクスポートし、次にクライアント画面から失敗したサブスクリプションを削除して再追加することです。それでも改善しない場合はクライアントを終了し、バックグラウンドのコアが停止したことを確認してから、クライアントのドキュメントに従って対象キャッシュファイルを処理します。再起動後は元のサブスクリプションだけをインポートし、すぐにオーバーライドルールを重ねないでください。
保存失敗、権限不足、ファイル使用中などのログが出る場合は、設定ディレクトリに書き込み権限があるか、ディスク容量が残っているか、セキュリティソフトがクライアントのファイル変更を阻止していないか確認します。ポータブル版クライアントを保護されたディレクトリに置くと、古い設定は読み取れても更新を保存できないことがあります。アプリケーションと設定を現在のユーザーが書き込める場所に置くほうが、管理者権限で常用するより保守しやすいのが一般的です。
自動更新間隔はどのように設定するか
更新頻度を上げても、接続が安定するとは限りません。サブスクリプションは通常、ノード、ルール、アカウント情報に変更があったときだけ再取得すれば十分です。間隔が短すぎると、サーバーへの要求、モバイル通信量、クライアントの起動回数が増え、アクセス頻度制限にかかる可能性もあります。長すぎるとノードの調整を見逃すことがあります。多くの個人用デバイスでは、6時間から24時間の間で選び、サブスクリプションサービスの更新頻度に合わせて調整するのがおすすめです。
- 6時間：ノードの変更が多く、デバイスが長時間オンラインで、ルールやポリシーの変更を素早く反映したい場合に適しています。
- 12時間：更新の速さと要求回数のバランスがよく、デスクトップクライアントの標準設定に適しています。
- 24時間：ノードの変更が少ない場合や、モバイルデバイス、決まった時間帯だけ使用する環境に適しています。
- 手動更新：使用頻度の低い予備端末に適していますが、接続に問題があるときはサブスクリプションの有効期限も確認してください。
クライアントに設定サブスクリプションの更新間隔が用意されている場合は、まず画面上で設定してください。このタイマーはクライアントの機能であり、通常はクライアントが起動しているときだけ実行されます。パソコンのスリープ中やアプリ終了中に実行できなかったタスクが、復帰後すぐに再実行されるとは限りません。具体的な動作はクライアントの実装によって異なるため、更新時刻とログで確認できます。
proxy-providerのintervalは設定全体の更新とは異なる
mihomoと互換性のある設定では、proxy-providersを使ってリモートURLからプロキシのグループを読み込めます。ここでのintervalは通常秒単位で、プロキシプロバイダーを更新する間隔を指定します。更新されるのはproviderの内容であり、GUIクライアントがProfile全体を再ダウンロードする処理とは異なります。設定全体に含まれるルール、DNS、プロキシグループの構造は、providerの更新だけでは自動的に置き換わりません。
proxy-providers:
remote-nodes:
type: http
url: "https://sub.example.net/clash/nodes.yaml"
path: ./providers/remote-nodes.yaml
interval: 21600
health-check:
enable: true
interval: 600
url: "https://www.gstatic.com/generate_204"例にある21600秒は6時間です。health-check.intervalはヘルスチェックの間隔で、プロキシの利用可能性を確認するだけであり、サブスクリプションの更新の代わりにはなりません。ヘルスチェックを極端に頻繁にすると、探査要求が継続的に発生します。ノード数とデバイスのリソースを考慮して設定してください。例のドメインとアドレスはフィールド構造の説明用です。実際には、サブスクリプションサービスが提供するアドレスと、現在のネットワークに適したテストURLを入力します。
同じクライアントでProfileの定期更新とproviderの定期更新を同時に有効にすると、2つのタスクは別々に実行されます。Profile全体の更新でローカルのprovider定義が上書きされる可能性があるため、変更前に設定の出所を確認してください。カスタムproviderを長期的に追加する場合は、クライアントが対応するオーバーライド機能を使うほうが安全です。
保守しやすい更新スケジュールを作る
適切な自動更新設定は、時間の数値を入力するだけでは不十分です。失敗時の対処方法もあらかじめ決めておきましょう。直近の正常に読み込めた設定を残し、1回の不正な応答で現在の接続を壊さないことが重要です。解析に成功してから設定を切り替えるクライアントもあり、これは比較的安全な流れです。クライアントがファイルを直接上書きする場合は、事前にコピーを保存しておく必要があります。
日常のメンテナンスは、次のように進められます。
- 普段使うデバイスの自動更新を12時間または24時間に設定し、まず1週間の更新ログを確認します。
- サブスクリプションサービスの変更が実際に多い場合だけ6時間へ短縮し、数分おきの高頻度更新は避けます。
- DNS、TUN、ルールのオーバーライドを大幅に変更する前には、手動更新を行い、基本設定が読み込めることを確認します。
- 更新に失敗したらログの時刻を記録し、アドレス、ネットワーク、応答内容、解析、保存の順に確認します。
- 長期間使っていなかったデバイスを再び使うときは、まず設定を更新してから、ノード自体が無効かどうかを判断します。
モバイルデバイスではバックグラウンド制限も考慮してください。システムがクライアントプロセスを停止し、定期タスクが予定どおり実行されないことがあります。アプリに戻った際に手動で一度更新するほうが確実です。ルーターや透過型ゲートウェイは常時稼働するため、固定周期の更新に向いていますが、ネットワーク利用のピーク時に設定全体を再読み込みするのは避けてください。更新でコアが再起動する場合は、深夜や通信量の少ない時間帯に設定し、失敗しても前回の設定が保持されることを確認します。
Clashのサブスクリプション更新失敗を素早く確認するチェックリスト
画面に大まかなエラーしか表示されない場合は、次の順番で対処します。よくある変更の小さい問題から先に切り分け、その後で設定ファイルやシステムディレクトリを確認するため、不要な再インストールを減らせます。
- サブスクリプションURLが完全か確認し、アクセストークン、クエリパラメーター、プロトコルヘッダーが欠落していないか確認します。
- アカウントの状態、サブスクリプションの有効期限、サーバーの状態を確認し、返却内容が本当に設定であるか調べます。
- 現在のネットワークでサブスクリプションのドメインを解決・訪問できるかテストし、必要に応じて直接接続と利用可能なプロキシをそれぞれ試します。
- TUNまたは無効なシステムプロキシを一時的に停止し、ルーティングの循環やDNS依存の問題を切り分けます。
- 更新ログを確認し、要求のタイムアウト、HTTP応答異常、YAML解析エラー、保存失敗を区別します。
- 使用中のコアが、サブスクリプション内のプロトコル、ルールタイプ、mihomo拡張フィールドに対応しているか確認します。
- 古い設定をエクスポートしてからサブスクリプションを再追加し、明確なキャッシュファイルについてはクライアントのドキュメントに従って処理します。
- 更新後に設定時刻、ノード数、プロキシグループを確認し、コアが再読み込みされていることを確認します。
複数のデバイスで同時にサブスクリプション更新に失敗する場合は、URL、アカウント状態、サーバー側の内容に問題がある可能性が高くなります。1台だけで失敗する場合は、そのデバイスのネットワーク、DNS、クライアントバージョン、設定ディレクトリ、システム権限を重点的に確認してください。同じURLをダウンロードできるのに特定のコアだけ読み込めない場合は、更新間隔を調整し続けるのではなく、コアの互換性とログに記録された具体的なフィールドを比較します。
安定したサブスクリプションの運用では、「設定を取得すること」と「設定を検証すること」を分けて考えます。自動更新は新しい内容を定期的に取得する機能であり、その内容を実際に使えるかどうかは解析と読み込みの結果で決まります。適度な更新間隔を選び、いつでも戻せる設定を保存し、要求の流れに沿って一つずつ確認すれば、Clashのサブスクリプション更新失敗の多くを迅速に特定できます。