Clash / mihomo システム設定ガイド

Clash設定ガイド
クライアントとルール設定

このページでは、9つの段階に分けて設定の流れを解説します。まずネットワーク通信がコアに届く仕組みを理解し、クライアントの選択、サブスクリプションの読み込みへと進み、最後にルール、TUN、メンテナンスを扱います。接続だけをすぐに済ませたい場合は使い方ガイドをご覧ください。設定項目の意味や動作の違い、設定の上書きで困った場合は、該当する章に戻って確認できます。

設定例はmihomoの項目を基準にしています。クライアントによって画面上の名称、モバイル版の機能、設定のマージ方法が異なる場合があるため、利用中のクライアントの説明と最終的な有効設定を確認してください。各例は特定の用途を示すもので、サブスクリプションが提供する完全な接続設定の代わりにはなりません。

1. 基本概念：コア、クライアント、設定

まず画面と処理層の違いを理解する

Clashのエコシステムでは、クライアントとコアは異なる役割を担います。クライアントは設定管理、プロキシグループの選択、システムプロキシの切り替え、ログ表示などを提供します。コアは通信の入口を待ち受け、リクエストを解析してルールと照合し、実際のアウトバウンド接続を確立します。mihomoはこのエコシステムで継続的に開発されているコアプロジェクトで、GUIクライアントに組み込まれることもよくあります。Clash風の画面が似ていても、対応する設定項目やコア、設定の処理方法まで同じとは限りません。

通信の流れは、アプリがリクエストを発生させ、OSまたはアプリがプロキシの入口に渡し、コアが設定に基づいて処理方法を決め、最後に直接接続またはプロキシ経由で接続する、という4段階で考えるとわかりやすくなります。あるWebページを開けても、その通信経路が動作したことしか確認できません。別のアプリはシステムプロキシを参照しない場合があり、別のドメインは異なるルールに一致することもあります。トラブル時はスイッチの状態だけでなく、入口、ルールの一致結果、アウトバウンドを確認しましょう。

ノード、プロキシグループ、ルールの役割

ノードには、プロキシ接続に必要なプロトコル、サーバーアドレス、ポート、認証情報が定義されています。プロキシグループはノードやほかのアウトバウンド候補をまとめ、手動選択や所定の方法による切り替えを可能にします。ルールは、特定のリクエストをどの接続先に渡すかを指定します。ルールがプロキシグループを参照し、グループがノードを選択するのが基本的な関係です。ルールから組み込みの DIRECT または REJECT を直接指定することもでき、それぞれ直接接続と拒否を意味します。

サブスクリプションは通常、更新可能なリモート設定の配信元ですが、内容は一定ではありません。ノード、ルール、プロキシグループを含む完全な設定を返すものもあれば、ノード一覧だけを返し、残りをクライアントのテンプレートで補うものもあります。ノード一覧を完全な設定として使うと、選択できるプロキシグループがない、あるいはノードは存在するのにルールから参照されない、といった状態になりがちです。読み込み前に内容の種類を見分けるほうが、モードを何度も切り替えるより効果的です。

YAMLファイルと実際に適用される設定

設定は通常、config.yamlとして保存します。YAMLはインデントで構造を表すため、同じ階層のキーは位置をそろえ、リスト項目にはハイフンを使います。スペースの代わりにタブは使えません。コロンの後には通常スペースが必要で、特殊文字を含む文字列は引用符で囲むと安全です。構文解析に成功しても、プロキシグループの参照、ファイルパス、ネットワーク権限などの実行条件が正しいとは限りません。変更後はコアが設定を受け付けたか、実際のリクエストがどのルールに一致したかも確認しましょう。

GUIクライアントでは、サブスクリプションの元データ、テンプレート、上書き設定、実行時に生成されるファイルをそれぞれ保存することがあります。ディスク上で編集したファイルが、コアの読み込み対象とは限りません。次回のサブスクリプション更新で、手動編集が上書きされる場合もあります。クライアントの設定プレビューや実行設定の場所を確認し、各項目がどこから適用されるか、画面上のスイッチがより優先されるかを把握してください。以降の設定例は、サブスクリプション全体を無条件に置き換えず、管理された上書きレイヤーに追加しましょう。

ソフトウェアとネットワークサービスは別のものです。クライアントをインストールしても、利用可能なサーバーが自動で用意されるわけではありません。ソフトウェアがオープンソースでも、接続先が付属するとは限りません。サービスの利用可否、通信量、プロバイダーのアカウント状態は別途確認が必要です。サブスクリプションには接続情報が含まれるため、アカウント情報と同様に扱い、公開の場やオンライン変換サービス、スクリーンショットに載せないでください。配信元が不明な設定は、読み込む前にリモートリソース、待ち受けアドレス、コントロールインターフェースを確認しましょう。

2. クライアントの選び方：プラットフォームと利用上の注意

まずデバイスを確認し、クライアントの機能を比較する

初めて使う場合はClash Plusを確認し、対応プラットフォーム、デスクトップ環境、使い慣れた操作方法に応じてほかのクライアントと比較してください。選定では画面の見た目より先に、OS、CPUアーキテクチャ、インストーラーの形式を確認します。デスクトップクライアントは設定管理や接続状況の確認に向いています。モバイル端末では通常、OSのVPNインターフェースを使って通信を取り込みます。サーバー上でコアだけを動かす場合は、設定やプロセスを自分で管理する必要があります。使い始める手順が異なるため、同じ権限設定をそのまま適用することはできません。

