Clashの設定ファイルとサブスクリプション

Profile・設定ファイル・サブスクリプションリンク

ClashクライアントにおけるProfileとは、通常、コアが読み込む設定ファイルと、その管理情報を指します。設定ファイルはYAML形式が一般的で、拡張子は.yamlまたは.ymlです。管理情報には表示名、サブスクリプションURL、自動更新の間隔などが含まれることがありますが、設定ファイル本体に記述されているとは限りません。

サブスクリプションリンクは設定内容を取得するための入口であり、プロキシノードそのものではありません。クライアントがリンクにアクセスすると、サーバーからClash設定一式が返される場合もあれば、ノード一覧だけが返される場合もあります。インポートに成功したという表示だけでは、ノードが使えるか、ルールが正しいか、通信がプロキシ経由になっているかは判断できません。

3つの主要セクションの関係

設定を読み解くには、出力先の参照関係を追うと分かりやすくなります。proxiesでノードを定義し、proxy-groupsでノードやほかのプロキシグループをまとめ、rulesで接続の出力先を決めます。proxy-providersからノードを読み込む設定もあるため、ローカルのproxiesが空でも、必ずしも問題とは限りません。

proxies：ノードの接続設定

各ノードには通常、name、type、server、portのほか、プロトコルに必要な認証情報や通信方式の設定が含まれます。ノード名はほかの項目から参照するための識別子です。名前を変更した場合は、プロキシグループ内の参照先も合わせて変更してください。一方だけを変えると、ノードが見つからないという読み込みエラーが起きることがあります。

ノードの接続先地域、認証情報、サーバーポートは提供元が指定します。クライアントのローカル待ち受けポートをノードのサーバーポートに設定しないでください。また、名前だけでプロトコルを判断することもできません。「香港」や「予備」といった名前はラベルであり、接続プロトコルの選択には影響しません。

proxy-groups：手動選択と自動選択

• select：メンバーを手動で選択します。出口を明示的に固定したい場合に適しています。
• url-test：指定したURLへの接続テスト結果に基づき、自動で選択します。テスト結果はファイルのダウンロード速度と同じではありません。
• fallback：メンバーを順に確認し、先頭にある利用可能なメンバーを優先します。
• load-balance：対応する方式に従って接続を振り分けます。1つのダウンロード接続の帯域を単純に合算する機能ではありません。

ルールが参照するのはプロキシグループ名であり、「現在選択中のノード」ではありません。たとえば、ルールの出力先が「Web用出口」グループなら、そのグループと配下のグループで何が選択されているかを確認します。無関係な別のグループでノードを切り替えても、そのルールの出力先は変わりません。

rules：上から順にマッチング

よく使われるルールには、完全一致のDOMAIN、ドメインのサフィックス一致のDOMAIN-SUFFIX、IPアドレス範囲に一致するIP-CIDR、最後のフォールバックとして使うMATCHがあります。ルールモードでは通常、最初に一致したルールで出力先が決まります。具体的なルールは広範囲に一致するルールより前に置き、MATCHは最後に配置してください。

DIRECTとREJECTは組み込みの出力先で、それぞれ直接接続と拒否を表します。ルールの出力先には、定義済みのプロキシグループ名も指定できます。名前は大文字・小文字、空白、句読点を含めて完全に一致させてください。見た目が似ていても、全角カンマはルール内の半角カンマの代わりにはなりません。

最小構成でYAMLの構造を確認

以下は構造を理解するための直接接続の例です。リモートプロキシノードは含まれていないため、リモートプロキシサービスとしては利用できません。HTTPとSOCKSの混合待ち受けポートを7890に設定し、LANからのアクセスを無効にしたうえで、手動選択グループをルールと組み込みの直接接続先に接続しています。

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

proxies: []

proxy-groups:
  - name: 手動出口
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,手動出口

1. proxies: []は、このセクションでノードを定義していないことを示します。プロキシグループから組み込みのDIRECTを参照することはできます。
2. DOMAIN-SUFFIX,example.com,DIRECTは、サンプルドメインとそのサブドメインに一致します。構文の説明用であり、特定のサービスで必要な振り分けを示すものではありません。
3. 192.168.0.0/16はプライベートアドレス範囲です。no-resolveを指定すると、このIPルールのために名前解決を明示的に行いません。
4. 前のルールに一致しなかった接続は「手動出口」に送られます。この例では、そのグループに直接接続のメンバーだけが含まれています。

