設定を調べるためのガイド 基本概念 → 設定 → メンテナンス

Clashの使い方ガイド
サブスクリプションとルール振り分けの設定

初めてのインストールから独自ルールの管理まで、9段階で設定手順を身につけます。

まず接続だけを完了したい場合は、入門ガイドのクイックスタートをご覧ください。このページでは、各設定の理由と、問題が起きたときに確認する箇所を解説します。クライアントをインストール済みの方は、目次からサブスクリプション、ルール、TUNの各章に進めます。

Clashクライアントを選ぶ クイックスタートを見る

01 基本概念：通信はどのような経路を通るのか

クライアント、コア、サービスはそれぞれ別のもの

Clashのエコシステムでクライアントとは、通常、ウィンドウやメニューを備えたアプリを指します。サブスクリプションの管理やモードの切り替え、接続状況の確認に使います。コアはネットワーク通信の転送やルール判定を実行するプログラムで、Mihomoはこのエコシステムで広く使われるコアです。画面が開いたことから分かるのはアプリが起動したことだけで、コアが設定を読み込んだことや、通信がプロキシに届いていることまでは確認できません。問題を調べるときは各要素を切り分けると、何度も再インストールするより効率的です。

プロキシサービスは、リモート接続に必要なアドレス、プロトコル、認証情報を提供します。サブスクリプションは、こうした設定を配布する仕組みです。クライアントをインストールしただけでは、利用可能なサービスは用意されません。利用権限のあるサービス提供元から互換性のある設定を入手し、現地の法令、サービス利用規約、利用ネットワークの管理要件を守ってください。サブスクリプションURLにはアクセス認証情報が含まれる場合があります。公開の場に貼り付けたり、出所不明の変換サイトに渡したりしないでください。

まずリクエストの入口を把握し、次に出口を確認する

リクエストは通常、次の4段階を通ります。アプリがリクエストを送信し、システムプロキシまたは仮想ネットワークインターフェースからコアに届き、ルールが適用するポリシーを決め、そのポリシーが直接接続かリモートプロキシかを選びます。システムプロキシはOSがアプリに提供するプロキシ設定で、利用するかどうかはアプリ次第です。TUNはより広範な通信を取り込める仮想ネットワークインターフェースですが、ルーティング、権限、除外設定の影響を受けます。有効にすればすべてのプログラムが想定どおり動く、というわけではありません。

ノードは個別のリモート接続パラメーター、プロキシグループはノードやほかのポリシーをまとめて管理するものです。ルールにあるPROXYは、多くの場合プロキシグループの名前であり、どの設定にも自動で用意される組み込みキーワードではありません。DIRECTは直接接続、REJECTは通信の拒否を表します。ルールの適用先に名前が指定されていたら、設定にその名前があるか確認し、グループが最終的に何を選択しているかも確認してください。

階層確認する内容主な確認箇所
リクエストの入口アプリがリクエストをコアに渡しているかシステムプロキシ、TUN、アプリ側のプロキシ設定
ルール判定リクエストに適用されたルール接続の詳細、ルール画面
出口のポリシーポリシーグループが最終的に選択した出口プロキシグループ、接続経路
リモート接続サーバー、認証、プロトコルが利用可能かログ、サービス提供元の稼働状況

DNSとポートが通信結果に影響する理由

DNSはドメイン名をIPアドレスに変換する仕組みです。クライアントはシステムのDNSを使うことも、コア独自のDNSを有効にすることもあります。どの階層で名前解決するかによって、ドメインルールが使えるか、IPアドレスに対してどのルールが適用されるか、リクエストが名前解決を待つ必要があるかが変わります。接続に失敗しても、すぐにノードの障害とは限りません。ドメインを名前解決できない場合、解決したアドレスに到達できない場合、プロキシのハンドシェイクに失敗した場合は、それぞれ別の問題です。

ポートは、ローカルサービスの接続口を示す番号です。混合ポートは通常、HTTPプロキシとSOCKSプロキシの両方を受け付けますが、クライアントによってデフォルト値は異なります。このページでは例として7897を使います。実際の操作では、必ず現在のクライアントに表示されている値を使ってください。ポート番号が一致しても、通信がコアに届いているとは限りません。待ち受けアドレス、アプリの設定、そのポートを別のプログラムが使用していないかも確認します。

02 クライアント選び：プラットフォームと管理方法から考える

使用するデバイスに合ったGUIクライアントを選ぶ

