Clash使い方ガイド：基礎から安定したルール分岐まで

Clashを理解する：コア、クライアント、プロキシ経路

インストールを始める前に、混同しやすい名称を整理しておきましょう。Clashは通常、プロキシ設定フォーマットの一種と、そのフォーマットを利用するクライアントエコシステムの両方を指します。クライアントはGUIの提供、設定の読み込み、システム機能の利用を担当し、DNS解決、ルール照合、接続転送を実際に実行する部分がコアです。現在よく使われるオープンソースのコアはMihomoで、Clash Metaの設定機能を継承・拡張しています。Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasuなどはクライアントであり、クライアント名をそのままコア名として扱うことはできません。ダウンロードページでは、これらのクライアントをプラットフォーム別に掲載しています。選ぶ際は、まずOS、次に画面構成と機能範囲を確認してください。

1回のアクセスは通常、4つの段階を経ます。まずアプリが対象ドメインまたはIPアドレスへのリクエストを作成し、クライアントが現在の設定に基づいてリクエストを取り込むか判断します。続いてコアがDNS処理を行い、ルールを上から順に確認して最初に一致した項目を探します。ルールはリクエストをプロキシグループ、ダイレクト、拒否のいずれかへ渡し、最後にノードが対象サーバーへの接続を確立します。どの段階で問題が起きても「Webページが開かない」という症状になりますが、対処法は異なります。ルールの判定を誤っているならノードを替えても意味はありません。DNSが誤ったアドレスを返しているなら、プロキシグループだけを変更しても解決しません。システムが通信をクライアントへ渡していない場合は、設定自体が正常な可能性もあります。

設定ファイルと実行状態は別物

YAML設定ファイルには、ポート、プロキシノード、プロキシグループ、ルール、DNSなどの宣言的な内容を保存します。クライアントは起動時にこれらをメモリへ読み込み、現在のモード、ネットワークインターフェース、実行権限に応じて状態を構築します。ファイルを変更してもリロードしなければ、画面上では古い設定が使われ続けることがあります。逆に、画面上で一時的にノードを切り替えても、元のサブスクリプションが変更されるとは限りません。問題が「ファイルが更新されていない」のか「実行状態に反映されていない」のかを判断するには、この違いの理解が役立ちます。設定のリロード、サブスクリプション更新、クライアント再起動はそれぞれ別の操作です。後の章で個別に説明します。

リクエストからノードまでの全経路

ブラウザでドメインにアクセスする場合を例にすると、まずブラウザがOSへ接続要求を送ります。システムプロキシの設定またはTUNインターフェースによって、通信をClashへ渡すかどうかが決まります。カーネルは通信を受け取ると、DNSモードに応じて宛先アドレスを取得し、rulesを上から順に確認します。DOMAIN-SUFFIXに一致すると、リクエストは指定されたプロキシグループへ渡されます。プロキシグループは、手動選択、フォールバック、またはURL Testの結果に基づいてプロキシノードを選択します。ノードのプロトコルによるハンドシェイクが完了して初めて、宛先へのリクエストが送信されます。経路上の「遅延」はテスト先とのTCP接続確立時間だけを示す場合があり、Webページ全体の読み込み時間とは異なります。速度測定指標の違いについては、Clashの遅延テストの仕組みを参照してください。

「プロキシクライアント」と「プロキシサービス」も区別が必要です。クライアントはローカル設定を実行するだけで、サブスクリプションサービスはノード情報と通信サービスを提供します。両者は同じ組織ではなく、アカウントも共有しません。サブスクリプションURLはサービス提供元からのみ取得してください。サイトのクライアント入口はプログラムのダウンロード用であり、ノードやサブスクリプションを生成・提供するものではありません。概念を整理したら、第2章でOSと利用目的に合うクライアントを選びます。

クライアントを選ぶ：OSの機能と目的で判断

