MANUAL / 01—09体系的な確認ガイド

Clash ゼロから応用まで完全使い方マニュアル

クライアント、コア、サブスクリプションの関係から始め、インストール、設定の読み込み、モード選択、ルール分岐、TUN による通信の取り込み、日常の保守、トラブル対処まで順に進めます。実際の操作順に沿って構成しているため、目次から現在の問題を直接探すこともできます。

クライアントを選ぶ クイックガイドを見る

1. 基本概念：クライアント、コア、サブスクリプションを区別する

3つの構成要素はそれぞれ異なる役割を担う

普段「Clash」と呼ばれるものは、GUI クライアント、プロキシコア、または Clash 設定形式に対応したツール群全体を指す場合があります。操作を始める前に、まず3者を分けて考えましょう。クライアントはウィンドウ、トレイメニュー、設定管理、システム権限への入口を提供します。コアは設定を読み込み、ローカルポートで待ち受け、ルールを実行してネットワーク接続を確立します。サブスクリプションサービスはサーバー情報、プロキシグループ、ルールを提供します。クライアントをインストールしただけで利用可能な接続先が得られるわけではなく、サブスクリプションを読み込んだだけでアプリの通信がプロキシを経由するわけでもありません。

Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu は、いずれも GUI を備えたクライアントです。クライアントには mihomo などのコアが組み込まれている場合があり、コアを切り替えられるものもあります。mihomo には、かつて使われていた Clash Meta という名称からの経緯があります。設定項目の認識、DNS 処理、ルール実行、TUN の処理を担うのがコアです。画面上のスイッチは最終的にコアのパラメーターや OS のネットワーク設定へ変換されるため、同じ機能でもクライアントによって名称や場所が異なることがあります。判断の基準は、生成された設定とコアのログに置いてください。

サブスクリプションは独立した提供元です。サブスクリプション URL は通常、利用者が選んだサービスから提供されるもので、当サイトやクライアントプロジェクトがインストール完了後に自動提供するものではありません。1つのサブスクリプションにノード、プロキシグループ、リモートルールセット、DNS 設定が含まれる場合もあれば、基本的なノード一覧だけの場合もあります。「クライアントは起動するのに選択できるプロキシグループがない」ときは、クライアントを何度も再インストールするのではなく、まずサブスクリプションの内容が完全か確認します。

アプリから出口までの基本的な通信経路

システムプロキシを使う場合、アプリは OS の HTTP または SOCKS プロキシ設定を読み取り、クライアントが待ち受けるローカルポートへリクエストを渡します。コアは設定されたモードに従ってリクエストを処理します。ルールモードでは上から順にルールを確認し、最初に一致した項目が DIRECT、REJECT、またはプロキシグループのいずれかを決めます。グローバルモードでは通常、プロキシ可能な通信の大半を指定したプロキシグループへ渡します。ダイレクトモードでは対応する通信を宛先へ直接接続します。TUN モードは仮想ネットワークインターフェースを作成し、よりネットワーク層に近い位置で通信を取り込みますが、DNS、ルーティング、ルール評価は引き続き必要です。

つまり、「クライアントが起動している」「ローカルポートが待ち受けている」「システムプロキシが有効」「対象アプリが実際にシステムプロキシを使っている」「ルールが利用可能な出口を選んでいる」は、5つの異なる状態です。ブラウザーでページを開けても、それはブラウザーの現在の経路が成立していることしか示しません。ターミナル、ゲーム、仮想マシンも同じ経路を使っているとは限りません。トラブル対処では、アプリ設定、OS のプロキシ、ローカル待ち受けポート、コアのルール、リモート接続の順に確認し、クライアントのメイン画面にある1つの状態表示だけを見て判断しないでください。

クライアントとコア

設定、プロキシグループ、ノード

ノードは具体的な接続出口を表します。プロキシグループは、1つ以上のノード、ダイレクト接続、または別のプロキシグループを選択可能な行き先としてまとめます。ルールは、特定のリクエストをプロキシグループへ渡します。ルール内の PROXY はプロキシグループ名の例であり、proxy-groups に同名の定義が存在しなければなりません。

検証できる最小限の理解を身につける

初回から大量の YAML を変更する必要はありません。まずは最小限の流れを完成させます。利用するプラットフォームに合ったクライアントをインストールし、提供元が明確なサブスクリプションを読み込み、設定とプロキシグループを選び、いずれかの通信取り込み方法を有効にして、ブラウザーとターミナルで別々に確認します。この流れを終えてからルールの適用範囲、DNS、TUN を学ぶと、複数の変数を同時に増やさずに済みます。その後の変更も同じ原則で行います。1回に1つの層だけを変更し、変更前の設定を残し、変更後に現れたログやアクセス結果を記録します。

2. クライアント選び：プラットフォームと保守方法で判断する

まず操作の入口を選び、高度な機能を確認する

クライアントは、単純な性能ランキングではなく、OS、インストール方法、日常の保守習慣を基準に選びます。初めて使う場合は、一般的なデスクトップ・モバイル環境に対応し、GUI からサブスクリプション管理、プロキシ選択、接続制御を行える Clash Plus が候補になります。Windows、macOS、Linux で複数の設定を管理したい場合は、Clash Verge Rev と FlClash も比較できます。Windows では Clash Nyanpasu も選択肢です。アーカイブ済みのクライアントは動作する可能性がありますが、継続的な互換性更新が必要な環境には向きません。

