Clash使い方ガイド：サブスクリプション・分岐・TUN設定

基本概念：カーネル、クライアント、設定ファイルを区別する

Clashは単一のインストールパッケージではありません

日常的に「Clash」と呼ぶものは、プロキシカーネル、GUIクライアント、またはClash形式の設定を採用するツール群全体を指す場合があります。カーネルは設定の読み込み、プロキシ接続の確立、ルール照合、トラフィック転送を担当します。GUIクライアントは、設定、ログ、プロキシグループ、システムプロキシ、更新操作をクリックできる画面にまとめます。mihomoは現在のClashエコシステムで広く使われている後継カーネルで、多くの新しいクライアントがプロトコル、ルール形式、TUN、DNS機能を提供するために採用しています。この関係を理解することが重要です。同じサブスクリプションでもクライアントによってボタンの位置は異なりますが、カーネルが処理するプロキシノード、プロキシグループ、ルールの考え方は概ね共通しています。

設定ファイルは通常YAML形式で、ポート、プロキシノード、プロキシグループ、ルール、DNS、TUN設定などを含みます。サブスクリプションはリモート設定の取得元です。クライアントがサブスクリプションURLを保存し、必要に応じてサービス提供元が生成した設定をダウンロードし、カーネルに読み込ませます。サブスクリプションURL自体は「接続ボタン」ではなく、ノード名も最終的な出口を意味しません。リクエストはまずルールに照合され、指定されたプロキシグループによって特定のノードまたはDIRECTが選ばれます。トラブルシューティングでは、リモートサブスクリプションを取得できるか、設定をカーネルが解析できるか、トラフィックが利用可能なポリシーへルールどおり送られるかを分けて確認してください。

リクエストがClashを通過する流れ

ブラウザでWebページにアクセスする場合を例にすると、ブラウザはまずリクエストをシステムのネットワークスタックへ渡します。システムプロキシが有効なら、システムプロキシに対応するアプリはHTTPまたはSOCKSリクエストをクライアントの待受ポートへ送ります。TUNを有効にしている場合は、より多くのIPトラフィックが仮想ネットワークインターフェースに入ります。カーネルは宛先ドメインまたはアドレスを取得し、ルールリストの先頭から照合します。マッチしたリクエストは指定されたポリシーに渡されます。ポリシーには特定のノード、手動選択、自動速度測定、フェイルオーバー、DIRECT、拒否などがあります。最後にノードが対応プロトコルでリモートサーバーとの接続を確立し、返されたデータが同じ経路を戻ってアプリへ渡されます。

この流れから、よくある現象も説明できます。ブラウザは正常なのにゲームだけ接続できない場合、そのアプリがシステムプロキシを使っておらず、TUNが必要な可能性があります。サブスクリプション更新は成功するのにすべてのサイトが開かない場合、設定の取得はできており、問題はノード、ポリシー、ローカルでのトラフィック取り込みにあることが多いです。特定のドメインだけ異常なら、ルール、DNS、対象サービス自身の制限が疑われます。クライアントを何度も削除するのではなく、「サブスクリプション取得、設定解析、トラフィック取り込み、ルール照合、ノード接続、DNS解決」のどの層に障害があるかを先に特定してください。

クライアントの選び方：プラットフォーム、カーネル、用途で判断する

現在も保守されているGUIクライアントを優先する

クライアントを選ぶときは、まずOSを確認し、次に保守状況、カーネルの種類、必要な機能を見ます。本サイトのダウンロード一覧ではClash Plusを最初に紹介しています。Windows、macOS、Android、iOSに対応し、複数のプラットフォームで似た操作感を求めるユーザーに適しています。WindowsとmacOSではClash Verge Rev、FlClashも選択できます。WindowsにはClash Nyanpasuもあります。AndroidではClash Meta for Android、FlClash、Surfboardを利用できます。Linuxのデスクトップ環境ではClash Verge RevまたはFlClashが使えます。Clash for WindowsとClashX Metaは保守が終了しているため、古い設定の移行用にとどめ、新規インストールの標準にはしないでください。

「見慣れた画面であること」だけが判断基準ではありません。TUN、プロセスルール、ルールセット、新しい設定フィールドが必要な場合は、使用するクライアントのカーネルがそれらに対応しているか確認してください。mihomoを採用するクライアントは現在の設定エコシステムに適していることが多いものの、同じmihomoクライアントでも権限の要求、設定の保存場所、トレイメニュー、システムプロキシの実装は異なる場合があります。サービスが特定のフィールドに依存する設定を生成する場合は、サービスの説明を優先してください。フィールドが認識されないときは、設定全体を削除・改変する前にカーネルの互換性を確認します。

デスクトップ、モバイル、サーバーでは使い方が異なる

デスクトップクライアントは通常、システムプロキシとTUNの両方を提供します。システムプロキシは設定が簡単で、ブラウザ、メッセージアプリ、システムプロキシに従うソフトに適しています。TUNはカバー範囲が広く、システムプロキシを参照しないアプリに向いています。Androidクライアントは通常、システムVPNインターフェースでトラフィックを取り込み、有効にするとVPN状態の表示が出ます。ほかのVPN系アプリが同時に動作している場合、同じインターフェースを同時に使用できないことが一般的です。iOS版もシステムのネットワーク拡張機能に依存し、設定入口やバックグラウンド動作はOSの制約を受けます。モバイルではバッテリー最適化、バックグラウンド制限、アプリ単位のプロキシにも注意してください。