クライアントは名前やスクリーンショットだけでなく、3つの条件で選びます。必要な取り込み方式をOSがサポートしているか、サブスクリプションやルール操作を画面上で完結できるか、必要なプロトコルとDNS機能をコアのバージョンが備えているかです。一般的なデスクトップユーザーには、トレイ常駐、システムプロキシ、設定のリロード、ログ確認が必要です。モバイル端末では、バックグラウンド制限、バッテリー設定、システムVPN権限も考慮します。サーバーやソフトルーターでは、コマンドライン起動、設定ファイルの場所、プロセス監視がより重要です。ダウンロードページでは各プラットフォームの先頭にClash Plusを掲載しています。GUIの入口として使いやすい一方、クライアントによってメニュー名が異なる場合があります。

WindowsとmacOSの選び方

Windowsでは、まずClash Plus、Clash Verge Rev、FlClash、Clash Nyanpasuを確認できます。従来型のデスクトップ操作と少ない設定項目を求めるなら、読みやすい画面のクライアントを選びます。Mihomoの詳細な項目、TUN、ルールのデバッグが必要なら、コアのログと完全な設定領域を表示できるものが適しています。Clash for Windowsはメンテナンスが終了しているため、新規インストールの標準選択には向きません。既存設定は移行できますが、移行前にサブスクリプションURLとカスタムルールを保存してください。macOSではClash Plus、Clash Verge Rev、FlClash、ClashX Metaを選べます。ClashX Metaはメンテナンスが終了しており、古い設定を読み込む目的で残すのは構いませんが、新しい環境の主要クライアントには推奨しません。

AndroidとiOSの制限

Androidクライアントは、システムVPNまたはVpnServiceを通じて通信を取り込む必要があり、初回起動時にシステムの許可ダイアログが表示されます。Clash Plus、Clash Meta for Android、FlClash、Surfboardは設定場所が異なりますが、いずれもVPNが実行中になっていることを確認してください。Androidの省電力設定によってバックグラウンドプロセスが停止し、画面ロック後に接続が切れることがあります。その場合はクライアントをバッテリー最適化の対象外にし、バックグラウンドデータの権限も確認します。Androidでは、通知権限、常時接続VPN、ローカルネットワークへのアクセス権限も重要です。詳しくはAndroidのVpnServiceと省電力設定を参照してください。

iOSのシステムプロキシ権限はVPN構成の許可に集約され、クライアントの取得や設定のインポートもシステム画面によって制御されます。ダウンロードページにはClash PlusのApp Storeへの入口と、公式サイト clashplus.ioを掲載しています。初回起動時は、先に設定をインポートし、次にシステムによるVPN構成の追加を許可し、最後にクライアント内で接続を開始してください。iOSではバックグラウンド動作、オンデマンド接続、ネットワーク切り替えをシステムも管理します。モバイル通信とWi-Fiで挙動が異なる場合は、それぞれ個別にテストしてください。

LinuxとMihomoコア

LinuxのデスクトップユーザーはClash Verge RevまたはFlClashから始めるとよいでしょう。サーバー、ルーター、GUIのない端末ではMihomoを直接実行する方法が適しています。コアのパッケージは実行ファイルや圧縮アーカイブを提供するだけで、systemdサービスの作成、設定の書き込み、ポートの開放は自動で行いません。インストール後は、アーキテクチャ、ファイル権限、設定ディレクトリ、待ち受けアドレスを自分で確認する必要があります。管理パネルをインターネットへ公開するとリスクが増えるため、通常はローカルアドレスだけで待ち受け、SSHトンネルやLAN経由で管理してください。

選択後は、複数のクライアントを同時にインストールし、すべてでシステムプロキシを有効にしないでください。複数のプログラムが同じポートを奪い合ったり、システムプロキシを繰り返し書き換えたりすると、原因を特定しにくい状態になります。初回設定では、実行中のクライアントを1つに絞り、接続、ルール、DNSが正常だと確認してから、別のソフトへ移行してください。

インストールと初期設定：元に戻せる環境を先に作る

インストール前に、OSのバージョン、CPUアーキテクチャ、他のVPNやプロキシツールの有無を記録します。デスクトップでは現在のアカウントにインストール権限があることも確認し、モバイルではシステムVPNの許可を準備してください。まずクライアントページから対象プラットフォームへ進み、カードの説明に従ってインストールパッケージを選びます。初回からTUNを有効にしたりDNSを変更したりせず、最小限の権限で通常のシステムプロキシ接続を一度確立してください。機能を1つずつ追加すれば、問題の範囲を明確にできます。

