設定ファイルの場所と参照関係を確認する

設定の基本的な関係は、ルールがプロキシグループを選び、プロキシグループがノードを選択し、DNSがドメイン名を解決することです。この関係に沿って項目を分けると、サブスクリプションの設定を行ごとに編集するより、問題の箇所を特定しやすくなります。この記事ではmihomoを扱います。mihomoは、Clash Metaコアの後継プロジェクトとして知られています。旧Clashコアや各種GUIクライアントでは、同じ項目を設定ファイルに統合できるとは限りません。

コアを直接起動する場合は、作業ディレクトリを ~/.config/mihomo にし、その中に config.yaml を置きます。クライアントを使う場合は、最終的にコアへ渡される設定ファイルのパスを確認してください。サブスクリプションの元ファイル、オーバーライドファイル、実行時設定は別々の場合があります。実行時設定を直接編集すると、次回のサブスクリプション更新で上書きされることがあります。

mkdir -p ~/.config/mihomo
mihomo -v
mihomo -t -d ~/.config/mihomo

-v は実行中のコアのバージョンを表示し、-t は指定ディレクトリの設定を検証します。設定ファイルをまだ作成していない場合、最後のコマンドでファイルが見つからないのは正常です。以下の最初の6節にあるYAML例は、順につなげて基本設定として使えます。ただし、例のローカルSOCKSノードは特定の条件が前提です。すぐに使えるリモートプロキシサービスではありません。

1. mixed-port：ローカルのプロキシ接続口を設定

mixed-port: 7890
allow-lan: false
bind-address: "127.0.0.1"
ipv6: false

mixed-port はHTTPプロキシとSOCKS5プロキシの両方の接続を受け付けるため、ブラウザーやコマンドラインツールから 127.0.0.1:7890 を共用できます。これはコントロールパネルのポートでも、ノードサーバーのリモートポートでもありません。ローカルアプリからの接続だけでよければ、allow-lan: false のままにしてください。Webページの問題を調べるためだけに、リッスンアドレスをすべてのネットワークインターフェースに変更しないでください。

項目用途この記事の設定値
mixed-portアプリが接続するHTTP／SOCKSのポート7890
portHTTPプロキシ専用のポート個別には有効にしない
socks-portSOCKSプロキシ専用のポート個別には有効にしない
dns.listenコアのDNSサービスのリッスンアドレス127.0.0.1:1053
external-controller管理API。通常のWebプロキシリクエストは受け付けない基本設定では省略

ここでは初回セットアップ時の変数を減らすため、IPv6を一時的に無効にしています。すべてのネットワークでIPv6を常に無効にすべきという意味ではありません。後で有効にする場合は、DNSのAAAA応答、ノードのIPv6接続性、システムのルーティングをあわせて確認してください。LAN内の機器と共有するには、値を1つ変更するだけでなく、リッスンアドレス、認証、ファイアウォールを別途検討する必要があります。

ss -lntp 'sport = :7890'
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com/

1つ目のコマンドでポートがリッスン状態か確認し、2つ目ではプロキシを明示してデスクトップ環境のシステムプロキシ設定を迂回します。どちらもコアが起動している場合にのみ意味があります。接続拒否が発生したら、まずプロセスとポートを確認してください。すぐにDNSを変更する必要はありません。

2. modeとログ：通信の振り分け方法を設定

mode: rule
log-level: info

mode: rule は、rules のリストに従って接続先を選びます。direct モードは直接接続を優先し、global モードはグローバルポリシーを使用します。ルールを調べる際は、クライアント側で別のモードに切り替わっていないか、まず確認してください。設定ファイルのモードは管理APIから変更されることもあるため、ファイルに rule と書かれていても、実行中の状態が同じとは限りません。

log-level: info は、通常の接続状況や起動時のエラーを確認するのに適しています。特定のルールやDNSの動作を詳しく調べる場合は、一時的に debug に変更し、再現できたら元に戻してください。ログにはアクセス先のドメイン名、ノードのアドレス、接続情報が含まれることがあります。共有する前に機密情報を削除してください。mode、ノード、DNSを同時に変更しないでください。変更する項目を一度に1グループに絞ると、結果と変更内容を対応づけられます。

3. DNS：上流サーバー、リッスンポート、fake-ipを整理

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
    - https://doh.pub/dns-query

3つの項目の役割

  • listen は、ローカルDNSサービスがクエリを受け付けるアドレスを指定します。ここでは特権ポートではない 1053 を使い、セットアップの初期段階でシステムがよく使う 53 を占有しないようにしています。
  • default-nameserver は、DNS上流サーバー自体のドメイン名を解決するために使います。上流サーバーのアドレスが解決できず、後続の問い合わせもできない状態を防ぎます。
  • nameserver は、デフォルトで使うドメイン名解決の上流サーバーです。この例ではDoHのアドレスを2つ指定しています。実際のネットワークから接続できる必要があり、HTTPSのURLを設定しただけで到達可能になるわけではありません。

