設定項目 · mihomo

Clashの設定ファイル
YAMLと設定項目のリファレンス

構造から設定項目を確認し、接続経路に沿って問題を切り分けます。まず設定の読み込み元を確認し、プロキシ、グループ、ルールを調整しましょう。

このページは、設定を読み込み済みで config.yaml の内容を理解したい方向けです。初回インストールやサブスクリプションの追加、システムプロキシの有効化については、まず使い方ガイドで基本操作を済ませてから、ここで各設定項目を確認してください。例はmihomoで一般的な構文をもとにしています。クライアントの画面表示やコアの機能、最終的に生成される設定は異なる場合があるため、実際の動作はログで確認してください。

1. YAML構造と設定の読み込み

トップレベルの項目：オブジェクトとリストを見分ける

Clashの設定ファイルは、通常YAMLのマップ形式です。mixed-port と mode はスカラー項目、dns はネストしたマップ、proxies、proxy-groups、rules はリストです。まずこの構造を把握してから個々のパラメーターを確認すると、プロキシをグループの中に書く、ルールをDNSの下に置くといった階層の誤りを防げます。

インデントで親子関係を表します。半角スペース2つに統一し、タブは使わないでください。リスト項目はハイフンとスペースで始め、同じ項目内の設定は位置をそろえます。エディター上で整って見えても、実際の文字がそろっているとは限りません。設定を貼り付けた後は、空白文字を表示して確認しましょう。全角の句読点もエラーの原因になります。項目の後のコロンやルール内のカンマには半角文字を使ってください。

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

proxies: []

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

rules:
  - MATCH,Proxy

このひな形では項目間の参照関係を確認できますが、用意されているのは直接接続の経路だけです。最後のルールは Proxy を指定し、そのグループには DIRECT しかありません。基本構造の確認には使えますが、プロキシノードが自動で追加されるわけではありません。実際に使うには、サービス提供元から入手したノードを追加するか、プロバイダーでノード一覧を読み込んでください。構造例を利用可能なサブスクリプションと混同しないようにしましょう。

文字列・真偽値・重複キー

ポートは通常整数で、オン・オフの値には true または false を指定します。名前、パスワード、特殊記号を含む文字列は引用符で囲めます。特に、コロンの後にスペースがある文字列、シャープ記号を含む文字列、真偽値に見える文字列には注意してください。ダブルクォート内では一部のエスケープ文字が解釈されるため、バックスラッシュを含む場合は慎重に扱います。判断に迷ったら、サービス提供元から受け取った値を確認し、文字を独自に変換しないでください。

コメントは文字列の外にあるシャープ記号から始まり、変更理由の記録などに使えますが、コアの設定には反映されません。同じトップレベルのキーを重複して宣言しないでください。たとえば、先に dns を記述し、ファイル末尾でもう一度 dns を定義するケースです。パーサーによってはエラーになったり、片方だけが採用されたりします。必要な子項目は同じオブジェクトにまとめ、後から書いた値で前の値を上書きする方法に頼らないでください。

YAMLとして解析できても、構文が正しいことを示すだけで、現在のコアがその項目をサポートしているとは限りません。項目名の誤記で期待した効果が得られないことも、存在しないノードをグループが参照していることもあります。確認すべき点は、テキストを解析できるか、コアが設定を受け付けるか、接続が想定どおりに流れるかの3段階です。これらを混同すると、参照の誤りをネットワーク障害と誤認しやすくなります。

設定の読み込み元とテストの順序

クライアント内のサブスクリプション原文、ローカルで編集した内容、上書き後の結果、コアが実際に読み込んだ設定は、別々のテキストである可能性があります。問題を調べる前に、現在有効なProfileを確認し、クライアントが設定のマージやスクリプト処理を適用しているかも確認してください。画面上で変更が保存されていても、実行中のコアが再読み込みされたとは限りません。必要に応じてクライアントの再読み込み操作を行い、ログを確認しましょう。

mihomoを直接実行する場合は、次のコマンドで指定したファイルを検査できます。GUIクライアントでは、設定チェック、実行ログ、エラーメッセージを優先して確認してください。コマンド内の設定ファイルのパスは、テスト対象のファイルを指している必要があります。別のディレクトリにある同名ファイルを指定していないか確認しましょう。テストに合格してから有効化すると、唯一使える設定を直接上書きして、比較対象を失う事態を避けられます。

mihomo -t -f ./config.yaml

一度に変更する範囲は1つに絞りましょう。まず基本構造を読み込めることを確認し、次にノード、プロキシグループ、ルールとDNSの順に設定します。問題が起きたら、前回正常に動作したファイルに戻すほうが、数十項目を同時に変更するより原因を特定しやすくなります。複数の設定の命名や切り替えについては、Profileとローカル設定の管理もご覧ください。

2. ポート・モード・共通設定

待ち受けポート：プロキシの種類を確認する

