Clash 設定ファイルリファレンス

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

まず、サブスクリプションURL、Profile、実際に有効な設定の3つを区別しましょう。サブスクリプションURLは設定を取得するためのアドレス、Profileはクライアントが管理する設定レコード、コアが最終的に読み込むものが有効な設定です。リモートProfileには、クライアント設定や上書き、スクリプトによる処理が加わることがあります。そのため、サブスクリプションの元データに項目があっても、コアで同じ値が使われているとは限りません。問題を調べるときは、サブスクリプションファイルを何度も編集するより、まずクライアントの実行設定を確認し、項目の出どころをたどるほうが効果的です。

トップレベル構造と参照関係

以下は、読み込みの流れを確認するための、直結のみの基本設定です。mixed-port、モード、空のノード一覧、手動選択グループ、フォールバックルールを含み、すべてのリクエストを直接接続します。リモートプロキシ機能はありません。まずこの設定が読み込めることを確認してから、プロバイダーのノードを一つずつ追加してください。構造上のエラーとリモート接続のエラーを切り分けられるため、最初から複数の要因を同時に調べずに済みます。

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

proxies: []

proxy-groups:
  - name: "出口選択"
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,出口選択

proxiesには個々のリモート接続を定義し、proxy-groupsにはノードやほかのグループを選択肢としてまとめます。rulesはリクエストの振り分け先を決めます。ルールが参照するのはノードのファイル内の順番ではなく、名前です。空白、大文字・小文字、全角記号の違いも影響するため、名前は正確に一致させてください。ノード、グループ、ルールの順に記述すると読みやすくなりますが、YAMLのトップレベル項目に決まった記述順があるわけではありません。

インデント・リスト・文字列の書き方

YAMLではインデントで階層を表します。スペース2つに統一し、タブは使わず、同じ階層の項目は位置をそろえてください。リスト項目はハイフンとスペースで始め、項目内の属性はさらに一段インデントします。コロンの後には通常、スペースが必要です。ノード名やパスワード、コロンやシャープ記号を含む文字列は引用符で囲むと安全です。特に数字だけのパスワードは文字列として記述し、数値として解釈されないようにしましょう。

引用符の外にあるシャープ記号は、通常コメントとして扱われます。特殊文字を含むパスワードを引用符で囲まずに貼り付けると、途中から後ろがコメントと解釈される場合があります。ファイル自体は読み込めても、接続時の認証に失敗することがあります。真偽値はtrueまたはfalse、ポート番号は整数、空のリストは[]で記述します。画面からコピーした全角コロンは設定に使わないでください。見た目が似ていても、YAMLのキーと値を区切る記号にはなりません。

1つのファイルと複数の設定レコード

複数のProfileは通常、互いに切り替えて使うもので、自動的に重ね合わせられるわけではありません。選択中のProfileがクライアントの主な設定元になります。グローバル上書きが引き続き適用されるかどうかは、クライアントの適用範囲によって異なります。2つのサブスクリプション全体を単純に連結すると、トップレベル項目が重複したり、同名ノードが上書きされたりする可能性があります。複数の設定元を組み合わせる場合は、重複項目の解析結果に頼らず、プロキシコレクションやクライアントのマージ機能を明示的に使ってください。

リモート設定を更新すると、手作業で編集した元ファイルが新たにダウンロードされた内容で置き換わることがあります。長期的に使う個人ルールは独立した上書き設定に保存し、一時的な試験ではローカルProfileにコピーして、見分けやすい名前を付けましょう。インポート、削除、Profileの切り替え方法はProfileと複数設定の管理方法を参照してください。この先は、最終設定に明確な構造が1セットだけあることを前提に説明します。

2. ポート・モード・実行時の設定

共通項目では、クライアントがリクエストを受け付けるポート、プロキシの動作モード、ログの詳細度を設定します。変更前に、リクエストの入口を確認してください。ブラウザーがシステムプロキシを使うのか、コマンドラインから個別にプロキシを指定するのか、それともTUNでデバイス全体の通信を取り込むのかを見極めます。これらは同時に使えますが、同じ設定スイッチではありません。ポートが待ち受け状態でも、アプリがそこへリクエストを送らなければ、プロキシ接続は発生しません。

port・socks-port・mixed-port

