Clash 入門から応用まで：インストール、サブスクリプション、ルール分流の完全ガイド

本マニュアルは学習順に構成されており、前の章が次の章の前提になります。まずカーネルとクライアントの役割分担を理解してからでないと、以降の各設定項目がどちらの管轄なのかが分かりません。先にサブスクリプションをインポートして初めて、ルールや TUN が制御する対象が生まれます。最初は順番どおりに一通り読み、その後はリファレンスとして使い、具体的な問題が起きたときは上の目次から該当章へ直接ジャンプしてください。本文中の設定例はすべて config.yaml の対応するセクションにコピーできます。例に登場するサーバーアドレス、パスワード、サブスクリプションリンクはすべてプレースホルダーで、実際にはサブスクリプションまたはご自身のサーバー側から提供されます。

コア概念：Clash、カーネル、クライアントの関係

Clash という言葉は、文脈によって3つのものを指します。ルールベースプロキシの設定仕様、その仕様を実装したカーネルプログラム、そしてその上に GUI を載せたクライアントです。初心者が最もつまずきやすいのは、「Clash をダウンロードする」を「ソフトを1つダウンロードする」と解釈してしまう点です。実際に日々開くのは GUI クライアントで、接続を確立し、ドメイン名を解決し、ルールに従ってデータを転送しているのはカーネルです。この2層の役割分担を理解しておけば、以降の設定項目がどこに置かれるのか、なぜ一部の設定は変更後にカーネルの再起動が必要なのかが、自然に腑に落ちます。

カーネル：実際にトラフィックを処理する層

カーネルは UI を持たないコマンドラインプログラムです。起動時に YAML 設定ファイルを読み込み、次の4つを行います。ローカルポートをリッスンしてアプリからの接続を受け付ける、設定内のノード情報を使えるアウトバウンドとして整理する、rules セクションに従って接続ごとにどのアウトバウンドを使うか順に判定する、その判断過程をログに書き出す。

mihomo（旧名 Clash Meta）は現在コミュニティでメンテナンスされているメインラインのカーネルです。オリジナルの Clash カーネルはメンテナンスが終了しており、新しくリリースされるクライアントはほぼすべて mihomo ベースです。カーネル自体はサブスクリプションを扱いません。自分から設定をダウンロードすることも、自動更新することもなく、起動時に読み込んだファイルだけを認識します。設定ファイルを変更した場合は、リロードまたはカーネルの再起動が必要です。

GUI クライアント：設定管理と操作シェル

GUI クライアントはカーネル以外のすべてを担当します。サブスクリプションリンクを config.yaml としてダウンロードする、モードやノードを切り替えるスイッチを提供する、カーネルのログを読みやすいパネルとして表示する、システムトレイや通知領域に常駐する、起動時にカーネルを立ち上げる、などです。同じ設定ファイルでもクライアントによって見せ方は異なりますが、最終的にはファイルをカーネルに渡して実行させます。

ここから実用的な結論が1つ導けます。クライアントを乗り換えても、サブスクリプションリンクはそのまま使えることが多く、作り直しが必要なのはクライアント側の設定（ポート番号、TUN のオン・オフ、ルール上書きの位置）だけです。ノード定義はクライアントの中にはないので、シェルを替えてもノードを再構築する必要はありません。

設定ファイルの3層構造

典型的な config.yaml は3つのセクションに分かれます。基本設定（ポート、モード、ログレベル、DNS）、アウトバウンド定義（proxies と proxy-groups）、分流ルール（rules）です。3つの順序はファイル内で入れ替えられますが、論理関係は固定です。まずどのノードと出口グループがあるかを定義し、次にどのトラフィックをどの出口に流すかを決めます。

mixed-port: 7890
mode: rule
log-level: info

proxies:
  - name: "node-a"
    type: ss
    server: 203.0.113.10
    port: 8443
    cipher: aes-128-gcm
    password: "your-password"

proxy-groups:
  - name: "PROXY"
    type: select
    proxies: ["node-a", "DIRECT"]

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

例の 203.0.113.10 はドキュメント用の予約アドレスです。実際の設定では server と password はサブスクリプションから提供されるため、手書きする必要はありません。このセクションはすでに最小構成で動作する骨組みです。ローカルの 7890 ポートで接続を受け、ルールモードで動作し、手動選択グループが1つ、3つのルールが上から順にマッチします。

