mihomo · 設定ファイルガイド

Clash上級設定ガイド

プロキシグループからネットワークスタックまで、設定が適用される順に確認します。インストールとサブスクリプションの読み込みが済み、接続できている方向けの内容です。初めて使う場合は、まずクイックスタートを完了してください。クライアントを選ぶ場合はダウンロードページをご覧ください。ここでは各設定の連携方法と、変更後の確認方法を解説します。

読み進め方

現在動作している設定を保存し、一度に変更するのは1つの設定項目に絞りましょう。設定を再読み込みしたら、接続、ルール、ログを確認します。以下の例は各項目の関係を示す独立した抜粋です。サブスクリプションに適用する際は、同名の項目がすでにないか確認し、複数の例をそのままつなげてトップレベル設定を重複させないでください。

設定ガイド 01 / 07

プロキシグループの種類と選び方

プロキシグループは、ルールに一致した通信を最終的にどのノードや出口へ送るかを決めます。ルーティングを調べるときは、まずルールの転送先グループ名を確認し、次にそのグループで選択されているメンバーを見ます。プロキシ一覧で利用可能と表示されているノードを見ただけでは、その通信に使われるとは限りません。よくある設定では、ノードを「手動選択」に登録し、「自動選択」や「フォールバック」などのグループから同じノードを参照します。そのうえで、各サービスのルールを上位グループに向けます。グループ名はルール末尾の転送先と、大文字・小文字や空白も含めて完全に一致させてください。サブスクリプション更新後は、ノードの絞り込み条件が新しい名前にも合っているか確認しましょう。

4種類の選択方式

selectはユーザーが選んだメンバーを維持するため、ログインやリモートアクセスなど、出口を固定したい場合に適しています。テスト結果が変わっても自動でノードを切り替えません。url-testはテストURLへの応答時間を基準にメンバーを選ぶため、日常のブラウジングなど出口の変化を許容できる用途に向いています。fallbackはメンバーの並び順に従い、最初に利用可能なものを使います。主回線を優先し、切断時のみ切り替えたい場合に適しています。load-balanceは複数のメンバーに異なる接続を振り分けます。同じサイトで安定した出口が必要なら、ログイン通信を負荷分散グループに割り当てるのは避けましょう。テストの成功はテスト先に到達できたことを示すだけで、すべてのサイトが使える保証にはなりません。特定のサイトで失敗する場合は、実際の接続ログも確認してください。

種類出口が切り替わるタイミング確認する項目
selectユーザーがメンバーを手動選択したとき選択中の項目、メンバー名
url-test定期テストで応答の速いメンバーが選ばれたときテスト先、間隔、許容値
fallback先行するメンバーのテストに失敗したときメンバーの順序、テスト状態
load-balance新しい接続がグループに入ったとき振り分け方式、接続先サイトのセッション

ノードを確認しやすいグループに登録する

以下では、設定に「ノードA」と「ノードB」という名前のプロキシが登録済みとします。実際にはサブスクリプションで提供されたノード名に置き換え、同名のプロキシグループを重複して作成しないでください。intervalの単位は秒です。toleranceは自動選択時に現在のメンバーを維持するための遅延差で、測定結果が僅差のときに頻繁に切り替わるのを抑えます。テストURLには、自分のネットワークから安定してアクセスでき、短い応答を返すアドレスを指定してください。ログインが必要なサイトをテスト先にするのは避けましょう。

proxy-groups:
  - name: 手動選択
    type: select
    proxies:
      - ノードA
      - ノードB
      - DIRECT
  - name: 自動選択
    type: url-test
    proxies:
      - ノードA
      - ノードB
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
  - name: フォールバック
    type: fallback
    proxies:
      - ノードA
      - ノードB
    url: http://www.gstatic.com/generate_204
    interval: 300
rules:
  - DOMAIN-SUFFIX,example.org,手動選択
  - MATCH,自動選択

