Clash使い方ガイド

1. 基本概念と通信の流れ

クライアント、コア、ノード、サブスクリプション

Clashは単一のインストーラーを指す名称ではありません。実際の利用では、GUIクライアントが設定画面、プロキシ画面、接続一覧、システム設定を提供し、コアが接続を受け付け、宛先を解析してルールと照合し、通信先への接続を確立します。mihomoは、このエコシステムでよく使われるコアです。画面が似ていても、コアの機能まで同じとは限りません。設定項目が機能するかは、クライアントが設定をどう生成するか、コアがその項目に対応しているかの両方を確認してください。

ノードは、リモートサーバーへの接続に必要なパラメーターのまとまりで、通常はサーバーアドレス、ポート、プロトコル、認証情報などを含みます。クライアント自体がノードサービスというわけではなく、インストールしただけで利用可能な接続先が得られるわけでもありません。サブスクリプションは、設定やノード一覧を取得・更新するための手段です。アクセス用の認証情報が含まれることが多いため、パスワードと同じように扱い、スクリーンショットやログ、問い合わせ文にリンク全体を載せないでください。

設定ファイルは、これらの要素をまとめて管理します。受信ポートがローカルの通信を受け付け、ノードがリモート側の出口を定義し、プロキシグループが出口を選択可能な集合にまとめ、ルールが接続先のグループを決めます。サブスクリプションには、設定一式が含まれる場合とノード一覧のみの場合があります。追加後はどの要素が実際に作成されたかを確認してください。設定画面に名前が表示されただけで、接続の準備が整ったと判断しないようにしましょう。

まず通信の取り込み、次に振り分けを確認

通信の問題は、2つの段階に分けて考えられます。1つ目はアプリの通信がコアに入っているかどうかで、通常はシステムプロキシ、アプリ独自のプロキシ設定、またはTUNで取り込みます。2つ目は、コアに入った通信をルール、プロキシグループ、ノードでどこへ送るかです。接続一覧に記録がまったくない場合と、記録はあるのにリモート側でタイムアウトする場合では、問題の層が異なります。前者は通信の取り込み、後者はルール、名前解決、出口を確認してください。

システムプロキシは、システム設定に従うアプリにプロキシアドレスを知らせる機能であり、すべての通信を必ず通す経路ではありません。ブラウザーは利用しても、一部のゲーム、コマンドラインツール、バックグラウンドサービスは無視することがあります。TUNは仮想NICとルーティングを使って取り込み範囲を広げますが、経路の除外、アプリの動作、システム権限の影響を受けます。取り込みが成功しているかは、スイッチの色だけでなく接続記録で確認しましょう。

4つの確認ポイントで判断材料をそろえる

トラブル対処では、まず現在の設定が有効か、コアが起動しているか、アプリの接続がコアに入っているか、選択されたポリシーでアクセスできるかを順に確認します。それぞれについて、設定画面の有効状態、ログの待ち受け情報、接続画面の宛先ドメインとポリシー経路など、確認できる証拠を残してください。証拠が得られない段階で止めて、その層を調べます。DNS、ノード、ルールを同時に変更すると、変更同士が原因を覆い隠すため避けてください。

遅延テストと実際のサービスへのアクセスも区別しましょう。クライアントのテスト機能は、通常、特定のテスト先にリクエストを送ります。結果から分かるのはその経路で通信できたかどうかで、すべてのWebサイト、動画サービス、ログインAPIが使えることまでは証明できません。続けて、実際に使うアプリで確認し、時刻、ネットワーク環境、エラー内容を記録してください。同じアクセス経路で設定を比較できるようになります。

2. クライアントとプラットフォームの選び方

OS、アーキテクチャ、メンテナンス状況で選ぶ

初めて使う場合は、まずClash Plusを検討し、そのうえでプラットフォームに合った他のクライアントと比較してください。画面の見た目ではなく、OSとCPUアーキテクチャを確認して選びましょう。Windowsでは一般的なx64のほか、一部の端末でARM64が使われています。macOSではIntelとApple Siliconを区別し、Androidではインストーラーが対応する命令セットを確認します。アーキテクチャが合わないと、インストールや起動に失敗したり、変換レイヤーが必要になったりすることがあります。ファイルの拡張子だけで判断しないでください。

対応OSのバージョンは、ダウンロードページとクライアントの最新の説明を確認してください。同じWindowsやAndroidでも、すべての世代のOSで同じインストーラーが動作するとは限りません。ダウンロード前に、インストール権限、空き容量、仮想NICを作成できるかも確認しましょう。組織管理の端末では、ネットワーク拡張やサービスのインストールが制限されることがあります。その場合は端末管理者にポリシーを確認し、権限の制限をノードの問題と誤認して接続先を何度も変更しないでください。