portはHTTPプロキシの入口、socks-portはSOCKSの入口、mixed-portは同じポートで両方の接続を受け付けます。普段のデスクトップ利用なら、通常はmixed-portだけで十分です。「設定を完全にする」ためにすべての入口を有効にする必要はありません。ポート番号は固定ではなく変更できますが、クライアントのシステムプロキシ設定、ブラウザー拡張機能、コマンドラインの環境変数も合わせて更新してください。

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

profile:
  store-selected: true

この例では、ローカルマシンからのリクエストだけを受け付けます。同じLAN内の別のデバイスから接続するには、allow-lan、待ち受けアドレス、システムファイアウォールをあわせて確認してください。スイッチを有効にするだけでは不十分です。すべてのネットワークインターフェースで待ち受けるとアクセス範囲が広がるため、信頼できないネットワークに直接公開しないでください。一時的な共有が終わったらローカル待ち受けに戻し、ルーターのポートフォワーディングも確認しましょう。不要な転送設定は無効にしてください。

モードは通信の振り分けを制御する。システムプロキシを有効にする設定ではない

ruleはルールに従って接続先を決め、globalは通常のリクエストにグローバルポリシーを適用し、directは通常のリクエストを直接接続します。ここでいうグローバルモードは、デバイス内のすべてのアプリを自動的にプロキシへ接続するという意味ではありません。コアに届いていない通信は制御できません。普段はルールモードを使い、特定サイトの問題を調べるときだけ一時的にグローバルモードへ切り替えて、振り分けが原因か確認しましょう。比較後はルールモードに戻し、本来直結すべき通信までリモートに送らないようにしてください。

profile.store-selectedはプロキシグループの選択状態を保存し、再起動後に復元するための設定です。YAML全体の変更を保存する機能ではありません。グループ名の変更、ノードの削除、キャッシュのリセットによって復元結果が変わる場合があります。サブスクリプション切り替え後に選択肢が想定と異なる場合は、直近のクリック履歴だけで判断せず、グループの現在のメンバーを確認してください。各モードの使い分けはルール・グローバル・直結モードの解説をご覧ください。

TUNは別の通信入口

TUNは仮想ネットワークインターフェースとルーティングを使って通信を取り込み、システムプロキシに対応していないプログラムにも適しています。以下は一般的な設定例ですが、有効にする前に、クライアントに必要なサービスがインストールされ、システム権限が付与されていることを確認してください。デスクトップクライアントがこれらの項目を画面から管理する場合、設定画面でTUNを無効にしていると、元ファイルを編集しても実行状態が変わらないことがあります。モバイル端末ではシステムのVPNインターフェースを使うことが多いため、デスクトップ向けサービスのインストール手順をそのまま適用しないでください。

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

stackはプロトコルスタックの実装を選びます。利用可能な値や対応状況は、使用中のmihomoコアで確認してください。プロトコルスタックの変更を、あらゆるネットワーク問題に対する万能な解決策と考えてはいけません。auto-routeはルートを作成し、auto-detect-interfaceは出口インターフェースを検出します。複数のネットワークアダプター、別のVPN、仮想マシンのネットワークが判定に影響する場合があります。DNSのリダイレクトは、条件に一致する通常のDNSリクエストを処理するものです。アプリ内の暗号化DNSまですべて取り込めるとは限りません。

3. DNS・fake-ip・名前解決の経路

DNSはドメイン名からIPアドレスを取得しますが、プロキシ設定ではルール判定、ノードサーバーの名前解決、接続経路にも影響します。まず、2種類のドメインを区別しましょう。Webサイトへのアクセス時に解決する宛先ドメインと、プロキシ接続を確立する際に解決するノードサーバーのドメインです。後者が、まだ接続できていないプロキシ経由のアクセスに依存すると、循環が発生します。「すべてのノードが同時に失敗する」場合は、Webサイトのルールをすぐに変えるのではなく、まずノードサーバーの名前解決を確認してください。

まずはシンプルで把握しやすいDNS設定にする

以下の例ではfake-ipを使い、上流DNSとノード用のDNSサーバーを指定しています。ローカルのDNSサービスと競合しないよう、待ち受けポートは設定していません。システムのDNSリクエストがコアに届く経路は、クライアントのTUN設定またはDNS連携設定で確認してください。例にあるパブリックDNSへ接続できるかどうかは、現在のネットワーク環境によります。実際に使う前にローカルネットワークで到達性を確認し、利用するか判断しましょう。DNSサーバーのアドレスが、あらゆる地域で使えるとは限りません。

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