見落としやすい違いとして、ノードのテストはグループのメンバーに対して行われ、実際のリクエストはまずルールに照合されます。例のドメインルールより前にDIRECTルールがあると、そのリクエストは「手動選択」に入りません。調査するときは、クライアントの「接続」を開いて対象ドメインと一致したルールを確認し、どのグループを参照しているかを確かめます。続いて「プロキシ」で、そのグループのメンバーと選択状態を確認してください。変更後も既存の接続に以前の出口が表示される場合は、その接続を切断して新しいリクエストを送ります。確立済みの接続は通常、途中で経路が変わりません。

最後にフォールバックルールを確認します。通常、MATCHはルール一覧の末尾に置き、前のルールに一致しなかった通信の出口を決めます。先頭に置くと、それ以降の個別ルールが機能しません。一時的にルールの動作を確認する場合は、特定のドメインを手動グループに割り当て、新しい接続を作ってログを確認しましょう。すべての通信をグローバルモードに切り替える必要はありません。テスト後は確認用ルールを削除し、元の順序と選択状態に戻せば、変更範囲を追跡できます。

設定ガイド 02 / 07

ルールセットを購読して管理する

ルールセットを使うと、頻繁に変わるドメインやIPアドレスの項目をメイン設定から分離できます。rule-providersで取得元、形式、ローカルキャッシュの保存先を定義し、rulesからRULE-SETで参照します。ルール内容の更新時にメイン設定を1件ずつ編集せずに済みますが、ダウンロード、解析、キャッシュ、参照という読み込み経路が増えます。どこかで失敗すると、想定したルーティングが機能しない場合があります。まず、必要なのがリモートルールセットなのか、少数の変更しないローカルルールなのかを見極めましょう。カスタムドメインが数件だけなら、rulesに直接記述するほうが管理しやすい場合があります。

ルールセットの形式を確認する

behavior: domainはドメイン項目、behavior: ipcidrはネットワーク範囲に使用します。behavior: classicalでは、従来形式のルール式を扱えます。format: yamlまたはformat: textは、ダウンロードする内容に合わせて指定してください。ファイルの拡張子だけでは判断できません。YAML形式のルールセットでは通常、payloadの下に項目を列挙します。従来形式ではDOMAIN-SUFFIXなどの種類を示す接頭辞を使用できます。従来形式のルールテキストをドメイン形式として読み込ませたり、ウェブページのエラーメッセージをルールファイルとしてキャッシュしたりすると、解析に失敗します。リモートURLを初めて参照する前に、ブラウザーでルールの内容が返ることを確認してください。ログインページやリダイレクト先の説明ページではないことも確かめましょう。

例では項目の関係を示すため、ドキュメント用ドメインを使っています。このアドレスは購読可能なルールソースではありません。実際に使う際は信頼できるルールセットのURLに置き換え、ファイルに合わせてbehaviorとformatを設定してください。キャッシュ用のpathには設定ディレクトリからの相対パスを使い、複数のproviderで同じファイルを指定しないでください。intervalは更新確認の間隔であり、リクエストごとに再ダウンロードする設定ではありません。

rule-providers:
  work-domains:
    type: http
    behavior: domain
    format: yaml
    url: https://example.com/rules/work-domains.yaml
    path: ./rules/work-domains.yaml
    interval: 86400
rules:
  - RULE-SET,work-domains,手動選択
  - DOMAIN-SUFFIX,example.org,DIRECT
  - MATCH,自動選択

上の例に対応するwork-domains.yamlは、次のように記述できます。ドメイン形式のルールセットにはドメイン項目だけを書き、メイン設定のrulesで使うプロキシグループ名を各行に繰り返し追加しないでください。出口は、それを参照するRULE-SETの行で指定します。同じルールセットを複数のルールから参照することもできますが、先に一致したルールが優先されるため、順序を確認してください。

payload:
  - example.net
  - '+.example.org'

読み込み経路に沿って確認する