デスクトップとモバイルの違い

Windowsでは通常、まずシステムプロキシでブラウザーの接続を確認し、その後でTUNを使うか判断します。macOSではチップのアーキテクチャに加え、アプリやネットワーク拡張に対するシステムの許可を確認してください。Linuxはデスクトップ環境によってシステムプロキシの対応が異なり、スイッチが機能してもターミナルのプログラムが従うとは限りません。サーバーやルーターではmihomoを直接実行できますが、サービスの起動、設定ファイルの場所、待ち受け範囲、ログ管理は自分で行う必要があります。

Androidのクライアントは通常、システムVPNインターフェースを使って通信を取り込むため、デスクトップと同じ手順でシステムプロキシを設定することはできません。初回起動時にVPN接続を許可し、継続利用では省電力設定も確認してください。Surfboardの設定形式はClash YAMLと異なります。ファイルの拡張子を変更するだけではなく、サブスクリプションが対応形式を提供しているか確認しましょう。バックグラウンド設定についてはAndroidのバッテリー消費とバックグラウンド動作の設定をご覧ください。

iOSではClash Plusを選択できます。App Storeの製品ページでシステム要件を確認してください。公式サイトはclashplus.ioです。VPN構成を許可した後、対応する設定を追加し、実際にアクセスできるか確認します。スマートフォンにVPNのアイコンが表示されても、ネットワークインターフェースが使用中であることを示すだけです。サブスクリプションが有効か、選択した出口に到達できるかまでは確認できません。

移行にかかる手間も考慮する

Clash for WindowsとClashX Metaは開発が終了しています。既存環境の参考資料としては使えますが、新しい端末に導入するクライアントとしては推奨できません。古いクライアントが起動しても、現在のサブスクリプションで使うプロトコルや設定項目に対応しているとは限りません。移行前に既存のルール、プロキシグループの選択、LAN設定を記録し、新しいクライアントには設定を別途追加してください。復元に必要な情報を失わないよう、古いディレクトリを直接上書きしないでください。

比較のために1台の端末へ複数のクライアントを残してもかまいませんが、検証時に通信を取り込むクライアントは1つだけ起動してください。複数のシステムプロキシ設定、VPNインターフェース、TUNルートが同時に動くと、通信の経路が分かりにくくなります。各プラットフォームのダウンロード先はクライアントのダウンロードにまとめています。候補を決めたら、まず最小限の接続テストを行い、その後にショートカット、上書き設定、接続画面を比較しましょう。最初から高度な設定をすべて移行する必要はありません。

3. インストールと初期確認

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

まず実行中のプロキシクライアントとVPNを終了し、通常のネットワークで普段使うサイトにアクセスできることを確認します。システムプロキシが有効か、DNSを手動設定しているか、端末が社内ネットワークに接続しているかも記録してください。インストール後に問題が起きても、元の状態に戻す基準ができます。組織のプロキシ経由でネットワークを利用している端末では、設定をすぐに消去しないでください。アドレスとポートを控え、別のネットワークツールを併用できるか確認しましょう。

ダウンロードページからアーキテクチャに合ったインストーラーを入手し、OSの手順に従ってインストールします。デスクトップでは、インストール時の権限と通常利用時の権限は別です。サービスのインストールには管理者の許可が必要な場合がありますが、システムプロキシでの通常利用には必要ないこともあります。考えられる問題をすべて排除するために、クライアントを常に最高権限で実行するのは避けてください。TUNを使う場合に限り、クライアントの説明に沿って補助サービスをインストールし、サービスの提供元とインストール先が使用中のクライアントのものか確認してください。

初回起動時に、設定、プロキシ、接続、ログの4つの画面を確認してください。設定画面では使用するファイルを、プロキシ画面ではプロキシグループの出口を選びます。接続画面には通信がコアに入ったかどうかが表示され、ログ画面では設定の読み込みや接続のエラーを確認できます。各画面の場所はクライアント画面の構成ガイドを参照してください。初期設定では、まず自動起動、LAN共有、TUNを無効にして、確認する項目を絞りましょう。

待ち受けポートとシステムプロキシを確認する

有効な設定を追加したら、コアが正常に起動しているか、混合ポートで待ち受けているかを確認します。混合ポートは通常、HTTPとSOCKSの両方のプロキシリクエストを受け付けます。実際のポート番号は有効な設定によって決まります。以下は受信と直接接続を確認するための独立した設定例で、プロキシノードは含まれていません。リモートのプロキシサービスの検証には使えません。利用前にポートが他のプロセスに使われていないことを確認し、テスト後は自分の設定に戻してください。

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

rules:
  - MATCH,DIRECT

