インポート前に確認すること:URLの内容とクライアントのコア

クライアントの「サブスクリプション」または「設定」画面を開き、URL、クリップボード、ローカルファイルのいずれかを選びます。3つの方法は設定をクライアントに取り込む入口が異なるだけです。正常に使えるかどうかは、取得した内容の形式、コアが対応するプロトコル、設定が有効になっているかで決まります。プロバイダーからリンクを受け取ったら、まず「Clash」「Clash Meta」「mihomo」と明記されたサブスクリプションを選びましょう。

  • リモートURL:長期利用に適しています。クライアントに取得元のURLを保存し、手動または指定した間隔で更新できます。
  • クリップボード:ブラウザーからコピーしてすぐに取り込みたい場合に便利です。コピーしたものがURL、YAML一式、単一のノードURIのどれかを先に確認してください。
  • ローカルファイル:設定ファイルの受け取りやオフラインでの確認、スナップショットの保存に適しています。一般的なローカル設定は、元のサブスクリプションURLに連動して更新されません。

この記事では、mihomoコアを採用したデスクトップクライアントを例に説明します。Clash Verge Revでは通常、「サブスクリプション」画面から操作します。ほかのクライアントでは同様の項目が「設定」「Profiles」「リモート設定」などと表示される場合があり、名称はバージョンによって異なります。macOS、Windows、Androidでインポートの基本的な仕組みは同じですが、システムプロキシやVPNの許可設定は後の手順です。リンクを貼り付ける前に同時に有効化する必要はありません。

方法1:URLからリモートサブスクリプションを取り込む

URLを貼り付け、設定を取得して有効化

  1. プロバイダーのサブスクリプションページで、現在のコアに対応する形式を選び、サブスクリプションURLをコピーします。アカウント管理画面のURLではなく、リンクそのものをコピーしてください。
  2. クライアントの「サブスクリプション」画面を開きます。「サブスクリプションURL」の入力欄があれば、そこに貼り付けます。新規作成画面を使う場合は「新規作成」から「リモート」を選び、URLを入力してください。
  3. URLの先頭や末尾に余分な空白、改行、日本語の句読点が入っていないか確認します。クエリパラメーターはそのまま残し、疑問符以降をむやみに削除しないでください。
  4. 「インポート」をクリックするか、リモート設定を保存し、設定カードが表示されるまで待ちます。成功すると設定名や更新時刻が表示されます。入力欄が空のままなら、取り込みが完了していません。
  5. 取り込んだ設定を選択し、「プロキシ」画面でプロキシグループを確認します。インポートの成功と設定の有効化は別です。設定カードが一覧にあっても、コアがその設定に切り替わったとは限りません。

初回の取得では、サブスクリプションサーバーに接続できるネットワークが必要です。クライアントに「直接接続」「システムプロキシ」などの取得方法がある場合は、実際のネットワーク環境に合わせて選んでください。既存のプロキシが使えない状態で、そのプロキシ経由で取得しようとすると、更新にはプロキシが必要なのにプロキシは更新待ちという循環に陥ることがあります。まず直接接続で更新するか、サーバーに接続できるネットワークを利用してください。

インポート後はログを確認してから接続テスト

ログに設定の解析エラーがないか確認し、プロキシグループに選択可能なノードがあるかを確認します。まずは動作モードを「ルール」に設定し、ブラウザーの通信をプロキシ経由にする必要がある場合はシステムプロキシを有効にします。通常のHTTPプロキシ設定では、すべてのアプリのUDP通信を処理できません。TUNを有効にするかどうかは、基本的な接続確認が済んでから個別に判断してください。

設定に mixed-port: 7890 とある場合、HTTPとSOCKSのクライアントは同じローカルポートに接続できます。ただし、GUIクライアント側のポート設定が設定ファイルの値を上書きすることがあります。設定画面に表示される実際の待受アドレスとポートを確認し、ネット上の例だけを根拠に、この端末が必ず 127.0.0.1:7890 だと決めつけないでください。

方法2:クリップボードからURLまたは設定テキストを取り込む

クリップボードの内容を確認してから、対応する方法で取り込みます。macOSでのコピーと貼り付けは ⌘C、⌘V、Windowsでは Ctrl+C、Ctrl+V です。ショートカットはテキストを渡すだけで、ノードのリンクを完全なClash設定に自動変換するものではありません。