ダウンロードページでは、プラットフォームごとのクライアントと対応情報をまとめて確認できます。初めて使う場合は、メンテナンスが続いていて、正常に起動し、デバイス要件にも合うクライアントを一つ選び、まず最短の接続手順を完了してから追加機能を比較しましょう。クライアントを頻繁に切り替えると、設定のマージ方法、DNSの初期値、システムへの通信取り込み方式も変わります。同じ問題を複数のソフトウェアの不具合と誤認しやすくなり、残ったプロキシ設定の調査にも手間がかかります。

プラットフォーム別の選び方と確認事項
プラットフォーム	まず確認する項目	インストール前の確認事項
Windows	Clash Plus	対応OS、CPUアーキテクチャ、サービスの権限
macOS	Clash Plus	Apple SiliconかIntelか、ネットワーク権限
Android	Clash Plus	デバイスのアーキテクチャ、VPN権限、バックグラウンド制限
iOS	Clash Plus	ストアのデバイス互換情報、VPN設定の権限
Linux	Clash Verge Rev	ディストリビューションのパッケージ形式、デスクトップ依存関係、権限

プラットフォーム別に見るクライアント候補

WindowsではClash Verge Rev、FlClash、Clash Nyanpasu、macOSではClash Verge Rev、FlClashを比較できます。LinuxではClash Verge RevとFlClashを候補にし、利用するディストリビューションに合ったパッケージ形式を確認してください。AndroidではClash Meta for Android、FlClash、Surfboardを比較できます。ただしSurfboardの設定形式はClash YAMLと同等ではないため、専用の読み込み手順に従ってください。同じサブスクリプションURLを使えるからといって、すべてのクライアントが解析できるとは限りません。

iOSではClash Plusのストア情報とデバイスの互換性を確認してください。製品の公式サイトはclashplus.ioです。モバイルOSにVPNの表示があっても、それはネットワークインターフェースが有効であることを示すだけで、すべての宛先がプロキシ経由になるとは限りません。実際の動作は、クライアントが対応するルール、除外範囲、アウトバウンド設定によって決まります。接続確認は特定のアプリと宛先を使って行い、ステータスバーのアイコンだけで判断しないでください。

メンテナンス状況と設定の移行

Clash for WindowsとClashX Metaは開発が終了したアーカイブ版のため、新しいデバイスでの標準的な選択肢にはおすすめできません。起動できても、新しいOSの権限、プロトコル対応、設定項目に制限がある場合があります。移行する際は、設定の配信元と手動ルールを書き出し、旧環境のバックアップを残してから新しいクライアントに読み込んでください。アプリのデータフォルダー全体をそのままコピーするのは避けましょう。データベース構造、パス、暗号化された保存方法が異なることがあります。

機能を比較するときは、実際の用途に沿って確認しましょう。使用するサブスクリプション形式に対応しているか、有効設定をプレビューできるか、安定した上書き方法があるか、TUNに追加サービスが必要か、ログを絞り込めるか、といった点が目安です。あるクライアントにボタンがあっても、ほかのプラットフォームで同じ仕組みが使えるとは限りません。特にデスクトップのシステムプロキシやサービスモードと、モバイルのVPNによる通信取り込みは別々に理解し、同じ日本語名だけを根拠に動作を推測しないでください。

一般的なデスクトップユーザーは、mihomoコアを個別にダウンロードする必要は通常ありません。クライアントがコアの起動、設定パス、一部の権限を管理します。手動でコアを置き換えると、コントロールインターフェースとの互換性が失われたり、起動引数が合わなくなったりすることがあります。サーバーやルーターで使う場合や、プロセスを自分で管理する必要がある場合は、コアを直接実行する方法が適しています。その場合はサービス管理とネットワーク分離も自分で行います。クライアントと設定の配信元を決め、再現可能な環境を用意して次の段階へ進みましょう。

3. インストールと権限：元に戻せる実行環境を整える

インストール前に現在のネットワーク状態を記録する

インストール前に、ほかのプロキシ、VPN、通信フィルター、セキュリティソフトが動作していないか確認してください。現在のシステムプロキシ、既存のVPN設定、業務ネットワークに必要な条件を記録し、複数のソフトウェアが同じ設定を同時に変更しないようにします。旧クライアントから移行する場合は、システムプロキシとTUNを正常に無効にしてからプロセスを終了します。アプリを削除しただけでは、システムプロキシ、サービス、仮想ネットワークアダプターが残ることがあります。「アンインストール済み」というだけでネットワークが元に戻ったと判断しないでください。

インストーラーは本サイトのダウンロードページと各プロジェクトの配布元から入手し、プラットフォームとアーキテクチャを確認してください。WindowsのOSのビット数とCPU、macOSのチップ、Androidの命令セット、Linuxのパッケージ形式によって利用できるファイルが異なります。解凍できても実行できるとは限りません。アーキテクチャ不一致のエラーが出た場合は、ダウンロードページに戻って適切なファイルを選び直してください。拡張子の変更や再解凍では解決しません。後で更新や復元ができるよう、入手元を記録しておきましょう。