本マニュアルとクイックスタートガイドの役割分担

クイックスタートガイドは3ステップの主線です。サブスクリプションのインポート、モードの選択、接続の確認。目標はできるだけ早く動かすことです。本ページは体系的なリファレンスマニュアルで、同じ9つのステージを扱いますが、各ステージで原理、パラメータの意味、境界ケース、トラブルシューティングの分岐まで掘り下げます。最初のインストール時はまずチュートリアルページの主線をたどり、「なぜこう設定するのか」という疑問が出たときに本ページの該当章へ戻ってくるのがおすすめです。

クライアント選定：プラットフォームとメンテナンス状況で絞り込む

3つの判断基準

第一にカーネルです。クライアントが mihomo ベースか、Clash の設定構文と互換性があるかで、どのフィールドを解釈できるかが決まります。オリジナルの Clash カーネルベースのクライアントは新しいプロトコルやルールタイプに追随できず、サブスクリプションに見慣れないフィールドが現れるとエラーになったり黙って無視されたりします。症状としては「サブスクリプションの更新は成功したのにノードが半分になった」という形で現れます。

第二にメンテナンス状況です。クライアントの更新頻度は、新しい OS バージョンへの対応速度を決めます。メンテナンスが終了したクライアントも動作はしますが、OS の更新やカーネルの新機能が出ても修正は入らず、問題が起きたら自力で解決するしかありません。

第三に機能のカバレッジです。差が最も大きいのは3点。TUN モードに対応しているか、複数の設定を素早く切り替えられるか、ルールの上書きとマージに対応しているか。ブラウザのプロキシだけを使うユーザーには1点目は関係ありませんが、ゲームや UWP アプリをプロキシ経由にしたいユーザーは必ず確認が必要です。

デスクトップ：Windows と macOS

Windows では Clash Plus が現在の第一候補で、インストーラーは x64 と ARM64 の両アーキテクチャに対応しています。Clash Verge Rev と FlClash は近い設定管理機能を提供しますが、UI の構成が異なります。Clash Nyanpasu はよりシンプルな UI で、基本機能だけを求めるユーザーに向いています。Clash for Windows はメンテナンスが終了しており、旧環境との互換や過去の設定移行のためのアーカイブ選択肢としてのみ位置づけられます。

macOS でも同様に Clash Plus が第一候補で、Clash Verge Rev と FlClash が代替です。ClashX Meta はメンテナンスが終了しています。そこから移行するユーザーは設定の違いに注意してください。ポリシーグループの命名や DNS セクションの構造は新しいカーネルではより厳格になっており、古い設定の省略記法のフィールドは認識されないことがあります。

モバイル：Android と iOS

Android では Clash Plus、Clash Meta for Android、FlClash がいずれも TUN とアプリ別プロキシに対応しています。アプリ別プロキシはどのアプリをプロキシ経由にし、どれを直結にするかを決めるもので、スマートフォンではデスクトップ以上に実用的です。Surfboard は別の設定フォーマットを使うため、サブスクリプションをインポートする前に、そのフォーマットの出力が提供されているか確認してください。

iOS ではクライアントはシステムの制約を受け、App Store からのみインストールできます。Clash Plus は App Store で提供されており、公式サイトのアドレスは clashplus.io です。設定のインポート方法は他の iOS プロキシツールと同様で、システムの VPN 構成プロファイルを使います。

Linux とサーバー環境

Linux デスクトップディストリビューションでは Clash Verge Rev または FlClash が使え、deb パッケージも rpm パッケージも用意されています。サーバーやルーターには GUI がないため、mihomo カーネルを直接使います。該当アーキテクチャのアーカイブをダウンロードして解凍し、コマンドラインで起動し、systemd ユニットやプロセス監視スクリプトで常駐させます。この方法の利点はリソース消費が最小なこと、代償はすべての設定を手書きする必要があることです。

完全な横並び比較と選定のアドバイスはクライアント選定ガイドにあります。すべてのインストーラーはプラットフォーム別にダウンロードページに整理されており、プラットフォームの入口から該当ブロックへ直接移動できます。選定段階で悩みすぎる必要はありません。同じサブスクリプションはほとんどのクライアントで共通して使えるので、まず1つインストールして使い始め、実際に足りない機能に応じて調整すれば十分です。

