Mihomo
入門・応用ガイド

基本概念：コア、クライアント、通信経路

Mihomoはネットワークプロキシのコアで、設定の読み込み、接続の受け付け、ルールの照合、出力先の選択を担います。Clash Metaは、その開発の背景を知るうえでよく使われる名称です。パソコンやスマートフォンのGUIクライアントは、設定のインポート、ノードの選択、権限の取得、動作状態の表示を担います。画面が開いていてもコアが起動しているとは限らず、コアが起動していてもアプリの通信がプロキシに入っているとは限りません。この2つの違いを理解することが、トラブル対処の出発点です。

まずは4つの要素を区別する

クライアントは操作するためのアプリ、コアはネットワーク通信を実際に処理するプログラム、設定ファイルはコアの動作条件、プロキシサーバーは外部への接続先です。サブスクリプションは通常、ノードや設定一式を配布するためのもので、プロキシソフトそのものではありません。クライアントをインストールしても、使えるサーバーが自動的に用意されるわけではありません。ノードに接続できても、帯域、接続元の地域、プロトコルが用途に合うとは限りません。

1つの設定には、待ち受けポート、DNS、プロキシノード、プロキシグループ、ルール、リモートルールセットなどが含まれることがあります。プロキシグループは複数の出力先をまとめ、選択可能な接続先として提供し、ルールからそのグループを参照します。画面上で選ぶノードは設定の一要素にすぎません。リクエストが最終的にDIRECTルールに一致した場合、プロキシグループのノードを切り替えても通信経路は変わりません。

リクエストの流れから振り分けを理解する

ブラウザーでドメインにアクセスするには、まずIPアドレスを取得し、その後に接続を確立します。通信はシステムプロキシ設定を通じてローカルの待ち受けポートに入ることも、TUN仮想ネットワークインターフェースに取り込まれることもあります。コアに入った後、ルールがドメイン、宛先アドレスなどの条件に応じて出力先を決定します。リモートサーバーに到達できるか、接続先のウェブサイトが応答するかは、通信経路の後半に関する問題です。画面上の接続状態だけでは判断できません。

システムプロキシは通常、対応アプリにプロキシの接続先を知らせる機能です。一部のゲーム、コマンドラインツール、独自にネットワークを管理するアプリは、この設定を参照しません。TUNはより広範囲の通信を取り込めますが、ルーティング、DNS、権限に関わります。用途に応じて使い分けるものであり、TUNを有効にすれば必ず速くなるわけでも、システムプロキシが使えないからといってクライアントを再インストールする必要があるわけでもありません。

プロトコル、トランスポート、設定形式を知る

Shadowsocks、Trojan、VLESS、Hysteria2、TUIC、WireGuardなどの名称は、それぞれ異なるプロトコルの機能を表します。対応プロトコルの一覧に載っていても、すべてのノードで利用できるとは限りません。サーバー側で提供されるパラメーター、クライアントが使用するコア、そのビルドで有効になっている機能を確認してください。UDP転送にも、入口、出力プロトコル、リモートサービスのすべてが対応している必要があります。ウェブページを開けても、確認できるのはそのウェブ通信が使えたことだけです。

YAMLは構造化されたテキスト形式です。同じインデントは同じ階層を表し、コロンの後には通常スペースが必要です。リスト項目にはハイフンを使い、インデントにはタブではなくスペースを使います。日本語の説明はコメントに書けますが、フィールドの構文に全角コロンや曲線引用符を混ぜないでください。編集後は、クライアントの設定チェック機能で検証してから、実行中のコアに適用します。

学習時は、安定してアクセスできるテストページ、動作確認済みの設定、明確な復旧手順を用意します。システムプロキシとTUNのどちらを使っているか、現在のモード、選択中のプロキシグループも記録してください。問題が起きたときは、一度に変更する項目を1つに絞ります。用語の意味を確認したい場合は、まず用語集を参照し、通信経路をたどって問題のある段階を特定してください。

選び方とインストール：OS、アーキテクチャ、権限

まずダウンロードセンターでOSを選び、プロセッサアーキテクチャを確認してください。当サイトではClash Plusをおすすめしています。デスクトップでは、使い方に応じてClash Verge RevやFlClashも選べます。WindowsではClash Nyanpasuも利用できます。クライアントによって画面や設定のマージ方法が異なるため、複数を同時にインストールして通信の取り込みを有効にするより、まず1つを選んで基本動作を確認するほうが管理しやすくなります。

OSとメンテナンス状況から選ぶ