Android では Clash Plus のほか、端末のアーキテクチャや操作習慣に応じて Clash Meta for Android、FlClash、Surfboard も検討できます。iOS の主な入口は Clash Plus です。Linux デスクトップでは Clash Verge Rev または FlClash、サーバー、ルーター、GUI のない環境では mihomo コアの直接導入が適しています。対応プラットフォームと現在のインストールパッケージはダウンロードページから確認し、デスクトップクライアントの手順をコマンドライン用コアにそのまま当てはめないでください。

利用環境ごとの選択ポイント
利用環境 優先して確認する項目 適した入口 その後の保守ポイント
個人用デスクトップ システムアーキテクチャ、システムプロキシ、TUN 権限 Clash Plus、Clash Verge Rev、FlClash サブスクリプション更新、自動起動、コアの互換性
Android プロセッサーアーキテクチャ、VPN 許可、バックグラウンド制限 Clash Plus、Clash Meta for Android、FlClash、Surfboard バッテリー設定、アプリごとの分岐、ネットワーク切り替え
iOS ストアの入口、VPN 構成の許可 Clash Plus 必要時の接続、設定更新、システム制限
GUI のない Linux アーキテクチャ、サービスアカウント、設定ディレクトリ mihomo コア systemd、ログ、権限、リモート制御の範囲

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

Windows の一般的な端末は x64 アーキテクチャを使用します。ダウンロードページで実際に提供されているビルドに合わせてインストールパッケージを選んでください。macOS では Apple Silicon と Intel を区別します。「この Mac について」でチップまたはプロセッサー情報を確認し、Apple チップなら ARM ビルド、Intel プロセッサーなら x64 ビルドを選びます。Android では端末情報や信頼できるハードウェア情報画面で ARM64、ARM、汎用パッケージのいずれに対応するかを確認します。新しい端末の多くは ARM64 ですが、OS のバージョンだけで判断してはいけません。

Linux ではディストリビューションのパッケージ管理方式も合わせる必要があります。Debian、Ubuntu とその派生システムでは通常 .deb、Fedora、RHEL 系では通常 .rpm を使います。単体のコア圧縮パッケージを使う場合は、設定ディレクトリ、サービスファイル、更新手順を自分で用意します。GUI クライアントと単体コアの違いは、ウィンドウの有無だけではありません。前者は権限要求、システムプロキシの書き込み、コアのライフサイクルを代行することが多い一方、後者では起動ユーザー、作業ディレクトリ、ログ、再起動方針を明確に管理する必要があります。

機能ではなく実際の操作フローを確認する

ブラウザーや一般的なデスクトップアプリだけでプロキシを使うなら、複雑な書き換え機能より、安定したシステムプロキシ制御とサブスクリプション更新のほうが重要です。システムプロキシを読み取らないアプリも取り込みたい場合は、クライアントが TUN、権限のインストール、ルーティングの復元に対応しているか確認します。複数のサブスクリプションを頻繁に管理するなら、設定の切り替え、書き換え、サブスクリプション更新、バックアップの入口が分かりやすいか確認してください。画面にスイッチがあるからといって、現在のコアがすべての項目に対応しているとは限りません。高度な設定の可否は、コアのバージョン、設定形式、OS の制限に左右されます。

選定のゴールは、機能が最も多いクライアントを見つけることではありません。インストールパッケージがプラットフォームに合い、よく使う入口を理解でき、サブスクリプションを保守でき、問題発生時にログを確認できることが重要です。まだ迷う場合はプラットフォームと利用習慣でクライアントを選ぶを読み、その後ダウンロードページに戻ってインストールしてください。

3. インストールと権限：復旧できる実行環境を整える

デスクトップ環境でのインストール手順

インストール前に同種のプロキシソフトを終了し、現在のシステムプロキシ設定を記録して、インストールパッケージとシステムアーキテクチャが一致していることを確認します。Windows では初回起動時に、ファイアウォールがネットワークアクセスの範囲を尋ねることがあります。実際に必要なネットワーク種別だけを許可し、ローカルプロキシの待ち受けのためにパブリックネットワークからの受信を開放する必要はありません。クライアントに「サービスモード」や補助サービスがある場合、それはルート変更、TUN の実行、自動起動に必要な権限を得るためのものです。クライアント内蔵の入口からインストールし、不明な場所からサービスコンポーネントを個別に取得しないでください。

macOS ではアプリを「アプリケーション」フォルダへ移してから初回起動します。ダウンロードフォルダから長期間実行すると、パスや権限情報が変わる可能性があります。アプリの安全確認、ネットワーク拡張、VPN 構成、キーチェーンアクセスの確認が順に表示されることがあります。これらは異なる機能に対応しています。VPN 構成は TUN や Network Extension、キーチェーンの確認は認証情報の保存、ネットワーク拡張は通信の取り込みに関係します。すべての通知を同じインストールエラーと考えず、利用する機能に応じて許可してください。詳しくはmacOS の権限に関する説明を参照してください。

Linux の GUI クライアントをディストリビューションのパッケージでインストールしたら、デスクトップメニューから一度起動し、ログディレクトリへ書き込めるか確認します。.deb ファイルを使う場合は、ファイルのあるディレクトリで次を実行します。

sudo apt install ./client-package.deb