コピーした内容おすすめの取り込み方法確認するポイント
https:// で始まるサブスクリプションURLリモートサブスクリプションURLの入力欄トークンとパラメーターがすべて残っているか
proxies: などの項目を含むYAMLテキストローカル設定エディターまたはテキストのインポートインデントが崩れていないか、説明文が混ざっていないか
ss://、vmess:// などのノードURIクライアントがノードのインポート機能を明示的に提供している場合に利用プロトコルへの対応とノード変換が可能か
長いBase64文字列取得元とデコード後の内容を確認完全なYAMLとは限らない
  1. コピーしたものがURLなら、「サブスクリプション」画面に戻って貼り付け、インポートします。以降はリモートサブスクリプションとして管理してください。
  2. コピーしたものがYAML一式なら、ローカル設定の新規作成または編集画面を開きます。クライアントにテキスト入力欄がない場合は、プレーンテキストエディターで .yaml ファイルとして保存し、ローカルファイルとしてインポートしてください。
  3. 単一のノードURIだけをコピーした場合は、クライアントがそのプロトコルのノードインポートに対応しているか確認します。完全な設定には通常、プロキシグループやルールも必要です。ノードの接続情報だけではそれらを代用できません。

チャットツールからコードをコピーする場合、コードブロックの囲み、行番号、「コピー」などの画面表示を一緒に貼り付けないでください。YAMLではインデントに半角スペースを使います。Tab文字が含まれると解析に失敗しやすくなります。エディターのスマートクォートやリッチテキスト形式によって内容が変わる場合もあるため、UTF-8のプレーンテキストで保存してください。

方法3:ローカルのYAMLファイルをインポート

「サブスクリプション」または「設定」画面で「ファイルをインポート」を選び、ディスク上の .yaml または .yml ファイルを指定します。ファイルのドラッグ&ドロップに対応するクライアントもあります。インポート後に設定を選択し、ログとプロキシグループを確認してください。選択できる拡張子は、クライアント画面の案内に従ってください。

まずファイルの内容を確認してから利用可否を判断

ファイル名が config.yaml でも、内容がダウンロード失敗時のHTMLページである可能性があります。テキストエディターで開き、先頭が <!doctype html>、ログイン案内、JSON形式のエラーメッセージなら、YAMLのインデントを直すのではなく、取得元に戻って認証やアクセスの問題を解決してください。

以下は、設定の構造を確認するための最小限の直接接続サンプルです。プロキシノードは含まれておらず、項目や解析動作の確認にのみ使えます。サブスクリプション設定の代わりにすると、プロキシ接続はできません。

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

rules:
  - MATCH,DIRECT
  • mixed-port はHTTPとSOCKSが共用するローカルの待受ポートです。ポートが使用中の場合は、設定ファイルまたはクライアントの設定を変更してください。
  • allow-lan: false はLANからのアクセスを制限します。共有が必要な場合にのみ、待受アドレス、ファイアウォール、認証設定を確認してください。
  • MATCH,DIRECT は残りの通信を直接接続にします。特定のプロキシノードが選択されたことを意味するわけではありません。

ローカルファイルはスナップショット。外部リソースには通信が必要な場合も

一般的なローカル設定には、サブスクリプションURLによる自動更新の仕組みがありません。プロバイダーがノードのパスワードやサーバーアドレスを変更した場合は、再インポートするか、ローカル設定を手動で更新してください。ただし、ファイル内でリモートの proxy-providers や rule-providers が指定されていれば、それらのリソースは個別にネットワーク経由で更新される場合があります。「ローカルファイルからインポート」しても、実行中に一切通信しないとは限りません。

長期的に使うルールの変更は、クライアントが提供するオーバーライド、マージ、スクリプト機能を使うのがおすすめです。リモートサブスクリプションの取得内容を直接編集すると、次回更新で上書きされる場合があります。オーバーライドを適用した後は、最終的に有効な設定を確認し、プロキシグループ名とルールの参照先が一致しているか確認してください。

形式の違い:Clash YAML、Base64、ノードURI

サブスクリプションURLは内容を取得するためのアドレスで、YAMLとBase64は内容の構造やエンコード方式を指します。どちらもHTTPSで始まるURLでも、返される内容は異なる場合があります。「サブスクリプションにアクセスできるのにインポートできない」ときは、拡張子だけで判断せず、レスポンス本文を確認してください。

形式主な内容インポート時の注意点
Clash YAML一式ノード、プロキシグループ、ルールなどの設定項目コアが使用されているプロトコルと設定項目に対応している必要があります
ノードプロバイダー用YAML主に proxies: を含むノード一覧通常は proxy-providers でメイン設定に組み込みます
Base64形式のサブスクリプションエンコードされた複数行のノードURIが一般的クライアントの変換機能が必要です。拡張子を変えるだけでは変換できません
単一のノードURI1台のサーバーのプロトコルと接続パラメーター通常はプロキシグループと振り分けルールも作成する必要があります