インストール：動作環境、権限、初回起動

インストール前に確認する3つのこと

システムバージョン。Windows は 10 1809 以降が必要で、それより古いとシステムプロキシモードしか使えず、仮想ネットワークアダプタドライバと一部のシステムインターフェースが利用できません。macOS はネットワーク拡張機能をサポートする比較的新しいバージョンが必要で、古いシステムでは TUN の認可ができません。Android はブラウザやファイルマネージャーからのアプリインストールを許可する必要があり、一部の ROM ではインストール時に再確認が入ります。Linux ディストリビューションはクライアントが要求する glibc のバージョンを満たす必要があり、古すぎる場合はカーネルのコマンドライン運用を直接使うのがおすすめです。

権限。TUN モードには管理者権限（Windows）または root、ネットワーク拡張の認可（macOS、Linux）が必要です。システムプロキシモードのみなら通常の権限で足ります。インストール段階ではまず TUN を有効にせず、設定のインポートが完了してから有効にすると、2つの変数が同時に動くのを避けられます。

ネットワーク環境。初回起動時はルールセットや GEOIP データベースのダウンロードが必要なことがあり、ネットワークが通らないとクライアントは初期化状態で止まります。利用中のネットワークでアクセスが制限されている場合は、まずクライアントが行う初期化リクエストが遮断されていないか確認し、そのうえでオフライン設定に切り替えるか判断してください。

Windows でのインストール手順

• ダウンロードページの Windows セクションから該当アーキテクチャのインストーラーを選びます。通常の PC は x64、ARM デバイスは ARM64 を選び、アーキテクチャを間違えると非対応の警告が直接表示されます。
• インストーラーを実行します。インストール先はデフォルトのままで問題ありません。
• 初回起動時に管理者権限の要求が表示されたら許可してください。これは TUN モード用の仮想ネットワークアダプタドライバを準備するためです。
• 起動後、トレイアイコンが表示されることを確認します。右クリックメニューにはモード切替、設定管理、終了の3項目が見えるはずです。
• インストール後に起動できない場合：まずシステムが署名のないドライバのインストールを遮断していないか、次にセキュリティソフトが本体プログラムを隔離していないか、最後に旧バージョンの残存サービスプロセスがポートを占有していないかを確認します。

macOS と Linux

macOS は dmg をダウンロードしてアプリケーションフォルダにドラッグします。初回起動時に Gatekeeper に止められた場合は、「システム設定 → プライバシーとセキュリティ」で「このまま開く」を選びます。TUN を有効にするとシステムがネットワーク拡張の認可を求めます。この手順は必ず許可してください。許可しないと TUN がトラフィックを引き受けられません。認可後も反映されない場合は、クライアントを一度再起動して拡張を再読み込みさせてください。

Linux デスクトップディストリビューションでは deb または rpm パッケージを優先し、インストール後はアプリケーションメニューから起動します。一部のクライアントは「UI + サービス」分離アーキテクチャを採用しています。カーネルはサービスとして動作し、UI はローカルインターフェース経由でそれを制御するため、UI に root 権限は不要です。インストール時の案内に従ってサービスコンポーネントを導入してください。サーバー環境では GUI を入れず、mihomo カーネルのアーカイブをダウンロードして解凍し、-d で設定ディレクトリ、-f で設定ファイルを指定して起動します。

モバイルへのインストール

Android は APK をインストールして初回起動すると VPN 権限を要求されます。この権限は TUN モードの基礎で、拒否するとシステムプロキシを手動設定するしかありませんが、モバイルでシステムプロキシを手動設定する体験は快適とは言えません。iOS は App Store からインストールした後、初回接続時に VPN 構成プロファイルの追加を案内されます。画面の指示に従ってシステム設定で許可し、その後クライアントに戻ってサブスクリプションをインポートします。

初回インストールでよくある落とし穴（権限、ポート、システムプロキシの3種類）はブログ「Clash の初回インストールと初期設定」にまとめてあります。インストール後に照合チェックしてみてください。

サブスクリプションのインポート：リンク、ホスト型設定、ローカルファイル

サブスクリプションリンクの本質

