Clash入門から応用までインストール・サブスクリプション・ルール振り分け

ステップ 01 / 接続の仕組みを知る

基本概念：クライアント・コア・設定

ホーム画面のスイッチから確認

Clash系クライアントを開くと、通常は設定、プロキシ、ログ、サービスの起動スイッチなどが表示されます。まずは複数の画面を同時に変更しないでください。クライアントはボタンや通知、システム権限を提供するアプリです。コアはルールを読み込み、接続を確立して通信を転送するプログラムです。mihomoはClashエコシステムで広く使われているコアであり、特定の画面アプリを指すものではありません。同じ設定でも、クライアントによって異なるコアや起動オプションで実行される場合があります。画面が似ていても、すべての機能が同じとは限りません。

設定ファイルはネットワーク処理の指示書で、一般にYAML形式が使われます。YAMLはインデントで階層を表すため、空白の位置も内容の一部です。設定にはプロキシノード、プロキシグループ、名前解決方法、振り分けルールなどを記述できます。サブスクリプションは、通常リンクを通じてこれらの情報を取得する仕組みです。リンクから取得できるのは完全な設定ファイルの場合も、ノード一覧だけの場合もあります。そのまま読み込めるかどうかは、リンク名にClashが含まれるかではなく、クライアントが形式を認識できるかで決まります。

ノード・プロキシグループ・ルールを区別する

ノードは接続先となるプロキシエンドポイントで、サーバーアドレス、ポート、プロトコル、必要な認証情報を含みます。プロキシグループは複数の出口から接続先を選ぶもので、手動選択、テスト結果に基づく選択、障害時の切り替えなどがあります。ルールが決めるのは、個々の通信をどの出口へ送るかです。ルールが通信をプロキシグループに渡し、グループがノードを選びます。ルールがDIRECTを指定した場合は、リモートのプロキシノードを経由しません。ノードを切り替えても、ルールですでにDIRECTと判定された通信の経路は変わらないことがあります。

通信の流れは、アプリがリクエストを送信し、システムがクライアントに通信を渡し、コアが接続先を特定して、ルールに基づいて出口を選び、接続先またはプロキシサーバーへ接続する、という順序で整理できます。その途中でドメイン名をアドレスに変換する名前解決も行われます。どの段階に問題があっても、見た目にはウェブページが開かないだけに見えることがあります。サブスクリプションを何度も切り替えるより、まずリクエストがクライアントに届いているか、どのルールに一致したか、出口への接続結果はどうかを順番に確認するほうが原因を見つけやすくなります。

端末内のVPNインターフェースとリモートサービスは別

AndroidにVPNアイコンが表示されるのは、システムがアプリによる対象通信の処理を許可していることを示します。VpnServiceはAndroidが提供する端末内のVPNインターフェースで、クライアントはこれを使って通信を取得・処理します。このアイコンだけでは、サブスクリプションの有効性、ノードの利用可否、接続先サイトへのアクセス可否までは確認できません。プロキシサービスの起動成功とリモート接続の成功は別々に確認する必要があります。後述の検証手順では、それぞれを個別に確認します。

混同しやすい概念にシステムプロキシもあります。デスクトップのシステムプロキシは通常、アプリにプロキシアドレスを提示し、それを使うかどうかはアプリ側に委ねます。一方、仮想ネットワークインターフェースは、より低いネットワーク層から通信を受け取ります。Androidクライアントには、VPNに含めるアプリを指定する機能がある場合もあります。ブラウザーでは接続できるのに別のアプリでは失敗する場合は、まず通信の対象範囲とアプリ独自のネットワーク設定を確認してください。ブラウザーの結果だけで端末全体の通信経路を判断することはできません。

このガイドでは、必要な機能を備えたmihomo系クライアントを主な対象として説明します。例に含まれる項目が使えるかどうかは、実際のコアとクライアントの設定処理方法によって異なります。GUIクライアントは起動時に追加項目を生成したり、設定ファイル内の同名項目を上書きしたりすることがあります。そのため、以降で説明する設定の確認には、保存された元ファイルだけでなく、アプリが実際に読み込んだ実行時設定も含まれます。この違いを把握すれば、ファイルを編集しても動作が変わらない理由を説明できます。

ステップ 02 / 端末と必要な機能を確認

クライアントの選び方：プラットフォーム・アーキテクチャ・コアの機能

まずOSで候補を絞り、次に機能を比較

クライアントのダウンロードページを開き、まず端末のOSを選んでからインストール方法を確認してください。AndroidではClash Plusを第一候補とし、設定との互換性に応じてClash Meta for Android、FlClash、Surfboardも選べます。第一候補であることは、ほかのクライアントの設定をそのまま使えるという意味ではありません。特にSurfboardはClash YAMLとは異なる設定体系を採用しているため、拡張子を変えるだけでは変換できません。すでにサービス提供元の設定がある場合は、対応クライアントとサブスクリプション形式を先に確認してください。