システムプロキシのサーバーアドレスにはローカルの待ち受けアドレスを、ポートには現在のコアと同じ番号を設定します。YAMLのポートだけを変更しても、クライアントがシステムに設定したプロキシの項目まで同期されるとは限りません。ポートが競合する場合は、クライアントの設定画面で変更できることがあります。変更後は両方の設定が一致するか、もう一度確認してください。設定を切り替えると有効なポートも変わる場合があります。古い番号を記憶に頼って各アプリに設定しないようにしましょう。

curlが使える環境では、次のコマンドでローカルのHTTPプロキシを明示して実行できます。HTTPレスポンスが返れば、少なくとも指定した受信経路を通ってアクセスできたことが分かります。リモート側が返したサービスのステータスは別途確認してください。ブラウザーで失敗し、このコマンドで成功する場合は、クライアントをすぐに再インストールするのではなく、ブラウザーのプロキシ拡張、独自のプロキシ設定、既存の接続を先に確認しましょう。

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

Windows UWPのループバックと例外

Windowsの一部のアプリコンテナーにはループバック通信の制限があり、通常のデスクトップアプリのようにローカルプロキシへ接続できないことがあります。ブラウザーは使えるのに、ストアアプリの接続記録が表示されない場合などが該当します。まず対象アプリがシステムプロキシを使っているかを確認し、そのうえで必要ならクライアントのUWPループバックツールを検討してください。信頼できるアプリのうち、実際に必要なものだけを例外に設定し、変更内容を記録しましょう。ループバックの例外設定は、すべてのストアアプリのネットワーク障害を解決する機能ではありません。

初期確認が完了した目安は、設定を正常に読み込める、待ち受けポートが分かる、テストリクエストの記録がある、終了後にネットワークが復旧する、の4点です。クライアントが異常終了してもブラウザーがローカルポートを参照している場合は、残っているシステムプロキシを解除し、バックグラウンドのプロセスを確認してください。インストールの問題とノードの問題は分けて記録しましょう。前者はプログラムが動くかどうか、後者は有効な設定で想定した出口へ接続できるかどうかの問題です。

4. サブスクリプションの追加と設定管理

サブスクリプションの内容を確認してから追加する

設定画面で「リモート設定を追加」「リンクからインポート」などの項目を選び、サービス提供元から受け取った対応済みのサブスクリプションリンクを貼り付け、見分けやすい名前を付けます。コピー時に空白や改行、チャットアプリが付加した句読点が混ざらないよう注意してください。リンクの用途も事前に確認しましょう。Web管理画面、購入ページ、サブスクリプションURLは別のものです。ブラウザーでページが開けても、コアが読み込める設定とは限りません。

ダウンロード後は、設定にノード、プロキシグループ、ルールが含まれているか確認してください。リンクによってはノード一覧をエンコードしたデータだけが返されるため、クライアントがその形式のインポートに対応している必要があります。完全なYAMLを返すリンクもあります。形式エラーが出たら、まずエラー行の前後を確認し、設定ファイルではなくログイン画面やエラーページを受信していないか判断しましょう。認証情報を含むサブスクリプションを、運営元が不明なオンライン変換サービスに渡さないでください。変換を依頼すること自体が、相手に内容を見せることになります。

設定の追加と有効化は別の操作です。設定一覧に項目が追加されたら、それを有効な設定に指定し、コアの再読み込みを待ってから、プロキシ画面にグループが表示されるか確認してください。読み込みに失敗しても、直前まで使えていた設定は残しておき、同じ名前の設定を続けて追加しないでください。まず今回ダウンロードした内容が完全か、項目が対応しているかを確かめてから、形式を修正するか設定の提供元に問い合わせましょう。

リモートの設定とローカルの変更を分ける

リモート設定を更新すると、サブスクリプションのファイルに直接加えた変更が上書きされる場合があります。LANルール、DNS設定、プロキシグループの追加などを継続して使う場合は、クライアントが対応するオーバーライド、マージ、スクリプト拡張機能を優先してください。マージの順序はクライアントによって異なります。ルールが前に追加されるか後ろに追加されるか、リストが置き換えられるか統合されるかを確認しましょう。保存後は編集欄の元テキストだけでなく、最終的に有効な設定を確認してください。

オーバーライドを使わない場合は、練習用にローカル設定のコピーを作成できます。ただし、ローカルコピーにはリモートのノード変更が自動反映されません。元のサブスクリプション、テスト用コピー、確認済みのコピーにそれぞれ別の名前を付け、直近の変更内容と目的を記録しておきましょう。更新後に問題が起きても、上流の設定変更が原因か、ローカルルールによる上書きが原因かを判断でき、設定全体を一から作り直さずに済みます。

