Clash / mihomo · 設定を体系的に学ぶガイド

Clashの基礎から応用まで

クライアント、サブスクリプション、トラフィックの入口、ルールの順に設定し、TUNと日常のメンテナンスへ進みます。

初回接続は使い方ガイドに沿って進めてください。このページでは各手順の仕組みや適用範囲、元に戻す方法を解説します。設定前に順を追って読むのにも、問題が起きた際に該当章を確認するのにも役立ちます。画面上の名称はクライアントによって異なります。mihomoの設定項目については、クライアントが実際に採用しているコアを基準にしてください。

1. Clashの基本概念を理解する

クライアント・コア・サーバーの役割

Clashは通常、プロキシコアを基盤とするクライアントや設定環境の総称で、特定の画面構成を指すものではありません。GUIクライアントは設定の読み込み、システムプロキシの切り替え、ノード選択、ログ表示を担当し、コアはローカルポートの待ち受け、ルールの読み込み、接続の確立を担います。mihomoはこの環境で広く使われているコアの一つです。画面が開いたからといってクライアントが起動したことしか確認できず、コアの正常動作やリモート回線の利用可能性までは判断できません。

サーバー上のノードは、実際に通信を中継するリモート接続先です。クライアントのインストーラーを入れても利用可能なノードは作られません。また、サブスクリプションはプロキシプロトコルではなく、設定やノード情報を配布する仕組みです。トラブル時は、設定を管理できるか、コアが接続を受け付けるか、ノードとのリモート接続が確立するかを分けて確認してください。すべてをインストール失敗と決めつけて再インストールしても、原因の箇所が違えば解決しません。

1回のリクエストで通信経路をたどる

アプリがリクエストを送ると、通信はシステムプロキシ、アプリ独自のプロキシ設定、またはTUNを経由してコアに入ります。コアは宛先のドメイン名やIPアドレスなどをもとにルールを選び、DIRECTまたはプロキシグループに接続を渡します。プロキシグループがノードを選択し、そのノードが宛先のサービスへリクエストを送ります。応答は逆の経路で戻ります。通信の入口、ルール判定、出口ノードはそれぞれ別の段階です。一つを有効にしただけで、ほかも正しく設定されたとは限りません。

設定内のproxiesはノードを定義し、proxy-groupsは選択方法をまとめ、rulesは接続をどのポリシーに渡すかを決めます。ルールで参照する名前は、該当するノード、プロキシグループ、または組み込みポリシーとして定義されている必要があります。名前が似ていても同じとは限らず、大文字・小文字、空白、句読点の違いも参照に影響します。見慣れない設定を読むときは、先頭から項目を暗記するより、入口のポート、グループ名、最後のフォールバックルールを先に確認するほうが効率的です。

ノード・ポリシー・名前解決の結果を区別する

ノード名に含まれる地域名は通常、プロバイダーが付けたラベルであり、出口IPの所在地を証明するものではありません。遅延テストの結果も、指定されたプローブへの応答を示すだけで、実際のダウンロード速度とは異なります。プロキシグループはノードの選択方法であり、別のサーバーではありません。DNSは名前をアドレスに変換し、ルール判定にも影響することがあります。これらの対象を区別すれば、ノード切り替え、DNS変更、ルール調整で結果が異なる理由を理解しやすくなります。

このガイドの設定例は特定の項目を説明するための断片です。特に明記されていない限り、完全なサブスクリプションとして読み込まないでください。既存の設定にはノードやクライアント固有の項目が含まれていることが多く、全体を置き換えると失われます。用語を手早く確認するには用語集を、初めて接続する場合は使い方ガイドを順に参照してください。まず動作する基本設定を作り、その後で応用機能を追加すれば、変更前後を明確に比較できます。

2. プラットフォームに合わせてクライアントを選ぶ

OSを選んでから使い方を確認する

一般的なデスクトップやモバイル端末では、まずClash Plusを候補にし、プラットフォームや使い方に応じてほかのクライアントと比較してください。選ぶ際は画面の見た目ではなく、OSとの互換性、設定の管理方法、必要なプロトコル、ネットワークを取り込む機能を基準にします。インストール前にダウンロードセンターでOSとアーキテクチャを確認し、別のOSのチュートリアルにあるボタン名をそのまま当てはめないでください。ルールの考え方は共通でも、サービスのインストール、ネットワーク権限、バックグラウンド実行の方法は異なります。