クライアントを選ぶ際は、端末にインストールできるか、サブスクリプションを認識できるか、必要な機能があるかの3点を確認します。サブスクリプションの追加とノード切り替えだけが目的なら、使う予定のない設定項目のためにすべての設定を移行する必要はありません。ルールの上書き、アプリごとのプロキシ設定、特定のDNS動作が必要になったら、クライアントが対応する画面を備えているか確認しましょう。画面にスイッチがあっても、同じ名前の機能が異なる仕組みで実装されている場合があります。スクリーンショットだけで互換性を判断しないでください。

端末に合ったアーキテクチャのインストーラーを選ぶ

Androidのインストールファイル名に含まれるarm64、arm、universalは、それぞれ異なるプロセッサや実行環境向けのビルドを表します。比較的新しいスマートフォンの多くは64ビットARM環境ですが、購入年だけで判断できません。端末によってはシステムのユーザー空間に別の制限があるため、システム情報やダウンロードページの説明を優先してください。汎用パッケージは容量が大きくなることがあり、OSの最低要件、署名の不一致、端末ポリシーの制限を回避できるわけではありません。

パソコンでもプロセッサの種類を確認する必要があります。macOSはApple SiliconとIntelに合ったビルドを選び、Linuxはディストリビューションに合ったパッケージ形式を選択してください。コアの圧縮ファイルを通常のGUIアプリとしてインストールしないでください。ダウンロードページのmihomoコア欄は、サーバーやルーターでの利用、またはコマンドラインでの導入を明確に必要とするユーザー向けです。スマートフォンでサブスクリプションを読み込むための完全な画面は通常備えておらず、システムの通信を取り込む設定も自動では完了しません。

移行前に元へ戻せる状態を残す

Clash for WindowsとClashX Metaはすでにメンテナンスが終了しています。ダウンロードページには既存環境向けのアーカイブ入口を残していますが、新規導入ではメンテナンスが続いている代替クライアントを優先してください。移行時はノード一覧だけでなく、現在選択中のプロキシグループ、アプリごとの対象範囲、ローカルルール、起動設定も記録します。新しいクライアントでサブスクリプションを読み込めても、以前のアプリのシステム権限やバッテリー設定は引き継がれない場合があるため、別途確認が必要です。

同じ端末に複数のクライアントをインストールして比較することはできますが、実際にテストするときは通信を取り込むサービスを1つだけ起動してください。2つのアプリがシステムプロキシやVPNインターフェースを取り合うと、結果を判断しにくくなります。まず既存のクライアントを停止し、同じ提供元の設定を読み込んで、同じネットワークと接続先でテストします。ページ表示の一度きりの速さではなく、特定のルールが一致するかなど、動作の違いを記録して比較してください。

スマートフォンとパソコンで同じサブスクリプションを使う場合は、共通のノードとルールを維持し、端末固有の設定はそれぞれに残します。Androidのアプリパッケージ名による振り分けは、デスクトップのプロセスルールの代わりにはなりません。デスクトップの待ち受けポートも、必ずしもスマートフォンにコピーする必要はありません。サポート終了済みクライアントからの移行については、mihomo系クライアントへの移行先も参照してください。この章を終える頃には、現在のアプリを選んだ理由と、使用予定の設定形式に対応していることを説明できるはずです。

ステップ 03 / 端末へのインストールと権限設定

Androidへのインストール・VPN権限・バックグラウンド設定

インストール後の状態から確認

Androidのダウンロード欄から端末に合ったインストールファイルを選びます。ダウンロード後、ブラウザーのダウンロード一覧またはシステムのファイル管理アプリからファイルを開いてください。この提供元からのアプリのインストールが許可されていないと表示された場合は、該当する権限設定画面を開き、今回使うブラウザーまたはファイル管理アプリからのインストールを許可して、戻って続行します。この権限はインストールファイルを開くアプリに対するもので、ネットワーク全体の許可ではありません。インストール後は、端末の管理方針に応じて権限を取り消してもかまいません。

「アプリをインストールできません」と表示された場合は、まずシステムが示す具体的な原因を確認してください。空き容量が足りなければストレージを整理します。アーキテクチャやOSが非対応なら、要件に合ったビルドを選びます。同名アプリの署名が異なる場合は、すぐに古いアプリを削除しないでください。設定やローカル項目をエクスポートし、復元できることを確かめてから、インストール元を変更するか判断します。アンインストールすると通常はアプリ専用データも削除され、サブスクリプションURL、ルールの上書き、プロキシグループの選択などがシステムバックアップから完全に戻せるとは限りません。

初回起動時は必要な権限だけを設定

クライアントを開いたら、まずアプリ名と設定画面を確認してください。有効な設定を読み込んでからサービスを起動します。初回接続時には通常、AndroidのVPN接続リクエストが表示されます。操作中のクライアントからの要求であることを確認して許可してください。この権限はアプリが端末内にネットワークインターフェースを作成することを認めるもので、リモートのプロキシサービスを購入・契約するものではありません。通知が表示されず起動に失敗した場合は、別のVPN、仕事用プロファイルのポリシー、端末管理の制限によって接続作成が妨げられていないか確認します。