YAMLのインデントにはスペースを使い、Tabは使いません。この例では各階層を半角スペース2つでインデントしています。キーのコロンと値の間にはスペースを入れてください。名前に#などの特殊文字が含まれる場合は、引用符で囲みます。エラーを調べるときは、まずログに表示された行番号を確認し、その直前の行のインデントと引用符の閉じ忘れをチェックしてください。

サブスクリプションの追加と初回確認

Clash Verge Revの一般的な画面を例に説明します。まず「サブスクリプション」を開き、提供元から受け取ったサブスクリプションURL全体を入力欄に貼り付けてインポートします。バージョンによってボタンの表記は異なりますが、「サブスクリプションの追加」「内容の更新」「設定の有効化」は別の操作です。追加しただけでは、現在の実行設定に切り替わったことにはなりません。

1. 応答形式を確認する。提供元がClashまたはmihomo用として案内しているサブスクリプションを使用してください。ダウンロード結果がログインページやエラーメッセージ、エンコードされたノード情報の場合は、完全なYAML設定としてそのまま使わないでください。
2. Profileに名前を付ける。インポート後すぐに、見分けやすいローカル名を設定し、一覧で取得元を区別できることを確認します。
3. 使用する設定を有効にする。対象のProfileを選択し、コアの読み込みが完了するまで待ちます。エラーが出た場合は、同じURLを繰り返しインポートして重複を作るのではなく、まずログを確認してください。
4. プロキシグループを確認する。「プロキシ」を開き、必要なグループがあり、選択可能なメンバーが含まれていることを確認してから、使用する出口を選びます。
5. 通信がプロキシ経由になっているか確認する。まずシステムプロキシなど、いずれかの通信経路を設定します。対象のアプリで新しい接続を開始し、接続履歴から適用されたルールと出力先を確認してください。

実際の混合ポートが7890の場合は、次のコマンドでHTTPプロキシを明示してテストできます。「アプリがシステムプロキシを使っていない」のか「プロキシ自体が使えない」のかを切り分けるのに役立ちます。このコマンドで確認できるのは、今回のリクエストがローカルプロキシ経由で送信されるかどうかだけです。TUNやほかのアプリの通信も正常にプロキシ経由になることを証明するものではありません。

curl --proxy http://127.0.0.1:7890 --head --max-time 15 https://example.com/

ポート番号が異なる場合は、実際の値を使ってください。接続が拒否された場合は、クライアントが起動しているか、ポートで待ち受けているかを確認します。ローカルプロキシには接続できるものの、接続先へのリクエストに失敗する場合は、ノードの認証情報、接続先サイト、DNSのログを確認してください。すべてのエラーをサブスクリプションの無効化が原因だと決めつけないようにしましょう。

複数サブスクリプションの名前付けと切り替え

多くのデスクトップクライアントでは複数のProfileを保存できますが、コアが読み込む実行設定は通常1つだけです。サブスクリプションを3つ保存しても、3つ分のルールが自動で統合されるわけではありません。Profileを切り替えると、通常はノード、プロキシグループ、ルールが置き換わりますが、クライアント全体の設定やオーバーライドは引き続き適用される場合があります。

取得元は名前で区別し、用途はメモに記録

• 仕事用・メイン：日常業務で使う設定を保存し、必要なプロキシグループや通信の振り分け方をメモに記録します。
• 自宅用・予備：別の取得元の設定を保存します。メインの設定が使えない場合に手動で切り替え、メインの設定と同じ更新情報にまとめないようにします。
• ローカルルールの検証用：設定を複製してルールを編集し、利用中のリモートサブスクリプションを直接上書きしないようにします。

Profile名にサブスクリプションURLやトークンをそのまま含めないでください。名前がスクリーンショットやログ、画面共有に表示されることがあります。バックアップにどのクライアント情報が含まれるかも確認しましょう。YAMLだけをエクスポートした場合、リモートURL、定期更新タスク、プロキシグループの選択履歴などは含まれないことがあります。