上記のファイル名は、実際にダウンロードしたパッケージ名へ置き換えてください。パッケージマネージャーは依存関係を解決するため、低レベルのインストールコマンドを直接呼び出すより不足コンポーネントを処理しやすい場合があります。RPM 系では、対象ディストリビューションに対応したパッケージ管理コマンドを使います。GUI のない環境で mihomo を導入する場合は、GUI クライアントのディレクトリ構成を流用しないでください。設定ディレクトリを個別に作成し、実行アカウントを決め、制御ポートへのアクセス範囲を制限します。

モバイル環境でのシステム権限

Android と iOS は通常、システム VPN インターフェースを使って通信を取り込みます。初回接続時に表示される VPN の許可は、OS が仮想ネットワーク経路を作るために必要な手順であり、サブスクリプションの検証に成功したことを意味しません。Android ではバッテリー最適化とバックグラウンド動作の設定も確認します。ロック画面後にクライアントが停止すると、接続が切れたり、予定した更新が実行されなかったりします。必要なバックグラウンド動作を許可したら、異なるネットワーク間の切り替えで復旧できるか確認してください。最初から常時 VPN、アプリごとの分岐、複雑な DNS の書き換えを同時に有効にしないことが大切です。

一部の Android では「常時接続 VPN」や VPN を経由しない接続の制限を設定できます。こうしたシステム設定を有効にする前に、通常モードでクライアントが安定して接続できることと、無効化する入口を確認してください。サブスクリプションの期限切れや DNS 設定の誤りが起きると、すべてのアプリが通信できなくなる一方、プロキシの失敗なのかシステムの強制設定なのか判別しにくくなります。

初回起動後の基準チェック

インストール直後は TUN を有効にしないでください。クライアントのログまたは実行状態画面を開き、コアが起動できること、設定ディレクトリを読み書きできること、ローカル待ち受けポートが競合していないことを確認します。一般的な待ち受けには HTTP、SOCKS、mixed ポートがありますが、具体的な値は現在の設定に従います。「address already in use」のようなログが出た場合は、他のプロセスがポートを使用しています。古いプロキシソフトを終了するかポートを変更し、接続ボタンを何度も押さないでください。

次に終了時の挙動を確認します。ウィンドウを閉じてもトレイに隠れるだけの場合があり、完全に終了するにはトレイメニューを使います。クライアントをアンインストールまたは切り替える前に、システムプロキシと TUN を無効にしてからコアを終了します。これにより、クライアントはルートとシステムプロキシの状態を復元できます。異常終了した場合は、OS のネットワーク設定でプロキシアドレスがまだローカルポートを指していないか確認し、仮想ネットワークインターフェースが残っていないか調べます。

GUI のない Linux でサービス化する原則

サーバーで mihomo を実行するときは、まずフォアグラウンドで設定を読み込み、エラーを確認します。問題がないことを確かめてから systemd に移行してください。サービスファイルには実行ファイル、作業ディレクトリ、設定ディレクトリを明示し、必要最小限の権限を持つアカウントを使用します。設定で外部制御インターフェースを有効にする場合、待ち受けアドレスは原則としてローカルに限定します。リモート管理が必要なときは、管理されたネットワークとアクセス制御を通じて入口を提供してください。デスクトップとサービス環境の違いについてはLinux の導入ガイドも参照できます。

4. サブスクリプション設定：読み込み、選択、更新、書き換え

読み込みは設定を取得するだけ

サブスクリプション URL は通常、クライアントが読み取れる設定またはノードの集合を返します。読み込み時は、クライアントの設定、サブスクリプション、Profiles 画面で「URL から読み込む」を選び、提供元が明確な URL を貼り付け、ダウンロードと解析が終わるまで待ちます。読み込みに成功した後は、その設定を現在の設定として適用し、プロキシグループに選択肢があるか確認します。設定一覧に名前が表示されても、切り替え後にコアがエラーを出すなら、解析ログで具体的な項目を確認してください。「ダウンロード成功」を「設定が実行可能」と同一視しないことが重要です。

サブスクリプション URL にはアクセス権が付いている場合があるため、機密情報として扱います。公開スクリーンショット、ログ共有ページ、質問掲示板などに貼らないでください。トラブル対処が必要な場合は、URL とノードの認証情報を隠し、エラー項目、ルール構造、関連ログだけを残します。URL が失効している、ログインページを返す、ネットワークでリダイレクトされるといった場合、クライアントが YAML 解析エラーを出すことがあります。まずサービス提供元の管理画面でサブスクリプションの状態を確認し、解析に失敗したレスポンスを無理に書き換えないでください。

完全な設定の主な構造を理解する

一般的な設定には、待ち受けポート、実行モード、DNS、ノード、プロキシグループ、ルールが含まれます。以下の断片は最小限の構造関係を示すもので、サーバーアドレスと認証情報は例にすぎず、そのまま接続には使えません。

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

proxies:
  - name: Example-Node
    type: socks5
    server: 192.0.2.10
    port: 1080
    username: demo-user
    password: "your-password"

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - Example-Node
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,PROXY

mixed-port は一般的な HTTP と SOCKS のプロキシリクエストを同時に受け付けます。mode: rule はルールに従って評価することを示します。proxy-groups は PROXY という名前のプロキシグループを定義し、最後の MATCH は前のルールに一致しなかった通信を受け取ります。ここでの PROXY はコアが自動生成する出口ではありません。プロキシグループを削除して MATCH だけ残すと、参照エラーになります。no-resolve は、その IP ルールを処理するときに一致判定のための名前解決を積極的に行わないことを示し、すべての DNS を無効にするという意味ではありません。