port はHTTPプロキシの入口、socks-port はSOCKSの入口です。mixed-port は1つの待ち受けポートでHTTPとSOCKSの両方を受け付けます。通常のデスクトップ利用なら、用途が明確な入口を1つ選べば十分です。ポート番号は性能を表す値ではなく、大きな数字に変更しても接続は速くなりません。ポートが使用中でないことと、アプリが正しい接続先を使っていることを確認してください。

次の設定例はローカルホストのみで待ち受けるため、クライアントのシステムプロキシ機能と組み合わせるのに適しています。クライアント側でポート設定を管理している場合、サブスクリプション内の値を直接変更しても、画面側の設定で上書きされることがあります。ポートが競合したら、まずクライアントが重複起動していないか、バックグラウンドサービスが動作していないかを確認してから、ポートを変更しましょう。複数のプログラムで同じアドレスとポートを同時に待ち受けないでください。

mixed-port: 7890
allow-lan: false
bind-address: "127.0.0.1"
mode: rule
log-level: info
ipv6: false

項目	用途	確認ポイント
`port`	HTTPプロキシの入口	アプリがHTTPプロキシに対応しているか
`socks-port`	SOCKSプロキシの入口	アプリが該当するプロキシ方式に対応しているか
`mixed-port`	HTTPとSOCKSの入口を統合	クライアントとアプリでポートが一致しているか
`allow-lan`	LANからの接続を許可	待ち受け範囲、認証、ファイアウォール

動作モード：入口の取り込みと接続先の選択を分けて考える

mode: rule はルール一覧に従って経路を選び、global はグローバル設定を使い、direct は直接接続を基本とします。モードが決めるのは、コアに入った接続の処理方法です。すべてのアプリの通信を自動でコアに取り込む機能ではありません。システムプロキシ、アプリ内プロキシ、TUNは通信を取り込む側の設定です。入口の設定を動作モードの切り替えで代用することはできません。

ブラウザーはプロキシ経由なのに、あるコマンドラインツールは直接接続している場合は、そのツールがシステムプロキシを参照するか、環境変数の個別設定が必要かを確認しましょう。一方、クライアントの接続パネルに通信が表示されているのに経路が違う場合は、モード、ルール、プロキシグループを確認します。まず通信がコアに入っているか、次に出力先の選択を確認すると、原因を絞り込みやすくなります。

LAN内で共有するには、allow-lan、待ち受けアドレス、OSのファイアウォール、接続する端末のプロキシ設定をすべて確認する必要があります。許可のスイッチをオンにしただけでは、ほかの端末から接続できるとは限りません。共有が必要な場合は、信頼できるネットワークに限定し、適切な認証を設定してください。トラブル対処を省くために、プロキシの入口や管理インターフェースをインターネット上に公開しないでください。

ログ・設定の保存・管理インターフェース

log-level は通常 info を使い、トラブル対処中のみ debug に上げ、調査後に元へ戻します。詳細ログにはドメイン名、接続先、パスなどが含まれる場合があります。問い合わせに添付する際は、機密情報を削除してください。警告が1件出ただけでクライアント全体が動作していないとは限りません。発生時刻や対象の接続、再現性と合わせて影響を判断しましょう。

profile.store-selected はプロキシグループの選択状態を保存する設定です。選択が期待どおりに復元されるかどうかは、クライアントの設定切り替え方法にも左右されます。グループ名やノード名を変更すると、以前の選択先が見つからず、デフォルトの経路に戻ることがあります。その場合は、すぐにクライアントを再インストールするのではなく、サブスクリプションの更新で名前が変わっていないか確認してください。重要なグループ名を安定させると、長期的な管理がしやすくなります。

profile:
  store-selected: true

external-controller は管理インターフェースであり、ブラウザーからWebサイトにアクセスするためのプロキシポートではありません。通常の利用でネットワーク接続のために公開する必要はありません。パネルから接続する必要がある場合は、ローカルホストまたは管理されたネットワークで待ち受け、クライアントの要件に従って認証を設定してください。管理ポートをシステムプロキシに指定すると、通常は接続できない、またはプロトコルが一致しないというエラーになります。

トップレベルの ipv6 とDNS内にある同名の項目は役割が異なります。前者はコアでのIPv6利用に関係し、後者はDNSでのAAAA問い合わせの処理に関係します。どちらもOSのネットワークアダプターを有効・無効にする設定ではありません。家庭内ネットワーク、ノードの出口、接続先サービスでIPv6の対応状況が異なることがあります。変更前の値を保存して1項目ずつテストし、問題のすべてをIPv6のせいにしないようにしましょう。

3. プロキシの設定項目とプロトコルの違い

基本項目：名前は参照に使う

proxies の各項目は、個別のプロキシノードを表します。まず name、type、server、port を確認し、その後に認証や通信方式の設定を見ます。名前はプロキシグループから参照するためのもので、サーバーのドメイン名ではありません。ノード名を地域名に変えても、出口の場所は変わりません。地域や回線の状況は、サービス提供元の情報と実際の接続結果で確認してください。

