通信の入り口からルールの照合、そしてプロトコルによる送信まで、Clash の一連のプロセスを紐解きます。単なる設定のコピーではなく、ルール振り分け、TUN 透明プロキシ、DNS リーク対策の裏側にある仕組みを理解しましょう。
ブラウザで URL を開いたとき、通信は直接行われるわけではありません。Clash はローカルで1つ以上のポートを監視し、すべての送信接続をインターセプトします。そしてルールエンジンが「直接接続」か「プロキシ経由」かを判断します。
全体のプロセスは5つの段階に分かれ、それぞれに Clash の介入ポイントがあります：
rules リストに従い、ドメイン、IP、プロセス名などの条件を上から順に照合します。
ルールエンジンは Clash の最も重要な機能です。rules リストを上から順に1行ずつ照合し、最初にマッチしたルールが即座に適用されます。以降のルールは無視されるため、記述する順番が極めて重要です。
最も頻繁に使用されるタイプです。ドメイン全体やサフィックス（後方一致）で、特定のサイトごとに経路を指定できます。
接続先の IP アドレスや GeoIP データベースに基づいて判断します。「国内は直結、海外はプロキシ」を実現する中核的なルールです。
アプリのプロセス名やポート番号で振り分けます。特定のソフト（開発ツールやゲームなど）だけ別の経路を通したい場合に便利です。
膨大な数のルールを外部のサブスクリプションファイルにまとめ、クライアントが定期的に更新・取得する仕組みです。大規模な振り分け設定に適しています。
interval を設定することで、自動的な定期更新が可能です。ルールは上から順にチェックされ、最初にマッチしたものが適用され、それ以降は実行されません。よくある間違いとして、GEOIP の前に MATCH,DIRECT を置いてしまうと、すべての通信が直接接続されてしまいます。推奨される順番：
IP-CIDR 192.168.0.0/16） → DIRECTGEOIP,CN,DIRECT — 国内 IP であれば直接接続MATCH,Proxy — デフォルト設定。上記に該当しないものはプロキシ経由Clash にはトラフィックを取り込む2つの方法があります。適切なモードを選ばないと「特定のアプリにプロキシが効かない」原因になります：
stack オプション：system はシステムのネットワークスタックを使用し、高性能です。gvisor はユーザー空間のスタックを使用し、互換性に優れています。Mihomo カーネルは mixed 混合モードもサポートしています。
DNS リークは、プロキシ利用者が最も見落としがちなセキュリティ上の盲点です。トラフィックがプロキシを通っていても、DNS クエリが地元の ISP へ明文で送信されてしまうと、訪問先のドメインが筒抜けになってしまいます。Clash はこの問題に対処するため、高度な DNS 処理モジュールを内蔵しています。
DNS リクエストを受け取ると、Clash は即座に仮想 IP（例: 198.18.x.x）を返します。これによりアプリは即座に接続を開始でき、実際の DNS 解析はプロキシサーバー側で行われるため、ローカルでのドメイン漏洩を防げます。
198.18.0.1 を返すまずローカルで実際の DNS 解析を行い、ドメインをリアル IP に変換してからルールエンジン（GEOIP など）に渡します。互換性は高いですが、DNS クエリ自体が ISP に漏れるリスクがあります。
fallback と fallback-filter の併用：海外 IP と判定された場合、自動的に暗号化された DoT / DoH サーバーで再解析を行い、DNS 汚染を防ぎます。
プロトコルは、通信の暗号化や難読化の戦略を決定します。Clash は多彩なプロトコルをネイティブサポートしており、Mihomo (Clash Meta) カーネルではさらに次世代プロトコルが拡張されています。
対称鍵暗号（AES / ChaCha20）を使用して通信を暗号化し、データをランダムに見せることで DPI（ディープ・パケット・インスペクション）に対抗します。設計がシンプルで、対応クライアントが最も多いです。
V2Ray プロジェクトによる独自プロトコル。暗号化に加えてタイムスタンプ検証や難読化機能を備えています。WebSocket + TLS と組み合わせることで HTTPS 通信に完璧に擬装でき、高い遮断耐性を誇ります。
TLS レイヤー内で直接データを転送するため、外見は通常の HTTPS と全く区別がつきません。サーバー側で実際のウェブレスポンスを返すことで、プロキシの特徴をさらに隠蔽します。
QUIC (UDP) をベースにした次世代の高速プロトコル。弱網環境やパケットロスが多い回線において、TCP ベースのプロトコルより圧倒的に高いパフォーマンスを発揮します。不安定な長距離回線に最適です。
同じく QUIC ベースで、低遅延と接続の再利用に特化。0-RTT ハンドシェイクにより接続開始を高速化。ゲームやリアルタイム通話など、レスポンス速度が重視されるシーンに最適です。
コードが極めて軽量で監査が容易な、現代的な VPN プロトコル。ChaCha20 + Poly1305 を採用し、カーネルレベルの実装により最高峰のパフォーマンスを誇ります。Mihomo はこれをアウトバウンドとして利用可能です。
ポリシーグループは、ルールを「まとめる」役割とノードを「振り分ける」役割を担います。ルールに合致した通信は、直接ノードへ行くのではなく、まずポリシーグループへ渡されます。グループ内で自動測速や死活監視を行い、最適なノードを決定します。
ユーザーがノード一覧から手動で使用するノードを選びます。クライアント画面で直接操作する最も標準的な方法です。経路を固定したい場合に使用します。
全ノードに対して定期的に HTTP リクエストを送信し、最も応答が速いノードを自動で選択します。一定以上の差（tolerance）がある場合のみ切り替わるため、頻繁な変動を抑えられます。
リストの先頭から順に使用し、ノードがダウン（健康診断失敗）した場合に次のノードへ自動で切り替えます。常に接続を維持したいシーンに適しています。
複数のノードを順番、あるいはランダムに利用して通信を分散させます。全体の帯域を最大限活用したい場合に有効です。Mihomo はセッション維持のための consistent-hashing に対応しています。
現在、Clash には2つの主要なブランチがあります。日常会話では混同されがちですが、特にプロトコルのサポート範囲や TUN モードの拡張機能において大きな違いがあります。
結論：新規ユーザーの方は、プロトコル対応がより完全で TUN モードも強力な Mihomo (Clash Meta) カーネルを採用したクライアント（Clash Verge Rev、Mihomo Party、Clash Meta for Android など）を直接選ぶのが最も賢明です。従来版の Clash も安定していますが、現在の開発の主流は Mihomo ブランチへと移行しています。
MATCH ルールを上に置いてしまうと、それより下の詳細なルールが一生実行されなくなります。理想的な順番は：ローカルネットワーク → 特定ドメインのプロキシ設定 → 特定ドメインの直接接続 → GEOIP による判定 → 最後に MATCH で一括設定、という流れです。198.18.x.x) を特別扱いするアプリで不具合が出ることがあります。その場合は Clash の fake-ip-filter 設定に該当ドメインを追加することで、通常の DNS 解析（リアル IP）を行わせることができます。system スタックは gvisor より高性能ですが、マシンスペックが不足している場合は、特定のアプリのみシステムプロキシを利用し、TUN はオフにすることをお勧めします。http://www.gstatic.com/generate_204 や Cloudflare の http://cp.cloudflare.com/generate_204 が一般的です。国内アドレスを使うとプロキシ経由の判定を誤る可能性があるため、国外のアドレスを推奨します。