fake-ip は、対象のドメイン名に仮想アドレスを返し、コアが対応関係からドメイン名を復元して接続を処理する仕組みです。リモートノードの実IPではなく、宛先サイトが 198.18.0.0/16 にあるという意味でもありません。実際のDNS解決結果を必要とするLAN内サービスは、ドメイン名を fake-ip-filter に追加すると、fake-ip応答を使わずに処理できます。

dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 localhost A

この設定例では、1つ目のクエリは通常fake-ipアドレスを返します。フィルター対象については、実際の名前解決結果によって動作が異なります。システムに dig がない場合は、ディストリビューションが提供するDNSツールパッケージをインストールしてください。コアのリッスンポートへ直接問い合わせることで、「上流の名前解決に問題がある」場合と「システムがコアのDNSを使っていない」場合を切り分けられます。

4. proxies：ノードを定義し、接続口を上流に使わない

proxies:
  - name: "ローカルSOCKS"
    type: socks5
    server: 127.0.0.1
    port: 1080
    udp: false

この例では、認証なしのSOCKS5サービスをローカルで起動済みであることを前提にしています。接続先は 127.0.0.1:1080 です。設定項目の参照関係を確認するための例であり、この設定がサービスを起動するわけではありません。この上流がなくても、後でプロキシグループを DIRECT にすれば、ローカルのリッスンとルール読み込みは検証できます。ただし、プロキシノードへの接続性は確認できません。

name は設定内で参照する名前です。後続のプロキシグループでは、同じ名前を一字一句一致させる必要があります。ノードの接続先を指定するのは server と port です。サブスクリプションがある場合は、提供元が指定するノード情報を使い、SOCKS5の例を別のプロトコルに機械的に置き換えないでください。Shadowsocks、VMess、VLESSなどでは、認証や通信方式の項目がそれぞれ異なります。違いは type だけではありません。

5. proxy-groups：ルールから参照する出口名を固定

proxy-groups:
  - name: "出口"
    type: select
    proxies:
      - DIRECT
      - "ローカルSOCKS"

select は手動選択型のグループです。ルールからは「出口」だけを参照するため、ノードを変更してもルールを1つずつ編集する必要はありません。DIRECT は直接接続用の組み込みポリシーなので、proxies に再定義する必要はありません。「ローカルSOCKS」は、前節で定義したノード名と一致させる必要があります。選択状態が保存されていない初回起動時に備え、この例では最初に DIRECT を置き、基本的な接続経路を先に確認できるようにしています。

GUIクライアントでは、プロキシグループの選択状態が保存されることがよくあります。リストの順序を変えても以前の選択が復元される場合があるため、テスト前に現在選択されている項目を確認してください。コアを直接実行し、管理APIを有効にしていない場合は、最初の項目を変更して再起動する方法で確認できます。その後、必要に応じてローカルのコントロールパネルを追加してください。

自動で速度を測る場合にurl-testを追加

url-test は指定したURLへ定期的に接続し、応答時間を比較します。「すべてのサイトにアクセスできる」ことを保証する機能ではありません。たとえば interval: 300 は300秒ごとに確認する設定で、リクエストごとに速度を測るという意味ではありません。ノードが少なく、問題を調べ始めた段階では、まず select で利用可能な接続経路を確認してから自動選択を検討してください。ヘルスチェックの失敗とノード認証の失敗を混同しにくくなります。

6. rules：具体的な条件から最後のフォールバックへ

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - DOMAIN,localhost,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DOMAIN-SUFFIX,github.com,出口
  - MATCH,出口

ルールは上から順に照合され、通常は一致した時点で後続のルールには進みません。DOMAIN は完全一致のドメイン名に、DOMAIN-SUFFIX はドメイン名そのものとサブドメインに一致します。たとえば github.com と api.github.com は、例のサフィックスルールに一致します。ただし、GitHubに関連するすべてのリソースドメインが対象になるわけではありません。

IP-CIDR は宛先のIPv4アドレス範囲で照合します。no-resolve は、このIPルールとの照合だけを目的に、未解決の宛先ドメインを新たに名前解決しない指定です。宛先IPがすでにある場合は、引き続き照合できます。LAN内サービスについては、必要なドメインルールも設定してください。プライベートアドレス範囲だけで、すべてのローカル名を判定することはできません。

MATCH は最後に使うフォールバックなので、末尾に配置してください。前に置くと、後続のルールが照合されなくなります。この例ではGeoIPデータベースに依存しないよう、プライベートアドレス範囲を明示しています。ただし、特殊用途のアドレスをすべて網羅したリストではありません。前述の基本設定ではIPv6を無効にしています。有効にする場合は、IPv6向けのアドレスルールも追加してください。

ここまでの6節をつなげると、基本設定が完成します。目的は項目間の関係を示すことであり、地域別の完全な振り分け設定を提供することではありません。基本設定が動作した後、ルールセット、DNSの振り分け、プロセスルールを1つずつ追加してください。項目の詳細は設定リファレンスで確認できます。

7. proxy-providers：ノード数が増えたらファイルを分割