default-nameserverは、DNS上流サーバー自身のドメイン名を解決するための設定で、「予備のWebサイト向けDNS」という意味ではありません。nameserverは通常の問い合わせに使う上流サーバーです。proxy-server-nameserverはプロキシサーバーのドメイン名を解決し、プロキシ接続に必要な名前解決経路を明確にします。ノードがドメイン名を使い、その上流サーバーへの接続にも同じノードが必要な場合は、依存関係が循環していないかを優先して確認してください。

fake-ipが返すのは仮想アドレスで、ノードのアドレスではない

fake-ipモードでは、アプリに仮想アドレスを返し、コアがドメイン名との対応を保持して、その後の接続を処理します。198.18のアドレス帯が表示されても、Webサイトが実際にこのネットワーク上にあるわけではありません。また、それだけでDNSが汚染されているとは判断できません。重要なのは、その後の接続も同じコアを経由するか、名前の対応情報が有効かどうかです。アプリがコアを迂回して仮想アドレスへ直接接続すると失敗します。fake-ipを有効にする際は、通信を完全に取り込めているかも確認してください。

fake-ip-filterは、実アドレスを必要とするドメインを仮想アドレスの応答対象から除外します。LAN内のデバイス検出、一部のゲーム、特殊な認証プログラムなどでは個別の設定が必要な場合がありますが、問題が起きるたびにすべてのドメインを除外するのは避けてください。まずログで対象のドメインを特定し、範囲を絞ったフィルターを追加してから、関連するキャッシュを消去して再試行します。*.lanや*.localは例にすぎないため、実際のLANドメインを確認してください。

ドメインのポリシー、通信のルーティング、キャッシュはそれぞれ別に処理される

イントラネットのドメインだけを内部DNSに問い合わせたい場合は、nameserver-policyでDNSサーバーを個別に指定できます。ただし、「どのDNSを使うか」と「Webサイトへの接続にどのノードを使うか」は別の設定で、後者はルールで決まります。暗号化DNSのHTTPSアドレスも、通信方式を示すだけで、問い合わせがプロキシ経由になるとは限りません。DNSにルールを適用する設定を有効にする前に、ノードのドメイン名と上流DNS自体の名前解決経路を整え、依存関係の循環を防いでください。

IPv6も経路ごとに確認してください。トップレベルのipv6、DNSがAAAAレコードを返すか、ノードが宛先アドレスに対応しているか、システムに利用可能なルートがあるかは、互いに関係しますが同じ条件ではありません。名前解決モードを切り替えても、OS、ブラウザー、アプリに古いキャッシュが残ることがあります。対象の接続を閉じ、必要なキャッシュを消去してから同じドメインをテストしてください。ブラウザーで既存の接続が成功しても、新しい設定の名前解決経路が正しいとは限りません。

4. プロキシノードの項目とプロキシコレクション

プロキシノードには、リモート接続に必要なパラメーターを定義します。どのWebサイトで使うかを決める設定ではありません。共通項目は、名前、プロトコル、サーバーアドレス、ポート、プロトコル固有の認証や通信方式です。プロバイダーから渡されるURI、QRコード、サブスクリプションには追加パラメーターが含まれる場合があります。手動で設定を作り直すときは、アドレスとパスワードだけをコピーしないでください。まずプロトコルを確認し、異なるガイドの項目を混ぜずに、同じプロトコルの設定項目を照合しましょう。

共通項目を確認してから、プロトコル固有の項目を確認する

以下はShadowsocksの設定例です。ドメイン名とパスワードは説明用で、実際の接続には使えません。プロバイダーから正しいパラメーターを入手して設定してください。nameはローカルで参照するための名前なので、見分けやすい名前に変更できます。serverには名前解決可能なホスト名か正しいIPアドレスを指定し、Webページのパスは付けません。portはリモートサーバーのポートで、ローカルのmixed-portではありません。

proxies:
  - name: "サンプル SS"
    type: ss
    server: proxy.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

cipherはサーバー側の設定と一致させてください。新しい方式に見えるからといって、独断で変更してはいけません。暗号方式によって、パスワードの形式に要件がある場合もあります。udp: trueは、ノードが該当するUDP通信を処理できるようにする設定ですが、プロトコル、サーバー、ネットワーク経路の対応も必要です。Webブラウジングはできるのにゲームや音声通話が失敗する場合、この項目を繰り返し有効にするだけでは解決しません。該当する通信がコアに届いているか、リモート側で許可されているかも確認してください。