サブスクリプション更新前にリモート内容とローカル変更を区別する

サブスクリプションから生成された設定を直接編集しても、通常は一時的にしか反映されません。次回更新時に、クライアントがリモート内容でローカルコピーを上書きするため、手動で追加したルール、DNS、プロキシグループの項目が消える可能性があります。長期的に残したい変更は、クライアントが提供する書き換え、マージ、スクリプト機能を優先して使います。安定した書き換え機能がない場合は、変更後の設定を独立したローカルファイルとして保存し、サブスクリプション更新に自動追従しない分の保守負担を受け入れます。

更新前に、現在利用できる設定、プロキシグループの選択、重要な書き換えを記録します。更新後はまず設定を解析できるか確認し、次にノード一覧とプロキシグループの参照を確認し、最後に通信の取り込みを復元します。接続に問題があるとき、更新を連続して何度も実行しないでください。サーバーの応答、ネットワークキャッシュ、クライアントのファイル書き込みが同時に変化し、どの内容がエラーの原因か分かりにくくなります。サブスクリプションの更新頻度も、根拠なく短く設定せず、提供元が許可する適切な間隔にしてください。

現象 優先して確認する項目 次に行うこと
サブスクリプションをダウンロードできない URL の状態、ネットワーク経路、システム時刻 サービスの入口とクライアントログに記録された HTTP ステータスを確認する
ダウンロード後に解析に失敗する 返された内容が YAML か、項目のインデントが正しいか 最初の解析エラー行を特定し、複数箇所を同時に変更しない
選択できるプロキシグループがない プロキシグループとノードの参照 サブスクリプションがノード一覧だけを返していないか確認する
更新後に自作ルールが消える 変更をサブスクリプションのコピーへ直接書き込んでいないか 書き換え機能または独立したローカル設定へ移行する

設定検証は3つの層に分ける

構文検証は YAML を解析できることしか示しません。参照検証では、プロキシグループ、ノード、ルールの対象がすべて存在することも確認します。実行検証では、ポート、DNS、権限、リモート接続を調べます。クライアントが「設定は有効」と表示してもアクセスできないことは矛盾しません。前2層しか完了していない可能性があるためです。変更を保存したら設定を再読み込みし、最初のログを確認して、最も早く出たエラーから対処します。サブスクリプションの読み込みに関するよくある問題は、ヘルプセンターで「インストールと設定」カテゴリを探してください。

5. プロキシモード：ルール、グローバル、ダイレクトの範囲

モードはコアが行き先を選ぶ方法を決める

ルールモード、グローバルモード、ダイレクトモードは、プロキシ経路に入った通信をコアが処理する方法です。システムプロキシ、TUN、VPN のスイッチと同じものではありません。システムプロキシと TUN は、どの通信がコアに入る機会を持つかを決め、実行モードはその通信がどの出口を使うかを決めます。モードをグローバルにしても、システムプロキシをまったく読み取らないプログラムが自動的にコアへ入るわけではありません。同様に、TUN を有効にしてダイレクトモードを選ぶと、通信が仮想インターフェースとコアを経由して判断されたうえで、最終的にローカルネットワークへ直接接続される場合があります。

ルールモードは日常利用に適しています。コアはルール一覧を上から順に確認し、対象ドメイン、IP、ポート、ルールセットなどに最初に一致した時点で評価を止めます。ルールは DIRECT、REJECT、または自作のプロキシグループを指定できます。ルールの品質は結果に直結します。広すぎるルールを前に置くと後ろの細かなルールが適用されず、フォールバックルールがないと設定によって挙動が予測しにくくなります。

グローバルモードは、ルールがアクセス問題の原因か一時的に判断したい場合や、短時間だけ出口を統一したい場合に使います。グローバルモードへ切り替えると、通常はグローバル用のプロキシグループまたはノードを選ぶよう求められます。グローバルでは使えるのにルールモードで失敗する場合は、対象がどのルールに一致したか、プロキシグループが利用可能かを確認し、すぐにノード自体の故障と決めつけないでください。グローバルモードを常用すると、本来の分岐方針を迂回し、LAN や直接接続すべきリソースまで不適切な出口へ送る可能性があります。

ダイレクトモードは、ローカルネットワークをすばやく復旧したり、プロキシの前後を比較したり、クライアントを起動したまま一時的にプロキシ転送を止めたりする場合に使えます。クライアントを終了する代わりにはなりません。システムプロキシがローカルポートを指したまま、TUN のインターフェースとルートが残ったままの場合があり、コアが DIRECT を選ぶだけだからです。保守やアンインストールの前には通信の取り込みを無効にしてコアを終了し、ダイレクトへ切り替えるだけで済ませないでください。

モードと通信の取り込み方法は独立した2つの軸
モード 基本動作 適した用途 よくある誤解
Rule ルールを順番に照合して出口を選ぶ 長期的な通信分岐と対象別の処理 ルールモードはすべてのアプリを自動的に取り込むわけではない
Global グローバル用のプロキシ選択へまとめて渡す 短時間の出口統一やルール障害との比較 グローバルモードは TUN ではない
Direct 取り込んだ通信を優先的に直接接続する ネットワーク復旧と比較テスト ダイレクトモードはクライアントの完全終了ではない

システムプロキシはプロキシ設定に従うアプリに適している

