Clash使い方ガイド｜インストール・ルール分岐・TUN設定 | Clashプロキシクライアントダウンロード・利用ガイド

CHAPTER 01

まずClashの基本概念と通信経路を理解する

クライアント、コア、設定ファイルは別の層

普段Clashと呼んでいるものは、実際には3種類の要素を指すことが多いです。1つ目はClash Plus、Clash Verge Rev、FlClash、Clash NyanpasuなどのGUIクライアントで、設定管理、トレイメニュー、システムプロキシの切り替え、サービスのインストール、ログ表示を担います。2つ目はネットワーク接続を処理するコアで、現在よく使われるクライアントの多くはmihomoを採用しています。コアはポートの待受、ルール解析、プロキシの選択、接続の確立、DNS処理を担当します。3つ目はYAML設定ファイルで、ポート、ノード、プロキシグループ、ルール、DNSの動作を記述します。

この3つの層は分けて判断する必要があります。画面が開くのは、クライアントが起動したことを示すだけです。コアが実行中になって初めて、ローカルのプロキシポートが待受を開始したと分かります。ブラウザーで対象サイトを開くには、システムの通信が実際にそのポートへ入り、ルールが有効なポリシーを選び、ノード接続とDNS名前解決も成功していなければなりません。「Clashは起動しているのにネットにつながらない」問題の多くは、インストーラーではなく、コアの後段にあるいずれかの層で発生しています。

設定ファイルとサブスクリプションは同じものではありません。サブスクリプションURLは通常サービス提供者が発行し、クライアントがURLへアクセスして設定内容を取得し、ローカル設定として保存します。単一ノードのリンクは1台のサーバーだけを記述するため、完全なプロキシグループやルール分岐を自動的に含むとは限りません。ローカルのYAMLファイルは完成済みの設定として直接登録できますが、その後の自動更新はクライアントの管理方法に左右されます。形式をさらに確認したい場合は、サブスクリプションURL・YAML設定・一般的な登録形式を参照してください。

アプリのリクエストから最終出口までの通信経路

ブラウザーでHTTPSサイトにアクセスする場合、まずドメイン名をアドレスへ解決します。続いてブラウザーがTCPまたはQUIC接続を確立し、システムのプロキシ設定または仮想NICのルーティングによってClashへ渡されます。コアは対象ドメイン、アドレス、ポート、プロセスなどの情報を読み取り、ルールを上から順に照合します。ルールに一致すると、リクエストは対応するプロキシグループへ渡されます。グループがノードを直接選ぶ場合もあれば、別のグループを参照して最終的に「プロキシ」「直接接続」「拒否」といった動作を決める場合もあります。

トラブル対処では、通信経路の順番に沿って確認します。アプリがシステムプロキシに従っているか、またはTUNが通信を接管しているか。ローカルの待受ポートが存在するか。ドメインが正しく解決されているか。ルールが想定した項目に一致しているか。プロキシグループが利用可能な出口を選んでいるか。リモートノードが接続を確立できるか。途中の層を飛ばしてノードを何度も替えるだけでは、一時的に問題を隠せても、システムプロキシ、DNS、ルール設定の誤りは解決できません。

層	主な役割	主な確認場所	典型的な異常
クライアント画面	設定管理、システム連携、状態表示	ホーム、設定画面、トレイメニュー	起動できない、権限が付与されていない
プロキシコア	ポート待受、ルール照合、接続転送	実行状態、コアログ	ポート競合、設定の解析失敗
システム接管	アプリの通信をコアへ送る	システムプロキシ、VPN、TUNの状態	一部のアプリがプロキシを経由しない
プロキシ出口	直接接続、プロキシノード、拒否を選択	プロキシグループ、接続履歴、ルール一致	ポリシーの選択ミス、ノードが利用できない

CHAPTER 02

クライアントを選び、各プラットフォームにインストールする

まずプラットフォームと接管要件で選ぶ

GUIクライアントの役割は、サブスクリプションの内容を変えることではなく、設定管理とシステム接管を簡単にすることです。本サイトのダウンロード一覧では、Clash PlusをWindows、macOS、Android、iOS向けの第一候補として案内しています。複数の主要プラットフォームで似た操作感を保ちたい方に適しています。WindowsとmacOSではClash Verge Rev、FlClashも選べます。WindowsではClash Nyanpasuも利用でき、開発終了済みのClash for Windowsのアーカイブ入口も残しています。macOSには開発終了済みのClashX Metaもあります。AndroidではClash Meta for Android、FlClash、Surfboard、LinuxデスクトップではClash Verge RevとFlClashを選べます。