サブスクリプションの更新に失敗した場合の切り分け

まずダウンロードの失敗と設定の解析エラーを区別してください。ダウンロード失敗の原因には、ネットワークに接続できない、証明書の時刻が合わない、リンクが無効、サーバーに拒否された、などがあります。解析エラーは通常、データを受信した後に発生します。ログに記録されたエラーの種類と発生時刻を確認し、赤いステータスだけで判断しないでください。端末の時刻が大きくずれている場合は、先に修正します。権限や利用上限に関する応答があれば、DNSを何度も変更するのではなく、サービスの管理画面でアカウント状態を確認しましょう。

更新リクエストがどの経路を通るかも確認してください。クライアントによっては、直接接続するか、現在のプロキシ経由で更新するかを選べます。現在の設定が無効な場合、その設定に依存した更新ができず、起動時に行き詰まることがあります。信頼できるネットワークで、もう一方の更新経路を試すことはできますが、クライアントごとに設定項目が同じとは限りません。更新方法だけを一度に1つ変更し、他の設定はそのままにして、まずダウンロードが成功したか確認してから新しい設定の有効性を調べましょう。

更新が成功しても確認を終えないでください。上流の変更でノード名やプロキシグループ、ルールが変わり、以前の手動選択が参照できなくなる場合があります。有効な設定、グループの選択肢、実際の接続をそれぞれ確認してから普段のアクセスを行いましょう。手順を簡潔に確認する場合はサブスクリプションの追加ガイドをご覧ください。この章では、リモート設定を更新でき、ローカルの変更を追跡でき、問題が起きたら元に戻せる状態を保つことを重視します。

5. プロキシモードとプロキシグループ

ルール、グローバル、直接接続の範囲

ルールモードでは、設定内のルールに従って出口を決めます。ローカルサービス、通常のWebサイト、プロキシ経由の宛先を使い分けたい日常の利用に向いています。グローバルモードでは通常、コアに入った接続をグローバルのポリシーに渡すため、問題が振り分けルールにあるか確認するのに便利です。直接接続モードでは、コアに入った接続を直接外部へ送ります。いずれのモードも、すでにコアに入った通信にのみ影響します。グローバルモードにしても、システムプロキシを無視するアプリが自動的に取り込まれるわけではなく、TUNの代わりにもなりません。

トラブル対処では、一時的にグローバルモードに切り替えて比較できます。同じ宛先がグローバルでは接続でき、ルールモードでは失敗する場合は、ルールのマッチングとプロキシグループの選択を確認してください。どちらでも失敗するなら、ノード、名前解決、ネットワークを調べます。比較時には同じノードを使い、新しい接続を確立してください。既存の長時間接続は変更前の出口を使い続けることがあります。更新ボタンを押すだけでは新しい接続が作られない場合があるため、対象アプリを閉じてからテストしましょう。

直接接続モードは、クライアントを終了することではありません。システムプロキシやTUNが有効なままなら、接続は引き続きコアに入り、処理されます。クライアントを経由しない元のネットワーク経路に戻すには、該当する通信の取り込み機能を無効にし、システムプロキシやVPNインターフェースの状態を確認してください。この違いを理解しておくと、クライアントが通信経路を占めたままシステムのネットワークが壊れたと誤認するのを防げます。また、直接接続モードでも接続一覧に記録が残る理由も分かります。

プロキシグループは出口を選ぶもの。ノード選択だけではない

プロキシグループにはノードだけでなく、別のプロキシグループも指定できます。手動選択グループは出口を固定したい場合に向いています。自動テストグループはテスト結果に基づいて候補を選び、フォールバックグループは設定された順に利用可能な項目を探します。自動選択の動作は、テスト先、間隔、許容値、コアの実装にも左右されます。自動ポリシーがすべての宛先で最速になるとは限りません。設定された探査条件に基づいて選択する仕組みです。

以下は、有効な設定に追加できるプロキシグループの例です。練習用の例では、組み込みポリシーは直接接続と拒否のみなので、読み込みに成功してもリモートプロキシは利用できません。実際に使う場合は、確認済みのノード一覧から候補を追加し、ルールから同じグループ名を参照してください。名前の大文字・小文字、空白、文字を正確に一致させましょう。存在しないグループをルールから参照すると、設定の検証に失敗したり、想定した振り分けができなくなったりする場合があります。

proxy-groups:
  - name: 出口グループ
    type: select
    proxies:
      - DIRECT
      - REJECT

rules:
  - DOMAIN-SUFFIX,example.com,出口グループ
  - MATCH,DIRECT