ノード名は重複させず、プロキシグループと同じ名前や、DIRECT、REJECT などの組み込みポリシー名も避けてください。ノードをコピーした後にアドレスだけ変更して名前を変え忘れると、参照が曖昧になったり、設定の読み込みに失敗したりすることがあります。サービス提供元が頻繁に名前を変える場合、特定のノードを手動で参照するグループは壊れやすくなります。プロバイダーからノードを読み込み、グループ内で絞り込む方法も検討してください。

proxies:
  - name: Example-SS
    type: ss
    server: proxy.example.com
    port: 443
    cipher: chacha20-ietf-poly1305
    password: "your-password"
    udp: true

上のShadowsocksの例は項目の関係を示すもので、アドレスとパスワードはサービス提供元の値に置き換える必要があります。cipher はプロトコルの暗号化方式です。サーバー側の設定と一致させ、名前が似ているからという理由で変更しないでください。サーバーのポートが一般的なWebサービスのポートとは限りません。443に設定しても、自動的にHTTPSを使うわけでも、ブラウザーから直接開けるようになるわけでもありません。

認証と通信方式：プロトコルごとに一式で確認する

認証に使う項目はプロトコルごとに異なります。Shadowsocksではパスワードと暗号化方式、Trojanではパスワードと対応するTLS設定、VMessやVLESSではユーザーIDなどを使います。項目名を別のプロトコルにそのまま流用しないでください。認証エラーが起きたら、元のサブスクリプションやサービス提供元のドキュメントに戻り、プロトコル、アカウント情報、追加パラメーターを確認しましょう。Web上で見つけた項目を手当たり次第に追加するのは避けてください。

プロトコルによっては、通信方式、パス、ホストヘッダー、TLSの設定も指定します。これらはサーバー側の設定と一式で一致させる必要があります。WebSocketのパスはWebサイトのトップページのパスとは限らず、HTTPのホストヘッダーも接続先アドレスと同じとは限りません。サーバーをブラウザーで開けるからといって、プロキシの認証まで正しいとは限りません。Webページへのアクセスで確認できるのは、ネットワーク条件の一部だけです。

servername は、対応するプロトコルでTLSのサーバー名として使われます。server と異なる値を指定できますが、その違いはサーバー側の設定に基づくべきで、接続できるドメインを適当に入力するものではありません。証明書のエラーが出たら、端末の時刻、サーバー名、証明書チェーンを確認してください。skip-cert-verify を万能な修正方法として使うと、重要なサーバー認証を省略してしまいます。

UDP・ドメイン解決・ノード選択

udp: true は、ノード側で関連するUDP転送を許可する設定です。ただし、入口、サーバー、接続先までの経路がすべて対応していることを保証するものではありません。アプリがUDP通信を送信しているか、システムプロキシがその通信を取り込めるか、ノードのプロトコルが対応しているか、サーバー側で許可されているかをそれぞれ確認してください。Webサイトを開けるだけでは、音声通話やゲームなどのリアルタイム通信も使えるとは限りません。

server にドメイン名を指定した場合、プロキシ接続を確立する前に、コアがそのドメインをIPアドレスに解決する必要があります。この処理は接続先のWebサイトにアクセスする前に行われます。DNSの問い合わせ先が、まだ確立していない同じノードを通る設定だと、依存関係が循環するおそれがあります。すべてのノードが一度に接続できなくなった場合は、個々の回線を疑う前に、ノードのドメイン名を解決できるか確認してください。

遅延テストに成功したということは、その時点でテスト要求が完了したことを示すだけで、すべてのWebサイトや通信方式が正常とは限りません。ノードは安定性、利用するサービスの地域、通信量の制限や倍率、日常の利用目的を踏まえて選びましょう。比較手順の詳細はノードの選び方をご覧ください。測定値の見方については遅延テストと実際の使い心地も参考になります。

新しい設定を作るときは、すべてのプロトコルを一度に登録する必要はありません。まず、必要な情報がそろい、正常に使えることを確認できたノードを1つ選び、手動選択グループで接続してから、自動テストや予備回線を追加しましょう。クライアントを乗り換える場合は、ダウンロードページでOSに合ったものを選んでください。Clash Plusを優先して検討し、必要なプロトコルが現在のクライアントコアに対応していることを確認しましょう。

4. プロキシグループの設定と選択ロジック

select：手動選択を1か所にまとめる

proxy-groups は、ノードやほかのグループ、組み込みポリシーをまとめ、ルールから参照できる接続先を作ります。ルールには変わりにくいグループ名を指定し、ノードの変更はグループ内で行うと、あちこちを書き換える手間を減らせます。最もよく使われる select は、ユーザーがメンバーを選ぶ方式です。普段の手動切り替えに適しており、自動選択グループと直接接続の共通入口としても使えます。

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

  - name: Auto
    type: url-test
    use:
      - Main
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

