Clash 高度な設定ガイド

プロキシグループの種類と振り分けの実践

ルール、プロキシグループ、ノードの役割を区別する

ルールは接続をどこに渡すかを決め、プロキシグループは次にどの出口を選ぶかを決めます。ノードは実際のプロキシ接続を確立します。これらは別々の設定レイヤーです。モードをルールモードにすると、接続はルールの上から順に照合され、指定されたプロキシグループに渡されます。グループが別のグループを参照している場合もあり、最終的にノードまたは組み込みのDIRECT、REJECTに到達します。ルールがPROXYにマッチしても、特定のノードを経由したとは限りません。プロキシグループの経路をたどり、最後に選ばれた出口を確認してください。

設定内の名称は文字列で参照されるため、大文字・小文字、空白、句読点まで一致させる必要があります。グループ名を「自動選択」から「自動」に変えた場合、そのグループを参照するルールやほかのグループの名称も合わせて変更してください。proxy not foundのようなエラーが出たら、サブスクリプションを何度も更新するのではなく、まず存在しない名称を探します。GUIによっては前回の手動選択が保持されます。グループ構成を変更した後、以前の選択が有効とは限らないため、再読み込み後に現在の出口を確認しましょう。

手動選択、自動選択、フォールバック

selectは出口を明示的に制御したい場合に適しています。選択はユーザーが行い、通常、疎通テストの結果によって自動で切り替わることはありません。url-testは候補の接続性をテストし、許容範囲などの条件に応じてテスト結果の良い候補を選びます。fallbackは候補の設定順を重視し、先頭から利用可能なものを優先します。load-balanceは指定した方式で接続を振り分けます。1つのファイル転送を自動で複数の回線に分割する機能ではありません。

以下はプロキシグループの設定例です。既存のproxiesまたはプロキシプロバイダーに「ノード-A」と「ノード-B」があることを前提とします。この2つは説明用のノード名なので、実際に使う際は実行時設定にある名称に置き換えてください。テスト用URLは疎通確認の宛先であり、実際のサービスサイトとは限りません。ネットワーク環境によってこのURLだけが制限されている場合、自動選択の結果も正確でなくなります。まず手動選択で接続できることを確認してから自動選択を設定すると、問題の箇所を特定しやすくなります。

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - 自動選択
      - ノード-A
      - ノード-B
  - name: 自動選択
    type: url-test
    proxies:
      - ノード-A
      - ノード-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

頻繁な切り替えより出口の安定性を重視

intervalはテスト間隔を秒単位で指定します。toleranceは自動選択時の切り替えに許容範囲を設け、わずかな変動で出口が変わるのを防ぎます。lazyを使うと、未使用グループへの不要なテストを減らせます。すべてのグループの間隔を短く設定するのは避けてください。プロキシプロバイダーにも独自のヘルスチェックがある場合があります。両方のチェックを頻繁に実行しても、リクエスト量やモバイル端末のバックグラウンド負荷が増えるだけで、ウェブページの表示が速くなるとは限りません。

ログインが必要なサービス、決済ページ、長時間のセッションでは、出口を固定する設定が適していることが多いです。自動切り替えによって同じアカウントが短時間に異なる出口を使うと、サービス側の不正利用検知にかかる可能性があります。用途ごとに手動選択のグループを作り、関連ドメインのルールからそのグループを指定すれば、自動選択を全体で無効にするより細かく制御できます。負荷分散を使う場合は、選択した振り分け方式とセッション維持の関係を理解し、接続ごとに出口が異なる可能性を考慮してください。

検証では、接続画面で対象ドメインを見つけ、マッチしたルール、プロキシグループ、最終的なノードを記録します。次に、利用可能と確認済みの別ノードを手動で選び、古い接続を閉じてから再アクセスしてください。確立済みのTCP接続は、グループを切り替えても通常は自動で移行しません。接続に以前の出口が表示される場合は、接続の再利用と設定の未反映を切り分けます。新しい出口が表示されても失敗する場合は、対象サービス、ノードへの接続性、DNSを確認し、すべての原因をプロキシグループに帰さないようにしましょう。

ルールセットを使ったルール管理

ルールの数より順序が重要

mihomoの通常のルールリストは、一般に上から順に照合され、マッチすると指定されたポリシーに渡されます。特定の例外ルールは広範なルールより前に置き、MATCHは最後のフォールバックとして配置してください。特定ドメインにプロキシを設定しても、その上により広範なDIRECTルールがあると、例外ルールが適用されません。接続の詳細に表示される実際のマッチルールから調べ、リクエストに含まれるドメイン名または宛先IPを確認してからルールの順序を見直しましょう。設定ファイル内でサイト名を検索するだけでは不十分です。