設定にPROXYと書かれていても、コアで必ず使う唯一のプロキシ名という意味ではありません。多くの場合、設定作成者が付けたプロキシグループ名にすぎず、「出口選択」など別の名前にもできます。名前と役割の関係が分かると、複数階層のポリシーも読み解きやすくなります。サービス別のルールから用途別グループへ進み、さらに地域別グループを経由してノードを選ぶ構成もあります。トラブル対処では最初のグループ名だけでなく、ポリシーの経路全体を展開して確認しましょう。

用途に合わせてノード選択を確認する

ノードを選ぶときは、実際に接続できるか、サービスが求める地域に合うか、回線が安定しているか、サービス側の通信量課金ルールに問題がないかを確認しましょう。遅延が小さいのは、探査経路が短いか応答が速いことを示すだけで、継続的なダウンロード速度が高いことを意味しません。動画、会議、ゲームをテストするときは、一定時間の実際の動作を観察してください。時刻やネットワーク環境が異なる単発の結果を、そのまま並べて比較しないようにしましょう。

接続元の変更に敏感なサービスでは、自動ポリシーによるバックグラウンドでのノード切り替えが、再認証やセッション切れを引き起こすことがあります。その場合は対象サービス用に手動選択グループを作り、出口を固定し、通常のブラウジングには自動選択を使う方法があります。比較方法はノードの遅延、倍率、地域、プロトコルの選び方をご覧ください。まず1つのノードが安定して使えることを確認してからポリシーの階層を増やすと、管理しやすくなります。

6. ルール振り分けとマッチングの確認

ルールは上から順に確認する

ルール振り分けでは、上から順に条件を照合し、最初に一致したルールで接続先のポリシーが決まります。そのため、具体的な例外ルールは広い条件のルールより前に置き、最後にデフォルトのルールを配置します。ドメインが前のサフィックスルールに一致すると、後ろにあるより具体的な項目が適用されない場合があります。ルールを追加する前に既存の順序を読み、項目を1つ増やせば古い動作を上書きできると思い込まないようにしましょう。

ドメインルールを使うには、コアが宛先のドメイン名を取得できる必要があります。アプリがIPアドレスへ直接接続した場合や、通信の取り込み経路で宛先情報が失われた場合は、想定したドメインルールに一致しないことがあります。その場合、接続画面に宛先アドレスだけが表示されることがあります。DNSモード、スニッフィング機能、アプリの動作をあわせて確認してください。ルールに一致しないからといってネットワーク全体をプロキシ対象にすると、ローカル端末や本来直接接続するサービスまでプロキシ経由にしてしまうおそれがあります。

最小限のルールから始めて、1つずつ追加する

練習では、動作を確認しやすいドメインルールと直接接続のデフォルトルールから始め、順序と宛先情報が正しいことを確認してからプロキシグループを追加します。以下は既存設定のルール部分に追加する例です。ループバックと一般的なプライベートアドレスを直接接続にし、例示ドメインでサフィックスマッチを確認できます。LANアドレスの完全な一覧ではなく、すべてのIPv6のケースも網羅していないため、あらゆる環境で使える最終テンプレートではありません。

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

no-resolveは、現在のIPルールを適用するためにドメイン名の解決を積極的に行わないようにする指定です。設定全体でDNSが使われなくなるわけではありません。接続先がすでにIPアドレスなら、アドレス範囲のルールに一致する場合があります。宛先がドメイン名だけで、まだIPアドレスを取得していない場合は、このルールに一致しないことがあります。地理ルールもデータベースと名前解決の結果に依存するため、Webサイトの言語や運営主体の所在地を基準に判定するものではありません。

リモートのルールセットを使う場合は、プロバイダー名、形式、動作タイプ、更新時刻も確認してください。ルールセットがローカルにキャッシュされていても、更新に成功したとは限りません。更新できても、対象サイトに関連するドメインすべてが含まれているとは限りません。トップページ、ログイン、画像、APIで異なるドメインが使われる場合があります。実際の接続記録に基づいて必要な項目を追加し、ブラウザーのアドレスバーにあるドメインを1つ追加するだけで済ませないようにしましょう。

出口を表示するWebサイトではなく接続記録で確認する

ルールを保存して設定を再読み込みし、新しいリクエストを送ってから、接続画面で宛先、適用ルール、ポリシー経路、最終的な出口を確認します。出口IPを調べるサイトに表示されるのは、その検索リクエストの出口だけです。別のアプリが同じポリシーを使っている証拠にはなりません。比較では、特定のページを再度開く、明示的なプロキシを指定してコマンドを実行するなど、再現しやすい操作を選びましょう。記録が表示されたらすぐにマッチング情報を確認してください。

