サブスクリプションの応答形式を確認する

Clashにサブスクリプションをインポートできるかどうかは、URLの末尾が.yamlかではなく、リンクから返される内容とクライアントが対応する設定形式で決まります。まず提供元が「Clash」または「Clash Meta / mihomo」向けとして案内しているリンクを使い、クライアントにインポートしてください。一般的なHTTPS URLからは、完全な設定ファイルのほか、Base64形式のノードリスト、ログインページ、エラーメッセージが返されることもあります。

クライアントは設定、システムプロキシ、コアを管理するためのGUIです。一方、mihomoはプロキシプロトコルやルールによる振り分けを処理するコアです。画面に「サブスクリプションをインポート」ボタンがあっても、コアがあらゆる形式を直接読み込めるとは限りません。クライアントによっては内容を変換してから取り込みますが、Clash YAMLのみ対応するものもあります。それぞれの対応形式を確認してください。

取得した内容見分けるポイント対処方法
Clash YAML（完全な設定）トップレベルによくある項目はproxies、proxy-groups、rulesですURLから設定をインポートするか、ローカル設定として読み込む
プロバイダーのノード用YAML通常はproxiesのノード一覧のみproxy-providersから参照するか、クライアントが明示的に対応するマージ機能を使う
Base64形式のノードリストデコードするとss://やvmess://などのURIが複数行で現れる提供元のClash形式の出力を使うか、信頼できるローカル変換ツールを使う
WebページまたはエラーデータHTMLタグ、ログインフォーム、JSON形式のエラーメッセージが含まれるURL、認証状態、サブスクリプションの有効期限を確認する。YAMLとして読み込まない

URLからサブスクリプションをインポートする

提供元からURL全体をコピーし、クエリパラメーターも残してください。URL内のトークンはアクセス認証情報であることが多く、疑問符以降をコピーし忘れるとHTTP 401や403エラーになる場合があります。WebサイトへのログインURL、購入ページ、QRコード画像のURLをサブスクリプションURLとして使わないでください。

インポートと有効化を別々に確認する

  1. 設定管理を開く。クライアントの「設定」「サブスクリプション」またはProfilesページを開き、URL入力欄があるリモートインポートを選びます。項目名はクライアントによって異なるため、実際の画面で確認してください。
  2. URL全体を貼り付ける。入力欄にはURLだけを貼り付けます。チャットアプリなどで付加された引用符、説明文、改行は含めないでください。提供元が案内するHTTPS URLを優先して使いましょう。
  3. ダウンロードまたはインポートを実行する。設定が一覧に表示されるまで待ち、更新日時とエラーメッセージを確認します。旧版Clash for Windowsの英語画面では、Profiles → URL 入力欄 → Downloadの順です。このクライアントはサポート終了済みのため、この手順は旧画面を見分けるための参考です。
  4. 設定を選択する。ダウンロード後、設定項目をクリックして現在の設定として有効にします。再読み込みに失敗したという表示が出た場合は、ログを確認してください。一覧に表示されているだけでは、正常に有効化されたとは判断できません。
  5. 動作状態を確認する。ルールモードでポリシーグループが読み込まれていることを確認し、利用可能なポリシーを選択します。デスクトップクライアントでは、用途に応じてシステムプロキシまたはTUNも有効にしてください。設定をインポートしただけでは、通信がプロキシ経由になるとは限りません。

「ダウンロード成功 → 解析成功 → 設定を有効化 → 通信への適用」の4段階で確認しましょう。最初の段階だけでは、ブラウザーが従来の接続方法を使い続けることがあります。解析に失敗しても、クライアントが以前の有効な設定を使い続ける場合があります。クライアントの入手先を確認するには、まずクライアントのダウンロードページでOSを選び、インストール・設定ガイドを参照してください。

ローカルYAMLファイルをインポートする

ローカルYAMLは、オフラインでの保存や設定の移行、形式の問題を調べるときに便利です。通常は「設定」ページにある「ファイルをインポート」またはファイルのドラッグ＆ドロップ領域から読み込みます。インポート後は設定を選択し、クライアントのログに構文エラーがないことも確認してください。