サーバー、ソフトルーター、コンテナ環境ではmihomoカーネルを直接実行する方法が適しています。GUIのためにデスクトップ依存関係を追加する必要はなく、通常は設定ファイル、コマンドライン引数、外部コントロールインターフェースで管理します。ただしカーネルパッケージは、そのまま使えるデスクトップクライアントではありません。設定パス、実行ユーザー、サービス管理、ログローテーション、ファイアウォールルールを自分で用意する必要があります。個人PCでWebを閲覧するだけならGUIクライアントを優先し、ゲートウェイ転送、透過ルーター、自動デプロイが明確に必要な場合にのみカーネル単体の構成を選びます。

システムアーキテクチャとパッケージ形式を確認する

Windowsの一般的なデスクトップPCはx64を使用します。ARMプロセッサー搭載機でのみARM64が必要です。macOSでは「このMacについて」でチップの種類を確認できます。Apple Siliconはarm64、Intelプロセッサーはx64に対応します。Androidのインストールパッケージにはarm64、arm、ユニバーサル版などがあり、近年の主流スマートフォンはarm64が多いものの、古い端末や特殊なエミュレーターでは実際のアーキテクチャに合わせて選びます。Linuxではアーキテクチャに加え、deb、rpm、圧縮パッケージも区別します。DebianとUbuntuではdeb、Fedora系ではrpmが一般的で、カーネル単体の圧縮パッケージは手動デプロイが必要です。

対応クライアント一覧、各プラットフォームへの入口、保守状況はダウンロードページにまとめています。古いクライアントに重要な設定が残っている場合は、移行前に設定をエクスポートするか、サブスクリプションURL、プロキシグループの選択、自作ルールを記録してから新しいクライアントをインストールしてください。クライアントごとにデータベースや設定ディレクトリは通常共用できないため、新しいクライアントでサブスクリプションを再導入し、カスタマイズを一つずつ戻すのが安全です。

インストールと初期設定：復旧できる基盤を整える

インストール前に競合状態を整理する

クライアントをインストールする前に、動作中のプロキシ、VPN、旧Clashクライアントを終了し、システムプロキシが残っていないことを確認してください。Windowsではシステムのネットワーク設定で手動プロキシが有効になっていないか確認します。macOSでは現在のネットワークサービスのプロキシ設定でHTTP、HTTPS、SOCKS項目を確認します。残留プロキシによって、新しいクライアントを起動していないのにブラウザが存在しないローカルポートへリクエストを送り、すべてのWebページが開けなくなることがあります。この場合、問題はインストールパッケージではなく、旧プログラムの終了後にシステムプロキシが復元されていないことです。

デスクトップへのインストールが完了したら、まずクライアントを起動しますが、すぐにすべての高度な機能を有効にしないでください。画面が正常に表示され、カーネルが起動し、ログにエラーが繰り返し出ていないことを確認してからサブスクリプションを導入します。TUNを初めて起動すると、Windowsでは管理者権限の要求や仮想ネットワークコンポーネントのインストールが行われる場合があります。macOSではネットワーク拡張の許可やシステム認証情報を求められることがあります。権限は機能を実際に有効化するときだけ与えてください。権限を拒否してもシステムプロキシは使えることが多いですが、TUNで仮想インターフェースを作成することはできません。

設定ディレクトリと自動起動の方針を先に決める

GUIクライアントは通常、設定、サブスクリプションのインデックス、カーネルファイル、ログをユーザーディレクトリに保存します。プログラムディレクトリと設定ディレクトリを混同しないでください。アプリをアンインストールしてもユーザー設定が削除されるとは限らず、上書きインストールでも設定が初期化されるとは限りません。異常が起きた場合は、まずクライアントが提供するリセット、設定の切り替え、キャッシュ削除機能を使います。設定データベースの破損を確認した場合に限り、バックアップ後の設定ディレクトリ削除を検討してください。ユーザーディレクトリを無計画に消すと、サブスクリプションURL、スクリプト、自作ルール、プロキシグループの選択まで失う可能性があります。

「OS起動時に起動」と「起動時にシステムプロキシを有効化」は別の設定です。前者はクライアントを起動するだけですが、後者はOSのプロキシ設定を変更します。モバイルワーク用の端末ではクライアントの自動起動を有効にしても構いませんが、数回再起動して動作を確認してから、ネットワークの自動取り込みを有効にするか判断してください。Web認証が必要な公共ネットワークを頻繁に使う端末では、自動プロキシによって認証ページが表示されないことがあります。その場合はシステムプロキシを一時停止して認証を完了し、その後接続を戻します。TUNの自動起動も、基本設定が安定してから有効にしてください。起動時の権限やDNSの異常でネットワーク全体に影響するのを防げます。

ポート設定は役割を明確にする

Clash設定でよく使うポートには、HTTPポート、SOCKSポート、混合ポートがあります。混合ポートは同じ待受ポートでHTTPとSOCKSのリクエストを受け付けられるため、個人端末の多くの用途に適しています。ポート番号は他のプログラムに使われていなければよく、「速度」のために頻繁に変更する必要はありません。LAN接続を許可すると、同じネットワーク上の他の端末が待受ポートへアクセスできる可能性があります。共有が本当に必要な場合だけ有効にし、待受アドレス、アクセス制御、OSのファイアウォールで接続元を制限してください。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false

external-controller: 127.0.0.1:9090

