Clash サブスクリプション更新失敗の対処法:5つの原因と自動更新間隔の設定

サブスクリプション更新はなぜ失敗するのか:まず全体の流れを理解する

Clash 系クライアント(Clash、Clash Meta カーネルの mihomo、および各種 GUI フロントエンド)は本質的にノードを生成しません。サブスクリプションアドレスに対して HTTP(S) リクエストを送り、リモートから返される設定ファイルのテキストを取得し、それをローカルで解析してノードリスト・プロキシグループ・ルールに変換しているだけです。この点を理解することが重要で、「サブスクリプション更新失敗」という言葉の裏には、「リクエストが送信されていない」「リクエストが遮断された」「リクエストは成功したが内容が不正」という 3 つの全く異なる段階が隠れており、対処の方向もそれぞれ完全に異なります。むやみにクライアントを再起動したり再インポートしたりするのは、そのうち一種類の問題を運良く解決しているだけで、別の原因のときには依然として効果がありません。

本稿ではよくあるサブスクリプション取得失敗を 5 種類に分類し、「経路の問題」から「内容の問題」までの順序で、それぞれ再現可能な判断方法を示します。「ネットワークを確認してください」というような曖昧な説明はしません。

第一種:サブスクリプションリンクの期限切れ、またはサービス提供者によるリセット

これは最もよくある、かつ最も見落とされやすいケースです。多くの機場(サブスクリプション提供サービス)のリンクには有効期限付きのトークンが含まれており、プランの期限切れ、アカウントのリセット、あるいはサービス提供者がリンクのプレフィックスを能動的にローテーションした場合、旧リンクは標準的なサブスクリプションテキストの代わりに 401、403、あるいは HTML エラーページを直接返します。この場合クライアントは通常「更新失敗」または「解析失敗」と表示しますが、エラー内容はあいまいなことが多いです。

判断方法は単純です。サブスクリプションリンクをそのままブラウザのアドレスバーに貼って直接アクセスしてみてください。Base64 でエンコードされた文字列や proxies: という文字を含む YAML テキストが表示されれば、リンク自体は生きています。ログインページや 404 ページ、あるいは「プランが期限切れです」といった表示が出た場合は、問題はサービス提供者側にあり、クライアント自体には責任がなく、再インストールやクライアントの変更をしても無意味です。サブスクリプション提供者の管理画面に戻ってリンクを再取得するしかありません。

第二種:ローカル環境またはローカルネットワークがリクエストを遮断している

サブスクリプションアドレス自体は有効ですが、リクエストがサービス提供者に到達する前に遮断されているケースです。よくあるシナリオとしては、企業や学校のネットワークが特定のドメインに対して DNS ポイズニングやポート制限をかけている場合、同一端末で競合する別のプロキシソフトが動作していてシステムプロキシ設定を占有している場合、セキュリティソフトがサブスクリプションのドメインを不審なアドレスと誤判定して送信リクエストを黒くフィルタリングしている場合などが挙げられます。この種の問題の典型的な特徴は、クライアントのエラーメッセージに通常「接続タイムアウト」「ホストを解決できません」「SSL ハンドシェイク失敗」といった明らかにネットワーク層の文言が含まれることで、「解析失敗」のような内容層の文言ではありません。

• まず現時点で利用可能なノードに接続済みかどうかを確認してください。クライアント自体がプロキシ未接続の状態で、サブスクリプションアドレスがプロキシ経由でしかアクセスできない場合、「プロキシがないとサブスクリプションが取得できず、サブスクリプションがないとプロキシが構築できない」というデッドロックに陥ります。この場合は一時的に既知の利用可能なノードを手動で追加し、接続後にサブスクリプションを更新してください。
• 同一端末に他のプロキシツールや VPN クライアントが同時にインストールされていないか確認してください。システムプロキシ設定が上書きされることはよくある競合の原因です。
• DNS を切り替えて(例えば一時的にパブリック DNS に切り替えて)再試行し、ローカル DNS ポイズニングの可能性を除外してください。

第三種:User-Agent 検証によるサブスクリプション拒否

多くのサブスクリプション提供サービスは、サーバー側でリクエストヘッダー内の User-Agent フィールドを検証し、「クライアントが正常に設定を取得している」のか「ブラウザやスクリプトで悪意的にトラフィック統計を回している」のかを区別しています。クライアントが送信する User-Agent がサービス提供者のホワイトリストに含まれていない場合、サーバー側は空の内容やエラーメッセージを直接返す、あるいは「見た目は成功しているがノードが空」という設定ファイルを返すことがあり、サブスクリプション更新が成功したように見えても実際には使用できない状態になります。

この種の問題を切り分ける手掛かりは、同じサブスクリプションリンクがブラウザでは正常にアクセスできる、curl などのコマンドラインツールで実際のクライアントの User-Agent を付けてリクエストしても正常なのに、クライアントソフト自体では更新が失敗する、または空のノードしか取得できないという状況です。多くの Clash 系クライアントはサブスクリプション設定の中で User-Agent 文字列をカスタマイズできる、あるいはサブスクリプションのインポート時にパラメータを追加できるようになっています。このような場合はクライアントのデフォルト値のままにせず、サービス提供者のドキュメントに記載されている推奨 User-Agent(よく見られる識別子には clash-verge、clash.meta などがあります)に変更してみてください。

curl -A "clash.meta" -x http://127.0.0.1:7890 "https://あなたのサブスクリプションアドレス"

このコマンドを使えばローカルで手動でクライアントのリクエストを模擬でき、User-Agent の問題なのか他の原因なのかを素早く検証できます。この User-Agent ヘッダーを付けると正常な内容を取得でき、付けないと空の内容が返る場合は、サーバー側の UA 検証が働いていることをほぼ確定できます。