デスクトップ：インストール権限とネットワーク権限を区別する

Windowsでは初回起動後、まずメイン画面とコアが動作していることを確認し、クライアントが提供するサービスコンポーネントをインストールするか判断してください。システムプロキシは通常、現在のユーザーの設定に関係します。TUNやバックグラウンドサービスには、より高い権限が必要な場合があります。ファイアウォールの警告が出たら、プログラムのパス、利用するネットワーク、待ち受け範囲を確認してください。警告を消すためにすべての受信接続を許可してはいけません。自分のデバイスだけで使う場合は、ローカルループバックでの待ち受けを優先し、LANアクセスは有効にしないでください。

macOSではインストーラーの説明に従って適切な場所にアプリを置き、初回起動時にOSの設定から表示される明確な許可要求に対応してください。ネットワーク拡張、補助コンポーネント、システムプロキシ、キーチェーンの許可はそれぞれ別の権限です。すべてのダイアログを同じ種類のエラーと考えないようにしましょう。アプリが何度も許可を求める場合は、インストール先と同名のアプリがすでにないか確認し、古いコピーを同時に実行しないようにしてください。具体的な対処はmacOSのネットワーク拡張とキーチェーンの権限に関する説明を参照してください。システムのセキュリティ機能全体を無効にすることはおすすめしません。

Linuxデスクトップでは、パッケージのインストール成功、GUIの起動成功、コアにネットワーク権限があることをそれぞれ確認する必要があります。デスクトップ依存関係が不足するとウィンドウを開けないことがあり、権限不足はTUNだけに影響する場合もあります。システムプロキシがアプリに使われるかどうかはデスクトップ環境によって異なります。ディストリビューションの説明に従って対応する形式をインストールし、まず通常の権限で起動を確認してください。機能の許可やサービスモードが必要な場合はクライアントの方法を使い、GUI全体を常に高い権限で実行することを標準にしないでください。

モバイル：VPN権限とバックグラウンド動作

AndroidとiOSでは通常、初回接続時にVPN設定の追加または有効化を求められます。ダイアログがインストールしたクライアントから表示されたことを確認してから許可してください。Androidではバッテリー最適化、バックグラウンド動作、システムの自動終了設定も確認します。画面ロック後に切断する、アプリを切り替えると更新が止まる、といった場合は、ノード設定ではなくプロセスが制限されている可能性があります。まずアプリを前面に表示したまま接続を確認し、その後必要なバックグラウンド権限だけを調整してください。関係のない権限を一度に多数有効にするのは避けましょう。

初回起動時に複数の通信取り込み方式をいきなり重ねないでください。まず設定を読み込み、クライアントのログでコアが正常に起動したことを確認します。デスクトップではその後システムプロキシを有効にし、モバイルでは通常の接続手順に沿ってVPNを許可します。テスト後は正常な停止も確認しましょう。通信取り込みを無効にし、システムプロキシが解除されたことを確認してクライアントを終了し、直接接続でネットワークが使えるか確かめます。正常に停止して復旧できることは、TUNや複雑なルールを試す前提です。「起動方法」だけでなく「停止方法」も確認してください。

4. サブスクリプションの読み込み：配信元、更新、設定の上書き

受け取ったものがURLかファイルかを見分ける

サブスクリプションの読み込み方法には、リモートURL、ローカルファイル、テキスト貼り付けの3種類があります。リモートURLは定期更新向け、ローカルファイルはバックアップや固定設定向け、テキスト貼り付けは一時的な確認に便利です。内容に合った読み込み方法を選び、Webページの説明用URLをサブスクリプションとして登録したり、YAMLをURL専用の入力欄に貼り付けたりしないでください。URLにアカウント情報が含まれる場合があります。必要な範囲で安全に保存し、公開したり共用端末に長期間残したりしないようにしましょう。

設定管理画面で新しい設定を作成し、見分けやすい名前を付けて内容を読み込んだら、ダウンロードと解析が終わるまで待ちます。次に、その設定を現在の使用対象に指定してください。リストに表示されただけでは、コアの設定が切り替わったとは限りません。プロキシグループが表示されるか、ノードを選択できるか、ログに読み込み成功と記録されているかを確認します。失敗した場合はエラー行と項目名を確認し、まず形式の問題を解決してください。設定が反映されていないまま接続ボタンを何度も押しても解決しません。

ダウンロード失敗、解析失敗、接続失敗を区別する

サブスクリプションのダウンロード失敗は設定の取得段階で起こり、ドメインの名前解決、アカウント状態、アクセス制限、配信サーバーの応答などが原因になり得ます。解析失敗は内容を取得できたものの、返されたものがログインページやエラーページ、別クライアント用の形式だったり、YAMLのインデントが誤っていたりする状態です。ノードの接続失敗は設定の読み込み後に起こるため、サーバーへの到達性や認証情報を確認します。3つは発生する段階が異なります。まずどの段階で失敗したかを確認してから、適切な方法で調べましょう。

サブスクリプションが完全な設定を返す場合は、まず既定のプロキシグループとルールを残したまま基本動作を確認します。ノードだけが返される場合は、クライアント対応のテンプレートか配信元の説明に従って設定を補い、出所のわからないテンプレートを適当に組み合わせないでください。テンプレート内のプロキシグループ名とルールからの参照名は一致している必要があり、ノードの配信元も正しく接続する必要があります。「プロキシグループが見つからない」といったエラーでは、ノードの一覧に表示されているかだけでなく、名前、大文字と小文字、マージ順を確認してください。