macOSではClash Plus、Clash Verge Rev、FlClashを選べます。AndroidではClash Plus、Clash Meta for Android、FlClash、Surfboardを選べますが、Surfboardは設定形式が異なるため、Mihomo YAMLをそのままインポートできるとは限りません。iOS版Clash PlusはApp Storeからインストールでき、公式サイトはclashplus.ioです。クライアントを移行するときは、ファイルの拡張子だけでなく、サブスクリプションの出力形式も確認してください。

LinuxのダウンロードページではClash Verge RevとFlClashを提供しています。インストール前に、ディストリビューションで使えるパッケージ形式を確認してください。Clash for WindowsとClashX Metaはメンテナンスが終了したアーカイブ版のため、新規ユーザーの選択肢としてはおすすめしません。Mihomoコア単体は、設定やプロセスを自分で管理できるユーザー向けです。一般的なデスクトップ利用にはGUIクライアントをおすすめします。

最小構成でインストールする

インストール前に、ほかのプロキシやVPNアプリを終了し、自動で通信を取り込む設定も無効にします。デスクトップ版のインストーラーはOSの手順に沿って実行してください。ポータブル版は書き込み権限のある固定フォルダーに配置し、圧縮ファイルの中から直接起動しないでください。初回起動後は、設定、プロキシ、ログ、設定画面の場所を確認します。スタートアップ起動、LAN共有、複雑な自動更新タスクは、まず無効のままにしておきましょう。

Windowsでは、通常のシステムプロキシ設定とTUNサービスのインストールで、必要な権限が異なる場合があります。インストーラーまたは信頼できるクライアントから明示的に求められた場合に限り、権限を許可してください。macOSでは、まずダウンロード元を確認し、アプリやヘルパーサービスの権限をシステムの案内に従って設定します。個別アプリの起動問題を解決するために、セキュリティ機能全体を無効にしないでください。権限を許可した後も、クライアントに戻ってコアが実際に動作していることを確認します。

Androidで通信の取り込みを有効にすると、通常はシステムのVPN許可画面が表示されます。許可後、ステータスバーにVPNアイコンが表示されることがありますが、リモートノードが使えることの証明にはなりません。同じ環境で動作する別のVPNサービスが、通信の取り込みを競合する場合もあります。まずは1つのサービスだけを動作させ、接続を確認してから、バッテリー最適化の除外やバックグラウンド動作の維持を設定しましょう。権限の問題とノードの問題を混同しないようにしてください。

インストール後の動作確認と終了

まず信頼できる設定をインポートし、コアのログを確認します。ポートが使用中と表示された場合は、古いクライアントや残存プロセスが同じポートを待ち受けていないか確認してください。正体のわからないシステムプロセスをむやみに終了しないでください。ポートを変更した場合、そのポートを参照するアプリのプロキシ設定も同時に変更する必要があります。ログに構文エラーがある場合は設定ファイルを修正します。何度インストールし直しても、誤ったフィールドは直りません。

最後に、正常に終了できることを確認します。システムプロキシまたはTUNを無効にしてからクライアントを終了し、ブラウザーが通常のネットワークで引き続きアクセスできるか確認してください。終了後にネットワーク全体に問題が起きる場合は、システムプロキシがローカルポートを指したままになっていないか確認します。ここまでできれば、管理可能なインストール環境が整ったことになります。システム権限について詳しくはよくある質問を参照してください。既存の環境をすぐに別のクライアントへ置き換える必要はありません。

サブスクリプションと設定：インポート、更新、ローカル上書き

サブスクリプションURLは設定を配布するための入口で、アカウント識別情報やアクセス認証情報が含まれる場合があります。パスワードと同じように安全に保管してください。信頼できる提供元からのみ取得し、公開チャット、スクリーンショット、問い合わせ内容にURL全体を載せないでください。インポート前に、完全なClash設定、ノード一覧、専用形式のどれが提供されているかを確認します。内容に応じて、クライアントの適切なインポート画面を使ってください。

インポートから適用まで

設定管理画面を開き、「リモート設定を追加」またはサブスクリプションのインポート機能を選んで、URL全体を貼り付けて保存します。ダウンロードが完了したら、設定名、更新日時、解析結果を確認し、現在の設定として選択してください。クライアントによっては、ダウンロード、選択、適用が別々の操作です。リストにファイルが表示されても、実行中のコアがその設定を使っているとは限りません。