WindowsではClash Plus、Clash Verge Rev、FlClash、Clash Nyanpasuを比較できます。Clash for Windowsは開発が終了しているため、既存環境の確認用として参照するにとどめ、新規導入の第一候補にはしないでください。macOSではClash Plus、Clash Verge Rev、FlClashを選べます。ClashX Metaも開発終了済みのアーカイブ版として扱ってください。現在起動できるかどうかと、メンテナンスが続いているかは別の問題です。新しいOSの権限仕様や今後のプロトコル互換性にも注意してください。

AndroidではClash Plus、Clash Meta for Android、FlClash、Surfboardを選べます。Surfboardの設定形式はClash YAMLと異なるため、同じサブスクリプションをすべてのクライアントでそのまま使えるとは限りません。iOSではClash Plusのストア情報を確認してください。公式サイトはclashplus.ioです。LinuxデスクトップではClash Verge RevまたはFlClashが候補です。GUIのないサーバーやルーターには、mihomoを個別に導入する方法が適しています。

比較時は実際に使われるコアを確認する

利用環境優先して確認する項目インストール前の確認事項
デスクトップOSシステムプロキシ、設定の上書き、接続パネルアーキテクチャ、サービス権限、ポートの使用状況
モバイルOSVPN権限、バックグラウンド実行、設定の互換性既存のVPN、バッテリー制限、サブスクリプション形式
サーバー・ルーター常駐プロセス、ルーティング、DNS、ファイアウォール起動方法、管理用アクセス、復旧手段

プロトコルの対応状況を確認するときは、クライアントが実際に使うコアとサブスクリプションの項目をあわせて確認してください。画面にプロトコル名が表示されていても、現在のコアがプロバイダーの全パラメーターを解析できるとは限りません。読み込みエラーが起きたら、エラーの内容とクライアント名を記録しておくと、アイコンだけを記録するより役立ちます。互換性を試すために複数のプロキシコアを同時に動かすのは避けてください。ポート、システムプロキシ、仮想ネットワークアダプターを取り合い、正常な設定まで動かなくなることがあります。

OSのアーキテクチャによって、インストーラーが動作するかどうかが決まります。Apple Silicon搭載機とIntel搭載機では、それぞれ対応するビルドを選んでください。WindowsとLinuxでもCPUアーキテクチャの確認が必要です。AndroidのARM64用とARM用のパッケージは自由に入れ替えられません。判断できない場合は、端末情報とダウンロードページの説明を確認してください。インストール失敗の原因は、必要なOSバージョンや配布元の制限である可能性もあります。ネットワーク転送より前の段階で起きる問題なので、最初からプロキシ設定を変更しないでください。

クライアントを決めたら、まず一つのアプリで基本接続を確立してから移行を検討してください。移行時は元の設定ファイル、サブスクリプションの提供元、必要なプロキシグループの選択内容を残します。画面に表示されたノード名だけをコピーしても、設定は引き継げません。候補を並べて比較するにはクライアント比較を参照してください。移行後は古いクライアントの自動起動とシステムプロキシを無効にし、次回の再起動で二つのアプリが同時にネットワークを取り込まないようにします。

3. クライアントをインストールしてポートを確認する

最小構成で動作環境を整える

ダウンロードセンターからOSとアーキテクチャに合ったインストーラーを入手し、画面の案内に従ってインストールします。初回起動時は設定画面、コアの状態、ログの場所を確認してください。すぐにシステムプロキシ、TUN、LAN共有、複雑な上書きを同時に有効にする必要はありません。まずクライアントからコアを起動でき、実際に使う設定ファイルの場所を確認できることが重要です。ネットワーク拡張やサービス権限を求められた場合は、システムの説明を読んで許可してください。セキュリティ警告を何度も無効にして起動を試すのは避けましょう。

デスクトップクライアントでは、GUIとバックグラウンドサービスが別々に動くことがあります。ウィンドウを閉じてもコアが停止するとは限らず、トレイから終了してもサービスが削除されるとは限りません。インストールの前後に、ほかのプロキシアプリが起動していないか確認してください。ポートの競合が表示されたら、まず使用中のプロセスを特定してから対処します。ネットワーク関連のプロセスを手当たり次第に終了しないでください。モバイル端末でVPNの許可を求められた場合は、対象がインストールしたクライアントであることを確認してください。通常、同じ入口を使える一般的なVPNセッションは一つだけです。

ローカルポートとノードのポートは別