通常、同じユーザーまたはプロファイル内で同時に動かせる一般的なVPNサービスは1つです。別のプロキシ、企業向け接続、ファイアウォールアプリが動作中の場合、新しい接続が既存の接続を置き換えることも、ポリシーに阻止されることもあります。まず必要なサービスを決め、競合するアプリを停止してから再試行してください。この時点では通信がリモートノードに到達していない可能性があるため、起動失敗をノードのタイムアウトと決めつけないでください。まず端末側の権限を確認し、その後ログの接続記録を確認します。

画面ロック後に切断される場合は、バッテリーとバックグラウンド制限を確認

アプリアイコンを長押ししてアプリ情報を開き、バッテリーまたはバックグラウンドの電力管理を確認します。継続して動作させる場合は、バックグラウンド動作を許可するか、制限なしに設定します。項目名はOSによって異なります。メーカーによっては自動起動、バックグラウンド実行の保護、最近使ったアプリのロックが別々に用意されています。それぞれ役割が異なるため、1つを有効にしただけで設定完了とは限りません。変更後は画面を点灯した状態で動作を確認し、次にしばらく画面をロックして、通知とサービス状態が維持されるか確認してください。

通知の権限とVPNの権限も別のものです。通知を許可するとサービスの状態を確認したり接続をすばやく停止したりできますが、通知が非表示でもサービスが停止したとは限りません。反対に、通知が表示され続けていてもリモート接続が正常とは限りません。バックグラウンドの問題を調べる際は、画面ロックの前後でサービスのスイッチ、システムのVPN状態、ログの時刻が連続しているかを記録します。システムがアプリを終了しているなら、再度開いたときにサービスが再作成されることがあります。サービスが動いているのにアクセスできない場合は、ネットワークの切り替えやノード接続を調べてください。

インストール後の最初のテストには、通常の家庭用ネットワークを使い、ルーター側のプロキシや複雑な職場ネットワークのポリシーを同時に有効にしないことをおすすめします。まず通常どおり直接接続できるサイトを開き、次にプロキシが必要な接続先にアクセスして、それぞれの結果を記録します。モバイル回線とWi-Fiの両方を試す場合は、一度に切り替えるのはネットワークだけにし、ノードや設定を同時に変えないでください。どの段階で失敗したかが明確になり、インストールの問題とネットワーク側の制限を区別しやすくなります。

権限を設定したら、VpnServiceの権限とバッテリー最適化の例外設定を参考に、メーカー固有の項目も確認してください。この章の完了条件は、VPNアイコンが表示されるだけではありません。設定が読み込まれ、サービスが起動し、基本的なアクセスができ、画面ロック後すぐにシステムから終了されないことを確認します。その後に自動起動を有効にすると、端末再起動後に原因を判断しにくい問題が連鎖するのを防ぎやすくなります。

ステップ 04 / 更新できる設定元を用意

サブスクリプションの追加・設定確認・更新時の注意点

まず取得した内容の種類を確認

設定画面を開き、新規追加またはURLからのインポートを選んで、サービス提供元から受け取ったサブスクリプションURLを貼り付けます。保存時は取得元が分かるローカル名を付け、URL全体を名前として表示しないでください。サブスクリプションURLには個人を識別できる認証情報が含まれる場合があり、URLにアクセスできる人がノード設定を取得できる可能性があります。スクリーンショット、ログを使った相談、同期するメモでは識別用のパラメーターを隠してください。形式の確認に、よく知らないオンライン変換サイトへ個人用URLを貼り付けないでください。

インポート後はまずダウンロード結果を確認し、その設定を現在の設定として選択します。リストに項目が増えただけでは、読み込みが完了したとは限りません。クライアントによっては選択、有効化、再読み込みが必要です。次にプロキシ画面を開き、想定したプロキシグループとノードが表示されているか確認してください。ノードだけでルールがない場合は、ノード一覧だけを取得した可能性があります。ウェブページの本文、ログイン画面、解析エラーが表示された場合は、まずサブスクリプションURLの用途を提供元に確認してください。ローカルDNSの変更を先に試す必要はありません。

YAMLの確認は構造から始める

設定の解析に失敗した場合は、エラーの行番号と前後の内容を記録します。よくある原因は、スペースの代わりにタブを使っている、同じ階層の項目のインデントがそろっていない、リスト項目のハイフンがない、文字列内の特殊文字が適切に処理されていない、などです。エラー表示の行より前に問題がある場合もあります。たとえば、前の行の引用符が閉じていないケースです。まず直近で動作していたコピーに戻し、変更した箇所を少しずつ確認してください。設定全体のインデントを一括置換で変更しないでください。

次は構造を理解するための最小構成のDIRECT設定です。リモートのプロキシノードは含みません。コアが設定を読み込めるかどうかと、プロキシサービスに接続できるかどうかを切り分けるために使えますが、サブスクリプションの代わりにはなりません。GUIクライアントが待ち受けポートやDNSを独自に管理している場合があります。完全な設定ファイルを読み込めるか事前に確認し、この例をサブスクリプションの末尾にそのまま追加して同名の項目を重複させないでください。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

