目次
サブスクリプションのインポートで長いエラーが出ても、すぐにファイルを編集する必要はありません。設定を取得できていない場合と、内容は取得できても読み込めない場合では、次にすることがまったく異なります。エラー全文と使えるコピーを保存してから、取得した内容が使用中のコアに合うかを判断すると、修正中に元の状態へ戻すことも容易になります。
サブスクリプションはダウンロードと構成解析のどちらで失敗したか
エラーの原文、HTTP ステータス、具体的な行番号を保存し、下の表でダウンロードの問題と設定の解析の問題を区別します。リンクが無効だったり、ログインページが返ったりする場合は、サブスクリプションの取得元を調べます。インデントの誤りやコアが対応しない項目のエラーであれば、ダウンロードした内容を確認してください。
二種類の失敗を示す証拠
| 動作 | 説明 | 最初に行うこと |
|---|---|---|
| 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 を含む場合があります。スクリーンショットやログでは認証情報を隠し、判断できなければ URL 全体を隠してください。curl コマンドを公開の問い合わせに貼り付けないでください。漏えいしていたら、提供元の管理画面でリセットしてから調査を続けます。
# URL 中含私密 token，不要复制输出到公开位置
curl -I "https://example.invalid/subscription?token=REDACTED"
curl -sS "https://example.invalid/subscription?token=REDACTED" | headサービスはリクエストの User-Agent に応じて異なる内容を返すことがあります。クライアントが実際に更新したときの応答を基準にしてください。curl の結果は比較用であり、それだけでサブスクリプションリンクが無効だとは判断できません。
インデントの誤りと非対応フィールドへの対処
YAML はインデントで階層を表します。Tab、欠けたコロン、閉じていない引用符、誤ったリスト記号があると、パーサーが次の行で初めてエラーを報告する場合があります。line 48 column 7 と表示されたら、48 行目だけでなく、属しているキーと前の項目が完結しているかも上方向へ確認してください。
プロキシ名にコロン、シャープ記号、特殊文字が含まれる場合は引用符で囲みます。同じ階層で異なる数の空白を混在させないでください。元のファイルを残してコピーを編集し、一回に一つのエラーだけを修正して、再テスト後に次へ進みます。
# 正确：proxies 是列表
proxy-groups:
- name: PROXY
type: select
proxies:
- DIRECT
# 错误：proxies 被写成普通字符串
proxy-groups:
- name: PROXY
type: select
proxies: DIRECT汎用 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 か、提供元が再生成した正常なサブスクリプションに戻して接続を復旧します。普段使う唯一の設定を手作業で変更し続けたり、解析に失敗するファイルを起動時に自動で読み込むよう設定したりしないでください。
修正記録には、少なくとも失敗した段階、元のエラー、クライアントとコアのバージョン、解決のために行った操作を残します。次回のサブスクリプション更新後に同じ問題が再発した際、サーバー側の生成内容の変更、クライアントのアップグレード、ローカルオーバーライドによるエラーの再導入を切り分けられます。