初めて使う場合はClash Plusを候補にし、プラットフォームや使い方に応じてほかのクライアントと比較するとよいでしょう。画面の見た目だけで選んだり、チュートリアルのスクリーンショットと同じにするために古いソフトをインストールしたりするのは避けてください。確認すべきなのは、OSがサポートされているか、CPUアーキテクチャが一致するか、サブスクリプション形式に互換性があるか、必要なシステムプロキシ、ログ、TUNの管理機能があるかです。インストーラーはClashダウンロードページから選べます。

WindowsではClash Plus、Clash Verge Rev、FlClash、Clash Nyanpasuが候補です。macOSではClash Plus、Clash Verge Rev、FlClashを選べます。Linux向けのGUIクライアントにはClash Verge RevとFlClashがあります。いずれも似たコア機能を利用できますが、サービスのインストール方法、設定の上書き方法、権限管理は異なります。このページでは機能名を使って手順を説明し、特定のボタンの位置がすべてのクライアントで共通とは限らない点に注意します。

モバイルとデスクトップで異なる点

AndroidではClash Plus、Clash Meta for Android、FlClash、Surfboardから用途に合ったものを選べます。Surfboardの設定形式はClashのYAMLと完全には一致しないため、Clash用設定をそのままインポートしても各項目が対応するとは限りません。まずサービス提供元が用意しているサブスクリプション形式を確認してから、クライアントを選んでください。モバイルOSでは通常、VPNインターフェースを使って通信を取り込みます。初回接続時に表示されるシステムの許可画面も、通信を取り込む手順の一部です。

iOSではダウンロードページからClash PlusのApp Storeページに進めるほか、公式サイトのclashplus.ioも確認できます。スマートフォンのバックグラウンド制限やアプリごとの通信制御は、デスクトップのシステムプロキシ設定とは仕組みが異なります。複数のデバイスで設定を学ぶ場合は、メニュー名をそのまま当てはめるのではなく、ルールの考え方や設定同士の関係を応用してください。同じサブスクリプションを使えても、すべてのデバイスで同じ実行パラメーターを使えるとは限りません。

利用目的選ぶときの確認ポイント次に行うこと
初めて使うサブスクリプションの追加方法とシステムプロキシの設定箇所が分かりやすいかまずルールモードで接続する
独自ルールを管理する永続的な上書き、ルールの挿入、マージ機能があるか上書きの適用順を記録する
より多くのアプリの通信を取り込むTUN対応、サービス権限、システムとの互換性このページのTUNの章を読む
サーバーやルーターで使うコアのアーキテクチャ、起動方法、管理機能サービスとアクセス制御を個別に計画する

クライアントとコアを個別に使う

Clash for WindowsとClashX Metaは開発・保守が終了しています。ダウンロードページではアーカイブ版として掲載しています。既存の設定は移行時の参考にできますが、新しい環境では継続的にメンテナンスされているものを選ぶのがおすすめです。移行時はサブスクリプションの提供元、ルールの目的、プロキシグループの選択を引き継ぎ、新しいクライアントのデータフォルダー全体をそのまま上書きしないでください。旧バージョンのデータベース、キャッシュ、サービス登録情報は、新しいクライアントと互換性がない場合があります。

Mihomoコアのパッケージは、設定、プロセス、権限を自分で管理できるユーザー向けです。GUIを備えたインストーラーとは異なり、システムとの連携をすべて自動で設定するものではありません。ブラウザーをルールに従って接続することが目的なら、まずGUIクライアントで基本の流れを確認する方が簡単です。古い環境から移行する場合は、Clash for Windowsのサポート終了後に選ぶ代替クライアントと移行方法も参考にしながら、ポートやプロキシ設定を一つずつ確認してください。

この段階では、複数のクライアントを同時にインストールして「動作を比較」する必要はありません。まずメインのクライアントを一つ選び、ほかのツールを終了してください。複数のツールがシステムプロキシ、ルーティング、DNSを同時に変更すると、原因の切り分けが難しくなります。通信経路を一つに絞ることで、後の検証結果を正しく判断できます。

03 インストールの確認：OS、権限、ローカルポート

ダウンロード前にOSとCPUアーキテクチャを確認する

まずシステム情報を開き、OS、CPUアーキテクチャ、空き容量を確認します。Windowsの一般的なインストーラーはx64向けです。macOSではIntelとApple Siliconを区別し、Linuxではディストリビューションに合ったパッケージ形式を選びます。ファイル名にARMとあっても、すべてのARMデバイスで同じファイルを使えるとは限りません。ダウンロードページに記載されたアーキテクチャとクライアントの要件を確認し、拡張子の変更や強制的な展開でプラットフォームの不一致を解決しようとしないでください。