システムプロキシを有効にすると、クライアントは通常、OS のプロキシアドレスをループバックアドレスとローカルポートに設定します。たとえば 127.0.0.1:7890 です。ブラウザーや一部のデスクトップアプリはこの設定を読み取りますが、ターミナルプログラムでは環境変数の個別設定が必要なことがあります。アプリ独自のプロキシ設定がシステム設定を上書きする場合もあり、プロキシをまったく無視して直接ネットワーク接続するプログラムもあります。「ブラウザーは正常だがターミナルは失敗する」ときは、モードを切り替える前にターミナルの環境を確認してください。

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7890

curl -I https://example.com

ポートはクライアントが現在待ち受けているものと一致させる必要があります。テストでは現在のターミナルセッションだけに変数を設定し、結果を確認してから shell の設定へ保存するか決めます。sudo、コンテナ、リモートセッションを使うと、環境変数が自動的に引き継がれない場合があります。コンテナ内のループバックアドレスは通常、コンテナ自身を指すため、ホストのアドレスをそのまま使うことはできません。

比較テストで問題の層を特定する

信頼できるモードテストでは、ノードと通信の取り込み方法を変えず、1つの変数だけ切り替えます。まずルールモードで対象が一致したルールを記録し、次にグローバルモードへ切り替えて同じ実際の出口を選びます。両方で失敗するなら、ローカルポート、DNS、ノード接続、システム時刻を確認します。ルールモードだけ失敗するなら、ルールの順序とプロキシグループを確認します。ブラウザーは成功してターミナルが失敗するなら、アプリのプロキシ設定を確認します。詳しい段階別の方法はブラウザーとターミナルのプロキシ診断を参照してください。

6. ルール分岐：上から順にマッチングとプロキシグループを理解する

最初に一致したルールが結果を決める

ルール分岐の要点は、ルールの数ではなく、順序、条件、対象プロキシの整合性です。コアはリストの先頭から確認し、通常は1つに一致すると処理を続けません。広いドメインサフィックスのルールを前に置くと、後ろにある特定サブドメイン用のルールが適用されません。広範囲の IP ルールも、本来は別のプロキシグループへ渡したいアドレスを先に処理する可能性があります。自作ルールは具体的なものから広いものへ並べ、最後に MATCH または同等のフォールバックで未一致の通信を受けます。

rules:
  - DOMAIN,blocked.example,REJECT
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,PROXY

DOMAIN は完全なドメイン名に一致し、単一のホストに適しています。DOMAIN-SUFFIX は指定したドメインとサブドメインに一致します。IP-CIDR はアドレス範囲で照合し、MATCH はフォールバックになります。上の例では、指定ドメインを拒否し、example.org とそのサブドメインを直接接続し、プライベートアドレス範囲も直接接続し、それ以外を PROXY へ渡します。PROXY は定義済みのプロキシグループ名でなければなりません。実際の設定で「ノード選択」など別の名前を使う場合、ルールの対象も完全に同じ名前にします。

プロキシグループがルールの結果を選択可能な出口に変える

ルールは通常、固定ノードへ直接結び付けず、プロキシグループを指定します。select グループでは利用者が手動で選択できます。その他のグループ種別は、コアの対応状況に応じて可用性やあらかじめ定めたロジックでメンバーを選びます。プロキシグループにはノード、DIRECT、別のプロキシグループを含められますが、入れ子の関係は明確にし、複数のグループが相互参照しないようにします。グループ名を変更するときは、すべてのルールと他のプロキシグループ内の参照も確認してください。

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - Example-Node
      - DIRECT

  - name: AUTO
    type: url-test
    proxies:
      - Example-Node
      - Backup-Node
    url: https://www.gstatic.com/generate_204
    interval: 300

この例は構造関係を示すもので、どのサブスクリプションにも同じノードが含まれることを意味しません。url-test は指定 URL で可用性を検査しますが、結果はその検査先と当時のネットワーク条件だけを反映し、実際のサービス対象の検証に代わるものではありません。検査間隔を短くしすぎると接続数やログが増えます。重要な通信では、挙動を理解しやすいプロキシグループを選び、問題が起きたときに現在のグループがどのメンバーを最終的に選んだか確認してください。

ドメインルールと IP ルールは DNS 経路の影響を受ける

ドメインリクエストがコアに入ると、DOMAIN 系のルールへ直接渡せます。アプリが対象 IP だけを送る場合や、ルールが IP で判断する場合は、DNS の解決と接続段階で得られるアドレス情報が一致結果に影響します。no-resolve は、IP ルールがドメインの一致判定のために解決を開始することを防ぎます。不要な DNS クエリを減らすのに役立ちますが、設定内の DNS サービスを停止するものではありません。fake-ip、ドメインスニッフィング、複雑な DNS 分岐を併用する場合は、クライアントが生成した完全な設定を理解してからルールを追加してください。

LAN アドレスは通常、広範なプロキシルールより前に処理し、ルーター、プリンター、ローカルサービスへのアクセスがリモート出口へ送られないようにします。代表的なプライベートアドレスには 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 があります。ただし企業ネットワークでは、さらに多くの内部ドメインやアドレス範囲が使われることがあります。公開ルールセットを機械的にコピーして現在のネットワークに合うと決めつけず、実際の内部ネットワーク範囲に応じて追加し、テストしてください。

リモートルールセットとローカルルールにはそれぞれ保守コストがある