選ぶ際は画面の見た目だけを基準にしないでください。現在のシステムアーキテクチャに対応するインストーラーがあるか、必要なコアをサポートしているか、システムサービスをインストールできるか、TUN接管に対応しているか、サブスクリプション更新とログ確認が分かりやすいかを確認します。ブラウザーやシステムプロキシに従う少数のアプリだけを使うなら、通常のシステムプロキシで十分です。コマンドライン、ゲームランチャー、仮想マシンの補助プログラム、システムプロキシを参照しないアプリまで接管するなら、TUNを安定して管理できるクライアントを優先してください。

サーバーやルーターではmihomoコアを直接動かすことが多い一方、設定ファイル、プロセス権限、起動サービス、ログローテーションを自分で管理する必要があります。一般的なデスクトップ利用者が「より軽量だから」とGUIクライアントを避ける必要はありません。後の管理コストが、節約できる画面リソースを上回ることが多いためです。完全なパッケージ一覧、プラットフォーム別の入口、開発終了状況はクライアントダウンロードページを確認してください。

Windows・macOS・Linuxのインストールで重視する点

Windowsでは、インストール前に古いプロキシソフトがまだ動作していないか確認します。複数のプログラムが同じポートを同時に待ち受けると、新しいコアの起動に失敗します。また複数のプログラムが順番にシステムプロキシを書き換えると、画面では有効に見えても、システムが実際には別のポートを指すことがあります。古いクライアントを終了してから新しいクライアントをインストールし、初回起動時はシステムのセキュリティ通知で通信を許可してください。システムサービスやTUNを使う場合は、通常クライアント内でサービスをインストールし、システム権限を確認する必要があります。サービスのインストール成功とTUNの有効化は別の状態なので、混同しないでください。

macOSでは、インストール後にアプリの入手元やネットワーク拡張の権限を求められたら、システム設定で許可します。Apple SiliconとIntelではソフトウェアパッケージのアーキテクチャが異なるため、「このMacについて」のチップ情報に合うものを選んでください。システムプロキシはmacOSのプロキシ設定に従う接続だけを処理します。高度な接管機能を有効にすると、VPN構成の追加やネットワーク拡張の許可を求められることがあります。許可を拒否した場合は、プライバシーとセキュリティ、ネットワーク、VPN関連の画面に戻って確認し、起動ボタンを連打しないでください。

Linuxの違いは主に、ディストリビューションのパッケージ形式、デスクトップ環境、権限モデルにあります。DebianやUbuntu系では通常debパッケージを使い、その他のディストリビューションではクライアントが提供する互換形式を選べます。インストール後に画面は起動するのに通信を接管できない場合は、デスクトップのシステムプロキシが実際に書き込まれているか、現在のセッションが関連設定を読み込んでいるか、TUNに必要なネットワーク管理権限があるかを確認します。サーバー環境でコアを動かす場合は、設定ディレクトリとログディレクトリを専用サービスアカウントからアクセスできるようにし、対話型ターミナルのプロセスを長時間維持する運用は避けます。

AndroidとiOSの接管方式

AndroidクライアントはVpnServiceでローカルVPNインターフェースを作成し、端末の通信をコアへ渡します。初回接続時にはシステムのVPN許可画面が表示され、承認して初めて通信を接管できます。画面ロック後の切断や、ネットワーク切り替え後に動かなくなる問題の多くは、省電力設定、バックグラウンド制限、メーカー独自の自動終了機能が原因です。クライアントのバックグラウンド実行を許可し、システム設定でバッテリー最適化の対象外にしてください。具体的な手順はメーカーによって異なります。詳しくはAndroidのVpnService、バックグラウンド実行、省電力設定を参照してください。

iOSはシステムのVPN構成を通じて動作します。Clash Plusをインストールして初めて有効にするときは、VPN構成の追加を許可してください。ステータスバーのVPN表示は構成が接続されたことを示すだけで、実際にアクセスできるかどうかはサブスクリプション、ポリシー、ノードにも左右されます。Wi-Fiからモバイル通信へ切り替えると既存の接続が再構築されるため、短時間の切断はネットワーク切り替えの過程です。長時間復旧しない場合は、いったん接続を停止し、システムのVPN表示が完全に消えてから再起動してください。同じサブスクリプションを何度も登録するのは避けます。

CHAPTER 03

サブスクリプションを登録し、基本設定の構造を理解する

サブスクリプションURL、ノードリンク、YAMLファイルを区別する

サブスクリプションURLは通常HTTPS URLで、アクセスするとClashで使える設定、またはエンコードされたノード一覧が返ります。最大の利点は更新できることです。サービス提供者がノード、ポリシー、ルールを変更しても、クライアントが再取得すれば新しい内容を受け取れます。ローカルYAMLファイルは静的なスナップショットで、バックアップ、カスタマイズ、オフライン管理に適していますが、元のサブスクリプションが変わっても自動同期されません。単一ノードリンクにはプロトコル、サーバー、ポート、認証情報しか含まれないため、登録後にプロキシグループとルールを手動で作る必要がある場合もあります。

