URL・設定ファイル・ノードのエンコードを区別する
「サブスクリプションのインポート」には、データを取得することと、クライアントにデータを解析させることの2つの手順があります。URLはデータを取得するためのアドレス、YAMLは設定ファイルの記述形式、Base64はエンコード方式です。それぞれ異なる階層のものです。同じHTTPSサブスクリプションURLでも、完全なClash YAMLが返る場合もあれば、Base64でエンコードされたノードURIが返る場合もあります。URLだけを見ても、そのままインポートできるかどうかは判断できません。
| 取得するデータ | 見分けるポイント | 適したインポート方法 | その後の更新方法 |
|---|---|---|---|
| リモートサブスクリプションURL | 通常は https:// で始まり、トークンを含むパラメーターが付くことがあります |
リモート設定・サブスクリプションのURL入力欄 | クライアントが同じURLに再度アクセス |
| ローカルYAMLファイル | proxies: や proxy-groups: などのキーを含む |
ローカルファイルをインポート、または設定フォルダーを開く | 通常は再インポートするか、自分で管理する必要があります |
| Base64形式のノード一覧 | デコードすると、複数行の ss:// や vmess:// などのURIがよく見られます |
対応形式のノードインポート機能、または信頼できる変換ツール | 配布元と変換手順によって異なります |
URLサブスクリプション：URLのコピーから設定の有効化まで
アカウントページではなく、クライアント用のサブスクリプションURLをコピーする
サブスクリプション提供元のアカウントページで、ClashまたはMihomo向けの出力項目を選び、URLを最後までコピーします。アカウントのログインページ、購入履歴ページ、サブスクリプションAPIはそれぞれ別のURLです。提供元がClash、Clash Meta、汎用サブスクリプションを個別に用意している場合は、実際に使うクライアントのコアに合わせて選んでください。Mihomoを使うクライアントではClash Meta向け設定を利用できる場合がありますが、対応プロトコルを必ず確認してください。
- 配布元を確認：実際に利用しているサービスのアカウントから取得したURLを使います。クエリパラメーターは残してください。
?以降のトークンを省略したり、コピー時に含まれた引用符、空白、改行を入力欄に貼り付けたりしないでください。 - リモートURLの入力欄を探す：たとえばClash Verge Revでは、「サブスクリプション」ページのURL入力欄に貼り付けて「インポート」をクリックします。バージョンによって画面が変わる場合があります。「URLから設定を取得」する項目を選び、ローカルファイルのボタンと間違えないようにしてください。
- ダウンロードと解析を待つ：インポート後、設定名、更新日時、ノード一覧を確認します。解析エラーが出た場合は、現在使えている設定を残し、続けて上書きしないでください。
- 新しい設定を選択する：インポートした設定が有効になっていることを確認し、「プロキシ」ページで使用するポリシーグループのノードを選択します。ダウンロードが完了しても設定を切り替えていなければ、接続には以前の設定が使われる場合があります。
- プロキシ経路を確認する：まずクライアントの接続テストを行い、次にシステムプロキシを有効にしてテストページへアクセスします。システムプロキシを経由しない通信も制御する必要がある場合に限り、TUNを設定してください。
ClashX系クライアントでは、メニューバーのアイコンから「設定」→「プロファイル」→「管理」と進むと、リモートサブスクリプションを登録できることが一般的です。ブランチによってメニュー名は異なります。「プロファイル」が見つからない場合は、別のクライアントの画面手順を流用せず、まずクライアント名とバージョンを確認してください。
ブラウザーでURLを開いたときにログインページ、認証コード、HTMLが表示される場合、サーバーがHTTP 200を返していても、そのまま解析できるClash設定ではありません。提供元のページに戻ってサブスクリプションURLを取得し直してください。表示されたページを .yaml として保存しても解決しません。
ローカルYAML：ファイルのインポートと構造の確認
ローカルファイルは、手動で管理するルール、オフラインでの設定移行、提供元から直接受け取った設定パッケージに適しています。拡張子は .yaml または .yml が一般的ですが、拡張子はファイルの識別に使われるだけで、内容の形式は変わりません。Base64テキストの拡張子をYAMLに変えても、ポリシーグループや振り分けルールが自動生成されることはありません。
インポート前に確認する3項目
- 文字コードとインデント：UTF-8のテキストを使います。YAMLの階層にはスペースを使い、Tabは使わないでください。リスト項目と上位キーのインデントを揃えます。
- 設定の範囲：完全なメイン設定には通常、ノードまたはノードプロバイダー、ポリシーグループ、ルールが含まれます。
proxies:しかないファイルはノードプロバイダー用の内容であり、単独で動作する完全な設定ではない可能性があります。 - コアとの互換性：Mihomoが認識できるフィールドでも、古いClashコアでは認識されないことがあります。「未対応のプロキシタイプ」と表示された場合は、プロトコルとコアを確認してください。インデントの調整だけでは解決しません。
以下はYAMLの階層とDIRECTポリシーの例です。プロキシサーバーは含まれていないため、リモートノードの接続確認には使えません。7890はサンプルの待ち受けポートで、すべてのクライアントのデフォルト値ではありません。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxy-groups:
- name: 手動選択
type: select
proxies:
- DIRECT
rules:
- MATCH,手動選択クライアントの「サブスクリプション」または「設定」ページで、ローカルファイルのインポート項目を選びます。ドラッグ＆ドロップに対応している場合は、ファイルを該当エリアにドロップしてもかまいません。インポート後、実際に適用されているポートとモードを確認してください。GUIクライアントでは、設定のマージや設定画面によってファイル内の値が上書きされることがあります。インポート前後でポートが異なる場合は、実行中の設定とログを確認してください。
Base64：ノードをデコードしてもClash設定にはならない
Base64は暗号化方式ではありません。テキストを転送しやすい文字列にエンコードできますが、ノードのパスワードやサブスクリプショントークンを隠すことはできません。一般的な汎用サブスクリプションは、デコードすると1行につき1つのノードURIになります。これらのURIが記述するのは個々のノードであり、通常、Clashのメイン設定にあるポリシーグループ、ルール、DNS設定は含まれません。
デコードした内容に応じて処理方法を選ぶ
- ノードURIの一覧が表示される：まず、クライアントに対応プロトコルのノードインポート機能があるか確認します。メイン設定のインポーターがURI一覧を受け付けるとは限りません。単一ノードをインポートできても、汎用サブスクリプション全体に対応するとは限りません。
- 完全なYAMLが表示される：設定内容として扱い、インデント、プロトコルの種類、フィールドの互換性を確認してから、ローカルファイルのインポート項目で読み込みます。
- ウェブページやエラーメッセージが表示される：ダウンロード元またはアクセス状態に問題があります。さらにBase64でデコードしたり、ファイルの拡張子を変えたりしても解決しません。
変換が必要な場合は、提供元のClash/Mihomo専用出力か、信頼できるローカル変換ツールを優先してください。変換にはデコードだけでなく、ノードパラメーターを対象コアの形式に合わせ、ポリシーグループとルールを生成し、TLS、SNI、通信方式などの必要なフィールドを保持する作業も含まれます。元の情報が不足している場合、変換ツールで認証パラメーターを補うことはできません。
第三者のオンライン変換サービスに、サブスクリプションURL全体やノードの認証情報を見られる可能性があります。出所が不明なサイトに実際のURLを貼り付けたり、公開サポートチケットに元ファイルを添付したりしないでください。調査時にはトークン、パスワード、UUID、サーバー情報を隠します。トークンが漏えいした場合は、提供元のアカウントでサブスクリプションURLを再発行してください。
自動更新：メイン設定とノードプロバイダーの更新間隔は別々
GUIクライアントの「サブスクリプション更新間隔」と、コア設定内のノードプロバイダーの更新は別の設定です。前者はメイン設定を再ダウンロードし、後者は proxy-providers が参照するノード情報だけを更新します。一方を変更しても、もう一方が連動するとは限りません。
| 更新対象 | 設定場所 | 確認するポイント |
|---|---|---|
| リモートのメイン設定 | クライアントのサブスクリプションカードにある編集・更新設定 | 画面の単位が分かか時間か、自動更新が有効か |
| HTTPノードプロバイダー | メイン設定の proxy-providers |
interval の単位は秒 |
| 通常のローカルファイル | ファイルの管理手順 | 再読み込みが必要か、リモートリソースを参照しているか |
以下はMihomoのHTTPノードプロバイダー設定例です。86400秒は24時間です。URLには予約済みのサンプル用ドメインを使用しているため、実際のノードは提供されません。この設定は完全なメイン設定に追加してください。取得先のレスポンスは、トップレベルに proxies: を含むYAMLなど、コアが対応するノードプロバイダー形式である必要があります。
proxy-providers:
remote-nodes:
type: http
url: "https://example.com/nodes.yaml"
path: ./providers/remote-nodes.yaml
interval: 86400ノードを該当グループに表示するには、ポリシーグループ側で use: を使って remote-nodes を参照する必要があります。プロバイダーのヘルスチェック間隔は接続確認の頻度を制御するもので、サブスクリプションのダウンロード間隔ではありません。「ノードを速くする」ために更新間隔を数秒に設定しないでください。リクエストが増え、サーバー側で制限される可能性があります。
クライアントが起動していない、端末がスリープ中、またはネットワークに接続できない場合、定期更新が実行されるとは限りません。設定を変更したら、まず手動で一度更新し、エラーがないことを確認してから、更新日時と次回起動後の動作を確認してください。残りの通信量や有効期限が表示されるかどうかは、レスポンス情報とクライアントの対応状況によります。設定形式の判断には影響しません。
インポートできない場合：ダウンロード・解析・動作の順に確認
手順1：正しいレスポンスを取得できているか確認
- HTTP 401または403：まずURLが完全か、トークンが有効か、アカウントに問題がないか確認します。403はアクセス制限やセキュリティシステムによる場合もあり、ノードの障害とは限りません。
- HTTP 429：更新ボタンを連続で押すのをやめ、サーバーの案内に従って待ってから、更新頻度を下げてください。
- タイムアウトまたは証明書エラー：ネットワーク、システム時刻、サブスクリプションドメインの名前解決を確認してください。証明書検証の無効化を常用の解決策にしないでください。
手順2：形式とコアを確認
YAMLの行番号エラーが出た場合は、表示された行とその直前の階層を確認します。特にコロン、引用符、リストのハイフンに注意してください。未知のプロキシタイプが表示された場合は、クライアントのバージョンとコア名を記録し、提供元で互換性のある出力形式を選び直します。設定に proxy-providers があり、ノードが直接列挙されていなくても、必ずしもエラーではありません。プロバイダーのダウンロードが成功しているか、ポリシーグループが正しく参照しているかを確認してください。
手順3：サブスクリプションの更新経路と実際のプロキシ経路を区別
サブスクリプションのリクエストはクライアント自身が送信する場合があり、コアのプロキシを経由するとは限りません。以前の設定ではインターネットに接続できるのに、新しいサブスクリプションをダウンロードできない場合は、サブスクリプション更新用のプロキシを個別に設定できるか、その設定が既存の有効なプロファイルを必要とするかを確認してください。TUNはネットワーク通信を取り込む機能であり、Base64を自動的にYAMLへ変換したり、無効なトークンを修復したりするものではありません。
最後に、有効な設定、ポリシーグループの選択、システムプロキシを確認します。システムプロキシのポートは、クライアントが実際に待ち受けているポートと一致している必要があります。たとえばクライアントが 7890 で待ち受けているのに、システムプロキシが 7897 を指定していると、設定をインポートできてもアプリは接続できません。この順に確認すれば、「ダウンロード失敗」「形式の非互換」「通信がプロキシを経由していない」を切り分けられ、クライアントの再インストールを繰り返さずに済みます。