カーネルや通信プロトコルから設定ファイルまで、よく使われる24の用語を機能別に解説します。まず用語がどの階層に属するかを確認し、クライアントの設定や実行ログと照らし合わせることで、名前解決の問題と接続の問題を切り分けられます。
操作手順を順番に確認する場合は入門ガイドを、各プラットフォームの権限、インストール、ネットワーク設定については全プラットフォームガイドをご覧ください。
クライアントは操作画面を提供し、カーネルは通信を処理します。互換性の問題を調べる際は、両方を確認する必要があります。
Proxy engine · formerly Clash Meta
mihomoはClash Metaの後継として使われているプロジェクト名で、設定の解析、ルールの照合、プロキシ接続、DNS処理を担います。単独で実行できるほか、GUIクライアントから起動・管理することもできます。同じクライアントでも異なるカーネルビルドが使われる場合があるため、プロトコルや設定項目が使えるかどうかは、実際に動作しているカーネルの対応状況を確認してください。
カーネルとプラットフォーム別の設定を確認 →Graphical client
Clashクライアントは通常、サブスクリプションのインポート、プロキシグループの切り替え、ログの確認、システムプロキシの設定など、カーネルを操作するためのGUIを提供します。クライアント名とカーネル名は別の概念であり、画面上の設定項目がカーネルの全機能を網羅しているとは限りません。選ぶ際は画面の見た目だけでなく、OSへの対応、設定の互換性、権限の管理方法も確認しましょう。
クライアントの選び方を見る →Proxy endpoint
ノードはプロキシ接続に使う設定情報で、通常はサーバーアドレス、ポート、プロトコル、認証情報、通信設定を含みます。表示名は選択しやすくするためのラベルにすぎず、サーバーの所在地、回線品質、利用可能な帯域幅を保証するものではありません。ノードを読み込めても、設定を読み取れたことしか確認できません。サービスが使えるかどうかは、接続テストと実際のアクセスで確認してください。
URL Test · request timing
クライアントは特定のノード経由でテスト先にアクセスし、その所要時間を遅延として表示することがあります。この数値には接続確立、プロトコルのハンドシェイク、接続先の応答時間が含まれる場合があり、ICMP Pingと同じではありません。遅延が小さくてもダウンロード速度が速いとは限りません。ノードを比較する際はテスト先を統一し、パケットロス、連続アクセス、実際の通信速度も合わせて確認しましょう。
遅延テストの仕組みを読む →プロトコルはクライアントとサーバー間のデータ交換方法を定めます。プロトコル、通信方式、暗号化レイヤーはそれぞれ分けて確認しましょう。
Encrypted proxy protocol
Shadowsocksは共有鍵と指定された暗号化方式を使い、クライアントとサーバー間でプロキシ通信を行います。ノードを設定する際は、暗号化方式、パスワード、関連するプロトコル設定をサーバー側と一致させる必要があります。アドレスとポートだけでは接続できません。暗号化方式によって対応状況や処理負荷は異なり、古い設定をインポートできても、現在のカーネルがすべての方式に対応しているとは限りません。
V2Ray protocol
VMessはV2Rayエコシステムのプロキシプロトコルで、ユーザー識別にUUIDを使い、さまざまな通信方式と組み合わせられます。WebSocket、TLS、VMessは同じ階層ではないため、プロトコル認証、通信経路、サーバー名をそれぞれ合わせる必要があります。認証処理によっては正確なシステム時刻が必要です。ハンドシェイクに失敗した場合は、時刻とサーバー側の設定も確認してください。
Lightweight proxy protocol
VLESSはUUID認証を使う軽量なプロキシプロトコルで、汎用的なペイロード暗号化機能はありません。実際の接続ではTLSやREALITYなどの設定を組み合わせることが一般的です。サーバー側のフロー制御、通信方式、セキュリティ設定をすべて一致させる必要があります。VMess設定のプロトコル名をVLESSに変えるだけでは変換できません。両者はプロトコル構造も必要な設定項目も異なります。
TLS-based proxy protocol
Trojanは通常、TLS接続でプロキシ通信を行い、パスワードで認証します。パスワードだけでなく、サーバー名と証明書が一致しているか、証明書チェーンが有効かも確認してください。証明書検証を無効にするとセキュリティ上の前提が変わるため、ハンドシェイク失敗時の標準的な対処として使うべきではありません。まずシステム時刻、ドメイン設定、サーバー証明書の状態を確認しましょう。
ルールが通信の経路を決め、プロキシグループがその経路で使うノードを指定します。ルールの順序と名称も設定の一部です。
Rule-based routing
ルール設定では、ドメイン名、宛先IP、プロセスなどの条件に応じて、接続に直結、プロキシ、拒否のいずれかを適用します。通常は上から順に照合し、最初に一致したルールが適用されるため、具体的な例外は広い条件のルールより前に配置します。変更後は接続の詳細から実際に適用されたルールを確認してください。出口IPを見るだけでは、特定のアプリが以前と同じ経路を使う理由を特定できないことがあります。
ルールの構文と優先順位を見る →Proxy group
プロキシグループは複数のノードやポリシーをひとつの名前でまとめ、ルールから参照できるようにします。ノードをひとつずつ指定する必要はありません。よく使われる種類には、手動選択の select、テスト結果に応じて選ぶ url-test、利用可能なノードへ切り替える fallback があります。自動選択が常に速いとは限りません。グループ内のノード、テスト先、切り替え条件を合わせて確認してください。
Built-in policies and configured names
DIRECTは組み込みの直結ポリシーで、プロキシサーバーを経由せずに接続します。REJECTは条件に一致した接続を拒否します。一方、PROXYは通常、設定作成者が付けたプロキシグループ名であり、すべての設定に標準で用意されているポリシーではありません。ルールで参照するグループ名は定義と完全に一致させてください。大文字・小文字、スペース、名称変更の不一致によって設定を読み込めない場合があります。
Catch-all rule
MATCHは、それ以前のルールに一致しなかったすべての接続に適用されます。通常はルール一覧の末尾に置くフォールバック項目です。たとえばMATCH,DIRECTは、残りの接続を直接接続します。適用先は設定の目的に合わせてください。一覧の先頭に置くと、後続の細分化されたルールが通常は適用されなくなります。振り分けの問題を調べる際は、まず配置を確認しましょう。
IP geography and domain categories
GeoIPはIPアドレスの割り当て情報、GeoSiteはドメイン名の分類情報を提供し、ルール判定に使われます。プロキシノードを提供するものではありません。分類結果はデータの提供元や更新時期によって変わる場合があり、ユーザーやサーバーの正確な物理的位置を示すものでもありません。使用時は、カーネルがデータ形式に対応しているか、ファイルを読み込めているか、先行するルールに上書きされていないかを確認してください。
データベースの更新とルールの記述方法を見る →通信の取り込みとドメイン名の解決は、関連しつつも別の経路です。プロキシを有効にした後も、アプリが実際にどの経路を使うか確認しましょう。
Virtual network interface
TUNモードは仮想ネットワークインターフェースでIP通信を受け取り、カーネルに振り分けと接続処理を任せます。システムプロキシを使わないアプリも対象にできる一方、実際の範囲はルーティング、除外設定、プラットフォームの実装によって異なります。有効にするには適切な権限が必要な場合があります。他のVPNや仮想ネットワークアダプター、LANアクセス用のルールとの競合も確認してください。
各プラットフォームのTUN設定を見る →Operating system proxy settings
システムプロキシは、OSのプロキシ設定をクライアントのローカル待ち受けアドレスとポートに向け、設定に従うアプリから利用できるようにします。すべてのネットワーク接続をひとつのトンネルに通す機能ではありません。一部のゲーム、コマンドラインツール、独自のネットワークスタックを使うアプリは、この設定を参照しない場合があります。クライアント終了後にプロキシ設定だけが残り、待ち受けポートが閉じていると、ブラウザーが接続できなくなることがあります。
Domain Name System
DNSはドメイン名をIPアドレスなどのレコードに変換する仕組みで、通常は名前解決後に接続先への通信が始まります。ブラウザーのセキュアDNS、OSのリゾルバー、カーネルのDNSが同時に使われることがあるため、クライアントのDNS設定を変えても、すべてのアプリの問い合わせ経路が変わるとは限りません。調査では、名前解決の失敗、返されたアドレスの不適切さ、接続先への接続失敗を区別してください。それぞれ必要な対処が異なります。
Synthetic address mapping
Fake-IPは、問い合わせたドメイン名に合成アドレスを返し、カーネル内にアドレスとドメイン名の対応関係を保存します。その後、接続がカーネルに届くと、対応関係からドメイン名を復元して通信を振り分け、実際の接続を行います。合成アドレスはWebサイトの実IPアドレスではありません。実際の名前解決結果を必要とするアプリには例外設定が必要な場合があります。DNSモードを切り替えた後は、OSやアプリに古いキャッシュが残っていないかも確認してください。
DNS query path leakage
DNSリークとは、DNSクエリが想定した名前解決経路を通らない状態を指します。たとえばプロキシ経由で送る予定のクエリが、アプリから別のリゾルバーへ直接送信されるケースです。実際の送信先と通信方式が想定どおりかを確認し、出口IPだけで推測しないようにしましょう。暗号化DNSは特定の通信区間を保護できますが、クエリがプロキシを経由するとは限りません。ブラウザーの設定、OSのルーティング、カーネルのログをあわせて確認してください。
ネットワーク障害のトラブルシューティングを見る →サブスクリプションは設定情報を配信し、設定ファイルは通信の動作を定義します。インポート成功、構文の有効性、接続可能かどうかは、それぞれ別に確認する必要があります。
Subscription URL
サブスクリプションはURLからノード情報や設定全体を取得・更新する仕組みで、取得した内容がすべてのクライアントで使えるとは限りません。URLにアクセス用の認証情報が含まれる場合があります。スクリーンショット、ログ、問い合わせ内容を共有する前に、URL全体を隠してください。更新によってローカルで編集した内容が上書きされることがあるため、独自ルールはクライアントが対応するオーバーライドやマージ機能に設定し、更新後に反映結果を確認しましょう。
サブスクリプションのインポート手順を見る →YAML configuration format
YAMLはClashの設定によく使われる構造化テキスト形式です。インデントで階層を表し、リストやマップで設定項目を整理します。インデントにはタブではなくスペースを使い、特殊文字を含む値はYAMLの規則に従って引用符で囲んでください。構文解析に成功しても、テキスト構造が有効であることしか確認できません。各項目への対応状況や参照先のプロキシグループが存在するかは、使用中のカーネルで確認が必要です。
Runtime configuration file
config.yamlはプロキシカーネルでよく使われる設定ファイル名で、待ち受けポート、ノード、プロキシグループ、ルール、DNS設定などを記述できます。GUIクライアントはサブスクリプション、オーバーライド、画面上の設定を統合し、別の実行用設定を生成する場合があります。そのため、編集中のファイルがカーネルの最終的な読み込み対象とは限りません。変更が反映されない場合は、同じ項目を何度も編集する前に、現在の設定ファイル、保存状態、再読み込み結果を確認してください。
Subscription conversion
サブスクリプション変換では、ノード情報や既存の設定を別のクライアントで読み込める形式に整えたり、プロキシグループやルールのテンプレートを追加したりします。形式を変換しても、カーネルが未対応のプロトコルを使えるようにはなりません。元データに必要な設定がなければ、自動で補われることもありません。リモート変換サービスを使う場合、サーバー側にサブスクリプションURLやノードの認証情報が渡る可能性があるため、取り扱い範囲を事前に確認してください。互換性のある設定がすでにある場合は、直接インポートする方法を優先しましょう。
External proxy providers
proxy-providersは、リモートまたはローカルのノード一覧を定義する設定項目です。ノードの更新とメイン設定の管理を分けられます。読み込み後、通常はプロキシグループからuseで参照すると、該当グループの選択肢にノードが表示されます。プロバイダーのダウンロードに成功しても、グループ内のノードが接続できるとは限りません。データ形式、参照名、ノードのテスト結果をそれぞれ確認してください。
External rule providers
rule-providersは外部ルールセットを定義する項目で、メインルール一覧のRULE-SETから使用位置と適用するポリシーを指定します。ルールセットの内容は、宣言したbehaviorとformatに合った形式にする必要があります。ドメイン名の一覧を、形式を問わない任意のルールセットとして扱うことはできません。ルールセットの内容を更新しても、接続に適用されるかどうかはメインルール一覧内の順序によって決まります。