ファイルをインポートする前の3項目チェック

  • 文字コードと拡張子：UTF-8のテキストファイルを使い、config.yaml.txtになっていないか確認します。ファイルマネージャーで拡張子を表示すると、アイコンだけで判断するより確実です。
  • インデントと階層：YAMLのインデントにはスペースを使い、Tabは使いません。同じ階層の項目は位置をそろえ、リスト項目のハイフンも適切な階層に配置します。
  • 設定が完成しているか：ノード一覧だけのYAMLは、完全な振り分け設定ではありません。実際に使用するポリシーグループ、ルール、DNS設定は、メイン設定で定義する必要があります。

以下は階層の説明に使う、最小限の直接接続設定です。リモートプロキシノードは含まれていないため、サブスクリプションのノードが利用可能かどうかは検証できません。インポートと解析の手順だけを確認する場合は、現在の設定を先にバックアップし、テスト後に元の設定へ戻してください。

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

proxies: []

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

rules:
  - MATCH,手動選択

mixed-port: 7890は、ローカルのHTTPとSOCKSで共用する待ち受けポートを設定する項目で、リモートノードのポートではありません。mode: ruleはルールに基づいて振り分ける設定です。末尾のMATCHは、残りの通信を「手動選択」グループに送ります。このグループにはDIRECTしか含まれていないため、例の通信は直接接続になります。ポートがすでに使用中の場合、構文が正しくても正常に待ち受けできないことがあります。

Base64形式のノードリストを見分ける

Base64はエンコード方式であり、Clashの設定構文でも暗号化でもありません。一般的なサブスクリプションでは複数のノードURIをまとめてエンコードしているため、デコードするとss://、trojan://、vmess://、vless://などが現れることがあります。こうしたテキストには通常、ポリシーグループやルール一式は含まれていません。

形式を見分けて対応する方法を選ぶ

  1. まず提供元のページで、Clashまたはmihomo向けと明記されたサブスクリプションを探します。同じアカウントで複数のURLが提供されている場合は、現在のコアに対応するものをコピーしてください。
  2. 汎用サブスクリプションしかない場合は、クライアントがURI一覧やBase64形式のインポートに明示的に対応しているか確認します。個別のノードURIに対応していても、Base64形式のサブスクリプション全体を読み込めるとは限りません。
  3. 変換が必要な場合は、提供元の変換機能か信頼できるローカルツールを優先してください。変換時にはノードのプロトコル、トランスポート層、TLSなどの項目を解析する必要があります。拡張子を変更するだけでは変換できません。
  4. 変換後はノード数、ポリシーグループの参照先、コアのエラーを確認してから有効化してください。解析が成功しても、すべてのノードの接続パラメーターが正しいとは限りません。

オリジナル版ClashとClash Meta（現在の名称はmihomo）では、対応するプロトコルや設定項目が完全には一致しません。変換ツールが特定のプロトコル項目を生成しても、旧コアで動作するとは限りません。unsupported proxy typeのようなエラーが出たら、同じファイルを何度もインポートするのではなく、実際に動作中のコアとサブスクリプションの対象形式を確認してください。

サブスクリプションの更新間隔を設定する

リモート設定全体の更新とノードプロバイダーの更新は、別々の仕組みです。GUIクライアントはリモート設定をダウンロードし、mihomoのproxy-providersはノード一覧を定期的に取得できます。それぞれのintervalや画面上の数値を混同しないでください。また、ヘルスチェックの間隔はサブスクリプションの更新間隔とは異なります。

更新設定の場所更新対象単位と設定例
クライアントのリモート設定設定ファイル全体画面に表示される単位で設定します。分単位と明記されている場合、360は6時間です
proxy-providers内のinterval指定したプロバイダーのノード一覧単位は秒です。21600は6時間です
health-check.intervalノードの接続確認単位は秒です。300は5分ごとの確認を表し、新しいサブスクリプションはダウンロードしません