インポートに失敗した場合は、まずどの段階でエラーが起きたか確認します。ネットワークのタイムアウトはリクエストが正常に完了しなかったことを示します。認証エラーはURLの期限切れなどが原因かもしれません。ウェブページが返された場合は、URLがログイン画面や説明ページを指している可能性があります。解析エラーは、内容の形式が合っていない場合によく発生します。任意のウェブページURLをサブスクリプション変換ツールに渡したり、デバッグのために個人用URLを出所不明のオンラインツールへアップロードしたりしないでください。

適用後は、選択できるプロキシグループが表示されるか確認し、出力先が明確なノードを選んでテストページにアクセスします。ノード一覧が空の場合は、リモートのプロキシプロバイダーからノードを読み込む設定になっているか、関連ファイルがダウンロード済みか確認してください。メイン設定の解析成功と、リモートリソースの取得成功は別の問題です。エラーメッセージとログをそれぞれ確認しましょう。

リモートファイルと実行中の設定を区別する

GUIクライアントは、リモートサブスクリプション、ローカル上書き、画面上の設定を組み合わせて最終的な設定を作ることがよくあります。サブスクリプションファイルに記載されたポートと実際の動作ポートが異なる場合は、画面上の設定で上書きされている可能性があります。トラブル対処では、クライアントが表示する実行中の設定やマージ結果を確認してください。機密情報が含まれる場合があるため、取り扱いに注意が必要です。ダウンロードしたファイルだけで現在の動作を判断しないでください。

長期的に使うカスタムルールは、クライアントがサポートする上書き、マージ、拡張設定に追加するのがおすすめです。ダウンロードしたリモートファイルを直接編集すると、次回の更新で変更が失われることがあります。クライアントによってマージ方法は異なり、リストに追加されるのか、全体が置き換わるのかを確認する必要があります。まず確認しやすいテストルールを1つ追加し、位置と結果を確かめてから本番のルールを移行してください。

# ルール例：既存設定のrulesリストの先頭にマージ
# example.comは予約済みのサンプルドメインです
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT

この例はルールを1つ示すもので、ノードやネットワーク設定一式は含みません。この内容でサブスクリプション全体を置き換えないでください。すでにrulesがある場合は、クライアントのマージ方法に沿ってリスト項目を追加します。同じYAMLマップ内に、同名のフィールドを重ねて記述しないでください。ルールが適用されたかどうかは接続の詳細で確認します。エディターで保存できたことだけでは判断できません。

更新とバックアップの順序を決める

更新間隔は、提供元の推奨とクライアントの機能に合わせます。短い間隔を設定してもノードの安定性は高まりません。サーバー側の頻度制限にかかる可能性もあります。まずは1日1回程度の確認から始め、重要な操作の前には手動で更新して結果を確認しましょう。ノードのサブスクリプション、リモートルールセット、クライアントアプリにはそれぞれ更新周期があります。どれか1つの更新に成功しても、すべての要素が更新されたとは限りません。

更新前に、直前に使えていた設定を保存し、選択中のプロキシグループも記録してください。更新によってノードが削除または改名され、選択内容が無効になることがあります。更新後は、まず設定が正しく解析されるか確認し、よく使うウェブサイトとUDPが必要なアプリで動作を検証します。問題が起きた場合は、先に古い設定へ戻してネットワークが復旧するか確認してから差分を比較してください。DNSを変更しながらクライアントを再インストールするような操作は避けましょう。

複数のデバイスで同じURLを使う場合は、サービスのデバイス数制限やクライアント形式の対応状況も確認します。設定のバックアップには、サブスクリプションURLだけでなく、ローカル上書き、プロキシグループの選択、定期タスクが含まれる場合があります。同期方法は複数デバイス間の設定同期ガイドを参照してください。同期前に、リモートで管理する設定と各デバイス固有の設定を整理しておきましょう。

プロキシモード：ルール、グローバル、DIRECTの確認

プロキシモードは、コアに入ったリクエストの出力先を決めます。リクエストをコアに取り込む機能ではありません。システムプロキシやTUNが入口で、ルール、グローバル、DIRECTがその後の判断方法です。まずアプリが接続されていることを確認してからモードを切り替え、違いを確認してください。リクエストが接続一覧に一度も表示されない場合、モードを変更しても入口に関する問題は解決しません。

3つのモードの違い

ルールモードでは、設定内のルールを上から順に評価して処理方法を決めます。接続先に応じて異なるプロキシグループを使いたい場合に適しています。グローバルモードでは、通常、コアに入ったリクエストをグローバルプロキシグループに送るため、一時的に原因を絞り込むときに使えます。DIRECTモードでは、コアに入ったリクエストを接続先へ直接接続します。DIRECTにしてもクライアントが終了するわけではなく、TUNやローカルの待ち受けが動作し続ける場合があります。モード名だけでDNSの動作を判断することもできません。