上書き設定とサブスクリプション更新の注意点

手動設定は、できるだけクライアントが対応する上書きレイヤーやマージ機能に追加してください。ダウンロードしたサブスクリプションの元データを直接編集すると、次回更新で変更が失われることがあります。実行時のファイルを直接編集した場合も、再起動時に再生成される可能性があります。リストを置き換える、追加する、先頭に挿入するなど、クライアントごとに処理方法が異なるため、最終的な rules、proxy-groups、dns の結果を確認しましょう。あるクライアントのマージ方法を、ほかのクライアントにもそのまま当てはめないでください。

次はトップレベルの設定例です。ローカル設定をノード情報から分離する方法を示すもので、ノードやプロキシグループは含まれていません。これだけではプロキシ接続を確立できません。クライアントの画面からすでに管理している項目は、該当するスイッチを優先し、設定プレビューで結果を確認してください。画面とファイルの両方で設定すると、起動後にポートやモードが上書きされ、変更しても元に戻ることがあります。

# トップレベル設定の例。既存の完全な設定にマージして使用
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

サブスクリプションを更新する前に、現在使える設定と必要な手動選択を保存してください。更新後はプロキシグループ名、ノード数の変化、ログを確認します。以前の選択項目が無効になっただけで、サブスクリプション全体に問題があるとは限りません。配信元でノードが削除または改名されると、クライアントが既定の選択に戻ることがあります。その場合は利用可能なアウトバウンドを選び直し、よく使う宛先への接続を確認しましょう。自動更新の間隔は、プロバイダーの制限と実際の必要性を考慮してください。短時間に何度も更新してもサーバー品質は改善しません。

サブスクリプションURLへのアクセスに既存のプロキシが必要な場合は、クライアントが対応する更新時のダウンロード方法を使うか、まず利用可能な通信経路を復旧してください。更新のために全通信を長期間グローバルモードにするのは避けましょう。問題を共有する場合は、URLを伏せたエラー内容、読み込み方法、設定の種類だけを伝え、URLそのものは公開しないでください。配信元やサブスクリプションのエラーについてはサブスクリプションに関するトラブル対処を確認し、失敗した段階に応じて調べてください。

5. プロキシモード：通信の入口と処理方法を分けて設定

ルール、グローバル、直接接続は処理方法の選択

ルールモードでは設定の順に各リクエストのアウトバウンドを選び、日常利用に適しています。グローバルモードでは、コアに届いたリクエストをグローバル用の選択先に渡します。直接接続モードでは、コアに届いたリクエストを宛先へ直接接続します。モードが変えるのは、リクエストがコアに届いた後の処理方法です。すべてのアプリがコアへ通信を渡すようになるわけではありません。したがって、グローバルモードでもデバイス全体の通信が必ず取り込まれるとは限らず、システムプロキシを迂回するアプリもあります。

日常利用ではルールモードを基本とし、ルールの違いを調べる場合に限ってグローバルモードと短時間比較するのがおすすめです。同じ宛先がグローバルモードでは使えてルールモードでは使えない場合は、一致したルールと選択されたアウトバウンドを調べましょう。グローバルモードを修正方法として使い続けるべきではありません。直接接続モードにしても、クライアントが完全に終了するわけではありません。コア、待ち受けポート、VPNインターフェースが動作し続けることもあります。システムのネットワークを完全に元に戻すには、該当する通信取り込みも無効にしてください。

システムプロキシ：適用範囲はアプリが設定に従うかで決まる

システムプロキシを使うと、OSがサポートするプロキシ設定をローカルの待ち受けポートに向けられます。ブラウザーや一部のアプリはこの設定を読み込みますが、コマンドラインツール、ゲーム、独自のネットワーク機能を持つプログラムは無視する場合があります。アプリ独自のプロキシ設定がある場合は、アプリ内で設定するか、環境変数を指定する必要があります。「ブラウザーは使えるのに別のプログラムは接続できない」ときは、ルールやノードを調べる前に、そのプログラムの通信がコアの接続一覧に現れるか確認してください。入口の問題を接続先の不具合と取り違えないようにしましょう。

環境変数は、それを読み込むプロセスにだけ影響し、ツール独自の設定で上書きされることもあります。以下はUnix系の端末で、今回のリクエストだけにプロキシを指定するコマンドです。ローカルのmixed-portが例と同じ値であることを前提としています。Windows PowerShellで同様に確認する場合は、curl.exeを明示的に呼び出してください。リクエストが成功しても、このコマンドが指定した入口を通ったことしか確認できません。ほかのアプリも同じ設定を使っているとは限りません。

curl --proxy http://127.0.0.1:7890 --head https://example.com

ポート設定：待ち受けアドレス、種類、競合

mixed-portはHTTPとSOCKSの入口を提供し、portとsocks-portはそれぞれ個別の入口を設定します。ポート番号は実際に適用されている設定を確認してください。例の数値がすべてのクライアントの既定値とは限りません。ログにアドレスが使用中と表示されたら、別のクライアントや古いコアのプロセスが動いていないか調べてから、使用中のプログラムを終了するかポートを変更してください。変更後はシステムプロキシとアプリ内の手動設定も更新します。

