CLASH / CONFIG DICTIONARY
Clashの用語と設定項目
mihomoコアからDNSの取り込みまで、設定の階層ごとに用語を確認できます。まず用語を整理してから設定項目を変更し、プロトコルの問題とインデントの問題を混同しないようにしましょう。
01 / CORE & CLIENT
コアとクライアント
クライアントは管理を担い、コアは接続を処理します。サブスクリプションとノードは入力データです。それぞれの層を分けて確認しましょう。
- mihomoコア core / Clash Metaの技術
- mihomoはプロキシ接続、ルール照合、DNSリクエストを処理するネットワークコアで、Clash Metaの技術を引き継いでいます。GUIクライアントは通常、バックグラウンドプロセスとしてmihomoを利用するため、クライアントとコアのバージョンは別々です。設定項目が未対応、またはプロトコルを読み込めない場合は、アプリ名だけでなく実際に動作しているコアのバージョンを確認してください。
- GUIクライアント GUI / 設定管理とシステム連携
- GUIクライアントでは、サブスクリプション管理、プロキシグループの選択、ログ確認、システムプロキシの操作を画面から行えます。各機能が使えるかどうかは、コアの対応状況に加えて、アプリが操作項目を提供しているか、OSから必要な権限を得ているかにも左右されます。クライアントを移行するときは設定内容とアプリ側の設定を分けて確認してください。後者は通常、サブスクリプションには含まれません。
- プロキシノード proxy / リモート接続パラメーター
- ノードはプロキシサーバーへの接続に必要なパラメーター一式です。一般にサーバーアドレス、ポート、プロトコル、認証情報、トランスポート設定が含まれます。リスト上のノード名は表示用のラベルです。特定の地域名が付いていても、実際の出口がその地域にあるとは限りません。トラブル時は、ドメインの名前解決、ポートへの接続、認証のどこで失敗しているかを切り分けてください。モードを何度も切り替えても、これらの問題は解決しません。
- サブスクリプション subscription / 設定の配布
- サブスクリプションはURLを通じてノードや設定一式を配布・更新する仕組みです。形式によってノードのみの場合もあれば、プロキシグループやルールが含まれる場合もあります。更新に成功しても、取得と解析が完了したことを示すだけで、すべてのノードが接続可能とは限りません。URLのパラメーターにはアカウント情報が含まれる場合があります。ログやスクリーンショットを共有したり、サブスクリプション変換を行ったりする前に、URLが第三者に渡らないか確認してください。
- 遅延テスト latency / 指定先へのリクエスト時間
- クライアントでは、ノード経由でテストリクエストを送り、応答時間を表示するのが一般的です。結果はテスト先、タイムアウト設定、接続の再利用などに左右されます。サーバーへの単純なpingでも、ダウンロード速度の測定でもありません。ノードのテストがタイムアウトしても一部のサイトを利用できる場合は、テスト先に接続できるか確認してください。ノードを比較する際は、テスト条件をそろえましょう。
02 / PROXY PROTOCOLS
プロキシプロトコル
プロトコルは接続の確立方法を定義します。トランスポート方式とTLSは別の設定層です。名称が似ていても、設定をそのまま置き換えられるとは限りません。
- Shadowsocks SS / 暗号化プロキシプロトコル
- Shadowsocksは一般的な暗号化プロキシプロトコルです。接続にはサーバーアドレス、ポート、暗号化方式、パスワードを正しく設定する必要があります。設定によっては特定のプロトコルバージョンやプラグインへの対応も必要なため、アドレスとパスワードだけをコピーしても接続できないことがあります。インポート時に暗号化方式が未対応と表示された場合は、コアの対応状況と元の設定を確認してください。方式名を適当に変更しても、サーバー側の設定は変わりません。
- VMess ユーザーID / トランスポート設定
- VMessはユーザーIDなどを使ってプロキシ接続を確立し、さまざまな下位トランスポート方式と組み合わせられます。プロトコル認証、WebSocketなどのトランスポート設定、TLS証明書の検証はそれぞれ別の処理です。どれか一つでも一致しないと接続に失敗する場合があります。元の設定を参照し、ユーザーID、トランスポートの種類、パス、サーバー名を確認してください。システム時刻が大きくずれている場合は、先に修正しましょう。
- VLESS 軽量プロトコル / セキュリティ機能との組み合わせ
- VLESSは軽量なプロキシプロトコルで、通常はTLSやREALITYなどのセキュリティ機能と組み合わせて使います。プロトコル名だけでは通信全体が暗号化されるとは限りません。クライアントが使用するトランスポート、セキュリティ機能、各パラメーターの組み合わせに対応している必要があります。インポートに失敗した場合は、コアが出力した具体的な項目を確認してください。画面にVLESSの選択肢があっても、関連するすべての設定に対応しているとは限りません。
- Trojan TLS / パスワード認証
- Trojanは通常、TLSを使ってプロキシ通信を行います。接続には正しいパスワードと証明書検証の両方が必要です。サーバー名、証明書チェーン、システム時刻に問題があると、ポートに接続できてもハンドシェイクに失敗することがあります。証明書エラーが出た場合は、まずサーバー名と証明書の状態を確認してください。検証を無効にするとサーバーの身元確認が弱まるため、通常の対処法として使うべきではありません。
- Hysteria 2 QUIC / UDPのネットワーク条件
- Hysteria 2はQUICベースのプロキシプロトコルで、ネットワーク経路上でUDP通信が許可されている必要があります。通常のHTTPSに接続できても、この種の通信が許可されているとは限りません。同じサーバーのTCPポートに接続できても、UDPの疎通確認にはなりません。この種類のノードだけ接続できない場合は、まず別のネットワークで結果を比較し、その後に認証、証明書、サーバー設定を確認してください。
03 / RULES & ROUTING
ルールとトラフィック分岐
まず通信がコアに取り込まれていることを確認し、次にどのルールに一致したかを調べます。取り込まれていない通信は、ルールを追加しても自動的に処理されません。
- ルールによるトラフィック分岐 mode: rule / 上から順に照合
- ルールによるトラフィック分岐では、通信がコアに入った後、ドメインやIPなどの条件に基づいてDIRECT、拒否、またはプロキシグループへの振り分けを決めます。ruleモードでは通常、リストの上から順に照合し、最初に一致したルールを適用します。そのため、特定のドメインを指定するルールは条件の広いルールより前に配置してください。変更後は接続の詳細で、一致したルールと最終的なポリシーを確認します。設定の保存だけでは、意図どおりに分岐したことは確認できません。
- GeoIP GEOIP / IP地理データベース
- GeoIPは、対象IPの地理データベース上の情報に基づいて照合します。たとえば
GEOIP,CN,DIRECTのように記述します。ウェブサイトの言語やドメインの末尾をもとに判定するものではなく、CDNのIP変更やデータベース更新によって結果が変わる場合があります。一部のIPルールではドメインの名前解決が発生するため、トラブル時は名前解決の結果、データベースの状態、no-resolveパラメーターの使用状況も確認してください。
- GeoSite GEOSITE / カテゴリ別ドメイン一覧
- GeoSiteは、ドメインをサービスやテーマ別にまとめたリストです。ルールでは個々のドメインを列挙せず、リスト名を指定できます。利用可能なカテゴリや収録内容は、データファイルとそのバージョンによって異なります。ルールの読み込みエラーが発生した場合は、指定したカテゴリが存在するか確認してください。ウェブサイトの一部のリソースだけが意図しないポリシーに振り分けられる場合は、関連するサブドメインがリストに含まれているか調べましょう。
- プロキシグループ proxy-groups / ノード選択の仕組み
- プロキシグループは複数のノードや他のポリシーをまとめ、手動選択、テスト結果に基づく選択、フェイルオーバーなどの動作を提供します。ルールで指定するグループ名は、設定内の定義と完全に一致させてください。名前を変更した場合は参照先も更新が必要です。自動選択はテスト先とチェック間隔に依存し、各サイトの実際の利用状況を常に把握するものではありません。「自動」という表示だけで判断せず、グループの種類を確認しましょう。
- MATCH フォールバックルール / 最後に配置
MATCHは、それ以前のルールに一致しなかった通信を処理するため、通常はルールリストの末尾に置きます。たとえばMATCH,PROXYのように記述します。ここで使うPROXYは、実際に存在するプロキシグループ名でなければなりません。どこでも使える予約済みのグループ名ではありません。フォールバックルールが処理するのは、すでにコアに取り込まれた通信です。システムプロキシやTUNによる取り込みの代わりにはなりません。
04 / DNS & NETWORK STACK
DNSとネットワークスタック
通信の取り込みとドメインの名前解決は、互いに関係する別々の経路です。一方のスイッチを有効にしても、もう一方の設定が完了したとは限りません。
- TUNモード 仮想ネットワークインターフェース / ルートによる取り込み
- TUNモードは仮想ネットワークインターフェースとルートを使い、条件に合う通信をコアに転送します。システムプロキシを参照しない一部のアプリにも適用できます。通信を取り込める範囲は、OSの権限、ルート、除外設定、他のVPNアプリの影響を受けます。すべての通信が必ずプロキシを通るわけではありません。有効化に失敗した場合はサービスの権限と起動ログを確認し、有効化後はスイッチの状態だけでなくルートとDNSも検証してください。
- Fake-IP enhanced-mode: fake-ip / ドメインのマッピング
- Fake-IPモードはアプリにマッピング用IPアドレスを返し、コア内に対応関係を保存します。これにより、後続の接続で元のドメインを特定し、ルールと照合できます。アプリにマッピング用のIPアドレスが表示されても、通常は仕様どおりであり、DNSリゾルバーの故障を意味しません。実IPを必要とするアプリでは
fake-ip-filterに除外設定を追加する場合があります。問題のあるドメインだけを指定し、すべてのドメインを除外するのは避けてください。
- DNS漏えい 名前解決経路 / 想定外のリクエスト
- DNS漏えいとは、DNSリクエストが想定した経路を迂回する状態です。たとえば指定した名前解決経路を通るはずのリクエストが、別のリゾルバーへ直接送信されます。検査サイトに特定地域のリゾルバーが表示されても、それだけで漏えいとは判断できません。DIRECTルールや上流DNSの設計も確認してください。トラブル時はシステムDNS、ブラウザーのセキュアDNS、他のVPN、暗号化DNSの設定を確認し、変更後は同じ条件で再テストしましょう。
- dns-hijack tun.dns-hijack / DNSの取り込み設定
dns-hijackはTUN設定の項目で、照合したDNS通信をコアの内蔵リゾルバーに渡します。従来のDNSポートを取り込んでも、ブラウザーが送信するすべての暗号化DNSリクエストを自動的に検出して遮断できるわけではありません。ルールを設定してもDNSが迂回する場合は、リクエストがTUNを通っているか、アプリがDoHやDoTを別途使っているかを確認してください。
- nameserverとfallback DNS上流 / 結果の選択条件
nameserverは内蔵DNSが使う上流リゾルバーを指定し、fallbackはフィルター条件と組み合わせて名前解決結果の選択に使われます。「メインのリゾルバーがタイムアウトしたときだけ使う予備アドレス」と単純に捉えることはできません。fallback-filterなどの設定も確認してください。ドメインポリシーやルール連動のオプションを有効にしている場合は、それらも合わせて確認し、複雑な経路を単一の上流DNSの障害と誤認しないようにしましょう。
続けて確認するには、DNS漏えいの検査とFake-IPの修正方法、またはmihomoのDNS設定項目を詳しく解説をご覧ください。
05 / YAML & CONFIG FIELDS
設定ファイルの項目
項目の値、記述する階層、実際に適用されるファイルを合わせて確認してください。クライアントのフォーム名がYAMLの項目名と同じとは限りません。
- YAML 設定形式 / インデントで階層を表現
- YAMLはClash系の設定でよく使われるデータ形式です。インデントで親子関係を、ハイフンでリスト項目を表します。タブではなくスペースを使い、同じ階層のインデントを統一してください。特殊文字を含む文字列は、構文に沿って引用符で囲む必要があります。解析に成功しても形式が正しいことを示すだけで、現在のコアがすべての項目に対応しているとは限りません。読み込みログと最終的な設定内容も確認してください。
- mixed-port HTTP + SOCKS / プロキシ待ち受けポート
mixed-portは同じポートでHTTPとSOCKSのプロキシリクエストを受け付けます。設定例では7890がよく使われますが、実際の値は動作中の設定に従ってください。アプリに入力するプロキシアドレスとポートは、コアが実際に待ち受けているアドレスとポートに合わせる必要があります。ポートが使用中というログが出た場合は、競合するプロセスを終了するか別のポートに変更し、そのポートに依存するOSやアプリの設定も更新してください。
- allow-lan LANからのアクセス / 待ち受け範囲
allow-lanは、LAN上のデバイスからクライアントのプロキシ待ち受けサービスへのアクセスを許可する設定です。このデバイス自身のプロキシを有効にする設定ではありません。trueにしても、バインドアドレス、ファイアウォール、無線LANのクライアント分離などによって接続できない場合があります。共有が必要な場合は信頼できる接続元に制限し、必要に応じて認証を設定してください。プロキシの待ち受けポートをインターネットに直接公開しないでください。
- external-controller Control API / プロキシポートではない
external-controllerは管理APIの待ち受けアドレスを指定します。管理画面はこのAPIを通じて接続状況の確認、ポリシーの切り替え、その他の管理操作を行います。mixed-portとは用途が異なり、管理用ポートをブラウザーのプロキシ設定に入力してもウェブ通信はプロキシされません。待ち受けは原則としてローカルに限定し、API認証を設定してください。リモートアクセスを許可する場合は、ファイアウォールとネットワークへの公開範囲も確認しましょう。
- オーバーライド override / クライアント側の設定マージ機能
- オーバーライドは通常、サブスクリプションにローカル設定をマージしたり、ルールを追加したり、設定変更スクリプトを実行したりするクライアント機能を指します。すべてのクライアントで共通のトップレベル項目ではありません。ローカルDNS、ポート、トラフィック分岐の変更を保持できるため、サブスクリプション更新のたびに同じ設定をやり直す手間を減らせます。リストを追加するか置き換えるかは実装によって異なります。編集画面の内容だけで判断せず、変更後の最終設定を必ず確認してください。