デスクトップ版の初期手順

インストール後にクライアントを起動し、まず「設定」「Profiles」「サブスクリプション」などの項目を探します。サブスクリプションがない場合は、プログラムが正常に開くか、コアが起動しているか、ログに起動情報が出ているかを確認します。テスト目的で出所不明のURLを入力しないでください。設定をインポートしたら、プロキシグループにノードが表示されるか、ルール欄にルール数やルールファイルが読み込まれているかを確認します。その後、設定画面で混合ポート、HTTPポート、SOCKSポート、外部コントロールアドレスを記録します。クライアントによって初期ポートは異なるため、他のソフトの値をそのまま流用しないでください。

システムプロキシは、システムのプロキシ設定に従うアプリだけに影響することが多い機能です。ブラウザ、コマンドラインツール、一部のデスクトップアプリはHTTP、HTTPS、SOCKSのいずれかだけを読み込む場合があり、システムプロキシを完全に無視するものもあります。システムプロキシを有効にしたら、まずブラウザで確認できるサイトへアクセスし、次にコマンドラインでテストします。ブラウザは使えるのにコマンドラインが使えない場合は、すぐにTUNを有効にせず、コマンドライン側で環境変数の設定が必要かを確認してください。

モバイル版の初期手順

Androidの初回起動時、クライアントはVPN接続の確立を要求します。システムのポップアップに表示されるアプリ名が、現在インストールしているクライアントと一致することを確認してください。許可後にクライアントへ戻り、状態が停止から実行中へ変わったこと、通知バーにVPNの表示が出ていることを確認します。iOSではクライアントによるVPN構成の追加を許可し、許可が成功するとシステム設定のVPN状態が変わります。システムに既存のVPNがあると表示された場合は、先に他のVPNを停止してから再度許可し、2つのネットワーク拡張が同時に動作しないようにしてください。

LinuxでMihomoコアを最小構成で動かす

LinuxでMihomoを直接実行する場合は、まず設定ファイルを明確なディレクトリに置き、フォアグラウンドで起動してログを確認します。設定の読み込みとポートの待ち受けが正常だと確認してから、systemdなどのプロセスマネージャーへ移行します。以下のコマンドは一般的な実行方法のみを示しています。パスは実際のファイル位置に置き換えてください。

mkdir -p "$HOME/.config/mihomo"
cp config.yaml "$HOME/.config/mihomo/"
mihomo -d "$HOME/.config/mihomo"

起動ログでは、設定の解析、DNSの初期化、プロキシグループの読み込み、ポートの待ち受けを重点的に確認します。YAMLのインデントが誤っている場合、コアは通常、起動段階でエラーを出して停止します。設定は読み込めてもノードが使えない場合は、実際の接続またはヘルスチェックの段階でエラーが出ます。この2種類のログを混同しないでください。フォアグラウンドで安定して動作することを確認してからサービスファイルを設定し、サービスには固定の作業ディレクトリとユーザー権限を指定します。

設定ファイルの基本構造

以下は、読みやすい最小構成の例です。ノードの内容とサブスクリプションサービスが提供するフィールドは、実際の設定を基準にしてください。例にある名前は参照関係を説明するためだけのものです。

mixed-port: 7890
mode: rule
allow-lan: false

proxies:
  - name: "サンプルノード"
    type: ss
    server: example.net
    port: 443
    cipher: aes-128-gcm
    password: "your-password"

proxy-groups:
  - name: "PROXY"
    type: select
    proxies:
      - "サンプルノード"
      - DIRECT

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

この設定にあるパスワードはサンプル値であり、そのまま接続には使えません。実際の設定にはTLS、UDP、ポート多重化、特定プロトコル用のフィールドが含まれる場合もあります。サブスクリプションの内容、パスワード、管理キーを公開リポジトリへ掲載せず、スクリーンショットにも完全なサブスクリプションURLを写さないでください。インストールが完了したら次の章へ進み、サンプル設定を実際のサブスクリプションに置き換えます。

サブスクリプションとノード：設定を更新し、プロキシグループの仕組みを理解する