使い始めはルールモードを選び、出力先が明確なノードを指定してください。最初から自動テストによる選択に頼る必要はありません。ページを開けない場合は、一時的にグローバルモードへ切り替え、グローバルグループでそのノードが選択されているか確認します。グローバルではアクセスできるのにルールモードでは失敗する場合は、ルールの一致とプロキシグループの参照先を確認します。どちらも失敗する場合は、ノード、DNS、ローカルネットワークを確認してください。

システムプロキシ設定とモードを分けて確認する

システムプロキシを有効にしたら、まずシステム設定に従うブラウザーでテストします。ブラウザー拡張機能、独自のプロキシ設定、個別のプロファイルがシステム設定を上書きする場合があります。コマンドラインツールも、システムのプロキシ設定画面ではなく、環境変数を参照することがあります。ブラウザーで接続できても、ターミナルがプロキシを使っているとは限りません。クライアント全体のスイッチだけでなく、アプリごとに接続経路を確認してください。

ローカルHTTPプロキシを確認するには、混合ポートが7890であることを確かめてから、次のコマンドを実行します。ポートが異なる場合は実際の値に置き換えてください。このコマンドは現在のリクエストだけに明示的にプロキシを使わせるもので、ほかのプログラムの環境変数を設定したり、UDP通信を取り込んだりはしません。接続先には例示用ドメインを使っています。結果は現在のネットワークと選択中の出力先に左右されます。

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

実行後は接続の詳細も確認します。リクエストが表示され、出力先が明確になっていれば、入口からコアまでの経路は確立しています。接続を拒否された場合は、待ち受けポートとコアの動作状態を確認してください。プロキシの入口には接続できてもリモート接続がタイムアウトする場合は、出力先のログを確認します。ターミナルのエラーをすべてノードの問題と決めつけないでください。証明書、システム時刻、ドメイン名の解決が個別に失敗することもあります。

テスト条件を固定する

テストではアプリ、接続先、ノードを固定し、モードだけを1つずつ切り替えて最終的な出力先を記録します。ブラウザーのキャッシュや既存の長時間接続によって、以前の経路が使われ続けることがあります。必要に応じて対象のページを閉じるか接続を切り、リクエストをやり直してください。1回のテストでノード、DNS、TUNを同時に変更すると、接続が復旧しても、どの設定が効いたのか判断できません。

ノードの遅延テストは、特定のテスト先への1回の測定にすぎず、すべてのウェブサイトの総合的な速度を示すものではありません。遅延値を取得できても、対象サービスが使えることやUDP転送の成功を証明できません。大容量ダウンロード、動画、リアルタイムゲームでは通信の特徴が異なります。それぞれのアプリで検証し、サーバー側の制限、出口のポリシー、ローカルネットワークの変化にも注意してください。

トラブル対処が終わったらルールモードに戻し、よく使うサイトが想定したプロキシグループを通るか確認します。プリンター、ルーターの管理画面、開発用サービスなど、ローカルからアクセスする接続もテスト対象に含めてください。終了手順も明確にしておきます。まずシステムプロキシまたはTUNを無効にしてから、アプリを終了します。再現可能なテスト手順は、次章でルールを調整する際の基準になります。ウェブページがたまたま開いたことだけで、設定が正しいとは判断できません。

ルールによる振り分け：判定順、プロキシグループ、ルールセット

ルールモードでは、Mihomoがルールを上から順に確認し、最初に一致したルールで処理先を決めます。ルールを増やせば振り分けが正確になるとは限りません。重要なのは順序と対象範囲です。上位に範囲の広いドメインルールがあると、後続の詳細なルールが実行されないことがあります。変更前に、どのアプリがどの接続先へアクセスし、どの出力先を使いたいのか、何を見て確認するのかを明確にしてください。

まずは少数の確認しやすいルールから

DOMAINは完全一致のドメインを、DOMAIN-SUFFIXはドメインのサフィックスとサブドメインを、DOMAIN-KEYWORDはドメインに含まれるキーワードを照合します。キーワードルールは対象範囲が広くなりやすいため、初心者は具体的なドメインやサフィックスを使うのがおすすめです。ウェブページのURL全体をドメイン欄に入力しないでください。通常、ルールにプロトコル、パス、クエリパラメーターは含めません。