インストール前に、古いプロキシクライアントやネットワークを取り込む可能性のあるツールを終了します。古いアプリで自動起動や常駐サービスが有効な場合、ウィンドウを閉じただけではバックグラウンドプロセスが残ることがあります。通知領域のメニューから完全に終了してください。移行後の確認に備えて、古い環境の混合ポートとサブスクリプションの提供元を記録します。この時点では古い設定を削除せず、新しいクライアントで接続と検証が完了してから整理してください。

プラットフォームに合わせて初回起動する

Windowsではインストーラーを実行した後、まず通常のアプリとして起動します。サービスのインストールやTUNの権限が必要な場合に限り、クライアントの案内に従って権限を許可してください。アプリ全体を常に管理者として実行する方法を、一般的な解決策にしないでください。macOSではアプリケーションフォルダーに入れ、システムが認識する方法で起動します。セキュリティの警告が表示されたら、提供元と警告の内容を確認し、出所不明のターミナルコマンドをまねてシステム保護を一括で無効にしないでください。

Linuxではディストリビューションに合ったパッケージ管理方法でインストールし、依存関係のエラーが解消しているか確認します。GUIが起動したら、コアの状態とログ画面を確認できるかチェックしてください。デスクトップ環境のシステムプロキシ設定は環境によって動作が異なります。プロキシ設定が自動で反映されなくても、コアが動作していないとは限りません。アプリ、コア、システム連携のどの段階で起きた問題かを切り分けてから対処します。

正常起動時の基準を作る

初回起動後、設定画面で混合ポート、待ち受けアドレス、LAN接続の許可状態を確認します。このPCだけで使う場合は、通常、ローカルからの接続だけを許可します。このページでは例として127.0.0.1:7897を使います。実際に別のポートが表示されている場合は、後のアプリ設定やコマンドでも該当する番号に置き換えてください。設定を保存したら、待ち受けの失敗やポートの競合が報告されていないか確認します。

# Windows PowerShell：サンプルポートの待ち受け状態を確認
Get-NetTCPConnection -LocalPort 7897 -State Listen

# macOS / 一般的なLinux環境：サンプルポートを確認
lsof -nP -iTCP:7897 -sTCP:LISTEN

これらはOSに応じて使う確認用コマンドであり、すべてのプラットフォームで実行する必要はありません。待ち受けが見つからない場合は、コアが起動しているか、設定を読み込んでいるか、実際のポート番号が一致しているかを確認します。プロセスが見つかった場合は、ポートが存在するだけで正常と判断せず、プロセス名も確認してください。コマンドが見つからない場合は、OS標準のリソースモニターやクライアントのログで確認できます。この確認のためだけにツールを追加でインストールする必要はありません。

インストールの段階で、TUN、自動接続、自動更新のすべてを有効にする必要はありません。まずクライアントが起動すること、ログを確認できること、ポートが競合していないことを確かめてから、サブスクリプションの章に進みます。問題が起きたら、エラーの原文と発生手順を記録してください。「開かない」とだけ記すより原因を調べやすくなります。ここまでで目指すのは、未検証の機能を重ねた環境ではなく、最小限で再現可能なローカル環境です。

04 サブスクリプションの追加：URLから実際の稼働設定まで

互換性のある設定を入手してから更新する

サブスクリプションは更新可能な設定の配布元です。一般的にはリモートURLを使いますが、ローカルのYAMLファイルの場合もあります。まずサービス提供元に、どのクライアントまたはコアに対応しているかを確認します。次にクライアントのサブスクリプション、設定、Profiles画面を開き、リモート設定の追加を選択してください。見分けやすい名前を付け、URLを省略せずに貼り付けて保存し、更新を実行します。URL末尾のパラメーターを落とさないようにし、Webページに表示されたタイトルをサブスクリプションURLと取り違えないでください。

更新が成功した後は、通常、その設定を選択して有効にする必要があります。ダウンロードと設定の適用は別の操作です。サブスクリプション一覧の更新時刻が変わっても、稼働中のコアで設定が切り替わったとは限りません。現在の設定名、コアのログ、プロキシグループの表示を確認してください。古いグループ名が残っている場合は、設定が有効になっているか確認します。複数のサブスクリプションを管理できるクライアントもありますが、稼働設定への統合方法はそのクライアント独自の仕組みに従ってください。

サブスクリプション、上書き設定、実行結果を区別する

サブスクリプションの原本はサービス提供元から配布されたデータ、上書き設定は読み込み時にクライアントが追加・変更する内容、実行設定は最終的にコアが受け取る結果です。ダウンロード済みのキャッシュを手動で編集すると、次回の更新で上書きされる場合があります。長期的に維持したいルール、ポート、DNS設定は、クライアントの永続的な上書き機能を使い、サブスクリプションの前後どちらで適用されるのか、または項目単位でマージされるのかを確認してください。