mixed-portは、この端末のアプリからコアへ接続する入口で、HTTPとSOCKSの両方のプロキシリクエストを受け付けます。一方、ノードのサーバーポートはサブスクリプション内のノード定義にあります。役割が異なるため混同しないでください。以下の例では、入口をループバックアドレスに限定しており、この端末だけで使う場合に適しています。ポート番号は設定例であり、すべてのクライアントの初期値ではありません。アプリにプロキシを設定するときは、クライアントが現在表示している待ち受けポートを指定してください。

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info

ブラウザーやツールでローカルプロキシを使う場合、アドレスには通常127.0.0.1を、ポートにはコアが実際に待ち受けている番号を入力します。リモートノードのアドレスをここに入力してはいけません。同じLAN上のほかの端末にもプロキシを使わせる場合は、待ち受けアドレス、アクセス認証、ファイアウォールの範囲を個別に検討してください。allow-lanを有効にしただけで設定完了ではありません。外部に公開したプロキシ入口は、ほかの端末に利用されて回線の通信量を消費する可能性があります。

起動ログでサービスの状態を確認する

WindowsではPowerShellでGet-NetTCPConnection -LocalPort 7890 -ErrorAction SilentlyContinueを実行し、この例のポートの待ち受けや接続状況を確認できます。Linuxではss -lntpで待ち受けプロセスを調べます。結果が空の場合は、コアが起動しているか、クライアントがポートを変更していないかも確認してください。待ち受けが表示されても、どのプロセスに属するかを照合します。同じポートを使っているだけで、現在のクライアントが待ち受けているとは限りません。

コアの起動直後に終了する場合は、ログに記録された最初の設定エラーを確認してください。その後に発生する接続拒否は、起動失敗に伴う二次的なエラーであることがよくあります。よくある原因は、YAMLのインデント、フィールドの重複、設定ファイルの読み込み不可、グループ名の参照間違いです。一つ修正したら再読み込みし、新たに最初に出たエラーを確認します。一度に多くの項目を変更しないでください。システム権限の問題はクライアントのサービス管理画面で対処し、サブスクリプションに無関係な項目を追加しないようにします。

インストール完了の目安は、コアが継続して動作し、使用中のポートのプロセスを特定でき、ログで再起動が繰り返されず、システムの通常の直接接続も使えることです。設定ディレクトリの場所と起動方法を記録し、次の章でサブスクリプションを追加します。クライアント終了後にネットワークがおかしくなった場合は、システムプロキシが停止済みのローカルポートを参照していないか確認してください。まず直接接続に戻してからインストールの問題に対処すれば、プロキシ設定の残りをシステム全体のネットワーク障害と誤認せずに済みます。

4. サブスクリプションを追加して設定を管理する

サブスクリプションの内容を確認する

サブスクリプションURLから完全なClash YAMLが返る場合もあれば、ノード一覧や別の形式が返る場合もあります。完全な設定には通常、ノード、プロキシグループ、ルールが含まれ、読み込むと選択可能なProfileになります。ノード一覧だけの場合は、メイン設定のproviderと組み合わせて使う必要があることもあります。Base64は単なるエンコード方式で、内容の互換性を保証するものではありません。URLをブラウザーで開けるかだけで判断せず、提供元が想定する形式を確認してください。

クライアントの設定またはサブスクリプション画面でリモート設定を追加し、URL全体を貼り付けて保存します。ダウンロードが完了したら、その設定を現在のProfileとして選択してください。項目を追加しただけで有効化していないケースはよくあります。有効化後はプロキシグループが表示されるか、グループ内のノードがすべて空ではないか確認します。クライアントにダウンロード日時や更新日時が表示される場合は、最後に成功した状態を記録してください。更新ボタンを押しただけでサーバーの内容が正常に反映されたと判断してはいけません。

サブスクリプションURLにはアクセス用の認証情報が含まれる場合があります。アカウント情報と同様に取り扱ってください。スクリーンショットを共有するときはURL全体を隠し、ログを他人に渡す前にクエリパラメーターや認証情報を削除します。個人用のURLを、よく知らないオンライン変換サイトに貼り付けないでください。変換サービスがURLやノード情報を読み取る可能性があります。形式を変換する必要がある場合は、提供元が対応を明示している出力方法を優先するか、管理下の環境で変換して結果を確認してください。

ローカル編集とリモート更新を分けて考える

リモート設定の元ファイルは次回の更新時に置き換わることが多く、直接編集したルールが残るとは限りません。クライアントの上書き、マージ、拡張設定機能を使うとローカルの変更を保存できますが、マージ順序はクライアントによって異なります。利用前に配列への追加なのか、配列全体の置き換えなのかを確認し、最終的に有効な設定を見てください。エディターにルールが存在していても、コアが現在読み込んでいるファイルに反映済みとは限りません。