IP-CIDRなどのIPルールは、接続先のアドレス範囲を対象にします。GEOIPは対応するデータに依存し、ウェブサイトの言語や企業の登記上の所在地を判定するものではありません。MATCHは最後に適用するフォールバックルールなので、リストの末尾に置いてください。前のほうに置くと、後続の項目が適用されません。IPルールを書く際はドメイン名の解決が発生するかどうかにも注意し、IPの照合によって余分なDNSリクエストが生じないようにします。

# 学習用の例：個別ルール、IPルール、フォールバックの順序
# この例はすべてDIRECTで、リモートプロキシ機能はありません
rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

no-resolveは、IPルールがドメイン名の解決を新たに要求するのを防ぐために使います。設定全体のDNSを無効にする機能ではなく、すべてのLAN通信がこのIP範囲に一致することを保証するものでもありません。家庭、オフィス、コンテナネットワークでは使用するネットワーク範囲が異なる場合があるため、追加前に実際のルーティングを確認してください。例の末尾がDIRECTなのは構文を示すためです。プロキシ接続が必要な設定全体を、そのまま置き換えるための例ではありません。

ルールが参照するプロキシグループを安定させる

ルールの最後のフィールドには、組み込みアクションまたは既存のプロキシグループ名を指定できます。参照先のグループ名は、スペースや大文字・小文字も含めて設定と完全に一致させてください。多くの場合、ルールからは安定したプロキシグループを参照し、そのグループ内でノードを切り替えるほうが、多数のルールを個別ノードに直接結び付けるより管理しやすくなります。サブスクリプション更新でノードが削除されても、グループ名を安定させておけば修正箇所を減らせます。

手動選択のグループは出力先の確認に、遅延テストを行う自動選択グループは候補内の選択に適しています。単純な優劣ではありません。自動グループのテスト先、テスト間隔、候補の範囲は結果に影響します。また、プロキシグループが別のグループを参照することもあるため、接続の詳細に表示されたグループ名が最終的なリモートノードとは限りません。原因を調べるときは、グループの選択先をたどってください。

リモートルールセットの範囲を理解する

ルールセットはrule-providersで定義し、ルールからRULE-SETで参照します。動作タイプはファイルの内容と一致させてください。ドメイン一覧、IPアドレス一覧、クラシック形式のルールを自由に混在させることはできません。ダウンロードの失敗、書き込み権限のないパス、内容の形式違いが原因で読み込みに失敗することがあります。ルールセット名が表示されても、中の項目が利用可能とは限りません。

大規模なルールセットは用途ごとの管理に役立ちますが、導入前にメンテナンス元、更新頻度、対象範囲を把握してください。まず重要なローカルルールを少数残し、リモートセットを1つずつ追加してログと一致結果を確認します。範囲が大きく重複するルールセットを一度に追加してから調査を始めると、先行ルールによる横取り、セット内容の変化、プロキシグループの選択ミスを見分けにくくなります。

ルールを確認するには、対象ページを開いて接続に表示されるドメイン、ルール、出力先を確認します。ウェブページは画像、ログイン、APIなど複数のドメインへリクエストを送ることがよくあります。メインのドメインが正しいルールに一致しても、すべてのリソースが同じ経路を通るとは限りません。一部の内容だけ読み込めない場合は、失敗したリクエストのドメインを調べてください。アプリ全体を恒久的にグローバルモードへ切り替えるのは避けましょう。

ルールをメンテナンスするときは、ローカルでの変更に、対象と理由を簡潔にコメントしてください。フィールド名を繰り返すだけのコメントは不要です。設定を更新するたびに、カスタムルールが想定した位置にあるか確認します。DNSに関する問題はDNS設定のセクションで引き続き確認してください。コアでドメイン名を確認できない場合、ドメインルールを追加するだけでは解決しないことがあります。まずリクエストの入口と名前解決の経路を確認しましょう。

TUNによる通信の取り込み：ルーティング、DNS、UDPの注意点

TUNは仮想ネットワークインターフェースで通信を受け取り、コアに渡します。システムプロキシに従わないアプリにも適しています。変更するのは通信の取り込み方法であり、ノード、ルール、リモート側の機能を代替するものではありません。有効にする前に、システムプロキシで動作する設定を用意し、現在のDNS、ほかのVPN、仮想ネットワークインターフェースの状態を記録してください。基準があれば、新しい問題を通信の取り込み段階に絞り込めます。

必要なサービスを設定してから機能を有効にする