サブスクリプションは通常、サービス提供元が生成したURLです。クライアントがアクセスすると、ノードやルール設定を取得します。サブスクリプションの更新は「特定ノードのテスト」ではなく、設定を再ダウンロードして解析する操作です。更新が成功して初めて、新しいノード、無効になったノード、新しいプロキシグループが表示される可能性があります。導入時はサービス提供元が発行した元のURLを使用し、不明な変換サイトへ貼り付けないでください。公開チャット、スクリーンショット、問い合わせにも完全なURLを載せないでください。サブスクリプションURLにはアクセス認証情報が含まれることが多く、漏えいした場合はサービス側でリセットまたは再発行します。

初回インポートの確認方法

クライアントのサブスクリプション管理画面でURLを追加し、用途が分かる名前を付けてから更新を実行します。完了後はまずステータスと更新時刻を確認し、設定の詳細を開いてノード数、プロキシグループ、ルールが表示されているか確認してください。「更新成功」の表示だけを信頼しないでください。URLがHTMLのエラーページを返していると、ダウンロード完了と表示されても有効な設定として解析できない場合があります。プロキシグループが空なら、レスポンス形式、サブスクリプションの有効期限、クライアントがその設定形式に対応しているかを確認します。

サブスクリプションの更新に失敗したら、次の順番で範囲を絞ります。1つ目は、現在のネットワークからURLへ直接アクセスできるか確認すること。2つ目は、TLS証明書の検証に正しい時刻が必要なため、システム時刻を確認すること。3つ目は、クライアントが既存のプロキシ経由で更新する必要があるか確認すること。4つ目は、ログでHTTPステータスコードと解析エラーを確認すること。5つ目は、URL末尾の余分な空白や改行を削除することです。ブラウザでは開けるのにクライアントで失敗する場合、ブラウザだけがプロキシを使用し、クライアントはまだプロキシを確立していない可能性があります。直結では失敗し、既存プロキシへ切り替えると成功するなら、サブスクリプション設定で正しい更新プロキシを選んでください。

ノード、プロキシグループ、ポリシーの関係

ノードは具体的なリモート接続の入口で、プロキシグループは複数のノードをまとめる選択機能です。最も単純なselectグループではユーザーが手動で選びます。URL Testはテスト結果に基づいてノードを選び、fallbackは現在のノードが利用できないときに切り替え、load-balanceはポリシーに従ってリクエストを分配します。テスト結果はテストURLとテスト時点の状態だけを示し、実際の利用感を保証するものではありません。ノードの地域、回線の混雑、接続先の位置、プロトコルの互換性によって結果は変わります。まずselectグループで制御可能な基準を作り、ルールが正しいと確認してから自動選択を試すことをおすすめします。

サブスクリプション更新とローカル変更

多くのクライアントは、サブスクリプション設定とローカル上書き設定を分けて保存します。サブスクリプションから生成されたファイルを直接編集すると、次回更新時に変更が上書きされる可能性があります。より安全なのは、クライアントの上書き、Merge、Patch機能を使い、カスタムプロキシグループ、ルール、DNSを独立したファイルへ分ける方法です。上書きに対応していない場合は、少なくとも編集前にバックアップをエクスポートし、変更箇所を記録してください。変更が有効か確認するときは、ディスク上のファイルだけでなく、実行中の設定プレビューとログを確認します。

ノード選びでは最低遅延だけを追求しないでください。たまに非常に低い数値が出るノードより、安定してパケットロスが少ない回線のほうが長期利用に向いています。通信量の倍率、出口地域、UDP対応、接続先サービスによる出口制限も確認しましょう。Clashのノード選びを参考に、自分用の選定記録を作成してください。サブスクリプションが正常に更新できたら、次の章でプロキシモードを選びます。モードを明確にする前に、ルールの効果を誤って判断しないためです。

プロキシモード：Direct・Global・Ruleの使い分け

プロキシモードは、コアがリクエストを受けた後にどのような判断を行うかを決めます。Directは対象へ直接接続し、ネットワーク自体の確認やルールの影響を切り分ける際に使います。Globalは大半のリクエストを1つのプロキシグループへ渡すため、回線で対象へ接続できるかを素早く確認するのに適しますが、日常的な細かな分岐には向きません。Ruleはrulesを上から順に照合する、日常利用で最も一般的なモードです。モードを切り替えてもノード自体は変わらず、DNS、システムプロキシ、TUN権限の問題が自動的に直ることもありません。ログと接続履歴を合わせて判断してください。