TLS・SNI・通信方式は互いに代用できない

TLSを使うプロトコルでは、サーバーアドレスとTLSの検証名が異なることがあります。たとえばTrojanでは、sniがTLSの名前のネゴシエーションに使われ、通常はサーバー証明書や設定内容と一致している必要があります。これは任意に設定する高速化用ドメインではなく、実際の接続先IPと一致するとも限りません。WebSocketのパス、HTTP Hostなどの通信パラメーターは別の層の設定なので、個別に一致させてください。SNIを設定しても、ほかの項目が自動的に補われるわけではありません。

proxies:
  - name: "サンプル Trojan"
    type: trojan
    server: proxy.example.com
    port: 443
    password: "your-password"
    sni: proxy.example.com
    skip-cert-verify: false
    udp: true

証明書エラーが発生したら、まずシステム時刻、SNI、サーバー証明書、接続先を確認してください。長期的な対処として証明書検証を無効にするのは避けましょう。重要な本人確認を回避するだけでなく、設定の入力ミスを見逃すおそれがあります。プロバイダーから特殊な証明書や追加の公開鍵パラメーターを指定された場合は、プロトコルの説明に従って設定してください。ほかのプロトコルの項目をこのノードに流用しないでください。古いクライアントではYAMLをインポートできても、新しいコアのプロトコルすべてに対応しているとは限りません。必要に応じてクライアントのダウンロードページから適切なクライアントを選んでください。

proxy-providersはノードを、rule-providersはルールを管理

プロキシコレクションを使うと、ノードの取得元を独立して管理できます。プロキシグループからはuseでコレクション名を参照します。以下ではローカルファイルを使い、基本構造を確認します。相対パスの基準は設定の作業ディレクトリであり、必ずしもダウンロードフォルダーではありません。ファイルにはproxiesのリストを記述し、ポートやルールを含む設定一式を入れないでください。HTTP形式のコレクションには、有効なダウンロードURL、更新間隔、書き込み可能なキャッシュパスも必要です。プロバイダーのURLがコレクションの形式に対応していることも確認してください。

proxy-providers:
  ローカルノード:
    type: file
    path: ./providers/local.yaml

proxy-groups:
  - name: "サブスクリプションの出口"
    type: select
    use:
      - ローカルノード

リモートの取得元を更新する際は、アカウントの認証情報が含まれる場合があるため、サブスクリプションURLを慎重に扱ってください。設定を共有する前に、完全なURLとパスワードを削除しましょう。ノード名を隠すだけでは不十分です。コレクションの読み込みに失敗したら、まずパスと形式、次にネットワークからのダウンロード、最後にグループの参照先を確認します。有効なメンバーがなければ、グループが存在していても期待した出口は使えません。インポートの成功、ノードの存在、実際に接続できることは、それぞれ分けて確認してください。

5. プロキシグループの種類と参照関係

プロキシグループはルールとノードの間に位置し、安定した名前を付けておくと管理しやすい設定項目です。ルールは常に「プロキシ出口」を参照し、グループ内のノードはサブスクリプション更新に合わせて変更できます。ノードを切り替えるたびにルールを編集する必要はありません。グループを作っても新しいプロトコルが追加されたり、UDP非対応のノードがUDPに対応したりするわけではありません。候補の中から何を選ぶか、いつ再選択するかを決める機能です。

selectは手動選択、自動グループは候補を自動判定

selectは手動選択グループです。自動選択グループ、直結、固定ノードなどを並べて選びたい場合に適しています。url-testは候補を定期的にテストし、その結果をもとに選択します。fallbackは設定順に従って利用可能な候補を使うことを重視します。テスト結果は指定先への到達性を示すもので、すべてのWebサイトが速くなることや、帯域幅を保証するものではありません。グループの種類を選ぶ前に、固定した優先先が必要なのか、テスト結果に応じて自動で切り替えたいのかを決めましょう。

proxy-groups:
  - name: "プロキシ出口"
    type: select
    proxies:
      - 自動選択
      - DIRECT

  - name: "自動選択"
    type: url-test
    use:
      - ローカルノード
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

rules:
  - MATCH,プロキシ出口