リモートルールセットは一括更新に便利ですが、ダウンロード URL、形式、更新方針に依存します。ローカルルールは監査しやすい一方、自分で保守する必要があります。リモートルールセットを使う場合は、処理対象のカテゴリ、標準の出口、更新失敗時の挙動を確認します。ローカルルールでは各グループの目的を明記し、重複項目を増やさないようにします。ルールが多いほど分岐が正確になるわけではありません。古いドメイン、重複範囲、到達不能なルールはトラブル対処の負担を増やします。

ルールを安全に調整する手順は、現在の設定をコピーし、具体的なルールを1つ追加し、再読み込みして対象をテストし、同時に影響を受けない対象もテストすることです。問題がないことを確認してから次へ進みます。サブスクリプション更新でルールが上書きされる場合は、クライアントの書き換え層へ移し、リモートルールの前後どちらに置く必要があるか記録してください。

7. TUN モード：取り込み範囲、DNS、ルーティングの確認

TUN は通信をコアへ入れるための機能

TUN モードは仮想ネットワークインターフェースとシステムルートを使い、より多くの IP 通信を取り込みます。システムプロキシを読み取らないアプリ、一部のコマンドラインツール、通信を一括して取り込みたい環境に適しています。ノード自体の接続品質を高めたり、ルールやプロキシグループの代わりになったりするものではありません。通信が TUN に入った後も、DNS 解決、ルーティング判定、ルール評価、出口への接続が必要です。ルールが DIRECT を指定すれば最終的に直接接続できますが、設定や権限に問題があると、システムプロキシより広い範囲に影響する可能性があります。

初回有効化の前に、システムプロキシモードでサブスクリプション、ノード、ルールが基本的に使えることを確認します。その後、他の VPN、プロキシ、ネットワークフィルターを終了し、現在の DNS とデフォルトルートを記録します。クライアントがサービスのインストール、VPN 構成の許可、ネットワーク拡張の有効化を求める場合は、正式な画面から実行してください。有効化後は、LAN アドレス、よく使うドメイン、システムプロキシを使わないプログラムを順にテストします。3つの経路が想定どおり動作してから、自動起動や常時接続を検討します。

一般的な設定項目の役割

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

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

auto-route は必要なルートの書き込みをコアに試行させ、auto-detect-interface は現在の出力インターフェースの識別に使います。dns-hijack は指定した DNS 通信を取り込むよう指示します。stack で利用できる値と挙動は、コアとプラットフォームの影響を受けます。現在のクライアントのドキュメントを確認せず、むやみに切り替えないでください。例にある公開 DNS は項目構造を示すためのもので、実際の選択はネットワークの到達性、プライバシー要件、サブスクリプションの設定を考慮します。サブスクリプションが完全な DNS セクションを提供しているなら、検証していない別の書き換えを重ねないでください。

fake-ip はドメインに対して予約範囲内のマッピングアドレスを返し、コアが後からドメインを復元してルールを適用します。ドメイン情報を保ちやすい一方、LAN サービス、実アドレスを必要とするアプリ、特殊なプロトコルでは除外が必要になることがあります。LAN 機器を検出できない、アプリが異常なアドレスを認識するといった場合は、すべての DNS 機能をすぐに無効にするのではなく、まず fake-ip の除外設定と LAN の直接接続を確認してください。

ノードよりルーティングの競合が原因になることが多い

企業 VPN、仮想マシンのネットワーク、コンテナネットワーク、別のプロキシを同時に使うと、各ツールがデフォルトルート、DNS、仮想インターフェースを奪い合う可能性があります。TUN を有効にすると完全に通信できない、LAN だけ使えない、スリープ復帰後に接続できない、Wi-Fi 切り替え後も古いインターフェースを使い続ける、といった症状が現れます。トラブル対処では、まず他の通信取り込みツールを終了し、TUN を無効にして基礎ネットワークが復旧するか確認します。その後 Clash だけを有効にします。単独で正常なら、他のツールを1つずつ戻し、競合が発生する時点を観察してください。

Windows ではルーティングテーブルとネットワークアダプターを確認できます。macOS ではネットワークサービスと VPN 構成を確認し、Linux ではシステムコマンドでルートとルールを確認します。診断の要点は出力をすべて保存することではなく、有効化前後でデフォルトルート、DNS の向き先、追加されたインターフェースを比較することです。Linux でよく使う確認コマンドは次のとおりです。

ip addr
ip route
ip rule
ss -lntup
resolvectl status

ディストリビューションによっては、すべてのコマンドが用意されていない場合があります。ss ではローカルポート、ip route と ip rule ではルーティング、resolvectl では systemd-resolved を使う環境の DNS を確認できます。用途を理解しないままルートルールを一括削除しないでください。まずクライアントを終了してクリーンアップさせ、次にネットワークサービスまたはシステムを再起動し、最後の手段として手動復旧を検討します。

DNS 障害では名前解決と接続を分けて考える

IP にはアクセスできるのにドメインへアクセスできない場合は、まず DNS を確認します。ドメインは解決できるのに接続できない場合は、ルール、出口、ファイアウォールを確認します。nslookup、dig、または OS 標準の名前解決ツールを使い、システムの解決結果とクライアントログを比較してください。ログに対象リクエストがまったくない場合、問題はアプリ、システムルート、または DNS がコアへ届く前にある可能性があります。リクエストが確認できるのにプロキシが誤っているなら、ルールと DNS 設定へ戻って確認します。

TUN が安定しているかは、起動、終了、スリープ復帰、ネットワーク切り替え、LAN アクセスまで確認して判断します。1回ウェブページを開けただけでは、ルートのクリーンアップや DNS の復元が正常とは限りません。モバイル端末ではバックグラウンドとロック画面の挙動もテストし、デスクトップではクライアント終了後にプロキシとルートが残っていないことを確認します。