サブスクリプションは1つの URL です。クライアントがリクエストすると、YAML 設定またはエンコードされたノードリストが返ります。Clash 系クライアントは Clash フォーマット（YAML）を必要とするため、サービス側が汎用フォーマットを配布している場合は、事前に変換するか、そのフォーマットに対応したサブスクリプション出力を選ぶ必要があります。リンクには通常、識別用のクエリパラメータが付くため、リンク自体が認証情報です。公開で共有したり、スクリーンショットに完全なパラメータを写したりしないでください。

インポートの操作手順

• サブスクリプションリンクを完全にコピーします。クエスチョンマーク以降のパラメータもすべて含めます。
• クライアントの設定またはサブスクリプションページを開き、新しい設定項目を作成します。クライアントによってこの入口の名称は Profiles、サブスクリプション、設定、ノードなどさまざまで、位置は通常サイドバーの最初の項目です。
• リンクを貼り付けて名前を付けます。名前はローカルでの表示にのみ影響し、接続には影響しません。
• ダウンロードまたは更新をクリックし、設定の取得が完了するまで待ちます。この手順でノードリストとルールが同時に取得されるため、ネットワークが不安定なときはもう一度試す必要があるかもしれません。
• この設定を選択し、カーネルに読み込ませます。
• プロキシページに戻り、ノードリストが表示されていることを確認して、任意のノードを1つ選びます。

ホスト型設定とローカル変更の衝突

リモートのサブスクリプションは更新のたびにファイル全体を上書きするため、サブスクリプションからダウンロードした config.yaml を直接編集すると、次回の更新で失われます。これは初心者が最もよく直面する挫折ポイントです。30分かけて書いたルールが一晩で消えてしまいます。対処法は3つあります。

• クライアント標準の上書き・マージ機能を使う。カスタムルールを別の上書きファイルに書き、サブスクリプション更新時に自動でマージさせ、元のサブスクリプションはそのままにします。
• ローカル設定。サブスクリプションの内容をローカルファイルとして保存し、以降は手動で管理します。利点は完全にコントロールできること、代償はノードリストが自動更新されないことです。
• 自前のホスティング。自分で完全な設定を1つ管理し、サブスクリプションのノード部分は proxy-providers で取り込み、ルールとポリシーグループはすべて自分で書きます。

proxy-providers:
  provider-a:
    type: http
    url: "https://example.com/subscribe?token=xxxx"
    interval: 86400
    path: ./providers/provider-a.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300

interval の単位は秒で、86400 は1日に1回更新を意味します。health-check はノードの遅延テストの対象アドレスと頻度を決めます。provider でノードを取り込んだ場合、proxy-groups ではノード名を個別に列挙するのではなく use: ["provider-a"] で参照します。サブスクリプション更新でノードが変わっても、ポリシーグループを書き換える必要はありません。

更新に失敗したときの対処

まずクライアントのログでサブスクリプション取得時のレスポンスコードを確認します。401 や 403 はリンクの失効、パラメータの変更、サービス側による現在の IP の制限が主な原因です。リクエストタイムアウトはローカルからサブスクリプションサーバーまでの区間が通っていないことを意味します。返ってきた内容の解析失敗は、取得したものが Clash フォーマットでない場合で、サービス側がクライアント種別ごとに異なるフォーマットを返している可能性があります。更新後に一部のノードだけが変わっているのは正常な挙動です。サービス側がノードを調整するのは日常的で、対処は不要です。

複数デバイス間で設定を一致させる方法は、ブログ「Clash マルチデバイス設定同期」をご覧ください。3つの方式の適用シーンとメンテナンスコストの比較はそちらに書いてあります。

プロキシモード：ルール、グローバル、ダイレクト、システムプロキシ

3つのモードの役割分担

ルールモード（rule）は rules セクションに従って順にマッチし、ヒットしたルールの出口を使います。日常利用ではこれが既定です。グローバルモード（global）はすべてのトラフィックを現在選択中のノードに流し、ルールを無視します。その価値は切り分けにあります。ルールの書き間違いを疑ったときグローバルに切り替えて接続が正常なら、問題はルール側にあります。ダイレクトモード（direct）はすべてプロキシを通しません。クライアント自体の影響を排除するために使い、ダイレクトでも通らないなら問題はプロキシ経路にはありません。

