Clashの設定ファイルは通常YAMLで記述します。リスニングポート、動作モード、DNS、プロキシノード、プロキシグループ、ルールを1つのドキュメントにまとめて管理できます。キーの並び順は通常カーネルの読み込みに影響しませんが、「基本設定 → DNS → ノード → プロキシグループ → ルール」の順に書くと、参照関係やインデントミスを見つけやすくなります。
本記事では、Clash for Windows 0.20.39で一般的な設定構造と、mihomo v1.19系の設定仕様を基準に解説します。対応プロトコル、TUNパラメータ、DNSの拡張項目はカーネルによって完全には一致しません。サブスクリプションで生成された設定を変更する前に、次回更新で手作業の内容が上書きされないよう、ローカルにコピーを保存しておくことをおすすめします。
YAMLの構文とトップレベル構造
インデント、リスト、キーと値
YAMLではスペースで階層を表し、インデントにTabは使えません。一般的には1階層あたりスペース2個で記述します。コロンの後にはスペースを1つ入れ、リスト項目はハイフンで始めます。ノード、プロキシグループ、ルールはそれぞれ異なるトップレベルキーの下にあります。階層が1段ずれるだけで、ファイル全体を読み込めなくなることがあります。
port: 7890
mode: rule
proxies:
- name: "サンプルノード"
type: ss
server: 203.0.113.10
port: 443
proxy-groups:
- name: "ノード選択"
type: select
proxies:
- "サンプルノード"
- DIRECT
rules:
- MATCH,ノード選択
port: 7890 はキーと値の組です。proxies: の後にはリストが続きます。- name: で始まる各項目はノードオブジェクトです。コロン、シャープ、アスタリスク、または真偽値として解釈されやすい名前は、引用符で囲むのがおすすめです。たとえばノード名を "HK: 01" と書けば、コロンがマッピングの区切りとして扱われるのを防げます。
よくある解析エラー
- インデントの不一致:よくあるメッセージには
did not find expected keyやmapping values are not allowedがあります。 - キーの重複:ファイル内にトップレベルの
dns:が2つあると、パーサーによっては読み込みを拒否し、別のパーサーでは後の定義だけを残すことがあります。 - リストのハイフン抜け:
rules、proxies、プロキシグループ内のproxiesはすべてリストです。 - 名前が完全一致していない:
香港選択と香港選択は別の文字列です。末尾のスペースだけでも、プロキシグループの参照に失敗します。 - コメントによる内容の切り捨て:シャープは通常、コメントの開始を示します。パスワードや名前に
#を含める場合は引用符を使用してください。
ポート、LAN、動作モードの設定
ファイルの先頭には通常、受信待ち受けと基本的な動作パラメータを記述します。次の例ではHTTP、SOCKS5、混合プロキシにそれぞれポートを設定しています。実際には3種類のポートを同時に有効にする必要はなく、デスクトップクライアントでは mixed-port が最もよく使われます。
port: 7890
socks-port: 7891
mixed-port: 7892
allow-lan: false
bind-address: "*"
mode: rule
log-level: info
ipv6: false
external-controller: 127.0.0.1:9090
secret: "change-this-controller-secret"
3種類のプロキシポートの違い
port:HTTPプロキシ用ポートです。アプリ側がHTTPプロキシ設定に対応している必要があります。socks-port:SOCKS4、SOCKS4a、SOCKS5の対応範囲はカーネルによって異なります。一般的なクライアントではSOCKS5として使用します。mixed-port:同じポートでHTTPとSOCKSのリクエストを受け付けます。よく使われる値は7890または7892です。
同じIPアドレスとポートを2つのプログラムが同時に待ち受けることはできません。ログに address already in use や bind: Only one usage of each socket address が表示された場合は、古いClashプロセス、別のプロキシツール、ローカル開発サービスがポートを使用していないか確認してください。Windowsではターミナルで netstat -ano | findstr :7890 を実行すると、該当するPIDを確認できます。
allow-lan と bind-address
allow-lan: false は、LAN内のデバイスにプロキシの入口を公開しない設定です。true に変更すると、スマートフォンや別のPCで、現在のPCのLANアドレス(例:192.168.1.20:7890)をプロキシサーバーとして指定できます。この場合は、Windowsファイアウォールで該当ポートの通信も許可してください。
bind-address は待ち受けアドレスを指定します。本機だけで使う場合は 127.0.0.1 にバインドすると明確です。LANからアクセスする場合は、カーネルの対応状況に応じて * または特定のネットワークアダプターのアドレスを使用できます。allow-lan だけを変更しても、他のデバイスから必ず接続できるとは限りません。ファイアウォール、ゲストネットワークの分離、ルーターのAP隔離もアクセスを妨げます。
mode、log-level、制御ポート
mode: rule:rulesを上から順に照合します。日常利用の中心となるモードです。mode: global:通信をすべてグローバルプロキシグループに渡します。ノードの接続性を短時間テストする場合に適しています。mode: direct:プロキシノードを経由せず、通信を直接接続します。プロキシが障害の原因かどうかを切り分ける際に便利です。log-level:一般的な値はsilent、error、warning、info、debugです。トラブルシューティングでは一時的にdebugを使い、完了後はログが過剰にならないようinfoに戻してください。external-controller:制御APIを提供します。ローカルでよく使われるアドレスは127.0.0.1:9090です。secretを設定した場合、コントロールパネルの接続時に同じキーが必要になります。
DNSセクション:待ち受け、リゾルバー、拡張モード
DNSセクションでは、ドメイン名をどのように解決するかを指定します。ルールの照合だけでなく、TUNモードでのドメイン通信の取り込みにも影響します。基本的な構成例は次のとおりです。
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.ptlogin2.qq.com"
- "+.msftconnecttest.com"
default-nameserver:
- 223.5.5.5
- 1.1.1.1
nameserver:
- https://dns.alidns.com/dns-query
- tls://1.1.1.1:853
fallback:
- https://dns.google/dns-query
fallback-filter:
geoip: true
geoip-code: CN
enable、listen、default-nameserver
enable は内蔵DNSモジュールを制御します。listen はDNSサービスの待ち受けアドレスです。例ではローカルのUDP/TCPポート 1053 を使用しています。別のローカルDNSプログラムがこのポートを使っている場合、ログに待ち受けの失敗が表示されます。
default-nameserver は主に、DoHやDoTなど上流サーバー自身のドメイン名を解決するために使われます。ブートストラップDNSと呼ばれることもあります。循環依存を避けるため、ここには別の名前解決が必要なドメイン名ではなく、直接アクセスできるIPアドレスを指定するのが一般的です。
nameserver、fallback、ポリシー別名前解決
nameserver は主要なリゾルバーで、通常のDNSアドレス、DoH、DoTのいずれも指定できます。fallback と fallback-filter は、従来のClash設定でよく使われる予備の名前解決構成です。mihomoではさらに nameserver-policy、proxy-server-nameserver、direct-nameserver などの項目にも対応しており、ドメインルールやプロキシノードの名前解決用途に応じて上流サーバーを使い分けられます。
「DNSを複数書いたから、すべてのリクエストが同時に全回答を使う」と考えないでください。カーネルは項目の意味、フィルター条件、応答結果に基づいて解決経路を選択します。ドメインは解決できるのにサイトが開けない場合は、DNSログ、ルールのヒット状況、ノード接続を同時に確認してください。ブラウザーのエラーだけで判断することはできません。
fake-ip と redir-host
fake-ip:まずドメインに予約アドレス範囲のマッピングアドレスを返し、カーネルが接続先を元のドメインに戻します。透過プロキシ環境でドメイン情報を保持しやすく、一般的なアドレスプールは198.18.0.1/16です。redir-host:先に実際のIPアドレスを取得し、名前解決の結果に基づいて接続を処理します。一部のLAN機器、古いソフトウェア、特殊な認証環境では、こちらのほうが互換性を確保しやすい場合があります。fake-ip-filter:LAN内のドメイン、接続性チェック用ドメイン、Fake IPに適さないドメインには実際の名前解決結果を返します。フィルター範囲を広げすぎると、Fake IPによるドメイン識別の効果が弱まります。
proxies:個別プロキシノードの項目
proxies には手動で定義したノードを保存します。サブスクリプションでは通常、このセクションが自動生成されます。プロトコルによって項目は異なりますが、各ノードには少なくとも一意の名前、プロトコル種別、サーバーアドレス、ポートが必要です。
proxies:
- name: "SS-HK-01"
type: ss
server: hk.example.net
port: 443
cipher: aes-128-gcm
password: "example-password"
udp: true
- name: "VMess-JP-01"
type: vmess
server: jp.example.net
port: 443
uuid: 11111111-2222-3333-4444-555555555555
alterId: 0
cipher: auto
tls: true
servername: jp.example.net
network: ws
ws-opts:
path: /gateway
headers:
Host: jp.example.net
共通項目とプロトコル固有の項目
name:プロキシグループから参照するノード名です。完全一致が必要で、同じ名前があると選択結果が不明確になるため、一意にしてください。type:プロトコル種別です。例としてss、vmess、trojanがあります。mihomoはさらに多くのプロトコルに対応していますが、利用できるかどうかは現在のカーネルに依存します。serverとport:サーバーのドメイン名またはIPアドレスとポートです。ポートは通常1~65535の整数で、スペースを含む文字列として記述すると検証に失敗することがあります。udp:ノードでUDP転送を有効にするかどうかを指定します。UDP非対応のプロトコルやサーバーに、この設定だけで機能が追加されるわけではありません。tls、servername、sni:TLSとサーバー名を制御します。項目名はプロトコルやカーネルのバージョンによって異なるため、すべてのノード間で機械的にコピーしないでください。skip-cert-verify:証明書検証をスキップすると、接続先の身元を確認する能力が低下します。証明書エラーが出た場合は、まずシステム時刻、SNI、証明書のドメイン名、サーバー設定を確認してください。
ノードがリストに表示されることは、YAMLが解析されたことを示すだけで、接続パラメータが正しいとは限りません。認証情報の誤りはハンドシェイク失敗として現れることが多く、サーバーアドレスを解決できない場合はDNSエラーになります。WebSocketのパスやHostが一致しない場合は、接続確立直後に切断されることがあります。トラブルシューティングでは、クライアントの「ログ」を開いてレベルを一時的に debug に変更し、1つのノードを対象に遅延テストを実行してください。
proxy-providers と proxy-groups
ノードプロバイダー proxy-providers
proxy-providers では、ローカルファイルやリモートURLからノード群を読み込めます。すべてのノードを proxies に直接記述するよりも、ノードの取得元とプロキシグループの構成を分けて管理するのに適しています。
proxy-providers:
provider-main:
type: http
url: "https://example.com/subscription"
path: ./providers/provider-main.yaml
interval: 3600
health-check:
enable: true
interval: 600
url: https://www.gstatic.com/generate_204
interval: 3600 は、3600秒ごとに更新を確認する設定です。ヘルスチェックの interval: 600 は、10分ごとにテストを実行することを示します。プロバイダーのダウンロードに失敗した場合は、サブスクリプションURLへのアクセス、システム時刻、プロキシ起動時の循環依存、保存先への書き込み権限を確認してください。
プロキシグループの種類と参照
proxy-groups:
- name: "ノード選択"
type: select
proxies:
- "自動選択"
- "フェイルオーバー"
- DIRECT
use:
- provider-main
- name: "自動選択"
type: url-test
use:
- provider-main
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 80
- name: "フェイルオーバー"
type: fallback
use:
- provider-main
url: https://www.gstatic.com/generate_204
interval: 300
select:ユーザーがノード、内蔵ポリシー、別のプロキシグループを手動で選択します。url-test:候補ノードを定期的にテストし、利用可能な中からテスト結果の低いものを選びます。遅延テストの値はテスト先へのリクエスト時間であり、すべてのサイトでの実際のダウンロード速度を示すものではありません。fallback:候補の順番に従って利用可能なノードを使用し、現在のノードが使えなくなると次のノードへ切り替えます。load-balance:カーネルが対応する方式に従って複数のノードへ接続を分散します。セッションの一貫性要件を把握している環境に適しています。proxies:ノード名またはプロキシグループ名を直接列挙します。use:1つ以上のproxy-providerを参照します。
tolerance: 80 は、遅延差が80ミリ秒以内なら自動選択グループが頻繁に切り替わらないようにする設定です。値が小さすぎると、軽微なネットワーク変動でノードが何度も切り替わります。大きすぎると、明らかに遅くなったノードを使い続けることがあります。家庭のブロードバンドでは、まず50~100ミリ秒から調整するとよいでしょう。
rules と rule-providers:分流ルールの照合順
rules は、接続をどのプロキシグループに渡すかを決めます。ルールは上から順に照合され、最初に一致した時点で処理が止まります。そのため、具体性の高いルールを前に置き、最後にデフォルトルールを配置するのが一般的です。
rules:
- DOMAIN,api.example.com,ノード選択
- DOMAIN-SUFFIX,example.net,ノード選択
- DOMAIN-KEYWORD,stream,自動選択
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
- GEOIP,CN,DIRECT
- MATCH,ノード選択
よく使われるルール種別
DOMAIN:完全なドメイン名だけに一致します。例:api.example.com。DOMAIN-SUFFIX:指定したドメインとそのサブドメインに一致します。例:example.net。DOMAIN-KEYWORD:ドメイン名に含まれるキーワードで照合します。範囲が広いため、短すぎるキーワードは意図しないサイトまで対象にすることがあります。IP-CIDR:IPv4のネットワーク範囲に一致します。IPv6には通常IP-CIDR6を使用します。GEOIP:接続先IPの地理データベース結果で照合します。データベースのバージョンによって結果が変わるため、ドメインの所属地域と同一視できません。MATCH:最後のフォールバックです。従来の設定ではFINALもよく使われますが、実際の対応状況は現在のカーネルを確認してください。
no-resolve は、一部のIPルールで照合のために追加の名前解決が発生するのを防ぎます。すべてのルールに必要な汎用サフィックスではありません。MATCH を1行目に置くと、後続のルールは一度も照合されません。存在しないプロキシグループをルールから参照すると、読み込み時に直接エラーになる場合や、接続処理中にポリシーが見つからないと表示される場合があります。
ルールプロバイダー rule-providers
rule-providers:
private-network:
type: http
behavior: ipcidr
format: yaml
url: "https://example.com/rules/private-network.yaml"
path: ./ruleset/private-network.yaml
interval: 86400
rules:
- RULE-SET,private-network,DIRECT
- MATCH,ノード選択
behavior はルールセットの内容に合わせる必要があります。一般的な値には domain、ipcidr、classical があります。ドメインルールセットを ipcidr と宣言すると、内容を正しく解析できません。mihomoのルールセットでは format も関係します。リモートファイルがYAML、テキスト、バイナリ形式の場合は、対応する値を指定してください。
TUNセクションと透過プロキシの設定
TUNモードは仮想ネットワークインターフェースを作成し、個別のプロキシ設定を持たないアプリの通信を取り込みます。システムプロキシとは別の入口です。mihomoでよく使われる設定例は次のとおりです。
tun:
enable: true
stack: mixed
dns-hijack:
- any:53
- tcp://any:53
auto-route: true
auto-detect-interface: true
strict-route: false
stack:一般的な値にはsystem、gvisor、mixedがあります。対応範囲はカーネルのバージョンとプラットフォームによって異なります。dns-hijack:指定ポートのDNSリクエストをカーネルに渡します。例ではUDPとTCPの53番ポートへのリクエストを取り込みます。auto-route:必要なルートを自動的に追加します。Windowsで有効化に失敗する場合は、クライアントの権限、仮想ネットワークアダプター、他のVPNソフトが設定したルートを確認してください。auto-detect-interface:デフォルトの出口ネットワークアダプターを自動検出します。Wi-Fiと有線LANを切り替えて使うデバイスに適しています。strict-route:より厳格なルーティング制約を適用します。通信漏れの抑制に役立つ一方、LAN、仮想マシン、特定の企業ネットワークに影響することがあります。
TUNを有効にした後に「ブラウザーは開けるのにゲームがネットワークに接続できない」「LAN内のデバイスにアクセスできない」といった問題が起きた場合は、実行権限、ルーティングテーブル、DNSの取り込み、LANセグメント向けのダイレクトルール、他のVPNを順に確認してください。デフォルトルートを作成するネットワークツールを複数同時に有効にしないでください。Windowsでは route print を実行して、デフォルトルートとインターフェースの優先順位も確認できます。
読みやすい最小構成とトラブルシューティング手順
次の構成では実際の認証情報を省略していますが、入口からルールまでの参照関係は完全に残しています。設定を確認する際は、最後のプロキシグループから逆方向に追跡できます。ルールは「ノード選択」を参照し、「ノード選択」は「サンプルノード」を参照し、「サンプルノード」にはサーバーパラメータが含まれています。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false
dns:
enable: true
listen: 127.0.0.1:1053
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
default-nameserver:
- 223.5.5.5
nameserver:
- https://dns.alidns.com/dns-query
proxies:
- name: "サンプルノード"
type: ss
server: 203.0.113.10
port: 443
cipher: aes-128-gcm
password: "replace-with-valid-password"
udp: true
proxy-groups:
- name: "ノード選択"
type: select
proxies:
- "サンプルノード"
- DIRECT
rules:
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- GEOIP,CN,DIRECT
- MATCH,ノード選択
エラーの種類ごとに段階的に確認
- ファイルを読み込めない:まずTab、インデント、コロン、引用符、重複キーを確認します。この段階ではノードのテストを先に行わないでください。カーネルがまだ設定を正常に読み込めていないためです。
- 設定は読み込めるがプロキシグループが空:
proxiesにノードがあるか、useのプロバイダー名が正しいか、プロバイダーファイルのダウンロードに成功しているかを確認してください。 - ノードテストに失敗する:server、port、認証項目、TLS名、通信パラメータを確認し、その後でサーバーのドメイン名を解決できるか確認してください。
- 一部のサイトだけ開けない:接続ログでルールのヒット状況、対象ドメイン、プロキシグループ、実際に使用されたノードを確認し、ルールの順番によって通信が先にDIRECTやREJECTへ送られていないか確認してください。
- システムプロキシは有効なのに他のプログラムがプロキシを通らない:そのプログラムがシステムプロキシに従うか確認してください。従わない場合にTUNを検討し、入口の問題を広範なルールの追加で隠さないようにします。
- サブスクリプション更新後に変更が消える:ローカルDNS、TUN、ルールの変更を、クライアントが対応するオーバーライドまたは設定マージへ移行してください。
項目の互換性とメンテナンスのヒント
Clash for Windows 0.20.39で使用されるClashカーネルの設定と、継続的に更新されるmihomoの設定は完全に同じではありません。新しいサブスクリプションには、古いカーネルが認識できないプロトコル、ルールセット形式、DNS項目が含まれることがあります。field not found や unsupported proxy type などのエラーが出た場合は、画面上の名称だけで判断せず、クライアントが実際に使用しているカーネルとバージョンを確認してください。
日常のメンテナンスでは、設定を3種類に分けると管理しやすくなります。サブスクリプションはノード、ルールプロバイダーは更新可能なルールセット、ローカルオーバーライドはポート・DNS・TUNを担当させます。手作業でのマージを減らし、問題の範囲も明確にできます。変更する際は、まずDNSだけを変更して再読み込みし、名前解決が正常になったことを確認してからTUNを有効にするなど、テーマごとに1つずつ調整してください。
設定ファイルの基本的な関係は複雑ではありません。受信ポートが通信を受け取り、DNSがドメイン情報を提供し、ルールがプロキシグループを決め、プロキシグループがノードを選び、ノードがリモート接続を確立します。この流れに沿って確認するほうが、ノードを何度も切り替えたり、YAML全体を一度に置き換えたりするより、問題のある項目を見つけやすくなります。