デスクトップクライアントでは、ネットワークインターフェースの作成やルート変更に必要な権限を、サービスモードやヘルパープロセスで取得する場合があります。操作方法はクライアントによって異なります。画面の案内に従ってサービスをインストールし、正常な状態を確認してからTUNを有効にしてください。Androidでは通常、システムのVPN許可を使って通信を取り込みます。すべてのクライアントが同じ権限モデルだと考えないでください。スイッチを押せるからといって、インターフェースが作成されたとは限りません。

初回はネットワークスタックの初期設定を維持し、厳格なルーティング、複雑な除外リスト、複数のDNS上流を同時に追加しないでください。まず通常のウェブページを確認し、次にシステムプロキシでは使えなかったアプリをテストします。コアのログに権限不足やインターフェース作成失敗が表示された場合は、サービスとシステム権限を先に確認してください。この段階でノードを切り替えても、仮想インターフェースの問題は解決しません。

# TUNの設定例。動作確認済みの既存設定にマージしてください
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: false
  dns-hijack:
    - any:53

この例は一般的なフィールドを示すもので、すべてのシステムで使えるとは限りません。クライアントの画面設定がこれらの値を上書きすることもあります。適用後は実際に動作中の設定を確認してください。auto-routeは関連するルートの自動設定に、auto-detect-interfaceは出力インターフェースの選択補助に使います。複数のネットワークアダプター、仮想マシン、特殊なダイヤルアップ環境では追加確認が必要になる場合があります。ネットワークスタックの利用可否や動作は、プラットフォームの対応状況によって異なります。

自動ルートと厳格なルートを理解する

自動ルートを有効にすると、条件に合うリクエストがTUNに入りますが、端末上のすべての通信が必ず取り込まれるとは限りません。ルートの優先順位、除外設定、アプリに割り当てられたインターフェース、ほかのVPNが結果に影響することがあります。厳格なルートは通信を取り込む範囲を制限します。OSによってルーティングや制限の動作が異なり、速度を上げるための設定でも、あらゆる問題に対する標準的な解決策でもありません。

厳格なルートを有効にする前に、LANへのアクセス、システムのネットワーク接続確認、社内ネットワークに必要な通信をテストします。プリンターが見つからなくなったり、社内サービスに接続できなくなったりした場合は、直前に追加したルート設定を無効にし、問題が解消するか確認してください。その後、実際のネットワーク範囲に合わせて例外を設定します。経験だけを頼りに多くのアドレス範囲を除外すると、取り込みたい通信まで迂回する可能性があります。

DNSとUDPを個別に確認する

dns-hijackは、条件に一致した従来型のDNSリクエストをコアのDNS処理に転送します。この例ではポート53へのリクエストが対象ですが、アプリ独自の暗号化DNSを自動的に復号するわけではありません。ブラウザーのセキュアDNSやアプリ内蔵の名前解決は、別の経路を使う場合があります。有効にした後にドメインへのアクセスで問題が起きたら、TUNのスイッチだけを見るのではなく、DNSの入口と接続の入口を分けて確認してください。

UDPは、実際に必要とするアプリを使って検証します。ノード設定でUDPが許可されていても、サーバーや途中のネットワークが必要な通信に対応しているとは限りません。ゲームで接続できない場合は、通信がコアに入っているか、必要な機能に対応した出力先がルールで選ばれているか、リモート側から応答があるか確認してください。ウェブページや遅延テストの成功は、これらの検証の代わりにはならず、リアルタイム通信の安定性も保証しません。

スリープからの復帰、Wi-Fiの切り替え、有線ネットワークアダプターの接続後は、出力インターフェースやデフォルトルートが変わることがあります。ネットワーク切り替え後だけ失敗する場合は、まず通信の取り込みを再起動するか、クライアントの手順に従ってインターフェースを作り直し、ログを比較してください。普段使うネットワークでTUNを安定して開始・停止できることを確認してから、スタートアップ時の自動起動を検討します。ルーターやサーバーへの導入には、転送、ファイアウォール、戻り経路の設定が必要です。デスクトップ用の設定例をそのまま流用せず、独立した作業として扱ってください。

日常のメンテナンス：更新、ログ、トラブル時の復旧

安定した運用には、環境の頻繁な再構築ではなく、変更履歴を追える管理が欠かせません。動作確認済みの設定、必要なローカル上書き、現在の通信取り込み方法を記録してください。クライアント、コア、サブスクリプション、ルールセット、地理データはそれぞれ別の更新対象で、管理画面も異なる場合があります。更新ボタンの処理が成功しても、すべての要素が変わったとは限りません。設定の動作が以前と同じとも限りません。