Directモードで基準を作る

Webページが開かないときは、一時的にDirectへ切り替えて対象へ正常に接続できるか確認します。Directでは正常でRuleでは失敗するなら、ルール、プロキシノード、プロキシグループに問題がある可能性があります。Directでも失敗するなら、ローカルネットワーク、DNS、接続先サイトの状態、システムファイアウォールを確認します。Directはプロキシ経路を迂回するため、ルールが正しいことの証明にはなりません。テスト後は元のモードへ戻し、想定した分岐を外れた通信が発生しないようにしてください。

Globalモードでノードを確認する

Globalモードでは、リクエストを選択したプロキシグループへ集中させ、「このノード群で対象へアクセスできるか」を確認できます。Globalではアクセスでき、Ruleではできない場合は、ルールの一致結果とプロキシグループの参照を優先して確認します。Globalでも失敗するなら、現在のノード、プロトコルのハンドシェイク、出口地域、リモート側の応答を確認します。Globalでは、本来直結すべき日本国内のサイト、LANアドレス、ローカルIPが必要なサービスまでプロキシを経由することがあります。短時間の診断用にとどめ、終了後はRuleへ戻してください。

Ruleモードで確認するポイント

Ruleモードで重要なのはルールの数ではなく、順序と適用範囲です。1つのドメインが複数の条件に一致することがあり、コアは通常、最初に一致したルールを採用します。一般的な設定では、LAN、プライベートIP、特定ドメインを先に処理し、その後に広告や地域別リストを処理し、最後にMATCHで未一致を受けます。MATCHがないと、どのルールにも一致しないリクエストがデフォルトポリシーに入り、想定と異なる動作になる場合があります。プロキシグループを選ぶときは、グループ名とルールが参照する名前が完全に一致していることを確認してください。

クライアントの接続履歴には通常、リクエストドメイン、一致したルール、最終ポリシーが表示されます。アクセスに問題がある場合は、まず接続履歴を消去または絞り込み、対象ページを1つだけ開きます。リクエストが表示されたか、ルール欄に何が出たか、最終的にどのノードが選ばれたかを確認してください。ブラウザは複数のドメインへ同時にアクセスするため、ページが開いてもすべてのリソースが同じ経路を通ったとは限りません。アプリの問題では、QUIC、DoH、アプリ内プロキシを使用していないかも確認します。これらの通信は通常のブラウザ接続とは異なる形で現れる場合があります。

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

システムプロキシは主に、システム設定に従うTCPアプリの通信を取り込みます。TUNは仮想ネットワークインターフェースを通じて、より広範なシステム通信を取り込みます。TUNを有効にすると、システムプロキシを迂回していたプログラムもコアへ入る可能性がありますが、権限、ルーティング、DNS処理は複雑になります。まずシステムプロキシモードでサブスクリプション、ルール、ノードを検証し、システムプロキシに従わないアプリを取り込む必要があると確認できた場合だけ、第7章のTUN設定へ進んでください。

ルール分岐：一致順序から検証可能なポリシー設計まで

ルール分岐の目的は、異なるリクエストを明確な条件に基づいて直結、プロキシ、その他のプロキシグループへ振り分けることです。ルールは多ければよいのではなく、境界が明確で、順序が安定し、フォールバックが定義されていることが重要です。一般的なルールには、完全なドメインに一致するDOMAIN、サフィックスに一致するDOMAIN-SUFFIX、キーワードに一致するDOMAIN-KEYWORD、IPやネットワークに一致するIP-CIDR、未一致のリクエストを最後に処理するMATCHがあります。ルール右側のポリシー名は、設定内のproxy-groupsまたは予約済みポリシーに存在しなければなりません。ファイルに記述されているだけでは、想定どおりに実行されません。

ドメインルールの違い

