目次
Clash サブスクリプションのインポートに失敗したら、リンク切れと読み取れない形式を先に区別する
クライアントは「更新失敗」を一つの通知にまとめがちですが、リンク切れ、Invalid YAML、unsupported field では対処方法がまったく異なります。エラー原文、HTTP ステータス、行番号を保存し、失敗した段階を先に判断してください。実際にはログインページであるファイルを YAML エディターで修正せずに済みます。
二種類の失敗を示す証拠
| 動作 | 説明 | 最初に行うこと |
|---|---|---|
| HTTP 401、403、404、またはタイムアウト | リモートリクエストから利用可能な設定をまだ取得できていない | token、アドレス、ネットワーク、サーバー側の状態を確認する |
| HTML、ログインページ、またはプランに関する案内が返る | URL にはアクセスできるが、内容が YAML ではない | ウェブページのアドレスではなく、サブスクリプション用エンドポイントをコピーしたことを確認する |
| mapping values are not allowed | YAML の構造またはインデントが不正 | 報告された行と上位階層のインデントから箇所を特定する |
| unknown field、cannot unmarshal | 構文は正しくても、現在のコアがフィールドまたはデータ型を受け入れない可能性がある | コアのバージョンと公式フィールドを確認する |
完全なサブスクリプションアドレスを公開せず、レスポンスヘッダーと冒頭の内容を確認する
自分で管理するターミナルまたはブラウザの開発者ツールだけで、サブスクリプションのレスポンスを確認します。ステータスは成功を示し、本文の先頭は YAML 設定または provider データの形式である必要があります。<!DOCTYPE html>、ログインフォーム、JSON エラー、「通信量を使い切った」という案内であってはいけません。
サブスクリプション URL には、設定を直接取得できる token が含まれることがよくあります。スクリーンショットではクエリパラメーターを隠し、curl コマンドを公開チケットへ貼り付けないでください。リンクがすでに漏えいした場合は、古いレスポンスの調査を続ける前に、サービスの管理画面でリセットします。
# URL 中含私密 token，不要复制输出到公开位置
curl -I "https://example.invalid/subscription?token=REDACTED"
curl -sS "https://example.invalid/subscription?token=REDACTED" | headYAML で報告された行は、その上位構造がすでに壊れている結果であることが多い
YAML はインデントで階層を表します。Tab、欠けたコロン、閉じていない引用符、誤ったリスト記号があると、パーサーが次の行で初めてエラーを報告する場合があります。line 48 column 7 と表示されたら、48 行目だけでなく、属しているキーと前の項目が完結しているかも上方向へ確認してください。
プロキシ名にコロン、番号記号、特殊文字が含まれる場合は引用符で囲みます。同じ階層で異なる数の空白を混在させないでください。元のファイルを残してコピーを編集し、一回に一つのエラーだけを修正して、再テスト後に次へ進みます。
# 正确：proxies 是列表
proxy-groups:
- name: PROXY
type: select
proxies:
- DIRECT
# 错误：proxies 被写成普通字符串
proxy-groups:
- name: PROXY
type: select
proxies: DIRECTYAML を解析できても、Mihomo がそのフィールドを受け入れるとは限らない
汎用 YAML チェッカーが検証するのはテキスト構造だけで、Mihomo のフィールド、型、参照関係は把握していません。unknown field、proxy not found、group not found、未対応のプロトコルが表示された場合は、インデントを変更し続けず、現在のコアのバージョンとドキュメントを確認してください。
クライアントに同梱されたコアのバージョンがサブスクリプション生成ツールより古い場合や、マージオーバーライドでフィールドが誤った位置へ移動する場合があります。まず「バージョン情報」または起動ログで実際のコアを確認し、現在の Mihomo ドキュメントと照合してください。アップグレード前に動作する設定を残し、プロトコル互換性の問題を新たな移行問題へ広げないようにします。
完全な設定、ノード Provider、ルールセットを互いの代わりにはできない
完全な設定には通常、ポート、プロキシグループ、rules が含まれます。proxy-provider ファイルは主にノードを提供し、rule-provider ファイルは domain、ipcidr、classical などの behavior に従ってルール内容を提供します。
provider URL を完全なサブスクリプションとしてインポートすると、ファイル自体が有効な YAML でも、完全な設定に必要なフィールドがないというエラーが表示されます。
反対に、完全な設定を proxy-providers へ入れると、リストの解析時に失敗する場合があります。返された最上位キーとサービス提供者のインポート方法を確認してから、Profile、proxy-providers、rule-providers のどこへ置くかを決めてください。
- 完全な Profile
- 通常は単独で読み込め、proxy-groups、rules などの実行時設定を含みます。
- Proxy Provider
- メイン設定の proxy-providers から参照され、内容は主にノード一覧です。
- Rule Provider
- RULE-SET から使用され、behavior と payload の構造を対応させる必要があります。
コピーでテストし、クライアントによるマージ後の最終ファイルも確認する
最初に元のレスポンスのコピーを保存し、token とノードの認証情報を隠してから編集します。Mihomo のコマンドラインには指定ディレクトリの設定をテストする機能があり、GUI クライアントも通常は読み込み前に検証を実行します。実際に使用中のコアが出力した最初のエラーを基準にしてください。
元のファイルは合格するのにクライアントで失敗する場合は、Merge、Mixin、オーバーライドスクリプト、グローバル設定が生成した最終設定を確認します。サブスクリプション自体ではなく、オーバーライドが削除済みのポリシーグループを参照していたり、同じ最上位キーへ互換性のない二つの内容を生成していたりすることがよくあります。
元のサブスクリプションは読めるが、最終設定で group not found が発生する
主な原因：オーバーライドまたは古いルールが、すでに存在しないポリシーグループを参照している
対処方法：最終設定内でグループ名を検索し、関連するオーバーライドを一時的に無効にします。
サブスクリプションの内容が HTML
主な原因：ウェブページをコピーした、ログインが期限切れになった、または token が無効
対処方法：専用のサブスクリプションアドレスを取得し直し、HTML は編集しません。
Provider だけの更新に失敗する
主な原因：URL、path、behavior、書き込み権限の問題
対処方法：provider の種類に応じて確認し、Profile 全体を作り直しません。
まず読み込める設定へ戻し、その後でエラーの原因を整理する
使用中の設定が壊れた場合は、以前の動作する Profile またはサービス提供者が再生成したクリーンなサブスクリプションへ先に切り替え、ネットワークを復旧します。唯一の本番設定を手作業で変更し続けたり、解析に失敗するファイルを起動時の自動読み込み対象にしたりしないでください。
修正記録には、少なくとも失敗した段階、元のエラー、クライアントとコアのバージョン、解決のために行った操作を残します。次回のサブスクリプション更新後に同じ問題が再発した際、サーバー側の生成内容の変更、クライアントのアップグレード、ローカルオーバーライドによるエラーの再導入を切り分けられます。