登録前にURLが完全であることを確認し、メッセージアプリによる途中切れや、コピー時の前後の空白がないか確認します。サブスクリプションURLは、ブラウザーの検索欄ではなく、クライアントのサブスクリプションまたは設定登録画面に貼り付けてください。登録後は、設定名、更新日時、プロキシグループが表示されたことを確認し、その設定を現在の有効項目に切り替えます。「ダウンロード成功」だけで「現在の設定に切り替え」が済んでいなければ、コアは以前のファイルを使い続ける可能性があります。

登録失敗のエラーは大きく3層に分けられます。ネットワーク層には接続タイムアウト、ドメイン解決失敗、証明書エラーがあります。サービス層には認証期限切れ、アクセス拒否、HTMLページの返却があります。設定層にはYAMLのインデントエラー、フィールド型の不一致、存在しないプロキシグループの参照があります。クライアントログにHTTPステータスの問題が出ているなら、まずサブスクリプション自体を確認します。特定行の解析失敗なら、ノードを替えるのではなく設定内容を確認してください。

基本設定で最初に知っておきたいフィールド

動作する設定には通常、ローカル待受パラメータ、プロキシノード、プロキシグループ、ルール、DNS設定が含まれます。GUIクライアントでは一部のグローバル項目を独自の設定データベースで管理する場合があり、エクスポートした設定にすべての画面上の切り替えが含まれるとは限りません。以下の例は基本構造を示すもので、実在のサーバー情報は含みません。プロキシノード部分もフィールドの関係を説明するためだけのものです。

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

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,PROXY
  - GEOIP,LAN,DIRECT
  - MATCH,PROXY

mixed-portは同じローカルポートでHTTPとSOCKSの接続を同時に受け付ける設定で、アプリにプロキシを手動入力するときに便利です。ポートを本機だけで待ち受ける場合、一般的なアドレスは127.0.0.1です。allow-lanは、同じLAN上の別端末が現在の端末のプロキシポートへ接続できるかを制御します。本機だけで使うなら無効のままにすると分かりやすいでしょう。modeは全体の照合モードを決め、通常はruleを使います。log-levelはログの詳細度を決めます。通常はinfoにし、トラブル対処時だけ一時的に上げた後、ログが大量に蓄積しないよう元に戻します。

proxiesは具体的な出口を定義し、proxy-groupsは複数の出口を選択式または自動テスト式のプロキシグループにまとめ、rulesは通信をプロキシグループへ渡します。ルールが参照するポリシー名は、大文字小文字や記号を含め、グループ名と完全に一致しなければなりません。グループ名をPROXYから別の名前に変更するなら、その名前を参照するすべてのルールも同時に変更してください。

更新、上書き、ローカル変更の関係

サブスクリプション更新では通常、リモートの内容を再ダウンロードしてキャッシュを上書きするため、生成されたYAMLを直接編集すると次回更新で変更が失われる可能性があります。長期的に残す独自設定は、クライアントが提供するオーバーライド、マージ、スクリプト処理、グローバル拡張機能を優先して使います。これらの機能がない場合は、ローカル設定をコピーして個別に管理できますが、その後のノード変更は自分で同期する必要があります。

更新に失敗しても、すぐに元の設定を削除しないでください。まず最後に使えたキャッシュを残し、サブスクリプションURLが有効か確認してから手動更新を試します。更新後に突然使えなくなった場合は、古いキャッシュへ戻し、プロキシグループ、ルール、DNSのどこが変わったか比較します。適切なクライアントは「リモートサブスクリプション」「ローカルキャッシュ」「現在有効な設定」を区別して管理します。この3つの状態を理解すれば、唯一の利用可能な設定を誤って削除する事態を防げます。

CHAPTER 04

システムプロキシ、実行モード、接続確認を理解する

システムプロキシとClashの実行状態の違い

クライアントがコアを起動すると、ローカルにHTTP、SOCKS、混合プロキシポートが現れますが、OSがすべての通信を自動的にそこへ送るわけではありません。システムプロキシの切り替えは、Windows、macOS、デスクトップ環境のネットワーク設定へローカルプロキシのアドレスを書き込むものです。ブラウザーなどシステムプロキシに従うプログラムはそのポートへ接続しますが、設定を無視するプログラムは直接接続します。つまり「コアが実行中」と「システムプロキシが有効」は別々の条件です。

アプリのプロキシを手動設定する場合、サーバーアドレスには通常127.0.0.1、ポートには設定中のmixed-port、HTTPポート、またはSOCKSポートを入力します。リモートノードのポートをブラウザーに直接入力しないでください。リモート側のプロトコルはブラウザーが対応するHTTPプロキシとは限りません。クライアントがローカルポートを変更した場合は、システムプロキシとアプリ内の手動設定も一致させる必要があります。