普段の利用では、まず更新間隔を6時間に設定し、提供元の制限に応じて調整するとよいでしょう。これは設定例であり、プロトコル上の要件ではありません。クライアントが応答に含まれる更新間隔の推奨値を読み取れる場合、実際の動作はクライアントの実装にも左右されます。アカウント側で変更があった後は、一度手動で更新し、更新日時とノード一覧を確認してください。

更新後もローカル設定を維持する

リモート設定を更新すると、直接編集したポート、ルール、DNS設定が上書きされることがあります。ローカルの変更を継続して使うには、クライアントが対応するオーバーライド、マージ、拡張設定機能を使い、マージ後の内容を確認してください。リモートファイルを編集しても、次回のサブスクリプション更新後に変更が残るとは限りません。

また、完全な設定を含むサブスクリプションには、ノードだけでなくルールや外部リソースへの参照が含まれることがあります。インポート前に提供元を確認し、allow-lan、コントローラーAPI、待ち受けアドレスなどの設定が使用中のデバイスに適しているか確認してください。一般的な個人用デスクトップ環境では、インポートのためだけにLANアクセスを安易に許可しないでください。

インポートに失敗したときの確認手順

まずダウンロードの失敗、内容形式のエラー、実行時の失敗を切り分け、それぞれの段階を確認してください。何度もインポートを繰り返しても、形式の問題は解決しません。提供元からのリクエスト頻度制限にかかることもあります。

症状まず確認する項目次の対応
HTTP 401または403トークン、アカウント状態、アクセス制限提供元の管理画面からURLをコピーし直してください。ステータスコードだけで原因を決めつけないようにしましょう。
HTTP 429リクエスト頻度が高すぎないか連続更新をやめ、サーバーの再試行案内に従って更新間隔を延ばします
HTMLが返る、または先頭行の解析エラーが出るログインページ、認証ページ、リダイレクトエラーページに移動していないか最終的な応答本文を確認し、サブスクリプションデータが取得できているか確かめます
YAMLのインデントまたは設定項目のエラーファイル内容、インデント、重複キー、プロトコルの対応状況ログで行番号を確認し、対象の形式を正しくダウンロードしたか確認します
インポートは成功したが、想定したノードがないノードプロバイダー用のファイルか、アカウントから空の一覧が返されていないか設定の種類と提供元の状態を確認し、ポリシーグループの参照先も確認します
設定を有効にしても通信できない現在の設定、グループ内の選択、システムプロキシまたはTUN、DNS通信経路に沿って一つずつ確認します。サブスクリプションの再ダウンロードだけを繰り返さないでください。

ブラウザーでは開けるのに、クライアントのダウンロードは失敗する

ブラウザーとクライアントでは、使用するプロキシ経路、DNS、リクエストヘッダーが異なることがあります。ブラウザーでダウンロード結果が表示されても、クライアントから同じURLにアクセスできるとは限りません。まずログでタイムアウト、証明書、ドメイン解決のエラーを確認してください。クライアントにサブスクリプションのダウンロード用プロキシ設定がある場合は、説明に従って選択します。接続の問題を隠すために証明書検証を無効にしないでください。

サブスクリプションをインポートする前のダウンロードにプロキシが必要

初期設定時に起こりうる依存関係のループです。提供元にアクセスできる信頼性の高いデバイスやネットワークでYAMLをダウンロードし、ローカルファイルとして最初にインポートする方法があります。その後、元のデバイスでリモート更新を確認してください。設定ファイルは機密情報として扱い、公開クラウドストレージや共有グループに置かないようにしましょう。

問題の確認後は、次の3点を確認してください。対象の設定が有効になっていること、ログに解析エラーやリソースのダウンロードエラーが継続して出ていないこと、接続テストが想定したポリシーを通っていること。設定項目の意味やルールの書き方は設定ファイルリファレンスを、通信がプロキシに適用されない場合はFAQを参照してください。サブスクリプションの更新に成功しても、取得と読み込みが正常であることしか確認できません。ノードの接続性は別途確認が必要です。