Clashの基本用語集

mihomoはClash Metaから発展したプロキシコアで、設定の読み込み、ルール判定、DNS処理、接続の転送を担います。Clashエコシステムの複数のGUIクライアントに組み込まれていますが、画面に表示されるクライアント名とコア名は同じとは限りません。プロトコルや設定項目の対応状況を調べる際は、クライアント名だけでなく、実際に動作しているコアとそのバージョンを確認してください。

クライアントはサブスクリプションのインポート、ノード選択、システムプロキシの切り替え、ログ確認などの画面を提供し、コアは設定に基づいて通信を処理します。クライアントの更新でコアも更新される場合と、画面機能だけが変わる場合があります。新しい設定項目が反映されない、起動できない、権限を求められるといった場合は、設定の解析、コアの動作、システム連携のどこで問題が起きているかを切り分けてください。

ノードはプロキシサーバーへの接続に必要なパラメーターのまとまりです。通常、サーバーアドレス、ポート、プロトコル、認証情報、通信方式が含まれます。名前が異なる複数のノードが同じサーバーを使う場合もあり、表示名だけでは接続先の地域や品質は判断できません。ログやスクリーンショットを共有する際は、表示名だけでなく、ノードに含まれるパスワードや鍵などの認証情報も隠してください。

遅延テストでは、ノード経由で指定したテスト先にアクセスしたときの応答時間を測定します。ICMP pingやダウンロード速度と同じ指標ではありません。スループットテストでは一定時間に転送できるデータ量を測定しますが、テスト先のサーバー、混雑状況、デバイスの性能にも左右されます。結果を比較する際は、できるだけ同じテスト先とネットワーク環境を使いましょう。一度タイムアウトしただけで、ノードが恒久的に使えないとは判断できません。

混合ポートは、同じ待ち受けポートでHTTPプロキシとSOCKSプロキシの接続を受け付けます。アプリ側では、対応するプロキシの種類を選んで設定してください。ポート番号はローカルの接続口であり、リモートノードのポートではありません。また、コアが正常に起動していることを示すものでもありません。他のデバイスから接続できるかどうかは、待ち受けアドレス、LAN接続の許可設定、システムのファイアウォールによって決まります。

HTTPプロキシでは、アプリがプロキシサーバーに接続し、リクエストをプロキシ経由で送信します。HTTPSサイトへのアクセスでは、通常CONNECTメソッドでトンネルを確立します。接続先のWebサイトがHTTPSでも、アプリからプロキシサーバーまでの通信がTLSで暗号化されているとは限りません。リモートのHTTPプロキシを設定する際は、プロキシまでの通信が暗号化されるか、認証が必要か、アプリが接続方式に対応しているかを確認してください。

SOCKS5は汎用プロキシプロトコルで、TCP転送に加えてUDPアソシエーションの仕組みも定義しています。プロトコル自体に通信の暗号化機能はなく、アプリとプロキシの実装がどちらもUDPに対応しているとは限りません。ドメイン名をローカルで解決するか、プロキシに処理を任せるかは、アプリが送信するアドレスの形式によります。同じSOCKS5アドレスを設定しても、すべてのアプリでDNSの経路が同じになるわけではありません。

Shadowsocksでは、合意した暗号方式と認証情報を使って、クライアントとサーバー間でプロキシ通信を行います。アドレス、ポート、暗号方式、パスワードまたは鍵をサーバー側の設定と一致させてください。暗号方式を自由に入れ替えることはできません。構成によっては、追加のプラグインや通信パラメーターも必要です。インポート後に接続できない場合は、ノード名を何度も変更するのではなく、ノード定義全体を確認してください。

Trojanの一般的な構成では、TLSを使ってプロキシ通信を行います。設定には通常、サーバーアドレス、パスワード、TLS用のサーバー名が含まれます。接続先アドレスと証明書のドメイン名が異なる場合があるため、SNIなどの設定も確認してください。証明書の検証に失敗した場合は、まずデバイスの時刻、ドメイン名、証明書チェーンを確認します。証明書検証を無効にする方法を恒久的な解決策にしないでください。

Hysteria 2はQUICベースのプロキシプロトコルで、通信にUDPを使用するため、ネットワークのUDP制限が接続に直接影響することがあります。認証情報、TLS、任意の難読化設定をサーバー側と一致させてください。初代と第2世代のプロトコルでは設定方法も異なります。このタイプのノードだけがタイムアウトする場合は、まずUDPの通信経路を確認し、コアのログでハンドシェイクの段階を調べてください。

ルールモードでは、接続条件を上から順に照合し、一致した通信を指定のプロキシに振り分けます。たとえばDOMAIN-SUFFIX,example.com,PROXYは、example.comとそのサブドメインへの通信をPROXYというプロキシに送ります。広い範囲に一致するルールが先に通信を処理する場合があります。接続先が想定と異なるときは、ルールが存在するかだけでなく、接続ログで実際にどのルールが適用されたか確認してください。

プロキシグループは複数のノードや他のプロキシをまとめ、ルールから参照できる接続先を定義します。selectは手動選択、url-testはテスト結果に基づく選択、fallbackは候補の順に利用可能な接続先へ切り替える方式です。自動テストの結果はテスト先やパラメーターによって異なり、すべてのWebサイトで同じ効果が得られるとは限りません。グループ内の選択を変更しても、確立済みの接続が切り替わらない場合があります。

GeoIPはIPデータベースを使って宛先アドレスの地域を判定します。たとえばGEOIP,CN,DIRECTのようなルールで利用します。ドメインへの接続で追加の名前解決が行われるかは、コアの動作やno-resolveなどのパラメーターによります。アドレスの割り当てやCDNの振り分けによって、データベースの結果が想定と異なることもあります。IPの地域判定は範囲の振り分けに使うもので、Webサイトの運営主体の所在地を示すものではありません。