待ち受けアドレスによって、どの端末が入口に接続できるかが決まります。自分のデバイスだけで使う場合はLANアクセスを無効にし、実際のバインド範囲を確認してください。allow-lanを有効にする場合は、バインドアドレス、ファイアウォール、ネットワーク環境を考慮してアクセスを制限しましょう。保護されていないプロキシの入口をインターネットに公開してはいけません。LAN上の端末から接続する場合は、クライアントを実行しているデバイスのLANアドレスを指定します。端末自身を指すループバックアドレスは使えません。ネットワーク分離や端末のスリープ状態も考慮してください。

接続ログでモードの動作を確認する

確認する宛先を一つ決め、既存の接続を閉じるか新しいコマンドを実行してから、接続一覧に記録されたドメイン、適用ルール、プロキシグループの経路、アウトバウンドを確認してください。長時間接続、ブラウザーの接続プール、キャッシュの影響で、モード変更の効果が遅れて見えることがあります。既存の接続がモード変更と同時に必ず作り直されるわけではありません。現在のモードとテスト時刻を記録すると、ログから該当する接続を探しやすくなります。接続の問題は接続に関するトラブル対処も参考にし、段階ごとに確認してください。

一部のクライアントではシステムプロキシとTUNを同時に使えますが、初回の調査では入口を一つに絞るのがおすすめです。二重に設定すると、リクエストがアプリのプロキシを経由した後に仮想ネットワークアダプターで再度取り込まれることがあり、状況を把握しにくくなります。まずシステムプロキシで設定とアウトバウンドを確認し、その後必要に応じて次の段階で取り込み範囲を調整してください。入口、モード、テスト対象を明確にすれば、問題が通信の取り込み、ルール判定、外部ネットワークのどこにあるかを判断できます。

6. ルール振り分け：照合順序とプロキシグループ

上から順に照合し、一致した時点で処理

ルールは通常、上から順に照合され、リクエストが一致すると、そのルールで指定されたアウトバウンドに処理が引き継がれます。ルール同士が投票したり、より「正確」な項目が自動で選ばれたりするわけではありません。明確なドメイン例外は広い範囲を対象とするルールより前に置き、LANアドレスなど基本的な直接接続ルールが末尾のプロキシルールに先回りされないようにします。最後に MATCH を置いてください。リストの下のほうにルールを追加しても、それより前のルールに一致すれば適用されません。

DOMAINは完全一致のドメイン、DOMAIN-SUFFIXはドメインの末尾とそのサブドメイン、DOMAIN-KEYWORDは指定したキーワードを含むドメインに一致します。キーワードルールは想定より広い範囲に一致しやすいため、短い語だけでサービス全体を指定するのは避けましょう。IP-CIDRはアドレス範囲、GEOIPはIPの位置情報データベース、GEOSITEはドメイン分類データに基づいて判定します。これらのルールを読み込むには、データベースと使用する分類ラベルが利用可能である必要があります。

まず参照先のプロキシグループを定義する

プロキシグループ名は設定間の参照に使われるため、ルール内の名前と定義を一致させてください。以下の例では、Proxyという手動選択グループを作り、構造とルールからの参照を確認するために組み込みの直接接続先だけを入れています。この例にはプロキシ機能はありません。実際に使う場合は、proxiesで定義したノード名か、正しく設定した配信元をグループに追加してください。例のグループに表示される直接接続を、プロキシノードの選択と誤解しないようにしましょう。

# 構造の例：Proxyには現在DIRECTのみ含まれています
proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,github.com,Proxy
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,Proxy

selectは手動選択、url-testはテスト結果に基づく候補選択、fallbackは順番に利用可能な接続先を維持する仕組み、load-balanceは指定した方式で接続を振り分ける仕組みです。自動テストは指定されたテスト用URLにアクセスします。その結果はすべてのWebサイトでの使用感と同じではなく、ダウンロード速度を直接示すものでもありません。候補の範囲と切り替え条件を理解してから自動選択が必要か判断し、入れ子のグループを増やしすぎて最終的な接続先を追いにくくしないようにしましょう。

ドメインルールとIPルールの違い

IP系のルールでは、宛先を判定するために先にドメインを名前解決する場合があります。no-resolveは、そのIPルールとの照合のために明示的な名前解決を行わない指定ですが、通信全体でDNSが使われなくなるという意味ではありません。リクエストがすでにIPアドレスを持っていれば、アドレスによる照合は可能です。ドメイン情報を取得できるかは、アプリからの通信経路、DNSモード、スニッフィングの設定にも左右されます。ドメインルールに一致しない場合は、ルールを増やす前に、接続記録にドメインが含まれているか確認してください。

rule-providersを使うと、大規模なルールセットをメイン設定から分離できます。ただし、配信元、キャッシュパス、形式、照合方法を正しく設定する必要があります。ドメインセット、IPセット、従来形式のルールは自由に混在できません。RULE-SETで参照する名前も定義と一致させてください。まず少数のローカルルールで振り分けが正しく動くことを確認してから、リモートのルールセットを追加しましょう。リモート更新に失敗した場合は、利用可能なキャッシュがあるか、読み込まれた内容が想定どおりかも確認します。