DOMAIN,api.example.com,PROXYは指定した完全なドメインだけに一致します。DOMAIN-SUFFIX,example.com,PROXYは通常、そのドメインとサブドメインを対象にします。DOMAIN-KEYWORD,example,PROXYはドメイン内のキーワードに一致するため範囲が広く、意図しない対象まで巻き込みやすくなります。サービスにルールを追加する場合は、まず完全なドメインまたはサフィックスを使い、ドメイン構造が複雑で影響範囲を確認できる場合に限ってキーワードルールを使用してください。ルール内のドメインにプロトコル、パス、ポートを付けないでください。https://example.com/pathと記述しても、通常は意図した一致になりません。

ルールの順序とLANの例外

LANとローカルアドレスは通常、上位に配置します。これにより、プリンター、ルーターの管理画面、家庭内サーバーなどへのリクエストがリモートノードへ送られるのを防げます。順序の例は次のとおりです。

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

no-resolveは、ドメインを判定するためにIPルールが追加のDNS解決を行うのを防ぎます。すでにIPネットワークで判定すると明確な場合に適していますが、すべてのルールに必須のスイッチではありません。使用前に、現在のDNSモードとルールエンジンの動作を理解してください。GEOIPはIPデータベースに依存するため、データベースの更新状態が結果に影響します。サイトの出口やドメインポリシーに明確な要件がある場合は、地域判定だけに頼らず、ドメインルールを優先してください。

ルールセットとローカル上書き

大規模なドメインリストは通常、rule-providerまたはルールセットとして読み込みます。ルールセットは一元管理に適していますが、デバッグ時には実際に一致したルールの出所を把握する必要があります。ローカルルールを変更したら、まず設定を保存し、その後リロードを実行します。ルールセットがリモートURLの場合は、更新が成功していることも確認してください。トラブルを減らすには、少数の個人用例外ルールを独立ファイルの先頭に置き、汎用ルールセットをその後に配置し、最後に明確なMATCHを残します。個人の例外を素早く適用しつつ、上流のサブスクリプションを直接変更せずに済みます。

ルールを検証する方法

検証では対象ドメインを1つだけ選びます。接続履歴を消去して対象へアクセスし、接続詳細に表示されるドメイン、解決先アドレス、一致ルール、最終ポリシーを確認します。履歴がない場合は、アプリがシステムプロキシまたはTUNを経由しているかを確認します。履歴はあるのにMATCHへ入る場合は、ルールファイルが読み込まれているか、順序が正しいかを確認します。対象ルールに一致しても失敗するなら、問題はルール層からプロキシグループ、ノード、またはリモート側の応答へ移っています。3か所を同時に変更しないでください。どの変更が結果を生んだのか分からなくなります。

ルール分岐はキャッシュの影響も受けます。ブラウザがDNS、接続、リダイレクトの結果をキャッシュし、クライアントも接続状態を保持することがあります。ルールを変更したら対象ページを閉じ、設定を一度リロードし、必要に応じて接続を再確立してから新しいリクエストを確認します。長期的な管理では、個人ルールを日付と用途の説明付きの独立した断片として保存し、不要になった例外を定期的に削除してください。ルール表が説明できないブラックボックスになるのを防げます。

TUNとDNS：システムプロキシで取り込めない通信を処理する

TUNは仮想ネットワークインターフェースです。システムが通信をこのインターフェースへ送ると、Clashコアはネットワーク層に近い位置でリクエストを受け取れるため、システムプロキシに従わないプログラムも分岐対象にできる可能性があります。TUNは「より速いプロキシモード」ではなく、有効にすればすべてのネットワーク問題が解決する機能でもありません。システム権限、ルーティング、正しいDNS設定が必要で、他のVPN、仮想NIC、企業向けセキュリティソフトと同時に動かすとルートが競合する場合もあります。通常のシステムプロキシで対象アプリを取り込めない場合に限って有効化してください。

有効化前の準備

まず他のVPNを停止し、現在のネットワークが正常に使えるか記録します。デスクトップクライアントでTUN、拡張モード、仮想NICなどの設定を探し、コアが対応機能を備えていることを確認します。Windowsではドライバーや管理者権限の確認が表示される場合があり、macOSではネットワーク拡張の許可が必要になることがあります。LinuxではCAP_NET_ADMINまたはroot権限が必要になる場合があります。モバイル端末のVPN取り込みはシステムのアプリ層で制御され、通常はデスクトップ版と同じTUNスイッチを使いません。有効化前に、TUNを無効にして戻せる手段を確保し、再起動後にネットワークが復旧できなくなる事態を避けてください。