以下はmihomoのリモートノード一覧の設定例です。provider互換の内容が提供されている場合に限り使用できます。例示用ドメインでは実際のノードに接続できないため、自分の有効なURLに置き換えてください。メイン設定には、このproviderを参照するプロキシグループも必要です。通常の完全なサブスクリプションをダウンロードする場合は、ファイルを自分で分割せず、クライアントのリモート設定機能を使ってください。

proxy-providers:
  remote:
    type: http
    url: "https://example.com/proxies.yaml"
    path: ./providers/remote.yaml
    interval: 3600

proxy-groups:
  - name: PROXY
    type: select
    use:
      - remote

更新エラーと複数設定の切り替え

サブスクリプションの更新に失敗したら、まずダウンロードエラーと解析エラーを切り分けます。ダウンロードエラーでは現在のネットワーク、URLの有効性、まだ使えないプロキシにリクエストが依存していないかを確認してください。解析エラーでは、返された内容がWebページ、ログイン案内、非対応形式ではないかを確認します。APIが返したエラーページをYAMLとして保存し、インデントを直し続けるのは避けてください。利用可能な前の設定を残しておけば、更新に失敗しても戻せます。

複数の設定は用途ごとに名前を付け、提供元、対応クライアント、ローカル拡張の保存場所を記録してください。切り替え後はプロキシグループ名が変わり、以前のノード選択が引き継がれない場合があります。現在のモードと既定のグループを確認し直してください。自動更新の間隔は提供元の要件に合わせればよく、何度も手動更新する必要はありません。形式の違いはサブスクリプションURL・YAML・Base64の解説を、複数設定の整理方法はProfileの管理方法を参照してください。

5. プロキシモードを選び、接続を確認する

モードが決めるのはポリシーであり、通信の入口ではない

ルールモードは設定内のルールに従って通信の行き先を決めるため、日常的な振り分けに適しています。グローバルモードは通常、コアに入ったプロキシ通信をグローバル選択先に渡します。DIRECTモードでは、コアに入った通信に直接接続のポリシーを適用します。いずれも、すでに受け取った接続をコアがどう処理するかを決めるものです。アプリがシステムプロキシを使わず、TUNでも取り込まれていない場合、ルールやグローバルモードを切り替えても自動的にコアへ通信が入りません。トラブル時に最初に確認すべき重要な点です。

システムプロキシは、OSがアプリに提供するプロキシ設定であり、すべてのネットワーク接続を強制的に取り込む機能ではありません。設定に従うアプリもあれば、独自のプロキシ設定を使うアプリや、直接接続するアプリもあります。まずシステムプロキシに対応していることが明確なブラウザーで確認し、その後ほかのアプリに広げてください。ゲームやコマンドラインツールがプロキシを通らないからといって、システムプロキシのスイッチが機能していないと決めつけないでください。そもそも設定を参照していない可能性があります。

入口・ルール・出口の順に確認する

設定を読み込んだら、まず主要なプロキシグループでノードを一つ選び、システムプロキシを有効にして新しいブラウザーリクエストを送ります。接続パネルに宛先ドメインが表示されるか、適用されたルールとポリシー経路が想定どおりか確認してください。既存の長時間接続は以前の経路を使い続けることがあります。ノードを切り替えたら、新しい接続を作成してから確認しましょう。対応するリクエストがログにまったく現れない場合は、リモートノードの設定ではなく、アプリの入口とプロキシポートを先に調べてください。

コマンドラインでは、次のようにローカルHTTPプロキシを明示してリクエストできます。例のポートは実際の設定と一致させてください。宛先サービス自体がアクセス可能であることも必要です。HTTPレスポンスが返れば、このリクエストが指定した入口を通ったことは確認できますが、リモートノードを経由したかどうかはルールと接続ログで確認してください。ルールがDIRECTを選んでいれば、ローカルプロキシ入口を指定していても出口は現在のネットワークからの直接接続になる可能性があります。

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

Webサイトを試すときは、接続できるか、出口IPがどうか、サービスが使えるかを分けて確認してください。ページが開いても、すべてのリソースが同じ経路を通るとは限りません。出口IPが変わっても、特定のサービスが使えるとは限りません。サービス提供元はアカウント、地域、端末、サービスのポリシーに基づいてアクセスを制限することがあります。ノード選びでは、まず接続が確立するか確認し、その後に実際の用途で比較してください。遅延や倍率の見方はClashのノード選び方を参照してください。

