1. ダウンロード・解析・有効化のどこで失敗したかを確認する

サブスクリプションの更新は、クライアントからURLへリクエストを送信し、応答を読み込んで解析した後、設定をコアに渡して読み込む、という複数の段階を経ます。「更新失敗」はどの段階でも起こり得ます。一方、ノードに接続できない場合は、設定の読み込み後に発生している別の問題かもしれません。まず失敗した段階を特定し、ネットワーク、ファイル、コアのどれを確認すべきか判断しましょう。DNS、ポート、ルールを一度に変更するのは避けてください。

  1. 現在使える設定を残す：「設定」画面で選択中の設定を確認し、ローカル設定とオーバーライドファイルを先にバックアップします。動作中の唯一のサブスクリプションをテスト目的で削除しないでください。
  2. 手動更新は一度だけ行う：更新ボタンを押した時刻を記録し、「ログ」でその前後に出た最初のエラーを探します。最後に表示される「更新失敗」は、単に結果を示している場合がほとんどです。
  3. 実行環境を記録する：「設定」→「このアプリについて」またはクライアントのバージョン情報画面で、クライアント名、バージョン、コアのバージョンを控えます。メニューはクライアントによって異なります。また、GUIクライアントのバージョンとmihomoコアのバージョンは別です。
  4. 失敗する範囲を確認する：特定のサブスクリプションだけか、すべてのサブスクリプションか、あるいは特定の proxy-providers だけかによって、調べる箇所は異なります。
ログの手がかり優先して確認する項目今は避ける操作
no such hostサブスクリプションのドメイン名解決、ネットワークのDNSYAMLのインデント変更
timeout、connection refusedリクエスト経路、プロキシの接続先、サーバーへの到達性何度も削除して再インポートする
HTTP 401、403、429認証状態、アクセス制限、更新頻度更新ボタンを連打する
yaml、unmarshal応答本文、フィールドの型、行番号ノードが無効だと決めつける
unsupported、not foundプロトコルの対応状況、ポリシー名、参照関係ファイルを開けるだけで有効と判断する

2. サブスクリプションURLとHTTP応答を確認する

サービスの管理画面から専用URLをコピーし直す

サービスの管理画面にログインし、サブスクリプションの項目でClashまたはMihomo形式を選んで、URL全体をコピーし直します。ブラウザーのアドレスバーに表示されたアカウントページのURLや、QRコード画像のURLを使わないでください。URL内の ? 以降のクエリパラメーターには認証情報が含まれていることが多く、一部が欠けるとログイン画面やアクセス拒否の応答が返ることがあります。

管理画面で「サブスクリプションURLをリセット」や「トークンをリセット」を実行した場合、古いURLはすぐに無効になることがあります。古いURLへのリクエストを続けず、既存設定のサブスクリプションURLを更新してください。アカウントの有効期限切れで案内ページが返ることもありますが、管理画面の表示とHTTP応答を確認しましょう。403がすべて期限切れを意味するわけではありません。

  • 401：通常は認証に関するエラーです。トークンとサーバー側の要件を確認してください。
  • 403：権限、アクセス元の制限、またはセキュリティポリシーによって拒否された可能性があります。応答本文も確認してください。
  • 404：パスとURLが変更されていないか確認してください。無効なURLを隠すために、このステータスを返すサービスもあります。
  • 429：リクエストが多すぎる状態です。更新を繰り返さず、サーバーの案内や Retry-After に従って待ってください。
  • 5xx：サーバーまたは中継ゲートウェイの障害が考えられます。現在の設定を残して、時間をおいて再試行してください。

HTTP 200でも、使える設定が返ってくるとは限らない

成功を示すステータスコードは、サーバーから応答があったことを示すだけです。本文が <!DOCTYPE html> や <html> で始まる場合、通常はWebページ、ログインページ、認証ページです。ss://、vmess:// などの共有リンクだけ、またはBase64文字列だけが返された場合も、クライアントが現在のインポート方式で必要とするYAML設定一式とは限りません。

ブラウザーではダウンロードできるのにクライアントでは失敗する場合、リクエスト方法の違いも考えられます。ブラウザーはログインCookieを送信したり、別のプロキシ経路を使ったりするほか、サーバーがUser-Agentに応じて異なる形式を返すこともあります。まずサービスの管理画面で対象クライアント向けの入口を確認し、リクエストヘッダーを安易に偽装するのは避けてください。

3. DNS・プロキシ経路・TLSエラーを調べる

サブスクリプションのリクエストは、GUIクライアントまたはコアから送信されます。設定ファイルのDNS設定が、GUIクライアント自身の更新リクエストに適用されるとは限りません。また、システムプロキシを有効にしても、更新機能が必ずそのプロキシを使うとは限りません。サブスクリプション設定のメニューで更新方法を確認し、「直接更新」と「プロキシ経由で更新」が選べる場合は、それぞれ一度ずつ試して比較してください。