8. 日常の保守：更新、バックアップ、ログ、障害復旧

クライアント、コア、サブスクリプションを分けて更新する

クライアント更新、コア更新、サブスクリプション更新は別々の経路です。クライアント更新では画面、権限補助コンポーネント、設定の保存先が変わることがあります。コア更新では対応項目、デフォルト動作、プロトコル機能が変わる可能性があります。サブスクリプション更新ではノード、プロキシグループ、ルールが変わります。日常の保守では、どの層に変更があったか記録し、同じ日に3層すべてを更新して問題の切り分けを難しくしないでください。安定しているときは、まず設定をバックアップし、サブスクリプションを更新して検証します。クライアントやコアを更新する場合は、別途テストの機会を設けてください。

更新前に、サブスクリプション URL、現在のプロキシ選択、ローカルの書き換え、重要な自作ルールを保存します。サブスクリプションが生成した YAML だけでは不十分です。クライアントが書き換え、プロキシ選択、画面設定を別ファイルやデータベースに保存している場合があるためです。クライアントにエクスポート機能があれば優先して使い、ない場合は再構築に必要な情報を個別に記録します。バックアップはクライアントのデータディレクトリ外に置き、アンインストールやキャッシュ削除で一緒に消えないようにします。

ログは再現可能な1回の操作を中心に読む

有効なログには、明確な時間範囲ときっかけとなった操作が必要です。まずログレベルを通常の情報レベルにし、現在時刻を記録またはログをクリアしてから、失敗する操作を1回実行します。直後に該当部分を確認し、設定読み込み、DNS クエリ、ルール一致、プロキシ選択、接続確立、タイムアウトを探します。詳細なデバッグレベルを長時間有効にすると大量の記録が生じ、対象ドメインなどの利用情報が含まれる可能性もあります。トラブル対処中だけ有効にし、完了後は戻してください。

ログを共有する前に、サブスクリプション URL、認証項目、制御インターフェースの認証情報、ノード接続情報を削除します。エラーの種類、対象カテゴリ、ルール名、必要な前後関係だけを残せば十分です。最後の1行だけを切り取ると、本当の原因を失うことがあります。たとえば接続失敗が、より早い DNS エラーによって引き起こされている場合です。トラブル対処では、ログに何度も出る後続エラーではなく、時系列で最初に現れた異常を優先します。

段階的な復旧手順を作る

通信できないときは、まず基礎ネットワークを復旧し、その後にプロキシを戻します。TUN とシステムプロキシを無効にし、ダイレクトへ切り替えるかクライアントを完全に終了して、OS が正常に名前解決とアクセスを行えることを確認します。基礎ネットワークが戻ったらクライアントを起動しますが、最初は通信の取り込みを有効にせず、設定の読み込みとローカルポートを確認します。その後システムプロキシを有効にしてブラウザーをテストし、最後に TUN を有効にします。この順序なら、権限、設定、ノード、ルーティングの問題を分けて確認できます。

特定のサイトやアプリだけが失敗する場合、すぐに再インストールしないでください。同じ対象をダイレクト、ルール、グローバルの各モードで比較し、ログで一致したルールを確認します。アプリに独自のプロキシ設定がないかも確認してください。すべてのノードが同時に失敗するなら、サブスクリプションの状態、システム時刻、DNS、現在のネットワーク制限を確認します。1つのノードだけ失敗するなら、同じプロキシグループの別メンバーへ切り替え、問題をその出口に限定します。よくある質問はヘルプセンターでも確認できます。

実施のタイミング 推奨する操作 確認する結果
サブスクリプション更新後 解析、プロキシグループ、ルール、書き換えを確認する よく使う対象が従来の方針でアクセスできる
クライアントまたはコアの更新後 変更内容を読み、システムプロキシと TUN をテストする 起動、終了、ネットワーク復旧が正常に行われる
OS の大規模アップデート後 権限、ネットワーク拡張、自動起動を再確認する 許可が有効で、ルートを正しく削除できる
端末を移行する前 サブスクリプション情報、書き換え、自作ルールをエクスポートする 新しい端末で最小構成から流れを再構築できる

設定を整理するときは復元ポイントを残す

設定を長期間使うと、重複したサブスクリプション、失効した書き換え、古いルールが互いに影響することがあります。整理する前に、現在利用できる設定をコピーし、疑わしい項目はすぐ削除せず無効化します。しばらく依存していないことを確認してから削除してください。クライアントのキャッシュ、設定データベース、コアディレクトリを一度にすべて削除すると、障害の証拠と復元状態を同時に失います。リセットが必要な場合は、先に必要な内容をエクスポートし、最小構成から検証します。

アーカイブ済みクライアントでは、一時的な修正を積み重ねるより移行を優先します。まず現在のプラットフォームをサポートし、保守が続いているクライアントを選び、元のサブスクリプションを読み込んで基本接続を確認します。その後、ローカルルールと TUN 設定を移します。古いクライアントのディレクトリを直接上書きせず、2つのクライアントが同時にシステムプロキシやルートを制御しないようにしてください。移行が終わったら、古いクライアントの自動起動を無効にし、明確な通信取り込み経路が1つだけ残っていることを確認します。

9. 応用への進み方：使うだけでなく自力で診断できる状態へ