更新後は、まずクライアントにルールセットのダウンロードエラーや解析エラーが表示されていないか確認します。次にキャッシュファイルの有無と、内容が想定した形式であることを確認してください。ダウンロードできてもルールが機能しない場合は、RULE-SETに記載したprovider名、対応するプロキシグループ名、rules内の位置を確認します。ドメインルールの照合には、参照可能なドメイン情報が必要です。接続先がIPアドレスしかない場合、想定どおりにドメインルールへ一致するとは限りません。IPルールではDNS解決や、no-resolveなどのオプションが照合経路に与える影響にも注意してください。特定のルールを一致させるために、DNS設定を一度にすべて変更するのは避けましょう。

サブスクリプション自体にルールやルールセットが含まれている場合もあります。更新のたびにクライアントがメイン設定を上書きするなら、ダウンロード後の設定を直接編集しても一時的な変更にしかなりません。クライアントのオーバーライド機能を使うか、自分で管理する設定にルールソースを固定してください。ルールを移行する際は、まず検証しやすいドメインを1つ残し、再読み込み後に「接続」で新しいRULE-SETに一致することを確認してから、ほかの項目を移します。役割が重複し優先順位が不明なリモートルールを、複数同時に有効化しないでください。どれが先に適用され、どれがフォールバックを担当するのかを把握しましょう。

設定ガイド 03 / 07

DNS設定と名前解決の経路

DNS設定が関わるのは、接続先ドメインの名前解決と、プロキシサーバー自身のドメインの名前解決という異なる2つの処理です。まず、ブラウザーからのDNSリクエストがクライアントを経由しているか確認してから、DNSサーバーの一覧を検討しましょう。システムプロキシは通常、アプリのHTTPまたはSOCKS通信を処理しますが、システム内のすべてのDNS問い合わせを処理するわけではありません。TUNモードとDNSハイジャックは別の経路です。ドメインを解決できても接続できない場合は、ルールの一致、ノードへの到達性、接続ログも確認してください。「ページが開かない」というだけでDNSの問題だと判断するのは避けましょう。

主なDNSサーバー設定項目

default-nameserverは、DNSサーバー自体のドメイン名を解決するなど、初期の名前解決に使います。直接アクセスできるIPアドレスを指定するのが適切です。nameserverは通常の問い合わせに使うDNSサーバーの一覧です。proxy-server-nameserverではプロキシノードのドメイン名を解決するサーバーを個別に指定でき、業務ドメインのルールによる影響を避けられます。nameserver-policyはドメインごとに使用するDNSサーバーを指定します。サーバーURL、通常のIPアドレス、ポート付きアドレスを混同しないでください。指定するプロトコル形式が現在のコアでサポートされていること、またネットワークからそのDNSサーバーに到達できることを確認しましょう。

以下の抜粋は、各サーバーの役割を最小限の構成で示しています。自分のDNSサーバーをすべて例のアドレスに置き換える必要はありません。有効にする前に、現在のネットワークからこれらのアドレスへアクセスできるか確認してください。特に、アクセス制限のあるネットワークや、社内ドメインの解決に内部DNSが必要な環境では注意が必要です。respect-rulesなど、DNSの送信経路に影響するオプションは、基本の名前解決が正常だと確認してから検討しましょう。DNSサーバーとプロキシノードのドメイン解決が相互に依存する事態を避けられます。

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 1.1.1.1
  nameserver:
    - 1.1.1.1
    - 8.8.8.8
  proxy-server-nameserver:
    - 1.1.1.1
  fake-ip-filter:
    - '*.lan'
    - localhost.ptlogin2.qq.com

ipv6: falseは例としての設定であり、すべてのネットワークでIPv6を無効にすべきという意味ではありません。端末、DNSサーバー、プロキシ経路でIPv6を正常に利用できる場合は、実際の接続要件に合わせて判断してください。fake-ip-filterは、一部のドメインに実際の名前解決結果を返す設定です。LAN内の機器検出に依存するアプリやFake-IPを利用できないアプリに適しています。項目を増やすほど、想定した照合経路を意図せず迂回していないか確認が必要です。社内ドメインは、その名前を解決できる内部DNSに処理させましょう。パブリックDNSがLAN内のアドレスを返すことを期待しないでください。