第四種:サブスクリプション内容のフォーマットエラーまたはフィールドの非互換

リクエスト自体は成功し、クライアントも応答内容を受け取っているものの、解析時にエラーになるケースです。この種の問題は通常、新しい Clash 派生カーネルに切り替えたとき、またはサービス提供者の設定テンプレートが更新された後に発生します。Clash オリジナルカーネルと Clash Meta(mihomo)カーネルでは一部のプロキシプロトコルのフィールドに対するサポート範囲が完全には一致しておらず、例えば Meta カーネルが追加でサポートしている一部の送出プロトコルパラメータについて、クライアントの下層が旧版のオリジナルカーネルで解析している場合、あるフィールドで直接 YAML 解析エラーになったり、あるプロトコルタイプが認識されないという表示が出たりします。

この種の問題の特徴は、エラーメッセージに具体的なフィールド名や行番号が含まれていることが多く、例えばある type フィールドがサポートされていないことを示す、あるいは YAML のインデント階層に異常があると表示されることです。切り分け方法:

1. 現在使用しているクライアントのカーネルバージョン、およびサブスクリプション提供者のテンプレートが対応する推奨カーネルの種類(オリジナル Clash か Meta/mihomo か)を確認します。
2. クライアントがカーネルの切り替えに対応している場合、Meta カーネルに切り替えてから再取得を試みてください。多くの新しいプロトコルフィールドの問題はこれで直接解決します。
3. サブスクリプション内容の原文をローカルファイルとして保存し、テキストエディタで明らかなフォーマットの断裂(途中で切れている、余分なエスケープ文字があるなど)がないか確認してください。この状況はサービス提供者側の API が一時的に不安定になり返却内容が不完全になったケースでよく見られます。

第五種:リクエスト頻度がサービス提供者のレート制限に触れる

自動更新の間隔を短く設定し過ぎている場合や、短時間に複数のデバイス・複数のクライアントで繰り返し手動更新を押した場合、一部のサブスクリプション提供サービスは同一のサブスクリプショントークンに対するリクエスト頻度を制限し、閾値を超えると応答を直接拒否したり、キャッシュされた古い内容を返したりします。この状況はしばしば間欠的に発生します。更新に失敗した直後、数分後に再試行すると成功するといった具合で、「ネットワークが不安定」と誤判定されやすいですが、実際にはレート制限のポリシーが働いています。

判断方法は最近の更新履歴を振り返ることです。短時間に何度も更新ボタンを押した後に失敗が集中しており、単発で間隔をあけた更新はほぼ成功している場合は、レート制限の問題であるとほぼ確定できます。解決策は自動更新間隔を調整することであり、頻繁な手動再試行を続けることではありません。

合理的な自動更新間隔の設定方法

多くの Clash 系クライアントはサブスクリプションの自動更新間隔の設定を提供しており、単位は通常時間(hour)です。設定の入口は一般的にサブスクリプション管理ページの対応するサブスクリプション項目の「編集」または「詳細」オプションの中にあり、よく見られるフィールド名は「更新周期」または「Update Interval」です。以下は代表的なクライアントでのおおよその位置と推奨値です:

• Windows / macOS GUI クライアント:サブスクリプションリストで対応するサブスクリプションの右側にある編集アイコンをクリックすると、展開して更新間隔の入力欄が表示されます。単位は時間で、12〜24 時間に設定することを推奨します。
• Android クライアント:サブスクリプション管理ページに入り、サブスクリプション項目を長押しまたはタップして編集状態にすると、同様に更新周期のフィールドがあります。デスクトップ側と同じ間隔に保つことを推奨し、同一アカウントで複数端末が同時に更新をトリガーしてリクエストが重複するのを避けてください。
• iOS クライアント:サブスクリプション設定では通常「自動更新」と表記されており、一部のクライアントでは「Wi-Fi 接続時のみ更新」オプションが追加でサポートされています。有効にしておくことを推奨し、電波の弱い環境やモバイルデータ環境で繰り返し取得に失敗するのを避けてください。

間隔設定の基本原則は、6 時間を下回らないことです。短く設定し過ぎるとサービス提供者側のレート制限に触れやすくなるだけでなく、ノード情報がほとんど変化していない状況で無意味なリクエストトラフィックが大量に発生します。逆に長く設定し過ぎる(例えば 48 時間を超える)と、ノードが失効してもなかなか新しいノードに自動的に切り替わりません。多くのサブスクリプション提供サービスが推奨する更新周期は1日1〜2回で、間隔設定に対応させると12〜24時間になります。これは多くのクライアントのデフォルト値でもあり、特別な理由がない限り無闇に短く変更することは推奨されません。

切り分けの順序まとめ

上記 5 種類の原因を一連の切り分け手順につなげると、サブスクリプション更新失敗に遭遇した際は次の順で確認できます:

1. ブラウザでサブスクリプションリンクを直接開き、サービス提供者側のリンクが依然として有効かどうかを確認する。
2. ローカルのネットワークとプロキシ設定に競合がないかを確認し、この時点で外部ネットワークに正常にアクセスできるかを確かめる。
3. コマンドラインツールで実際の User-Agent を付けてテストし、サーバー側の UA 検証による遮断を除外する。
4. クライアントの具体的なエラーフィールドを確認し、カーネルバージョンとサブスクリプションのプロトコルフィールドが非互換かどうかを判断する。
5. 最近の更新履歴を振り返り、更新間隔が短すぎてレート制限に触れていないかを判断する。

5つのステップを順に除外していけば、問題がある具体的な箇所をほぼ特定できます。そのうえで的確に対処すればよく、クライアントを繰り返し再インストールしたり、むやみにサブスクリプション提供サービスを変更したりする必要はありません。