3つのモードは設定ファイルでは mode フィールドで決まり、クライアントの画面から一時的に切り替えることもできますが、再起動後は設定ファイルの内容が優先されます。

システムプロキシと TUN の違い

システムプロキシは、クライアントが OS のプロキシ設定（Windows のインターネットオプション、macOS のネットワーク環境設定）を書き換える方式で、システムプロキシに従うプログラムにのみ効きます。ブラウザや多くのコマンドラインツールは従いますが、一部のゲーム、UWP アプリ、独自にネットワークスタックを実装したソフトは影響を受けず、トラフィックは直接外に出てしまいます。

TUN モードは仮想ネットワークアダプタを作成し、システムのルーティングテーブルのデフォルトルートをそこへ向けます。これによりすべての IP 層のトラフィックがカーネルに引き受けられ、アプリがシステムプロキシに従うかどうかに左右されません。代償は管理者権限が必要なこと、そして一部の VPN や仮想マシンのネットワークとルートが衝突しうることです。

もう1つの違いは DNS です。システムプロキシモードではアプリの DNS クエリは OS が処理しますが、TUN モードでは DNS もカーネルが引き受けます。これにより Fake-IP と組み合わせてドメイン名ベースのルールマッチが可能になります。詳しくは第7章で展開します。

ポートとコントロールインターフェース

mixed-port は HTTP と SOCKS5 の両プロトコルを同時に提供する、現在推奨される単一の入口です。古い設定では port（HTTP）と socks-port（SOCKS5）の2つのフィールドに分かれていることがあります。external-controller はコントロールインターフェースで、ダッシュボードはこれを通じて接続リストとログを読み取ります。既定では 127.0.0.1 のみをリッスンし、ローカルマシンからしかアクセスできません。LAN 内の他のデバイスからダッシュボードにアクセスしたい場合は、リッスンアドレスを 0.0.0.0 に変更し、secret を設定してください。そうしないとコントロールインターフェースを LAN 全体に開放するのと同じです。

mixed-port: 7890
allow-lan: false
external-controller: 127.0.0.1:9090
secret: "your-password"
mode: rule
log-level: info

allow-lan は LAN 内のデバイスが本機のプロキシ経由でインターネットに出られるかどうかを制御します。external-controller とは別物で、前者が開くのはプロキシポート、後者が開くのはコントロールインターフェースです。

選択順序のすすめ

まずシステムプロキシ + ルールモードで動かし、ノードが使えること、ブラウザが正常にアクセスできることを確認します。プログラムに効かないケースが出てから TUN を有効にします。最初から TUN を有効にしないでください。問題が起きたときにノード、DNS、仮想ネットワークアダプタ、ルーティングテーブルの4つを同時に疑う必要があり、切り分けのコストが格段に上がります。ノードに接続できないときの7つの確認ポイントはブログ「Clash ノードがタイムアウトして接続できない」にまとめてあります。

ルール分流：rules の構文、ポリシーグループ、優先順位

マッチの仕組み：上から順に、ヒットした時点で確定

カーネルは rules 配列の先頭から順に照合し、最初にヒットしたルールがその接続の行き先を決め、以降のルールは関与しません。つまり配列の順序がそのまま優先順位です。範囲が最も狭く明確なルールを前に、広い範囲をカバーするフォールバックを最後に置きます。MATCH は必ず最後の1条にしてください。前に書くとそれ以降のすべてのルールが無効になります。これはルールの書き間違いの中で最も深刻な結果を招くものです。

よく使うルールタイプ

• DOMAIN：ドメインを完全一致でマッチし、書いたその1つだけにヒットします。
• DOMAIN-SUFFIX：ドメインのサフィックスをマッチし、example.com は a.example.com と b.example.com の両方にヒットします。
• DOMAIN-KEYWORD：ドメインにキーワードが含まれればヒットします。範囲が広く誤爆しやすいため、使用は慎重に。
• IP-CIDR：宛先 IP レンジをマッチします。純粋な IP ルールは DNS 解決結果を得てからでないと判定できないため、no-resolve を付けるとルールマッチのためだけに余分な解決を行うのを避けられます。
• GEOIP：IP の帰属国・地域でマッチします。中国本土のアドレスを直結させるのによく使われ、通常はドメインルールの後に置きます。
• PROCESS-NAME：接続を発したプログラム名でマッチします。デスクトップでは使えますが、モバイルでは通常サポートされません。
• RULE-SET：外部のルールセットファイルを参照し、数百〜数千条のルールを独立したファイルで管理します。
• MATCH：フォールバックルールで、残りのすべての接続にマッチします。必ず最後の1条にします。