mixed-portは端末内からの対応プロキシリクエストを受け付けます。LANからのアクセスを禁止すると、ほかの端末がその待ち受け口を使えなくなります。ruleモードはルールに基づいて通信を処理し、ログレベルは通常時の確認に使います。末尾のルールは、どのルールにも一致しなかった通信をDIRECTへ送ります。ポートを別のプロセスが使用中なら、コアの起動に失敗する場合があります。構文が正しいことと、実行環境が整っていることは別です。ポートが競合したら、使用中のプロセスを停止するか、クライアントで変更できる待ち受けポートを設定します。

リモートの更新内容とローカル変更を分ける

サブスクリプションを更新すると、通常は取得元の設定内容が置き換わります。ダウンロードしたファイルを直接編集すると、次回の更新で変更が失われることがあります。クライアントの上書き、マージ、ローカルルール機能を使い、個人設定を分けて保存してください。ただし、実行タイミングとマージ方法は事前に確認します。リストに追加するツールもあれば、項目全体を置き換えるツールもあります。「マージ」という名前の機能なら、元のプロキシグループやルール順が必ず維持されるとは限りません。

更新間隔は、取得元の制限と実際の更新頻度を踏まえて設定します。短い間隔で何度も更新すると、リクエスト制限にかかったり、ネットワークが不安定なときに失敗通知が続いたりすることがあります。まず手動で更新し、設定を再読み込みできることを確認してから定期更新を有効にしてください。更新に失敗しても古い設定が使える場合は、現在の動作状態を保ち、サブスクリプションの有効期限、URLの権限、ダウンロード時のネットワークを確認します。一覧を更新したいだけだからと、唯一動作する設定を先に削除しないでください。

複数端末で同期する場合は、すべてのアプリデータを上書きするのではなく、設定元と必要な個人ルールを同期する方法がおすすめです。スマートフォンとパソコンで同じサブスクリプションを使えても、システムによる通信の取り込み、待ち受けポート、アプリの対象範囲、ファイルパスは端末ごとに管理してください。詳しくはスマートフォンとパソコンでサブスクリプションを共有する方法をご覧ください。この章を終える頃には、現在読み込んでいる設定、その更新元、個別にバックアップが必要なローカル変更を把握できているはずです。

ステップ 05 / リクエストの出口を決める

Rule・Global・Directを使い分ける

普段はルールモードを使う

クライアントのモード設定を開き、普段使いにはRule、つまりルールモードを選びます。コアは設定内のルールを順番に確認し、DIRECT、REJECT、プロキシグループのいずれに送るかを決定します。ルールモードでもすべての通信がプロキシ経由になるわけではなく、ブラウザーだけを対象にするわけでもありません。コアに届いた通信を処理します。アプリがVPNの対象外になっていたり、デスクトップアプリがシステムプロキシを使っていなかったりする場合、ルールモードに切り替えても通信は自動的に取り込まれません。

プロキシ画面を開き、ルールが実際に参照しているプロキシグループを見つけて、使用する出口を選びます。設定には、全体の選択グループ、自動選択グループ、サービス別のグループが同時にある場合があります。1つだけ変更しても、対象サイトの経路に影響しないことがあります。ログや接続画面で対象リクエストがどのグループに一致したかを調べ、そのグループを変更してください。似た名前のグループでも相互に連動しているとは限りません。目立つボタンがすべての通信の最終出口だと決めつけないでください。

Globalは比較用。通信が取り込まれているかの確認にはならない

ルールモードで特定の接続先にアクセスできない場合は、一時的にGlobalへ切り替え、グローバルプロキシグループで想定したノードが選択されていることを確認して、同じ接続先に再度アクセスします。Globalで正常なら、ルールの一致結果、プロキシグループの選択、名前解決の違いを優先して調べてください。この結果だけで元のルールが誤りだと断定することはできません。2つのモードで異なる出口が使われている可能性があります。比較時はネットワーク、接続先、ノードを変えず、ほかの条件をそろえてください。

Globalにしても、端末のすべてのパケットが必ずリモートプロキシを経由するわけではありません。アプリごとの除外、ローカルルート、システムの制限、クライアントの実装によって通信の対象範囲は変わります。Globalに切り替えてもログに対象アプリのリクエストがまったく表示されないなら、ノードを変えても解決しません。アプリが対象に含まれているか、システムVPNが有効か、アプリ独自のプロキシ設定やDIRECT設定がないかを確認してください。モードの選択と通信の取り込み範囲を分けて確認することが、この章で最も重要です。

Directモードはサービス停止と異なる

Directモードでは、コアに取り込まれた通信をDIRECTの出口へ送ります。クライアントの端末内インターフェースやDNS処理は、そのまま残る場合があります。サービスを完全に停止すると、システムのネットワーク経路が変わることもあります。そのため、Directでは接続できるのにサービス停止後は接続できない場合も、その逆の場合も、インターフェース、名前解決、VPNを迂回する通信のブロック設定を確認する必要があります。Directモードを、すべてのネットワーク設定が元に戻った状態とみなさないでください。理由が分からないままシステムのVPN設定を削除するのも避けましょう。

