まず、どの段階で失敗しているかを確認する
Clashクライアントの「サブスクリプションを更新」は、1つの処理だけで完了するわけではありません。更新をクリックすると、まず設定に保存されたサブスクリプションURLを読み込み、ネットワーク経由でリモートの内容を取得し、その内容をClash設定として解析できるか確認します。最後に、新しい設定でローカルのコピーを置き換えます。どの段階で失敗しても画面には「更新に失敗しました」とだけ表示されることがありますが、対処法はそれぞれ異なります。
切り分ける前に、現在の設定を削除しないでください。多くのクライアントは、最後に正常取得できたローカルコピーを保持しています。リモート側が一時的に利用できなくても、読み込み済みのノードやルールは通常そのまま使えます。設定を直接削除すると、この利用可能なコピーまで失われ、復旧の手順が増えてしまいます。
エラーメッセージから原因の方向を判断する
| 画面表示またはログのキーワード | 通常、何を示しているか | 優先して確認する項目 |
|---|---|---|
| timeout、deadline exceeded、i/o timeout | 制限時間内にリクエストが完了しなかった | ネットワーク経路、DNS、プロキシ更新の設定 |
| 404、Not Found | サーバーがサブスクリプションURLを見つけられない | リンクの有効期限とコピー漏れ |
| 401、403、Forbidden | 認証情報が無効、またはサーバーにリクエストを拒否された | サブスクリプションの再取得、デバイス数・更新頻度の制限 |
| connection refused | 接続先ポートが接続を拒否した、または更新リクエストが誤ってローカルプロキシへ送られた | 7890、7891などのポートとプロキシ設定 |
| unexpected EOF、connection reset | 通信中に接続が閉じられた | ネットワークの安定性、重複リクエスト、サーバーの状態 |
| YAML、parse、unmarshal | 内容はダウンロードできたが、形式を解析できない | 返却内容が本当にClash YAMLかどうか |
「ダウンロード失敗」か「解析失敗」かを確認する
ダウンロードに失敗した場合、ログにはドメイン、接続、タイムアウト、HTTPステータスコードなどが含まれることが多いです。解析失敗では、YAMLの行番号、フィールド名、型の不一致などがよく表示されます。たとえばリクエストが成功してログインページを返した場合、HTTPステータスは200でも、1行目がHTMLならクライアントは解析段階でエラーになります。
クライアントが設定ファイルを確認できる場合は、ダウンロード直後の内容の冒頭を開いて確認します。標準的なClashまたはmihomoの設定には、通常 proxies、proxy-groups、rules などのフィールドが含まれます。ウェブページのコードやエラーメッセージ、アカウントのログイン画面しか表示されない場合、サブスクリプションURLが返しているのは読み込み可能な設定ではありません。
mixed-port: 7890
mode: rule
proxies:
- name: Example
type: ss
proxy-groups:
- name: PROXY
type: select
rules:
- MATCH,PROXY上記は構造を確認するための簡略化した例にすぎず、実際のサブスクリプションを置き換えるために使うものではありません。サービスによっては、DNS、ルールセット、ヘルスチェック、多数のノード関連フィールドも含まれます。
Clashのサブスクリプション更新がタイムアウトするときの確認手順
タイムアウトは、クライアントが規定時間内に完全な応答を受け取れなかったことを意味します。原因として、サブスクリプションドメインを名前解決できない、直接接続の経路に到達できない、プロキシノードが無効になっている、といった可能性があります。また、「プロキシを使用して更新」が有効なのに、現在のプロキシ自体がまだ利用可能な接続を確立できていない場合もあります。決まった順番で確認すると、ノードを何度も切り替えるより早く解決できることが多いです。
手順1：直接接続とプロキシ更新を個別にテストする
クライアントによって名称は多少異なります。一般的には「設定」→「パラメータ設定」→「サブスクリプション」、または設定画面右上の更新メニューから開きます。「プロキシを使用して更新」「プロキシ経由でサブスクリプションを更新」「Proxy Subscription Update」などのスイッチを探してください。
- まず「プロキシを使用して更新」を無効にし、保存してから手動で1回更新します。これにより、サブスクリプションのリクエストは現在のシステムの直接接続を優先して使用します。
- それでもタイムアウトする場合は、このスイッチを有効にし、利用可能であることを確認したノードを選んで再度更新します。
- 2つの方式を短時間で連続して切り替えないでください。各テストでは現在のリクエストが完了するまで待ち、どちらの方式で成功したかを記録します。
直接接続では失敗し、プロキシ更新では成功する場合、現在のネットワークからサブスクリプションドメインへのアクセスが不安定である可能性が高いです。直接接続は成功するのにプロキシ更新が失敗する場合は、ノード、プロキシグループの選択、ローカルポートを確認します。どちらも失敗する場合は、URL、DNS、サーバーの状態を続けて確認してください。
手順2：ローカルプロキシのポートを確認する
多くのClashクライアントでは、デフォルトで混合ポート 7890 が使われます。HTTPポートは 7890、SOCKS5ポートは 7891 が一般的ですが、これらの値は変更できます。OS、ブラウザ、その他のダウンロードツールが停止済みのポートを参照していると、サブスクリプションのリクエストで connection refused が発生することがあります。
- クライアントの「設定」→「ネットワーク設定」または「ポート」で、現在のMixed Port、HTTP Port、SOCKS Portを確認します。
- システムプロキシに表示されるホストが通常
127.0.0.1になっており、ポートがクライアントの実際の待受ポートと一致していることを確認します。 - 同じポートを使用するClashクライアントを2つ同時に起動しないでください。ポートが競合すると、後から起動したクライアントが待ち受けできないことがあります。
- ポートを変更した直後は、システムプロキシをいったん無効にしてから再度有効にし、OSに正しいアドレスを書き込ませます。
手順3：DNSとネットワーク切り替えの影響を除外する
会社のネットワークからスマートフォンのテザリングへ移行した場合や、Wi-Fiから有線ネットワークへ切り替えた場合、古い接続やDNSキャッシュが一時的に残ることがあります。まずクライアントを完全に終了し、ネットワークを切断してから再接続し、クライアントを起動してテストします。ウィンドウを閉じるだけでは終了したことにならない場合があるため、システムトレイやメニューバーのプロセスが終了していることを確認してください。
ログに no such host、server misbehaving、ドメインの名前解決タイムアウトなどが表示される場合は、まず通常のウェブページを開けるか確認します。TUNモードを有効にしている場合は、一時的にTUNを無効にし、通常のシステムプロキシだけを残してサブスクリプション更新をテストします。TUNを無効にすると復旧するなら、クライアントを再インストールするのではなく、TUNで使用するDNSハイジャック、Fake-IPの範囲、nameserverの設定を確認してください。
404・401・403が表示される場合の対処法
HTTPステータスコードが返るということは、リクエスト自体はサーバーに到達しています。したがって重点はローカルポートではなく、サブスクリプションURLとサーバー側の認証です。404は多くの場合アドレスが存在しないことを示し、401は有効な認証情報が不足していること、403はサーバーがリクエストを理解したうえで内容の提供を拒否したことを示します。
404：サブスクリプションリンクの期限切れまたはコピー漏れ
サブスクリプションリンクには、トークン、クライアント種別、設定形式などを示す長いパスやクエリパラメータが含まれることがあります。チャットアプリでの改行、ブラウザのアドレスバーによる切り詰め、コピー時の末尾文字の欠落などにより、有効なアドレスが404になります。確認時はドメインだけを比べず、https:// からURL全体を1文字ずつ照合してください。
- サブスクリプション提供元の管理ページに戻り、Clashまたはmihomo用のサブスクリプションURLをコピーし直します。
- クライアントの設定一覧で元の設定の編集メニューを開き、URLを置き換えて保存します。
- クライアントがURLの編集に対応していない場合は、リモート設定を新規作成して新しいリンクを読み込みます。
- 新しい設定の更新に成功し、ノードを正常に切り替えられることを確認してから、無効な古い項目を削除します。
コピーし直しても404になる場合は、ブラウザでリンクを直接開いて結果を確認します。YAMLファイルがダウンロードされる、または設定テキストが表示されるならアドレスは有効です。ログインページ、プランページ、サイトのトップページが表示される場合は、サブスクリプションAPIではなく管理ページのURLをコピーした可能性があります。
401・403：認証情報またはアクセス制限
401は、トークンの失効、アカウント状態の変更、サブスクリプションURLのリセットなどでよく発生します。403は認証の問題だけでなく、リクエスト頻度、接続元ネットワーク、デバイス数の制限が原因になる場合もあります。この種の問題は、Clashのプロキシポートを変更しても通常は解決しません。
- サービスのページでサブスクリプションURLを再生成し、過去に保存した古いアドレスを使い続けないようにします。
- 短時間に更新を連続して実行するのをやめ、少なくとも5分空けてから再度テストしてください。
- アカウントの有効期限、通信量の状態、サービス提供元からAPIメンテナンスの告知が出ていないかを確認します。
- ブラウザではダウンロードできるのにクライアントが403を返す場合は、まずプロキシ更新を無効にし、接続元IPが制限されていないか切り分けます。
- 直接接続では403になり、プロキシ更新が正常な場合は、プロキシ更新を維持できます。ただし、遅延の変動が大きい自動ノードではなく、安定したプロキシグループを選んでください。
HTTP 200なのに失敗する場合：設定形式と内容を確認する
HTTP 200は、サーバーが内容を正常に返したことを示すだけで、その内容がClash設定であるとは限りません。ウェブページのエラー画面、Base64形式のノード一覧、他クライアント専用の形式なども200で返され、後続の解析段階で失敗することがあります。
よくある解析エラーを見分ける
| 症状 | 考えられる原因 | 対処法 |
|---|---|---|
| YAMLの先頭付近で構文エラーが発生する | HTML、JSON形式のエラー情報、または途中で切れた内容が返されている | 生のレスポンスを確認し、正しいサブスクリプションURLを取得し直す |
| proxiesまたはproxy-groupsがないと表示される | サブスクリプションが完全なClash設定ではない | Clash、Clash Meta、mihomo形式を選択する |
| unknown fieldと表示される | 設定に、現在のコアが対応していない新しいフィールドが含まれている | クライアントを更新するか、互換形式に切り替える |
| mapping values、bad indentationと表示される | YAMLのインデントが壊れている、または手動編集に誤りがある | リモートの元設定に戻し、タブによるインデントを使わない |
| ダウンロード内容が1行のエンコード文字列だけになっている | 汎用Base64ノードサブスクリプションの可能性がある | サービスページからClash専用リンクを選択する |
mihomoは、ルールセット、プロキシプロバイダー、DNSフィールドについて、以前のClashコアより幅広く対応しています。サブスクリプションがmihomoまたはClash Meta向けと明記されているのに、クライアントが古いコアを使っている場合、フィールドを認識できないことがあります。まず「設定」→「コア」または「バージョン情報」でコアの種類とバージョンを確認し、対応するサブスクリプション形式を選択してください。
エラーを消すために、意味の分からないフィールドを不用意に削除しないでください。一部のフィールドは、ルールプロバイダー、DNSの振り分け、ノードのヘルスチェックを担当しています。削除すると設定を読み込めても、通信経路が変わる可能性があります。対応形式をサポートするクライアントへアップデートするか、サブスクリプションサービスに互換設定を生成してもらうほうが安全です。
自動更新間隔を適切に設定する方法
自動更新は、頻繁にするほどよいわけではありません。ノードやルールは通常、数分単位では変わらないため、短すぎる間隔は重複リクエストを増やし、サーバーのレート制限にもかかりやすくなります。個人のデバイスでは、6〜24時間が一般的な範囲です。
| 利用シーン | 推奨間隔 | 説明 |
|---|---|---|
| 普段使いのパソコン | 12時間 | ノードの変更とリクエスト頻度のバランスがよい |
| たまに起動するノートパソコン | 24時間 | 起動後に1回手動更新すれば、通常は十分 |
| ノードの変化が比較的多い | 6時間 | 数分単位まで短くするのは推奨しない |
| 固定ルールと自前ノード | 24〜72時間 | 設定変更が少ないため、更新頻度を下げられる |
| トラブルを切り分けている | 一時的に自動更新を無効にする | 自動タスクによるログやテスト結果の上書きを防ぐ |
クライアントで更新間隔を設定する
一般的な操作手順は、「設定」または「サブスクリプション」ページを開き、対象のリモート設定の編集メニューで自動更新間隔を時間単位で指定します。秒単位のクライアントでは、6時間は 21600 秒、12時間は 43200 秒、24時間は 86400 秒です。入力欄に分単位と明記されている場合は、それぞれ360、720、1440を入力し、単位を混同しないでください。
設定後は、次回の予定更新時刻が想定どおりか確認します。クライアントによっては、プログラムの実行中だけ定期更新を行い、パソコンの電源が切れている間のタスクをまとめて実行しません。再起動後に1回更新すれば十分で、間隔を極端に短くする必要はありません。
「プロキシを使用して更新」は常に有効にすべきか
有効にするかどうかは、サブスクリプションドメインに実際に接続できるかで決まります。直接接続が長期間安定しているなら、プロキシ更新を無効にするほうが簡単で、現在のノードが無効になったためにサブスクリプションを更新できなくなる事態も避けられます。サブスクリプションURLがプロキシ必須、または直接接続が頻繁にタイムアウトする場合に限り、有効のままにするのが適しています。
- 直接接続で安定して更新できる：プロキシ更新を無効にし、自動更新間隔を12時間または24時間に設定する。
- 直接接続がタイムアウトし、プロキシが安定している：プロキシ更新を有効にし、更新通信を安定したプロキシグループ経由にする。
- ネットワークを頻繁に切り替える：まず直接接続を使い、失敗したときだけ手動でプロキシ更新に切り替える。
- 現在すべてのノードが使えない：プロキシ更新を無効にし、リクエストが無効なプロキシへ送られるのを防ぐ。
修復後、設定が本当に反映されたか確認する
画面に「更新成功」と表示されても、新しいファイルが保存されたことしか示していない場合があります。クライアントが実際にその設定を読み込んだことも確認してください。ダウンロード後に自動で切り替わるクライアントもあれば、古い設定を使い続け、手動で新しい項目を選ぶ必要があるクライアントもあります。
- 設定一覧で「最終更新」時刻を確認し、直前の操作時刻と一致しているか確認します。
- 更新後の設定を選択し、コアの再読み込みが完了するまで待ちます。
- プロキシ画面を開き、ノード数、プロキシグループ名、ルールに想定した変化があるか確認します。
- よく使うノードで遅延テストを1回実行します。遅延値はテスト先に到達できることを示すだけで、すべてのウェブサイトにアクセスできることを意味しません。
- 「ルールモード」のまま、直接接続すべき宛先とプロキシ経由にすべき宛先へ1つずつアクセスし、振り分け結果を確認します。
- 実行ログを確認し、解析エラー、DNSループ、接続拒否が継続的に発生していないことを確認します。
それでも失敗するときの最終チェックリスト
- サブスクリプションURLをサービスページからコピーし直し、前後にスペース、改行、欠落した文字がないか。
- ブラウザでアドレスを開いたとき、ログインページではなく設定テキストまたはダウンロードファイルが返るか。
- 直接接続とプロキシ更新をそれぞれテストしたか。同じ経路だけを繰り返していないか。
- システムプロキシのポートがクライアントの実際の待受ポートと一致しているか。7890または7891を他のプログラムが使用していないか。
- TUNを無効にすると更新できるか。できる場合は、DNSハイジャックとTUNスタックの設定を続けて確認する。
- サブスクリプション形式がClash、Clash Meta、mihomoのコアと一致しているか。
- 自動更新間隔が短すぎないか。リクエストの連続実行で403や一時的な制限が発生していないか。
- 更新成功後に新しい設定を手動で選択し、コアの再読み込みが完了したことを確認したか。
サブスクリプション障害を効率よく切り分けるには、まずステータスコードでネットワーク、認証、形式の問題を分け、直接接続とプロキシという2つの更新経路を比較します。タイムアウトならネットワークとプロキシ更新の設定、404なら完全なリンクの再取得、401または403なら認証とリクエスト頻度、解析エラーなら返却内容とコアの形式を確認します。自動更新を6〜24時間に設定し、直近で使えた設定を残しておくと、同じ障害の影響を抑えやすくなります。