DOMAINは完全一致のドメイン名を照合します。DOMAIN-SUFFIXは指定したサフィックスとそのサブドメインを照合します。DOMAIN-KEYWORDは文字列にキーワードが含まれるかだけで判断するため、対象範囲が広がりやすいルールです。対象サービスが分かっている場合は、完全なドメイン名か明確なサフィックスを優先してください。1つのウェブページからログイン、静的ファイル、APIなど複数のドメインにアクセスすることがあります。トップページのドメインだけを設定しても、一連の処理を網羅できない場合があります。接続履歴を確認して必要な依存先を追加し、すべての接続をグローバルモードに切り替えることは避けましょう。

ルールの内容と参照箇所を分ける

rule-providersでルールの取得元を定義し、RULE-SETでそのルールセットをどこで参照するか、どのポリシーで処理するかを指定します。ルールファイルを個別に更新しながら、メイン設定には分かりやすい実行順序を保てます。以下は構成を確認するためのローカルファイルの例です。クライアントの設定作業ディレクトリにrules/local-direct.yamlを保存してください。クライアントの実行ディレクトリがサンドボックス内にある場合は、対応するファイル管理画面で実際の保存先を確認します。

rule-providers:
  local-direct:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-direct.yaml

rules:
  - DOMAIN,example.com,DIRECT
  - RULE-SET,local-direct,DIRECT
  - MATCH,PROXY

上記のメイン設定にあるPROXYは、あらかじめ定義されている必要があります。以下は対応するローカルルールファイルの内容です。example.orgはサフィックス形式の説明用ドメインなので、実際に運用する際は直結させたいドメインに置き換えてください。ドメイン型のルールセットは通常のルールリストとは異なり、各行にポリシー名を記述しません。まず小さなルールセットが正しくマッチすることを確認してから大量のルールを移行すれば、パス、形式、内容の問題を切り分けやすくなります。

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

behaviorと更新方式を正しく選ぶ

behavior: domainはドメインの集合、ipcidrはIPアドレス範囲の集合、classicalはルールタイプを含む従来形式のルールに使います。ルールプロバイダーのformatもファイル形式に合わせる必要があります。拡張子だけで内容を判断しないでください。DOMAIN-SUFFIX,example.orgをドメイン型の集合に直接記述したり、ポリシー名を含むルール全体をクラシック形式の集合に入れたりすると、解析に失敗したり、想定と異なるマッチ結果になったりすることがあります。

リモートで管理する場合は、プロバイダーをtype: httpにし、信頼できるルールソースが実際に提供するurl、専用のpath、適切なintervalを設定します。複数のプロバイダーで同じキャッシュファイルを使わないでください。更新時に別のルールセットが上書きされるおそれがあります。ルールソースを変更したら、内容を一部確認し、ドメイン一覧ではなくウェブページやエラーメッセージが返されていないことを確かめてから、クライアントでプロバイダーを更新します。設定の再読み込みだけでは、すべてのリモートファイルが再取得されるとは限りません。

ルールのマッチ経路から問題を切り分ける

ルールが適用されない場合は、まず実行モードがルールモードであることを確認します。次に、プロバイダーが読み込まれているか、名前がRULE-SETでの参照名と一致しているか、上位のルールに先にマッチしていないかを確認してください。IPルールのno-resolveは、そのルールのためにドメイン名を自動で解決するのを避ける設定です。ドメインルールをIPルールに変えるものではなく、DNS問い合わせを完全に止める設定でもありません。接続先IPがすでに分かっている接続はIPルールの対象になるため、個々の接続情報に基づいて結果を判断してください。

GEOIPは対応する地理情報データベースに依存します。ルールセットのファイルが正常でも、データベースが正常とは限りません。GeoIP関連のエラーが出たら、ログに記録されたファイルパスとダウンロード失敗の理由を確認し、クライアントのデータベース更新機能を使ってください。設定ディレクトリ全体を何度も削除するのは避けましょう。「ルールが増えるほど問題を特定しにくい」場合は、ローカルの例外、用途別グループ、共通ルール、最終フォールバックの4層に整理し、順に検証します。基本用語は用語集、具体的なトラブルの確認先はヘルプセンターをご覧ください。

DNS設定の調整と名前解決の経路