すべてのリモート設定に完全なルールが含まれているとは限りません。ノードだけが提供され、クライアントのテンプレートでプロキシグループやルールを補うものもあれば、DNS、ルールプロバイダー、ポリシー一式を含むものもあります。インポート後にまず構成を確認し、チュートリアルに合わせるために既存の設定を削除しないでください。特にプロキシグループ名はルールの適用先から参照されます。グループ名を変えてルールを更新しないと、コアが設定を読み込めなかったり、一部のポリシーが機能しなくなったりします。

# 構成例：項目を理解するための例であり、プロキシサービスの設定ではありません
mixed-port: 7897
allow-lan: false
mode: rule

proxies: []

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

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

上のYAMLは設定項目の関係を示す例で、リモートノードがないため、すべてのリクエストが最終的に直接接続されます。項目の確認や読み方の学習には使えますが、プロキシサービスの動作確認には使えません。実際のサブスクリプションに必要なサーバーアドレス、パスワード、プロトコル、証明書の設定は、利用権限のある提供元から入手してください。説明用の断片を組み合わせて作らないでください。YAMLではスペースでインデントし、同じ階層の幅を統一します。タブ、全角コロン、対応しない引用符があると解析エラーになる場合があります。

更新エラーは内容に応じて対処する

ネットワークのタイムアウトが表示されたら、まず現在のネットワークからサブスクリプションの配布元にアクセスできるか確認し、既存のプロキシを経由した更新が必要かも調べます。認証エラーの場合は、URLの有効期限とサービスの利用状態を確認してください。設定ではなくWebページが返る場合、ログイン画面、エラーページ、リダイレクト先を開いている可能性があります。正しいURLをサービス提供元に確認しましょう。ダウンロードには成功しても解析に失敗する場合は、ノードを何度も変えるのではなく、項目の互換性やエラー行を確認します。

ローカルからのインポートは移行やオフラインバックアップに便利ですが、通常はサービス提供元の更新が自動で反映されません。リモートサブスクリプションは有効期間と更新頻度に合わせて使い、何度も手動で更新するのは避けてください。更新前に復元可能な設定を保存し、更新後はプロキシグループ、ルール、接続が引き続き正常か確認します。ログやスクリーンショットを共有するときは、サブスクリプションURL、サーバーの認証情報、個人のアクセス履歴を隠してください。名前だけを隠しても十分とは限りません。

05 プロキシモード：入口の設定とルーティングの判断を分ける

ルール、グローバル、直接接続の違い

プロキシモードは、コアに届いたリクエストの出口を選択する設定です。すべてのアプリがリクエストをコアに渡すことを保証するものではありません。ルールモードでは設定内のルールを順番に判定し、日常的な通信の振り分けに使います。グローバルモードでは、コアに届いたリクエストをグローバルポリシーに渡すため、原因を一時的に切り分けるのに便利です。直接接続モードでは、コアに届いたリクエストを宛先へ直接接続します。グローバルモードにしても、もともとシステムプロキシを使わないアプリの通信が自動で取り込まれるわけではありません。

グローバルモードに切り替えても、特定のノードが自動的に選ばれるわけではありません。グローバルポリシーが現在どのグループや出口を指しているか確認してください。ルールモードでは、各ルールが参照するプロキシグループの選択状態を確認します。グループにDIRECTが含まれている場合、それを選ぶと直接接続になります。画面にルールモードと表示されていても同じです。リクエストの実際の動作は、ホーム画面のモード名だけでなく、接続経路と適用ルールで判断してください。

設定解決する問題単独では保証できないこと
システムプロキシシステム設定に従うアプリにプロキシの入口を提供するすべてのアプリやUDP通信を取り込むこと
ルールモードドメインやアドレスなどの条件に応じてポリシーを選ぶルールに該当しないアプリの通信を自動でコアに渡すこと
グローバルモードコアに届いたリクエストをグローバルポリシーに渡す選択したリモートサービスが必ず利用できること
TUNモード仮想ネットワークインターフェースを介して、より広範な通信を取り込むすべてのルールやDNS設定が正しいこと

動作を説明できる初回接続を確認する

まずルールモードを有効にし、プロキシグループから利用権限のある出口を選んでから、システムプロキシを有効にします。確認したいWebページを開きながら、接続画面を確認してください。新しい接続が表示されない場合は、ブラウザー独自のプロキシ設定、設定を上書きする拡張機能、リクエストがキャッシュされていないかを確認します。ページを再読み込みして新しいリクエストを発生させてもかまいませんが、ブラウザーの既存接続を切り替え後の結果と混同しないでください。