ルールの数ではなく、個別の宛先で確認する

ルールを追加する前に、対象のドメインまたはアドレス、渡すプロキシグループ、例外が必要な理由を明確にしてください。保存後に新しい接続を作り、適用されたルールと最終的なアウトバウンドを確認します。結果が想定と違う場合は、より上にある一致ルールを調べ、上書きルールが末尾のルールより後ろに追加されていないか確認しましょう。ルールを増やせば正確になるとは限りません。重複や相互に隠し合うルールはメンテナンスを難しくします。用途のコメントと変更を戻す方法を記録することが、ルールを積み重ねるより大切です。

中国国内の宛先を直接接続し、それ以外をプロキシ経由にする設定については、ルール振り分けの設定例もご覧ください。地理データベースをサービスの地域や運営元を判断する絶対的な基準として使わないでください。CDN、共有インフラ、複数地域にまたがるサービスでは例外が起こり得ます。必要なサービスには理由を説明できるドメイン例外を設け、ルールとDNSの両方を検証して、維持しやすい振り分けを行いましょう。

7. TUNとDNS：通信の取り込み範囲を広げる

まず通常の接続入口が使えることを確認する

TUNは仮想ネットワークインターフェースを使い、そこへルーティングされたネットワークパケットを受け取ります。システムプロキシに従わないアプリの通信を扱うために使います。TUNを有効にしても、停止したノードや認証情報、問題のあるルールが自動的に直るわけではありません。先に通常のプロキシ入口で明確な宛先への接続を確認し、設定とアウトバウンドが使える状態にしてください。基本の通信経路が確立していない段階でルーティングとDNSを同時に変更すると、調べる要因が増えて原因を特定しにくくなります。

TUNの動作はOS、コアの機能、クライアントの権限に依存します。デスクトップではサービスコンポーネントや管理者権限が必要な場合があります。モバイルでは通常、OSのVPNインターフェースが同様の通信取り込みを担うため、デスクトップ向けのYAML設定をそのまま適用することはできません。仮想ネットワークアダプターやルートの作成に失敗した場合は、権限とクライアントのサービス状態を先に確認してください。この段階でノードを何度も切り替えても、ローカルのインターフェース初期化は改善しません。

ルーティングとDNSのリダイレクトは別の役割

auto-routeは関連するルートを自動設定し、auto-detect-interfaceはアウトバウンド用のインターフェースを自動検出します。dns-hijackは対象となるDNSリクエストを内蔵DNS処理へ渡します。次はデスクトップ版mihomoの一部設定例です。有効なアウトバウンド設定とマージし、権限をクライアントに適切に管理させてください。画面にTUNやDNSのスイッチがある場合は、生成された設定を確認し、互いに上書きし合う2つの設定を同時に管理しないようにしましょう。

# デスクトップ版TUN / DNSの設定例。これらの項目にクライアントが対応しているか先に確認
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query

DNSの上書きとfake-ipの仕組み

DNS設定はドメインの名前解決方法を決め、後続のルール判定や接続にも影響します。fake-ipモードでは、ドメインに内部マッピング用のアドレスを割り当て、コアがその対応関係からドメインを復元して接続を処理します。これは接続先Webサイトの実際のサーバーアドレスではありません。アプリがコアを迂回してこのアドレスを直接使ったり、期限切れのマッピングが古いキャッシュに残ったりすると、特定のアプリだけが接続できない場合があります。DNSモードを切り替えたら新しい接続で確認し、必要に応じてOSやアプリのキャッシュを処理してください。

LAN上の一部のサービス、デバイス検出、実際の名前解決結果に依存するアプリでは、fake-ip-filterやクライアントの互換設定が必要になることがあります。問題が起きるたびにすべてのドメインをフィルターへ追加したり、アドレスプール全体を安易に変更したりしないでください。対象のドメイン、LAN上のサービスかどうか、影響が特定のアプリだけかを確認してから、範囲を最小限にした例外を追加します。フィルターの意味は設定方式によっても変わるため、利用中のコアの説明と実際に適用された項目を確認してください。

通常のDNSポートをリダイレクトしても、暗号化DNSをすべて取り込めるわけではありません。ブラウザーやアプリに組み込まれたDoH、DoTは別の接続を使うことがあり、OS専用のDNS設定によって実際の経路が変わる場合もあります。まず誰が名前解決を担っているか確認し、DNSをコアに集約するのか、アプリ独自の設定を維持するのかを決めてください。リモートDNSサーバーへの接続経路も必要です。ホスト名で指定したDNSサービスを使う場合は、そのホスト名の初回解決方法も考慮し、DNSの参照が循環しないようにしましょう。

ルーティング、名前解決、アウトバウンドの順に確認する

TUNを有効にしたら、まず通常のドメインへのアクセスをテストし、次にシステムプロキシに従わないアプリ、最後にLAN上のデバイスとスリープ復帰後の動作を確認します。問題が起きたら、通信がコアに届いているかを見ます。記録がない場合は、ルート、除外範囲、権限を優先して確認してください。記録はあるものの名前解決に失敗する場合はDNSを調べます。アウトバウンドが選ばれた後の接続失敗なら、ノードと宛先を確認します。調査が終わったらTUNを無効にしてネットワークが元に戻ることを確認し、残ったルートをサービスの継続的な障害と誤認しないようにしましょう。

