Clash Profileとは

Profileとは：クライアントに保存する設定ファイル

Clash Profileとは、一般にクライアントで管理する設定ファイルのことです。サブスクリプションURLから取得するものもあれば、ローカルのYAMLファイルから読み込むものもあります。FlClashは設定の保存、更新、選択を行い、処理後の有効な設定をClash Metaコア（mihomo）に渡して実行します。Profileは単一のノードでも、特定のプロキシグループでもありません。

1つの設定ファイルには、待受ポート、DNS、プロキシノード、プロキシグループ、ルールをまとめて定義できます。たとえば、mixed-port: 7890はHTTPとSOCKSを兼ねるプロキシポートを指定し、proxy-groupsは出口の選択方法を、rulesは接続をどの出口に振り分けるかを定めます。Profileを切り替えると、ノードだけでなく、こうした設定も変わる場合があります。

• Profileの切り替え：別の設定ファイルを選ぶ操作です。ルール、ノードの参照元、グループ構成が変わる場合があります。
• プロキシグループの切り替え：現在の設定ファイルを使ったまま、グループ内で選択するノードやサブグループを変更します。
• 接続モードの切り替え：ルール、グローバル、ダイレクトの間で通信の処理方法を変更します。別のサブスクリプションに自動で切り替わるわけではありません。

サブスクリプション設定とローカル設定の違い

どちらも最終的にはコアが読み込める設定にする必要があります。主な違いは取得元と管理方法です。サブスクリプション設定はリモートURLから取得し、後から再取得できます。ローカル設定はユーザーがインポートして管理します。元ファイルを変更したときにクライアントへ反映されるかどうかは、インポート方法によって異なり、常にディスク上のファイルと連動するとは限りません。

サブスクリプションURLが完全なYAMLを返すとは限らない

「サブスクリプション」は取得方法を示す言葉であり、内容の形式が統一されているわけではありません。完全なClash設定を返すURLもあれば、ノード一覧や別クライアント用の形式を返すものもあります。ダウンロードできても有効化できない場合があります。サービス提供元がClashまたはClash Meta対応と明記しているURLを選び、使用中のクライアントとコアが対応する項目やプロトコルを確認してください。

サブスクリプションURLのクエリやパスに、アクセス用の認証情報が含まれている場合があります。問題を調べるときはエラー内容や項目名、機密情報を伏せた部分だけを共有してください。URL全体を公開画像、問い合わせへの添付ファイル、設定例に載せないでください。

ルールをカスタマイズする前に、変更内容の保存先を確認する

FlClashの画面上の設定、設定の上書き、リモートYAMLが組み合わさり、最終的な設定に影響する場合があります。編集機能や設定のマージ方法はバージョンによって異なるため、サブスクリプション本文を編集すれば変更が維持されるとは限りません。まず、使用中のバージョンで明示的に用意されている上書き機能を使ってください。適切な機能がない場合はローカルにコピーを保存し、変更内容を記録します。コピーを使う場合、リモート側のノード変更は自分で反映する必要があります。

サブスクリプションの追加と自動更新間隔

追加時は、「リストに登録した」ことと「その設定を有効にした」ことを区別してください。「サブスクリプションを追加 → 初回取得 → 設定を確認 → 有効化 → 新しい接続で確認」の順に進めるのがおすすめです。画面上の名称はFlClashのバージョンによって異なるため、以下では特定バージョンのメニュー名ではなく、機能を基準に説明します。

1. 接続元を追加：設定管理画面でURLから追加する項目を選び、サブスクリプションURL全体を貼り付け、用途が分かる名前を付けます。
2. 取得内容を確認：初回ダウンロード後、ノードやプロキシグループが表示されるか確認します。更新日時が表示されただけでは、設定が適用されたとは限りません。
3. 設定を有効化：追加した項目を現在の設定に指定し、構文エラー、存在しないプロキシグループ、ポートの競合などの通知がないか確認します。
4. 出口を確認：ルールモードを選択し、新しいテスト接続を行います。接続画面で適用されたルールと出口までの経路を確認してください。

通常の利用なら、まずは24時間ごとの更新から