Windows UWPのループバックとアプリの例外設定

一部のWindowsサンドボックスアプリはネットワーク分離の制約を受け、ローカルのループバックプロキシにアクセスできないことがあります。アプリがシステムプロキシを使っており、ブラウザーでは正常に接続できるのに、対象アプリの通信がコアに入らないことを確認してから、UWPのループバック例外を検討してください。クライアントに管理ツールがある場合は、対象アプリだけに許可を設定します。すべてのアプリをまとめて変更しないでください。ループバック例外で解決できるのはローカル入口へのアクセス制限であり、サブスクリプション切れ、ノードのタイムアウト、ルールの指定ミスではありません。

アプリに独自のプロキシ設定がある場合は、システム設定と競合していないか確認してください。クライアントを停止する前にシステムプロキシを無効にし、停止済みのポートへ接続し続けないようにします。グローバルモードでは使えるのにルールモードで失敗する場合は、両方のモードでポリシー経路を記録してからルールの章を確認してください。明示的なプロキシテストでどのノードも失敗するなら、まずノードとネットワークを調べます。初回接続の確認には接続チェックリストも役立ちます。スイッチの色だけで判断しないでください。

6. Clashのカスタムルールを書く

上から順に照合し、最初に一致したルールを適用

ルール一覧には順序があり、条件の順不同な集合ではありません。コアは通常、上から順に確認し、一致した時点で対応するポリシーを選びます。そのため、具体的な例外は広い範囲のルールより前に、フォールバックルールは末尾に置きます。MATCHが残りの接続をすべて受け取ると、その後に通常のルールを書いても適用されません。振り分けを変更するときは、構文が解析できるかだけでなく、ルールの位置とポリシー名も確認してください。

DOMAINはドメイン名の完全一致、DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRはIPアドレスの範囲、GEOIPはIPアドレスの地域情報に基づく照合に使います。ドメインルールには、コアが該当する名前を取得できることが必要です。IPルールは宛先アドレスや関連データを参照します。ドメインルール一つですべてのアクセス方法に対応できるわけではありません。アプリがIPアドレスへ直接接続する場合、独自の名前解決を行う場合、接続を再利用する場合は、接続パネルで実際の宛先も確認してください。

範囲を絞った例外でルール順を検証する

以下の例では、ドキュメントのドメインをDIRECT、コードホスティングのドメインをPROXYに振り分けた後、中国のIPアドレスと残りの通信を処理します。PROXYは実際の設定内で定義済みである必要があります。ネットワーク範囲のルールにあるno-resolveは、そのIP照合のために追加の名前解決を行わない指定です。設定全体のDNSを無効にする意味ではありません。これは順序を説明する例です。現在のネットワークに適しているか、用途に照らして一つずつ確認してください。

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

ルールを追加したら設定を再読み込みし、新しい接続を作成します。一致したルール、宛先ドメイン、最終的なプロキシグループを確認し、実行中の設定に変更が反映されたか確かめてください。前のルールに一致しているなら、順序を変えるか上位ルールの条件範囲を狭めます。ドメインではなく常にIPが表示される場合は、アプリの名前解決方法とDNS経路を調べます。複数のドメインを使うサービスでは、トップページだけにルールを設定せず、ログイン、API、リソース用ドメインの接続も確認してください。

ルールセットとローカル上書きの範囲

ルールが増えたら、rule-providersでルールセットを参照し、rules内でRULE-SETを使えます。セットの動作タイプは内容に合わせてください。ドメイン一覧、IPアドレス一覧、クラシックルールを自由に混在させることはできません。リモートセットの更新に失敗しても、コアが既存のキャッシュを使い続ける場合があります。そのため、画面にセットが表示されていても、直近のダウンロードが成功したとは限りません。更新日時、ログ、実際の接続でどのルールに一致したかをあわせて確認してください。

サブスクリプションのルールとローカルルールをマージするときは、最終的な並び順が重要です。上書き設定によってrules配列全体が置き換わる場合も、前後に追加される場合もあります。MATCHの後ろに例外を追加しても、通常は目的を達成できません。長期的に管理するには、ローカルルールを明確な個別差分に絞り、追加した理由を記録してください。外部ルールを丸ごとコピーすると、条件の重複や分類の古さを招き、問題発生時にどの層を直すべきか判断しづらくなります。