カスタムルールを保存したのに消える場合は、リモートのサブスクリプションを直接編集していないか、マージ時にオーバーライドが置き換えられていないか確認してください。ルールは残っているのに一致しない場合は、順序、ドメイン情報が見えているか、既存の接続が再利用されていないかを確認します。正しいポリシーに一致してもアクセスできない場合は、ノードやDNSの確認に進み、ルールを追加し続けないでください。各層の確認には通信速度が遅いときの段階的なトラブル対処も活用できます。ネットワークの問題をすべて振り分けのせいにしないようにしましょう。

7. TUNとDNSの設定

システムプロキシが安定してから通信の取り込み範囲を広げる

TUNは、システムプロキシに従わないアプリの通信も取り込みたい場合に便利ですが、仮想NIC、ルート、DNS経路など新たな確認項目が増えます。デスクトップでは、まずシステムプロキシで設定とノードが使えることを確認し、その後クライアントの説明に従ってサービスをインストールするかネットワーク権限を許可してください。モバイル端末はシステムVPNインターフェースを使うため、デスクトップ向けサービスと同じ手順ではありません。同じ名前のボタンを機械的に探さないでください。インターフェースが作成できることと、通信を正しく転送できることは分けて確認します。

有効化前に、既存のVPN、仮想マシンのネットワーク、コンテナネットワークを記録し、経路の重複による通信の迂回を防ぎましょう。有効化後は一般的なドメインにアクセスし、LAN内の端末、業務用ネットワーク、既存VPNも確認します。LANだけに接続できない場合は、リモートノードを変更するのではなく、直接接続ルール、除外ルート、宛先ネットワークを確認してください。社内ドメインにアクセスするには、専用DNSの名前解決経路を維持する必要がある場合もあります。

DNS、Fake-IP、宛先の識別

DNSはドメイン名をアドレスに変換しますが、プロキシ接続がシステムDNSだけで決まるとは限りません。アプリ独自の名前解決、ブラウザーのセキュアDNS、システムの名前解決、コアのDNSが同時に使われることがあります。トラブル対処では、まずリクエストをどこが処理しているかを特定してから、変更する設定を決めましょう。リクエストがコアのDNSに届いていなければ、上流のアドレスを変更しても結果が変わらないことがあります。暗号化DNSへの初回接続では、最初の名前解決に別の手段が必要な場合もあります。

Fake-IPモードでは、アプリに対応付け用のアドレスを返し、コアがそのアドレスとドメインの関係を記録しておきます。その後、記録から本来の宛先を復元してルールを照合します。このアドレスはリモートサーバーの実際のグローバルIPではないため、サーバーの所在地を判断する用途には使えません。実際のアドレスやブロードキャスト探索、特殊な名前解決に依存するアプリでは、例外設定が必要な場合があります。仕組みの違いはFake-IPとRedir-Hostの解説をご覧ください。

以下は、これらの項目に対応するデスクトップ版mihomo向けの独立した直接接続テスト用設定です。DNSはローカルの高位ポートで待ち受けます。TUNの自動ルーティングとインターフェース検出には、引き続きシステム権限が必要です。項目の意味や通信の取り込みを確認するための設定であり、プロキシノードは含まれません。社内ネットワーク、他のVPN、特殊なルーティングを使っている場合は競合を先に検討し、稼働中の設定全体を直接置き換えないでください。

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

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
    - 8.8.8.8

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

rules:
  - MATCH,DIRECT

ルーティングと名前解決を個別に確認する

dns-hijackは条件に一致するDNS通信を受け取りますが、アプリがHTTPSなどを使って独自に名前解決する場合、通常のDNSポートを横取りする設定だけで自動的に置き換わるわけではありません。auto-routeは関連するルートを自動設定し、auto-detect-interfaceは出口インターフェースの検出を試みます。複数のNIC、仮想ネットワーク、デフォルトルートの変更がある環境では、手動での確認が必要な場合があります。項目が設定されているからといって、使用環境に合った出口が自動選択されるとは限りません。

ブラウザーは使えるのに他のアプリで失敗する場合は、そのアプリのリクエストが接続画面に表示されるか確認してください。ドメイン名では失敗するが既知のIPアドレスには接続できる場合は、名前解決を重点的に調べます。TUNを有効にした後にすべての通信が切れた場合は、まずTUNを無効にして元の経路を復旧し、サービス権限、デフォルトルート、通信の二重取り込みを確認してください。DNSモードを変更したら、アプリの接続を作り直し、必要なら該当するキャッシュを消去してから、新しい設定を検証しましょう。

最終確認では、Webページが開けるだけでなく、スリープ復帰、ネットワーク切り替え、クライアント終了後に通信が復旧することも確認します。TUNを無効にしても問題が続く場合は、補助サービスと仮想インターフェースが正常に終了したか、システムプロキシが残っていないか確認してください。通信の取り込み範囲が広いほど、復旧手順が重要になります。確認済みのシステムプロキシ設定を残しておけば、複雑なネットワーク障害でも比較の基準にできます。

