まずはファイルの種類を確認：設定ファイル、サブスクリプション、クライアント設定

Clashの設定ファイルは通常YAML形式のテキストで、ファイル名はconfig.yamlが一般的です。ローカルの待ち受けポート、DNS、プロキシノード、グループ、ルールを記述し、クライアントが読み込んだ後、使用中のコアが各項目を解釈します。サブスクリプションリンクは設定を取得する方法の一つです。クライアントがリンクにアクセスして内容を保存し、設定した間隔で更新します。サブスクリプションURL自体はproxiesのノードではなく、rulesにルールとして記述することもできません。

まずクライアントで、現在選択されているProfileを確認してから編集するか決めましょう。複数の設定をクライアントに保存できますが、通常、実行時に有効になるのは選択中の一つです。サブスクリプションから生成されたファイルを手動で編集すると、次回更新時に変更が上書きされることがあります。調整内容を長期間保持するには、クライアントのオーバーライド機能を使うか、編集可能なローカル設定を管理してください。オーバーライドの方法はクライアントによって異なります。保存前に、変更が元ファイルとサブスクリプションのコピーのどちらに適用されるか確認しましょう。

作業前に元の設定をコピーしておきましょう。変更後は、まずYAMLをクライアントが読み込めるか確認し、次にグループとルールが意図どおりに動作するか確認します。「インポートできたこと」と「通信が正しい経路を通ること」は別の問題です。

基本項目：port、mixed-port、動作モード

トップレベルの項目は行頭から記述します。portはローカルHTTPプロキシの待ち受けポート、socks-portはローカルSOCKS5プロキシの待ち受けポートです。mixed-portでは、同じポートでHTTPとSOCKS5の接続を受け付けます。次の例では混合ポートに7890を指定しており、プロキシを手動設定できるアプリには127.0.0.1:7890を入力できます。これは端末内の接続口であり、リモートノードのポートではありません。

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

allow-lan: falseは、ほかのLAN内端末からこの端末のプロキシを使わせない設定です。共有する必要がある場合は、クライアントの待ち受けアドレス、システム権限、接続中のネットワークも確認してください。設定を一つ変更するだけでは不十分です。mode: ruleではrulesに基づいて接続先を決定します。globalでは通常、通信を選択中のグループにまとめて渡し、directでは直接接続します。モードの切り替えは問題の切り分けに役立ちますが、正しいルールやノード設定の代わりにはなりません。

iPhoneでは「ローカルプロキシのポート」と「システム通信をVPN経由で処理する仕組み」を区別する必要があります。クライアントでVPN構成を作成するかTUNを有効にすると、一部の通信はシステムのネットワーク拡張を通じてコアに渡されるため、各アプリで7890を手動設定する必要はありません。どの通信が対象になるかは、クライアント、システム権限、ネットワーク設定によって異なります。設定ファイルのtun項目に対応していないiOSクライアントもあります。デスクトップ向けのTUN設定例を、そのままスマートフォンの設定に貼り付けないでください。

DNS設定：名前解決の結果がルール判定に反映される仕組み

dnsはネストされたオブジェクトです。enableでコアのDNS機能を有効にし、nameserverに上流のDNSサーバーを指定します。fake-ipを使うと、コアは対象ドメインに予約済みアドレスを返し、そのアドレスとドメインの対応を保持します。その後、接続がこの対応情報に一致すると、コアは元のドメインを特定できるため、ドメインルールによる判定が可能です。Webサイトの実際のアドレスを予約済みアドレスに恒久的に置き換える仕組みではありません。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fake-ip-filter:
    - "*.lan"

198.18.0.1/16は例に使われているFake-IP用のアドレス範囲で、直接アクセスできるWebサイトのアドレスではありません。fake-ip-filterを使うと、特定のドメインをFake-IPによる割り当ての対象外にできます。LAN内の端末名や、実際の名前解決結果を必要とするサービスに問題が起きた場合は、まず対象ドメインごとに動作を確認してからフィルターに追加しましょう。除外する範囲を広げすぎると、どの設定が結果に影響したのか特定しにくくなります。上流DNSは利用中のネットワークに合わせて選んでください。上流サーバーに接続できないと、プロキシノードへの接続前に名前解決の段階で処理が止まることがあります。

「ドメインルールが効かない」ときは、まず通信にルール判定で使えるドメイン情報が残っているか、クライアントがこの設定のDNSを使っているかを確認しましょう。アプリによってはIPアドレスへ直接接続したり、独自の名前解決を使ったりします。nameserverを変更しても、すべての通信がDOMAIN-SUFFIXに一致するとは限りません。Fake-IPとredir-hostの使い分けを確認したい場合は、技術リファレンスで使用中のクライアントが対応する項目を確認してください。

proxiesとproxy-groups：ノードと選択グループを分けて記述

proxiesには個々のプロキシノードをリスト形式で記述します。各項目には、プロトコルに応じた名前、タイプ、サーバーアドレス、ポートが必要です。認証、暗号化、通信方式などの項目はプロトコルによって異なります。次の例にあるproxy.example.netは、階層構造を示すためのドキュメント用ドメインであり、利用可能なノードのアドレスではありません。実際の設定にはサービス提供元が案内する値を使い、ノード名だけでプロトコルを判断しないでください。