接続が表示されたら詳細を開き、対象ドメイン、適用ルール、最終的なポリシーを確認します。Webページが開くことは確認項目の一つにすぎず、直接接続が成功した可能性も、プロキシが機能した可能性もあります。設定上で直接接続に指定されたテスト用ドメインと、プロキシに指定された対象など、想定する経路が明確な宛先を使って比較してください。単一のWebページの成否からネットワーク全体の状態を判断したり、外部ページに表示された地域だけを唯一の根拠にしたりしないでください。

システムプロキシに従わないアプリには入口を個別に設定する

コマンドラインツールの中には、デスクトップのシステムプロキシ設定を自動で読み込まないものがあります。その場合は、ツール側でプロキシを設定するか、コマンド単位でローカルの接続先を指定します。以下は混合ポートを使う例です。ポート番号が異なる場合は、該当する数字に置き換えてください。これはHTTPプロキシの入口を確認するためのもので、UDPやTUNも正常だと判断する根拠にはなりません。結果は接続先のサイト、現在のネットワーク、選択したポリシーにも左右されます。

curl --proxy http://127.0.0.1:7897 --head https://example.com

コマンドでローカルポートに接続できないと表示されたら、インストールの章に戻って待ち受け状態を確認します。プロキシには接続できてもリモートのハンドシェイクに失敗する場合は、出口、認証、ネットワーク制限を確認してください。一時的にグローバルモードでテストする場合は、切り替え前のモードとプロキシグループの選択を記録し、完了後にルールモードへ戻します。モードを切り替えても通常は新しい接続にしか反映されず、既存の長時間接続は以前の経路を使い続ける場合があります。必要に応じて該当する接続を閉じ、リクエストを再実行して確認してください。

この段階では、「リクエストが入ったか」「どのルールに従ったか」「出口が動作するか」の順に確認する習慣をつけます。入口に通信が届いていないなら、ルールを調整しても解決しません。ルールが正しく適用されてもハンドシェイクに失敗するなら、ルールの変更を重ねても原因は特定しにくくなります。手順を短く確認したい場合は入門ガイドに戻り、基本の流れを一つずつ再現してください。

06 ルール振り分け：最初の一致から永続的な上書きまで

上から順に判定し、最初に一致した時点で終了

ルール一覧は、すべての条件を評価してから結果を総合する仕組みではありません。通常、コアは上から順にルールを確認し、最初に一致したルールでポリシーを決定します。後続のルールは、そのリクエストの判定に使われません。範囲の広いルールよりも、優先して適用したい具体的な例外を前に配置してください。MATCHは、通常、末尾に置くフォールバックルールです。前の方に置くと、後続のルールで該当するリクエストを処理できなくなります。

DOMAINは完全一致するドメイン、DOMAIN-SUFFIXは指定したドメインとそのサブドメイン、DOMAIN-KEYWORDはドメインに含まれるキーワードに一致します。適用範囲が異なるため、文字数を減らす目的で安易に置き換えないでください。特にキーワードルールは、想定以上に広い範囲に適用されることがあります。特定のホストだけを対象にするなら、完全一致のドメインルールの方が確認や管理をしやすいでしょう。

# 既存の設定にPROXYという名前のプロキシグループがある場合
rules:
  - DOMAIN,docs.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

この順序では、まず完全一致のドメインルールでdocs.example.comを直接接続にし、ほかのサフィックスに一致するドメインはプロキシグループに渡します。プライベートアドレスのルールは指定したアドレス範囲を処理します。no-resolveは、このアドレスルールのためにドメイン名の名前解決を新たに行わない指定です。リクエストに宛先IPがすでにある場合は一致できます。設定全体のDNSを無効にするものではなく、すべてのアドレスルールに機械的に付けるものでもありません。

アドレスルールとルールセットを使う場面

IP-CIDRはIPv4のアドレス範囲に使い、IPv6のアドレス範囲には通常IP-CIDR6を使います。GEOIPはアドレスデータベースをもとに判定するもので、IPの所在地は、企業の所在地やアクセス元の地域と必ずしも一致しません。データベースが更新されることもあります。ドメインの名前解決が必要か、既存のアドレスが使われるかによって動作が異なるため、アドレスルールをドメインルールより前に置く場合は、DNSの挙動と適用ログを特に確認してください。

RULE-SETは、設定内で定義済みのルールプロバイダーを参照し、ルール群を個別に管理するためのものです。ルール一覧にリモートURLを書くだけで使える略記ではありません。プロバイダー名、取得元、形式、動作タイプを正しく対応させる必要があります。ドメインだけのテキストリストと一般的なルールリストでは記述形式が異なります。形式を取り違えると、読み込みに失敗したり、ルールが機能しなかったりします。初めて使う場合は、まずローカルルールを理解してから外部のルールセットを追加しましょう。