DNSモードの役割

DNSはドメインをIPへ変換するだけではありません。ルールは通常、先にドメイン情報を必要とするため、DNSの処理方法がルール照合、Fake-IPのマッピング、LANアクセス、汚染回避に影響します。代表的な方式にredir-hostとfake-ipがあります。redir-hostは実際の解決先アドレスを返すため互換性が分かりやすい一方、ドメインによっては現在のネットワークの影響を受けます。fake-ipはドメインに仮想アドレスを割り当て、マッピング表でドメイン情報を保持します。これにより接続段階でもドメインによる照合を続けやすくなりますが、一部のLAN機器、IPアドレスをハードコードしたアプリ、特殊な認証処理では互換性の問題が起こることがあります。

設定例は次のとおりです。実際のDNSサーバーはネットワーク環境とクライアントの対応状況に応じて調整してください。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
    - "+.local"

Fake-IPのアドレス範囲は、実際のLANのネットワーク範囲と競合させないでください。フィルターリストも無条件に流用してはいけません。LANホスト名、スマートホーム機器、社内ネットワークへアクセスする場合は、対象ドメインをフィルター範囲へ追加し、LANのDNSへ引き続き到達できることを確認します。アプリがドメインではなくIPアドレスを表示する場合、Fake-IPでは元のドメインを復元できないことがあります。その場合は対象をフィルターへ追加するか、より適した取り込み方式を使用してください。

TUN有効化後のトラブル解決手順

有効化後は、まずLANゲートウェイ、次に通常のドメイン、最後にプロキシが必要な対象をテストします。LANに接続できない場合は、ルート、Fake-IPフィルター、LAN許可設定を確認します。通常のドメインに失敗する場合は、DNSログ、仮想NIC、システムDNSを確認します。前の2つが正常で、プロキシ対象だけが失敗する場合に、ルール、プロキシグループ、ノードを調べます。すべてのネットワークが切断されたら、直ちにTUNを無効にするかクライアントを終了し、基礎ネットワークを復旧してから権限とルーティングログを確認してください。設定を重ね続けないでください。

DNSキャッシュによって、変更が反映されていないように見えることもあります。設定を変更したら、クライアント設定をリロードし、ネットワークへ再接続して、OSに応じてDNSキャッシュを更新します。ブラウザ内蔵のセキュアDNSはシステムDNSを迂回する場合があり、アプリ独自のリゾルバーもコアを迂回することがあります。トラブル解決では、使用するテストツールがどの解決経路を通っているかを明確にしてください。TUNとDNSの検証が終わったら、複雑さを求めて設定項目を増やし続けないでください。機能を積み重ねるより、安定して説明できる設定のほうが長期管理に向いています。

日常のメンテナンスと上級設定への道筋：説明できる設定を保つ

Clashを安定して使う鍵は、頻繁に調整することではなく、定期的な確認サイクルを作ることです。サブスクリプションを更新するたびに、更新時刻、ノードの存続、プロキシグループの参照を確認します。クライアントを更新するたびに、コアのログとシステムプロキシの状態を確認します。ルールやDNSを変更するときは、1回に1つの変数だけを変更して対象テストを行います。設定を一度導入したら変わらないものではなく、管理が必要な実行ファイルとして扱えば、「昨日まで動いていたのに今日は使えない」という状況でも原因を追いやすくなります。

残しておきたい記録

少なくとも、現在使用中のクライアント名、設定の入手元、プロキシモード、混合ポート、TUNの有効・無効、DNSモード、カスタムルールファイルを記録してください。サブスクリプションURLは公開文書へ直接書かず、用途とサービス側の管理場所だけを残します。問題が起きたら、発生時刻、ネットワーク種別、対象ドメイン、接続ログの一致ルール、エラー内容を記録します。「インターネットにつながらない」の一言より、こうした背景情報のほうが、サブスクリプション、ルール、DNS、ノード、システム権限のどこに変化があったかを特定するのに役立ちます。