ルールのテストには、DIRECTになるべき接続とプロキシを通すべき接続を一つずつ含め、一方の修正で別の用途に影響しないか確認してください。REJECTを使う場合は、ログインに必要な接続ではなく、本当に拒否したい接続であることを確認します。設定を共有する前に、個人用ドメインとLAN内の構成を削除してください。よく使う照合方法を理解してから、プロセスルールなどOS依存の条件を試しましょう。プロセス識別の対応状況や権限要件はOSによって異なるため、一台での動作をすべての環境で保証されるものと考えてはいけません。

7. TUNとDNSを設定する

TUNによる通信の取り込みとシステムプロキシの違い

TUNは仮想ネットワークインターフェースとルーティングを使って通信を受け取り、システムプロキシに従わない一部のアプリも対象にできますが、ノードを高速化する機能ではありません。有効にすると通信の入口とDNS経路が変わるため、通常のプロキシ接続が使えることを確認してから設定してください。OSによってはバックグラウンドサービス、管理者権限、ネットワーク拡張の許可が必要です。モバイル端末では通常、システムのVPNインターフェースを使います。利用できる設定項目は、クライアントが採用するコアと公開している設定画面によって異なります。

同じ種類のルートを制御するVPNやTUNアプリがほかに動いていないことを確認してから、クライアントのTUNを有効にします。有効化前に、ローカルネットワーク、LAN内ドメイン、主要なサービスが使えるか記録し、一つずつ比較してください。企業VPN、仮想マシンのネットワーク、リモート管理経路は自動ルーティングと競合する可能性があります。唯一のリモートセッション上で、いきなり通信の取り込み方式を切り替えないでください。管理接続を失わないよう、ローカルコンソールか別の復旧経路を先に確保します。

DNSを通信経路全体の一部として扱う

DNSはサーバーアドレスを一つ設定するだけではありません。誰が問い合わせるか、どの経路で問い合わせが送られるか、回答がどうアプリに渡されるか、ルールで名前解決の結果をいつ使うかも関係します。fake-ipモードでは、ドメインに対応付ける仮想アドレスを割り当て、コアが実際の宛先と関連付けます。これはノードの出口アドレスではありません。LAN内サービスやデバイス検出など、実アドレスが必要な場合は、問題に合わせて例外を設定してください。すべてのドメインで一律にマッピングを無効にするのは避けましょう。

以下はTUNによる通信の取り込みと内蔵DNSの関係を示すmihomoの学習用設定例です。DNSの待ち受けはローカルのループバックアドレスに限定しています。例の上流DNSに接続できるかは、現在のネットワークによって異なります。既存のノード、ルール、クライアントに必要な設定を残したうえでマージしてください。画面にDNSやTUNの設定項目がある場合は、まず画面から変更して最終設定を確認します。同じ項目を複数の場所から繰り返し上書きしないようにしてください。

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1

dns-hijackのポート指定は、該当する従来型DNSリクエストを対象とするもので、あらゆる暗号化DNSの経路を自動的に処理するわけではありません。ブラウザーやアプリが独自に暗号化DNSを使うと、ドメイン名の見え方やルール判定の条件が変わる場合があります。トラブル時はこれらの設定を記録し、一時的に名前解決の経路を統一して結果を比較してください。DNSの上流に接続するためにプロキシが必要な場合は、ノード自身の名前解決が、まだ確立していない同じプロキシ経路に依存しないよう注意します。

症状に応じて戻し、一度に複数の層を変更しない

TUNを有効にしてすべてのアプリが接続できなくなった場合は、まずTUNを無効にし、システムプロキシでの基本接続が戻るか確認してから、ルーティング、権限、ログを調べます。ドメイン名では失敗するがIPアドレスには接続できる場合はDNSを重点的に確認してください。LAN内サービスだけが失敗するなら、プライベートネットワークのルートとLAN内DNSを調べます。特定のアプリだけに問題がある場合は、そのアプリが使うプロトコルと接続経路を確認します。変更は一度に一つの層に絞り、どの変更で復旧したか分かるようにしてください。

TUNを停止したら、仮想インターフェース、ルート、システムDNSが正常に戻ったか確認してください。Webページが表示できるようになっても、バックグラウンドアプリの古い接続を見落とさないようにします。複数のネットワーク取り込みツールを重ねて、不具合を「補う」運用も避けてください。通常のWeb閲覧、システムプロキシを使わないアプリ、LANへのアクセス、スリープ復帰後の再接続まで確認して初めて、動作を十分に検証できます。ブラウザーのプロキシだけが必要なら、よりシンプルなシステムプロキシの方式を使えばよく、保守対象を増やしてまで高度な機能を有効にする必要はありません。