ダウンロードしたキャッシュだけでなく、実行結果も変更する

ルールを追加する前に、クライアントの機能が前置ルール、後置ルール、全体上書きのどれに対応するか確認してください。独自ルールを既存のMATCHより後に追加すると、構文が正しくても適用されない場合があります。保存後は編集画面のテキストだけでなく、実際に読み込まれたルールを確認します。プロキシグループ名にスペース、句読点、英語以外の文字が含まれている場合は、見た目の印象で省略せず、そのまま参照してください。適用先の名前が存在しない場合は、まず参照関係を修正します。

一度に追加するルールは、動作を確認しやすい1件にします。設定を再読み込みし、新しい接続を発生させて、その接続の詳細でルールが適用されたか確認してください。古い接続が残っている場合は、該当する接続を閉じるか、リクエストを送るアプリを再起動します。それでも一致しないときは、確認できているのがドメインかIPか、先行する範囲の広いルールがないか、アプリがコアを経由しているか、上書きが実行設定に反映されているかを調べます。設定を一括で追加して判断できなくなるのではなく、順を追って原因を特定できます。

07 TUNモード：通信の取り込み範囲とDNSの連携

TUNが必要になるケース

ブラウザーがルールどおり接続できる一方で、特定のアプリがシステムプロキシに従わない場合は、まずアプリがHTTPプロキシまたはSOCKSプロキシの個別設定に対応しているか確認します。適切な設定箇所がなく、より多くの通信を取り込む必要がある場合にTUNを検討してください。TUNは仮想ネットワークインターフェースとルーティングを使って通信をコアに渡します。システムプロキシより多くのシステム機能に関わるため、基本の接続が正常なことを確認してから有効にしてください。

有効にする前に、システムプロキシの状態、現在のDNS、ほかのVPNツールの状態を記録し、終了後に元へ戻す方法を確認します。デフォルトルートを奪い合う可能性のあるツールを終了し、クライアントの案内に従ってサービスをインストールするか権限を許可してください。複数の仮想ネットワークインターフェースを同時に有効にして、どれが問題か分からなくなる状態は避けましょう。モバイル端末のVPNインターフェースとデスクトップのTUNは設定箇所が異なります。デスクトップ向けのYAMLをそのまま使って、スマートフォンの設定全体を置き換えないでください。

インターフェース、ルーティング、名前解決をまとめて理解する

TUNで通信を取り込めても、DNSの経路が自動的に正しくなるわけではありません。アプリがシステムDNS、暗号化DNS、独自のリゾルバーからアドレスを取得することがあり、コアが一部のDNSリクエストを取り込む場合もあります。ドメイン情報が想定した経路に届かないと、ドメインルールの動作はシステムプロキシモードと異なることがあります。「IPアドレスを直接入力すれば使えるが、ドメイン名では使えない」という場合は、すぐに出口をすべて切り替えたりルールを変更したりせず、まずDNSを確認してください。

# Mihomoの項目例：設定が必要かどうかはクライアントのTUN管理方法に従ってください
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

この設定例は、自動ルーティング、出口インターフェースの検出、DNSの取り込みに関する項目を示すもので、単独で動作する完全な設定ではありません。GUIクライアントがこれらの項目を自動生成する場合は、重複する上書きを避け、設定画面から管理してください。any:53は、あらゆる種類の暗号化DNSを自動で処理するという意味ではありません。アプリがHTTPSで送信する名前解決リクエストは、従来の53番ポートへの問い合わせと単純に同一視できません。実際の動作はDNS設定とルーティング範囲にも左右されます。

Fake-IPと実際のアドレス解決を理解する

Fake-IPは、ドメインに内部用のマッピングアドレスを割り当て、コアがそのアドレスをドメインと対応付ける方式です。接続先のサーバーを実際にそのアドレスへ移すものではありません。使用中にシステムツールに表示されるアドレスが、Webサイトの実際のグローバルアドレスと異なることがあります。そのため、名前解決の結果を一度見ただけで、誤った書き換えが起きているとは判断できません。実際のアドレスや特殊な検出方式に依存するアプリでは、特定のドメインを除外する必要がある場合があります。除外範囲をできるだけ絞り、DNS全体を無効にすることは避けてください。