ほかのVPN、コンテナネットワーク、仮想マシン、業務用トンネルは、TUNのルーティング範囲と競合することがあります。見覚えのないシステムルートを直接削除せず、まず今回追加した通信取り込みを停止して動作を比較してください。必要に応じてクライアントのルート除外機能を使い、除外された通信は現在のコアを経由しないことを理解しておきましょう。TUNの目的は入口の対象範囲を補うことであり、設定の境界をなくすことではありません。どの通信が取り込まれ、どの通信が除外されるかを説明できれば、この段階は完了です。

8. 日常のメンテナンス：ログ、バックアップ、更新

時系列でリクエストとエラーを照合する

メンテナンスでは、再現できる記録が役立ちます。問題が起きたら、発生時刻、使用中のネットワーク、宛先ドメイン、クライアントのモード、そのときのプロキシグループ選択を記録してから、対象を明確にしたリクエストを1回実行してください。接続確立のタイムアウト、名前解決の失敗、リモート側からの切断、設定解析エラーは、発生する段階が異なります。最後の1行だけでは前提となる原因を見落とし、正常な再試行を継続的な障害と誤認することがあります。

通常は適切なログレベルを維持し、問題を再現するときだけ一時的に詳細度を上げましょう。詳細ログにはドメイン、アドレス、プロセス名、設定に関する情報が含まれる場合があるため、保存や共有の範囲を制限してください。再現が終わったら通常のログレベルに戻し、アクセスに関する情報を長期間記録し続けないようにします。よくあるエラーの読み方はClashの実行ログを使ったトラブル対処を参照してください。エラーの語句を検索するだけでなく、どの段階で起きたかに注目しましょう。

速度が遅いときは測定対象を分ける

接続できても、期待どおりの速度が出るとは限りません。速度低下の原因には、接続先のサービス、プロキシサーバーの負荷、出口までの経路、ローカルの無線ネットワーク、アプリ自体の動作などがあります。まず同じデバイスで直接接続とプロキシ経由を比較し、次に同じ設定のままアウトバウンドを変えて比較してから、ローカルネットワークやほかのアプリの通信量を確認しましょう。プロキシグループのテストでわかるのはテスト先の応答状況です。大容量ダウンロードの速度や、その日の利用時間全体の状態を直接示すものではありません。

テストでは、宛先、時間、ネットワーク条件をできるだけそろえてください。ノードの変更、DNSの切り替え、TUNの有効化、ルール変更を同時に行うと、どの変更で改善したのかわからなくなります。速度が遅いときの段階的な確認方法に沿って一つずつ比較し、必要な結果を記録しましょう。特定のWebサイトだけに起きる問題なら、該当ルール、CDNの経路、接続の再利用を確認します。すぐにクライアントを再インストールしたり、すべての設定をリセットしたりする必要はありません。

バックアップは配信元と上書き設定も含める

有効なバックアップには、YAMLファイルだけでなく、サブスクリプションの配信元、クライアントの設定マージ方法、手動ルール、プロキシグループの選択、必要なシステムへの通信取り込み設定も含めます。機密情報は保護された場所に保管し、公開リポジトリや信頼できない共有フォルダーに置かないでください。各ファイルの用途を判別できることを確認し、変更前に新しい復元ポイントを作ります。どのファイルが実際に適用されていたか分からないバックアップは、復元時に再び調査が必要です。

クライアントの更新とサブスクリプションの更新は、別々の操作です。クライアントの更新では画面、コア、権限管理が変わる場合があり、サブスクリプションの更新ではリモート設定が変わります。更新は分けて行い、一方を更新したら起動、設定の読み込み、よく使う宛先、LAN接続を確認してから、もう一方に進みましょう。画面の表示が変わっただけでコアも更新されたと判断したり、互換性を確認せずにアプリ内のファイルを手動で置き換えたりしないでください。元に戻す場合は、元の配布元と保存済みの設定を使います。

ネットワーク切り替え、スリープ、正常な終了

有線からWi-Fi、家庭のネットワークからモバイルホットスポットへ切り替えたときや、スリープから復帰したときは、アウトバウンド用インターフェース、DNS、ルーティングが変わる場合があります。まずクライアントがインターフェースを再検出したか確認し、次に通信の取り込みを正常に停止して再度有効にします。特定のネットワークだけで失敗する場合は、そのネットワークの認証ページ、アクセス制限、ほかのVPNを比較しましょう。ローカルルールをすべて削除する必要はありません。モバイルではバックグラウンドのプロセスがOSに終了されていないかも確認してください。

正常に終了する前にシステムプロキシやVPNによる通信取り込みを停止し、アプリの停止表示を確認してから終了してください。異常終了後にネットワークが使えない場合は、システムプロキシが停止済みのローカルポートを指していないか確認し、クライアントが提供する方法でサービスやルートを復旧します。アンインストール前にも同じ手順を行ってください。メンテナンスの目的はプログラムを終了させないことではありません。起動時、停止時、障害発生時にシステムネットワークへどのような影響が出るかを把握することです。

9. 応用編：再利用できる設定と動作範囲

設定ファイルを増やし続けるのではなく、役割ごとに分ける