どこからどこへ問い合わせるかを整理する

DNSのトラブルを調べる際は、アプリ、OS、mihomo、上流DNSリゾルバーを区別する必要があります。ブラウザー独自のセキュアDNSが有効になっていたり、OSに手動設定したサーバーが残っていたり、TUNが一部のDNSリクエストを処理していたりする場合があります。nameserverを変更してもウェブページに変化がないからといって、設定項目が無効とは限りません。リクエストがmihomoを経由していない可能性があります。まずクライアントのログで対象ドメインの問い合わせを確認し、その後でOSのDNS、ブラウザーの設定、通信の処理方法を調整してください。

ドメイン名で指定する暗号化DNSの上流サーバーは、サーバー自体の名前解決が先に必要です。これはブートストラップ名前解決と呼ばれます。default-nameserverは関連する初期名前解決に使われるもので、すべての通信に対して最初に使われるDNSサーバーという意味ではありません。ノードサーバーにドメイン名を使う場合は、proxy-server-nameserverも確認し、「プロキシに接続するにはノード名の解決が必要だが、その名前を解決するにはプロキシ接続が必要」という循環を避けます。プロキシが起動できるかどうかと、通信先ドメインが正しく解決されるかどうかは分けて検証してください。

まずは少数の明確なDNSリゾルバーから始める

以下はDNS設定の例です。ブートストラップ、通常の名前解決、ノードのドメイン名解決を分けています。すべてのネットワークに適した万能の設定ではありません。パブリックDNSに接続できるか、現在のネットワークに対応しているかを実際に確認してください。この例ではローカルの待ち受けアドレスを設定していません。OSやほかの端末からmihomo DNSに接続させる場合は、listenを別途設定し、ポートの競合、権限、ファイアウォールを確認してください。待ち受け項目を追加しただけでLANに公開しないようにしましょう。

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

dns.ipv6: falseは、このDNSモジュールがAAAA問い合わせを処理するかどうかに影響します。OSのIPv6を無効にする設定ではなく、IPv6通信がすべてTUNに取り込まれることを保証するものでもありません。OSにIPv6ルートが残っていれば、アプリがキャッシュや別の名前解決経路を使ってIPv6通信する可能性もあります。実行時設定のトップレベルにあるIPv6設定、TUNのルート、接続履歴も合わせて確認し、DNSの設定項目だけでネットワーク全体の動作を説明しないようにしましょう。

ドメインごとにDNSを指定し、フォールバックを増やしすぎない

nameserver-policyを使うと、特定のドメインを指定したDNSリゾルバーで名前解決できます。社内ドメインや、特定のDNSを使う必要があるサービスに適しています。社内DNSはオフィスネットワークへの接続時にしか利用できないことが多く、すべてのドメインの上流に設定すると、社外では名前解決が全面的にタイムアウトする可能性があります。対象を社内ドメインに限定し、正しいネットワークインターフェースを経由して問い合わせていることを確認してください。対象ドメインに直結ルールも必要かどうかは、宛先に到達できるかを別途確認して判断します。

DNSリゾルバーを増やしても、必ず信頼性が高まるわけではありません。fallbackとフィルター条件によって結果の選択方法が変わるため、リストの順序だけを見て「先頭が失敗したら次へ問い合わせる」と判断することはできません。respect-rulesを有効にしてDNS通信にもルーティングルールを適用する場合は、ノードのドメイン名解決とルールの依存関係も考慮し、ノード用に独立した名前解決経路を確保してください。明確な要件がなければ、まず到達可能な少数のDNSリゾルバーを使い、動作が安定してからドメイン別の設定を追加すると、複雑な依存関係を避けやすくなります。

DNSエラーと接続エラーを切り分ける

トラブルの切り分けは、「問い合わせを受け取ったか」「結果が返ったか」「接続先に到達できるか」の3段階で行います。問い合わせがタイムアウトする場合は、まずDNSリゾルバーへの接続性を確認します。IPアドレスが返っているのにTCP接続がタイムアウトする場合は、ルール、出口、ルーティングを調べます。特定のブラウザーだけ失敗するなら、そのブラウザー独自のDNS、プロキシ設定、キャッシュを確認してください。Fake-IPモードで予約アドレスが表示されるのは仕様です。DNSの改ざんと決めつけたり、そのアドレスを手動でドメインに固定したりしないでください。