上記の基本設定例は、混合ポートを有効にし、ローカルホストからのみアクセスを許可し、ルールモードを使用し、コントロールインターフェースをローカルに限定するものです。クライアントによってはGUIからこれらのフィールドを生成するため、手動編集前に保存時の上書き有無を確認してください。コントロールインターフェースはGUIとカーネルの通信に使うもので、信頼できないネットワークへ直接公開してはいけません。ログレベルは通常の利用ならinfoで十分です。debugは診断情報が増えるため短時間の調査に向きますが、長期間有効にするとログが肥大化し、重要な情報を見つけにくくなります。

最小限の動作確認でインストールを検証する

基本確認は決まった順序で行います。まずカーネルが実行中であることを確認し、次に利用可能な設定を1つ導入します。プロキシグループからノードを選び、システムプロキシを有効にして、最後にブラウザで通常のWebページへアクセスします。失敗した場合は、クライアントの接続記録とログを確認します。接続記録がまったくなければ、トラフィックがクライアントに入っていません。記録はあるもののDIRECTなら、ルールがDIRECTにマッチしています。プロキシ記録があるのにハンドシェイクに失敗するなら、ノード接続またはネットワーク環境に問題があります。この最小ループを完了してからTUN、DNSハイジャック、スクリプト、複雑なルールを有効にすると、トラブルシューティングが大幅に容易になります。

サブスクリプションの導入と更新：リモート設定を一通り管理する

サブスクリプションURL、設定ファイル、ノードURLの違い

サブスクリプションURLは通常、サーバーが生成した設定を返します。複数のノード、プロキシグループ、ルール、DNS設定を含む場合があります。単一ノードのURLは1つのプロキシノードだけを記述するもので、完全な分岐構成を自動で提供することはありません。ローカルYAMLファイルはある時点で保存した静的設定で、リモートの変更には自動追従しません。導入前に、手元の内容の種類を確認してください。クライアントがURL入力を求める場合はHTTPSで始まるサブスクリプションURLを入力します。ファイルから導入する場合は完全なYAMLを選びます。単一ノードのURLしかない場合は、クリップボード解析に対応するクライアントを使うか、既存設定へ手動で追加します。

サブスクリプションURLは設定へアクセスする認証情報に相当するため、スクリーンショット、フォーラム、公開リポジトリに載せないでください。クライアントは通常、このURLをローカルの設定データベースに保存します。複数端末で同期する場合は、各端末に個別にサブスクリプションを導入するか、サービス提供元の集中管理機能を使ってください。サブスクリプションURLを含む設定ファイルを公開同期フォルダへ置いてはいけません。サンプルURLにはテスト用ドメインを使用します。例：

https://example.invalid/api/profile/clash?token=xxxx

正しい導入手順

クライアントで「サブスクリプション」「設定」「Profiles」などのページを開き、URLから設定を新規作成します。リンクを貼り付け、識別しやすい名前を付けてください。更新間隔は設定の変化頻度に合わせます。日常利用では数分おきに更新する必要は通常ありません。保存後に一度手動更新を行い、クライアントに設定名、更新日時、プロキシグループなどが表示されることを確認します。「追加済み」と表示されるだけでは不十分です。その設定へ切り替えて、カーネルを再読み込みします。クライアントによっては「サブスクリプションをダウンロード」と「設定を有効化」が別操作です。更新しただけで切り替えなければ、古い設定が実行され続ける場合があります。

導入後すぐに古い設定を削除しないでください。まず主要なプロキシグループが存在するか、ルールモードを選べるか、よく使うノードが表示されるかを確認してから接続テストを行います。新しい設定が安定したら、短期間のロールバック用に古い設定を残してもよいでしょう。複数の設定を併用する場合は「日常用サブスクリプション」「ローカルルール検証」など明確な名前を付け、すべてをconfigやdefaultにしないでください。設定を切り替えるとプロキシグループとルールも変わります。古いプロキシ選択を新しい設定へ引き継げないことがあるため、切り替え後は出口グループを再確認してください。

更新に失敗したら層ごとに切り分ける

サブスクリプション更新に失敗したら、まずエラーの種類を確認します。タイムアウトはクライアントがサブスクリプションサーバーへ到達できないことを示す場合があります。証明書やシステム時刻のエラーはHTTPS接続に影響します。未認証の応答はURLの期限切れやアクセス条件の変更を示すことがあります。ダウンロードは成功したのに解析に失敗する場合、返された内容が有効な設定ではない可能性があります。Webページのエラー、文字コードの異常、現在のカーネルが認識しないフィールドなどが原因です。まずアクセス可能なブラウザ環境でURLを開き、内容を取得できるか確認します。ただし返された内容を公開してはいけません。ブラウザでは取得できてクライアントだけ失敗する場合は、更新時の通信がプロキシ、DIRECT、現在のプロキシのどれを使う設定になっているか確認してください。

「プロキシ経由でサブスクリプションを更新」するときによくある循環があります。現在の設定にあるノードがすべて無効なのに、更新も現在のプロキシ経由で行うため、新しい設定を取得できません。この場合は一時的にDIRECTで更新するか、まだ使える予備設定から更新します。反対に、現在のネットワークからサブスクリプションサーバーへ直接接続できない場合は、利用可能なプロキシ経由で更新します。クライアントによって更新経路の名称は異なるため、サブスクリプション設定、全般設定、ネットワーク設定を確認し、同じURLを何度も登録し直さないでください。

