Clash クライアントのダウンロードとルール振り分け設定

ルールで接続の出力先を決める

ルールモードでは、設定の記述順にルールを評価し、一致すると通常は後続のルールを調べません。特定サイトにはドメインサフィックス、LANアドレスにはIPアドレス範囲が適しています。地域データを使うルールには、対応するデータベースが必要です。すべての接続を一つの出力先に送るグローバルモードと異なり、ルールモードでは日本国内のサービスを直接接続しながら、指定したサイトだけをプロキシグループに振り分けられます。問題を調べるときは、まずログで一致したルールを確認し、次にプロキシグループの選択状態を見ましょう。ノードだけを変更しても、ルールの順序が誤っていれば解決しません。末尾のMATCHで、ほかの接続を処理します。

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

この設定例では、既存のProxyプロキシグループと利用可能なGEOIPデータが必要です。

プロキシグループでルールを受け、出力先を選ぶ

プロキシグループを使うと、ルールと実際のノードを別々に管理できます。ルールではグループ名だけを参照するため、後からノードを切り替えてもルールを一つずつ修正する必要はありません。selectグループは手動選択に向いています。自動テストやフォールバックのグループを使う場合は、テスト用アドレスと更新間隔も設定してください。各ルールにノード名を直接記述する方法に比べ、グループ化すると管理しやすくなり、サブスクリプション側でノード名が変更された際の影響も抑えられます。以下は直接接続の選択肢だけを含む構成例です。設定に統合した後、プロキシ経由で接続するには、既存ノード名を追加するか、定義済みのプロキシプロバイダーを参照してください。

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

TUNでより多くのアプリの通信を取り込む

TUNは仮想ネットワークインターフェースを使って通信を処理するため、システムプロキシ設定に従わないアプリにも適しています。TUNが変えるのは、通信をコアに取り込む経路であり、ルール、ノード、DNSの設定に代わるものではありません。システムプロキシだけを使う場合と異なり、TUNではルーティングと高い権限が関わります。有効にする前に通常のプロキシ接続が使えることを確認し、サービスのインストールやシステムの許可を済ませてください。LANにアクセスできなくなった場合は、ルートの除外設定とDNSの横取り範囲を確認しましょう。ネットワークスタックの対応状況はOSによって異なるため、以下の設定は各プラットフォームのドキュメントに合わせて調整してください。

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

DNS設定は名前解決とドメイン判定に影響する

DNSはドメイン名をIPアドレスに変換するだけでなく、コアがドメインに基づいてルールを判定できるかどうかにも関係します。fake-ipモードでは仮想アドレスとリクエストのドメイン名を対応付けるため、TUNとの併用に適していますが、一部のLAN機器やアプリでは例外設定が必要になることがあります。システムのDNSをそのまま使う場合と異なり、コアのDNSを使うと名前解決を一元管理できますが、上流DNSと通信の取り込み経路を正しく設定する必要があります。ウェブページが開けないときは、名前解決の失敗と接続の失敗を切り分けてから設定を調整してください。以下は基本項目のみの例です。既存のDNS設定全体を置き換えないでください。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query

設定全体のサブスクリプションとプロキシプロバイダーの更新を区別する

クライアントに読み込む設定全体のサブスクリプションと、コアのproxy-providersで管理するノード一覧は、異なる階層のものです。前者にはルール、グループ、DNS設定が含まれる場合があり、後者は通常、プロキシグループから参照できるノードだけを提供します。設定全体のサブスクリプションから生成されたファイルを直接編集すると、更新時に変更が上書きされることがあります。変更を長期的に保持するには、クライアントが対応する上書きまたはマージ機能を使いましょう。ノード一覧の管理には、手動で何度も読み込むより定期更新が便利ですが、配信元と更新ログの確認は必要です。以下はローカルファイルを使う例で、リモートのサブスクリプションURLは含みません。

proxy-providers:
  local-nodes:
    type: file
    path: ./providers/local.yaml

ローカルファイルが存在し、正しいproxiesリストを含んでいる必要があります。プロキシグループからuseでlocal-nodesを参照してください。

システムプロキシでアプリの通信を待ち受けポートに送る

システムプロキシを有効にすると、システム設定に従うアプリがローカルのプロキシ入口を使います。mixed-portは、コアがHTTPとSOCKSのリクエストを受け付けるポートを指定します。両者を一致させる必要があり、設定ファイルのポートだけを変更してもシステム設定が変わるわけではありません。TUNによるネットワーク層での取り込みとは異なり、一部のコマンドラインツールでは別途プロキシの指定が必要です。初めて使う場合は、クライアントのデフォルトポートを維持し、ほかのプロキシアプリを終了しておくとよいでしょう。以下はローカル端末のみで待ち受ける設定例です。LANに公開する場合は、認証とファイアウォールの制限を別途検討してください。

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