24時間は管理しやすい設定例であり、コアの必須条件ではありません。サービス提供元がノードを頻繁に更新する場合は、案内に従って6時間ごとに短縮できます。リクエスト頻度に制限がある場合は、その制限を優先してください。サブスクリプションを頻繁に取得してもノードの帯域は改善せず、端末側のDNSやTUNルーティングの問題も解決しません。

• 単位を確認：24時間は1440分、または86400秒です。入力欄の単位が「分」の場合、1日を表す値として24を入力しないでください。
• 2種類の更新を区別：Profileのリモート更新と、proxy-providers内のintervalは別の設定です。後者はmihomoの設定で秒単位です。
• バックグラウンドでの動作を確認：PCがスリープ中の場合や、クライアントが終了している場合、またはモバイルOSがバックグラウンド動作を制限している場合、設定した時刻どおりに更新されるとは限りません。必要に応じて、アプリを開いて手動で更新してください。
• 時刻の意味を区別：最終更新の試行時刻、最終更新の成功時刻、サブスクリプションの有効期限は、それぞれ異なる情報です。更新に成功しても、アカウントの有効期限は延長されません。

複数設定の名前付けとバックアップ：接続元・用途・日付

設定が3つ以上になると、「サブスク1」「新しい設定」といった名前では選び間違えやすくなります。「接続元－用途－管理方法」の順で名前を付けるのがおすすめです。たとえば「回線A－普段使い－リモート」「回線B－予備－リモート」「普段使いルール－テスト－ローカル」のようにします。日付はバックアップ名に付けると管理しやすく、「普段使いルール－バックアップ－2026-11-03」のようにできます。

設定名はクライアント内で管理するためのもので、ルールの転送先に自動で使われるわけではありません。ルールが参照するのはYAML内のプロキシグループ名です。proxy-groups内のグループ名を「普段使いの出口」から「メインの出口」に変更した場合、その名前を参照するルールや他のグループも合わせて修正する必要があります。Profile一覧の名前だけを変更する場合は、通常、こうした参照先への影響はありません。

少なくとも1つ、元に戻せる状態を残す

• 変更前：現在の設定名、接続モード、選択中のノード、システムプロキシ、TUNのオン・オフを記録します。
• バックアップ内容：YAMLと必要な上書き設定を保存します。基本のYAMLだけを書き出すと、クライアント側に個別保存された設定が抜ける場合があります。
• 保存場所：ノードのパスワードを含むバックアップはアクセスを管理できる場所に保存し、公開リポジトリや共有クラウドストレージには置かないでください。
• 古い項目を整理：代わりの設定が正常に起動することを確認してから、重複する項目を削除します。使えなくなったURLを自動更新し続けないようにしてください。

切り替え後、接続とルールはどう適用される？

設定の選択、コアによる読み込みの成功、新しい接続への設定適用は、それぞれ別に確認が必要です。クライアントは選択内容を先に保存してから、コアの設定を読み込む場合があります。YAMLエラーや存在しないプロキシグループがあると、画面で選択されているだけでは切り替えが完了したとは判断できません。ログと接続画面も確認してください。

新しい接続と既存の接続を分けて確認する

新しい設定が正常に読み込まれた後、新しく作成した接続には通常、現在のモードとルールが適用されます。確立済みのTCP長時間接続、動画の再生セッション、アプリのコネクションプールが新しいノードへ自動で移行するとは限りません。クライアントが接続を閉じる場合もあれば、そのまま維持する場合もあります。実際の動作は実装や操作方法によって異なります。確認時は新しいリクエストを送信し、必要に応じてクライアントの接続切断機能を使うか、対象アプリを再起動してください。

長時間接続を維持しているページを再読み込みしただけで、切り替えに失敗したと判断しないでください。接続画面で新しいリクエストのドメイン、適用ルール、出口を確認できます。ブラウザーのキャッシュや接続の再利用、HTTP/3の影響で、一度の再読み込みでは変化を確認できないことがあります。新しいタブを開いても、ネットワーク接続が必ず新たに作られるとは限りません。

モード、DNS、TUNはProfileと一緒に切り替わるとは限らない