8. 設定を保守し、トラブルを調べる

動作する基本設定を残して復旧に備える

日常のメンテナンスでは、現在何を使っているか把握し、変更に失敗しても元に戻せる状態を保つことが大切です。少なくともクライアント名、コアの提供元、現在のProfile、ローカルの入口ポート、上書き設定の保存場所を記録してください。バックアップではリモートの元設定と個人用の拡張を分け、サブスクリプションから再取得できないルールは特に保存します。バックアップにはノードの認証情報やサブスクリプションURLが含まれる場合があるため、管理された場所に保管し、公開リポジトリへアップロードしたり、安易に他人へ送ったりしないでください。

クライアント、コア、サブスクリプションの更新はそれぞれ別の変更です。クライアントの更新でサービス管理やマージの仕様が変わることがあり、コアの更新で対応フィールドが変わることがあります。サブスクリプションの更新ではノード、グループ名、ルールが変わる可能性があります。問題が起きたら、まず直近でどの層を変更したか確認してください。一度のトラブル対応でクライアントを更新し、サブスクリプションを差し替え、DNSも書き換えるのは避けましょう。復旧しても原因の特定や安定設定の再現が難しくなります。

「インターネットに繋がらない」を具体的な症状に分ける

接続ログがまったくない場合は、アプリの通信がローカルの入口に入っているか、システムプロキシが正しいポートを参照しているかを確認します。ログがあるのにノード接続がタイムアウトする場合は、ノードの状態、リモートアドレスへの到達性、現在のネットワーク制限を重点的に調べてください。名前解決エラーが出る場合は、DNSリクエストとノードアドレスの名前解決を確認します。明確なHTTPエラーが返る場合、接続が何らかのサービスまで到達している可能性があります。プロキシ認証、宛先サービスによる拒否、アカウントやサービス側の制限を切り分けてください。

確認できた症状優先して確認する項目次に行うこと
コアが起動しない設定の構文、フィールド参照、ポート起動時の最初のエラーを確認し、一項目ずつ修正する
接続パネルにリクエストが表示されないシステムプロキシ、アプリのプロキシ、TUNの入口プロキシを明示したリクエストで比較する
ルールには一致するが接続に失敗するプロキシグループの選択、ノード、名前解決利用可能と分かっている別の回線と比較する
特定のネットワークだけで失敗する接続時の認証、DNS、プロトコルの到達性別のネットワークで同じテストを行う

ネットワーク切り替えやスリープ復帰後は、無効になったインターフェースに古い接続が依存したままの場合があります。まず新しいリクエストを作成し、その後でコアの再起動を試してください。すぐに設定を削除する必要はありません。公衆Wi-FiでWeb認証が必要な場合は、プロキシを戻す前に認証を済ませます。そうしないとサブスクリプションの更新やノードの確認も失敗し、すべての回線が突然使えなくなったように見えることがあります。モバイル端末ではバックグラウンド実行の制限も確認し、画面ロック後にOSがクライアントのプロセスやネットワークセッションを停止していないか調べてください。

原因を特定できるログを取り、記録範囲を管理する

通常は情報レベルのログを使い、調査が必要な場合だけ短時間、詳細度を上げて一度再現したら元に戻します。詳細ログを長期間大量に出し続けると、ディスクへの書き込みが増え、ドメイン名、パス、接続メタデータが記録される可能性もあります。問題を報告するときは、操作の順序、OS、エラーが起きた時刻、関連する数行のログを添えれば十分です。サブスクリプション、認証情報、個人のネットワーク情報は削除してください。入口、ポリシー、エラーの種類が分からず、単に「繋がらない」だけでは、実行可能な判断を下すのは困難です。

ノードの接続テストは成功するのに実際の用途で失敗する場合は、同じ用途で比較し、UDP、複数ドメイン、独自の名前解決が使われていないか確認してください。テスト先と実際のサービスは別のため、結果が異なっても矛盾ではありません。ルールの問題を隠すためにグローバルモードを常用するのも避けてください。経路を短時間比較する用途には使えますが、最後は必要なモードに戻して該当条件を修正します。LAN内通信、更新サービス、ほかのアプリの通信が意図せず別経路へ送られないようにしましょう。