Base64はエンコード方式であり、暗号化ではありません。また、統一されたプロキシ設定の規格でもありません。デコードすると複数行のノードリンクになる場合も、別のテキストになる場合もあります。利用できるかどうかは、実際の内容とクライアントの対応状況によります。ファイル名を .txt から .yaml に変更しても、形式は変換されません。

Clash Meta(現名称:mihomo)が対応するプロトコルや設定項目は、従来のClashコアと完全には一致しません。未対応のノード形式がある場合は、まず現在使用中のコアを確認し、サブスクリプションの提供元で対応する形式を選んでください。プロバイダーがClash用とmihomo用の両方を提供している場合、mihomoコアではmihomo対応と明記された入口を優先してください。

自動更新間隔の設定:クライアントのサブスクリプションとproviderは別々

リモートサブスクリプションのカードメニューから「編集」または更新設定を開き、「更新間隔」を探します。入力欄の単位を先に確認してください。単位が分なら 360 で6時間、秒なら 21600 で6時間です。同じ時間を表す値ですが、単位を確認せずに入力しないでください。

  1. まず手動で一度更新し、現在のURLにアクセスでき、正常に解析されることを確認します。
  2. プロバイダーの推奨に合わせて間隔を設定します。特に指定がなければ、まず6時間に設定し、ノードの変更頻度に応じて調整してください。
  3. カードに表示される更新時刻と更新ログを確認し、間隔の値を保存しただけでなく、更新処理が実行されたことを確かめます。
  4. パソコンがスリープ中、またはクライアントが終了している間は、GUIクライアントの定期更新は通常実行されません。復帰後すぐに更新されるかどうかは実装によります。必要に応じて手動で更新してください。

mihomo設定のHTTPタイプの proxy-providers と rule-providers には、それぞれ個別の interval フィールドがあり、単位は秒です。たとえば interval: 21600 は6時間を表します。更新されるのはノード一覧またはルール一覧であり、クライアントに保存されたリモートサブスクリプション全体の再取得とは異なります。ノードのヘルスチェックにある health-check.interval も別の更新間隔です。

すべてのクライアントで 0 が自動更新の無効化を意味するとは限りません。無効にする方法、設定できる最短間隔、再試行の動作は画面の説明を確認してください。通信量や有効期限は通常サーバーから返される情報であり、すべての提供元が表示に必要な情報を提供するわけではありません。表示がないだけで設定が無効とは限りません。

よくあるエラー:リクエスト、解析、有効化の順に確認

ダウンロードに失敗する場合:HTTPステータスとネットワークを確認

  • 401または403:トークンの有効期限切れ、サブスクリプションの期限、サーバー側のアクセス制限を確認してください。403はアクセス方針によって返される場合もあり、ステータスコードだけで原因を決めつけることはできません。
  • 404:URLのパスを完全にコピーしたか、プロバイダーがサブスクリプションのURLを変更していないか確認してください。
  • タイムアウトまたは証明書エラー:ネットワーク、システム時刻、リクエスト先を確認してください。証明書の検証を恒常的に無効にして問題を隠さないでください。

解析に失敗する場合:エラー行周辺の元データを確認

YAMLエラーが出た場合は、インデント、コロンの後のスペース、HTMLの混入を確認します。未知のプロキシタイプや設定項目のエラーが出た場合は、コアとの互換性を確認してください。サーバーはリクエストのUser-Agentに応じて異なる形式を返す場合があります。ブラウザーで正常に開けても、クライアントが同じ内容を取得しているとは限りません。クライアントのダウンロードログも確認してください。

設定は有効だが接続できない場合:有効な設定と通信の取り込み方を確認

新しい設定が選択されていること、プロキシグループが実際に使えるノードを指していることを確認し、システムプロキシまたはTUNが意図どおり通信を取り込んでいるかを調べます。サブスクリプションのインポート、設定の解析、ノードへの接続、DNS解決はそれぞれ別の段階です。ノードの遅延テストに成功しても、すべてのWebサイトにアクセスできるとは限りません。接続パネルで対象ドメイン、適用されたルール、出力先のポリシーを確認すると、何度もインポートし直すより原因を絞り込めます。

問題なく使える設定を1つ保存し、更新の前後で設定名、更新時刻、エラーメッセージを記録しておくと便利です。問い合わせる際は、クライアント名、コアの種類、インポート方法、個人情報を伏せたログを共有してください。サブスクリプションURL全体やノードのパスワードは公開しないでください。