順序を決めて更新する

クライアントを更新する前にリリースノートを読み、OSの対応状況と設定の移行に関する案内を確認してください。設定をエクスポートまたはバックアップし、通信の取り込みを正常に無効にしてからインストールします。更新後は、以前の設定を読み込めるか、待ち受けポートが変わっていないかを確認し、システムプロキシとTUNの動作をテストします。クライアントにコアの個別更新機能がある場合は、同じテスト中にアプリ本体とコアを同時に置き換えないようにしてください。

サブスクリプションの更新後はノードやグループ名の変更を、ルールセットの更新後は重要な接続先の一致結果を確認します。リモートリソースのダウンロードに成功していても、内容が想定と異なる場合があります。パスの権限が原因で古いデータが残ることもあります。ログと更新時刻をあわせて確認してください。重要な作業の前に複数の要素をまとめて更新するのは避けましょう。同期更新を急ぐより、検証と復旧の時間を確保するほうが実用的です。

入口、名前解決、ルール、出力先の順に調べる

まず、通常のネットワークでアクセスできるはずの接続先に到達できることを確認し、次にコアのプロセスとローカルの待ち受けを確認します。その後、失敗したリクエストが接続一覧に入っているかを確認してください。記録がまったくない場合は、アプリのプロキシ設定またはTUNを調べます。記録がある場合は、ドメイン名の解決、ルールの一致、選択中の出力先を確認してください。最後にリモート側とのハンドシェイクと接続先サービスの応答を調べます。この順で確認すると、システムプロキシの設定残りをサーバー障害と誤認しにくくなります。

ログの「接続拒否」は通常、接続先のポートが接続を受け付けていないことを示します。「タイムアウト」は期限内に処理が完了しなかったこと、「名前解決エラー」はドメイン名の処理段階に問題があることを示します。具体的な原因は、エラーに含まれるアドレス、ポート、処理段階をあわせて判断してください。証明書エラーは、システム時刻やサーバー名が原因のこともあります。最後の1行だけをコピーせず、前後の同じ時間帯のログも残してください。

トラブル対処の間だけログの詳細度を上げ、完了後は普段使うレベルに戻してください。ログを長期間記録すると、ストレージとプライバシーへの負担が増えます。共有する前に、サブスクリプションURL、認証情報、コントロールインターフェースの認証情報、個人を特定できる情報を削除してください。スクリーンショットからノードの完全なアドレスやアカウント情報が漏れることもあります。状況を説明する際は、エラーの種類、発生時刻、必要な通信段階を優先して伝えてください。

変更の影響を切り戻して確認する

更新後に問題が起きたら、まず前回使えていた設定に戻し、必要に応じて以前の通信取り込み設定も復元します。ネットワークが復旧してから差分を1つずつ比較してください。復元しても直らない場合は、ローカルネットワーク、サーバー側、その他の外部要因が考えられます。切り戻しは最終的な結論ではなく、問題が今回の変更に関係するかを確かめる手段です。設定ファイルの差分をテキストで比較するほうが、記憶に頼って項目を探すより確実です。

スマートフォンのバックグラウンドで切断する場合は、OSによるアプリ終了、ネットワーク切り替え、リモート側のタイムアウトを区別してください。アプリに戻った直後に復旧するなら、バックグラウンド制限や省電力設定を確認する価値があります。デスクトップでは、スリープ復帰後のインターフェース、DNS、ルートの再設定を確認します。発生時の端末の状態とタイミングを記録し、あらゆる断続的な問題を同じ設定項目のせいにしないでください。

サポートを求める際は、プラットフォーム、クライアント名、通信の取り込み方法、接続できない対象の種類、直近の変更、すでに試した内容を伝えてください。「インターネットにつながらない」だけでは状況を特定できません。接続済みなのにページが開けない場合の確認リストを参考に必要な情報を整理し、該当する項目はよくある質問で確認してください。個人情報を含む設定一式より、再現できる最小限のケースのほうが共有に適しています。

DNSと応用設定：名前解決の経路、コントロールインターフェース、導入方法

前の章を終えてから、DNSと自動化をそれぞれ独立したテーマとして学びましょう。DNSはドメインからIPアドレスを調べるだけでなく、ルールから見える情報、接続先、ネットワーク経路にも影響します。変更前に、システムDNS、ブラウザーのセキュアDNS、クライアントのDNS、TUNのDNSハイジャック設定を記録してください。どこでリクエストを受け取り、どこへ問い合わせるのかを整理すると、複数の名前解決レイヤーが互いに依存する問題を避けられます。