ここでは前の章で作成した「ローカルノード」コレクションを使います。この部分だけをコピーする場合は、先に対応する定義を追加してください。intervalは秒単位でテスト間隔を設定し、toleranceは小さな差による頻繁な切り替えを抑えます。テスト先には安定したアドレスを指定し、実際のネットワーク環境に合うものを選んでください。特定の経路で制限されるアドレスでは、テスト結果が実情を反映しないことがあります。例では実際の接続テストに使えるアドレスを指定していますが、導入前に現在の環境からアクセスできることを確認してください。

負荷分散で1つの接続の帯域幅が合算されるわけではない

load-balanceは複数の候補に異なる接続を振り分ける機能ですが、通常、1つのダウンロード接続を複数ノードに分けて帯域幅を合算するものではありません。ログイン、決済、長時間接続が必要なサービスなど、出口IPの維持が求められる場合もあります。明確な要件がない場合は、手動グループまたは自動選択グループから始めると、接続先を把握しやすくなります。負荷分散は、振り分け方式とセッションの制約を理解してから検討してください。

自動グループのテストが成功しても、既存の接続がすぐに新しいノードへ移るとは限りません。接続済みの通信は通常、元の出口を使い続け、新しい接続からグループの選択結果が反映されます。問題を調べるときは、接続履歴で実際の経路を確認し、新しいリクエストを送ってください。グループ画面で選択項目が強調表示されているだけで、すべての通信が切り替わったと判断しないでください。コアを再起動すると接続をリセットできますが、実行中の通信が切断されます。切り替えのたびに再起動する必要は通常ありません。

安定したグループ名でサブスクリプションの変更を切り離す

「プロキシ出口」や「仕事用アクセス」のような、安定した名前の業務用グループを1層作り、ルールから参照させます。その内部でノードコレクションや自動選択グループを利用してください。階層はシンプルに保ちます。通常は、ルールから業務用グループ、業務用グループから候補グループ、候補グループからノードへつなぐ構造で十分です。グループどうしを循環参照させても意味はなく、設定の読み込みに失敗する原因にもなります。たとえば甲が乙を含み、乙が甲を含む構造は避け、参照を一方向にしてください。

名前の重複にも注意が必要です。ノードとプロキシグループには、できるだけ異なる名前を付けてください。同じ名前だと実行時の経路を読み解きにくくなります。コレクションの更新でメンバー名が変わると、手動選択の状態が復元されないことがあります。コレクション参照を使えば固定ノード名への依存を減らせますが、有効なメンバーがあることは引き続き確認してください。正規表現での絞り込みはシンプルな式から始め、結果を確認してから範囲を狭めます。最初から条件を厳しくしすぎると、候補がすべて除外されるおそれがあります。

モバイル端末では接続テストの頻度にも注意してください。複数の自動選択グループやプロキシコレクションでヘルスチェックを有効にすると、同じようなリクエストが重複する場合があります。間隔を短くしても、必ず安定性が向上するわけではありません。重複するテストを減らし、実際に使う候補だけを残して、バックグラウンドでの動作を比較しましょう。バッテリー消費が多い場合は、スマートフォンでのバックグラウンド動作と省電力の確認方法もご覧ください。バッテリー残量の一度の変化だけでコアの故障と判断しないでください。

6. ルールの順序・構文・ルールセット

ルールモードでは、上から順にルールを照合し、最初に一致したルールのポリシーを適用します。より「正確な」後続ルールを探し続けることはありません。そのため、例外は上のほうに、範囲の広いルールは後ろに置き、最後にMATCHで残りのリクエストを処理します。名前が似ていても適用範囲が同じとは限りません。ドメイン全体、サブドメイン、文字列のいずれを照合するかに応じて、ルールの種類を選んでください。

ドメインルールとIPアドレスルールを分けて考える

DOMAINはドメイン名全体に一致し、DOMAIN-SUFFIXはドメイン名本体とサブドメインに一致します。DOMAIN-KEYWORDはキーワードで照合するため適用範囲が広く、意図しない通信まで一致するおそれがあります。特定のサイトの接続先を設定する場合は、短いからという理由でキーワードを使わず、完全なドメイン名かサフィックスを使いましょう。ルールにプロトコルのプレフィックスやWebページのパスは指定しません。通常、ドメインルールだけで特定のURLのページを区別することはできません。