この例は、後述する Main ノードプロバイダーの定義が必要です。プロバイダーなしで貼り付けても、参照先が見つかりません。Proxy は全体の入口で、自動選択グループと直接接続の間をユーザーが切り替えられます。トラブル対処しやすいよう、グループ名には「通常の接続先」「仕事用」「メディア用」など、用途が分かる名前を付けましょう。見分けにくい記号だけの名前は避けてください。

proxies には具体的なノード名やグループ名を列挙し、use ではノードプロバイダーを参照します。両者が指す対象は異なるため、プロバイダー名を通常のノード名として記述することはできません。グループのメンバーは設定内に存在する必要があり、循環参照も避けてください。たとえば、グループAがグループBを含み、グループBがグループAを含んでも予備経路にはならず、無効な構造になります。

自動選択グループ：まずテスト条件を理解する

url-test はテスト結果をもとにメンバーを選びます。url はテスト先のアドレス、interval はテスト間隔で、通常は秒単位です。tolerance はわずかな差による頻繁な切り替えを抑えます。テスト先には、安定して応答が速く、必要な基本的な到達性を確認できるアドレスを使いましょう。アカウント情報を含むページや、ログインが必要なページは避けてください。

自動テストは、継続的にダウンロード速度を測る機能ではありません。テストサーバーの場所、名前解決の方式、接続の再利用、その時点の回線状況などが結果に影響します。テスト先に快適に接続できても、実際に使うサービスでは遅いことがあります。グループの選択が頻繁に変わる場合は、まず回線の変動とテスト条件を確認し、必要に応じて許容値を調整してください。数値をより頻繁に更新するためだけに、テスト間隔を短くするのは避けましょう。

fallback はメンバーの順序に沿って利用可能な経路を選び、主回線と予備回線が明確な場合に適しています。ただし、主回線でテスト先を開けても、特定のサービスに接続できないことがあります。その場合、テストでは利用可能と判定される可能性があります。主系・予備系の構成で一部の障害を軽減できても、対象サービスに合わせたルールや到達性の確認は必要です。グループ名で常に利用可能だと誤解させないようにしましょう。

load-balance は設定した方式に従って接続をメンバーに割り振ります。1つのダウンロード接続を複数のノードに分割し、帯域を合算する機能ではありません。ログイン状態や出口IPの安定性が重要なサービスでは、出口の頻繁な変化が追加認証につながることがあります。明確な目的がなければ、手動選択グループやテストグループのほうが挙動を理解しやすく、再現性のある基本設定を作るのにも向いています。

絞り込みと選択状態の保存：空のグループを防ぐ

プロバイダーから読み込んだノードは、絞り込み設定で対象を限定できます。絞り込みには通常正規表現を使い、実際の地理的位置ではなくノード名を対象にします。提供元が名称や記号、表記言語を変更すると、以前のフィルターでは何も選ばれなくなることがあります。利用を始める前に、クライアントでグループ内の実際のメンバーを確認してください。正規表現が正しそうに見えるだけで、グループが使えると判断しないようにしましょう。

プロキシグループの入れ子は深くしすぎないようにします。全体の入口から用途別グループへ、さらに具体的なノードを選ぶ構成で十分な場合がほとんどです。自動選択グループを何段も重ねると、理解しにくくなります。問題を調べる際は、ルールの接続先、現在のグループ選択、その次のグループ、最終ノードの順にたどり、実際の出力先を確認してください。最上位のグループ名だけを見ると、内部で直接接続が選ばれていることに気付かない場合があります。

サブスクリプション更新後に選択先が変わる原因には、ノードの削除や名前変更、グループ構成の再作成、クライアントの選択状態の保存方式などがあります。まず元のメンバーが残っているか確認し、次に profile.store-selected とクライアントが選択状態をリセットしていないかを確認してください。長期的に維持したいグループはローカルの上書き設定で管理できますが、サブスクリプション更新後も、そのグループが参照するメンバーが存在するか確認が必要です。

特定のグループだけに問題があり、ほかのグループは正常な場合は、同じノードを一時的にシンプルな手動選択グループに追加して比較しましょう。ノード自体が使えるなら、原因はフィルター、ヘルスチェック、グループ間の参照にある可能性が高いです。ノードの障害と選択ロジックを分けて確認できるため、1つのグループを直すためにサブスクリプション全体のポリシーを書き直す必要がありません。

5. ルール構文とマッチ順序

上から順に評価：具体的なルールを先に置く

rules は順序のあるリストで、通常は上から順に評価され、条件に一致すると指定されたポリシーが適用されます。すべての条件をまとめて評価し、投票で決まる仕組みではありません。そのため、具体的な例外ルールは広い範囲に適用されるルールより前に置いてください。カスタムルールが効かない場合は、まず上に適用範囲の広いルールがないか確認し、すぐにルールの種類を変更しないようにしましょう。