ノードが増えたら、ノード一覧をProviderファイルに移せます。以下は第4節と第5節を置き換えるための任意の構成です。同じ名前のプロキシグループを前述の設定に重ねて貼り付けないでください。メイン設定はファイルからノードを読み込み、プロキシグループはノード一覧にProvider名を書くのではなく、use でProvider名を参照します。

proxy-providers:
  local-pool:
    type: file
    path: ./providers/local.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: "出口"
    type: select
    proxies:
      - DIRECT
    use:
      - local-pool

~/.config/mihomo/providers/local.yaml に以下の内容を記述し、あらかじめ providers ディレクトリを作成してください。相対パスは実際の作業ディレクトリに合わせて確認します。この記事の起動コマンドでは、-d でディレクトリを明示しています。

proxies:
  - name: "ローカルSOCKS"
    type: socks5
    server: 127.0.0.1
    port: 1080
    udp: false

Providerファイルは、ノード集合の形式にする必要があります。dns や rules などを含むクライアント設定全体のファイル名を変えるだけでは使えません。type: http を使う場合は、実際のサブスクリプションURLを設定し、Provider側の interval で取得間隔も指定してください。サブスクリプションURLにはアクセス認証情報が含まれることが多いため、公開ログやスクリーンショットに載せないでください。

2種類の更新間隔を区別してください。Providerの interval はリモートの内容を更新する間隔で、health-check.interval はノードの疎通を確認する間隔です。ここではローカルファイルをProviderとして使うため、ヘルスチェックが600秒ごとに実行されても、リモートからノードが取得されることはありません。確認先のURLに接続できない場合、グループ内のノードがすべてチェック失敗になることもあります。実際のリクエスト結果とあわせて判断してください。

8. TUNは追加の通信制御レイヤー。必須設定ではない

明示的なプロキシ接続が動作してからTUNを有効にしてください。TUNは仮想ネットワークデバイスとルーティングを使って通信を取り込みます。通常の mixed-port だけでは、すべてのアプリが自動的にプロキシを使うわけではありません。以下の例は、必要な権限とルーティング環境を整えたLinuxでのテスト向けです。最初の6節にある基本設定には含まれません。

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

auto-route は、必要なルートの設定をコアに要求します。auto-detect-interface は、外部接続に使うインターフェースを検出します。TUNデバイスの作成やルートの変更には十分なシステム権限が必要です。通常はクライアントのサービスモードや、管理者が設定したサービスを通じて実行します。一般ユーザーのプロセスでは権限が足りないことがあります。dns-hijack は、その処理経路に入った従来の53番ポートへのDNSリクエストを取り込みます。ブラウザー自身が使うDoH通信を直接復号する機能ではありません。

9. 「構文、リッスン、DNS、出口」の順に検証

  1. 現在のファイルをバックアップします。変更前に、動作が確認できている設定を保存してください。サブスクリプションのオーバーライドや手書きのルールは特に重要です。バックアップファイルを、実際に使用中の設定と取り違えないようにしてください。
  2. 構文と参照先を確認します。 mihomo -t -d ~/.config/mihomo を実行してください。ノード名の不一致、プロキシグループの参照ミス、YAMLのインデントエラーは、再起動する前に解消します。
  3. テスト用のインスタンスは1つだけにします。GUIクライアントがすでに 7890 を使用している場合は、コアを停止するか、テスト設定で別のポートを選んでください。ポートの競合はノードの障害ではありません。
  4. フォアグラウンドで起動してログを確認します。以下の起動コマンドを実行し、別のターミナルからポート、DNS、プロキシ接続をテストしてください。フォアグラウンドでのテストを終了するには、Ctrl+Cを押します。
mihomo -d ~/.config/mihomo

# 別のターミナルで実行
ss -lntp 'sport = :7890'
dig @127.0.0.1 -p 1053 example.com A
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com/
curl --proxy socks5h://127.0.0.1:7890 --connect-timeout 10 -I https://example.com/

socks5h の h は、宛先のドメイン名をプロキシ側で解決することを示します。クライアント側でドメイン名を解決する方式とは異なります。これにより、問題がアプリ独自のDNS処理で起きているかどうかを判断しやすくなります。HTTPリクエストがエラーステータスを返した場合は、接続先サイトの応答とプロキシ接続の失敗を区別してください。200 が返ったかどうかだけで、通信経路を判断することはできません。

設定テストに合格しても、設定ファイルを解析・読み込みできたことしか確認できません。サブスクリプションURLへの接続、ノード認証、DNS上流への到達性、TUNのルーティングが正しいことまでは保証されません。基本的な検証が済んだら、systemdサービスまたはクライアントによる管理に戻し、使用するバイナリ、作業ディレクトリ、設定ファイルがテスト時と同じか確認してください。導入手順はクイックスタートを参照してください。接続に問題がある場合は、まずトラブルシューティングを確認します。

最終的には、アプリが mixed-port に接続し、ルールが「出口」に一致し、プロキシグループが有効なノードまたは DIRECT を選び、DNSが必要な名前解決を行う、という依存関係を保ちます。サブスクリプションの更新、ルールセット、TUNを追加する際は、一度に1つのレイヤーだけ拡張し、同じ検証コマンドを繰り返してください。