クライアントとコアを更新するときの移行手順

アップグレード前に現在の設定をエクスポートするか、ローカル上書きファイルをコピーし、カスタムルールとプロキシグループ名を記録します。新しいクライアントをインストールしたら、まずTUNを有効にせず設定をインポートしてプロキシグループを確認します。次にシステムプロキシを有効にしてブラウザでテストし、最後にTUN、DNS、自動起動を復元します。クライアントによってフィールド、外部コントロールインターフェース、上書き構文の対応は完全には一致しません。古い設定をインポートできても、すべてのオプションが採用されるとは限りません。起動エラーが出たら最小構成へ戻し、部分ごとに復元してください。古いディレクトリ全体を新しいクライアントへ上書きする方法は避けます。

よくある障害の判断フロー

クライアントが開かない場合は、まずインストールパッケージ、権限、システムログを確認します。クライアントは開くのにノードがない場合は、サブスクリプションの更新と設定解析を確認します。ノードはあるのにすべてのリクエストが失敗する場合は、プロキシグループの選択、ノードのハンドシェイク、システム時刻を確認します。一部のドメインだけが失敗する場合は、ルールの一致、DNS、接続先サイトの制限を確認します。ブラウザは使えるのに特定のアプリだけ使えない場合は、そのアプリがシステムプロキシに従うか確認します。TUNを有効にして全体がオフラインになった場合は、TUNを無効にし、ルート、権限、他のVPNを確認します。ローカルのプログラムからリモートサービスへ段階的に確認することで、すべての問題をノードのせいにせずに済みます。

FAQページでは、サブスクリプション更新の失敗、システムプロキシ、設定のインポートなど、短い疑問を整理しています。用語を調べたい場合は、サイト内のクライアントと設定の解説から該当する章へ進んでください。ブログ記事はFake-IPの仕組みやiOSの設定インポートなど、特定テーマを読むのに適しています。一方、このページは設定中に章を繰り返し参照するためのものです。3種類のコンテンツは用途が異なるため、問題が起きても文書を最初からすべて読み直す必要はありません。

Mihomo設定をさらに学ぶ

基本的なルール分岐を終えたら、プロキシグループのポリシー、rule-provider、スクリプトルール、外部コントロールインターフェース、サービスとしての実行を順に学ぶとよいでしょう。上級設定では2つの原則を守ります。追加する機能ごとに解決する問題を説明できること、リモートソースごとに誰が管理しているか説明できることです。他人の完全な設定をそのまま使うために、DNS、スクリプト、ルールセットを一度に大量に有効化しないでください。複雑な設定ほど障害の範囲が広がり、上流の変更で古いフィールドが無効になる可能性もあります。設定を読むときは、まずポートとモード、次にDNS、その後にプロキシグループとルール、最後に高度な実験項目を確認します。

サーバーやルーターでは、Mihomoプロセスの権限、設定ディレクトリ、管理インターフェースを分けて計画することをおすすめします。管理インターフェースは信頼できるアドレスだけにバインドし、設定ファイルの読み取り権限を制限します。サービス再起動後はログを確認し、アップグレード時には動作していた前のコアファイルを残してください。デスクトップやモバイル端末では、バックグラウンド権限を管理し、複数のVPNの競合を避け、使えなくなったサブスクリプションや期限切れのルールを整理することが重要です。プラットフォームが変わっても、基本的なトラブル解決法は同じです。通信がコアに入っているか、DNSとルールがどう処理しているか、プロキシグループとノードが接続を完了しているかを確認します。

ここまでのClashの利用手順は、安定した1つの流れにまとめられます。OSに合うクライアントを選び、最小限の権限でインストールする。サブスクリプションを導入して検証する。Ruleモードで分岐の基準を作る。接続履歴でルールを検証する。必要な場合だけTUNとFake-IPを有効にする。定期的にサブスクリプションを更新し、ログを確認してカスタム設定をバックアップする。具体的な操作で迷ったらクイックスタートに戻って手順を進めてください。対応クライアントの一覧が必要な場合はClashダウンロードページからプラットフォームを選べます。