rules:
  - DOMAIN,internal.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,プロキシ出口
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - MATCH,プロキシ出口

この例では、社内サイトを先に直結し、それ以外のexample.comへのリクエストをプロキシグループへ送ります。順序を逆にすると、社内サイトも広い範囲を対象とするサフィックスルールに先に一致します。IP-CIDRはIPアドレスの範囲に使い、IPv6では対応するIP-CIDR6を使います。no-resolveは、IPルールの判定だけを目的とした追加のドメイン解決を行わない設定です。リクエスト全体でDNSが不要になるわけではありません。接続先にすでにIPアドレスがある場合は、そのアドレスを使って判定できます。

ルールセットのbehaviorをファイルの内容に合わせる

ルールセットを使うと、長いドメイン一覧を独立して管理できます。domainはドメインのリスト、ipcidrはIPアドレス範囲のリスト、classicalはルールの種類を含む従来形式のルールセットに使います。Clashの設定ファイル全体をルールセットとして扱うことはできません。また、プロキシのサブスクリプションURLをルールセットの取得元に指定しないでください。以下ではローカルのdomainセットを使います。接続先はメイン設定で指定し、セットのファイルには照合範囲だけを記述します。

# メイン設定の例
rule-providers:
  仕事用ドメイン:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/work.yaml

rules:
  - RULE-SET,仕事用ドメイン,プロキシ出口
  - MATCH,DIRECT

# ./rules/work.yaml
payload:
  - "example.com"
  - "+.example.org"

この例では、example.comを完全なドメイン名として指定し、+.example.orgでドメイン本体とサブドメインを表しています。classic形式のルールセットには、DOMAIN-SUFFIX,example.orgのように種類を指定した項目を記述できますが、ルールセット内に接続先のポリシーを重ねて記述しないでください。接続先はメイン設定のRULE-SETで指定します。HTTPルールセットには、更新間隔とキャッシュパスも必要です。初回ダウンロードに失敗した場合は、利用可能なキャッシュがあるか確認してください。更新失敗がすべてのルールの停止につながるとは限りません。

接続履歴で実際に一致したルールを確認する

ルールを変更したら、対象への新しいリクエストを送り、接続画面でドメイン、適用ルール、ポリシーの経路を確認してください。ブラウザーのページはログイン、画像、APIなど複数のドメインに同時にアクセスする場合があります。アドレスバーに表示されたメインドメインだけを変更しても、解決しないことがあります。実際に失敗したリクエストを特定し、範囲を絞ったルールを追加してください。広い範囲に一致するキーワードで、すべての通信を同じ出口に送るのは避けましょう。アプリ内の暗号化DNS、コネクションの再利用、IPアドレスだけを使った接続によって、ドメイン情報が見えにくくなる場合もあります。

プロセスルールはデスクトップアプリの振り分けに使えますが、コアがプロセス情報を取得できることが条件です。OSの権限や通信の入口によって動作が異なるため、使用する環境で確認してから利用してください。プロセス名をあらゆるOSで使える共通識別子として扱わないでください。GEOIPや地理情報を使うルールも、対応するデータファイルとその更新状況に依存します。まず明確なドメインルールで振り分けが正常に動くことを確認し、その後に大きなルールセットを導入すると、問題を切り分けやすくなります。

7. 上書き・マージ・サブスクリプション更新

上書き機能は、リモートのサブスクリプションから個人設定を切り離すためのもので、元ファイルとほぼ同じ内容の大きなファイルをもう一つ管理するためのものではありません。よくある用途には、ローカルのポートを固定する、イントラネットサイトの例外を追加する、安定したプロキシグループを作る、DNSを変更するといったものがあります。クライアントによって上書き形式や処理順序が異なります。画面で提供される機能が、項目の置換、再帰的マージ、ルールの先頭への追加、スクリプト処理のどれなのかを確認してください。特定クライアントの制御キーをmihomo標準の項目と混同しないようにしましょう。

どの設定元を変更し、どのProfileに適用するかを確認する

一般的には、リモート設定の取得、クライアントの変換や拡張の適用、個人の上書き処理、コアへの受け渡しという流れで考えられます。グローバル設定や実行時の変更が加わる場合もあるため、実際の順序はクライアントで有効な設定を確認してください。特定のサブスクリプションだけに必要な例外は、該当するProfileに適用するのが基本です。すべての設定に必要なローカル項目だけを、グローバルな適用範囲にします。範囲を広くしすぎると、別のサブスクリプションに存在しないグループを参照するおそれがあります。