一部のコマンドラインプログラムはデスクトップのシステムプロキシを自動的に読み込まず、環境変数を参照します。一時的なテストでは、現在のターミナルにプロキシ変数を設定できます。ターミナルを閉じると通常は無効になるため、プログラムがローカルポート経由で接続できるか確認する用途に適しています。

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

Windows PowerShellでは、現在のセッションに対応する環境変数を設定し、アプリを終了した後に削除できます。プロキシ変数をシステム環境へ長期保存する前に、ポートがクライアントの切り替えで変わらないことを確認してください。クライアントが起動していない間、変数に依存するツールが存在しないローカルポートへ接続し続ける可能性があります。

ルール、グローバル、直接接続モードの役割

ルールモードは設定内のルールを上から順に判定する、日常利用の基本モードです。LAN、よく使うローカルサービス、指定ドメインを直接接続にし、プロキシが必要な通信をプロキシグループへ渡したり、アクセスしたくない対象を拒否したりできます。結果はルールの品質と順序に左右されます。特定サイトだけ出口を誤る場合は、実行モードを変える前に、どのルールに一致したかを確認してください。

グローバルモードは通常、コアに入ったすべての通信を指定プロキシグループへ渡し、短時間の比較テストに適しています。ルールモードではアクセスできず、グローバルモードではアクセスできるなら、ノードと基本経路はおおむね正常で、問題はルール、プロキシグループの参照、DNSマッピングにある可能性が高いです。グローバルモードにしてもOS上のすべての通信が自動的に接管されるわけではありません。プロキシポートやTUNに入っていない接続は処理されません。

直接接続モードは、コアに入った通信を対象へ直接アクセスさせるため、異常がプロキシ出口に関係するかを判断するのに使えます。直接接続でもアクセスできない場合は、DNS、システムネットワーク、対象サービス、ローカルファイアウォールを確認します。トラブル対処が終わったらルールモードへ戻し、一時的なテスト状態を恒久設定と勘違いしないようにしてください。

接続履歴とログで一連の動作を検証する

Webページが開くというだけでは、分流が正しいとは確認できません。クライアントの接続画面では通常、対象ドメイン、対象アドレス、ルールチェーン、最終ポリシーを確認できます。テスト対象へアクセスした後、接続一覧に表示されるかを見ます。記録がなければ通信がコアに入っていない可能性があります。記録はあるものの誤ったポリシーなら、ルールまたはプロキシグループの選択に問題があります。ポリシーが正しいのに接続できない場合は、ノード、プロトコルのハンドシェイク、DNSログを確認します。

ログは最後の1行だけでなく、最初に現れた明確なエラーの前後を読んでください。ポート使用中のエラーはコア起動時、設定参照エラーは読み込み時、ノードのタイムアウトは実際の接続確立時に発生します。ログ上の失敗がバックグラウンドプログラムによるもので、テスト中のブラウザーとは限りません。テスト前にログを消去するか時刻を記録し、1つの操作だけを実行すると確認しやすくなります。

CHAPTER 05

管理しやすいルール、プロキシグループ、DNSを構成する

ルールは上から照合され、順序が優先順位になる

Clashのルールは基本的に「種類、照合内容、適用ポリシー」で構成されます。たとえばDOMAIN-SUFFIX,example.com,PROXYは、対象ドメインがexample.comで終わる場合にPROXYへ渡します。IP-CIDR,192.168.0.0/16,DIRECT,no-resolveは指定アドレス範囲を直接接続にし、このルールの照合時にドメイン解決を積極的に行いません。MATCH,PROXYは、それまでに一致しなかった通信を受けるため、通常はルール一覧の最後に置きます。

コアは最初に一致したルールで照合を停止するため、より具体的な例外は広いルールより前に置きます。たとえば、あるサブドメインだけをプロキシ経由にし、同じ親ドメインのそれ以外を直接接続にするなら、サブドメインルールを先に、親ドメインのサフィックスルールを後に書きます。MATCHを途中に置くと、その後のルールは永遠に一致しません。大規模なルールセットを調整する際は、対象がドメイン、アドレス、プロセスのどのルールに該当するかを判断し、前の広いルールに先取りされていないか確認します。

rules:
  - DOMAIN,api.example.com,PROXY
  - DOMAIN-SUFFIX,example.com,DIRECT
  - DOMAIN-KEYWORD,media,MEDIA
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - GEOIP,LAN,DIRECT
  - MATCH,FINAL

DOMAINは完全なドメイン名に一致し、厳密な例外に適しています。DOMAIN-SUFFIXは親ドメインとサブドメインを対象にでき、一般的に使われます。DOMAIN-KEYWORDは範囲が広く、似た名前のドメインまで誤って対象にしやすいため、慎重に使います。IP-CIDRとIP-CIDR6は対象アドレスを直接照合し、LANや明確なネットワーク範囲に適しています。プロセスルールはOSと通信接管方式に依存します。システムプロキシ環境では常に正確なプロセス情報を取得できるとは限らないため、接続履歴で確認してから使ってください。