ポリシーグループ：ルールが指す出口

proxy-groups はルールが指せる出口グループを定義します。グループにはノードも他のグループも入れられます。よく使う4タイプ：select は手動選択で、画面でクリックしたものが使われます。url-test はグループ内のノードを定期的に速度測定し、遅延が最も低いものを自動選択します。fallback は順番に最初に使えるノードを取ります。load-balance は複数ノードに接続を分散します。

グループはネストできます。よくある3層構造は「手動選択グループ → 自動速度測定グループ → 個別ノード」です。日常は自動速度測定グループを使い、指定したいときは手動グループで切り替えます。

proxy-groups:
  - name: "PROXY"
    type: select
    proxies: ["AUTO", "DIRECT"]
  - name: "AUTO"
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies: ["node-a", "node-b"]

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - DOMAIN-KEYWORD,analytics,DIRECT
  - IP-CIDR,203.0.113.0/24,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

tolerance は切り替えのしきい値（ミリ秒）です。新しいノードの遅延が現在のノードよりこの値以上に低い場合にのみ切り替えるため、2つのノードの遅延が近いときに頻繁に行き来するのを防ぎます。interval は速度測定の間隔（秒）で、短くしすぎると低スペックのデバイスが常時測定リクエストを走らせることになります。

よくある書き間違い

• MATCH を途中に書く：それ以降のすべてのルールがデッドコードになります。
• GEOIP を具体的なドメインルールより前に置く：本来プロキシ経由にすべきドメインが中国本土のアドレスと判定され直結されます。
• IP-CIDR に no-resolve を付けない：接続ごとに DNS 解決が1回走り、遅延が増えます。
• ルールが存在しないポリシーグループ名を指している：カーネルがエラーを出すか接続が拒否され、ログにはっきりしたヒントが出ます。
• タイプ名の大文字小文字を混在させる：domain-suffix は認識されません。タイプ名は大文字で書く必要があります。
• ルールセットファイルのパスを間違える：起動時に黙ってスキップされ、そのルールセットがカバーするドメインがすべてフォールバックに流れます。

1条ずつの解説とより多くの記述例はブログ「Clash カスタムルールの構文と優先順位」をご覧ください。

TUN モード：仮想ネットワークアダプタ、DNS、Fake-IP

TUN が行うこと

有効にすると、カーネルは仮想ネットワークアダプタ（Windows では Wintun、macOS と Linux では utun または tun）を作成し、システムのデフォルトルートをそこへ向けます。アプリが送り出したパケットはまず仮想アダプタに届き、カーネルが読み取ってルールに従って処理し、直結かプロキシ経由かを決めます。IP 層で動作するため、アプリがシステムプロキシ設定に従うかどうかに依存せず、ゲーム、UWP アプリ、独自にネットワークスタックを実装したソフトも引き受けられます。

代償も同じ層から来ます。ルーティングテーブルが書き換えられるため、VPN、仮想マシン、複数ネットワークアダプタの環境と衝突する可能性があります。

重要な設定項目

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

stack はユーザー空間プロトコルスタックの実装を決めます。system は性能が良いが互換性は普通、gvisor は互換性が良いがスループットはやや低い、mixed はカーネルが状況に応じて自動選択します。auto-route はカーネルにルーティングテーブルを自動で書かせます。auto-detect-interface は物理的な出口ネットワークアダプタを自動識別します。この2項目は複数アダプタのマシンで特に重要で、無効にすると戻りのトラフィックが誤ったアダプタを通り、接続はできるが極端に遅い、あるいは頻繁に切断するという症状が出やすくなります。dns-hijack は 53 番ポート宛ての DNS クエリをカーネルが処理するようハイジャックします。これが TUN モードで DNS を漏らさない前提条件です。

DNS と Fake-IP

TUN モードでは DNS を必ずカーネルに処理させる必要があります。そうしないとアプリが自分で実 IP を解決してしまい、ルールのドメインマッチが機能しません。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "+.pool.ntp.org"
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