上書きを追加する前に元の設定をコピーし、現在のモード、グループの選択状態、再現可能なテスト対象を記録してください。次に、まずDNSを固定するなど、変更する項目を一種類に絞ります。ノードとルールを同時に変更しないでください。読み込みに成功したら、元ファイルと最終設定を比較し、値が想定どおり変わったか、既存のリストが残っているか、必要なグループが削除されていないか確認します。結果を確かめてから次の変更に進みましょう。「保存しました」という表示だけで、一度にすべての変更を追加するより確実です。

スカラー値の上書きとリストのマージは異なる

modeのようなスカラー値は、後から指定した値で上書きされることが多くあります。dnsのようなマッピングは再帰的にマージされる場合も、全体が置き換わる場合もあります。rulesのようなリストは、特に全体が置き換わりやすい項目です。どちらのクライアントも機能を「マージ」と呼んでいても、動作が同じとは限りません。以下は意味上の変更前後を示す例で、すべてのクライアントにそのまま貼り付けられる上書き構文ではありません。

rules:
  - DOMAIN-SUFFIX,example.org,プロキシ出口
  - MATCH,プロキシ出口

rules:
  - DOMAIN,intranet.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,プロキシ出口
  - MATCH,プロキシ出口

ここでは、例外ルールを先頭に追加し、既存のルールも残す必要があります。クライアントがリストの置き換えにしか対応していない場合は、置き換え後の全項目を明示的に作成してください。ルールを先頭に追加する機能があるなら、そちらが適しています。ファイルの末尾にrulesキーを追加しただけでは、ルールが自動的に先頭へ移動することはありません。複数ファイル間のリスト結合にYAMLアンカーを使うのも避けてください。アンカーは主に同一ドキュメント内で値を参照するためのもので、クライアントのマージ処理の代わりにはなりません。

同名グループと動的なノードも考慮する

サブスクリプション内のグループ名は変更される場合があります。個人ルールからプロバイダーのグループ名を長期間参照していると、更新後に参照先が見つからなくなることがあります。安定した名前の業務用グループを自分で作り、プロキシコレクションを参照させる方法があります。クライアントが明示的に対応しているスクリプトを使い、条件に応じてメンバーを生成する方法もあります。スクリプトでは、ノード一覧が空の場合や名前が重複する場合も処理してください。ダウンロードのたびに同じノードがあると決めつけず、候補が見つからないときに未確認の出口を暗黙に選択しないようにしましょう。

個人の上書き設定には、できるだけプロバイダーの認証情報を重複して保存しないでください。サブスクリプションのパスワード更新時に、複数箇所を管理せずに済みます。手動設定のノードとサブスクリプションのノードを併用する場合は、異なる名前を付け、取得元も記録してください。マージに失敗したら、まず個人拡張を無効にし、元のサブスクリプションが読み込めることを確認してから、項目を一つずつ戻します。元のサブスクリプション自体に問題がある場合は、設定元を先に修正してください。トップレベル構造の詳しい解説はconfig.yamlの項目別解説をご覧ください。

8. 設定の検証・切り分け・復元

検証は3段階に分けられます。ファイルを解析できること、コアが設定を受け付けること、リクエストが想定どおりに動くことです。YAML構文が正しくても、最初の段階を通過しただけです。未対応の項目、存在しないグループ名、形式が合わないルールセットがあれば、コアに拒否されることがあります。コアの起動に成功しても、すべてのリモート先に接続できるとは限りません。この3段階に沿って確認すれば、起動エラーをネットワークエラーと取り違えたり、意味なくクライアントを再インストールしたりするのを避けられます。

まず静的チェックを行い、その後に実際の通信経路をテストする

mihomoのコマンドライン版コアをインストール済みの場合は、設定ファイルがあるディレクトリでテストコマンドを実行できます。Windowsでは対応する実行ファイル名を使い、それ以外のOSでは実際のインストール先を指定してください。以下は、現在のディレクトリに実行ファイルとconfig.yamlがある想定です。コマンドで確認できるのは設定の妥当性であり、プロバイダーのアカウントが有効か、すべてのリモートリソースをダウンロードできるか、各ルールが想定どおりに動くかまでは分かりません。デスクトップクライアントでは、画面に設定チェック機能が用意されている場合もあります。