モードを変更したら、新しい接続を開始して検証してください。ブラウザーは接続を再利用し、アプリが長時間接続を維持している場合もあります。ポリシーを変えても、すでにある接続は自動的に作り直されません。関連するページを閉じて開き直すか、クライアントで可能な場合は対象の接続だけを終了します。すべての接続を切断すると進行中の処理も中断されるため、必要な作業を保存してから行ってください。再利用中のセッションのページを更新するだけでなく、新しい接続の出口と一致したルールを確認します。

ノードのテスト結果は、特定のテスト先と方法による結果にすぎず、すべてのサイトへ接続できることを示すものではありません。実際のリクエストは異なるプロトコル、ポート、アドレスファミリーを使う場合があります。ノードを選んだら、対象アプリから実際にアクセスして接続エラーを確認してください。あるアプリでは動くのに別のアプリで失敗する場合は、まず通信の対象に含まれているか、同じプロキシグループを使っているか、異なるネットワーク機能が必要かを比べてから、ノードを変更するか判断します。

比較が終わったらルールモードに戻し、一時的な変更内容を記録してください。Globalのままにすると、修正が必要な振り分けの問題を見落とし、本来直接接続すべきローカルサービスが誤った出口へ送られることがあります。デスクトップのブラウザーとターミナルでシステムプロキシの挙動が異なる場合は、システムプロキシが効かないときの個別の切り分け方法をご覧ください。次の章では、ここで確認した一致結果を個別のルールに結び付けて解説します。

ステップ 06 / ルールを1つずつ変更

ルール振り分け：マッチ順序とローカル上書き

既存ルールを確認してから追加する

ログまたは接続の詳細を開き、対象へアクセスして、ドメイン名、一致したルール、最終的なポリシーを確認します。ルールは通常上から順に評価され、最初に一致した時点で出口が決まります。そのため、より具体的な例外は、より広範囲に適用されるルールより前に置くのが一般的です。デフォルトルールの後に追加した内容は、適用される機会がない場合があります。変更前に、設定にルールセット、ローカルマージ層、クライアントが自動で挿入するルールがあるか確認してください。実行時の順序が元ファイルの順序と同じとは限りません。

ドメイン完全一致は指定した名前だけに適用され、ドメインサフィックス一致は対象ドメインとサブドメインを含みます。IPアドレス範囲のルールは接続先アドレスに基づいて判定します。それぞれ用途が異なり、アプリ画面に表示されるブランド名をそのままドメインルールにすることはできません。アプリが複数のドメインにアクセスしたり、固定アドレスへ接続したりする場合があります。まずログから実際の接続先を集め、必要最小限の範囲でルールを試してください。1つのページを直すために、広いドメイン範囲全体を同じ出口へ送らないようにしましょう。

最小構成の例でルール順を理解する

次の例はリモートノードを含まず、ローカルドメイン、プライベートアドレス、デフォルトルールの順序を示します。単体のDIRECTテスト用設定として使えます。サブスクリプションのルールへ取り込む場合は、クライアントのローカルルールまたは上書き機能から操作し、元の設定のほかの項目を残してください。この例は一部の一般的なローカルアドレスのみを対象とするもので、プライベートネットワークの分類を網羅しているわけではありません。企業環境の特殊なアドレス設計に適する保証もありません。

mode: rule
rules:
  - DOMAIN,localhost,DIRECT
  - DOMAIN-SUFFIX,home.arpa,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

最後のMATCHは、それ以前のルールに一致しなかった通信を処理します。実際のサブスクリプションでは、プロキシグループを指定している場合があります。変更時は、その設定に実在するプロキシグループ名を使ってください。名前が異なると参照エラーになります。アドレスルールのno-resolveは、そのルールに一致させる目的で能動的に名前解決を行わないことを示します。通信全体のほかの名前解決まで禁止するものではありません。この違いを理解しておけば、no-resolveを全体のDNSスイッチと誤認せずに済みます。

ルールセットとプロキシグループは別々に管理

ルールセットは複数の一致条件を管理し、プロキシグループは出口の選択を管理します。両者を混同しないでください。ルールセットの更新に失敗してもノードは使える場合があり、ノードサブスクリプションの更新が成功してもリモートルールが更新済みとは限りません。ルールプロバイダーを確認するときは、取得元の形式、動作タイプ、ダウンロード結果、ローカルキャッシュを確認します。初回ダウンロードに失敗した端末と、以前のキャッシュを保存済みの端末では、実行結果が異なる可能性があります。移行テストでは特に注意してください。

アプリごとに振り分ける場合は、クライアントが提供する機能がアプリ別VPN対象の設定なのか、コアのプロセスルールなのかを確認してください。アプリをVPNの対象外にすると、そのアプリの通信はコアにまったく入らない場合があります。一方、アプリの通信をDIRECTにする場合は、コアによる処理自体は続く可能性があります。両者ではログでの確認しやすさやDNSの挙動が異なる場合があります。Androidのアプリ識別子はデスクトップのプロセス名と異なるため、パソコンのルールをそのままスマートフォンにコピーしても設定は完了しません。