自動更新にはロールバック用の余地を残す

起動時の自動更新は、設定が安定していて端末のネットワークも信頼できる場合に適していますが、唯一の保守手段にしてはいけません。リモート設定の生成に一時的な失敗があると、利用可能な設定が異常な内容に置き換わる可能性があります。最近正常に使えた設定を残し、適切な更新間隔を設定したうえで、重要な外出やネットワーク切り替えの前に手動更新とテストを行うのが安全です。自分で管理するローカル上書きルールがある場合は、サブスクリプション更新で変更内容が上書きされないことを確認してください。クライアントが上書き、マージ、スクリプトに対応しているなら、自作内容は毎回置き換えられるサブスクリプションファイルへ直接書かず、独立した層に配置します。

プロキシモード：ルール、グローバル、DIRECTの選び方

日常利用のデフォルトはルールモード

ルールモードでは、リクエストの宛先を順に確認し、ドメイン、IP、プロセス、ルールセットに応じて異なるポリシーへトラフィックを渡します。一般的な設定では、ローカルネットワークやプロキシ不要の宛先をDIRECTにし、特定の宛先をプロキシグループへ送り、最後のフォールバックルールで未マッチのリクエストを処理します。利点は「最速ノードを自動選択すること」ではなく、トラフィックの種類ごとに異なる経路を使えることです。最終的なノードは、マッチしたプロキシグループが決めます。多くの日常用途では、アクセス範囲、LANサービス、アプリごとの接続要件を両立できるルールモードを維持してください。

ルールモードで「一部のサイトは正常だが、一部は異常」になっても、すぐにグローバルへ変更しないでください。まず接続記録から対象リクエストを見つけ、マッチしたルールとポリシーを確認します。誤ってDIRECTになっているなら、より正確なドメインルールを追加します。誤ったプロキシグループへ送られているなら、ルールの宛先またはグループ選択を調整します。ドメインが表示されずIPだけの場合は、DNSモード、スニッフィング、アプリがアドレスへ直接接続していないかを確認します。グローバルモードは診断に使えます。グローバルに切り替えると復旧するなら、ノードは使える可能性が高く、問題はルールまたはDNSに集中しています。グローバルでも失敗するなら、ノードとトラフィックの取り込みを優先して確認します。

グローバルモードは「性能強化モード」ではない

グローバルモードでは通常、カーネルに入ったすべてのトラフィックを同じグローバルプロキシグループへ渡し、通常の分岐ルールによる経路選択を行いません。ノードの短時間テスト、ルールでまだ対応していない宛先への一時アクセス、すべての通信を同じ経路にしたい場合に適しています。グローバルモードにしても、システムプロキシを使わないアプリが自動的にClashへ入るわけではなく、OSの権限も回避できません。ルールモードであるアプリの接続記録がまったくない場合、グローバルに切り替えても通常は解決しません。その場合はシステムプロキシ、アプリのプロキシ設定、TUNを確認します。

グローバルモードを長期間使うと、ローカルサービス、プリンター、LAN機器、本来DIRECTにすべき業務通信までプロキシを通ることがあります。設定によってはLANアドレスを特別扱いしますが、すべてのクライアントが同じ動作をするとは限りません。ルーター管理画面、LANストレージ、開発環境へアクセスする際に経路が遠回りになるなら、ルールモードへ戻し、ローカルセグメントをDIRECTとして残してください。グローバルモードの出口は「GLOBAL」プロキシグループの現在の選択に依存し、一覧の先頭ノードが自動的に使われるわけではありません。

DIRECTモードは復旧と原因特定に使う

DIRECTモードでは、カーネルに入ったトラフィックをプロキシノードへ通しません。ネットワーク認証、サブスクリプションの直接更新、対象がローカルネットワークから到達可能かの確認、通常の通信の一時復旧などに使います。クライアントを終了することとは完全に同じではありません。クライアントはシステムプロキシやTUNによる取り込みを維持しつつ、転送動作だけをDIRECTに変える場合があります。システムプロキシの残留を調べるときは、DIRECTモードと取り込みを完全に停止した状態の両方をテストしてください。DIRECTでは使えるのにクライアント終了後は使えない場合、システムDNS、プロキシ設定、ネットワークインターフェースの状態が戻っていない可能性があります。

モード切り替え後の確認方法

モードを切り替えたら、新しいリクエストを発生させて確認します。以前から確立している接続だけを見てはいけません。ブラウザは既存接続を再利用することがあり、アプリもDNSキャッシュを保持する場合があります。新しいプライベートウィンドウを開く、対象を再読み込みする、アプリを短時間再起動するなどしてテストしてください。その後、接続一覧で新しいリクエストがどのモードとポリシーにマッチしたかを確認します。クライアントに接続のクリア機能があれば、切り替え後に古い接続を閉じても構いませんが、カーネルを何度も再起動する必要はありません。「モード、マッチしたルール、プロキシグループ、具体的なノード、エラー内容」の5項目を記録すると、「開く・開かない」だけを記録するより差異を見つけやすくなります。

モードを選ぶときは、「プロキシモード」と「トラフィックの取り込み方式」も区別してください。ルール、グローバル、DIRECTはカーネルに入った後の処理ロジックを決めます。システムプロキシとTUNは、どのトラフィックをカーネルへ入れるかを決めます。この2つの軸は独立しています。TUNとルールモードを組み合わせればより多くのアプリを処理できますが、システムプロキシとグローバルモードの組み合わせではシステムプロキシに従うソフトしか対象になりません。これを理解すれば、一見矛盾した現象も整理できます。