8. 日常のメンテナンスと復旧

更新を3種類に分ける

クライアント、コア、サブスクリプションの更新は、それぞれ異なる問題に対応します。クライアントの更新では画面、サービス、設定生成の方法が変わることがあります。コアの更新はプロトコルや設定項目の対応に影響し、サブスクリプションの更新ではノード、ポリシー、ルールが変わります。メンテナンスでは一度に1種類だけ更新し、安定して動作することを確認してから次に進みましょう。3種類を同時に変更すると、問題が起きたときにどれを戻すべきか分かりにくくなり、設定の違いをプログラムの不具合と誤認することもあります。

更新前に、有効な設定、オーバーライド、重要な設定を保存し、システムプロキシのポート、現在のポリシー選択、TUNの状態、サービスのインストール状況を記録してください。バックアップは、画面のスクリーンショットだけでなく、実際の動作状態を復元できるものである必要があります。更新後は最終的に有効な設定を確認し、特にクライアントが自動管理する項目に注意しましょう。クライアントによっては画面の設定がYAMLを上書きするため、元ファイルの比較だけではすべての変更を把握できません。

ロールバックも段階的に行います。サブスクリプションの変更なら、確認済みのローカルコピーに戻します。オーバーライドの問題なら、その拡張機能を一時的に無効にします。クライアントの更新が原因なら、該当するインストール手順に沿ってプログラムやサービスを復旧してください。新しい設定ディレクトリに古いプログラムを直接上書きすると、設定構造やデータベースが互換性を失うおそれがあります。旧環境を試す場合は独立したバックアップを使用し、同じポートやネットワークインターフェースを複数のインスタンスが同時に使わないようにしてください。

自動起動とバックグラウンド動作

自動起動は通常、クライアントを起動する設定であり、コア、サブスクリプション、システムプロキシがすべて準備完了になることまでは保証しません。手動起動で動作を確認してから、クライアントの自動起動を有効にしましょう。次回の再起動後は、プログラムが起動したか、有効な設定が正しいか、通信の取り込みが想定どおりかを順に確認し、最後に実際のアクセスをテストします。コアが待ち受けを開始する前にシステムプロキシが有効になると、起動中に一時的にネットワークへ接続できない場合があります。

スリープからの復帰やネットワークの切り替えも確認が必要です。Wi-Fiから有線、スマートフォンのテザリング、別のルーターへ切り替えると、デフォルトのNICやDNSが変わり、TUNで経路を再検出する必要が生じることがあります。復帰のたびに失敗する場合は、インターフェースの変更とログの時刻を記録してから、通信の取り込み機能やコアを順番に再起動してみてください。繰り返し発生する障害をノードの不安定さと決めつけると、端末側のルート復旧の問題を見落とすおそれがあります。

Androidのバックグラウンド動作は、端末メーカーの省電力設定に合わせて調整します。まず必要なバックグラウンド動作を許可し、画面ロック後に接続が切れるか確認してから、必要に応じてバッテリー最適化の対象外に設定してください。すべてのアプリ権限を一度に許可したり、常時表示の通知を減らすためにシステムが求めるフォアグラウンド動作を無効にしたりしないでください。消費電力は、画面の明るさ、ネットワーク、利用時間が近い条件で比較し、画面、無線信号、プロキシ通信の影響を分けて考えましょう。

ログを適切な範囲に保ち、復旧手順をまとめる

日常のログレベルはinfoなど適切な値にし、具体的な問題があるときだけ一時的に詳細度を上げます。発生時刻、対象アプリ、エラー内容、そのとき使っていた設定を記録すると、調査対象を絞り込めます。ログにはアクセス先のドメイン、ノードのアドレス、認証情報が含まれることがあります。公開する前に内容を確認してください。調査が終わったら通常のログレベルに戻し、不要になった診断ファイルを削除して、機密性の高いアクセス記録を長期間残さないようにしましょう。

「Clashでインターネットに接続できない」場合は、まず通信の取り込みを無効にして元のネットワークを確認し、次に動作確認済みの設定へ戻してからノードとサブスクリプションの状態を調べます。元のネットワークでも接続できない場合は、端末の接続、ルーター、通信事業者の問題を先に解決してください。1つのアプリだけで失敗する場合は、そのアプリのプロキシ動作と接続記録を確認します。プロキシ対象がすべて失敗して直接接続は正常なら、ノード、サービスの状態、出口への接続を重点的に確認しましょう。