プロキシグループは出口を決める層であり、単なるノード一覧ではない

プロキシグループは、ルールと具体的なノードの間にある判断レイヤーと考えられます。selectグループはユーザーが手動で選ぶため、結果が安定しトラブル対処にも便利です。url-testは指定したテストURLと間隔で候補ノードを測定し、条件に合う結果を選びます。fallbackは通常、利用可能性の順に切り替えます。load-balanceは指定した方式で複数の候補へ接続を分配します。高度なパラメータの表示方法はコアやクライアントによって異なるため、設定の検証結果を基準にしてください。

proxy-groups:
  - name: FINAL
    type: select
    proxies:
      - AUTO
      - MANUAL
      - DIRECT

  - name: MANUAL
    type: select
    use:
      - main-provider

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

自動テストが示すのは、クライアントからテスト対象までの接続状況だけで、すべてのWebサイトの体感が同じになるわけではありません。テストURL、ノードの出口、対象サービスの経路は異なる場合があり、動画、ダウンロード、Web閲覧では帯域、遅延の揺らぎ、接続の再利用に対する要求も違います。日常利用では自動グループを基準にしつつ、特定の対象や障害時の切り替え用に手動グループも残すとよいでしょう。プロキシグループ同士を参照できますが、循環参照は避けてください。

サブスクリプションでproviderを使ってノードを管理する場合、useが参照するのは単一ノードではなくprovider名です。サービス提供者がノードを追加しても、providerを更新すれば関連するプロキシグループへ反映できます。グループにノード名を固定で書いているだけでは、新しいノードは自動追加されません。変更前にクライアントのGUIオーバーライド機能を確認し、リモートサブスクリプションのキャッシュを直接編集するのは避けてください。

DNSはコアが把握する対象情報を決める

DNSの問題は、Webページが長時間読み込まれない、一部ドメインだけ開けない、ルールがドメインではなくアドレスに一致する、システムが想定外の解決経路を検出するといった形で現れます。ClashのDNSモジュールは名前解決を接管し、ドメインごとに指定した上流DNSへ振り分け、ルールと組み合わせてドメイン情報を提供できます。代表的な拡張モードにはfake-ipとredir-hostがあります。fake-ipはまず予約アドレスを返し、接続時にコアが実際のドメインを復元します。より完全なドメイン照合能力を保ちやすい一方、LAN機器、特殊なアプリ、接続確認機能ではフィルターリストへの追加が必要になることがあります。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
    - "+.stun.*.*"

例に示す上流DNSは構文の説明用です。実際の選択では、利用ネットワークからの到達性、解決結果、プライバシー要件を考慮してください。DNSの待受アドレスをコアまたは本機だけで使うなら、ローカルアドレスに制限します。TUNを有効にすると、DNSハイジャックでシステムの53番ポートへの要求をコアへ取り込むことが一般的です。このとき、別のDNSフィルター、暗号化DNSクライアント、セキュリティソフトも同時に接管していると、奪い合いやループが起きやすくなります。

DNSに異常があるか判断するときは、「ドメインを解決できない」のか「アドレスは得られたが接続できない」のかをまず分けます。前者ではDNSログ、上流DNSへの到達性、システムキャッシュを確認し、後者ではルール一致、対象アドレス、ノード接続を確認します。DNSを変更した後はコアを再起動し、環境に応じてキャッシュを消去してから、以前アクセスしていないドメインでテストします。解決経路が気になる場合は、FAQの関連項目と、サイト内のClash DNSと接続異常に関するQ&Aも確認してください。

CHAPTER 06

TUN接管を設定し、権限とルーティング競合に対処する

TUNがカバーするシステムプロキシ外の通信

システムプロキシは、アプリがOSのプロキシ設定を自発的に読み込むことを前提とします。ブラウザーや多くのデスクトップアプリは対応していますが、コマンドラインツール、一部のゲーム、仮想マシンコンポーネント、UDPアプリ、独自のネットワークスタックを使うプログラムは完全に無視することがあります。TUNモードは仮想ネットワークインターフェースを作り、システムルートで接続をClashへ送るため、対応範囲が広く、UDPやプロキシ非対応アプリも処理しやすくなります。

TUNはシステムプロキシより必ず速いわけではありません。仮想NIC、ルーティング、DNSハイジャック、プロトコル変換などの処理が増えるため、利点はネットワーク距離の短縮ではなく、通信を広く接管できることです。ブラウザーのプロキシだけで足りるならシステムプロキシのほうが簡単です。アプリがプロキシを回避する、UDPが必要、システム通信を一元管理したいといった場合にTUNを有効にしてください。トラブル対処では、まず通常のプロキシを動かしてからTUNを追加し、ノードの問題とシステムルーティングの問題を分けて確認します。

TUNの主要パラメータを理解する

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

dns:
  enable: true
  enhanced-mode: fake-ip