一度に追加するルールは1つにし、保存して再読み込みしたら、新しい接続を作成して確認します。画面上で成功と表示されても結果が変わらない場合は、対象の設定が読み込まれているか、上書きが有効か、デフォルトルールより前にあるか、接続が再利用されていないかの順に確認してください。これらを確認してから、ドメインの識別やDNSマッピングの問題を調べます。同じルールを次々に追加しても設定が読みにくくなり、次回更新時のマージ競合が増えるだけです。

複数の接続先で同じエラーが起きる場合は、それぞれに例外を追加する前に、共通するプロキシグループや名前解決経路を調べてください。ルールを細分化しすぎると、出口側の問題が見えにくくなります。詳しくはRuleの用語解説をご覧ください。設定でよく起きる問題はFAQで確認できます。この章の完了条件は、通信が現在の出口を使う理由を説明でき、元に戻せる1つの変更で結果を変えられることです。

ステップ 07 / 通信範囲を広げる前に名前解決を理解

TUN・VpnService・DNSの連携

仮想ネットワークインターフェースでできること

TUNはネットワーク層の通信を受け取るための仮想ネットワークインターフェースです。デスクトップでは、システムプロキシだけでは対象にできない通信、たとえばプロキシ設定に従わないプログラムや、ブラウザー以外の特定の通信を扱う場合に使われます。TUNとRule、Globalは同じ種類の設定ではありません。前者は通信をコアに取り込む方法、後者は取り込んだ通信をどの出口へ送るかを決めます。TUNを有効にしてもルールモードを使えるため、仮想ネットワークインターフェースのためにすべての通信をGlobalへ切り替える必要はありません。

Androidクライアントは通常、VpnServiceを通じてシステム通信を取得しますが、デスクトップ用のTUN項目をそのままスマートフォンにコピーしないでください。モバイルではクライアントがインターフェース、ルート、ファイルディスクリプターを設定してから、コアへ渡す場合があります。デスクトップの自動ルーティング設定は、追加の権限やシステムコマンドに依存することがあります。まずクライアントが用意するスイッチとデフォルト値を使用し、関連項目のカスタマイズに対応していることを確認してから調整してください。画面が生成する設定と手動設定が互いに上書きし合う事態を防げます。

有効にする前にルートと権限を確認

デスクトップで仮想ネットワークインターフェースを有効にすると、管理者権限やサービス権限が必要になる場合があります。許可したら、まずインターフェースが作成されたことを確認し、一般的なウェブサイト、LAN上の端末、プロキシの接続先にアクセスできるかを調べます。プロキシノードへの通信まで仮想ネットワークインターフェースへ送り返すと、ループが発生する場合があります。別のVPNと同時にデフォルトルートを変更すると、一部の通信が誤った経路を通ることもあります。このような場合は追加した通信取り込み機能をいったん無効にしてネットワークを復旧し、ルートの除外設定とクライアントの説明を確認してください。

LANへのアクセスは個別に検証する必要があります。プリンター、ルーターの管理画面、ネットワークストレージは、ローカルアドレス、マルチキャストによる検出、端末名の名前解決に依存することがあります。外部サイトが開くかどうかだけでは判断できません。まずクライアントが推奨するローカルルートの処理方法を使い、除外ルールが本当に必要か確認してください。端末1台への一時的なアクセスのために、ファイアウォールをすべて無効にしたり、LAN全体から端末内プロキシへの接続を許可したりしないでください。これらは別のアクセス権限に関わります。

DNSが名前をアドレスに変換する

DNSはドメイン名を解決するシステムです。ブラウザーに名前を入力すると、接続を続けるためにIPアドレスを取得するか、プロキシ側で名前解決を行う必要があります。名前解決に成功しても、そのアドレスに接続できるとは限りません。接続に失敗しても、DNSの失敗とは限りません。まずログに表示される名前解決エラー、接続タイムアウト、認証エラーを区別してから、DNS設定を変更してください。サブスクリプションのダウンロードに使う名前解決経路と、プロキシ稼働中の名前解決経路が異なる場合もあります。サブスクリプションを更新できない問題とページを開けない問題が、同じ原因とは限りません。

一部のクライアントが提供するfake-ipモードでは、まずアプリに対応付け用の仮想アドレスを返し、その後コアがドメイン名と接続を対応付けた状態で保持します。ドメイン情報を保ちやすくなりますが、実際のアドレスを前提とするアプリでは例外が必要になることがあります。外部公開用ではないアドレスが返されたからといって、すぐに誤った名前解決だと判断しないでください。モードが有効か、同じコアがリクエストを処理しているか、アプリが通常の名前解決経路を迂回していないかを確認します。

暗号化DNSは名前解決時の通信を保護するもので、正しい出口を自動的に保証するものではありません。DNSサーバー自体にも接続できる必要があります。起動時にまだ確立されていないプロキシ経路に依存すると、名前解決と接続のどちらが先かという循環に陥ることがあります。変更時は、まず基本的な名前解決ができる経路を1つ残し、その後で上流サーバーや振り分けを段階的に調整してください。ブラウザー独自のセキュアDNS、システムのプライベートDNS、クライアントのDNSが同時に関わる場合があります。設定をすべて一度に変更せず、実際に有効な項目を記録してください。

