ClashのサブスクリプションURLをインポートする方法：完全なYAML、ノード一覧、共有リンクの違い

1. 入力内容を見極めてからインポート先を選ぶ

「リンクをコピーしてインポート」は、クライアントが認識できる入力にのみ使えます。サブスクリプションURLはコンテンツを取得するためのアドレス、YAMLは設定テキストの形式、単一ノードの共有リンクは特定ノードのパラメータを運ぶものです。この3つは同じ階層ではありません。同じHTTPSアドレスでも、完全な設定、ノード一覧、ログインページのいずれかが返る可能性があります。ブラウザーで開けるからといって、Clashの設定として読み込めるとは限りません。

クライアントは画面表示、サブスクリプションのダウンロード、設定管理を担い、ClashやClash Meta（mihomo）などのコアは、有効な設定の解析、プロキシ接続の確立、ルールの照合、DNS処理を担当します。一部のクライアントには形式変換機能がありますが、すべてのClashクライアントが任意の共有リンクを直接インポートできるわけではありません。開始前に「About」またはコア情報の画面で、クライアントのバージョンとコアのバージョンを記録しておきましょう。両者を置き換えて考えることはできません。

手元にある内容	典型的な特徴	探すべき入口
リモートサブスクリプションURL	`https://`で始まり、認証パラメータが付く場合がある	リモート設定、URLインポート、またはサブスクリプションの新規作成
ローカルYAMLファイル	通常は`.yaml`または`.yml`で、構造化されたテキストが入っている	ローカル設定、ファイルからインポート
ノードプロバイダーの内容	トップレベルが`proxies:`で、プロキシグループとルールがないことが多い	メイン設定の`proxy-providers`から参照する
単一ノードの共有リンク	`ss://`、`vmess://`、`trojan://`などで始まる	クライアントが明示的に提供するノードインポートまたは変換の入口

2. サブスクリプションURLのインポート：ダウンロード、選択、適用の3段階

まず現在のコアに対応したサブスクリプションURLを取得する

サブスクリプション提供元の管理画面で、クライアントのコアに合ったClashまたはmihomo用の出力を選びます。アカウントページのアドレスをそのままコピーしたり、「ワンクリックインポート」ボタンのクライアント起動用プロトコルをHTTPSサブスクリプションURLとして扱ったりしないでください。提供元が旧Clashとmihomoを区別している場合は、デスクトップ上のショートカット名ではなく、実際に動作しているコアを基準に選びます。

コピー結果を確認：リンクの前後に引用符、空白、チャットアプリが付加した句読点がないことを確認します。元の認証パラメータは残してください。パラメータを変更すると、サーバーにアクセスを拒否されることがあります。
リモート設定を作成：クライアントの「設定」または「サブスクリプション」ページを開き、URL入力欄またはリモート設定の新規作成入口を探します。アドレスを貼り付けてダウンロードしてください。ボタン名や配置はクライアントによって異なります。
インポート結果を確認：設定一覧に新しい項目が追加され、更新時刻、ノード数、ダウンロードエラーを確認できることを確認します。設定名が表示されるだけでは、内容が正しく解析された証拠にはなりません。
選択して適用：新しい項目を現在の設定にします。インポート後も古い設定が使われるクライアントがあるため、設定カードをもう一度クリックするか、適用操作を実行してください。
動作状態を確認：コアが動作しているか、プロキシグループが表示されているか、未知のプロトコルや存在しない宛先に関するエラーがないかを確認してから、接続テストを行います。

ProfilesページとURL入力欄がある旧版のClash for Windows画面を例にすると、通常の手順はProfiles → URL入力欄 → Downloadで、その後に対応する設定カードを選択します。これは旧画面の入口例にすぎず、現在も保守されていることを示すものではありません。また、すべてのクライアントに適用できるわけではありません。新しいクライアントでは、「リモート設定」という機能の意味から対応する入口を探してください。