1つのリクエストから問題を切り分ける

まずクライアントのDNS機能が有効か確認し、設定を再読み込みして、ログにDNSサーバーへ到達できないというエラーが出ていないか確認します。次に対象ドメインへ新しい接続を行い、実際のアドレス、Fake-IP、または応答なしのどれになったか記録してください。クライアントのログに問い合わせが出ていない場合は、アプリ独自のセキュアDNS、別のDNSサーバーを参照しているシステム設定、現在のプロキシモードがその問い合わせを処理しているかを確認します。問い合わせがログに記録されているのに応答が想定と異なる場合は、nameserver-policyの一致項目、Fake-IPフィルター、ローカルキャッシュを確認してください。設定変更後はクライアントのキャッシュ消去方法に従って再テストし、古い結果を新しい設定の結果と誤認しないようにしましょう。

DNSサーバーが正常に応答しても、その後の接続が正常とは限りません。テストには、ドメインと出口ルールが分かっているリクエストを選び、「接続」で最終的なルールを確認しましょう。DIRECTに一致した場合は、直結ネットワーク側を調べます。プロキシグループに一致した場合は、そのグループのノードを確認してください。社内ネットワークでは、社内ドメインの名前解決経路を維持することが特に重要です。元のDNS設定を記録してから1項目ずつ変更し、調査中にDNS、ルール、TUNを同時に変えないでください。どの変更から問題が起きたかを把握しやすくなります。

設定ガイド 04 / 07

TUNモードとFake-IPの組み合わせ

システムプロキシとTUNでは、通信を取り込める範囲が異なります。システムプロキシは、アプリがOSのプロキシ設定に従う必要があります。TUNは仮想ネットワークインターフェースを作成し、プロキシ設定を参照しないアプリの通信もより多くクライアントに取り込みます。TUNを有効にしても、すべての問題が自動的に解決するわけではありません。ルートの設定、DNSハイジャック、ほかのVPN、LANアクセス、システム権限が結果に影響します。初めて有効にする際は、通常のシステムプロキシで接続できることを確認し、現在のDNSとルートの状態を記録してください。TUNを有効にした後に問題が起きても、元からあった設定の問題か、新たに取り込んだ通信経路の問題かを切り分けやすくなります。

最小構成から始める

auto-routeはコアにルート設定を試みさせる項目です。auto-detect-interfaceは実際の出力インターフェースを識別します。ネットワークインターフェースが頻繁に変わる端末では、特に識別結果を確認してください。dns-hijackのany:53は、条件に合う従来型のDNS問い合わせを取り込む指定ですが、アプリ独自の暗号化DNS接続まで処理できるとは限りません。クライアントによっては画面のスイッチでこれらの項目を書き込む一方、ネットワーク拡張機能や仮想インターフェースの権限をOSに許可する必要があります。スイッチの表示だけで判断せず、クライアントが有効な設定として表示する内容を確認してください。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

stack: mixedは、テスト用に選べるネットワークスタックの一つです。特定のアプリのハンドシェイクやLANアクセスに問題がある場合は、症状を記録してから、クライアントが対応する別のスタックと比較しましょう。すべてのルート設定を同時に変更するのは避けてください。端末で企業VPN、別の透過プロキシ、仮想マシンのブリッジを利用している場合は、ルートの優先順位とインターフェースの競合に注意します。複数のソフトがデフォルトルートを取り込もうとすると、頻繁に切断されたり、本来LANを通るアドレスが誤った出口に送られたりすることがあります。まず別の通信制御ツールを一時的に停止して比較し、その後でルートの除外やインターフェースの調整が必要か判断してください。

Fake-IPの対応関係を理解する