ルール分岐：マッチ順序とプロキシグループ設計

ルールは上から順に照合され、最初にマッチした時点で停止する

Clashのルールリストには明確な順序があります。リクエストは1行目から確認され、マッチするとそのルールが指定するポリシーを直ちに使い、下のルールには進みません。そのため、範囲が限定されたルールを上に置き、広いルールセットや最終フォールバックルールを後ろに置くのが一般的です。広範なドメインサフィックスやIP範囲を前に置くと、後ろの精密なルールは機能する機会を失います。ルールを調べるときは、設定内にそのルールが存在するかだけでなく、より広いルールの前後どちらにあるかも確認してください。

よく使われるルール形式には、完全一致ドメイン、ドメインサフィックス、ドメインキーワード、IPネットワーク、送信元アドレス、宛先ポート、プロセス名、ルールセット参照があります。ドメインルールは、カーネルが宛先ドメインを取得できることが前提です。リクエストがIPとしてしか現れない場合、ドメインルールはマッチしないことがあります。IPルールでは、解決結果とIPv4・IPv6の違いも考慮します。プロセスルールはデスクトップ環境で有効ですが、OSの権限やクライアントの実装に左右されるため、重要な分岐すべてをプロセス識別に依存しないでください。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,Proxy
  - DOMAIN-KEYWORD,media,Media
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DST-PORT,22,Direct-or-Proxy
  - MATCH,Final

例では、完全一致ドメインを最初にDIRECTとし、example.orgとそのサブドメインをProxyへ送り、名前にmediaを含むドメインをMediaへ送り、ローカルネットワークをDIRECTとし、宛先ポート22のリクエストを専用ポリシーへ渡し、残りをFinalで処理します。ポリシー名はproxy-groups内の名前と大文字・小文字、空白を含めて完全に一致させる必要があります。no-resolveは、一部のIPルールでマッチのために追加のドメイン解決が発生するのを防ぎますが、適用できるかどうかはルール形式と設定の目的に応じて判断してください。

プロキシグループでルールと個別ノードを切り離す

ルールは、特定のノード名ではなく意味の分かりやすいプロキシグループを指すように設計するのが適切です。たとえばルールは「Media」「Work」「Final」を参照し、グループ内で具体的なノードを選びます。サブスクリプション更新でノードが増減しても、ルール層をすべて書き換える必要がありません。手動選択グループは出口を明示的に決めたい場合に適しています。自動テストグループはテスト先へ定期的にアクセスし、応答に基づいてノードを選びます。フェイルオーバーグループは利用可能なノードを順に試し、ロードバランシンググループは設定したアルゴリズムで接続を分配します。グループごとに解決する問題が異なるため、名前だけで動作を判断しないでください。

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - Auto
      - DIRECT

  - name: Auto
    type: url-test
    use:
      - main-provider
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

url-testが測定するのは、指定したテスト先への1回のリクエストの結果であり、動画の帯域幅、長時間接続の安定性、すべての宛先での実際の体感を示すものではありません。テスト先は長期的にアクセスでき、応答が小さく、実際の利用時のネットワーク経路とある程度近いものを選びます。間隔が短すぎると余分なリクエストが増え、長すぎるとノードの変化をすぐに検知できません。toleranceは遅延が近いときの頻繁な切り替えを抑え、複数ノード間の往復を防ぎます。自動グループは一般的なアクセスに適し、重要なセッションや固定出口が必要な用途には手動選択グループが向いています。

ルールセットとリモートプロバイダー

ルール数が多い場合は、rule-providersを使ってカテゴリーごとに独立したファイルへ分け、メイン設定から参照できます。ルールセットを個別に更新でき、再利用もしやすくなります。ただしリモートルールには、ダウンロード失敗、形式の非互換、更新による動作変更のリスクがあります。ルールプロバイダーには適切な更新間隔とローカルキャッシュパスを設定し、初回有効化後にログでダウンロード成功を確認してください。ルールセットの種類、動作タイプ、ファイル形式は一致させる必要があります。domain、ipcidr、classicalでは内容構造が異なるため、混用すると解析エラーや想定外のルール動作につながります。

ルールを変更するときは「最小限の上書き」を意識します。まず、異常が明確なドメインに完全一致ルールを1つ追加し、マッチを確認してからドメインサフィックスやルールセットへ広げるか判断してください。1つのサブドメインの異常だけを理由に、トップレベルドメイン全体を同じポリシーへ送らないでください。最終のMATCHを前へ移動してもいけません。クライアントが上書きやマージに対応している場合は、ローカルルールを永続化された上書き層に置き、サブスクリプション更新で失わないようにします。DNSとルールの相互作用については、Clash DNS設定の詳しい解説も参照してください。

TUNとDNS：より多くのトラフィックを取り込み、名前解決を一貫させる

TUNが解決するのはトラフィックの入口の問題

システムプロキシは、アプリがOSのプロキシ設定を自ら参照することを前提とします。ブラウザや多くのデスクトップアプリは対応していますが、ゲーム、コマンドラインツール、一部のストアアプリ、独自ネットワークスタックを使うソフトはシステムプロキシを完全に無視することがあります。TUNは仮想ネットワークインターフェースを作り、ルーティングによってより多くのIPトラフィックをカーネルへ送るため、対応範囲を広げられます。TUNは新しいプロキシモードではありません。トラフィックがTUNに入った後も、ルール、グローバル、DIRECTのモードで処理され、出口はプロキシグループが決めます。