初回インポートでTUNを有効にしたり、DNSを変更したり、すべてのルールを入れ替えたりする必要はありません。まず設定を読み込めることを確認し、次にプロキシの適用方法を確認すれば、問題の範囲を1つの段階に絞れます。サブスクリプションのダウンロード自体に既存のプロキシが必要な場合は、動作する古い設定を使うか、提供元が対応するネットワーク経路から取得してください。新しい設定がまだダウンロードされていない段階で、それ自身のダウンロード問題を解決させることはできません。

3. ローカルYAML：内容の完全性と参照関係を確認する

ローカルインポートは、オフライン設定、バックアップからの復元、手動編集に適しています。ファイル拡張子は手がかりにすぎません。ウェブページをconfig.yamlに名前変更しても、設定にはなりません。プレーンテキストエディターでファイルを開き、<html>、ログイン案内、APIエラーなどが含まれていないか確認します。YAMLのインデントにはスペースを使い、Tabを混在させないでください。エディターでは実際の拡張子を表示し、config.yaml.txtとして保存されるのを防ぎます。

完全な設定は「proxiesが含まれていれば十分」ではない

想定したプロキシ振り分けを行える設定には、通常、ノードまたはノードプロバイダー、プロキシグループ、ルール、適切なリスニング設定が必要です。各フィールドが必須かどうかは、コアのデフォルト値とクライアントの生成方式によって異なります。ただし、ルールの宛先は解析可能でなければなりません。ルールがProxyを指すなら、同名のプロキシグループまたはノードが必要であり、画面に表示される名前だけから存在を判断することはできません。

# 設定例：構造のみを確認し、リモートプロキシノードは含まない
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,Proxy

ローカルファイルをインポートした後、そのファイルに元のサブスクリプションの自動更新関係が保たれているとは限りません。クライアントがファイルを独自の設定ディレクトリにコピーする場合もあれば、元のパスを直接参照する場合もあります。デスクトップ上の元ファイルを編集しても、実行中のコピーに反映されないことがあります。現在の設定項目にある編集または表示機能で実際の内容を確認してから変更し、再読み込みしてください。操作前に、config-backup-2026-06-16.yamlのような日付付きバックアップを保存しておきます。

ファイルでproxy-providersまたはrule-providersを使っている場合、ローカルYAMLは入口にすぎず、起動時に外部リソースのダウンロードが必要になることがあります。メインファイルをコピーしても、すべての依存関係がコピーされるわけではありません。プロバイダーのパス、リモートアドレス、キャッシュが利用可能か確認してください。特に別の端末へ設定を移行する場合は、元の端末の絶対パスをそのまま使わないでください。

4. ノード一覧または共有リンクしかない場合の対処

ノード一覧はメイン設定で組み込む必要がある

トップレベルにproxies:しかないYAMLは、ノードプロバイダーとして使われることが多い形式です。利用可能なノードは記述されていますが、アプリが使うローカルポート、プロキシグループ、振り分けルールまでは定義されていない場合があります。メイン設定としてインポートすると、必要な構造を補完するクライアントもあれば、ノードだけを表示したり、直接エラーを出したりするクライアントもあります。特定クライアントの補完動作を一般的な形式仕様とみなさないでください。

プロバイダーに対応したコアでは、通常、メイン設定のproxy-providersで名前付きリソースを定義し、プロキシグループからuseで参照します。プロバイダー名は一致していなければならず、リモートリソースもコアが対応するノード形式でなければなりません。通常のサブスクリプションURLをこのフィールドに入れるだけで、コアが任意のBase64ノードサブスクリプションをデコードすると考えてはいけません。関連フィールドは設定リファレンスのノード説明で確認できます。

共有リンクでは解析能力とプロトコル対応の両方を確認する