stackはTUNが使うネットワークスタックの実装を指定します。一般的な値にはsystem、gvisor、mixedがあり、利用できる項目はコアによって異なります。systemは通常、システムのネットワーク機能を利用するため、互換性と性能はプラットフォームの実装に左右されます。gvisorはユーザー空間で多くのネットワーク処理を行い、環境によっては分離が明確になります。mixedはプロトコルに応じて組み合わせて使います。明確な障害がない限りクライアントのデフォルトを維持し、名前だけで性能を判断しないでください。

auto-routeは必要なルートをコアが自動的に書き込み、auto-detect-interfaceは実際に接続中のインターフェースを検出します。Wi-Fiと有線ネットワークを切り替える環境に適しています。strict-routeはルーティングを厳格にし、通信の迂回を減らしますが、仮想マシン、コンテナ、企業VPN、特殊なLANルートがある場合は追加調整が必要になることがあります。dns-hijackは指定したDNS要求をClash DNSへ送ることで、アプリがシステムの53番ポートを直接使って分流を回避するのを防ぎます。

プラットフォームごとの権限と競合要因

WindowsでTUNを有効にするには、管理者権限、システムサービス、ドライバーコンポーネントが必要になることがあります。クライアントにサービス未インストールと表示されたら、まず設定でサービスをインストールし、コアを再起動します。仮想NICの作成に失敗する場合は、他のVPN、ネットワーク高速化ソフト、セキュリティソフトがルーティングやフィルタードライバーを管理していないか確認してください。2つの全体VPN接管プログラムを同時に有効にしないでください。デフォルトルートを繰り返し書き換え、接続が周期的に切断される可能性があります。

macOSでは通常、システムネットワーク拡張またはVPN構成で通信を接管します。初回有効化時はシステムの許可を完了してください。古い構成が残って再作成できない場合は、システムのネットワーク設定で古いVPN項目をいったん無効にし、クライアントから再作成します。AndroidとiOSはもともとシステムVPNインターフェースで接管するため、通常は同時に1つの主要VPN構成しか有効にできません。クライアントを切り替える前に現在の接続を切断してください。

Linuxでコアを直接動かす場合は、TUNデバイスの作成とルート変更の権限が必要です。systemdでサービスを管理するなら、ディストリビューションのセキュリティ方針に従い、必要なネットワーク権限だけを付与します。管理者ターミナルを長時間開いたままにする運用は避けてください。コンテナ環境ではTUNデバイスとネットワーク管理権限も明示的に渡す必要があります。ホストに既存のファイアウォールルールがある場合は、コアが書き込んだルートと転送ルールが後から上書きされていないか確認します。

LAN、仮想マシン、企業VPNとの境界

TUNを有効にした後、プリンター、ルーターの管理画面、NASへアクセスできなくなった場合は、LANのルーティングが接管されている可能性があります。まず、IPv4の一般的なLAN範囲やIPv6のローカルアドレスなど、プライベートアドレス帯が直接接続のままか確認します。次に、厳格なルーティングが特定インターフェースを妨げていないか確認してください。企業VPNは社内ネットワークだけを専用インターフェースへ送ることがあります。Clashがそのルートを上書きすると、社内ドメインや業務システムに到達できなくなります。必要なネットワーク帯を企業VPNに残すことを明確にし、すべての分流を単純に無効化しないでください。

仮想マシンやコンテナは独自のブリッジを通じてネットワークへ接続することがあります。ホストのTUNがこれらの通信を接管するかどうかは、ルート、転送、ネットワークモードに左右され、ホストのブラウザー結果だけでは判断できません。競合が起きたら、TUN有効化前後のルートテーブルの変化を記録し、自動ルートを一時的に無効にして比較します。そのうえで除外ネットワークの追加やインターフェース優先度の調整を検討してください。

CHAPTER 07

日常のメンテナンス、移行、トラブル対処の流れを作る

日常の更新で、すべてを同時に更新する必要はない

Clash環境には通常、クライアントプログラム、プロキシコア、サブスクリプション設定、ルールデータという4種類の更新対象があります。クライアント更新は画面やシステム連携を変えることがあります。コア更新はプロトコル、ルール構文、TUN動作に影響する場合があります。サブスクリプション更新は主にノードとサービス提供者の設定を変え、ルールセット更新は分流結果を変えます。これらを同時に更新すると、異常の原因を特定しにくくなります。

安全な方法は、最後に使えた設定を残し、まずサブスクリプションを更新して検証し、その後にクライアントやコアを更新することです。重要な端末を更新する前に、使用中の設定名、プロキシモード、ポリシー選択、待受ポート、DNSモード、TUNの状態を記録します。クライアントが設定のエクスポートに対応していればバックアップを保存できますが、サブスクリプションURLや認証情報が含まれる場合があります。管理された場所に保管し、公開リポジトリや公開質問のスクリーンショットへアップロードしないでください。

