Clash
Clashはもともと、ルールに基づいてネットワーク接続を処理するプロキシコアのプロジェクト名でした。現在は関連するクライアント群の総称として使われることもあります。オリジナルのプロジェクトと後続のフォークは、同じ開発主体ではありません。対応するプロトコルや設定項目も完全には一致しません。「Clash対応」と書かれていても、どのコアを前提としているかを確認してください。拡張子だけで互換性を判断することはできません。
CLASH / 設定用語集
Clash用語集
サブスクリプション、ルール、TUN、DNS。まず用語を整理してから設定を変更しましょう。
5分野・25用語・各項目の見出しから直接リンクをコピー
01 / PROJECTS
コアとプロジェクト
コアは接続を処理し、クライアントは操作画面を提供します。名称とバージョンは分けて確認しましょう。
mihomo
mihomoはClash Metaの技術路線を引き継ぎ、プロキシプロトコルへの接続、ルール判定、DNS処理、TUN経由のトラフィックを扱います。mihomoはコアであり、特定のデスクトップアプリやスマートフォンアプリを指すものではありません。複数のGUIクライアントで同じ種類のコアを利用できます。機能の対応状況を調べるときは、クライアントとコアの両方のバージョンを記録してください。
GUIクライアント
GUIクライアントは、スイッチの操作、サブスクリプションのインポート、ポリシー選択、ログ確認などに使うアプリです。Clash Verge RevやFlClashなどがあります。画面での設定をコア用の設定に変換するほか、システムプロキシ、サービスの権限、自動起動なども管理する場合があります。同じ種類のコアを使っていても、設定の保存場所やオーバーライドの適用順序はクライアントごとに異なることがあります。移行時にアプリの設定をそのまま一括で移さないようにしてください。
外部コントローラー
フロントエンドやコントロールパネルからコアを管理するための入口です。接続情報の取得、ポリシーの切り替え、設定の更新に使います。ブラウザー用のプロキシポートではありません。127.0.0.1:9090はローカルで待ち受ける場合の例であり、混合プロキシポートとして設定するものではありません。リモートからアクセスする場合は、アクセスキーを設定し、ネットワーク上のアクセス範囲を制限してください。管理機能を外部に直接公開しないようにしましょう。
コアログ
ログにはコアの実行中の接続情報やエラーが記録され、DNSの失敗、プロキシのハンドシェイク失敗、ルールの適用状況を調べる手がかりになります。log-levelで記録の詳細度を指定できます。問題の調査中は一時的に詳細度を上げ、再現できたら通常の設定に戻してください。ログを共有する前に、サブスクリプションURL、認証情報、公開したくないアクセス先ドメインを削除しましょう。
02 / PROTOCOLS
プロキシプロトコル
プロトコルは接続方式を表し、回線の品質を示すものではありません。インポート時には必要なパラメーターをすべて保持してください。
Shadowsocks
Shadowsocksは暗号化プロキシプロトコルの一種です。通常、ノードにはサーバーアドレス、ポート、パスワード、暗号化方式が必要です。クライアントとサーバーで互換性のある設定を使ってください。プラグインやそのオプションが含まれる設定もあり、アドレスとパスワードだけでは接続できない場合があります。暗号化方式によって対応状況が異なります。インポートできても接続できない場合は、まずコアが該当方式に対応しているか確認してください。
VMessとVLESS
VMessとVLESSは異なるプロキシプロトコルです。設定の種類名を書き換えるだけで相互に変換することはできません。VLESS自体は暗号化を提供せず、接続の保護はTLSやREALITYなど、実際に組み合わせるセキュリティレイヤーによって決まります。調査時はユーザーID、トランスポート方式、サーバー名、関連するセキュリティパラメーターを一つずつ確認してください。サーバーが稼働しているかどうかだけでは不十分です。
Trojan
Trojanは通常、TLSでクライアントとサーバー間のプロキシ接続を保護します。パスワードだけでなく、正しいサーバー名と証明書の検証も必要です。サーバーアドレスは接続に使い、TLSサーバー名はハンドシェイクと認証に使います。両者は異なる場合があります。証明書エラーが出たら、設定とシステム時刻を優先して確認してください。証明書検証の無効化を恒久的な対処にするのは避けましょう。
Hysteria 2
Hysteria 2はQUICベースのプロキシプロトコルです。接続できるかどうかは、使用中のネットワークでUDP通信が可能かどうかに左右されます。初代Hysteriaとはプロトコルも設定も共通ではないため、インポート時に種類が正しく認識されているか確認してください。プロトコル名だけでは実際の速度はわかりません。ネットワークの制限、サーバーの負荷、帯域幅の設定も通信品質に影響します。普段使うネットワークで実測してください。
SOCKS5・HTTPプロキシ
この2種類の入口は、アプリからローカルクライアントにトラフィックを渡すために使われます。クライアントがリモートノードへの接続に使うプロトコルとは異なります。HTTPプロキシでもCONNECTを使ってHTTPS接続を中継でき、HTTPサイトだけに限られるわけではありません。混合ポートはHTTPとSOCKSの両方を受け付けます。アプリでプロキシを手動設定する場合は、設定に記載されたアドレスと実際のポートを入力してください。ポートが必ず7890だとは限りません。
03 / ROUTING
ルールと振り分け
接続先は、ルールの順序や照合条件、プロキシグループで現在選択されている項目によって決まります。
ルール振り分け
ルール振り分けでは、設定の順に接続を照合し、条件に一致した時点で対応するポリシーに渡します。主な処理は、直接接続、プロキシ、拒否です。具体的なドメインのルールは、広い範囲を対象とするルールより前に置き、末尾にMATCHを設定して残りの接続を処理するのが一般的です。TUNを有効にしてもルール振り分けは可能です。トラフィックの取り込み方法と接続先の選択は別の仕組みです。
プロキシグループ
プロキシグループはノードやほかのポリシーをまとめ、ルールから参照できる接続先として設定します。ルールは通常、個別のノードではなくグループを指定します。selectは手動選択、url-testはテスト結果に基づく選択、fallbackは利用可能な接続先と順序に基づくフェイルオーバーに使います。グループ内の選択を変更すると、主に新しい接続に反映されます。既存の長時間接続がすぐに切り替わるとは限りません。
GeoIPとGeoSite
GeoIPはIPアドレスのデータによる分類、GeoSiteはドメイン集合による分類に使われ、相互に置き換えることはできません。IPアドレスの割り当て地域と実際のサービス提供地域は、必ずしも一致しません。CDNの影響で同じドメインが異なる地域のIPアドレスに解決される場合もあります。判定結果はデータの提供元や更新状況、コアの対応状況によって異なります。振り分けに誤りがある場合は、ノード名だけで判断せず、該当するルールとデータを確認してください。
ルールセット
ルールセットでは複数のルールを別ファイルで管理します。メイン設定でrule-providersを使って取得元を定義し、RULE-SETで参照します。分類データを更新しやすくなりますが、接続先が自動で決まるわけではありません。参照するルールには、適用先のポリシーを指定する必要があります。形式や動作タイプごとに要件があり、ダウンロードできても現在の定義方法で正しく解析できるとは限りません。
レイテンシテスト
クライアントに表示されるレイテンシは、指定URLへの接続やリクエストをテストした時間で、従来のICMP Pingとは限りません。特定の宛先に対して、テストした時点でかかった時間を示すものであり、ダウンロード速度、動画の安定性、すべてのサイトへの接続性を直接表すものではありません。ノードを比較する場合は、できるだけ同じテスト先を使い、実際のアプリでも確認してください。一度タイムアウトしても、テスト先自体に接続できない可能性があります。
04 / NETWORK STACK
DNSとネットワーク
まずトラフィックがどのようにコアへ入り、次にドメインがどのように名前解決されるかを確認します。接続できても、DNSの経路が想定どおりとは限りません。
システムプロキシ
システムプロキシはOSのプロキシ設定をローカルクライアントに向ける機能で、主にその設定に従うアプリに適用されます。一部のコマンドラインツール、独自のネットワーク処理を行うアプリ、ゲームは設定を参照しないことがあります。そのため、ブラウザーで接続できても、すべてのプログラムがプロキシ経由とは限りません。クライアントを終了する前に、システムプロキシが元に戻っていることを確認してください。戻っていないと、待ち受けを停止したローカルポートへアプリが接続しようとする場合があります。
TUNモード
TUNは仮想ネットワークインターフェースを通じて、ルーティング条件に合うトラフィックをコアに渡します。システムプロキシの設定に従わないアプリの通信を取り込む場合に使われます。通常は適切な権限やサービスが必要で、対象範囲はルーティング、除外設定、ほかのVPNの影響も受けます。TUNを有効にしても、すべての接続がプロキシ経由になるわけではありません。コアに取り込まれた後も、ルールに従って直接接続や転送ができます。
DNS名前解決
DNSはドメインに対応するIPアドレスなどを問い合わせる仕組みで、多くの接続で重要な役割を果たします。どのDNSサーバーに問い合わせるか、どのネットワーク経路を通るかによって、返される結果や後続のルール判定が変わることがあります。DNSの問い合わせ経路とWeb接続の経路は分けて考えてください。ノードを変更しても問題が解決しない場合、DNSキャッシュや設定が影響している可能性もあります。
Fake-IP
Fake-IPモードはアプリに仮想IPアドレスを返し、コアがアドレスとドメインの対応関係を保存します。接続が届いたときにドメイン情報を復元して振り分けに利用できます。仮想アドレスはWebサイトの実サーバーのアドレスではないため、表示されても名前解決の失敗を意味しません。実IPアドレスに依存するアプリやLAN内のデバイス検出を使うアプリは、フィルターリストへの追加が必要な場合があります。名前解決方式を切り替えた後は、必要に応じてアプリやOSのキャッシュを消去してください。
DNSリーク
DNSリークとは、DNS問い合わせが想定した名前解決経路から外れることです。特定の地域のDNSサーバーが表示されたというだけでは、DNSリークとは判断できません。ブラウザーのセキュアDNS、OSのリゾルバー、IPv6、アプリ独自の名前解決が別々の経路を使うことがあります。検証する際は、どの問い合わせを直接接続にし、どれをプロキシ経由にする想定かを明確にしてから、接続ログやテスト結果を確認してください。暗号化DNSでも、問い合わせがプロキシ経由になるとは限りません。
05 / CONFIGURATION
サブスクリプションと設定ファイル
サブスクリプションは設定を取得し、設定ファイルは実際の動作を決めます。取得元とローカルの変更は分けて管理しましょう。
サブスクリプション
サブスクリプションは、設定やノード一覧を繰り返し取得するためのURLです。提供元が内容を更新すると、クライアントから再取得できます。見た目が似たURLでも、返されるのはYAML全体、Base64でエンコードされた一覧、単一のプロトコルリンクなどさまざまです。形式に合った方法でインポートしてください。サブスクリプションURLはアカウント権限に紐づくことが多いため、機密情報として扱い、公開画像や信頼できないオンライン変換ツールに載せないようにしましょう。
ノード
ノードはリモートプロキシへの接続に必要なパラメーター一式で、通常はサーバーアドレス、ポート、プロトコル、認証情報、トランスポートの設定などを含みます。画面に表示されるノード名はラベルにすぎず、実際の接続先の地域、帯域幅、サービス品質を証明するものではありません。インポート後にノード一覧が表示されても、設定が読み込まれたことを示すだけです。ポリシーを選択し、実際に接続できるか確認してください。
YAML設定
YAMLはキーと値、リスト、インデントでデータを表現します。Clashのエコシステムでは、ポート、ノード、プロキシグループ、ルール、DNSなどの記述に使われます。インデントにはスペースを使ってください。階層の誤り、キーの重複、リスト記号の不足があると、解析に失敗したり想定外の結果になったりします。YAMLとして解析できても、すべての項目が現在のコアで使えるとは限りません。編集後はコアの読み込みメッセージも確認してください。
プロキシプロバイダー
プロキシプロバイダーはproxy-providersで独立したノードの取得元を定義し、プロキシグループから参照することで、ノードの更新をメイン設定から分離します。ルールプロバイダーとは用途が異なり、あらゆる形式のサブスクリプションファイルをそのまま指定できるわけではありません。ノードが表示されない場合は、取得元の形式や取得結果、プロキシグループから正しく参照されているかを確認してください。更新ボタンを繰り返し押すだけでは解決しないことがあります。
設定のオーバーライド
設定のオーバーライドは、サブスクリプションの元データにローカルの変更を適用し、ポート、DNS、独自ルールなどを保持するための仕組みです。クライアントによって、項目の置換、リストの結合、スクリプト処理など方式が異なり、すべてのオーバーライドが同じ動作をするとは限りません。更新後に変更が消えた場合は、再ダウンロードで上書きされる元ファイルを編集していないか確認し、最終的な実行設定とオーバーライドの適用順序を調べてください。