単一ノードURI：ss://などのリンクには1つのノードのパラメータが含まれますが、完全な振り分けルールは含まれません。クライアントがその形式のインポートに明示的に対応している場合にのみ、直接利用できます。
複数行URIまたはBase64テキスト：汎用ノードサブスクリプションの場合がありますが、完全なClash YAMLではありません。提供元の互換形式の出力を使うか、信頼できるツールで変換する必要があります。
プロトコルと転送パラメータ：変換後も、プロトコル、ポート、TLS、SNI、転送パスなどを確認してください。旧Clashコアはmihomoと同じものではなく、同じプロトコルやフィールドに対応しているとは限りません。

「未知のプロトコル」と表示された場合は、まず現在のコアの対応範囲を確認します。接続ハンドシェイクエラーが出た場合は、元のパラメータと照合してください。認識できないフィールドを削除して無理にエラーを消そうとしないでください。そのフィールドが、サーバー側で要求される転送または認証パラメータである可能性があります。クライアントを変更する場合は、まず選び方ガイドでプラットフォームとコアの関係を確認してから設定を移行します。

5. サブスクリプション更新失敗：レスポンス、解析、接続の順に切り分ける

「更新失敗」には少なくとも3種類あります。リクエストで内容を取得できない、取得した内容を解析できない、解析は成功したがノードに接続できない、の3つです。ノードの遅延テストに失敗しても、サブスクリプション更新の失敗とは限りません。同様に、HTTPリクエストが成功しても設定が正しいとは限りません。まず設定の更新時刻とダウンロードログを確認し、次にコアのエラー、最後に実際の通信をテストします。

具体的なシグナル	優先して確認する項目	次に行う操作
HTTP 401または403	トークンの期限切れ、アカウント権限、アクセス制限	サブスクリプションURLを再取得してアカウント状態を確認します。403はアクセス保護が原因の場合もあります。
HTTP 404	アドレスのパス変更、コピーの欠落	提供元が現在生成しているアドレスと照合し、パスを手動で推測しない
HTTP 429	更新頻度が高すぎる	連続再試行を止め、レスポンスの案内または提供元のルールに従って待つ
HTTP 200だが解析エラー	ウェブページ、エラーJSON、または互換性のないノード形式が返っている	ローカルでレスポンスの冒頭とエラー行を確認し、対応形式を確認する
DNS失敗または接続タイムアウト	サブスクリプションドメインの名前解決とダウンロードに使われる経路	ローカルのネットワーク接続、既存のプロキシ、サブスクリプション更新時のプロキシ設定を確認する
TLS証明書エラー	システム時刻、証明書チェーン、認証ポータル、ネットワークによる遮断	時刻を調整してネットワーク状態を確認し、証明書検証の無効化を通常の修復方法にしない

ブラウザーでは正常にダウンロードできるのにクライアントで失敗する場合は、リダイレクト、ログインCookie、リクエストヘッダー、提供元のクライアント識別ポリシーも確認します。ブラウザーはログイン済みのためファイルを取得できても、クライアントにはログインページが返ることがあります。逆に、サーバーがUser-Agentに応じて異なる内容を返す場合もあります。対処法は、対象クライアント向けのサブスクリプション入口を取得することであり、ブラウザーのログインセッションを関係のないソフトウェアへコピーすることではありません。

yaml: line 12のようなメッセージが出たら、12行目とその直前の行のインデント、引用符、コロンを確認します。エラー行はパーサーが異常を発見した位置であり、最初に書き間違えた位置とは限りません。リモート内容そのものに問題がある場合は、まず提供元へ連絡するか、提供元が対応する出力形式に切り替えてください。ローカルで一時的に修正しても、次回更新時に元のエラー内容が再取得される可能性があります。

6. 更新でローカル変更が上書きされる場合：サブスクリプションと上書きを分ける