TUNを初めて有効にすると、管理者権限、ネットワーク拡張権限、VPN権限が必要になる場合があります。Windowsでは他の仮想NIC、企業向けセキュリティソフト、既存VPNにも注意してください。macOSではネットワーク拡張がシステムで許可されていることを確認します。AndroidとiOSでは通常、TUNがシステムVPNとして扱われ、同じインターフェースを使うほかのアプリと競合します。有効化直後にネットワーク全体が切断された場合は、まずTUNを無効にして基本接続を復旧し、インターフェース作成、ルート追加、DNS待受のエラーをログで確認します。ノードを何度も切り替え続けないでください。

TUNでよく使うパラメーターの役割

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

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  fallback:
    - tls://8.8.8.8:853

auto-routeは必要なルートをカーネルが自動追加できるようにします。auto-detect-interfaceは現在の外向きネットワークインターフェースを識別し、有線、無線、モバイルホットスポットを切り替える端末に適しています。stackはTUNで使うネットワークスタックの実装を決めます。mixedは一般的な選択肢です。特定のプラットフォームで互換性の問題が起きた場合は、クライアントのドキュメントに従いsystem、gvisor、mixedを試しますが、一度に変更するのは1つのパラメーターだけにしてください。dns-hijackは条件に合うDNSリクエストをカーネルへ渡し、アプリがClashのDNSを迂回するのを抑えます。

例に示したアドレスはフィールド構造を説明するためだけのものです。実際のDNSサーバーは、現在のネットワークからの到達性、プライバシー要件、設定の取得元を踏まえて選びます。nameserverとfallbackを大量に単純追加しないでください。サーバー数が多いほど安定するとは限らず、問い合わせ経路と原因の切り分けが複雑になります。サブスクリプションにDNSセクションがある場合は、まず既存のロジックを理解してから変更します。GUIのスイッチでTUN設定を生成するクライアントでは、サブスクリプションファイルと全般設定に競合するDNSパラメーターを二重に書かないようにしてください。

fake-ipとredir-hostの違い

fake-ipモードでは、ドメインに対して予約アドレス範囲のマッピングアドレスを返します。カーネルはマッピングを通じて元のドメインを保持するため、より早い段階でドメインルールにマッチできます。分岐性能に優れることが多い一方、LANサービス、特殊なアプリ、実際の名前解決結果に依存するプログラムではfake-ip-filterへの追加が必要になる場合があります。redir-hostは従来の名前解決に近く、実IPを返して解決結果をもとに転送します。互換性の考え方は分かりやすいものの、ドメイン情報の保持とマッチ経路は異なります。選択時はクライアントのデフォルト値と実際の互換性を基準にし、名称だけを理由に頻繁に切り替える必要はありません。

「Webページは開くのにLAN機器が見つからない」「アプリのログインに失敗するがブラウザは正常」といった場合は、DNSログ、fake-ipの除外項目、LANドメインを確認します。除外はできるだけ具体的にし、すべてのドメインを対象外にするのではなく、特定のローカルドメインサフィックスを指定してください。変更後はアプリ自身のDNSキャッシュを削除するか、接続を再確立します。そうしないと古い解決結果が残ることがあります。システムで別の暗号化DNS、ブラウザのセキュアDNS、企業向けDNSクライアントを使っている場合は、Clashの名前解決経路を迂回していないかも確認してください。

TUNでよくある競合を特定する

TUNを有効にして完全にネットワークへ接続できなくなった場合は、まず仮想インターフェースの作成、デフォルトルートの追加、現在の物理インターフェースの正しい認識を確認します。一部のアプリだけ異常なら、そのアプリのリクエストが接続一覧に入っているか、TUNルートの対象外になっていないかを確認します。LANへのアクセスに問題がある場合は、プライベートネットワーク範囲のルールとルート除外を調べます。スリープ復帰後に機能しない場合は、ネットワークインターフェースの変化に対してルートが更新されていない可能性があります。まずTUNを一度無効・有効にして復旧するか確認し、その後にインターフェース自動検出やクライアント更新を検討します。

コンテナ、仮想マシン、ゲーム向け高速化ツール、企業VPNを同時に動かすと、ルーティングテーブルは複雑になります。トラブルシューティングでは、まずルートを変更するほかのプログラムを一時終了し、Clash TUN単独で正常に動作するか確認します。その後、1つずつ戻して競合が発生する段階を観察します。業務環境で企業VPNの利用が必須なら、そのルートを勝手に上書きせず、システムプロキシを使うかネットワーク管理の方針に従ってください。TUNの目的は取り込み範囲を広げることであり、管理対象ネットワークのポリシーを強制的に変更することではありません。

日常の保守とトラブルシューティング：安定した確認手順を整える

保守で重視するのは設定、カーネル、システムの状態

Clashクライアントが安定して動作しているなら、設定を頻繁に消去したりノードを交換したりする必要はありません。日常の保守は、必要に応じたサブスクリプション更新、クライアントとカーネルの保守状況の確認、ログ容量の定期確認、復旧可能な設定元の保持の4項目にまとめられます。更新後は普段使うプロキシグループを簡単に確認してください。クライアント更新前には現在の設定場所と重要なスイッチを記録し、更新後はカーネルの起動、システムプロキシ、TUNの状態を最初に確認します。上書きインストールでサブスクリプションが変わるとは限りませんが、自作ルールとローカル設定は独立したバックアップを残してください。