rules:
  - DOMAIN,api.github.com,Proxy
  - DOMAIN-SUFFIX,github.com,Proxy
  - DOMAIN-KEYWORD,example,Proxy
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

例にある Proxy は、設定済みのプロキシグループまたはノード名である必要があります。ルール末尾のポリシー欄は自由記述のメモではありません。実際の名前とスペル、大文字・小文字、スペースを一致させてください。エディターによる記号の自動置換や、コピー時に混入した見えない空白も参照エラーの原因になります。グループ名を変更したら、すべてのルールとほかのグループ内の参照も確認してください。

ドメインルールとIPアドレスルールの違い

DOMAIN はドメイン名全体に一致し、単一のホスト名を指定する場合に適しています。DOMAIN-SUFFIX はドメイン自身とそのサブドメインに一致し、同じサービスのドメイン群を対象にできます。DOMAIN-KEYWORD はキーワードによる判定で範囲が広く、無関係な接続まで一致するおそれがあります。明確なドメイン名で指定できる場合は、曖昧な誤マッチを防ぐため、より具体的なルールを優先しましょう。

IP-CIDR と IP-CIDR6 はIPアドレスの範囲を指定します。ドメイン名を使った接続でも、IPアドレスを必要とするルールに到達すると、コアが名前解決を行う場合があります。no-resolve は、このIPルールのためだけにドメインを積極的に解決しないという意味です。接続全体のDNS問い合わせを禁止する設定ではありません。接続にすでに宛先IPアドレスがある場合は、このルールに一致することがあります。

GEOIP はIPアドレスのデータベースを使って地域を判定するため、データの内容や更新状況に結果が左右されます。Webサイト運営者の所在地を示すものではなく、CDNの接続先が変わるたびの出口を正確に表すものでもありません。関連ルールを有効にする前に、コアが必要なデータを読み込めることを確認してください。同じWebサイトでも名前解決先が別の地域のIPアドレスになり、経路が変わる場合があります。ルールがランダムに無効になったとは限らず、解決結果の違いが原因かもしれません。

MATCH は最後に評価するフォールバック項目です。リストの先頭に置くと、後続の通常ルールが接続を処理できなくなります。DIRECT は直接接続、REJECT は拒否を表し、それ以外の名前は通常ノードまたはプロキシグループを指します。設定を短くするために、個別の例外をすべてフォールバックの後ろへ移動しないでください。記述があっても、実行時に一度も一致しなくなります。

ルールセットとプロセス判定の制約

ドメインの一覧が長い場合は、ルールプロバイダーにまとめて RULE-SET で参照できます。メイン設定では用途ごとの順序を分かりやすく保ち、外部の一覧で個々のルールを管理します。ルールセットもリスト内の記述位置で評価される点に注意してください。内容が正確でも、その前にフォールバックルールがあると、ルールセットが接続を処理する機会はありません。

プロセスを対象とするルールは、実行環境、プロセスの識別機能、通信の取り込み方法に依存します。デスクトップクライアントで識別できるプロセス名が、ルーターでも識別できるとは限りません。ルーターが受け取るのは、ほかの端末からの接続だからです。モバイルOSでも関連情報が制限される場合があります。設定を別のプラットフォームへ移す際は、まず機能の違いを確認し、プロセスルールをどの環境でも使えるドメインルールの代わりとして扱わないでください。

ドメインルールの適用には、コアがドメイン情報を取得できる必要があります。アプリがIPアドレスへ直接接続する場合、DNS問い合わせがコアを経由しない場合、暗号化DNSの経路によってはドメインを識別できないことがあります。スニッフィング機能にも適用条件があり、すべてのプロトコルからドメインを復元できるわけではありません。接続先がIPアドレスだけで表示される場合は、キーワードの範囲をむやみに広げる前に、DNSと通信の入口を確認しましょう。

ルールを検証するときは、接続パネルで新しい接続を開き、一致したルールの種類と内容、ポリシーの経路、最終的なノードを確認してください。変更前から確立していた長時間接続では、出口が切り替わらない場合があります。必要に応じて対象アプリの接続を切り、再試行してください。それでも解決しない場合は、トラブル対処で症状に合わせて確認しましょう。「ルールが効かない」と説明するだけでなく、成功例と失敗例の接続記録を残すと役立ちます。

6. サブスクリプション・ノードプロバイダー・ルールプロバイダー

完全な設定ファイルとノード一覧は別のもの

クライアントのリモートProfileは通常、ポート、DNS、ノード、プロキシグループ、ルールを含む設定ファイル全体です。一方、proxy-providers はメイン設定からノードの一覧を読み込む機能です。どちらもURLから更新できますが、用途は異なります。完全な設定ファイルのURLをノードプロバイダー用の欄に入力すると、ダウンロードはできても内容を解析できないことがあります。