リモートサブスクリプションは通常、再ダウンロードできる元ファイルです。そこへ直接ルールを追加したり、ポートを変更したり、プロキシグループ名を変更したりすると、次回更新で上書きされることがあります。これは内容の更新方式による結果で、保存に失敗したとは限りません。クライアントの実行設定は「サブスクリプション内容＋グローバル設定＋上書き」を統合して生成される場合もあるため、ある階層を編集したら最終的に適用される値を確認してください。

サブスクリプション原本を保持：リモートURLと自動更新はリモート設定の記録に残し、復元しにくい手動編集版を唯一のコピーにしない
変更を分けて保存：クライアントに上書き、マージ、スクリプト機能がある場合は、それを使ってカスタムルールや設定を保存します。具体的な適用順序は、そのクライアントの実装に従ってください。
配列の動作を確認：rulesとproxy-groupsは置き換え、先頭への追加、末尾への追加などの動作になる可能性があります。すべてのマージ方式が同じだと考えないでください。
ルールの順序を再確認：ルールは通常、順番に照合されます。カスタムルールをMATCHの後ろに置くと、多くの場合適用されません。ルールが参照するプロキシグループも、更新後に存在し続けている必要があります。
手動更新を1回実行：更新前後の有効な設定を比較し、サブスクリプションの更新が成功してカスタム設定も残っていることを確認してから、定期更新を有効にします。

7. インポート後の最小確認リスト

インポート成功の判断は、設定、コア、実際のリクエストという3つの層を確認する必要があります。最初から「すべてのノードをテストする」ことで基本確認を代用しないでください。遅延テストの宛先には到達できなくても、ブラウザーから同じノード経由で別のサイトへアクセスできる場合があります。逆に、遅延テストに成功しても、アプリがプロキシを使っているとは限りません。

設定層：新しい設定が選択されていること、更新時刻が今回の操作と一致すること、対象のプロキシグループが存在すること、グループ内でDIRECTではなく想定したノードが選択されていることを確認します。
コア層：解析失敗、ポート競合、未知のプロトコルに関するエラーがないことを確認します。実際のリスニングポートを確認し、チュートリアルにある7890をそのまま使わないでください。
適用層：デスクトップのシステムプロキシは、システムプロキシ設定に従うアプリに主に影響します。TUNは仮想ネットワークアダプター、ルーティング、権限に関係し、モバイル端末では通常VPNの許可が必要です。いずれも、誤ったサブスクリプション形式を修正するものではありません。
リクエスト層：既知の利用可能なウェブサイトへアクセスし、接続画面またはログ画面で、コアに到達したか、どのルールに一致したか、最終的にどのプロキシグループを使ったかを確認します。

明示的なプロキシリクエストでシステムプロキシの問題を切り分ける

デスクトップ端末にcurlがインストールされており、コアが実際にローカルの7890ポートでHTTPまたは混合プロキシを提供している場合は、次の診断コマンドを実行できます。Windowsではcurl.exeを使うと、PowerShell環境によっては同名エイリアスによって引数の扱いが変わる問題を避けられます。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

ここでの10秒は接続タイムアウトの上限、20秒はリクエスト全体の制限時間であり、実測遅延ではありません。HTTPレスポンスを受信できたことは、今回の明示的なプロキシリクエストがレスポンス処理まで完了したことを示しますが、リモートノードを使った証拠ではありません。ルールによっては直接接続が選ばれるためです。127.0.0.1:7890へ接続できないと表示された場合は、まずリスニングポートとコアの動作状態を確認します。明示的なリクエストは成功するのに通常のブラウザーだけ失敗する場合は、ブラウザーのプロキシ設定や他の適用機能との競合を確認してください。

最後に、機密情報を除いたエラー内容、クライアントとコアのバージョン、入力タイプ、再現手順を保存します。さらに調整する前に、クイックスタートの接続確認を参照し、毎回1つの変数だけを変更してください。これにより、問題がサブスクリプションの取得、設定の解析、プロキシ経路のどこで発生しているのかを特定しやすくなり、インポートや再インストールを繰り返すうちに手がかりを失うこともありません。