ログは問題の特定に使うもので、debugレベルを長期間維持するものではありません。正常時はinfoで、設定の読み込み、待受ポート、サブスクリプション更新、接続エラーを確認できます。問題が起きたら一度再現し、その時刻の前後からログを読みます。最後の行を眺めるより、最初に現れた明確なエラーを探すほうが有効です。後続のエラーは最初の失敗による連鎖反応にすぎない場合があります。ログを共有する前に、サブスクリプションURL、ノード認証情報、個人のパスを削除し、エラーの種類、関連フィールド、必要な前後関係だけを残してください。

「範囲」で障害箇所を判断する

すべてのアプリがネットワークへ接続できない場合は、まずDIRECTに切り替えてTUNを無効にし、通常のネットワークが使えるか確認します。その後、カーネルの状態とポート競合を確認します。システムプロキシに従うアプリだけ正常で、ほかのアプリが異常なら、TUNまたはアプリ自身のプロキシ設定を調べます。1つのWebサイトだけ異常なら、マッチしたルール、DNSの結果、対象サービスの状態を確認します。1つのノードだけ異常なら、同じプロキシグループの別ノードと比較します。サブスクリプションだけ更新できず既存接続が使える場合は、問題をURLと更新経路に限定し、クライアント全体をリセットしないでください。

遅延テストが示すのは、テスト先への短いリクエストの結果だけです。低遅延のノードでも、帯域幅、パケットロス、混雑、対象への経路によって動画や大容量ファイルでは性能が出ないことがあります。反対に、遅延がやや高いノードのほうが安定する場合もあります。実際の体感は、接続成功率、継続転送、対象サービスの応答、一定時間の安定性を合わせて判断してください。遅延値の仕組みと注意点についてはClashの遅延テスト値と実速度の見方を参照してください。

ポート、時刻、キャッシュは見落としやすい基本項目

ポート競合があるとカーネルは待ち受けできず、ログには通常address already in useのような情報が出ます。まず古いクライアントと重複したカーネルプロセスを終了し、ポートが解放されたことを確認してください。システム時刻が大きくずれていると、HTTPS証明書の検証や一部プロトコルのハンドシェイクに失敗します。信頼できる時刻同期を有効にしてください。DNSと接続のキャッシュによって、変更がすぐ反映されないこともあります。ルールを切り替えても古い接続が元のポリシーを使い続け、DNSを変更してもアプリが古い結果を保持する場合があります。テストでは接続を再確立し、必要に応じて対象アプリを再起動します。毎回端末全体を再起動する必要はありません。

システムプロキシを無効にできない場合は、OSのネットワーク設定から手動で復元します。Windowsでは自動構成スクリプトと手動プロキシが同時に残っていないかも確認します。macOSでは現在のネットワークサービスごとにプロキシ項目を確認します。クライアントが異常終了した場合、TUNのルートは通常削除されますが、仮想インターフェースやルートの状態が一時的に残ることがあります。ドライバーをすぐ削除するより、クライアントを再起動して正常終了を一度行うほうが安全です。モバイルではシステムVPN設定から接続を切断し、クライアントを再認証してください。

再現可能なトラブルシューティング記録を作る

有効なトラブルシューティング記録には、少なくともOS、クライアント名、使用した取り込み方式、プロキシモード、発生時刻、対象アプリ、マッチしたポリシー、重要なログを含めます。「使えない」だけでは、サブスクリプション、ルール、DNS、ノードのどこが問題か分かりません。「ルールモードでブラウザのリクエストがDIRECTにマッチし、グローバルモードでProxyにマッチすると復旧した」と書けば、ルール層を直接疑えます。各テストでは1つの変数だけを変更し、変更前後の結果を記録します。複雑な問題では、現在の設定をコピーしてテスト用の複製を作り、日常用設定に一時的な変更を重ね続けないようにします。

クライアント更新後に新しい問題が起きたら、まず設定が選択されたままか、カーネルが切り替わっていないか、TUN権限が保持されているかを確認し、その後でロールバックを検討します。古いクライアントの保守が終了しても、長期的に使い続けるのは避けてください。新しいクライアントへ移行したら、システムプロキシ、プロキシグループ、自作の上書きを再確認します。オリジナル版、Meta、mihomoの関係についてはClashカーネルのバージョン差と選び方を参照し、クライアントのバージョン変更とカーネルの違いを混同しないようにしてください。

上級設定への道筋：GUI設定から保守しやすい構成へ

まず設定を読めるようになってから、設定を書き換える

上級設定の第一歩は、空のファイルから始めることではありません。まず、すでに動作している設定を読み解きます。基本の待受、DNS、プロキシプロバイダー、プロキシグループ、ルールプロバイダー、最終ルールを識別し、実際のリクエストがどのフィールドを通るか追跡してください。サブスクリプションが生成した設定は複製し、その複製に最小限の変更を加え、クライアントの設定チェック機能で検証します。YAMLはインデントに敏感です。リスト項目、オブジェクトの階層、文字列内の特殊文字が解析失敗の原因になることがあります。エディターではスペースによるインデントを使い、通常の文字を自動的に組版記号へ置き換えないようにしてください。