DNSの動作方式を切り替えても、OSやアプリのキャッシュに以前の結果が残っている場合があります。関連する接続を終了し、名前解決をやり直してからログを確認してください。必要に応じてOSのドキュメントに従ってDNSキャッシュを消去します。LANプリンター、共有フォルダー、デバイス検出に問題が起きた場合は、プライベートネットワークのルーティング、LAN内の名前解決、除外ルールを確認してください。LANの問題をすべてノード障害と決めつけたり、名前解決の問題を直すために待ち受け範囲全体を開放したりしないでください。

検証では、ブラウザー、対象アプリ、LAN内のリソースを個別にテストし、接続画面でコアに通信が届いているか確認します。特定のアプリだけが失敗する場合は、そのアプリが使うプロトコルとプロキシ対応を調べます。すべてのアプリで失敗する場合は、通信を取り込む経路を優先して確認してください。クライアントを終了した後に、システムのネットワークが正常に戻ることも確認します。こうした比較を完了してから自動起動や自動取り込みを有効にしましょう。Webページが一時的に開いたことだけで、設定が安定したと判断しないでください。

08 日常のメンテナンス：更新、バックアップ、段階的なトラブルシューティング

3種類の更新を分けて行う

クライアント、コア、サブスクリプションの更新では、それぞれ異なる内容が変わります。クライアントの更新は画面やシステム連携に影響します。コアの更新はプロトコル、ルール、DNSの動作に影響する場合があります。サブスクリプションの更新では、主にサービス提供元が配布するノードやルールが変わります。3つを同時に更新してから検証を始めると、変化の原因を特定しにくくなります。必要なものを一つずつ更新し、操作前後のモード、設定名、重要なスイッチを記録してください。

更新前に復元可能な設定を保存し、現在の使い方に関係する変更内容を確認します。サブスクリプションに含まれる項目が、より新しいコアを必要とする場合があります。また、古いクライアントでは新しいコアの機能を正しく管理できないことがあります。互換性エラーが発生したら、まずクライアントとコアの組み合わせを確認してから、以前のバージョンに戻すか検討してください。出所不明のファイルを複数の場所から入手して混在させないでください。バックアップの復元時も、内部データをすべて上書きするのではなく、クライアントが認識する設定形式か確認します。

バックアップに含めるもの

役立つバックアップには、少なくともサブスクリプションの提供元、永続的な上書き設定、独自ルール、プロキシグループの選択、ポート、TUN、DNSの重要な設定を含めます。サブスクリプションのキャッシュは一時的な復元材料にはなりますが、提供元や独自の設定内容の代わりにはなりません。スイッチの状態を覚えるにはスクリーンショットが便利ですが、長いルールの復元には向いていません。設定をテキストでエクスポートし、簡単な操作メモを添えておくと、アプリのフォルダーだけを保存するより移行しやすくなります。

バックアップにはサービスにアクセスできる認証情報が含まれる場合があるため、アクセス制限のある場所に保存し、デバイス間で送る際は公開しないようにしてください。PCとスマートフォンで同じサブスクリプションURLを使えても、ポート、インターフェース、キャッシュの保存先、TUNの設定は共通とは限りません。複数のデバイスを同期する場合は、まずサービスとルールの意図をそろえ、システム固有の設定はデバイスごとに調整します。具体的な方法はPCとスマートフォンでサブスクリプションを共有する方法をご覧ください。

発生している現象最初に調べる階層次に確認する情報
アプリのリクエストが接続画面に表示されないシステムプロキシ、アプリ側のプロキシ、TUNの入口新しいリクエストがコアに届いているか
接続は表示されるが出口が違うルールの順序とプロキシグループの選択適用ルールと最終的な接続経路
ドメイン名を解決できないDNSの提供元、到達性、通信の取り込み方法名前解決のエラーと対象ドメイン
プロキシのハンドシェイクに失敗するリモート接続、認証、プロトコルの互換性エラーの原文と発生時刻

一度に一つの設定だけ変更して原因を調べる

まずプロキシを使わない状態で基本のネットワークが使えるか確認し、次にコアの起動とポートの待ち受けを確かめます。その後、対象リクエストに適用されたルールを見て、最後にリモート接続を確認します。各段階の結論を記録してください。一時的なグローバルモードへの切り替えはルールの影響を比較するためのもので、日常的な問題に対する万能策ではありません。一時的にTUNを無効にするのは通信の取り込みに原因があるかを調べるためで、TUNを恒久的に停止すべきという意味ではありません。調査後は元の設定に戻し、再度確認します。