変更後は対象アプリの古い接続を閉じ、クライアントが対応する方法でDNSとFake-IPのキャッシュを消去してから試します。必要に応じてOSのキャッシュも消去しますが、毎回システム全体のネットワーク設定をリセットする必要はありません。証明書エラーはDNSを変更すれば解決するとは限りません。まずOSの時刻、証明書の発行者、アクセス先ドメインを確認し、ブラウザーの証明書検証は有効のままにしてください。特定の出口だけで問題が起きる場合は、同じドメインを直結とその出口でそれぞれ試し、違いを記録してから調整方法を判断します。

TUNモードとFake-IPの連携

通信の取り込みと返すIPアドレスは別の仕組み

TUNは仮想ネットワークインターフェースとルーティングを使って通信を受け取り、システムプロキシ設定に従わないアプリにも適しています。Fake-IPはDNS応答とドメインの対応付けの仕組みで、予約アドレスを返すことで、後続の接続とドメインをコアが関連付けられるようにします。併用されることはよくありますが、同じ機能ではありません。システムプロキシは使えるのに特定のアプリだけ使えない場合、アプリがプロキシを迂回している可能性があります。TUNを有効にしても接続できない場合は、権限不足、ルートの競合、アプリ独自の通信方式などが原因かもしれません。DNSモードを必ず変更する必要があるとは限りません。

有効にする前に、使用中のClashクライアントがTUNに対応しているか、サービスモードや管理者権限が必要かを確認してください。Windowsでは対応サービスや権限の昇格が必要になることがあります。macOSではシステムの許可とクライアントの実装が関係します。Linuxでは仮想インターフェースの作成とルート管理の権限が必要です。Androidは通常、OSのVPNインターフェースを使うため、デスクトップのサービスモードの手順は適用できません。インストール方法や権限の許可方法はクライアントの実際の画面で確認してください。機能が見つからない場合は、ダウンロードセンターでクライアントを確認しましょう。

まずは元に戻せる基本設定から始める

以下はデスクトップ環境向けのTUN設定例です。DNSの項目は前章の設定と合わせて確認してください。auto-routeは関連ルートの自動設定を要求し、auto-detect-interfaceは出口インターフェースの検出に使います。dns-hijackは指定したDNS通信を取り込みます。any:53を設定しても、すべての暗号化DNSを検出できるわけではありません。アプリがHTTPSポート宛てに送る独自のDoHリクエストは、通常の53番ポートへの問い合わせとは異なります。

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

stackで選べる値は実行環境やカーネルの機能によって異なります。一般的な値はsystem、gvisor、mixedです。ネットワークスタックの変更、MTUの調整、厳格なルーティングを同時に行い、1回のアクセス結果からどの変更が効いたかを判断するのは避けてください。まずはクライアントの推奨値を使い、ウェブ閲覧、ダウンロード、LANアクセスが正常かを確認します。再現性のある問題がある場合に限り、ネットワークスタックを個別に比較し、ノード、ルール、テストアプリは同じ条件に保ちましょう。

Fake-IPの互換性とLANアクセスへの対応

一部のデバイス検出、LANサービス、実IPアドレスに直接依存するアプリでは、Fake-IPの応答が適さない場合があります。その場合は、対象ドメインをfake-ip-filterに追加して実際のDNS解決を使うようにし、DNSモード全体を切り替えない方法を検討してください。フィルターは関連するDNSの動作を変えるもので、直結ルートを自動で設定するものではありません。LAN内のサービスを直結したい場合は、ルール、OSのルート、使用するネットワークインターフェースも確認します。ドメインがプライベートIPに解決されても、そのアドレスに現在のネットワークから到達できるとは限りません。

すべてのドメインをフィルターに追加すると、Fake-IPの主な利点が失われ、動作も把握しにくくなるため避けてください。Fake-IPのモード、アドレス範囲、フィルターを変更しても、古いキャッシュが残ってアプリが以前の予約アドレスに接続することがあります。対象アプリの接続を閉じ、該当するキャッシュを消去してからテストしてください。企業VPN、コンテナネットワーク、検証環境ですでにFake-IPと重なるアドレス範囲を使っている場合は、範囲を再設計し、キャッシュも合わせて消去する必要があります。ルートを1つ変更するだけで競合を隠そうとしないでください。

権限、ルート、DNS、接続の順に切り分ける