設定の分割は保守の境界を中心に考えます。サブスクリプションはリモートノードを担当し、ローカル上書きは個人用ルールを担当し、ルールプロバイダーは再利用可能な分類を担当し、全般設定は端末単位のポート、TUN、画面動作を担当します。サブスクリプション更新のたびに置き換えられる1つのファイルへ、すべてを詰め込まないでください。クライアントがmerge、override、スクリプトに対応している場合は、まずマージ順を確認します。同名フィールドが上書き、追加、深いマージのどれになるかで、最終設定は大きく変わります。変更後は入力した断片だけでなく、クライアントが実際に生成してカーネルへ渡す設定を確認してください。

プロキシプロバイダーで動的なノードを管理する

proxy-providers:
  main-provider:
    type: http
    url: https://example.invalid/provider.yaml
    path: ./providers/main.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: Main
    type: select
    use:
      - main-provider
    proxies:
      - DIRECT

proxy-providersを使うとノードの取得元をメイン設定から分離でき、メイン設定ではuseでプロバイダーを参照します。リモートファイルはカーネルが対応するprovider形式にし、pathでローカルキャッシュの場所を指定し、intervalで再取得の頻度を制御します。ヘルスチェックは指定したテスト先への到達性を判断しますが、すべての宛先での体感を示すわけではありません。複数のプロバイダーを併用する場合は、用途別にプロキシグループを作り、すべてのノードを巨大な1つのリストへ詰め込む必要はありません。プロバイダーの更新に失敗しても、ローカルキャッシュを継続利用できる場合があります。そのためキャッシュパスは、クライアントが書き込め、更新後も保持される場所に置いてください。

外部コントロールインターフェースとLAN公開を分けて管理する

external-controllerを使うと、GUIや管理パネルからカーネルの状態を読み取り、切り替え操作を実行できます。個人PCではまずループバックアドレスで待ち受け、他の端末から管理する必要がある場合だけLAN待受を検討してください。その際はアクセス認証、OSのファイアウォール、信頼できるネットワーク範囲も設定します。allow-lanはプロキシポートへのLAN端末からの接続を許可するかどうかを制御し、コントロールインターフェースとは別のスイッチです。プロキシポートを公開してもコントロールインターフェースまで公開すべきとは限らず、その逆も同様です。LAN向けの待受はすべて、用途とアクセス範囲を明確にしてください。

ソフトルーターやサーバーで実行する場合は、カーネルをどのユーザーで起動するか、設定とキャッシュディレクトリを誰が書き込むか、サービス失敗時にどう再起動するかも決める必要があります。ターミナルでプロセスを長時間起動したままにするより、システムサービスマネージャーを使うほうが信頼性が高くなります。カーネル更新前には現在の実行ファイルと設定を保持し、設定チェックを実行してからサービスを再起動し、ログを確認してください。コンテナ運用では、ポートマッピング、ネットワークモード、TUNデバイスの権限、設定ボリュームを明確にします。ホストの全ディレクトリをそのままコンテナへマウントしないでください。

DNS、スニッフィング、ルールを1つのシステムとして設計する

上級設定では、fake-ip、DNSハイジャック、ドメインスニッフィング、ルールセットを同時に有効にすることがあります。共通の目的はドメイン情報をできるだけ保持し、トラフィックを正しく分類することです。しかし重複や競合する設定は誤判定を増やします。スニッフィングは一部のHTTP、TLS、QUICトラフィックからドメインを復元でき、IPへ直接接続するアプリに役立つことがあります。ただし業務内容を復号するものではなく、すべてのプロトコルからドメインを取得できるわけでもありません。まずクライアントのデフォルト範囲から始め、明確な問題があるポートや除外項目だけを調整してください。

DNS経路を設計するときは、3つの問いを図にします。システムのリクエストを誰へ渡すのか、カーネルがどの上流DNSへ問い合わせるのか、解決結果をルールでどう使うのか、です。nameserver-policyを使えば特定のドメインに解析サーバーを指定できますが、範囲は正確にし、多数の問い合わせが不適切な上流へ誤送信されないようにします。fallback-filterは、どの結果を代替名前解決のロジックへ送るかを判断します。地理情報、ネットワーク範囲、ドメイン条件と合わせて理解してください。関連フィールドの関係はnameserver、fallback、ハイジャックパラメーターの解説で確認できます。

自分の変更手順を確立する

保守しやすい設定には固定した手順が必要です。現在使える設定を複製し、今回解決する問題を1つだけ明記します。変更後に構文チェックを実行し、DIRECTで復旧できる環境に読み込んでテストします。接続記録、ルールのマッチ、ログを確認し、安定したら日常用設定へ統合します。ルールセットとプロキシプロバイダーについては、取得元、用途、更新方法を記録してください。使わなくなったフィールドを削除し、GUI設定、上書きファイル、サブスクリプションで同じ機能を重複定義しないようにします。

学習は3つの線に沿って進められます。1つ目はルールです。DOMAIN、IP-CIDR、PROCESS-NAME、RULE-SET、MATCHのマッチ範囲を理解します。2つ目はネットワークです。システムプロキシ、TUN、ルーティング、DNS、IPv6を理解します。3つ目は運用です。設定の分割、ログ、サービス管理、ロールバックを身につけます。この3本を終えてから、mihomoの拡張プロトコルや特殊なルール形式を調べてください。まずmihomoカーネルの機能差を読み、どのフィールドが現在のカーネルに属するか確認してから、設定へ追加するか判断します。