proxies:
  - name: "自前のSOCKS5"
    type: socks5
    server: proxy.example.net
    port: 1080

proxy-groups:
  - name: "ノード選択"
    type: select
    proxies:
      - "自前のSOCKS5"
      - DIRECT

proxiesという名前はここに2回登場しますが、階層が異なります。行頭のproxiesはノードを定義し、proxy-groupsの項目内にインデントして書くproxiesは、そのグループで選択できる接続先を列挙します。selectは手動選択グループで、通常はクライアントのグループ選択画面に候補が表示されます。DIRECTは組み込みの直接接続先なので、同じ名前のプロキシノードを作る必要はありません。グループ名とノード名は参照用の識別子です。ルールで使う名前は完全に一致させてください。

サブスクリプション設定では、proxy-providersを使ってノードをまとめて取得し、プロキシグループから参照することもあります。これはノードをトップレベルのproxiesに一つずつ記述する方法とは異なる管理方式です。「ノード一覧が空」の場合は、サブスクリプションが更新されているか、providerがグループから参照されているか、更新したProfileを現在選択しているかをそれぞれ確認しましょう。グループの候補が空だからといって、すぐにDNSの問題と判断しないでください。

rules：上から順に判定し、接続先の指定も確認

rulesは順序を持つリストです。通常、コアは上から順に判定し、最初に一致したルールで指定された接続先を使います。そのため、範囲の狭いドメインルールは範囲の広い地理位置情報ルールより前に置き、最後にフォールバック用のルールを記述します。次の例にあるノード選択は、前に定義したグループ名と一致させてください。

rules:
  - DOMAIN-SUFFIX,example.org,ノード選択
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

DOMAIN-SUFFIXは指定したドメインとそのサブドメインに一致します。GEOIP,CN,DIRECTは接続先IPアドレスの地理情報に基づく判定で、「このアプリは中国本土向けか」という条件とは異なります。MATCHはそれまでのルールに一致しなかった通信を処理します。MATCHを先頭に置くと、通常は後続のルールが判定されません。範囲の広いルールを前に置いた場合も、より具体的なドメインルールが先に遮られることがあります。

ルールに一致したのにページが開かないからといって、ルールの構文が間違っているとは限りません。まずクライアントの接続ログで、どのルールに一致し、どのグループに渡されたかを確認します。次に、グループ内でノードとDIRECTのどちらが選択されているか確認してください。宛先へIPアドレスで直接接続している場合、ドメインルールの判定条件を満たさないことがあります。REJECTを使うと通信は拒否され、プロキシ接続は試行されません。用語の違いは用語集で確認できます。

インデント、順序、保存方法：一度に一か所ずつ変更

YAMLではインデントで階層を表します。トップレベルのdns:、proxies:、proxy-groups:、rules:はすべて行頭から記述します。配下のオブジェクト項目はさらにインデントし、リスト項目はハイフンとスペースで表します。インデントにはスペースを統一して使い、Tabは混在させないでください。コロン、シャープ記号、先頭や末尾の空白を含む名前は、YAMLの構文と誤認されないよう引用符で囲めます。大文字と小文字も区別されます。DIRECTと、独自に付けたDirectは同じ参照先ではありません。

症状まず確認する項目対処方法
設定を読み込めないエラー行付近のインデント、コロン、リストのハイフン直近の変更を元に戻し、項目を少しずつ追加する
ルールで指定した接続先が見つからないルール末尾の名前とプロキシグループ名名前を統一し、大文字・小文字も確認する
グループに選択できるノードがないグループ内のノード名またはproviderの参照ノードが読み込まれていることを確認してから、グループの候補一覧を調べる
変更が元に戻ってしまう現在のProfileの入手元とサブスクリプションの更新履歴永続化できるオーバーライド機能かローカル設定を使う

安全に変更するには、まず元ファイルをバックアップし、項目またはルールを一つだけ変更します。保存後にクライアントで設定を再読み込みし、構文エラーがないか確認します。最後に、対象ドメインを指定して接続ログを調べます。たとえばDOMAIN-SUFFIX,example.org,ノード選択を変更した場合は、そのドメインに属するアドレスへ接続し、ログに想定したグループが表示されるか確認してください。動作を確認してから次の箇所を変更すれば、問題が起きたときに原因を特定しやすくなります。

YAMLとして解析できても、現在のコアがすべての項目に対応しているとは限りません。Clash、Clash Meta（mihomo）、各クライアントで利用できる設定項目は完全には同じではありません。ほかの端末から設定をコピーする場合は、使用中のコアと対応範囲を先に確認してください。iPhoneでは特に、システムのネットワーク拡張に必要な権限、Profileの選択、設定の構文、実際の通信経路を分けて確認しましょう。この4点を順に切り分ける方が、設定ファイル全体を一度に置き換えるより問題を見つけやすくなります。