サブスクのインポートエラーは、まず失敗した段階を切り分ける
Clash Verge でサブスクをインポートするときのエラーは、発生段階によって「ダウンロード失敗」「解析失敗」「YAML検証失敗」「コア読み込み失敗」の4種類に分けられます。原因の切り分け方がまったく異なるため、先に段階を特定してから対処すると大幅に時間を節約できます。
| エラー段階 | 代表的なメッセージ | 考えられる主な原因 |
|---|---|---|
| ダウンロード段階 | 「ダウンロード失敗」「サブスク内容の取得に失敗」 | リンク切れ、通信遮断、認証エラー |
| 解析段階 | 「解析失敗」「有効な YAML ではありません」 | HTMLページの返却、Base64 デコード異常 |
| 検証段階 | 「YAML 構文エラー:12行目」 | インデントミス、引用符の閉じ忘れ、全角記号 |
| 読み込み段階 | 「フィールド非互換」「設定の読み込みに失敗」 | mihomo と旧版 Clash のフィールド差異 |
切り分け方:Clash Verge の「サブスク」ページを開き、「更新」を一度押して、エラーが出るタイミングを確認します。プログレスバーが完了する前に失敗するならダウンロードの問題、ダウンロード完了直後にエラーになるなら解析または検証の問題、設定は読み込めるのにコアの起動に失敗するならフィールド互換性の問題です。以下、4つの節で順に解説します。
リンクの到達可否:期限切れ・認証・通信遮断
まず、サブスクリンクを全文コピーしてブラウザのアドレスバーに直接貼り付けてアクセスしてください。これが最も手っ取り早い切り分けです。
proxies:で始まるテキストが返る:リンクは正常。問題はクライアント側- 404 または「リンクが存在しません」が返る:サブスクは失効済み。プロバイダーのパネルで再生成
- ログインページやプラン期限切れの案内が返る:アカウントの状態に問題。まず更新またはサブスクのリセット
- 読み込み中のまま、またはタイムアウト:ローカルネットワークからサブスクサーバーまでの経路が不通
ブラウザでは開けるのにクライアントだけダウンロードに失敗する場合は、コマンドラインで確認します。Windows は PowerShell、macOS はターミナルを開いて次を実行してください:
curl -v -L "サブスクリンク" -o sub.yaml -w "%{http_code}\n"注目すべきは HTTP ステータスコードとレスポンスボディの2点です。
| ステータスコード | 意味 | 対処 |
|---|---|---|
| 200 | サーバーが正常に返答 | クライアントのサブスク設定を確認 |
| 401 / 403 | 認証エラー、または UA がブロックされている | リンクをコピーし直し、User-Agent をカスタム設定 |
| 404 | サブスクが削除または期限切れ | プロバイダーのパネルで再生成 |
| 429 | リクエストが過剰 | 数分待ってから再試行 |
| 000 / タイムアウト | 接続がリセットされた | DNS・ファイアウォール・プロキシ経路を確認 |
一部のプロバイダーは User-Agent を検証しており、クライアントのデフォルト UA が異常なトラフィックと判定されることがあります。Clash Verge のサブスク編集パネルで User-Agent をカスタマイズし、一般的なブラウザの UA 文字列を設定すれば回避できます。
DNS 汚染でもサブスクの更新に失敗することがあります。サブスクのドメインが誤ったアドレスに解決されると、ブラウザはシステムプロキシ経由のため正常でも、クライアントの直接接続はタイムアウトします。サブスクのドメインを「設定」→「パラメータ設定」→「システムプロキシ」の直接接続ルールに追加するか、利用可能なノードに一時的に切り替えてから更新してください。
サブスクを更新する前に、現在少なくとも1つは利用可能なノードがあることを確認してください。サブスク更新のリクエストは既定でプロキシ経由で送信されるため、全ノードが無効だとリクエストが直接 ISP に接続され、失敗率が大幅に上がります。
返却内容の形式:HTML・Base64・変換ツールの JSON
リンクに到達できるのにクライアントが「解析失敗」と報告する場合、返却内容が標準の YAML サブスクではないケースがほとんどです。ブラウザでリンクを開き、返却内容の先頭を確認してください:
- HTML ページ:プロバイダーのお知らせページ、Cloudflare の認証ページ、404 ページなど。リンクが Web ページを指している
- Base64 の文字化け:一部のプロバイダーはサブスクを Base64 でエンコードしており、これは正常
- JSON 構造:プロバイダーがサブスク変換ツールを有効にしており、変換結果が返っている
- 空のファイル:サーバーが空の内容を返している。プロバイダーに連絡
Clash Verge は Base64 形式のサブスクを直接インポートでき、クライアントが自動でデコードします。ただし、一部プロバイダーの Base64 には改行や BOM が混入しており、デコードに失敗することがあります。リンクの内容を任意の Base64 デコードツールに貼り付け、デコード結果が proxies: で始まることを確認すれば、この問題を切り分けられます。
プロバイダーがサブスク変換ツールのリンクを提供している場合、たとえば Subconverter 形式なら、リンクの後ろに変換パラメータが付いているのが一般的です:
?target=clash&url=元のサブスクリンク変換ツールによってパラメータ名は異なるため、プロバイダーのパネルが提供する「Clash サブスク」専用リンクをそのまま使い、パラメータを手動で組み立てるのは避けてください。
もう一つの分かりにくい問題として、プロバイダーがサブスクの内容を HTTP レスポンスヘッダーに載せていたり、gzip 圧縮しているのに Content-Encoding を宣言していなかったりするケースがあります。こうした異常はクライアント側では自動処理できないため、プロバイダーのサポートに連絡して修正してもらうしかありません。
YAML 構文エラー:インデント・引用符・全角記号
サブスクのダウンロードは成功し、形式も YAML と認識されたのにパーサーが読めない場合、原因は YAML 構文にあります。プロバイダーが生成する設定はまれにミスがあり、設定ファイルを手動で編集したことがあるユーザーは特に遭遇しやすくなります。よくあるエラーは次のとおりです:
- インデントでスペースとタブが混在:YAML はスペースのみ受け付け、タブは即エラー
- コロンの後にスペースがない:
name: ノード名は有効、name:ノード名は解析失敗 - 引用符の閉じ忘れ:ノード名に特殊文字が含まれる場合は引用符で囲む必要がある
- 全角記号:全角コロン「:」や全角カンマ「,」がテンプレートに混入すると、パーサーが認識しない
- URL 内の
#がエスケープされていない:#は YAML ではコメントの開始記号なので、値の中の#は引用符で囲む必要がある
mihomo のエラーには行番号が付きます。例:
yaml: line 12: mapping values are not allowed in this context切り分け方:Clash Verge の「設定」→「パラメータ設定」→「設定ディレクトリ」を開くと、profiles フォルダーに対応するサブスクの yaml ファイルがあります。テキストエディターでエラー行に移動し、インデント・コロン・引用符を確認してください。
GUI がない場合は、コマンドラインで検証します:
python -c "import yaml; yaml.safe_load(open('sub.yaml', encoding='utf-8'))"None と出力されれば構文は正しい状態です。エラーの場合は具体的な行番号と理由が示されます。手動での修正は一時しのぎにしかなりません。プロバイダーのサブスクは次回更新時にファイル全体が上書きされるためです。正しい対処は、プロバイダーにフィードバックを送るか、サブスク変換ツールでクリーンな設定を再生成することです。
サブスクファイルを手動で編集する前に、必ずコピーしてバックアップを取ってください。サブスクを更新すると profiles ディレクトリ内の該当ファイルが上書きされるため、バックアップがないと最初から切り分けをやり直すことになります。
コアのフィールド互換性:mihomo と旧版 Clash の差異
サブスクは解析・読み込みできるのに、コアの起動時にエラーが出る、または一部ノードが使えない場合は、フィールド互換性の問題です。Clash コアは Clash Premium から mihomo に移行しており、2世代のコアでフィールドが完全に互通するわけではありません。
古いサブスクによく見られる廃止された書き方:
| 旧フィールド | mihomo での状態 | 代替方法 |
|---|---|---|
dns.enable |
非推奨 | dns セクションは既定で有効。削除するだけでよい |
tun.enable |
旧形式の書き方 | 完全な tun セクションで設定する |
experimental.udp-fallback |
削除済み | sniffer に置き換える |
proxy-groups に url がない |
新バージョンでは必須 | テスト用 URL を追加する |
mihomo で新しく追加されたフィールドは旧版コアでも認識されません。たとえば sniffer、profile.store-selected、dns.fake-ip-filter などです。
判定方法:コアのログを確認します。Clash Verge の「設定」→「パラメータ設定」→「ログ」でコアの出力を確認でき、unknown field や unsupported という記述があればフィールド非互換です。対処の優先順位:
- プロバイダーに mihomo 専用のサブスクリンクを要求する。多くのプロバイダーは Clash 用と mihomo 用の2本を用意している
- サブスク変換ツールで旧形式を mihomo 形式に変換する
- サブスク編集パネルで非互換フィールドを手動で削除する
フィールドを削除するときは、proxies セクションの核心フィールドには触れないでください。type、server、port、uuid、alterId はノード接続の基本であり、誤って削除すると全ノードが使えなくなります。
完全なセルフチェックの手順と復旧のすすめ
上記4つの原因を1つの流れにまとめました。順番に実行すれば、ほとんどの問題は5分以内に特定できます:
- ブラウザでサブスクリンクを開き、返却内容が YAML または Base64 であることを確認
- curl で HTTP ステータスコードを確認し、403 や 404 ならリンクを再生成
- ローカルに yaml として保存し、Python またはオンラインツールで構文を検証
- コアのログを確認し、
unknown fieldの警告がないことを確認 - Clash Verge で古いサブスクを削除し、新しいリンクをインポートし直す
- コアを起動し、プロキシが必要なサイトにアクセスして疎通を確認
すべて確認しても使えない場合は、サブスクファイルとコアのログをプロバイダーのサポートに送り、mihomo のバージョン番号も添えてください。切り分けが格段に速くなります。
最後に復旧のすすめです。サブスクのインポートに成功したら、その都度「サブスク」ページで設定ファイルのコピーをバックアップとして保存してください。設定に問題が起きてロールバックしたいときは、バックアップの内容を貼り付けるだけで済み、最初から切り分けるよりはるかに速いです。