Fake-IPは、対象ドメインをすぐに実IPアドレスへ解決するのではなく、アプリに合成アドレスを返し、コア内にドメインとアドレスの対応関係を保持します。その後、接続が届いたときにコアがドメインを復元し、ドメインルールとの照合に使います。この仕組みが機能するには、DNS問い合わせとその後の接続が、相互に対応付けられる同じ経路でクライアントに届く必要があります。アプリが別のDNS経路を使用している場合や、古いアドレスをキャッシュしている場合は、ドメインと接続が対応しないことがあります。特定のアプリがIPアドレスしか表示せず、ドメインルールに一致しない場合は、DNS問い合わせと接続の両方がログに記録されているか確認してください。

LAN内機器の検出、プリンター、画面ミラーリング、実アドレスを必要とする一部のアプリでは、Fake-IPが適さない場合があります。対象を特定できたら、そのドメインだけをフィルターに追加して、機器の検出と接続をテストしましょう。ドメインサフィックスのリストを広範囲に除外するのは避けてください。LAN内のIPアドレスにアクセスできない場合は、プライベートアドレスをプロキシグループへ送るルールになっていないか、OSのファイアウォールとローカルネットワーク権限も確認します。Fake-IPフィルターが扱うのは名前解決の結果であり、ルーティングルールの代わりにはなりません。調査後はブラウザー、システムプロキシに従わないアプリ、LAN内サービスをそれぞれテストし、TUNで必要な通信を取り込みつつ、ローカルアクセスが維持されていることを確認してください。

設定ガイド 05 / 07

ドメインスニッフィングとルール照合

クライアントが接続先のIPアドレスしか認識できず、ドメインルールで出口を判断したい場合、ドメインスニッフィングで接続のプロトコルハンドシェイクからドメインを取得できることがあります。主にHTTPリクエストやTLS、QUICのハンドシェイクで確認できる情報を調べる仕組みで、ウェブページの内容を読み取るものではありません。暗号化された接続すべてから元のドメインを取得できるわけでもありません。取得したドメインで接続先を上書きするか、ルーティングに使うかは、該当するオプションで決まります。有効にする前に「接続」を確認してください。接続先のドメインがすでに表示され、ルールも正常に一致しているなら、表示されるドメインを増やすためにスニッフィングの範囲を広げる必要はありません。

対象プロトコルとポートを絞る

以下の例では、一般的なHTTP、TLS、QUICの通信を対象にします。portsで調査する範囲を制限し、override-destinationでスニッフィング結果を使って接続先を上書きするか指定します。まずは使用中のアプリに合うポートだけを残し、問題のある接続を対象にテストしてください。QUICはUDPを使います。ネットワークまたはクライアントが該当するUDP通信を取り込んでいない場合、QUICのスニッフィング項目を追加しただけでは、その接続はコアに届きません。標準以外のポートを使うHTTPも同様に、実際のサーバーポートを個別に確認してください。

sniffer:
  enable: true
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
      override-destination: true
    TLS:
      ports:
        - 443
    QUIC:
      ports:
        - 443
  skip-domain:
    - '+.lan'

例では、ローカルネットワークを使うと明確に分かっている接続に余計な判定を行わないよう、LAN内ドメインを除外しています。実際の設定では使用するアプリも考慮してください。IPアドレスでサーバーに接続する一方、TLSハンドシェイクにアクセス目的とは異なるドメインを含めるアプリもあります。スニッフィング結果で接続先を強制的に上書きすると、元のルーティング動作が変わる可能性があります。特定のサービスでスニッフィングを有効にした後に問題が起きた場合は、有効化前後の接続先、照合ルール、エラーログを比較してから、その接続先を除外する条件を設定しましょう。ルールによる振り分けをすべて無効にするのは避けてください。

スニッフィングを一連の切り分けに組み込む

接続をドメインで振り分けられるか確認するには、少なくとも3点を調べます。DNSから対応付け可能なドメインが得られているか、スニッフィングでドメインを取得して利用しているか、ルール一覧でフォールバックルールより前に該当するドメインルールへ一致するか、です。「接続」にIPアドレスしか表示されない場合は、アプリがもともと固定IPを使っていないか確認してください。ドメインが表示されても出口が誤っている場合は、スニッフィング対象を増やすのではなく、まずルールの順序とプロキシグループを調べましょう。Fake-IPを有効にした通信では、アプリのDNSと接続が同じ取り込み経路を通っているかも確認してください。