利用可能な接続経路を先に確認し、使えない設定に依存した更新を避ける

更新にプロキシが必要なのに現在の設定が使えない場合、循環依存が起こります。まず保存しておいた利用可能な設定に戻してからプロキシ経由の更新を試すか、サブスクリプションのドメインに直接接続できるネットワークで更新してください。TUNモードは通信の経路を変えるため、元の状態を記録してから一時的に無効にし、確認済みのシステムプロキシまたは明示的なプロキシを使って、変更点を一つに絞ってテストできます。

以下のPowerShellコマンドは、URLを対話形式で入力し、直接接続とローカルHTTPプロキシ経由をそれぞれテストします。プロキシの例は 127.0.0.1:7890 です。クライアントの設定画面でHTTPポートまたは混合ポートが実際に7890と表示されている場合にのみ、そのまま使ってください。SOCKS専用のポートをHTTPプロキシとして使うことはできません。

$subscription = Read-Host "サブスクリプションURLを貼り付けてください（この端末内でのみ確認）"
curl.exe --noproxy "*" --location --connect-timeout 10 --max-time 30 --output NUL --write-out "HTTP %{http_code}\n" "$subscription"
curl.exe --proxy http://127.0.0.1:7890 --noproxy "" --location --connect-timeout 10 --max-time 30 --output NUL --write-out "HTTP %{http_code}\n" "$subscription"
Remove-Variable subscription

ここでの10秒は接続タイムアウト、30秒はリクエスト全体の制限時間であり、速度測定の結果ではありません。コマンドは最終的なHTTPステータスのみを表示し、応答本文は出力しません。000 はサーバーのステータスコードではないため、curlのエラーメッセージも確認してください。対話形式で入力すれば実際のURLをコマンド履歴に残さずに済みますが、実行中のプロセス引数はローカルで確認される可能性があります。共有端末での実行は避けてください。

  • 直接接続は失敗し、プロキシ経由は成功：サブスクリプションの更新で想定したプロキシ経路が使われているか確認してください。
  • 直接接続は成功し、プロキシ経由は失敗：ローカルの待ち受けポート、現在の接続先、更新時のプロキシ設定を確認してください。
  • どちらの方法でもドメイン名を解決できない：まずシステムDNSとサブスクリプションのドメインが有効かを確認してください。設定ファイルにDNSサーバーを手当たり次第に追加するのは避けましょう。
  • x509 または証明書の有効期限エラーが発生：システムの日付、タイムゾーン、証明書チェーン、HTTPS検査ソフトを確認してください。企業ネットワークの場合は、管理者に信頼チェーンの確認を依頼しましょう。

4. 行番号を確認してYAMLの構文とフィールドの型を修正する

ログに yaml: line 12 のような解析エラーが出た場合、何らかの内容は取得できていますが、それが設定ファイルだとは限りません。まずHTMLのエラーページではないことを確認し、ローカルのテキストエディターでエラー行とその前後3～5行を確認してください。解析エラーの行番号は「読み取りを続けられなくなった位置」を示す場合があり、コロンや引用符の不足は前の行にあるかもしれません。

よくある形式エラーを4種類確認する

  1. インデントの混在：YAMLのインデントにはスペースを使い、Tabは使いません。同じ階層のインデントをそろえてください。リスト項目の - と子フィールドの位置もそろえます。
  2. 全角記号：フィールド名の後にある全角コロンを半角の : に置き換え、カンマや引用符が入力方式によって置き換わっていないか確認してください。
  3. 値の型が不適切：allow-lan は真偽値、mixed-port はポート番号で指定します。オブジェクト、リスト、文字列を互いに置き換えないでください。
  4. 特殊文字の引用符が不適切：「コロンの後にスペース」または「スペースの後に#」を含む文字列には注意が必要です。URLや名前は対応する引用符で囲んでください。

以下は構造を示すための最小限の設定例です。ローカルの混合プロキシポートだけを用意し、通信を DIRECT に渡します。リモートのプロキシノードは含まれていないため、サブスクリプションの代わりに使っても同じ接続経路にはなりません。有効にしてテストすると通信は直接接続されます。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: "手動選択"
    type: select
    proxies:
      - DIRECT

rules:
  - "MATCH,手動選択"

ローカルファイルを読み込めるのにサブスクリプションのファイルを読み込めない場合は、サブスクリプションの内容、マージスクリプト、オーバーライド設定を引き続き確認します。リモートのサブスクリプションを手動で変更しても、次回の更新で上書きされるのが一般的です。まずコピー上で修正を検証してから、クライアントの永続オーバーライド機能を使うか、サブスクリプション提供元に元ファイルの修正を依頼してください。