サブスクリプションの更新頻度は、実際の変更に合わせます。頻繁に更新してもノード品質は改善せず、一時的なネットワーク不調で失敗記録だけが増えることがあります。更新後にプロキシグループが空になった場合は、providerが読み込まれたか、ノードのフィルター条件が厳しすぎないか、サブスクリプションの返却形式が変わっていないかを確認します。バックアップなしで古い設定を削除して再登録するのは避けてください。古いキャッシュ自体が重要な比較材料になります。

「まったくネットにつながらない」場合は層ごとに調べる

最初にシステムの基本ネットワークを確認します。システムプロキシとTUNを無効にした状態で、直接接続が正常か確認してください。直接接続も失敗するなら、Wi-Fi、有線接続、ゲートウェイ、システムDNSを先に直します。次にClashコアを起動しますが、システムは接管せず、設定解析エラーとポート競合を確認します。3段階目でシステムプロキシを有効にし、ブラウザーでテストサイトへアクセスしながら接続履歴を見ます。履歴がなければシステムプロキシのアドレスを確認し、履歴があれば一致したポリシーとノードのエラーを確認します。

すべてのノードがタイムアウトする場合は、サブスクリプション期限切れ、ノード全体の到達不能、ローカルネットワークによる遮断のどれかを判断します。同じ設定内の直接接続ポリシーに切り替えると、ローカルネットワークの状態を確認できます。異なる地域やプロトコルのノードを選ぶと、単一出口の問題かどうかを切り分けられます。1つのノードだけが失敗しているなら、DNSやルール全体を変更しないでください。すべてのノードが直ちに認証エラーを返すなら、サブスクリプションの状態とサービスの認証を確認します。

HTTPS証明書エラーは、通常の接続失敗とは分けて対処します。まずシステムの日付、タイムゾーン、証明書チェーンを確認し、HTTPSを検査するセキュリティソフトや中間プロキシが有効になっていないか調べます。Clashの通常転送では、一般的なHTTPSサイトのためにサイト証明書をインストールする必要はありません。詳しい確認手順はプロキシ環境でのHTTPS証明書エラー対処を参照してください。

一部のサイトやアプリだけに起きる問題を調べる

特定のサイトだけ異常な場合は、まず接続履歴を開き、ドメイン、適用ルール、最終ポリシーを確認します。ルールが誤っているなら、より具体的なドメインルールを調整します。ポリシーは正しいのに接続できないなら、同じグループ内の別ノードを試します。接続履歴にアドレスしか表示されずドメインがない場合は、DNS接管とfake-ipの動作を確認します。対象がQUICを使っている場合はUDP対応も影響するため、比較用にブラウザーのQUICを短時間無効にできますが、その結果を恒久的な結論にしないでください。

ブラウザーは正常なのにコマンドラインや別のアプリが動かない場合、アプリがシステムプロキシに従っていない可能性があります。まず手動HTTPまたはSOCKSプロキシに対応しているか確認し、環境変数でテストします。長期的に一括接管する必要があるならTUNを検討してください。モバイルアプリだけが画面ロック後に切断される場合は、バックグラウンド実行と省電力制限を確認します。LANリソースだけにアクセスできない場合は、プライベートネットワーク帯の直接接続、TUNの厳格ルーティング、ローカルドメインのDNS処理を確認します。

プロキシを無効にした後もシステムがネットにつながらない場合、クライアントが異常終了してシステムプロキシだけが残っていることがあります。システムのネットワーク設定でプロキシのアドレスと有効状態を確認し、無効な手動プロキシを解除します。TUNを使っていた場合は、仮想VPNが切断され、デフォルトルートが戻っていることも確認してください。クライアントを再起動して通常の停止ボタンで接管を解除すると、プロセスを強制終了するよりシステム設定が戻りやすい場合があります。

症状	優先して確認する項目	比較用の操作
コアが起動しない	設定構文、ポート使用中、権限	デフォルトポートに戻し、元の設定を検証する
ブラウザーに接続履歴がない	システムプロキシのアドレスとポート	127.0.0.1とmixed-portを手動指定する
ルールモードは失敗するがグローバルは使える	ルールの一致とプロキシグループの参照	対象接続のルールチェーンを確認する
TUN有効化後にLANが使えない	プライベートネットワーク帯、厳格ルーティング、インターフェース優先度	TUNを無効にして通常のプロキシを確認する
更新後にプロキシグループが空になる	サブスクリプションの返却内容、provider、ノードフィルター	前回使えたキャッシュへ戻す

ページ全体のスクリーンショットではなく有効なログを集める