システムプロキシ、TUNモード、一部のDNS設定は、クライアント全体の設定で管理される場合もあれば、上書き設定によって基本YAMLに影響する場合もあります。Profileを切り替えた後、ファイル内のtunやdnsの記述だけを見て実際の状態を判断しないでください。画面上のスイッチと有効な設定を確認し、クライアントが全体モードを引き続き使用していないかにも注意してください。

たとえば、設定Aではmixed-port: 7890を使い、設定Bではmixed-port: 7891に変更しているとします。クライアントがポートを上書きせず、アプリ側で127.0.0.1:7890を手動設定している場合、切り替え後もそのアプリは古いポートに接続します。クライアントが管理するシステムプロキシと、アプリごとに設定したプロキシアドレスは、分けて確認してください。

ローカル設定の例：参照関係を確認する

以下はローカルProfileの仕組みを確認するための、最小構成のダイレクト接続サンプルです。profile-local-demo.yamlとして保存し、インポートできます。リモートのプロキシノードは含まれておらず、「普段使いの出口」に一致する接続はすべてDIRECTで処理されます。そのため、リモートプロキシの動作確認には使えません。

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

proxy-groups:
  - name: 普段使いの出口
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,普段使いの出口
  - MATCH,普段使いの出口

このサンプルでは、2段階の参照関係を確認できます。ルール内の「普段使いの出口」は、プロキシグループ名と一致している必要があります。グループ内のDIRECTはコアに組み込まれた接続先です。最後のMATCHは、それまでのルールに一致しなかった接続を受け持ちます。実際のサブスクリプションでは、ネストされたプロキシグループ、ルールセット、プロキシプロバイダーを使うことがあります。一部分だけをコピーしても、必要な設定がすべてそろうとは限りません。

YAMLのインデントにはスペースを使い、Tabは使わないでください。インポート時にポート使用中のエラーが出た場合は、サブスクリプションを何度も更新するのではなく、7890番ポートを他のプログラムが使用していないか確認します。プロキシやプロキシグループが見つからないというエラーでは、名前の綴りと参照関係を確認してください。

よくある質問：更新に成功しても設定が変わらない

予備の設定を更新したのに、現在の接続が変わらないのはなぜ？

項目を更新しても、その設定が有効になるわけではありません。更新したProfileと、現在有効なProfileが同じか確認してください。予備の設定を更新した場合、現在の接続設定が変わらないのは正常です。現在有効な設定を更新した場合も、クライアントが再読み込みしたか、設定内容に実際の差があるかを確認してください。

切り替え後もノード名が同じです。切り替えに失敗していますか？

異なるサブスクリプションで同じノード名が使われることがあります。また、クライアントが同名のプロキシグループで以前の選択を復元する場合もあります。ノード名だけで判断せず、設定名、ルールの内容、新しい接続の出口を確認してください。ノード名の変更や削除後は、以前の選択が復元されない場合もあります。

ローカルコピーにリモートで追加されたノードが反映されないのはなぜ？

ローカルコピーは通常、インポート時点の内容を保存したものです。更新可能なプロキシプロバイダーを参照していない限り、元のサブスクリプションにノードが追加されても自動では反映されません。リモートのノードを継続して取得しながら独自ルールも維持するには、現在のクライアントが対応する上書き機能を使うか、プロキシプロバイダーとその参照を正しく設定してください。

どの順番でトラブルシューティングすればよいですか？

1. 有効なProfileの名前を確認し、最後に正常に読み込まれた記録を確認します。
2. ルール、グローバル、ダイレクトのどのモードかを確認し、プロキシグループで現在選択されている項目を確認します。
3. プロキシポート、システムプロキシ、TUNの実際の状態を確認します。
4. 接続を新しく作成し、接続画面で適用ルールと出口を確認します。
5. まだ問題がある場合は、動作確認済みのバックアップに戻し、変更を1つずつ復元します。

Profile管理では、取得元、更新状況、実行状態を分けて把握することが大切です。まず1つの設定でインポートと接続を確認してから、予備やテスト用の設定を追加しましょう。切り替えるたびに新しい接続を確認すれば、既存セッション、全体設定、サブスクリプション内容を混同せず、原因調査を効率よく進められます。