基本的な接続ができるようになったら、設定の整理から応用に進みましょう。リモートのノード配信元、プロキシ選択、用途別ルール、ローカル環境の設定を分けて管理します。ノードはサブスクリプションに応じて変わり、プロキシグループは選択方法、ルールは通信先、ローカルの上書き設定はポート、DNS、通信の取り込みを受け持ちます。設定を分けておけば、サブスクリプションを変更するたびにルールを作り直したり、別のデバイスに移行するとき環境依存の項目を見失ったりせずに済みます。ファイルを分割するだけではなく、クライアントのマージ方法を理解することが前提です。

proxy-providersはプロキシの配信元を管理し、rule-providersはルールの配信元を管理します。互いの代わりにはなりません。導入前に内容の形式、更新先、キャッシュ場所、参照名を確認し、初回ダウンロードに失敗したときの動作も調べてください。リモートリソースを使うと起動時の依存関係が増えるため、まだ確立していないプロキシを通さないと基本設定を取得できない構成は避けましょう。キャッシュが残っていても内容が常に有効とは限りません。更新と復旧の経路を明確にしてください。

複合プロキシグループの運用コストを理解する

入れ子のプロキシグループを使うと、用途別の選択と個別ノードを分けられますが、階層が深すぎると最終的なアウトバウンドが見えにくくなります。まず明確な手動選択グループを作り、必要に応じて自動テストやフェイルオーバーを追加しましょう。階層を増やすたびに、候補、テスト経路、既定の選択を確認します。自動切り替えは通常、新しい接続に影響します。既存のセッションが途切れないとは限りません。長時間接続を使うアプリでは、グループ名の表示だけで判断せず、実際に利用して確認してください。

ルールセットの管理でも、内容を確認する習慣を保ちましょう。サードパーティのルールセットは範囲、更新頻度、分類方法がローカルの用途に合わないことがあり、大きすぎるセットは起動とメンテナンスの負担にもなります。まず必要なローカル例外を残し、リモートのルールセットより前か後かを明確にしてから、分類ルールを段階的に導入してください。業務上重要な宛先については、想定するアウトバウンドと確認方法を記録します。リモートルールが変わった後に、使用感だけで原因を推測することを避けられます。

外部コントロールインターフェース：必要な範囲だけ公開する

外部コントロールインターフェースは、クライアントや管理ツールが状態を確認し、プロキシグループを切り替え、設定を更新するために使います。権限は通常のプロキシ入口より強いため、自分のデバイスだけで使う場合はループバックにバインドし、インターネットへ直接公開しないでください。以下はトップレベルの項目1つの構造例で、手動でインターフェースを有効にする指示ではありません。GUIクライアントがアドレスや認証を管理していることがあります。変更によって画面から操作できなくなったり、制御が競合したりしないよう、先にクライアントの説明を確認しましょう。

# ループバックへのバインド例のみ。認証とアクセス制御の代わりにはなりません
external-controller: 127.0.0.1:9090

複数デバイスから管理する場合は、待ち受けアドレスを変えるだけでなく、保護された接続経路、認証、ファイアウォール、最小限の公開範囲を先に設計してください。プロキシの入口、コントロールインターフェース、DNSの待ち受けは別々のサービスです。それぞれのバインド範囲と権限を確認しましょう。コントロールインターフェースの認証情報を公開用の例、スクリーンショット、問い合わせ内容に含めないでください。ループバックへのバインドも、ローカルのアプリやスクリプトを信頼できるかどうかの判断に代わるものではありません。

デスクトップクライアントからコア単体の実行環境へ移行する

サーバーやルーターでは、起動引数、設定パス、ファイル権限、ログローテーション、サービス復旧を自分で管理する必要があります。まず重要な環境ではない場所で既知の設定を使って起動し、パスと待ち受け範囲を確認してから自動起動を設定してください。初回起動時にデバイス全体のデフォルトルートをすぐに置き換えるのは避けましょう。特にリモート管理中のマシンでは、通信の取り込みを誤ると操作中の接続が切れるおそれがあります。独立した復旧経路を残し、再起動、ネットワーク切り替え、リソースのダウンロード失敗時の動作も確認してください。

コア単体の設定ではテストモードで読み込み条件を確認できますが、まず使用するバイナリのヘルプで引数を確認し、テストの範囲を理解してください。構文と参照先の確認に成功しても、リモートサーバーへの到達性、ルーティング権限、OSのDNS経路まで正しいとは限りません。通常運用では入口、名前解決、ルールとの照合、アウトバウンドの順に確認します。クライアントが生成したファイルをサーバーへそのままコピーし、相対パス、キャッシュディレクトリ、プラットフォームの違いを見落とさないようにしてください。

説明できる検証結果を応用の基準にする

この段階を終えたら、特定のリクエストについて、どこから入り、どのDNSで名前解決され、どのルールに一致し、どのプロキシグループを通り、どうすれば元に戻せるかを説明できる状態を目指します。明確な用途がない高度な設定は既定のままでかまいません。設定を長くするためだけに複雑さを増やす必要はありません。すぐに接続したい場合は使い方ガイドを、個別の問題を調べる場合はトラブル対処をご覧ください。確認結果をメンテナンス記録に加え、デバイスやネットワークに合った設定を整えていきましょう。