TUNの有効化に失敗した場合は、まずログで権限不足、デバイスの作成失敗、ルート追加の失敗がないかを確認し、該当するOS側の問題に対処してください。有効化できても通信できない場合は、ほかのVPNや通信最適化ツールがデフォルトルートを同時に変更していないか確認します。現在のネットワークの出口が誤って検出されていないことを確認したら、DNS問い合わせがコアに届いているかを調べます。セキュリティソフトやOSのファイアウォールを一括で無効にせず、対象のプロセス、インターフェース、ルールを確認し、必要最小限の許可を維持してください。

ウェブページは表示できるのにゲーム、音声通話、ほかのUDPアプリが失敗する場合は、ノードと上流回線が該当するUDP転送に対応しているかを確認してから、ルールが正しい出口に通信を送っているか調べます。TUNがUDPを受け取っても、接続先が必ず処理できるとは限りません。大きな応答や特定の通信だけが失敗する場合は、MTUや経路の問題を検討し、同じ条件で変更前後を比較してください。最終的には接続履歴とアプリの動作を合わせて判断します。画面にTUN有効と表示されていても、取り込み機能が有効になったことを示すだけで、すべてのアプリが想定どおりに振り分けられているとは限りません。

ドメインスニッフィングでルールマッチを補正する

ドメイン情報を補う必要がある接続

ドメインルールを適用するには、接続から利用可能なドメイン情報を取得できる必要があります。アプリがIPアドレスに直接接続している場合、独自の名前解決を使っている場合、DNS問い合わせがmihomoを経由していない場合は、接続一覧に宛先IPだけが表示されることがあります。ドメインスニッフィングは、一部のプロトコルのハンドシェイク情報からドメインを抽出し、後続の処理に利用しようとする機能です。接続に関する情報を補える場合はありますが、DNSの問題をすべて解決する設定ではなく、すべてのアプリの接続からドメイン名を復元できるわけでもありません。

HTTPのホスト情報、TLSハンドシェイクのサーバー名、一部のQUICハンドシェイク情報が、ドメインの識別に使われる場合があります。TLSスニッフィングはHTTPSの本文を復号する機能ではありません。そのためにパケット解析用のルート証明書をインストールする必要もなく、暗号化された内容を読み取れるわけでもありません。暗号化されたClientHelloなどの仕組みが使われると、ドメイン情報を取得できないことがあります。このような接続では識別機能の限界を受け入れ、既知のIP範囲、アプリ向けのルール、信頼できるDNS経路を使いましょう。スニッフィングの範囲を広げ続けるのは避けてください。

対象ポートを絞り、限定的に適用する

以下は、一般的なプロトコル向けのスニッフィング設定例です。HTTPとTLSの対象ポートを限定し、すべてのポートを無差別に処理しないようにします。この例ではoverride-destinationを無効にしており、宛先の扱いをすぐに変更せず、ドメインの識別状況から確認できます。クライアントによっては、GUIのスイッチから同じ設定項目が生成される場合があります。有効にする前に、サブスクリプションにすでにsnifferが設定されていないか確認してください。ローカルでの変更が別のレイヤーに上書きされるのを防げます。

sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true
  override-destination: false
  sniff:
    HTTP:
      ports:
        - 80
        - 8080
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443

parse-pure-ipを有効にすると、ドメイン情報のないIP接続も処理対象として試せますが、必ずドメインを取得できるわけではありません。force-dns-mappingはDNSマッピングに関係する処理であり、正しいDNS設定の代わりにはなりません。override-destinationは、スニッフィングで取得したドメインを宛先の処理に反映するかどうかに関わるため、用途に合わせて検証してください。プロトコル別の上書き設定もある場合は、最終的に適用される値を確認します。トップレベルのスイッチだけを見て、すべての接続の動作を判断しないでください。

ドメインの識別と出口の変更を分けて検証する

まず、通常はIPアドレスだけが表示され、安定して再現できるリクエストを1つ選びます。スニッフィングを有効にして接続し直し、接続の詳細にドメインが表示されるか、マッチするルールが変わるかを確認してください。ドメインを識別できても直結のままなら、ルールの順序とプロキシグループの選択を確認します。ドメインが表示されない場合は、対象プロトコル、ポート、ハンドシェイクが識別可能な範囲に含まれているかを調べます。接続が1つ変化しなかっただけで、設定全体が読み込まれていないと判断しないでください。同じページ内のリソースでも、異なるプロトコルが使われることがあります。