ログレベルは、現在の調査に必要な範囲に設定します。詳しい情報が必要な場合は一時的にレベルを上げて一度再現し、該当するログを保存してから通常の設定に戻してください。アクセス記録が長期間大量に残るのを避けられます。他の人に相談するときは、OS、クライアント、現在のモード、通信の取り込み方法、エラーの全容を伝え、必要なログは機密情報を隠して提示してください。サブスクリプション全体をそのままアップロードしたり、関係のない閲覧履歴をまとめて共有したりしないでください。

遅延テストは状況を把握するための補助であり、実際の使用感を保証するものではありません。テスト先、ハンドシェイクの手順、対象サイト、必要な帯域によって結果は変わります。テスト結果が正常でもアプリの動作が遅い場合は、テストを何度も繰り返すのではなく、そのアプリが接続する宛先を確認してください。テストの意味についてはurl-testの遅延と実際の使用感が異なる理由を参考にし、単一の数値を出口全体の品質とみなさないようにしましょう。

09 応用設定：プロキシグループ、ルールセット、復元可能な設定

自動化を追加する前にポリシーの構成を整える

基本の接続が安定した後に目指すのは、設定をできるだけ長くすることではなく、選択、更新、復元を分かりやすくすることです。まず日常利用、特定のサービス、直接接続する例外のポリシーを明確に分けてから、自動選択を検討します。名前が分かりやすく階層の少ないプロキシグループは、相互に参照する複雑な構成より説明しやすくなります。グループを作る前に、解決する問題と、不具合時に戻す出口を決めておきましょう。

selectプロキシグループはユーザーが手動で選択するため、出口を固定したい場面に適しています。url-testは指定先へのテスト結果に応じて候補を選び、fallbackは候補の順序と利用可能な状態に基づいて切り替えます。グループごとに選択方法が異なるため、すべてを「最速を自動で選ぶ機能」とみなすことはできません。テストリクエストにもネットワーク負荷がかかります。画面表示を頻繁に変える必要はないので、実際の使い方に合わせて確認間隔を設定してください。

# 設定例：proxiesに同名のノードをあらかじめ定義してください
proxy-groups:
  - name: 日常利用の選択肢
    type: select
    proxies:
      - 自動選択
      - DIRECT

  - name: 自動選択
    type: url-test
    proxies:
      - 出口A
      - 出口B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

ここにある「出口A」と「出口B」は参照名の例です。使用する前に、既存の設定に実在するノード名へ置き換えてください。テスト先には、現在の環境からアクセスでき、継続的な確認に適したものを選びます。intervalは確認間隔、toleranceは小さな変動による頻繁な切り替えを抑えるための設定です。これらのパラメーターが速度を保証するわけではありません。接続状態の維持が必要なアプリでは、出口の切り替えがログインや長時間接続に与える影響も考慮してください。

ルールセットを独立した依存関係として管理する

ルールプロバイダーを追加するときは、提供元、動作タイプ、更新方法、参照箇所を記録します。リモートルールが更新されると実際の通信振り分けも変わるため、設定ファイルを変更していなくても動作が常に同じとは限りません。重要な独自例外は前置ルールとして維持し、ルールセットが引き続き更新できることを定期的に確認します。ダウンロードに失敗した場合は、プロキシグループが正常に見えるだけで外部依存もすべて読み込まれたと判断せず、プロバイダーの状態を確認してください。

DNSやスニッフィング機能を追加するときも、解決したい問題を明確にしてください。スニッフィングは一部のプロトコル通信からドメイン名などを取得する機能ですが、プロトコルや暗号化方式による制限があり、すべての接続からドメイン名を復元できるわけではありません。現在のルールで問題がなければ、機能一覧を埋めるためにすべてを有効にする必要はありません。機能を一つ追加するごとに、対象となるリクエスト、制限、無効にしたときに元の動作へ戻す方法を記録します。

再現可能な設定変更の手順を整える

設定の変更は、現在動作している設定を複製し、小さな変更を一つ加え、構文と実行結果を確認し、結論を記録してから保存する4段階で進めることをおすすめします。Mihomoコアを単独で使い、ターミナルから実行ファイルを呼び出せる場合は、以下のコマンドで設定を確認できます。GUIクライアントの場合は、クライアント内の設定チェック機能も利用できます。構文チェックに通ることは設定が読み込める証拠にすぎません。ルールと出口の動作は実際の接続で確認してください。

mihomo -t -f config.yaml

応用練習は、ドメインに直接接続の例外を追加し、サービスごとのポリシーを作り、ルールセットが更新されるか確認し、復元可能なバックアップを作成する順に進めるとよいでしょう。各作業の後に、実行中のルールと接続経路が想定どおりか確認します。出口を選ぶときは、遅延、倍率、地域、プロトコルの比較方法も参考にできますが、単発のテストを長期的な実測の代わりにしないでください。