スニッフィングは「すべてのIPをドメインに変える」ための汎用スイッチではありません。ホスト名を識別できないプロトコルもあり、プロトコルの更新でハンドシェイクから確認できる項目が変わる場合もあります。ログにスニッフィング結果がないからといって、クライアントが接続を処理していないとは限りません。接続先、ルールとの一致、最終的な出口という、確認できる情報に戻って調べてください。変更はアプリごとにテストし、一度に変えるのはプロトコルか除外条件のどちらか1つにします。既存の接続を切断してから、新しいリクエストを送ってください。ブラウザーだけで問題が起きる場合は、ブラウザー独自のDNSやQUICが有効か、ほかのアプリとは異なる通信経路を使っていないかも確認しましょう。

設定ガイド 06 / 07

ローカルオーバーライドと複数サブスクリプションの統合

サブスクリプションは提供元が更新するため、ダウンロードしたファイルを直接編集しても、次回更新までしか変更が維持されないことがあります。ローカルオーバーライドを使えば、長期間管理するポート、DNS、ルール、プロキシグループの設定を、更新対象となるノード情報と分離できます。オーバーライドの実装はクライアントによって異なります。設定の読み込み後にパッチを適用するもの、項目ごとにマージするもの、スクリプトで最終的なYAMLを生成するものがあります。まずクライアント画面で「オーバーライド」「設定の統合」などの項目を探し、適用順を確認してから、変化を見分けやすい項目で試してください。配列が必ず追加されるとは限りません。ルールやプロキシグループが全置換されると、既存のルーティングが失われる可能性があります。

最終的に適用されているファイルを確認する

確認すべきなのはエディター内の断片ではなく、クライアントが読み込んだ後の完全な設定です。mixed-port、mode、dns、proxy-groups、rulesに、想定した項目だけが残っているか確認してください。以下は自分で管理する設定に記述できるトップレベル項目の例です。クライアントのオーバーライド画面が特定のパッチ形式のみ受け付ける場合は、その画面の仕様に合わせて変換してください。この例がすべてのクライアントで使えるオーバーライドファイルとは限りません。ポートが競合する場合は、どのプロセスが使用中かを確認してから設定を変更し、そのポートを使うアプリの設定も合わせて更新しましょう。

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

複数サブスクリプションの統合では、ノード名も確認が必要です。2つのサブスクリプションに「自動選択」「既定ノード」や同じ地域名が含まれる場合があります。統合ツールが名前で上書きすると、最終設定が別のサブスクリプションのメンバーを参照することがあります。統合前に元のサブスクリプションを保存し、それぞれのノード名と更新頻度を記録してください。統合後は、最終的なproxies、proxy-providers、proxy-groupsで名前の参照先を確認します。ノード一覧は素材にすぎません。どのグループがノードを選択するか、ルールがどのグループを参照するか、更新後の新しいノードがどのようにグループへ追加されるかも明確にしましょう。

更新後の確認手順を決めておく

まずサブスクリプションを1つずつ更新し、元の設定が解析できることを確認します。次にローカルオーバーライドを適用し、最終設定を読み込めるか確認してください。続いて、DIRECTルール、プロキシルール、最後のMATCHをそれぞれ確認し、新しい接続を作って照合結果を検証します。最後にサブスクリプションを再更新して、もう一度テストしましょう。最初は成功して更新後に失敗する場合は、オーバーライドが再適用されているか、グループのメンバー絞り込みが更新後のノード名にも一致するかを重点的に確認します。ダウンロード、統合、解析、接続のどの段階で失敗したかを記録すれば、異なる問題を混同せずに済みます。