スニッフィングで得られたドメイン情報も、無条件に正しいとは限りません。アプリによっては異なる用途の通信を同じ接続にまとめたり、IPアドレスで接続しながら別の名称を含めたりします。宛先の上書きを有効にした後、特定のサービスだけが失敗する場合は、まずスニッフィング自体は維持したまま上書きを無効にして比較してください。互換性の問題が確認できた場合に限り、対象を明確にしたうえでskip-domainなどの除外設定を使います。例外の理由を説明できるようにし、検証していないサービス名を大量に追加しないでください。

互換性、プライバシー、パフォーマンスの注意点

スニッフィングは接続開始時のデータを識別する処理を追加します。効果は現在のDNS経路や通信の種類によって異なります。Fake-IPによって大半の接続とドメインがすでに正しく関連付けられているなら、識別範囲をさらに広げる必要はないかもしれません。サーバーへの長時間接続や独自プロトコルでは、元の宛先の意味を保つことを優先してください。ログのドメイン表示を充実させるために、正常な接続を損なわないようにしましょう。調査が終わったら一時的なデバッグログを無効にし、不要なドメイン名やアクセス経路の情報を長期間保存しないでください。

証明書の警告が出たら、まず証明書がアクセス先サイトのものか確認し、宛先の上書きを有効にした場合と無効にした場合を比較してください。スニッフィングは証明書の警告を無視する理由にはなりません。「修正を確認する」ために安全でない接続を許可するのも避けてください。対象ドメインとルールが正しいのに特定のノードだけで失敗する場合は、出口と接続先サービスを調べます。識別できないプロトコルでは、スニッフィング項目を増やすより、アプリのプロキシ対応、DNSの名前解決、IPルールの設計を見直すほうが効果的です。

ローカル上書きと複数サブスクリプションの統合

変更がどの段階で保持されるかを確認する

サブスクリプションの原文、ローカルの設定コピー、上書きルール、最終的な実行時設定は、それぞれ別のものです。サブスクリプションからダウンロードしたファイルを直接編集すると、次回の更新で置き換えられることがあります。実行時設定を編集しても、次の再読み込みで再生成される場合があります。継続して使うルールは、クライアントが対応するローカル上書き、拡張設定、スクリプトの仕組みに追加してください。Clashクライアントによってメニュー名や処理順序は異なります。特定クライアントのスクリプトAPIをmihomo共通の設定項目と考えないでください。

画面で現在の設定の取得元と、全体上書きやサブスクリプションごとの上書きが設定されているかを確認します。見分けやすいルールを1つ使って、設定の保存、再読み込み、実行時設定の確認、サブスクリプションの更新、実行時設定の再確認まで行いましょう。各段階で想定どおりに動作することを確かめてから、大量のカスタマイズを移行してください。更新後にルールが消えた場合は、まずどの設定レイヤーに書き込んでいたかを特定します。手動で貼り付ける回数を増やして対処すると、設定元を追跡しにくくなるだけです。

完全なサブスクリプションとノードプロバイダーを区別する

完全なClash YAMLには、通常、ノード、プロキシグループ、ルール、その他の設定が含まれます。ノードサブスクリプションにこれらの構造が含まれるとは限りません。Base64でエンコードされたノード一覧を完全なYAMLとしてそのまま使うこともできません。複数のサブスクリプションを統合する前に、入力の形式を確認してください。構造の違いについては、サブスクリプション形式と変換ガイドをご覧ください。サブスクリプションURLの認証情報はローカルにのみ保存し、公開ログやスクリーンショット、オンライン変換サイトに入力しないでください。

既存のデータがmihomoのノードプロバイダー形式に対応している場合は、proxy-providersを使ってノードの取得元とメイン設定を分けられます。以下はローカルのノードファイルを使った構成例です。ファイルには実際のproxiesリストを含めてください。任意の完全なサブスクリプションをそのまま置き換えるための入口ではありません。入力ファイルがウェブページの案内やエンコードされたテキストだけの場合は、信頼できるローカルの手順で正しい形式にしてからプロバイダーに読み込ませてください。

proxy-providers:
  office:
    type: file
    path: ./providers/office.yaml
  travel:
    type: file
    path: ./providers/travel.yaml

proxy-groups:
  - name: PROXY
    type: select
    use:
      - office
      - travel

リモートノードプロバイダーを使う場合は、ソースごとに異なる名称とキャッシュパスを割り当て、提供元が実際に公開しているURLと更新間隔を指定します。ノードファイルとルールセットファイルに同じパスを使わないでください。クライアント独自のインポート機能でサブスクリプションを管理している場合は、その画面で更新を続け、生成後のノードをローカル上書きから参照する方法もあります。ただし、更新後も参照先が有効であることを確認してください。一時的なファイル名や不安定な内部ディレクトリに依存しないようにしましょう。