まず設定の読み取りを身につけ、複雑な書き換えはその後に学ぶ

応用の第一歩は、設定断片を集めることではなく、現在有効な設定を読めるようになることです。待ち受けポート、実行モード、DNS、プロキシグループ、ルール、TUN セクションを見つけ、リクエストがどの入口から入り、どのルールに一致し、どのプロキシグループを使い、最終的にどの出口を選んだか説明できるようにします。クライアント画面で一部のデフォルト値が隠れている場合は、エクスポートした設定やコアのログを確認できます。ただし、いつ上書きされるかを理解していない限り、プログラムが自動生成したファイルを直接編集しないでください。

第二歩は、保守しやすい書き換え層を作ることです。LAN の直接接続、特定ドメインのプロキシ方針、DNS の例外、プロキシグループの調整を目的ごとに分け、毎回1グループだけ追加します。ルール名とコメントには一時的な番号ではなく理由を書きます。サブスクリプション更新後に自動マージされる内容は、挿入位置を確認してください。同じルールでもリストの先頭と末尾では結果が大きく異なります。クライアントが YAML マージに対応している場合は、配列が追加、先頭挿入、全置換のどれになるか確認します。

mihomo の機能と設定互換性の境界を理解する

mihomo は Clash 設定エコシステムを基盤に、プロトコル、DNS、ルール、実行機能を拡張しています。ただし、具体的な項目は現在のコアビルドとクライアントへの統合状況にも左右されます。古い設定を移行するときは、まず移行先のコアで構文を確認し、非推奨項目、ルールプロバイダー、DNS 拡張モード、プロキシグループの挙動を照合します。ファイル拡張子が同じという理由だけで、設定をそのまま交換できると考えないでください。背景についてはmihomo と原版 Clash の違いも参照できます。

サーバーやルーターへの導入では、実行ユーザー、ネットワーク名前空間、ファイアウォールの転送、永続ルートも関係します。デスクトップの「TUN を有効化」ボタンは権限やルーティング操作を代行することが多い一方、単体コアでは導入者がこれらを明示的に管理する必要があります。応用構成へ進む前に、まず一般ユーザーの環境で設定の読み込み、DNS、プロキシポートを確認し、その後に透過的な通信取り込みと自動起動サービスを段階的に追加します。設定問題とシステムネットワーク問題を最初から重ねないことが重要です。

大規模な試行錯誤ではなく最小再現を使う

複雑な問題が起きたら、設定をコピーし、入口1つ、検証可能なノード1つ、プロキシグループ1つ、少数のルールまで縮小します。最小設定が動作することを確認してから、DNS、ルールセット、TUN、書き換えを段階的に戻します。各段階の復元後は、設定読み込み、ドメイン解決、ダイレクト対象、プロキシ対象、LAN 対象、終了後のネットワーク復旧という固定テストを実行します。これにより、問題を具体的な設定ブロックまで絞り込めます。

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

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - MATCH,PROXY

この断片はコアの構造とローカル待ち受けを検証するためだけのもので、利用可能なプロキシノードは含みません。PROXY グループには DIRECT しかないため、フォールバックの通信はすべて最終的に直接接続されます。実際のサブスクリプションノードを追加する前に、設定を読み込めること、ポートが待ち受けること、ルールログを確認できることを確かめ、ノードを段階的に追加してください。接続に失敗しても、YAML 構造やローカルポートが原因ではないと判断しやすくなります。

固定の診断ツールセットを整える

デスクトップでもサーバーでも、待ち受けポートの確認、ドメイン解決、HTTP リクエストの送信、ルーティングの確認、プロセスの確認、サービスログの読み取りという基本ツールを使えるようにします。Windows ではシステムのネットワークコマンドと PowerShell、macOS と Linux では curl、dig または nslookup、netstat または ss が使えます。ツールの価値は、情報をすべて一度に出力することではなく、「7890 は待ち受けているか」「ドメインはどのアドレスに解決されたか」「リクエストはプロキシを使ったか」といった明確な問いに答えることです。

診断では、各テストの期待結果を書き留めます。LAN アドレスは DIRECT、テスト用ドメインは特定のプロキシグループ、クライアント終了後はシステムプロキシが解除されることを期待します。実際の結果が異なる場合は、該当する層のログを確認します。期待結果のないテストは、「ウェブページが開けば正常」という曖昧な判断につながり、本来直接接続すべき通信が誤ってプロキシへ送られていることにも気づけません。

継続的に学べる順序を作る

このマニュアルを終えたら、「設定構造—ルール順序—DNS 経路—TUN ルーティング—サービス化」の順に学習を進められます。各段階で動作する基準設定を1つ残し、実験はコピー上で行います。まず単一端末のリクエスト経路を理解し、その後にリモートルールセット、複雑なプロキシグループ、ルーターの透過プロキシへ進みます。まずネットワークを復旧できるようになってから、自動起動による通信取り込みを有効にしてください。

特定プラットフォームの権限が関係する問題はインストールの章へ戻り、特定アプリだけ動作しない場合はプロキシモードの章へ戻ります。対象が誤った出口へ進む場合はルールの章へ、全体が通信不能になる場合は TUN と DNS の章へ戻ってください。基本接続をやり直すだけならクイックガイドへ進み、クライアントを変更またはインストールパッケージを再取得する場合はクライアントダウンロードページを使います。このように層ごとに確認し直すほうが、再インストールを繰り返すより証拠を残しやすく、再現可能な結果につながります。