ルールセットを使うと、一連の照合条件をメイン設定から分離できます。rule-providersで取得元を定義し、RULE-SETで参照します。内容の種類は、宣言した動作タイプやファイル形式に合わせてください。ドメインのリストと従来形式のルールセットは、自由に置き換えられません。ルールセットの更新に成功しても、接続に適用されるかどうかはメインのルール一覧での参照位置によります。

MATCHは、それまでのルールに一致しなかった通信を処理するため、ルール一覧の最後に置きます。最終的な接続先にはプロキシグループのほか、DIRECTやREJECTも指定できます。ドメインルールより前に置くと、後続のルールで通信を処理できなくなることがあります。順序を変更した後は、接続を確立し直して適用結果を確認してください。

DNSはドメイン名をIPアドレスに変換します。名前解決には、システムのリゾルバー、クライアント内蔵のリゾルバー、ブラウザーのセキュアDNSなどが使われることがあります。DNSクエリの経路と、Webサイトへの接続で使われる経路は別の問題です。ドメイン名では接続できずIPアドレスなら接続できる場合は、名前解決の結果やリゾルバーへの接続を確認してください。ただし、HTTPS証明書や仮想ホストの仕組みにより、IPアドレスへの直接アクセスが失敗することもあります。

Fake-IPはDNSクエリに対してマッピング用のアドレスを返し、接続がコアに届くと、そのマッピングから元のドメイン名を復元して後続処理を行います。これによりドメイン名の情報を保ち、一部の環境では実際のIPアドレスをローカルで名前解決する必要を減らせます。LAN内のサービスや実際の名前解決結果に依存するアプリでは、必要に応じてfake-ip-filterを調整してください。モード変更後は、システムやアプリに残っているDNSキャッシュにも注意が必要です。

DNSリークは、アプリのクエリが元のネットワークのリゾルバーに送られるなど、想定した名前解決経路を通らない状態を指します。確認する際は、システムDNS、ブラウザーのセキュアDNS、IPv6、TUNが通信を取り込む範囲をあわせて確認してください。テストページに表示されるリゾルバーの所在地は手がかりの一つにすぎず、地域名だけで結論を出すことはできません。必要に応じてログやパケットキャプチャで、クエリの実際の送信先を確認してください。

TUNモードでは仮想ネットワークインターフェースを通じてIP通信を受け取り、システムプロキシを使っていないアプリの通信もコアで処理できるようにします。実際に取り込まれる通信は、システム権限、ルーティング、除外設定、DNSの設定によって異なります。TUNを有効にしても、あらゆる通信が自動的に処理されるわけではありません。他のVPNと併用する場合はルートの競合を確認してください。また、仮想インターフェース自体をリモートの暗号化トンネルと混同しないでください。

システムプロキシは、この設定に従うアプリにローカルのプロキシアドレスを通知する仕組みで、すべてのプログラムの通信を強制的に取り込むものではありません。ブラウザーは設定に従う一方、コマンドラインツールやゲーム、独自のプロキシ設定を持つアプリは別の経路を使うことがあります。一部のアプリだけ通信ログに表示されない場合は、まずアプリ独自のプロキシ設定を確認してください。クライアントが異常終了して接続できなくなった場合は、システムに古いプロキシアドレスが残っていないかも確認しましょう。

サブスクリプションは、更新可能なノードや設定をリモートURLから取得する仕組みです。サービスによって返される形式は異なります。完全なClash設定を返すものもあれば、ノード一覧だけを返すものもあり、後者のインポートには対応するクライアント機能が必要です。サブスクリプションURLにはアクセス用の認証情報が含まれる場合があるため、パスワードと同様に管理してください。更新に失敗した場合は、ネットワーク接続、アカウントの状態、内容の解析エラーを切り分けます。

YAMLはClashの設定によく使われる構造化テキスト形式です。インデントで階層を表し、ハイフンでリスト項目を記述します。インデントにはスペースを使ってください。特殊文字を含む値は引用符で囲む必要がある場合があり、キーの重複はエラーや設定の上書きにつながることもあります。YAMLの構文を解析できても、項目名や参照関係、ノードのパラメーターが正しいとは限りません。実際に使用するコアでも設定を検証してください。

設定ファイルには通常、待ち受けポート、ノード、プロキシグループ、ルール、DNSなどを記述します。外部のプロバイダーから一部の項目を読み込むこともできます。クライアントに複数のファイルが保存されていても、コアが使用するのは現在選択されている設定と、クライアントによる統合後の内容です。ファイルを変更しても反映されない場合は、保存済みか、対象の設定が選択されているか、再読み込みに成功したかを確認してください。編集画面に表示された内容だけを確認しても不十分です。

プロキシプロバイダーはノードの参照元をメイン設定から分離し、リモートURLやローカルファイルからノードを読み込みます。プロキシグループからuseで参照できます。提供するのはプロキシ候補であり、照合条件を提供するrule-providersとは役割が異なります。プロバイダーの取得に成功してもグループにノードが表示されない場合は、ファイル形式、プロキシグループの参照名、ノードのフィルター条件を確認してください。

設定オーバーライドは、ベース設定やサブスクリプションとは別にローカルの変更を保存し、更新時や読み込み時に最終設定へ統合する仕組みです。DNS、ポート、ルールなどのカスタマイズを保持するために使われますが、統合順序はクライアントによって異なり、配列を追加ではなく置き換える場合もあります。設定後は、最終的に有効な内容を確認してください。オーバーライド用のファイルがあるだけでは、カスタムルールがコアに反映されたとは限りません。