切り替え後に確認する4項目

1. 対象のProfileに有効化マークが付いていることと、ログに読み込みエラーがないことを確認します。
2. ルールが参照するプロキシグループを再確認します。前の設定で選択した内容が、新しい設定にも引き継がれるとは限りません。
3. システムプロキシやTUNが想定どおりの状態になっていることを確認します。通信経路とサブスクリプションを同時に変更すると、問題の切り分けが難しくなります。
4. 対象アプリを終了して接続し直し、新しい接続の出力先を確認します。既存の長時間接続は、新しいノードにすぐ切り替わらない場合があります。

複数の取得元のノードを同時に使う場合は、proxy-providersや、クライアントが明示的にサポートする集約機能を検討してください。2つのYAMLをそのまま連結するのは避けましょう。トップレベルキーやノード名、プロキシグループ名が重複すると、解析エラーや参照先の曖昧さにつながることがあります。設定一式を含むサブスクリプションが、そのままprovider用のノードデータとして使えるとも限らないため、返される形式を確認してください。

更新間隔とローカル編集の保存方法

「サブスクリプションの更新」と「ノードのテスト」は別の操作です。前者はリモートから設定を取得し、後者は既存ノードへの接続を確認します。更新頻度を上げても、遅延が自動で下がったり、使えないアカウントが利用可能になったりするわけではありません。内容の変化が少ない取得元なら、まず1日1回に設定し、提供元の案内に応じて調整してください。

リモート更新では通常、ダウンロードした設定ファイルの内容が置き換えられます。リモート設定に独自ルールを直接追加すると、次回の更新で消える場合があります。変更を継続して残したい場合は、クライアントが対応するオーバーライドやマージ機能を使ってください。一度だけオフラインで試す場合は、ローカルProfileとして別名で保存し、リモート更新には自動追従しないことを把握しておきましょう。

オーバーライドを使う場合も、マージ方法の確認が必要です。ルール一覧への追加、先頭への挿入、全置換のどれになるかは、クライアントの実装によって異なります。独自ルールがMATCHの後ろに追加されると、意図したとおりにマッチしません。編集画面に行があることだけでなく、保存後の最終的なルール順を確認してください。

インポート失敗・設定が使えない場合の確認手順

ダウンロードできない：URLと取得経路を確認

サブスクリプションURLに含まれるクエリパラメーターはそのまま保持し、トークンを省略しないでください。チャットアプリが付けた句点まで一緒にコピーしないよう注意しましょう。HTTPステータス401や403は、認証やアクセス制限が原因のことがあります。429はリクエスト頻度の制限を示すため、繰り返し更新するのはやめてください。サブスクリプションの更新にプロキシが必要な場合は、ノードを取得できなくなる状況を避けるため、利用可能な設定を先に残しておきましょう。

解析できない：形式とコアの互換性を確認

YAMLエラーが出たら、まず応答の本文がHTMLではないことを確認し、次にインデントとコロンを確認してください。未対応のプロキシタイプや項目が表示された場合は、使用中のコアと提供元の要件を確認します。エラーを消すために認証情報を安易に削除しないでください。設定は読み込めてもグループのメンバーが見つからない場合は、ノード名、providerの参照先、グループ名が一致しているかを確認します。

読み込みは成功するが接続できない：実際の出力先を確認

まず出力モードがruleになっているか確認してください。グローバルモードや直接接続モードでは、設定内のルールとは異なる経路が使われることがあります。次に接続履歴から、適用されたルール、プロキシグループ、接続先を確認します。必要に応じて、前述のプロキシを明示したリクエストと比較してください。DNS、システムプロキシ、TUNの設定については詳細設定ガイドを、基本的な通信経路の設定についてはシステムプロキシの設定を参照してください。

安定して管理するには、まず利用可能なProfileを残してから新しい取得元を追加し、ルールと出力先を確認してから更新を設定します。継続的な変更は、管理しやすいオーバーライド層に記述してください。一度に変更するのは1か所に絞ると、ダウンロード、解析、選択、通信経路のどの段階で失敗したかを特定できます。