LAN共有は特に定期的な見直しが必要です。「LANからの接続を許可」を有効にすると、他の端末がローカルの待ち受けポートにアクセスできる範囲が変わります。家庭用Wi-Fiにつないでいるからといって、アクセス範囲を無視してはいけません。共有が必要な場合は認証を設定し、ファイアウォールで接続元の範囲を限定して、ネットワークを切り替えた後に設定を再確認してください。メンテナンスの目的は、すべての機能を常に有効にすることではなく、端末の通信経路にどの機能が影響しているかを把握することです。

9. 応用編と自分で行うトラブル対処

自動化を導入する前に設定の差分を管理する

応用設定は、設定ファイルを説明できる状態を作ることから始めましょう。設定の出どころを増やす前に、サブスクリプションが管理する部分、クライアントが生成する部分、ローカルで手動管理する部分を区別し、それぞれの変更場所を1つに決めます。同じDNS項目が画面設定、サブスクリプション、オーバーライドに重複している場合は、最終的にどれが優先されるか確認してから変更してください。そうしないと、再起動のたびに変更が反映されないように見えることがあります。

次に、ノードプロバイダーやルールプロバイダーを学び、接続パラメーター、ポリシーの仕組み、サービス別ルールを分けて管理できます。分割すると個別に更新しやすくなりますが、名前の参照、パス、キャッシュ、ダウンロードの依存関係も増えます。初めて使う場合は、小さな項目を1つだけ分割し、ダウンロード、形式、ポリシーからの参照が正常か確認してから残りを移行してください。すべてのリモートリソースを一度に追加し、起動結果だけで完了と判断しないようにしましょう。

自動テストやフォールバックも、実際の用途に合わせて設定してください。ログイン状態を維持したいサービスでは、遅延が多少大きくても頻繁に切り替わるより出口を固定するほうが適切な場合があります。一般的なブラウジングなら、自動選択による出口の変更を許容できることもあります。テスト間隔は通信量と検出の速さのバランスを考え、テスト先は必要な経路を安定して確認できるものにしましょう。複数のプロキシグループが同じノード群を重複してテストすると、不要なバックグラウンド通信が増える場合があります。

問題の再現を小さな実験にする

複雑な問題では、まず想定される動作を整理します。どのアプリがどの宛先へ接続し、どのルールに一致し、最終的にどの出口を通るべきかを書き出してください。次に、ブラウザーの新しいウィンドウで決まったページを開く、明示的にプロキシを指定したコマンドを実行するなど、最小限の操作を選びます。各回で変更する条件は1つだけにし、接続記録があるか、どのルールに一致したか、どの段階でエラーになったかを記録しましょう。再現性のある結論を得られ、他の人にも正確に状況を説明できます。

3つの環境を比較すると切り分けやすくなります。通信の取り込みを無効にした元のネットワーク、システムプロキシを使った動作確認済みの設定、同じ設定のTUNです。元のネットワークでは正常でシステムプロキシでは失敗するなら、受信経路と出口を確認します。システムプロキシでは正常でTUNでは失敗するなら、ルーティングとDNSの取り込みを重点的に調べましょう。特定のドメインだけで失敗する場合は、関連ドメイン、サービスの制限、ルールの経路を確認します。ソフトウェア一式を再インストールする必要はありません。

サーバーやリモート管理に進む前に

mihomoを直接実行する場合は、GUIクライアントが代わりに行っていた設定ディレクトリ、作業ディレクトリ、サービスユーザー、ログローテーション、異常終了時の再起動を自分で管理する必要があります。まずフォアグラウンドで設定を読み込めることを確認してから、システムサービスに登録してください。サービスの起動に成功しても、通信の取り込みが完了したとは限りません。待ち受けアドレス、ルート、権限も確認しましょう。ルーターで実行する場合は、ストレージ容量、アーキテクチャ、既存のファイアウォールルールも考慮してください。

リモートコントロール用APIでは接続一覧の確認やポリシーの変更ができます。必要な場合に限って有効にし、アクセス範囲を端末内または管理下のネットワークに限定して認証を設定してください。スマートフォンの管理画面につなぐためにインターネットへ直接公開しないでください。また、コントロール用ポートとプロキシの受信ポートを混同しないようにしましょう。設定を共有する前に認証情報を削除してください。リモート管理に問題がある場合は、待ち受け範囲を広げて試すのではなく、アクセス範囲と認証を先に確認します。

この段階を終えた目安は、リクエストがどのようにコアに入り、宛先情報を取得し、ルールに一致して出口へ到達するか説明でき、失敗時には問題の層を特定できることです。最短の操作手順をもう一度確認する場合は接続確認ガイドをご覧ください。各機能の仕組みをさらに知りたい場合は解説記事一覧からお読みいただけます。新しい機能を試すときは、確認結果と元に戻す方法を記録してから、次の設定に進みましょう。