Fake-IP の動作：カーネルは DNS クエリを受け取ると即座に 198.18.x.x レンジの偽アドレスを返し、同時にその偽アドレスがどのドメインに対応するかを記録します。アプリがその偽アドレスに接続すると、カーネルはマッピングテーブルからドメインを取り出し、ドメインでルールをマッチします。利点は2つ。ルールマッチが常にドメイン名ベースになり、アプリが先に解決してから接続する場合でも対応できること。実際の解決を待つ時間が省け、初回接続が速くなることです。

fake-ip-filter に入れたドメインは Fake-IP を通さず、実アドレスを返します。LAN 内のデバイス名、NTP タイムサーバー、実 IP を必要とする一部の LAN サービスは必ず入れてください。そうしないと、Web ページは開けるのに LAN 内のデバイスに接続できない、といった不可解な現象が起きます。nameserver にはローカルから到達できる DNS サーバーを指定し、すでにプロキシ経由になっているアドレスは指定しないでください。解決リクエストが遠回りして自分に戻り、ループになります。

よくある問題

• 有効にしたらまったくインターネットに出られない：まずログで仮想ネットワークアダプタが作成されたか、次に auto-detect-interface が物理アダプタを正しく識別したか、最後に他の VPN がルートを奪っていないかを確認します。
• 一部のアプリが異常動作する：それらを fake-ip-filter に追加するか、ルールで直結を指定します。
• Windows で UWP アプリが効かない：UWP アプリはアプリコンテナ内で動作するため、ループバック除外の有効化が必要です。クライアントには通常そのためのスイッチが用意されています。
• 仮想マシンとの衝突：仮想マシンの仮想ネットワークアダプタが TUN のルートルールの影響を受けるため、そのアダプタを除外リストに入れるか、時間帯を分けて使います。

ノードタイムアウトの完全な切り分け手順はブログ「Clash ノードがタイムアウトして接続できない」をご覧ください。

日常メンテナンス：更新、ログ、マルチデバイス同期

サブスクリプションの更新

更新頻度はサービス側のノード変動頻度によりますが、1日1回が一般的な設定です。更新後はクライアントが設定を再読み込みするため、進行中の接続は一時的に切断されます。ノードリストが長期間変わらない場合は、まず手動で更新を1回実行し、次にログのレスポンス内容を確認します。更新は成功しているのにノードが変わらないなら、サービス側が実際に調整していないということです。

ログと接続パネル

log-level は silent、error、warning、info、debug の順に詳細になります。問題を切り分けるときは一時的に debug に上げ、接続確立時にカーネルが実際にどう判断したか（どのルールにヒットし、どの出口を通り、解決に失敗していないか）を確認します。日常は info のままで十分です。debug はログ量が大幅に増え、長時間有効にすると低スペックのデバイスを遅くします。

external-controller が提供するインターフェースはダッシュボードから読み取れ、各接続のヒットしたルール、アウトバウンドノード、アップロード・ダウンロードのバイト数を確認できます。ルールが期待どおり効いているかの判断は、ログよりも接続パネルのほうが直接的です。該当の接続を見つけ、ヒットしたルール番号と出口グループ名を、自分が書いたルールと照合します。

マルチデバイス

サブスクリプションリンクの同期：すべてのデバイスが同じリンクをインポートし、ノードリストが自動的に一致します。ノード中心でローカルのカスタマイズが少ないケースに向きます。代償は各デバイスのルール設定が独立していること、1か所を変えても他のデバイスには同期されないことです。

自前の設定ホスティング：自分で完全な設定を1つ管理し、すべてのデバイスが同じアドレスから取得するため、ルールとポリシーグループが完全に一致します。複数デバイスでルールが複雑なケースに向きますが、メンテナンスコストは最も高く、設定に問題があるとすべてのデバイスに影響します。

手動でのエクスポート・インポート：設定ファイルを LAN やクラウドストレージ経由で他のデバイスに渡します。頻繁に変わらないケースに向き、前述2方式のバックアップ手段としても適しています。

リソース消費と安定性