検証の順序は、インターフェースの存在、対象リクエストのログ表示、ドメイン名の処理、ルールの一致、出口への接続、と固定できます。各段階が正常なのに特定のアプリだけ失敗する場合は、アドレスファミリー、UDP対応、アプリ自体の制限を確認してください。ノードが特定の通信方式に対応しているかどうかを、一度のウェブページ表示だけから推測することはできません。この章を終える頃には、TUNが必要な場面と、設定の参照エラーを直すだけなら端末全体の仮想ネットワーク設定に広げる必要がないことを理解できているはずです。

ステップ 08 / 繰り返し使えるメンテナンス手順

更新・バックアップ・段階別のトラブルシューティング

3種類の更新を分けて管理

クライアント、コア、サブスクリプションの更新は、それぞれ別の作業です。クライアントの更新では画面、システム権限、設定の処理方法が変わる場合があります。コアの更新は項目の対応状況やネットワーク動作に影響することがあります。サブスクリプションの更新では主にノード、プロキシグループ、ルールの内容が変わります。すべてを一度に更新して問題が発生すると、原因を特定しにくくなります。日常のメンテナンスでは、まず動作中の状態をバックアップし、1つずつ変更してください。各変更後に基本的なアクセスをテストし、正常であることを確かめてから次へ進みます。

バックアップには少なくとも、設定の取得元、ローカルルール、プロキシグループの選択、システム関連設定を含めます。サブスクリプションURLや認証情報が含まれるファイルは、自分で管理できる安全な場所に保管し、公開の問い合わせには情報を隠した一部だけを使います。アプリからエクスポートしたバックアップには個人情報が含まれる場合があり、システムVPNの権限までは含まれないこともあります。復元前にエクスポートの説明を確認してください。YAMLファイルを復元できることと、端末全体を完全にバックアップできたことは同じではありません。バッテリー制限やアプリ別の設定は再設定が必要になる場合があります。

直近の変更と影響範囲から調べる

接続できなくなったら、まずいつから問題が発生したか、その前に何を変更したか、影響が1つのアプリかすべてのアプリかを記録します。次にWi-Fiとモバイル回線、DIRECT接続先とプロキシ接続先を分けて確認します。サービスを停止しても端末が基本的なネットワークに接続できない場合は、ネットワーク接続やログイン認証画面を先に確認してください。ネットワーク自体が使えない状態でクライアントからノードを何度もテストしても、失敗結果が並ぶだけでノード本来の状態は判断できません。

ノードのタイムアウトは、特定の接続が所定時間内に完了しなかったことを示すもので、サーバーが停止したと断定するものではありません。サブスクリプションの期限切れ、アドレスの名前解決エラー、現在のネットワーク制限、システム時刻のずれ、プロトコルの非対応などが原因になる場合があります。まずノード情報が直近の更新で取得されたものか確認し、端末の時刻が自動同期されているかを確認してから、別のネットワークでも試してください。詳しい手順はノードがタイムアウトし、すべて接続できない場合の確認リストをご覧ください。サーバーアドレス、ポート、プロトコルを同時に変更して当たりを探すのは避けてください。

ログは具体的な問題を調べるときだけ詳細にする

普段は適切なログレベルで利用してください。問題を調べるときは、対象のページを1つだけ開くなど、再現可能な操作を用意してから、短時間だけログの詳細度を上げます。必要な情報を取得したら元のレベルに戻し、記録が大量に残り続けないようにします。ログを共有する前に、ドメイン、アドレス、サブスクリプションのパラメーター、認証情報を隠す必要がないか確認してください。最後のエラー1行だけでは判断できない場合がありますが、確認していない実行ログを丸ごと公開するのも適切ではありません。

ログは発生段階を区別して読みます。名前解決エラーはアドレス取得前に起きます。接続拒否は接続先または途中の機器が明示的に拒否した状態です。タイムアウトは待機時間内に処理が完了しなかった状態です。これらは互いに置き換えられる症状ではありません。証明書関連のエラーでは、システム時刻、サーバー名、ネットワーク環境を先に確認し、検証を無効にして問題を隠さないでください。設定の解析エラーはファイル構造に戻って確認します。通常、この段階ではまだネットワーク接続処理に進んでいません。

修正するたびに、「特定のルールを戻したら対象に接続できた」など、最小限の結論を記録してください。「ネットが直った」とだけ記録するのでは不十分です。その後、サブスクリプションの更新、画面ロック後の復帰、ネットワークの切り替えをテストし、ほかの状況に悪影響がないことを確認します。直近で動作していた設定のコピーと簡単な変更履歴を残しておけば、次の問題発生時に明確な状態へ戻せます。よくある画面上の問題はよくある質問から確認すると、ガイド全体を探し回らずに済みます。

ステップ 09 / 動作する設定から管理しやすい設定へ