問題を報告する前に、OS、クライアント名、現在の接管方式、障害が始まった時刻、最小限の再現手順を記録します。ログはエラーの前後の短い範囲だけを残し、サブスクリプションURL、サーバーアドレス、ユーザー名、認証フィールドは伏せてください。画面のスクリーンショットには状態とエラーの範囲を含めれば十分で、関係のないデスクトップ全体を送る必要はありません。「TUNを無効にすると正常で、有効にすると失敗する」「グローバルは正常だがルールモードは失敗する」といった比較結果のほうが、単に「使えない」と説明するより有用です。

短い質問はよくある質問で、基本知識、インストールと設定、利用のコツ、トラブルシューティングの分類から検索できます。プロキシ画面、設定画面、ログ画面の見方が分からない場合は、Clashクライアントの画面と機能を読み、まず該当する状態を確認してから、本章の通信経路に沿って原因を絞り込んでください。

CHAPTER 08

安定動作から高度な設定と長期管理へ

まずモジュール化した設定の考え方を身につける

高度な設定の目的はルールを増やすことではなく、ノードの取得元、ポリシー判断、ルールの取得元、DNS、システム接管を独立して検証できるモジュールに分けることです。ノードはproxy provider、ルールはrule providerで管理し、固定のプロキシグループとグローバル設定はメイン設定に残せます。こうすればノード更新で独自ポリシーが上書きされず、ルール更新のたびに設定全体をコピーし直す必要もありません。

モジュール化する前に、各プロキシグループの役割を明確に定義します。たとえば「手動選択」「自動選択」「メディアサービス」「開発サービス」「最終出口」などです。グループ名は安定させ、ログで見分けやすくしてください。記号だけで区別する似た名前を頻繁に使うのは避けます。ルールは短期間のノードを直接参照せず、役割グループを参照します。ノードが変わってもグループのメンバーだけを調整すれば済み、ルール層は変更せずに済みます。

リモートproviderには適切な更新間隔を設定し、ローカルキャッシュを残します。ルールの取得元に一時的に到達できなくても、コアはキャッシュを使って起動できます。重要な内容をすべてリアルタイム取得に依存すると、ネットワーク障害時に起動できない可能性があります。外部リソースの形式とbehaviorは一致させてください。ドメイン集合、IPネットワーク集合、従来型ルール形式を無造作に混在させないでください。

rule-providers:
  private-network:
    type: http
    behavior: ipcidr
    format: yaml
    path: ./ruleset/private-network.yaml
    url: https://example.com/rules/private-network.yaml
    interval: 86400

rules:
  - RULE-SET,private-network,DIRECT
  - MATCH,FINAL

例のアドレスは構造の説明用です。実際にリモートルールを使う前に、提供元、内容の更新方法、利用可能な形式を確認してください。ルールセットは大きければよいわけではありません。重複する項目が多いと理解とトラブル対処の負担が増え、分類を誤ると本来直接接続すべき通信までプロキシへ送られます。まず自分の利用場面に関係する少数の例外を管理し、境界が明確な汎用ルールの提供元を選びます。

mihomoの拡張機能を適用する範囲を理解する

mihomoはオリジナルClashの設定思想を基礎に、より多くのプロトコル、ルール種別、DNS機能、providerオプション、TUN動作を拡張しています。古い設定を移行する際は、まず基本フィールドとプロキシグループを検証し、その後で新機能を段階的に導入してください。複数の提供元の断片をいきなり組み合わせるのは避けます。クライアントに組み込まれたコアのビルド、デフォルトパラメータ、オーバーライド方式は異なる場合があり、あるクライアントで使える断片が別のクライアントでもまったく同じように読み込まれるとは限りません。

互換性、拡張ルール、移行時の要点を体系的に学ぶには、mihomoコアの機能とオリジナルClashとの違いを参照してください。学習時は、クライアントが実際に生成した実行用設定を基準にします。画面で保存した設定が起動時にサブスクリプション設定へ統合されることがあり、最終的にコアへ渡される内容が実際の動作を決めます。

設定変更の検証とロールバックを仕組み化する

長期管理では、起動できることを確認した基準設定、現在使用中の設定、変更中のテスト設定という3種類のファイルを残します。変更後はまずクライアントの設定チェックを実行してから起動テストを行います。コアの起動、システムプロキシ、ルール一致、DNS、TUNがすべて正常だと確認してから、現在の設定を置き換えます。テキスト設定はローカルのバージョン管理で差分を記録できますが、認証情報やサブスクリプションURLを公開リポジトリに入れないでください。

変更するたびに、「開発用ドメインを指定ポリシーへ送る」「家庭内LANを除外する」「システムプロキシに従わないアプリでTUNを有効にする」のように目的を書きます。一言で目的を説明できないなら、1回の変更に変数を詰め込みすぎている可能性があります。回帰が起きたら記録に基づいて前の状態へ戻し、変更を小さく分割します。管理しやすさを生むのは、設定ファイルの長さではなく、安定した命名、明確な役割、戻せる手順です。

Clash完全ガイド

クイックスタートと総合ガイドの使い分け