ルールの件数は、接続ごとのマッチにかかる時間に直接影響します。数千条のルールはデスクトップではほとんど体感できませんが、ルーターなどの低スペックデバイスでは規模を抑え、大きなルール群は RULE-SET に分けて必要時に読み込ませます。GEOIP データベースはカーネルの更新に伴って更新されるため、手動で差し替える必要はありません。メモリ使用量はアクティブな接続数と DNS キャッシュの規模に関係します。長時間運用後にメモリが増え続ける場合は、まず大量の url-test グループが頻繁に速度測定していないか、ログレベルが debug のままになっていないかを確認します。

マルチデバイス同期3方式の完全な比較はブログ「Clash マルチデバイス設定同期」をご覧ください。

応用ロードマップ：カーネル機能、自作設定、トラブルシューティング手法

mihomo がもたらした変化

mihomo はオリジナルの Clash をベースに、インバウンド種別、ルール種別、DNS 機能を拡張しました。より多くのインバウンドプロトコル、より多くのルールマッチ軸（プロセス、ルールセット、論理結合）、より細かい DNS ポリシー、より完全な TUN 実装などです。サブスクリプションにオリジナルカーネルが認識しないフィールドが現れたら、mihomo ベースのクライアントに変えれば解析できます。オリジナルの Clash カーネルはメンテナンスが終了しているため、長期的には mihomo 系クライアントを起点にするのがおすすめです。

サブスクリプションの利用者から設定の管理者へ

応用の第一歩は、サブスクリプションを完全な設定ではなくノードの供給元として扱うことです。やり方は第4章ですでに示しました。proxy-providers でノードを取り込み、ルール、ポリシーグループ、DNS はすべて自分で書きます。利点は、サービス提供元を変えるときに provider のアドレスを変えるだけで済み、ルール体系に手を入れずに済むことです。ルールはサブスクリプション側の既定ルールに縛られず、自分の使い方に合わせて細かく調整できます。

第二歩はルールセットのメンテナンス方法を理解することです。大きなルール群は RULE-SET が参照する外部ファイルに分け、定期的に更新し、メイン設定は簡潔に保ちます。ルールセットの利点は更新時にメイン設定に影響しないこと、欠点はファイル依存が1層増え、パスを間違えると黙って無効になることです。

第三歩は設定をバージョン管理に載せることです。変更のたびにバックアップを残し、変更内容を記録します。設定に問題が起きたとき素早くロールバックでき、1行ずつ見比べるよりはるかに速いです。

再利用できるトラブルシューティングの順序

1. サブスクリプション：直近の更新が成功したか、ノードリストが空でないか。
2. ノード：グローバルモードに切り替えて1つのノードを単独でテストし、ルールの要素を排除します。
3. DNS：Fake-IP が有効か、filter が誤爆していないか、解決が正常か。
4. ポート：ローカルポートが他のプログラムに占有されていないか。
5. システムプロキシまたは TUN：オン・オフの状態が実際の期待と一致しているか。
6. ルール：接続パネルに見えているのが期待どおりのポリシーグループか。
7. ログ：ここまでの6ステップの観察とログを照合し、本当に問題のある層を特定します。

この順序の価値は、各ステップで1種類の要素を排除していくことにあります。すべての段階を同時に疑うのではなく。7ステップを終えてもつながらない場合は、問題はより下の層（物理ネットワーク、サーバー側、OS のファイアウォール）にあります。ログを持ってサービス提供元やクライアントのコミュニティに相談するとよいでしょう。

さらに深く進む方向

• カーネル設定ドキュメント：各設定項目のデフォルト値を理解することは、推奨値を覚えるよりも役に立ちます。
• ルールセットのエコシステム：よく使われるルールセットのメンテナンス方法と更新ペースを知り、活発にメンテナンスされている配布元を選びます。
• ネットワークの基礎：DNS 解決の経路、ルーティングテーブル、TCP ハンドシェイク。トラブルシューティングで最も役立つ3つの知識です。
• 自動化：スクリプトで設定のバージョンとルール更新を管理し、変更を記録に残します。

カーネルの違いの具体的な比較はブログ「mihomo カーネルとオリジナル Clash の違い」、初回インストールのチェックリストはブログ「Clash の初回インストールと初期設定」をご覧ください。まずクライアントの横並び比較を見たい場合はクライアント選定ガイドへ、決まったらダウンロードページで該当プラットフォームのインストーラーを取得し、最初の設定はクイックスタートガイドに沿って一通り進めれば十分です。