ルール一覧の最終的な順序を管理する場所は、1つに決めておくのがおすすめです。サブスクリプションAのMATCHがサブスクリプションBの個別ルールより前にあると、Bのルールは実行されません。統合ツールが同名のグループを複数そのまま連結した場合も、参照先が曖昧になることがあります。正常に接続できる元の設定を保存し、大幅な変更の前には現在使えるオーバーライドを複製してください。サブスクリプションURLが完全なYAMLを提供するのか、ノード一覧を提供するのか知りたい場合は、サブスクリプションの形式と変換をご覧ください。形式を変換しても、元のルールやプロキシグループがすべて保持されるとは限りません。

設定ガイド 07 / 07

外部コントローラーパネルと設定確認

外部コントローラーを使うと、対応するパネルから接続、ルール、プロキシグループの状態を確認でき、選択中のグループを切り替えたり、設定を再読み込みしたりできる場合もあります。コントローラーは混合プロキシポートとは別のサービスです。mixed-portはアプリの通信を受け付け、external-controllerは管理用インターフェースを提供します。設定の調査では、パネルを使って現在のグループ選択を確認したり、実際の接続とルールを調べたりできます。ただし、表示結果は稼働中のコアの状態が基準です。クライアント内蔵の画面で同じ情報を確認できるなら、管理用のネットワーク接続を新たに公開せず、まず内蔵画面を使いましょう。

まずローカルアドレスにバインドする

パネルを同じパソコンから使う場合は、管理インターフェースを127.0.0.1にバインドしてください。ローカルのパネルに接続するために、すべてのネットワークインターフェースで待ち受ける設定にする必要はありません。例の空のsecretは、ローカルに隔離したテスト環境でのみ使用できます。LAN内の別端末からアクセスする必要がある場合は、専用の管理用キーを設定し、アクセス可能なネットワークを限定したうえで、システムのファイアウォールも確認してください。サブスクリプションURL、管理用キー、ノードの認証情報を含む設定全体を、出所の分からないオンラインパネルに貼り付けないでください。

external-controller: 127.0.0.1:9090
secret: ""
mixed-port: 7890
mode: rule

コントローラーのアドレスとポートはコア側で設定しますが、パネル側にも接続先の指定が必要です。クライアント内蔵パネルが自動で読み込む場合もあれば、独立したパネルで手動入力が必要な場合もあります。接続できない場合は、コアが該当設定を読み込んでいるか、ポートを別のプロセスが使用していないか、パネルが同じ端末に接続しているか、ブラウザーやシステムプロキシがローカルの管理リクエストを遠隔へ送っていないか確認してください。ポートを変更した場合は、パネルに保存された接続先も更新します。認証エラーが出たら、コントローラーのキー設定を確認してください。ノードサブスクリプションのパスワードをパネルのキー欄に入力しないようにしましょう。

パネルの表示から設定ファイルに戻って確認する

パネルにグループが表示されても、ルールから参照されているとは限りません。グループを切り替えられても、新しい接続が必ずそのグループを通るとは限りません。順に確認するには、まず「設定」で現在読み込まれているファイルと更新状態を確認し、次に「ルール」で対象ドメインのルールを調べ、最後に「接続」でそのリクエストの照合結果を確認します。クライアントで設定を切り替えたのにパネルに古いグループが表示される場合は、パネルを更新し、コントローラーが別のコアのインスタンスに接続していないか確認してください。パネルにキャッシュされた表示だけを根拠に設定を書き換えないでください。

設定の読み込みに失敗した場合は、ログに表示された項目名と行番号を確認し、YAMLのインデント、トップレベルキーの重複、ルールで参照しているグループ名、providerのローカルパスを調べます。YAMLでは空白で階層を表現し、リスト項目のハイフンは正しい階層に置く必要があります。ウェブページから設定をコピーすると、タブや全角記号が混入して解析に失敗する場合もあります。まず保存済みの正常な設定に戻し、このページの例を少しずつ追加して再読み込みするほうが、壊れたファイルを頼りに推測を重ねるより確実です。初回インストール後の接続方法が分からない場合はクイックスタートに戻ってください。GUIクライアントを変更する場合は、ダウンロードページでプラットフォームを選択してください。Clash Plusは掲載クライアントのおすすめです。