配列、同名オブジェクト、優先順位

統合で特に間違いやすいのは配列の扱いです。上書きに新しいrules配列を追加した場合、クライアントによって既存の配列を置き換えることも、「先頭に追加」「末尾に追加」として扱うこともあります。スクリプトで明示的に結合する必要があるクライアントもあります。マッピング形式の項目も、必ずしも再帰的に統合されるとは限りません。画面に「マージ」と表示されるだけで全項目が保持されると思い込まず、生成後の設定全体を確認してください。特に、既存のMATCHが最後に残っていること、ローカル例外が共通ルールより前にあることを確認しましょう。

複数のサブスクリプションに同じノード名やプロキシグループ名が含まれることはよくあります。そのまま連結すると、参照先が曖昧になったり、名称が衝突したり、インポートに失敗したりします。管理された統合手順でノード名にソース名の接頭辞を付け、グループ内の参照も合わせて更新してください。プロバイダーのフィルター式を使っている場合は、名称変更がフィルター結果に影響しないかも確認します。表示名だけを変えて、ルールの参照先を古いままにしないでください。統合後は、どのルールからでも存在するプロキシグループをたどり、有効なノードまたは組み込みポリシーまで確認できる状態にします。

検証、ロールバック、移行

mihomoの設定テストモードを使うと、構文や参照先を確認できます。実行ファイルがあるコマンドライン環境で以下のコマンドを実行し、config.yamlにはテスト対象のファイルを指定してください。相対パスで指定したリソースは実行時の作業ディレクトリに依存します。GUIクライアントの実際の作業ディレクトリは異なる場合があるため、コマンドラインで検査に通った後もクライアントで再読み込みし、プロバイダーの読み込み結果を確認してください。構文が正しくても、サブスクリプションの取得元に接続できることや、すべてのノードが接続できることを保証するものではありません。

mihomo -t -f config.yaml

元に戻す際は、まず今回追加した上書きを無効にし、前回動作していた設定を復元してから再読み込みし、動作を確認します。「変更の目的、対象項目、検証したドメイン、復元箇所」を簡潔に記録しておくと、見分けのつかない設定ファイルを何世代も残すより役立ちます。クライアントを移行する際は、まずサブスクリプション、次にルールとDNS、最後にGUI側のスクリプトを移行してください。クライアントごとに起動設定、TUNの権限、上書き機能の設定が異なるため、YAMLを1つコピーするだけでは移行は完了しません。

外部コントローラーパネルとLAN共有

プロキシの接続口と管理用の接続口を分ける

プロキシポートはアプリの通信を受け付け、コントローラーは状態の参照、プロキシグループの切り替え、接続の管理を行います。同じネットワーク内の端末にプロキシを共有する場合でも、コントローラーを同時に公開する必要はありません。mixed-portはHTTPとSOCKSで共用するプロキシの待ち受けポートです。external-controllerは管理APIのアドレスです。役割、権限、リスクが異なるため、「スマートフォンからPCのプロキシに接続できない」問題を管理ポートの公開で解決しようとしないでください。

単独で使用する場合は、コントローラーをループバックアドレスだけで待ち受けるようにします。以下はローカル管理の設定例です。例のパスワードは説明用の仮の値なので、実際に有効にする前に、このPC専用の長いランダムなパスワードを生成してください。例の値をそのまま使わないでください。secretはコントローラーの認証に使う項目であり、ノードのパスワードやサブスクリプションの認証情報とは別のものです。クライアントがコントローラーの設定を管理している場合は、その設定画面で変更してください。起動時に手動設定が再生成されるのを防げます。

mixed-port: 7890
allow-lan: false
external-controller: 127.0.0.1:9090
secret: "your-password"

接続パネルを設定する前に待ち受けと認証を確認する

接続パネルには通常、コントローラーのアドレスとパスワードを入力します。コントローラーが起動し、アドレスに到達でき、認証が通って初めて、パネルからプロキシグループや接続を読み取れます。パネル自体が開かない問題と、パネルは開くのにコアへ接続できない問題は別です。前者はパネルのリソース、後者はAPIアドレス、ポート、認証、ブラウザーのネットワーク制限を確認します。ログにaddress already in useと表示されたら、そのポートを使っているプロセスを探してください。すべての待ち受けアドレスを全ネットワークインターフェースに変更して解決しようとしないでください。