応用編：検証・階層化・最小限の変更

まず自分用の検証リストを作る

応用とは、すべての機能を有効にすることではありません。現在の動作を説明でき、変更後に結果が想定どおりであると確認できることです。まず、安定して再現できるテストをいくつか選びます。DIRECT接続のサイト、プロキシが必要な接続先、LAN内のアクセス先、普段使うアプリなどです。変更のたびに同じテストを行い、通信の取り込み、ルール、出口が一貫しているかを確認します。設定を完全に見せるために、使ったことのないプロトコルやルールセットを追加する必要はありません。

設定を階層化する場合は、取得元をリモートサブスクリプション、ローカルポリシー、端末設定に分けると整理しやすくなります。リモートサブスクリプションにはノードと共通ルール、ローカルポリシーには少数の個人用例外、端末設定にはVPNの対象範囲、待ち受けポート、起動動作を割り当てます。各階層の役割を明確にしておくと、更新時にどの部分が変わるべきか判断できます。同じDNS項目をサブスクリプション、上書き設定、クライアント画面のすべてで変更している場合は、最終的にどの設定が有効かを先に特定してから、残す設定箇所を決めてください。

コアのチェック機能で編集内容を確認

コマンドラインの使用経験があれば、mihomoの設定テスト機能でローカルファイルを確認できます。次のコマンドは、コアがインストールされ、現在のディレクトリに設定ファイルがある環境で実行してください。設定のテストを行うもので、OS上にプロキシの通信取り込みを構築する機能ではありません。AndroidのGUIクライアントを使う場合は、アプリ内の設定確認とログを引き続き利用できます。コマンド実行のためにスマートフォンへ別の実行環境をインストールする必要はありません。

mihomo -t -f ./config.yaml

テスト成功が示すのは、コアが設定を読み込み、実行する関連チェックを通過したことです。すべてのリモートノードに接続できることや、ルートと権限が正しいことまでは保証しません。外部のルール、プロバイダー、リソースファイルを使う場合は、作業ディレクトリ、相対パス、ダウンロード条件も確認してください。ターミナルからの起動とGUIクライアントからの起動で、作業ディレクトリが異なることがあります。ある場所で読み込めたローカルファイルが、別の起動方法でも使えるとは限りません。

編集前に設定のコピーを保存し、変更後はまず構文を確認してからクライアントで再読み込みし、新しいリクエストを確認します。問題が発生したら、変更を重ねるのではなく、直前に行った1つの変更を元に戻してください。ファイルを比較する場合は必要な項目だけに絞り、認証情報を公開の差分確認ツールに貼り付けないようにします。サブスクリプションが自動生成した複雑な設定では、マージ方法を理解しているローカル上書きを優先してください。見た目をすっきりさせるために、仕組みの分からない参照項目を手作業で削除しないでください。

リモート管理とLAN共有には追加の対策が必要

一部のコアは、パネルやクライアントが状態を取得したりプロキシグループを切り替えたりするためのコントロールAPIに対応しています。これはプロキシの待ち受けポートとは用途が異なります。通常の個人利用でコントロールAPIをすべてのネットワークインターフェースで待ち受ける必要はありません。リモート管理が必要な場合は、認証、ネットワークの分離、ファイアウォールの許可範囲もあわせて検討してください。管理用の入口、サブスクリプションURL、権限付きのパネルリンクを公開しないでください。ブラウザーから管理画面を開けるからといって、インターネットに公開してよいとは限りません。

LANでプロキシを共有する場合も、別途計画が必要です。他の端末からアクセスできるようにすると、この端末がそれらのネットワーク出口になります。待ち受けアドレス、ポート、接続を許可する相手を確認してください。モバイルホットスポット、公衆Wi-Fi、家庭内ネットワークでは信頼度が異なるため、同じ公開設定を常時使わないでください。管理されたネットワークで端末1台を使って検証し、共有を終えたら接続範囲を元に戻します。認証が必要か、アクセスをどう制限するかは、現在のクライアントが対応する機能に基づいて判断してください。

次に学ぶ内容は目的に合わせて選ぶ

複数端末の管理が目的なら、サブスクリプションとローカル上書きを分ける方法を学びます。アプリの互換性が課題なら、DNS、アドレスファミリー、通信方式の関係を確認します。ルーターへの導入を考えているなら、インターフェース、ルート、サービス管理を調べてください。サーバーやルーターの設定には、起動時のサービス、ファイル権限、ネットワークファイアウォールも関わります。スマートフォンで動いた設定が、そのまま完全な導入方法になるとは限りません。元に戻せる環境で検証してから、日常利用の端末へ移行してください。

最後に、使用クライアント、設定の取得元、ローカルで変更した項目、正常動作の確認方法、元に戻す方法を簡潔にまとめてください。説明できないパラメーターを長々と並べるより、このメモのほうが役に立ちます。基本操作をもう一度確認する場合はクイックスタートガイドへ、端末を変更する場合はダウンロードページでプラットフォームの要件を確認してください。動作を再現でき、原因を特定でき、元に戻せることが、この学習ルートの完了条件です。