まずサービス提供元のコンテンツ形式を確認し、適切な読み込み方法を選びましょう。初めて使う場合は、クライアントのサブスクリプション追加機能で完全なProfileを登録するのがおすすめです。メイン設定を自分で管理する必要がある場合に限り、ノードの取得元をプロバイダーとして分けてください。クライアントでの操作手順はサブスクリプションの追加手順、形式変換の制約はサブスクリプション形式の変換をご覧ください。

proxy-providers:
  Main:
    type: http
    url: "https://example.com/nodes.yaml"
    path: ./providers/main.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300

サンプルURLから実際のノードは取得できません。HTTPノードプロバイダーが返す一般的なYAML形式には、トップレベルの proxies リストが含まれます。Webページ、ログイン画面、エラーメッセージをその代わりに使うことはできません。path はローカルキャッシュの保存先です。通常はコアの作業ディレクトリを基準に解決されますが、クライアント側のパス制限も影響します。複数のプロバイダーには異なるキャッシュファイルを指定し、互いに上書きされないようにしましょう。

更新間隔とヘルスチェックの役割

プロバイダーの interval はノード一覧を再取得する間隔を設定します。一方、ヘルスチェック内の同名項目は、ノードのテスト間隔を設定します。この2つは別の設定です。前者は新しいノード情報を取得する頻度、後者は既存ノードへの接続性を確認する頻度です。ヘルスチェックを頻繁にしても、サブスクリプションの内容が早く更新されるわけではありません。リクエストが増え、モバイル端末のバッテリー消費につながる可能性があります。

更新に失敗した場合は、取得の流れに沿って順番に確認してください。URLの期限切れや再認証の要否、現在のネットワークからのアクセス可否、サーバーの応答内容、YAML形式との一致を調べます。ブラウザーでURLを開ける場合も、表示されているのがアカウントページではないか確認しましょう。クエリパラメーターにそのまま使える認証情報が含まれることが多いため、サブスクリプションURL全体を公開の問い合わせに貼り付けないでください。

ローカルキャッシュが有効であれば、リモート更新に失敗しても既存のノードはすぐに使えなくならないことがあります。ただし、キャッシュの扱いや再起動後の動作はクライアントによって異なるため、常に使えるとは限りません。トラブル対処では、まず現在動作している設定を残してください。キャッシュと古いProfileを同時に削除しないようにしましょう。よくあるエラーの詳しい分類はサブスクリプション更新の失敗と自動更新間隔をご覧ください。

ルールプロバイダー：形式と動作を一致させる

rule-providers が管理するのは接続条件であり、プロキシノードではありません。behavior は内容がドメイン、IPアドレス、クラシック形式のいずれかを指定し、format はファイル形式を表します。実際のファイルに合わせて両方を設定してください。拡張子がYAMLだからといって、同じ動作になるとは限りません。メインルールでは RULE-SET の参照箇所に接続先ポリシーを書くため、同じ一覧を異なる出力先に利用できます。

rule-providers:
  Work:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/work.yaml

rules:
  - RULE-SET,Work,Proxy
  - MATCH,DIRECT

上にある rules は順序の例です。ファイル末尾で再宣言するのではなく、既存のリストに組み込んでください。同じ一覧をドメイン形式で扱う場合は、次のような構造になります。保存する前に、クライアントが指定した相対パスを読み込めるか確認しましょう。作業ディレクトリを直接管理できないモバイルクライアントでは、クライアントが提供するローカルルールや上書き機能を使うほうが適しています。

payload:
  - "+.github.com"
  - "example.com"

プロバイダーを分けると、管理する内容も分かれます。メイン設定はグループと順序、ノードの取得元は回線情報、ルールの取得元は一致条件を担当します。ローカルでの変更は、該当する内容を管理する場所に加えましょう。残したいカスタムドメインを、リモート更新で置き換わるキャッシュファイルに一時的に書くだけでは、次の更新時に消える可能性があります。

複数の取得元を使う場合は、それぞれの用途、形式、参照先のグループを記録しておくと便利です。新しい取得元を追加したら、まず正常に読み込まれたか、次にグループ内にメンバーが表示されるか、最後に接続できるかを確認してください。ダウンロード失敗、形式エラー、フィルターによる空リスト、ノードの接続不可を個別に判別でき、すべてをサブスクリプションURLの問題として扱わずに済みます。

7. DNS・Fake-IP・TUNの連携

DNS：名前解決の依存関係を整理する

dns はコア自身の名前解決を設定しますが、そのDNS経路を通る問い合わせだけに影響します。ブラウザー内蔵の暗号化DNS、アプリ独自のリゾルバー、OSに残るキャッシュなどもあるため、設定で上流DNSを変更しても、すべてのアプリがすぐに新しい設定を使うとは限りません。問題を調べる前に、問い合わせがどこから送られ、最終的に誰から応答を受け取っているか確認しましょう。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost"
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - 223.5.5.5
    - 119.29.29.29