パネルをローカルでホストする場合は、入手済みの信頼できる静的パネルファイルを設定作業ディレクトリ内の専用フォルダーに置き、external-uiでパスを指定します。関係のないファイルが公開されないよう、ユーザーディレクトリ全体を静的リソースの公開先にしないでください。ブラウザーからアクセスする際は、ページのプロトコルにも注意が必要です。HTTPSページからHTTPのAPIにアクセスすると、混在コンテンツとして制限される場合があります。オリジンをまたぐリクエストでは、許可するオリジンの設定が必要になることもあります。これらはサブスクリプションの問題ではありません。

パネルはカーネルを操作できるため、読み取り専用のダッシュボードではありません。コントローラーの認証情報を、公開URLのクエリ文字列、公開スクリーンショット、共有ブックマークに含めないでください。認証を省くためにパスワードを空にするのも避けましょう。リモート管理が必要な場合は、管理リクエストを管理された専用ネットワークやセキュアなトンネル経由にし、アクセス元を制限してください。リバースプロキシ、アクセス認証、TLSはそれぞれ正しく設定する必要があります。複雑なパスワードだけでネットワーク境界を代替することはできません。

LAN共有では必要なプロキシポートだけを公開する

共有する前に、2台の端末が相互に通信できるネットワークに接続されていること、PCの現在のLANアドレスが安定していること、ルーターでクライアント間の通信が遮断されていないことを確認します。Clashクライアントで「LAN内接続を許可」を有効にし、実際の待ち受けアドレスとOSのファイアウォールを確認したうえで、信頼できる必要なネットワーク範囲だけにプロキシポートへのアクセスを許可してください。スマートフォンにはPCのLANアドレスを指定します。127.0.0.1はスマートフォン自身を指すため、PCには接続できません。

以下はプロキシ共有の設定例です。コントローラーは引き続きループバックアドレスで待ち受けます。bind-addressは、関連するLAN許可設定が有効な場合に、その仕様に従って動作します。実際の待ち受け状態も確認してください。例の認証値は説明用の仮の値なので、実際に使う場合は、このPC専用の認証情報に置き換えます。端末によっては、システムプロキシ設定画面が認証に対応していません。その場合は端末の機能と管理できるネットワーク範囲を考慮し、信頼できないネットワークにプロキシポートを公開しないでください。

mixed-port: 7890
allow-lan: true
bind-address: '*'
authentication:
  - "lan-user:your-password"
external-controller: 127.0.0.1:9090
secret: "your-password"

スマートフォンのWi-Fiで設定するHTTPプロキシは、通常、その設定に従うアプリだけに適用されます。すべてのアプリやUDP通信が取り込まれるわけではありません。PCでTUNを有効にしても、PCが自動的にスマートフォンの透過型ゲートウェイになることはありません。端末全体の通信を取り込むには、ゲートウェイ、ルーティング、DNSの設計が必要です。「LAN内接続を許可」と「TUNの共有」を混同しないでください。一般的な家庭のネットワークでは、まずアプリが対応する明示的なプロキシを使うと、適用範囲を制御しやすく、問題も特定しやすくなります。

最小限のテストで接続を確認する

共有の動作確認では、まずPC上でプロキシ経由のアクセスができることを確認します。次に、2台目の端末からPCのアドレスに接続できることを確認してから、プロキシを設定し、PCの接続一覧を確認してください。新しい接続が一切表示されない場合は、アドレス、ポート、認証、ファイアウォールを調べます。接続は表示されるのにアクセスできない場合は、マッチしたルール、最終的なノード、DNSを確認してください。一部のアプリだけ動作する場合は、アプリがシステムプロキシに従うかを確認し、コントローラーの設定を変更しないようにしましょう。公衆Wi-Fiやゲストネットワークでは端末間通信が遮断されることがあり、同じネットワーク名でも相互接続が保証されるわけではありません。

設定が完了したら、一時的に開放したポートとデバッグログを無効にし、コントローラーへのアクセスが想定した範囲に限られていること、サブスクリプションの更新でローカルのセキュリティ設定が上書きされていないことを確認してください。長期運用に備え、プロキシポート、待ち受け範囲、認証情報の保存場所、上書きの設定箇所、復元方法を簡潔に記録しておきます。記録にパスワードそのものを書かないでください。基本的な設定手順を確認する場合は使い方ガイドに戻ってください。インポートの失敗やシステムプロキシ設定の残留など、日常的な問題はヘルプセンターを確認し、高度な設定をすべて重ねて適用し直す必要はありません。