インポート前にURLと設定形式を確認する
Clashクライアントでいう「サブスクリプション」とは、通常HTTPまたはHTTPSで取得できるリモート設定URLを指します。クライアントがURLへリクエストを送ると、サーバーはYAML設定、エンコードされたノード一覧、または特定クライアント向けに変換したデータを返します。ブラウザーでURLを開けても、Mihomoカーネルで読み込めるとは限りません。返却内容、設定項目、クライアントの対応範囲をあわせて確認してください。
サブスクリプションURLには、ユーザー識別子、アクセストークン、一時的な認証パラメーターが含まれることがあります。コピー時は疑問符以降のパラメーターを含め、クエリ文字列全体を保持してください。末尾の文字を手動で削除してはいけません。このURLは設定へアクセスする認証情報に相当するため、スクリーンショットやログ、問い合わせ内容ではドメインだけを残し、パスとパラメーターは伏せてください。
Clash標準YAML設定
標準設定は、ClashおよびMihomoクライアントが直接読み込める形式です。冒頭の項目順に決まりはありませんが、通常は mixed-port、proxies、proxy-groups、rules、dns などのキーを確認できます。最小構成は、次のような形になります。
mixed-port: 7890
mode: rule
proxies:
- name: example-node
type: socks5
server: 192.0.2.10
port: 1080
proxy-groups:
- name: PROXY
type: select
proxies:
- example-node
rules:
- MATCH,PROXY実際のサブスクリプションには、プロトコル認証、TLS、UDP、ルールセット、DNS設定も含まれるのが一般的です。Mihomoの拡張フィールドである rule-providers、sniffer、tun や一部プロトコルのパラメーターは、対応するフィールドを扱えるカーネルで解析する必要があります。古いClashクライアントでは、拡張フィールドに遭遇するとエラーになる場合も、認識できない項目を無視する場合もあります。
Base64ノードサブスクリプション
Base64サブスクリプションをデコードすると、通常は1行ごとに並んだ共有リンクになります。たとえば ss://、trojan://、vmess://、vless:// などです。これは完全なClash YAMLではなく、一般にプロキシグループ、ルール、DNS、TUNのパラメーターを含みません。ノード一覧を解析して基本設定を自動生成するクライアントもありますが、YAMLだけを受け付けるクライアントでは「設定形式が正しくありません」や「proxiesフィールドがありません」と表示されます。
単一の共有リンクと汎用サブスクリプション
プロトコル名で始まる単一のURIは、1つのノードだけを記述します。クライアントの「ノードをインポート」には適していますが、「リモート設定URL」の入力欄では使えないことがあります。汎用サブスクリプションは、リクエストヘッダーからクライアントを判別して形式を変える場合があります。同じURLでもブラウザーではBase64、クライアントではClash YAMLが返ることがあるのは、サーバーがUser-Agentに応じて変換しているためです。
デスクトップクライアントでのインポート手順
デスクトップクライアントによって名称は少し異なりますが、基本の流れは共通しています。リモート設定を新規作成し、URLを入力して設定をダウンロード、設定を有効化した後、プロキシグループを選択します。以下は一般的なバージョンの画面を基準にした手順です。メニュー構成が異なる場合は、「サブスクリプション」「設定」「Profiles」などの画面でURLインポートの入口を探してください。
Clash Verge Rev
- クライアントを開き、「サブスクリプション」ページへ移動します。
- 完全なサブスクリプションURLを上部のURL入力欄に貼り付け、URLの先頭が
https://またはhttp://になっていることを確認します。 - 「インポート」を選択します。クライアントがリモートリクエストを実行し、ダウンロードに成功した設定がサブスクリプションカードとして表示されます。
- 新しい設定カードをクリックし、現在の有効な設定にします。
- 「プロキシ」ページを開き、よく使われる
PROXY、ノード選択、または同様の名前のプロキシグループからノードを選択します。 - 「設定」→「システム設定」へ進み、必要に応じてシステムプロキシを有効にします。より多くのアプリの通信を取り込む必要がある場合は、TUNモードを有効にするか検討してください。
インポート後にカードは存在するのにプロキシページが空の場合は、システムプロキシを何度も切り替えないでください。設定の詳細でダウンロード時刻とファイルサイズを確認し、ログを開いてYAMLの解析エラーを確認します。ローカルリスニングポートでは混合ポート 7890 がよく使われますが、設定で上書きできます。ブラウザーに手動でプロキシを設定する場合は、現在実行中の設定に表示されるポートを使用してください。
Mihomo Party
- 「サブスクリプション」ページを開き、「追加」を選択します。
- リモートサブスクリプションを選び、名前とサブスクリプションURLを入力します。
- 保存後に一度更新し、ステータスが「ダウンロード中」から「利用可能」に変わるまで待ちます。
- 追加したばかりのサブスクリプションを選択し、現在の設定にします。
- 「プロキシ」ページでプロキシグループとノードを選択し、「設定」でシステムプロキシまたはTUNを有効にします。
Mihomo PartyはMihomoカーネルを使用するため、Mihomoの拡張フィールドを含む設定の読み込みに適しています。サブスクリプションがリモートルールセットを参照している場合、初回読み込み時に rule-providers が指定するファイルも続けてダウンロードされます。メイン設定のダウンロードに成功してもルールセットの取得に失敗した場合、ログには2つのリクエストが別々に記録されます。確認時はサブスクリプションのドメインとルールセットのドメインを分けて調べてください。
FlClash
- 「設定」ページを開き、右上の追加ボタンを選択します。
- 「URL」を選択し、サブスクリプションURLを貼り付けて識別しやすい名前を入力します。
- インポートを確定し、設定カードが表示されるまで待ちます。
- 設定を選択してから「プロキシ」に戻り、プロキシグループを展開してノードを選びます。
- 「ツール」または「設定」からシステムプロキシを有効にします。デスクトップで全通信を取り込む必要がある場合に限り、TUNを有効にしてください。
FlClashは複数のデスクトップおよびモバイルプラットフォームに対応し、ウィンドウ幅に応じて画面構成が変わります。狭い画面では設定への入口が下部ナビゲーションやその他メニューに収納されることがありますが、URL、ファイル、クリップボードのインポート方法は通常分かれています。リモートサブスクリプションにはURLを、ローカルに保存済みのYAMLにはファイルを選択してください。
Android・iOSクライアントでのインポート方法
Clash Meta for Android
- 「設定」を開き、右上のプラスボタンをタップします。
- 「URLからインポート」を選択します。
- 設定名、サブスクリプションURL、自動更新間隔を入力します。
- 保存してダウンロードが完了するまで待ち、その設定をタップして有効にします。
- メイン画面に戻り、「起動」をタップして、システムに表示されるVPN接続の許可を確認します。
- 「プロキシ」を開いてプロキシグループを確認し、接続できない古いノードが選択されたままになっていないか確認します。
AndroidのClash Metaクライアントは通常、システムVPNインターフェースで通信を取り込むため、アプリごとに 127.0.0.1:7890 を入力する必要はありません。初回起動時にVPN権限のダイアログが表示されるのは、システム上の通常の手順です。同時にAndroidのVPNインターフェースを使用できるアプリは1つだけです。別のVPN、フィルター、プロキシツールが動作している場合は、先に停止してから現在の設定を起動してください。
自動更新間隔は短くしすぎないでください。ノード情報の変化が少ない場合は、まず1440分、つまり1日1回に設定します。ルールを頻繁に調整する設定では360分が適しています。15分に設定すると重複リクエストが増え、サブスクリプションサービスのアクセス頻度制限にかかる可能性もあります。
FlClashモバイル版
Android版FlClashのインポート手順はデスクトップ版に近く、「設定」→「追加」→「URL」と進み、URLを貼り付けてダウンロードし、有効化します。サービスを起動する前に、システムVPNの許可にも同意する必要があります。インポート後はプロキシグループでノードを確認し、ホーム画面の起動状態だけで設定の完全性を判断しないでください。
iOSでの互換性に関する注意
iOSクライアントでは、設定の解析方法がアプリごとに異なります。StashのようにClashのルール構造に対応したクライアントでは、リモート設定または設定管理画面からURLを指定してダウンロードし、返された設定を現在の設定にできます。具体的な入口はクライアントのバージョンによって変わるため、インポート前にサブスクリプション提供元がそのクライアント対応形式を案内しているか確認してください。
一部のiOSツールは主にノードサブスクリプションと単一の共有リンクを受け付け、Clash YAMLに含まれるプロキシグループ、スクリプト、ルールセット、DNSフィールドを完全には利用しません。同じURLをインポートしてノードだけが表示され、元の設定にあったルールグループが見えない場合は、クライアントが形式を変換した可能性が高く、リモートファイル自体にルールがないとは限りません。
インポート後にノード、プロキシグループ、ルールの読み込みを確認する
「インポート成功」は、クライアントが設定レコードを保存したことを示すだけです。完全な確認では、少なくとも設定内容、カーネルの動作、プロキシグループの選択、実際の接続という4つの段階を確認します。以下の順序で調べると、ルールの問題をサブスクリプションのダウンロード問題と取り違えにくくなります。
ステップ1：設定の更新時刻と内容量を確認する
- 設定カードには、数日前のキャッシュ時刻ではなく、直近の更新時刻が表示されているはずです。
- リモートファイルのサイズが0であってはいけません。数十バイトしかない場合は、エラーメッセージやログインページが返されている可能性があります。
- 設定の詳細にはノード数が表示されるはずです。20ノードを想定しているのに1つしか表示されない場合は、単一の共有リンクを誤ってインポートしていないか確認します。
- 設定でルールが定義されているなら、
proxiesだけでなくrulesまたはリモートルールセットも確認できるはずです。
ステップ2：カーネルの起動を確認する
設定を切り替えた後、実行状態とログを確認します。通常は、設定の読み込み、リスニングポートの起動、コントロールインターフェースの利用可能化などが記録されます。ログが解析段階で止まっている場合は、最初のエラーから該当フィールドを特定してください。その後に大量の連鎖エラーが出ていても、先行するインデント、フィールド型、非対応パラメーターが原因であることが多いです。
YAMLではスペースで階層を表します。Tab、コロンの欠落、誤ったインデントはいずれも解析エラーの原因です。たとえば rules はリストでなければならず、ルール全体を改行なしの1つの文字列にしてはいけません。リモートサブスクリプションをサーバー側で生成している場合は、更新のたびにキャッシュファイルを手動編集するのではなく、提供元に元の設定を修正してもらうのが先です。
ステップ3：プロキシグループの選択を確認する
「プロキシ」ページを開き、プロキシグループを階層ごとに展開します。最終出口グループが DIRECT になっていると、クライアントが起動していても、そのグループに一致する接続は直接接続されます。url-test または fallback の自動グループを選んでいる場合は、少なくとも1つのノードで遅延テストが完了していることを確認してください。
遅延テストで80msと表示されても、そのノード経由でテストURLへアクセスできることを示すだけで、すべてのサイトに接続できるとは限りません。実際のリクエストも1回実行し、接続記録でドメイン、適用ルール、プロキシグループ、最終ノードを確認してください。たとえば DOMAIN-SUFFIX に一致した後 PROXY に渡され、さらにそのグループが具体的なノードを選択していれば、ルールの流れが正しく機能しています。
ステップ4：プロキシモードを確認する
| モード | 通信の動作 | 確認ポイント |
|---|---|---|
| ルール | rulesを上から順に照合し、一致したプロキシグループを使用 | 接続記録で適用ルールとプロキシグループを確認 |
| グローバル | すべての接続をグローバルプロキシグループへ渡す | グローバルグループで利用可能なノードが選択されていることを確認 |
| 直接接続 | 接続はプロキシノードを経由しない | 基準テスト用であり、ノードの出口確認には使用しない |
インポート結果を確認する際は、まずルールモードを使用し、サブスクリプション本来の振り分けを維持してください。一時的にグローバルモードへ切り替えると、ノードに基本的な接続性があるか判断できますが、テスト後はルールモードへ戻します。モード変更が影響するのは新しい接続だけです。ブラウザーで既に確立された長時間接続は古い経路を使い続けることがあるため、該当タブを閉じるかアプリを再起動して再テストしてください。
サブスクリプションのインポートに失敗したときの代表的な表示と対処
HTTP 401、403、404
401 と 403 は通常、認証パラメーターの欠落、トークンの期限切れ、アクセス元の制限、サブスクリプションの無効化を示します。404 はパスが存在しないことを示しますが、サーバーが無効なトークンを隠すためにこのステータスを返す場合もあります。サブスクリプション管理ページから完全なURLをコピーし直し、ブラウザーのアドレスバーに表示された管理ページのURLだけをコピーしないでください。URLに & パラメーターが含まれる場合は、チャットアプリやメモツールによって後半が切り取られていないか確認します。
リクエストがタイムアウトする、または接続を拒否される
サブスクリプション更新がプロキシ起動前に行われる場合、クライアントは通常、ローカルネットワークからサブスクリプションのドメインへ直接接続します。プロキシ起動後は、更新リクエストが現在のプロキシを経由するクライアントもあります。サブスクリプションのドメインへのアクセスにプロキシが必要だと、「設定をダウンロードできないためプロキシを起動できず、プロキシが起動しないため設定をダウンロードできない」という循環に陥ることがあります。まず到達可能なネットワークで初回インポートを完了するか、クライアントが対応していればサブスクリプション更新リクエストの経路を調整してください。
ローカルHTTPプロキシでは 127.0.0.1:7890、SOCKSポートでは 127.0.0.1:7891 がよく使われますが、いずれも一般的な初期値にすぎません。ポートが他のプログラムに使用されていると、カーネルを起動できず、ログにbindやaddress already in useが表示されます。この場合は現在の設定にある mixed-port、port、socks-port を確認し、同じポートを重複して待ち受けないようにしてください。
YAML解析エラーが表示される
まず設定の詳細で、返された内容がHTMLではないことを確認します。先頭に <!doctype html>、ログイン案内、エラーページがある場合、クライアントが取得したのはYAMLではありません。本当にYAMLであれば、ログに示された行番号とフィールド名を記録し、インデント、真偽値の型、リスト形式、カーネルが該当プロトコルのフィールドに対応しているかを重点的に確認します。
ノードはあるが、ルールとプロキシグループが消えている
この症状は、Base64ノードサブスクリプションをインポートした場合や、クライアントが汎用サブスクリプションを基本設定へ変換した場合によく起こります。ノード一覧には接続パラメーターしかなく、完全な通信振り分け設計は含まれません。ルールによる振り分けが必要なら、ClashまたはMihomoのYAMLサブスクリプションを取得するか、クライアントのローカルオーバーライド機能でプロキシグループ、DNS、ルールを追加してください。オーバーライド前に元の設定を保存し、サブスクリプション更新後に項目が重複しないようにします。
更新しても設定が変わらない
まずクライアントに表示された更新時刻を確認し、その後手動更新を実行します。更新時刻は変わったのにノードが変わらない場合は、サーバー側の内容がもともと更新されていない可能性があります。更新時刻も変わらない場合は、リクエストがキャッシュに当たっていないか、自動更新が有効か、同名の別設定カードを使っていないかを確認します。設定を削除するとローカルの選択状態も消えるため、通常は最初に行うべきではありません。
自動更新、オーバーライド、TUNの設定順序
サブスクリプションのインポートが安定してから、自動更新とローカルオーバーライドを調整します。推奨順序は、まずリモートYAMLを単独で読み込めることを確認し、次に更新間隔を360～1440分に設定、その後に少数のオーバーライドを追加し、最後にシステムプロキシまたはTUNをテストする流れです。一度に複数の層を変更すると、失敗箇所を特定しにくくなります。
自動更新間隔
- ノードの変化が少ない場合：1440分、1日1回確認。
- ルールやノードを頻繁に調整する場合：360分、6時間ごとに確認。
- 一時的に設定の修正を待つ場合：手動更新を使用し、5分や10分の間隔で繰り返し取得しない。
クライアントのスリープ、システムによるバックグラウンド動作の制限、モバイル端末の省電力機能によって、更新が遅れることがあります。そのため自動更新間隔は予定頻度を示すもので、指定した分数どおりの実行を保証するものではありません。すぐに新しい内容を取得したい場合は設定ページを開いて手動更新を実行し、更新時刻が変わったことを確認してください。
ローカルオーバーライドの範囲
オーバーライドは、リスニングポートの変更、LANへの直接接続ルールの追加、DNSサーバーの調整、TUNパラメーターの補足など、端末固有の差分を保つ用途に適しています。大量のノードをオーバーライドファイルへコピーするのは避けてください。サブスクリプション更新後に古い項目が残りやすいためです。ルールの順序にも注意が必要です。Clashは上から順に照合するため、追加したLANルールを MATCH の後ろに置くと実行されません。
TUNモードはサブスクリプションの解析可否を決めない
TUNはOSの通信を取り込む機能であり、サブスクリプションのインポートは設定を取得して解析する段階です。YAMLの解析に失敗しているとき、TUNを有効にしても設定は修復されません。ノードとルールが正しく読み込まれていて、システムプロキシに従わないアプリの通信を取り込みたい場合に、TUNをテストします。有効化後は接続を再確立し、接続一覧に対象アプリのリクエストが表示されるか確認してください。
繰り返し使えるインポート確認リスト
- ClashまたはMihomoのサブスクリプションURLをコピーしたことを確認します。管理ページやQRコードのURLではありません。
- URLの完全なパス、クエリパラメーター、プロトコル接頭辞を保持します。
- クライアントの「サブスクリプション」または「設定」ページでURLインポートを選択し、ローカルファイルを誤って選ばないようにします。
- ダウンロード後、更新時刻、ノード数、プロキシグループ、ルールが想定どおりか確認します。
- 新しい設定を有効化し、カーネルが起動していることと、ローカルリスニングポートに競合がないことを確認します。
- プロキシグループでノードを選択してから、システムプロキシまたはモバイル端末のVPNサービスを有効にします。
- ルールモードで新しい接続を開始し、接続記録でルール、プロキシグループ、最終ノードを照合します。
- 安定して動作してから自動更新、オーバーライド、TUNを設定し、複数の変数を同時に変更しないようにします。
サブスクリプションのインポートで重要なのは、「追加」を一度クリックすることではありません。リモートの内容がクライアント対応の設定かを見極め、ダウンロード、解析、有効化、通信の一致までの流れを確認することが重要です。失敗した場合は、HTTPリクエスト、返却形式、カーネル解析、プロキシ選択、システムによる通信取り込みの順に確認すると、問題を1つの工程へ絞り込めることが多いです。