# Linux / macOS：テスト用ディレクトリで実行
./mihomo -t -d . -f ./config.yaml

# Windows PowerShell：テスト用ディレクトリで実行
.\mihomo.exe -t -d . -f .\config.yaml

相対パスの問題は、まず作業ディレクトリを明示して解決してください。-d .は現在のディレクトリを設定の作業ディレクトリに指定します。ルールセットやプロキシコレクションが参照するファイルも、指定先に置く必要があります。テストを通すためだけに、実行中のクライアントのデータディレクトリをむやみに移動しないでください。単独でテストする場合は、必要なファイルを別のディレクトリにコピーしましょう。パスを確認しやすくなり、デバッグでメイン設定やキャッシュに影響することも防げます。

再現できるリクエストを1つに絞ってログを確認する

詳細なログが必要な場合は、一時的にlog-levelをdebugに設定し、関係のないアプリを終了してから、対象を1つだけ開いてください。まずリクエストがコアに届いているか、次に一致したルールとポリシーの経路、最後に接続段階のエラーを確認します。リクエストの記録自体がない場合、原因はシステムプロキシ、アプリ側のプロキシ設定、TUNによる通信の取り込みにある可能性があります。リモートノードを先に変更する必要はありません。ポリシーの経路が正しい場合は、名前解決、認証、TLSを確認してください。

すべてのエラーログを同じ問題として扱わないでください。バックグラウンドでルールセットの更新に失敗していても、既存キャッシュを使ってWebページを正常に表示できる場合があります。1つのテスト先に接続できなくても、すべての通信が失敗しているとは限りません。ログを共有するときは、エラーの前後の状況と時刻順を残しつつ、サブスクリプションURL、認証情報、公開したくないドメインを削除してください。「タイムアウト」の一文だけでは、名前解決、接続、ハンドシェイクのどこで失敗したか判断できません。

感覚ではなく、比較テストで修正を確認する

HTTPプロキシを明示してリクエストを送ると、ポートの入口をテストできます。以下のコマンドで確認できるのは、リクエストがローカルのmixed-portを経由して送信されるかどうかだけです。システム全体の通信が取り込まれていることや、UDPの動作までは確認できません。コマンドを実行する前に、コアが指定したポートを待ち受けていることを確認してください。接続を拒否された場合は、サブスクリプションをすぐに変更せず、まずローカルサービスとポートを調べましょう。テスト先は、現在のネットワークで結果を予測できるサイトを選んでください。

curl -I --proxy http://127.0.0.1:7890 https://example.com

次に、直結するはずの接続先とプロキシ経由にするはずの接続先へそれぞれアクセスし、接続画面で結果を確認します。ルールを変更したら新しい接続を作成し、DNSを変更したら古いキャッシュの影響を考慮してください。グループを切り替えた後は、実際の通信経路を確認します。「何を変更したか、何をテストしたか、どうなったか」を毎回記録し、効果を説明できる変更だけを残しましょう。原因を特定できない場合はノードのタイムアウトを確認する手順に沿って範囲を絞るか、ヘルプセンターで該当する症状を探してください。

設定の復元と今後のメンテナンス

設定を戻すときは、まず追加した上書きを無効にし、検証済みのProfileに切り替えます。それでも問題が続く場合は、システムプロキシやTUNに、設定と一致しない入口が残っていないか確認してください。比較に使う手がかりを失わないよう、設定、キャッシュ、ログを一度にすべて削除しないでください。クライアントはClash Plusを候補にしつつ、OSや機能要件に合わせてほかの選択肢も比較できます。インストール先はクライアントのダウンロードページにまとめています。古いクライアントが設定項目に対応していない場合は、インデントを何度も変更するのではなく、コアの対応状況を確認してください。

設定が安定したら、デバッグログを通常の詳細度に戻し、不要なテスト項目を削除して、短い変更メモを残してください。バックアップには個人の上書き設定だけでなく、必要なローカルコレクションのファイルも含めます。サブスクリプションURLだけでは個人ルールをすべて復元できません。次回からは更新のたびにいくつかの決まったケースを確認するだけで、ルール順序、グループのメンバー、DNS経路の変化に気づきやすくなります。接続手順を最初から確認する場合はクイックスタートガイドに戻ってください。このページは設定項目を調べる際に引き続き利用できます。