サブスクリプションを登録する前に：URL・形式・コアを確認
ClashのサブスクリプションURLは、リモート設定を取得するためのアドレスであり、単一のプロキシノードを指すものではありません。クライアントがURLにアクセスして設定を取得・保存し、その設定をコアで実行します。登録が成功したということは、設定の取得と解析ができたという意味にすぎません。利用可能なノードがあるか、ルールが正しいプロキシグループを参照しているかは、別途確認が必要です。
Clash Nyanpasuはデスクトップ向けの設定管理クライアントです。対応プロトコルは、選択したコアとそのバージョンによって異なります。Clash Metaの後継プロジェクトはmihomoです。mihomo向けの設定には、旧バージョンのClashでは認識されない項目が含まれることがあります。サブスクリプションサービスに複数の形式が用意されている場合は、汎用のノードリストをそのままコピーせず、使用中のコアに合ったClash形式またはmihomo形式を選びましょう。
- URLの取得元：サブスクリプションサービスのアカウントページから、HTTPSのURL全体をコピーしてください。ブラウザーで開いているアカウント管理ページのアドレスではありません。
- 出力形式：Clash YAML、Clash Meta、mihomoのいずれかであることを確認し、サービス提供元の形式に関する説明も確認してください。
- 認証情報：クエリパラメーターは削除せず、そのまま残してください。URL内のトークンは通常、認証に使われます。パラメーターを途中で切ると、リクエストが拒否されることがあります。
- 現在の設定：既存の設定名と使用中のプロキシグループを控えておきましょう。登録後に元の状態へ戻す際の手がかりになります。
Clash NyanpasuにサブスクリプションURLを登録する手順
ここでは「リモート設定」として登録する手順を説明します。ボタン名はバージョンによって「新規作成」「インポート」などと表示されたり、プラスアイコンになったりしますが、基本的な流れは同じです。プロファイル管理画面でリモート設定を作成し、URLを入力して取得した後、その設定を選択します。サブスクリプションURLをシステムプロキシのアドレスや外部コントローラーのアドレスに入力しないでください。
- プロファイル画面を開く。クライアントのサイドバーから「プロファイル」画面に進み、新規作成またはインポートの項目を探します。「ローカル」と「リモート」を選べる場合は、リモートを選択してください。
- 区別しやすい名前を付ける。たとえば「普段使い・メイン回線」のように設定します。名前はローカルで管理するためのもので、サービスから返されるノードの内容には影響しません。
- URL全体を貼り付ける。先頭が
https://で始まっていること、末尾に余分な空白や改行、日本語の引用符が付いていないことを確認します。URL内の&と=はクエリパラメーターの区切り文字なので、手動で削除しないでください。 - インポートして結果を確認する。ダウンロード失敗、認証エラー、YAML解析エラーなどが表示されないか確認します。エラーが出ても元の設定は残し、同じ設定を何度も作成しないでください。
- 新しい設定を選択する。プロファイル一覧で、新しく作成した設定を現在の使用項目に指定します。リモート設定を保存しただけでは、実行中の設定が切り替わらない場合があります。
- プロキシとルールを確認する。プロキシ画面を開き、ノードやプロキシグループが表示されているか確認します。続いてログを確認し、ポリシーグループの不足や未知のプロキシタイプなどのエラーがコアから報告されていないか確認してください。
登録後はまず基本動作を確認する
まずルールモードのまま、実際のプロキシノードを選択して確認対象のサイトにアクセスし、接続履歴で適用されたルールと出力先を確認します。ノードの遅延テストに成功しても、それはテスト先への接続結果を示すだけで、すべてのサイトにアクセスできることを意味しません。設定にDIRECTしかない場合、選択できるプロキシノードがありません。「設定が有効になった」ことを、プロキシが使える証拠と考えないでください。
システムプロキシとTUNは、通信を取り込むための方式です。サブスクリプションをノードに変換する機能ではありません。最初のトラブルシューティングでは、DNS、TUN、ルーティングを同時に変更せず、まずシステムプロキシを使って確認しましょう。ブラウザーでプロキシを使えるかどうかは、ブラウザー側の設定にも左右されます。システムプロキシを参照しないアプリでは、個別に設定するか、適切な接続方式を使う必要があります。
Clash YAML・Base64・単一ノードURLの違い
ファイルの拡張子やURLの見た目だけでは、サブスクリプションの形式を判断できません。.yamlで終わらないURLからClash設定が返されることもあれば、.yamlで終わるURLからログインページが返されることもあります。実際にサーバーから返された本文と、対象のコアが求める設定構造に合っているかを確認してください。
| 形式 | よくある特徴 | インポート時の扱い |
|---|---|---|
| Clash YAML設定一式 | proxiesまたはproxy-providersを含み、プロキシグループやルールが定義されている | コアとの互換性を確認してから、リモート設定としてインポートする |
| Base64形式のノードリスト | 本文はエンコードされたテキストで、デコードすると通常は複数行のノードURIになる | まず対象のコアに対応したYAML設定へ変換する |
| 単一ノードURI | ss://、vmess://、trojan://などのプロトコルで始まる | 対応プロトコルを扱えるインポートツールで処理してから、設定に追加する |
| Proxy Provider用YAML | トップレベルにproxies:があり、ノードだけが列挙されていることが多い | 通常はproxy-providersのデータソースとして使用する |
| HTMLまたはJSONのエラーレスポンス | ログイン要求、期限切れの案内、エラーコード、WebページのHTMLなど | URLやアカウントの状態を修正し、設定としてはインポートしない |
YAMLを解析できても、設定が動作するとは限らない
YAMLはデータの表現形式です。「コロンがあり、インデントされている」だけでは、設定として使えるかどうかは判断できません。以下は階層構造を示すための最小設定例です。待ち受けポートは7890で、プロキシグループには直接接続しか含まれていないため、プロキシ機能はありません。実際のサブスクリプションには、ノード定義、またはノードを読み込むProxy Providerが必要です。
mixed-port: 7890
mode: rule
log-level: info
proxies: []
proxy-groups:
- name: 手動選択
type: select
proxies:
- DIRECT
rules:
- MATCH,手動選択proxy-groupsのメンバーは、定義済みのノード、ほかの有効なプロキシグループ、または組み込みの出力先として解決できる必要があります。上の例にあるMATCH,手動選択はプロキシグループ名を参照しているため、名前を完全に一致させてください。Proxy Providerを使う場合は、グループ内のuseが実在するプロバイダー名を参照していることも確認します。各項目の詳細はYAML設定ガイドをご覧ください。
Base64をデコードしても設定変換にはならない
Base64はデータのエンコード方式であり、ルールやプロキシグループ、DNS設定を提供するものではありません。また、暗号化でもありません。デコードしても、ノードURIが複数並んでいるだけの場合があります。実際に変換するには、プロトコルのパラメーターを解析し、対象コアの項目に対応付け、プロキシグループを作成してルールを追加する必要があります。元ファイルの名前をconfig.yamlに変えても、これらの処理は行われません。
サブスクリプション変換：まず公式形式を選び、必要な場合だけ変換する
サービス側にClashまたはmihomo形式の接続先が用意されている場合は、そちらを優先してください。項目の対応付けやテンプレートの違いによる問題を減らせます。汎用のノードサブスクリプションしかなく、現在のクライアントで設定として直接使えない場合に限り、変換を検討しましょう。
- 元の形式を確認する。設定一式、ノードリスト、Proxy Provider用ファイルを区別します。ノードリストにはルーティングルールが含まれないため、変換後も元の振り分けルールが保たれるとは限りません。
- 対象のコアを選ぶ。変換先としてmihomoを指定する場合、実行中のコアも互換性のあるものにしてください。変換ツールを使っても、旧コアに新しいプロトコルへの対応が追加されるわけではありません。
- 管理できる変換方法を選ぶ。ローカルで実行する方法や、自分で管理する変換サービスを優先しましょう。リモートの変換サービスには、元のサブスクリプションURLと返されるノードの認証情報を渡すことになります。
- 変換後の内容を確認する。ノード数、プロトコルの種類、TLSパラメーター、プロキシグループ名、最後の
MATCHルールを確認し、独立したテスト用設定としてインポートします。
更新間隔と手動編集：2種類のサブスクリプションを区別する
リモート設定の更新とProxy Providerの更新は、別々の仕組みです。前者はクライアントが設定一式を再ダウンロードし、後者はコアがproxy-providersの設定に従ってノードファイルを更新します。参照するURLが異なる場合もあり、更新間隔をそろえる必要はありません。
クライアントのリモート設定を更新する
「プロファイル」画面で対象の項目の編集画面を開き、更新間隔または自動更新の設定を探します。入力単位はバージョンによって分単位の場合もあれば、別の形式で表示される場合もあるため、項目の横に記載された単位を確認してください。たとえば単位が分なら360は6時間、秒なら6時間は21600です。単位を確認せずに数値だけをそのまま入力しないでください。
更新頻度が低いサブスクリプションなら、まず6時間ごとの更新に設定し、ノードが一時的に使えなくなった場合やサービス提供元から変更の通知があった場合に手動で更新するとよいでしょう。サービス提供元がリクエスト頻度を指定している場合は、その制限に従ってください。クライアントを終了している場合、端末がスリープ中の場合、ネットワークに接続していない場合は、自動更新が壁時計どおりに実行されるとは限りません。
コアのProxy Providerを更新する
mihomoの設定では、HTTPタイプのProxy Providerにあるintervalの単位は秒です。以下の例では、3600秒ごとにプロバイダーファイルを更新します。URLは形式を示すためのもので、実際のサブスクリプションには使用できません。この設定は設定一式に追加し、プロキシグループからuseで参照する必要があります。
proxy-providers:
remote-nodes:
type: http
url: "https://example.net/clash-provider.yaml"
path: ./providers/remote-nodes.yaml
interval: 3600ダウンロードしたリモート設定ファイルのルールを直接編集すると、次回の更新で上書きされる場合があります。個別のルールやポート、DNSの変更を保持するには、現在のバージョンが対応するオーバーライドまたはマージ機能を使い、生成後の設定を確認してください。ローカルでの編集がサブスクリプションサービスに反映されるとは限りません。また、元のサブスクリプションと個別の変更を、復元しにくい1つのファイルにまとめないようにしましょう。
サブスクリプションの登録に失敗したときの確認手順
「リクエストが成功したか → 返された形式は正しいか → コアに互換性があるか → 通信が取り込まれているか」の順に確認します。一度に変更する項目は1つにし、エラーがダウンロード時とコア起動時のどちらで発生したか記録してください。原因によって対処方法が異なります。
| 症状 | まず確認する項目 | 次に行うこと |
|---|---|---|
| HTTP 401または403 | トークン、アカウント権限、サーバー側のアクセス制限 | アカウントページからURLをコピーし直し、サービス提供元の案内を確認する |
| HTTP 404 | URLのパスが完全か、古い接続先が無効になっていないか | 現在有効な接続先を使い、APIのパスを推測して入力しない |
| HTTP 429 | 更新リクエストの頻度が高すぎないか | 連続した再試行をやめ、サーバー側の制限に従って時間をおいて更新する |
| タイムアウトまたはドメインの名前解決に失敗 | 現在のネットワーク、DNS、ダウンロードリクエストの通信経路 | サブスクリプションのドメインに接続できることを確認し、更新時のプロキシ設定を調べる |
| YAML解析エラー | レスポンスがWebページではないか、インデントが崩れていないか | レスポンス本文を確認し、正しい形式の接続先を選ぶ |
| 未知のプロキシタイプまたは設定項目のエラー | コアのバージョンと出力対象 | 対応するコアに切り替えるか、互換性のある設定を使う |
| インポート済みだが通信がない | 設定が有効か、プロキシグループ、システムプロキシ | 接続履歴と実際の出力先を確認し、何度もインポートし直さない |
ブラウザーではURLを開けるのに、クライアントで失敗するのはなぜ？
ブラウザーとクライアントでは、通信経路が異なることがあります。ブラウザーはログインCookieを送信していたり、すでに使えるプロキシ経由でアクセスしていたりする場合があります。一方、クライアントのサブスクリプション取得リクエストは直接接続する場合もあれば、異なるリクエストヘッダーを使う場合もあります。User-Agentに応じて返す形式を変えるサービスもあります。そのため、ブラウザーに内容が表示されても、クライアントが同じYAMLを受信しているとは限りません。
サブスクリプションのドメインへのアクセスにプロキシが必要な場合は、まず利用できる設定を1つ残したうえで、現在のバージョンに更新時のプロキシ設定があるか確認してください。新しいサブスクリプションを取得するために、唯一使える古い設定を先に削除しないでください。ログを共有する前にURL全体を隠し、特にリクエストパスとクエリパラメーター内の認証情報を伏せてください。
インポート後のチェックリスト
- 使用中の設定名が正しく、最後の更新結果を確認できる。
- ノードとプロキシグループが読み込まれ、ルールが参照する名前に不足がない。
- 更新間隔の数値と単位が一致し、分と秒を取り違えていない。
- 接続履歴に想定したルールと出力先が表示され、アプリの通信が実際にコアへ届いている。
- 個別の変更は継続して使えるオーバーライド方法で保存され、元の設定に戻せる。
サブスクリプションの登録では、「URLの応答内容」「設定の構造」「実行するコア」の3つを一致させることが重要です。まず形式と認証の問題を解決し、その後にルールと通信の取り込みを確認すれば、ネットワークの問題をYAMLの問題と誤認しにくくなります。初めて使う場合は、クイックスタートガイドを参考に、システムプロキシの設定と基本的な接続を確認してください。Profileやプロキシグループなどの用語は、用語集をご覧ください。