Fake-IPと上流DNSの役割

fake-ipモードでは、アプリにマッピング用のIPアドレスを返し、コアがそのアドレスからドメイン名と後続の接続をひも付けます。実際の接続先が存在しないという意味でも、リモートサーバーのアドレスという意味でもありません。redir-hostは、名前解決した実際のIPアドレスをアプリに返します。互換性やルールで利用できる情報はモードによって異なるため、すべての端末で同じ設定にするのではなく、アプリと通信の取り込み方法に合わせて確認してください。

以下は既存設定にマージするDNSの例です。ループバックアドレスで待ち受けると、ローカルの待ち受け範囲を限定できます。TUNやクライアントが独自のDNS接続方法を使う場合は、必要な設定を維持し、無理に上書きしないでください。例で使用する上流DNSに、現在のネットワークから到達できることも確認します。まず名前解決が完了することを検証してから、振り分けや代替手段を検討してください。

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

nameserverは通常の上流DNSサーバーのリストです。複数のアドレスを記述しても、上から順に切り替わるとは限りません。ドメイン名を使う暗号化DNSでは、その上流サーバーのドメインを解決するための初期経路も考慮してください。ノードのサーバーアドレスがドメイン名の場合も、接続前に名前解決が必要です。ノードへの接続がまだ確立していないのに、そのノードに依存して名前解決する構成は避けましょう。

fallbackとfallback-filterは、代替DNSと結果の選択条件を設定するためのもので、任意のリクエストが失敗したら自動的に別のアドレスへ切り替える機能ではありません。実際の名前解決要件に合わせて設計し、上流サーバーを何重にも追加しないでください。LAN内のドメインや特定のアプリではマッピングアドレスが適さない場合があります。そのときはfake-ip-filterを検討できますが、まず名前解決モードが原因だと確認してから、対象範囲を限定した例外を追加してください。

モードを切り替えた後も、アプリが以前のアドレスをキャッシュしていたり、ブラウザーが既存の接続を維持していたりすることがあります。新しくリクエストを発生させ、OSとクライアントが提供する方法に従って関連キャッシュを処理してください。古い状態を新しい設定の結果と誤認しないようにしましょう。各パラメーターの関係はnameserver、fallback、DNSハイジャックの解説を参照し、新しい名前解決の経路は1つずつ試してください。

コントロールインターフェースとLANアクセス

外部コントロールインターフェースからは、状態の取得や管理操作ができます。初期設定ではローカルホストに限定し、認証情報を設定してからリモート管理を検討してください。コントロールポートをインターネットに直接公開しないでください。ほかの端末からローカルプロキシを使う場合も、待ち受けアドレス、認証、OSのファイアウォールを確認します。LANアクセスの許可は単独のスイッチで完結するものではなく、どの接続元から実際に接続できるかにも関わります。

設定、ログ、バックアップには機密情報が含まれることがあります。プライベートリポジトリにも適切なアクセス制御が必要です。自動同期の前に、共有すべきでない端末設定を除外し、端末ごとに異なるポート、ルート、権限の設定が混在しないようにしてください。自動化タスクでは失敗を通知し、最後に使えた状態を保持する必要があります。エラーページを取得したときに、使用中の設定をそのまま上書きしないでください。

用途に合わせて次の学習テーマを選ぶ

デスクトップユーザーは、プロキシグループとルールセットの管理を続けて学ぶとよいでしょう。モバイルユーザーは、ネットワーク切り替えとバックグラウンドでの安定性を優先してください。サーバーやルーターで使う場合は、サービス管理、転送、ファイアウォールへ進みます。さらに戻り経路と通信の取り込み範囲も確認が必要です。デスクトップ用の設定をコピーしただけでは導入完了とはいえません。コアのコマンドラインを使う前に、現在のプログラムのヘルプを確認し、設定チェックを実行してください。

応用設定には、それぞれ確認条件を設けてください。ルールは接続の詳細で説明できること、DNSは名前解決の経路を説明できること、TUNは安定して開始・停止できること、更新後は以前の設定に戻せることが目安です。これらを確認してから、自動選択やリモート管理を追加しましょう。基本的な手順をやり直す場合はクイックスタートガイドへ、クライアントを変更する場合はダウンロードセンターへ進んでください。学習内容と実際の操作を対応させながら進めましょう。