5. コアとの互換性と設定の参照関係を確認する

YAMLの構文が正しくても、コアで動作するとは限りません。Clash、Clash Meta（現mihomo）、および各バージョンで対応するプロトコルやフィールドは異なります。古いコアで未対応のプロキシタイプを使うと、unsupported proxy type と表示されることがあります。未知のフィールドが無視される場合もあるため、「解析エラーがない」ことは、機能が反映されたことを意味しません。

具体的なエラーに応じて参照関係を確認する

  • プロキシタイプが未対応：サブスクリプションの出力先と実際に動作しているコアを確認します。コアと互換性のある設定を使うか、クライアントが対応している方法でコアを更新してください。
  • ポリシーまたはプロキシが見つからない：proxy-groups が参照するノードやグループ名、およびルール末尾のポリシー名を確認します。名前は完全に一致させ、大文字・小文字と末尾の空白にも注意してください。
  • ルールセットが見つからない：ルール内の RULE-SET 名は、rule-providers に定義されている必要があります。参照だけをコピーして定義を忘れないようにしてください。
  • 起動時にポートが使用中と表示される：address already in use は読み込みまたは待ち受けの問題です。クライアントが二重に起動していないか確認し、サブスクリプショントークンは変更しないでください。

完全な設定ファイルとプロバイダーファイルも区別しましょう。完全な設定には proxies、proxy-groups、rules などが含まれます。プロキシプロバイダーファイルは通常 proxies のリストを提供し、メイン設定の proxy-providers から参照されます。ルールプロバイダーは宣言した形式に応じてルール内容を提供し、YAML形式では payload が使われることがよくあります。用途が異なるため、拡張子がどちらも .yaml だからといって同じインポート画面に読み込まないでください。

特定のプロバイダーだけにエラーが出る場合は、まずその項目のURL、形式、更新ログを確認します。メインのサブスクリプション更新に成功しても、すべてのプロバイダーが更新されたとは限りません。クライアントのオーバーライド、マージ、スクリプトが最終設定を変更することもあります。コピー上で関連処理を一時的に無効にし、元の設定と最終的な実行設定を比較すると、どの段階で問題が入ったのか特定しやすくなります。

6. 更新成功後、新しい設定が実際に適用されたか確認する

「ダウンロード完了」と「現在有効」は別です。「設定」画面に戻り、選択中のカード、更新時刻、ノード数を確認してから、「プロキシ」画面でポリシーグループの内容が変わったか確認してください。ダウンロードに成功してもコアの検証に失敗した場合、古い設定のまま動作し続けることがあります。更新通知だけで判断せず、読み込みログを確認してください。

  1. 一覧に同じ名前のカードが複数ある場合、現在使用中のサブスクリプションを更新したか確認してください。
  2. 更新後の読み込みログを確認し、設定のロールバック、ポート競合、参照先の不足がないか確認してください。
  3. 「プロキシ」画面で有効なポリシーグループを選び、必要に応じてノードを個別にテストします。すべてのノードの速度測定を、サブスクリプションのダウンロードテストと混同しないでください。
  4. ブラウザーがまだ接続できない場合は、システムプロキシ、TUN、ルールの適用先を確認してください。これは通信の経路制御や送信先の問題であり、サブスクリプションの解析エラーではありません。

結果を確かめるために何度も再起動したり、自動更新間隔を極端に短くしたりしないでください。短時間に繰り返しリクエストすると429が発生し、元の問題が分かりにくくなることがあります。「リクエスト成功 → 検証成功 → 読み込み成功」を一度確認するほうが、更新を何度もクリックするより原因を判断しやすくなります。

7. 問い合わせ前に準備する最低限の情報

ローカルで調べても解決しない場合は、サブスクリプション提供元またはクライアントのメンテナーに問い合わせてください。「インポートに失敗した」だけでは再現が難しいため、以下の情報を添えると、サーバーの応答、クライアントのリクエスト、コアの検証のどこに問題があるか切り分けやすくなります。

  • 環境：OS、クライアントの完全なバージョン、実際に使用しているコアの名称とバージョン。
  • 日時と操作：失敗した日時とタイムゾーン、初回インポート・手動更新・自動更新のどれか。
  • エラー：最初に出た関連ログ、HTTPステータスコード、解析エラーの行番号、機密情報を伏せた前後の内容。
  • 比較結果：直接更新とプロキシ経由の更新結果、ほかのサブスクリプションが正常に動作するか。
  • 設定の処理：オーバーライド、マージスクリプト、プロキシプロバイダー、ルールプロバイダーを有効にしているか。