この例は一般的な項目の関係を示すもので、あらゆるネットワークで使える共通設定ではありません。listen を設定するとDNSの待ち受け口が作られますが、OSが自動的に問い合わせをそこへ送るわけではありません。ローカルの高いポート番号で待ち受けても、ルーター経由でほかの端末にDNSを提供できるとは限りません。クライアントの通信取り込み機能、OSの設定、必要な権限をそれぞれ確認してください。

default-nameserver は、DNS上流サーバー自身のドメイン名を解決するために使われます。nameserver は通常の問い合わせ先を設定し、proxy-server-nameserver はノードのドメイン名を解決するリゾルバーを指定できます。公開DNSをいくつも追加するより、各設定の役割を理解することが重要です。ノード接続前の名前解決には独立して動作する経路を用意し、まだ確立していない同じプロキシ接続に問い合わせが依存しないようにしましょう。

Fake-IP：マッピング用アドレスは最終的な接続先ではない

fake-ip はドメイン名にマッピング用のIPアドレスを割り当てます。コアはその対応関係から接続先のドメイン名を復元し、通信を処理します。応答されたアドレスが設定済みのマッピング用ネットワーク範囲に含まれていても、すぐにWebサイトのDNSエラーと判断しないでください。後続の接続もマッピングを認識できるコアを通ることが前提です。DNS問い合わせがコアを通っても接続がコアを迂回すると、通常のネットワークでは到達できないマッピング用アドレスにアプリが接続しようとすることがあります。

fake-ip-filter を使うと、特定のドメインではマッピングを使用しないようにできます。LAN内のデバイス検出や、実際のIPアドレスが必要なアプリでは個別の調整が必要な場合がありますが、最初から広い範囲を例外にしないでください。例外の範囲が広いほど、ドメインの対応関係から得られる情報が減ります。まず問題のある具体的なドメインを特定し、必要最小限の範囲だけを追加して、対象のアプリを再テストしましょう。

名前解決方式を切り替えても、古いDNSキャッシュや確立済みの接続が残り、変化がないように見える場合があります。まず対象アプリを再起動し、OSやクライアントが提供する方法でキャッシュを消去してください。上流DNS、マッピング方式、スニッフィング、ルールを一度に変更すると、どの変更が接続を改善または悪化させたのか判断しにくくなります。LAN内の名前については、ルーターとローカルの名前解決環境も確認しましょう。

TUN：通信の取り込みにはルーティングと権限も必要

TUNは仮想ネットワークデバイスを通じて通信を受け取り、システムプロキシを参照しない一部のアプリにも対応できます。ただし、ルールやノードの代わりになるものではなく、あらゆる環境でそのまま有効化できるとは限りません。デスクトップではサービスの実行や権限昇格が必要な場合があり、モバイルOSではシステムのネットワーク拡張機能を使います。ルーターではゲートウェイと転送経路の設定も関係します。具体的な有効化手順は、使用中のクライアントの画面で確認してください。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

これはデスクトップでよく使われる設定項目の例です。適用前にプラットフォームが対応していることを確認してください。auto-route は通信を取り込むためのルートを設定し、auto-detect-interface は送信に使うインターフェースを検出します。複数のネットワークアダプター、仮想マシン、別のVPN、コンテナーネットワークがあると、自動判定が期待と異なる場合があります。通信できなくなったら、まずTUNを無効にして元の状態に戻し、OSのルートとインターフェース選択を確認しましょう。

dns-hijack が対象とするのは条件に一致する通常のDNS通信です。HTTPSで暗号化された問い合わせをすべて自動で識別し、書き換えるわけではありません。ブラウザーが独自の暗号化DNSを使う場合は、その動作が通信の振り分け方針に合っているか確認してください。また、TUNとシステムプロキシを併用するときは、クライアント自身の通信がループしないよう、どのように処理されるかを把握しましょう。出所が分からない複数の通信取り込み設定を手動で重ねないでください。

トラブル対処は、まず直接接続をテストし、次に通常のプロキシ入口、続いてTUNを有効にし、最後にDNSとドメインルールを確認する順がおすすめです。TUNを有効にしたときだけ問題が起きるなら、権限、ルート、インターフェース、ほかのネットワークソフトとの競合を重点的に確認します。特定のドメインだけが対象なら、名前解決とルールを調べてください。最初からDNS設定全体を書き直すより、段階を分けてテストするほうが原因を特定しやすくなります。

8. 上書き・マージと安全に戻せる設定管理

サブスクリプションの原文と実際の設定を区別する

リモートのサブスクリプションを更新すると、設定内容は再生成または置き換えられるのが一般的です。サブスクリプションの原文にルールを直接追加しても、次回の更新までしか残らない場合があります。ポート、用途別の通信振り分け、DNSの調整を長期的に維持するには、クライアントが対応する上書き、マージ、スクリプトの機能を使いましょう。まず、機能がどのProfileに適用されるか確認してから変更箇所を決め、全体設定の変更が別の設定に影響しないようにしてください。