メンテナンスの最後に、不要になったデバッグ機能を無効にし、重複した自動起動項目を整理します。クライアントを終了したとき、システムが想定どおりの状態に戻ることも確認してください。有効だった変更は、どのルールをどの症状に対して変更し、どう検証したかを簡潔に記録します。次に同じ問題が起きたら、その記録を先に確認し、見知らぬ設定を丸ごとコピーしないようにします。安定した設定の価値は項目数ではなく、一つひとつの変更に観察可能な理由と結果があることです。

9. 検証しながら応用へ進む

一台での利用から、保守しやすい設定へ

前の8章を終えたら、必要なことを明確にして応用へ進んでください。ノードを頻繁に手動で切り替えるならプロキシグループの選び方、同じルールを何度も管理しているならルールセット、サービスを常時動作させたいならコマンドラインとサービス管理を学ぶとよいでしょう。外部の設定にある項目をすべて自分の環境にコピーする必要はありません。ルーターで意味のある設定がモバイル端末にも適しているとは限りません。依存条件、権限、元に戻す方法を事前に確認してください。

プロキシグループのselectは手動で明示的に選ぶ場合に適しています。url-testは指定したプローブの結果に基づいて候補ノードを比較し、fallbackは利用可否と順序に応じて選びます。自動選択は実際の用途での品質を保証するものではなく、プローブに成功してもすべてのサービスが利用できるとは限りません。設定ではプローブ先、確認間隔、候補の範囲を明確にし、順位を見るためだけに何度もテストしないようにしてください。利用する地域を安定させたい場合は、自動で頻繁に切り替えるより、適切な回線を手動で固定するほうが目的に合うことがあります。

コマンドラインで導入する場合は、検証してから常駐させる

GUIのないLinux環境では、まず前面で設定を検証し、ログとファイルの場所を確認してからsystemdなどのサービス管理に登録してください。作業ディレクトリと設定ディレクトリを混同しないようにし、ルールセットの相対パスも安定した場所に置きます。以下のコマンドは、mihomoが実行可能なパスにあり、現在のディレクトリに完全な設定ファイルがあることを前提としています。構文チェックに通っても、ノード、DNS、接続先のサービスが利用できるとは限りません。

mihomo -t -d ./mihomo-data -f ./config.yaml
mihomo -d ./mihomo-data -f ./config.yaml

前面で正常に動作することを確認してから、システムの規則に従ってサービス用ユーザー、作業ディレクトリ、設定ファイルのパス、再起動ポリシーを設定します。すべての処理に高い権限のアカウントを使うのは避けてください。TUNに特定のネットワーク権限が必要なら、導入先の環境に応じて必要最小限の権限を付与します。サービスログでは、プロセスの終了とネットワークリクエストの失敗を区別してください。設定エラーによる無限再起動は、放置しても直りません。デスクトップ版とコマンドライン版の違いはLinuxでClashを導入する2つの方法を参照してください。

管理インターフェースとネットワーク共有は個別に評価する

外部コントロールインターフェースは管理用の入口であり、通常のプロキシ入口ではありません。コントロールパネルが必要な場合は、本機または管理下のネットワークに限定し、適切な認証を設定してください。インターネットに直接公開してはいけません。LANプロキシを公開する場合も、アクセス範囲とファイアウォールのルールを別途設定します。管理インターフェース、サブスクリプションの認証情報、プロキシ認証は、それぞれ異なる対象を保護します。一つを設定しただけでほかも保護されるわけではないため、実際の待ち受けアドレスを個別に確認してください。

ルーターやゲートウェイへの導入はほかの端末にも影響し、単一端末よりリスクの範囲が大きくなります。テスト用端末と迂回できる復旧手段を用意し、ネットワーク範囲、DHCP、DNS、出口ルートの関係を確認してから、対象範囲を少しずつ広げてください。IPv4で正常でもIPv6の経路が同じとは限りません。また、一度Webページを開けただけではUDPが正常とは判断できません。対象範囲を広げるたびに、直接接続、プロキシ接続、LAN内通信を検証してください。外部サイト一つだけで判断しないようにします。

最後に、現在の環境に合わせた確認リストを作成します。コアの起動、サブスクリプションの更新、DIRECTルール、プロキシルール、DNS、ネットワーク切り替え、終了後の復旧を含めてください。変更のたびに主要な条件を一つだけ変え、変更前後のログと設定差分を残します。実験に失敗したら、まず利用できる状態に戻してから原因を整理してください。最短の接続手順をやり直す場合は使い方ガイドへ、クライアントを変える場合はダウンロードセンターを確認してください。ソフトの移行を、あらゆるネットワーク問題の解決策と考えないでください。

Clash最新版をダウンロード