「マージ」の定義はクライアントによって異なります。マップは項目ごとにマージされても、リストは全体が置き換わる場合や、先頭への追加・末尾への追加が可能な場合があります。スクリプトによって、マージ後に結果が変更されることもあります。どのクライアントでも「上書き」という名前なら同じ動作だと考えないでください。入力欄の内容だけで判断せず、小さなテストを行い、最終的な設定を確認するのが確実です。

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

たとえば、仕事で使うドメインを特定のグループへ優先的に接続させる場合、必要なのは対象ルールを広範囲のルールより前に配置することです。単にファイル末尾へテキストを追加するだけではありません。上書き機能が末尾への追加にしか対応しておらず、サブスクリプションに MATCH が含まれていると、追加したルールは一度も一致しないことがあります。先頭への追加機能やルール挿入機能を使い、最終設定で位置を確認しましょう。

項目間の参照：マージ後に関係を確認する

プロキシグループを追加したら、参照先のノード、プロバイダー、ほかのグループが存在するかも確認してください。ローカルのグループ名を維持していても、メンバーが常に有効とは限りません。リモートのサブスクリプションによってノード名やプロバイダー名が変更される場合があります。長期的に使うルールは安定したローカルの用途別グループを参照させ、そのグループから構成の分かりやすい取得元を参照すると、ルールがリモートのノード名に直接依存するのを防げます。

DNSを上書きするときは、特定の子項目だけを置き換えるのか、DNSオブジェクト全体を再作成するのか確認してください。上流DNSだけを変更したいつもりでも、待ち受けアドレス、マッピング方式、フィルター一覧まで失われると、通信の挙動が同時に変わる可能性があります。変更前の値を記録し、適用後に最終結果と照合しましょう。別の設定にあるDNSブロック全体を貼り付けても、単一項目だけを変更したことにはなりません。

パスを指定する項目も改めて確認してください。元のサブスクリプションが使う相対ディレクトリ、クライアントの上書きファイルがあるディレクトリ、コアの実行ディレクトリは異なる場合があります。別の端末へ移行すると、ファイルプロバイダーやキャッシュのパスが使えなくなることがあります。ファイルが見つからないというエラーが出たら、まず作業ディレクトリとクライアントがアクセスできる場所を確認してください。パスの問題を、ディレクトリの権限をむやみに緩めて解決しないでください。

検証の流れ：保存・読み込み・接続・復元

変更ごとに、どの項目を変更したか、どの接続への影響を想定したか、何を使って検証するか、失敗したらどのファイルに戻すかを簡潔に記録しましょう。複雑な記録は不要ですが、1週間後に見ても変更理由が分かるようにしておくことが大切です。トラブル対処用に一時的に有効にした設定にも印を付け、作業後に元へ戻してください。詳細ログ、特殊なDNS例外、一時的な直接接続ルールを放置しないようにしましょう。

操作は4段階に分けると分かりやすくなります。現在正常に使えている設定をバックアップし、構文とコアのチェックを行い、設定を適用して読み込みログを確認し、最後に新しい接続でルールの適用結果を調べます。設定の読み込みに成功しただけでは完了ではなく、実際の用途で検証が必要です。反対に、Webサイトが一時的に開けても、新しいルールが有効になったとは限りません。以前からの長時間接続がそのまま使われている可能性があります。

テスト中は、ほかの条件をできるだけ変えないようにしましょう。同じ接続先、入口、ノードを使い、変更する項目は1つに絞って前後を比較してください。サブスクリプションの更新、ノードの変更、モードの切り替え、TUNの有効化を同時に行うと、改善しても原因を特定できません。安定した設定の価値は項目数を増やすことではなく、その後の変更の影響を説明できることにあります。

元に戻す手順もあらかじめ用意しておきましょう。直近で正常に使えたProfile、対応する上書き設定、必要なクライアント設定を保存します。復元後は設定を再読み込みし、システムプロキシやTUNの状態が元どおりか確認してください。バックアップファイルにはノードやサブスクリプションの情報が含まれるため、安全な場所に保管しましょう。サポートを求める際は、必要な部分だけを抜き出し、機密情報を削除してからエラー情報とともに共有してください。

設定を管理するときは、項目ごとの役割を明確にしましょう。サブスクリプションはノードの取得元、ローカルの上書き設定は個人の調整、プロキシグループは接続先の整理、ルールは接続先の選択、DNSと入口は通信情報を正しい経路に導く役割を担います。初めて使う場合は、まずクイックスタートガイドをご覧ください。長期利用に合わせて、このページの各章を参考に少しずつ設定を増やせばよく、すべての機能を一度に有効化する必要はありません。