MIHOMO / CONFIGURATION HANDBOOK
Clash 設定ガイド：基礎から応用まで
基本概念 → クライアント → インストール → サブスクリプション → モード → ルール → TUN → メンテナンス → 応用
このページは、初期設定を終えたあとに確認できる総合ガイドです。前提となる項目から順に、まず検証可能なプロキシ接続を確立し、ルール分岐、DNS、仮想ネットワークインターフェースへと進みます。初回接続だけを設定する場合は、まずClash入門ガイドをご覧ください。設定項目の意味、通信の接管範囲、メンテナンスで困ったときは、該当する章を参照してください。本文のYAMLは、関連項目に対応したmihomoコアを前提としています。GUIのメニュー名はクライアントによって異なります。
1. 基本概念と通信経路
クライアント・コア・サービスの役割
Clashのエコシステムにある名称は、すべて同じソフトウェア層を指すわけではありません。クライアントは通常、画面の表示、設定の管理、システムプロキシの変更、バックグラウンドサービスの起動を担います。コアはローカルポートの待ち受け、ルールの判定、外部への接続を担当します。mihomoはこのエコシステムで開発が続くプロキシコアで、Clash Metaは関連する過去の資料でよく見かける名称です。GUIクライアントをインストールして画面が開いても、確認できるのはフロントエンドが起動したことだけです。コアの起動やサブスクリプションの有効性までは判断できません。
サブスクリプションから取得できるのは、リモート設定またはノード情報です。ノードには、プロキシサーバーへの接続に必要なアドレス、プロトコル、認証情報が記載されています。クライアントをインストールしただけでは、利用可能な接続先は用意されません。有効期限、通信量の上限、サービス品質は各サービスによって異なります。サブスクリプションを追加する前に、配布元が信頼でき、利用する権限があることを確認してください。ログやスクリーンショットを共有する際は、サブスクリプションURLにアクセス情報が含まれることが多いため、一般のWebアドレスのように公開しないでください。
アクセスを4つの段階に分けて考える
Webサイトへのアクセスは、入口、判定、名前解決、外向き接続の4段階に分けて考えられます。入口ではアプリの通信がコアに入るかどうか、判定ではどのルールやプロキシグループを使うか、名前解決では接続先のドメインをIPアドレスに変換するか、外向き接続ではDIRECT、プロキシ、拒否のいずれで処理するかが決まります。実際の処理はDNSモード、ドメインのスニッフィング、接続方式によって複雑に絡みますが、この4点は切り分けに役立ちます。ブラウザーでWebページが開かないときは、DNSの設定を次々に変更するのではなく、まず通信の入口を確認してください。
DIRECTは端末のネットワークから接続先へ直接接続すること、REJECTは該当する通信を拒否することを表します。プロキシグループは、1つまたは複数のプロキシノードを接続先として選べます。ルールモードではWebサイトごとに異なる経路を使えるため、端末のIPアドレスとプロキシの出口IPアドレスが両方確認できても、必ずしも異常ではありません。一方、グローバルモードでDIRECTを選ぶと、コアに入った通信がすべて直接接続になることがあります。動作を判断するには、現在のモード、実際に適用されたルール、最終的な接続先を確認してください。画面上の接続状態だけでは判断できません。
繰り返し検証できる方法を用意する
期待する経路が明確なアクセス先を2つ用意します。1つは直接接続、もう1つはプロキシ経由になるものを選びます。接続パネルを開き、接続先ドメイン、適用ルール、プロキシグループ、最終ノードを記録して、ページが読み込めるか確認してください。Webサイトに表示される出口IPだけで、すべてのアプリの経路を判断するのは避けましょう。ブラウザーのキャッシュ、アプリ独自のプロキシ設定、IPv6、接続プロトコルの違いによって結果が変わる場合があります。大切なのは、個別の速度測定値を集めることではなく、リクエストとコアの記録を対応づけることです。
設定の学習も、この経路に沿って進めましょう。まずノードが接続できる状態にし、次にアプリの通信をプロキシへ通し、最後にルールやDNSを細かく調整します。前の段階ができていないうちにルールを増やすと、原因の切り分けが難しくなります。クライアント名、OSのアーキテクチャ、待ち受けポート、通信の接管方法、検証結果をローカルに記録しておくと便利です。サブスクリプションや認証情報を含む元データは、公開する可能性のあるトラブル報告とは分けて保管してください。
2. プラットフォームと運用方法に合うクライアントを選ぶ
まずクライアントを選び、対応機能を確認する
初めて使う場合は、まずClash Plusを確認し、そのうえで利用するプラットフォームや必要な機能に応じて他のクライアントと比較しましょう。選ぶ際はOSとCPUアーキテクチャを確認し、次にサブスクリプション管理、システムプロキシ、TUN、ログのエクスポート、設定の上書き機能が要件を満たすかを見ます。画面にスイッチが表示されていても、すべてのOSで同じように動くとは限りません。同じクライアントでも、権限、バックグラウンド動作、OSのネットワーク機能によってプラットフォームごとに制約が異なる場合があります。特定の機能が必要なら、インストール後に実際の接続で動作を確認してください。
WindowsではClash Plus、Clash Verge Rev、FlClash、Clash Nyanpasuを比較できます。Clash for Windowsは開発終了済みで、アーカイブ用途の選択肢です。macOSではClash Plus、Clash Verge Rev、FlClashを比較できます。ClashX Metaもアーカイブ版です。アーカイブ版は古いガイドを理解したり、設定を移行したりする用途には使えますが、新規ユーザーが長期運用するための第一候補には向きません。古い画面のスクリーンショット、ボタンの位置、設定項目を、現行クライアントの操作手順としてそのまま使わないでください。
AndroidではClash Plus、Clash Meta for Android、FlClash、Surfboardを確認できます。iOSではClash Plusを利用でき、公式サイトはclashplus.ioです。LinuxではClash Verge RevとFlClashを優先して比較してください。候補に挙げたクライアントが設定の互換性を保証するわけではありません。特にSurfboardの設定形式をmihomoのYAMLとそのまま併用することはできません。インストール先はダウンロードページにまとめています。先にプラットフォームを確認してからアプリを選んでください。
アーキテクチャ・配布形式・実行権限を確認する
CPUアーキテクチャによってプログラムが動作するかどうかが決まり、配布形式によってインストール方法が異なります。Windowsではx64とARM64、macOSではApple SiliconとIntel、AndroidではARM64と旧世代のARM環境を区別してください。LinuxのDEBとRPMは、異なるディストリビューション向けのパッケージ形式です。同じインストールコマンドがどちらでも使えるという意味ではありません。デスクトップOSで互換実行が可能な場合でも、サービスや仮想ネットワークインターフェースの差を減らすため、CPUに合ったパッケージを選ぶのがおすすめです。
| 用途 | 優先して確認する項目 | 最初の確認方法 |
|---|---|---|
| ブラウザーや一般的なデスクトップアプリ | システムプロキシとサブスクリプション管理 | 接続パネルに該当ドメインが表示される |
| ターミナルやプロキシ設定に従わないアプリ | 明示的なプロキシ設定またはTUNへの対応 | リクエストが想定した接続先に到達する |
| サーバーやルーター | コアのアーキテクチャ、サービス管理、ルーティング | 待ち受け、権限、転送経路 |
GUIクライアントと単体コアの使い分け
単体のmihomoコアは、サーバーやルーターの運用者、システムサービスに慣れたユーザーに向いています。設定を読み込んでプロキシの待ち受けを提供できますが、デスクトップのトレイアイコン、サブスクリプション編集画面、システムプロキシの切り替えボタンなどは備えていません。単体コアを使う場合は、プロセスの再起動、ファイル権限、サービスの起動順、ログの保存方法を自分で計画する必要があります。一般的なデスクトップユーザーは、まずGUIで基本の動作を理解してからコマンドラインに移行すると、ネットワーク設定とサービス管理を一度に学ばずに済みます。
クライアントを移行する際は、元のサブスクリプション配布元、プロキシグループの選択、必要な上書きルールを引き継ぎましょう。以前のクライアントのデータフォルダーを丸ごとコピーするのは避けてください。クライアントによってデータ構造、暗号化された保存情報、サービス設定が異なり、互換性がない場合があります。新しいクライアントで設定を再度読み込み、基本動作を確認してから、必要なカスタムルールだけを少しずつ移行するのがおすすめです。移行中にシステムプロキシやトンネルの接管を有効にするクライアントは1つだけにしてください。元のクライアントを終了してもシステムプロキシの設定が残る場合があるため、OSのネットワーク設定も確認しましょう。
3. インストール・権限・最小限の動作確認
インストール前に通信の接管が競合していないか確認する
ダウンロードページから、OSとアーキテクチャに合ったインストーラーを選び、クライアントの通常の手順でインストールします。初回起動の前に、プロキシやルート設定を変更している他のツールを終了し、以前のプロキシアドレスがシステムに残っていないか確認してください。会社や学校の端末、管理対象のPCでは、仮想ネットワークインターフェースやバックグラウンドサービスのインストールが制限されていることがあります。管理ポリシーを回避して無理に変更しないでください。画面は起動するのにサービスのインストールに失敗する場合は、インストールを何度も上書きする前に、権限の案内とOS側の制限を確認しましょう。
Windowsでは、バックグラウンドのコアやTUNの利用にサービスモードや管理者権限が必要な場合があります。macOSではネットワーク関連の許可を求められることがあり、モバイルOSでは通常、VPN構成の作成をユーザーが許可する必要があります。ここで表示されるVPNは、OSのネットワーク接管機能を使うことを示すもので、接続先のプロトコルを表すわけではありません。権限は必要なときに、クライアントの手順に従って付与してください。アプリの配布元や署名に問題があるという警告が表示された場合は、ダウンロード元とOSのセキュリティ通知を確認し、OSの保護機能を無効にすることを標準のインストール手順にしないでください。
複雑な設定を読み込む前にローカルの待ち受けを確認する
最小限の動作確認では、ローカルの待ち受け、ルールモード、明示的なDIRECTの接続先だけを使います。次の設定は単体コアでのローカルテスト用です。プロキシノードを含まないため、リモートのプロキシ接続は検証できません。GUIクライアントが待ち受けポートやコントロールインターフェースを独自に管理する場合があります。設定を読み込んだ後、有効設定を確認し、該当項目が上書きされていないか見てください。テストでは、コアが設定を正常に読み込み、明示的にローカルプロキシを使うリクエストが接続記録に表示されることを確認します。
mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info
rules:
- MATCH,DIRECTmixed-port は、同じ待ち受けポートでHTTPとSOCKSのプロキシ接続を受け付けます。リモートサーバーのポートではありません。allow-lan: false は、LAN内の他の端末からのアクセスを制限する設定です。ローカルテストでプロキシを他の端末に公開する必要はありません。待ち受けアドレスや接続元の許可範囲には、OSのファイアウォールも影響します。1つの設定項目だけでアクセス制御が完結するわけではありません。LAN内で共有する必要がある場合は、許可する端末、ネットワークの範囲、ファイアウォールルールを別途明確にしてください。
ポートと設定ファイルの構文を確認する
単体コアを使う場合は、まず次のコマンドで設定を検査できます。実行ファイル名とパスは、実際のインストール先に合わせてください。検査に合格しても、設定を解析できたことを示すだけで、サブスクリプションに含まれるリモートサーバーへの接続を保証するものではありません。YAMLではスペースでインデントし、同じ階層の項目を揃え、リスト項目にはハイフンを使います。記事の設定例をコピーする際は、インデントがタブに変わっていないか注意してください。既存の設定に同じ名前の最上位項目を2つ作ると、片方が上書きされたり、設定が曖昧になったりするおそれがあります。
mihomo -t -f config.yaml
curl -I -x http://127.0.0.1:7890 https://example.com起動ログにポートの競合が表示されたら、まず使用中のプロセスを特定してから、古いプログラムを終了するか、待ち受けポートを変更するか決めます。ポートを変更した後は、システムプロキシ、ブラウザー拡張機能、ターミナルの環境変数も合わせて更新してください。Windowsではnetstat -ano | findstr :7890を実行すると、関連する接続を確認できます。プロセスIDから該当するアプリを特定し、不明なシステムプロセスを強制終了しないでください。詳しい手順はポート競合とmixed-portの変更方法をご覧ください。
4. サブスクリプションの読み込み・有効設定・上書き
サブスクリプションの内容と読み込み結果を確認する
クライアントの設定またはサブスクリプション管理画面でリモートURLを追加し、識別しやすい名前を付けてからダウンロードまたは更新します。読み込み後は、その設定が現在の設定として選択されていることを確認し、プロキシノードやプロキシグループが表示されるか確認してください。配布元によって、完全なYAML、ノード一覧、他のソフト向けの形式など、返される内容が異なります。サーバーから正常に応答があっても、現在のクライアントで使える形式とは限りません。読み込み時に構文エラーが出る場合は、配布元の形式とサブスクリプションの説明を確認しましょう。
サブスクリプションの読み込みに失敗したら、ダウンロードの失敗と解析の失敗を分けて考えます。ダウンロードエラーは、タイムアウト、証明書の問題、認証の期限切れ、サーバーによる拒否などが原因です。解析エラーは、Webページが返された、形式に互換性がない、項目に誤りがある場合などに発生します。まずクライアントに表示される詳細なエラーを確認し、サブスクリプションURLを不明なオンライン変換サイトに入力しないでください。URLのクエリパラメーターがアカウントの権限情報を含む場合があります。トラブル時のスクリーンショットを共有するなら、URL全体とノードの認証情報を隠し、エラーの種類を判断できる範囲だけ残してください。
実際に読み込まれている設定を確認する
GUIクライアントでは、元のサブスクリプション、ローカルの上書き設定、実行時の有効設定が別々に存在することがあります。元のサブスクリプションはダウンロード内容、上書き設定はポートやDNS、ルールなどの追加設定、有効設定はコアが最終的に読み込む内容です。画面上のスイッチを変更したら、実行時の設定も変わったか確認してください。キャッシュファイルを直接編集すると、次回の更新で変更が消える場合があります。設定が何度も元に戻るときは、同じ一時ファイルを繰り返し編集するのではなく、どの層を変更したか確認しましょう。
長期的に使うカスタム設定は、クライアントが正式に対応する上書き機能やマージ機能に追加します。配列の処理方法はクライアントによって大きく異なります。リスト全体を置き換えるものもあれば、先頭や末尾への追加に対応するものもあるため、マージ後も元のルールが残るとは限りません。特にrules、proxy-groups、dns.nameserverを一括置換すると、サブスクリプション本来の構成が失われることがあります。上書き設定を初めて使う前にバックアップを取り、有効設定で最終的な項目の順序を確認してください。
更新後も設定間の参照関係を保つ
ルールはプロキシグループを参照し、プロキシグループはノードやプロバイダーを参照します。名前が変われば、参照関係にも影響します。リモート更新でノードが削除されても、ローカルで作成したプロキシグループが古いノード名を参照していると、設定の読み込みに失敗したり、選択できなくなったりすることがあります。配布元が頻繁に変更する個別のノード名ではなく、変更されにくいプロキシグループ名をローカルルールから参照するのがおすすめです。次の例は構造の説明用で、完全なプロキシ設定ではありません。「プロキシ出口」というプロキシグループは、実際の設定内で定義済みである必要があります。
rules:
- DOMAIN-SUFFIX,example.com,プロキシ出口
- DOMAIN-SUFFIX,lan,DIRECT
- MATCH,DIRECT更新前に、現在使用できるプロキシグループの選択を記録し、更新後にノードとルールを再確認してください。自動更新の頻度を過度に上げても、サーバーの利用上限や認証切れは解決しません。アクセス制限を招く可能性もあります。新しいサブスクリプションのダウンロードに失敗した場合、障害中に利用可能な設定まで消さないよう、前回の設定を優先して保持してください。クライアントに設定履歴がある場合は、どの内容に戻せるか確認しましょう。最新の内容しか保存されない場合は、必要なローカルバックアップを別途保管してください。
サブスクリプションの変換が必要なのは、配布元と読み込み先の形式が異なる場合に限られます。変換しても、プロトコルのパラメーター、ルールセット、DNSの動作が完全に保たれるとは限りません。変換後も構文検査と接続確認を行い、「変換成功」を実際の動作確認の代わりにしないでください。日常の管理では、サブスクリプションの更新とノードの切り替えを区別しましょう。前者は設定データを変更し、後者は現在の接続先を切り替えるだけです。基本操作は入門ガイドのサブスクリプション読み込み手順を見ながら確認できます。
5. プロキシモード・システムプロキシ・実際の通信経路
ルール・グローバル・DIRECTの違い
ルールモードでは、設定に記述された順序に従って接続先を決めます。日常的な通信の振り分けは、まずこのモードから始めましょう。グローバルモードでは、コアに入った接続をグローバル設定の選択先へ送ります。特定の接続先に対して、ノードが使えるか一時的に確認する場合に便利です。DIRECTモードでは、コアに入った通信を直接接続します。端末のネットワークとプロキシ経由の経路を比較するときに利用できます。3つのモードが変更するのは、コアが受け取った通信の処理方法です。アプリがそもそもコアを経由していなければ、モードを切り替えても通常は接続経路は変わりません。
初回接続では、プロキシグループで接続先のノードを1つ選び、ルールモードで動作を確認します。接続できない場合は、グローバルモードに一時的に切り替え、同じノードを明示的に選んで結果を比較してください。グローバルモードでは接続できてルールモードではできないなら、ルールやプロキシグループの選択を重点的に確認します。どちらも失敗する場合は、ノード、ネットワーク、名前解決を調べます。比較が終わったら元のモードに戻してください。診断用の設定を日常利用で放置すると、通常は直接接続するサービスまでプロキシ経由になる場合があります。
システムプロキシが影響するのは、その設定に従うアプリ
システムプロキシは、OSが対応するプロキシ設定をローカルの待ち受けアドレスに向ける仕組みです。ブラウザーや、この設定に従うデスクトップアプリでよく使われます。一部のターミナルツール、ゲーム、独自のネットワーク機能を持つソフト、バックグラウンドサービスは自動的に設定を読み込みません。そのため、ブラウザーでは使えるのにコマンドラインでは失敗しても、ノードの異常とは限りません。ターミナルのツールが明示的なプロキシオプションに対応しているか確認し、まずは明確な入口でテストしてください。その後、環境変数やTUNで通信の接管範囲を広げる必要があるか判断します。
curl -I -x http://127.0.0.1:7890 https://example.com
curl -I --proxy socks5h://127.0.0.1:7890 https://example.com上記の2つのコマンドは、異なるプロキシ経路を使います。socks5hは接続先ドメインの名前解決をプロキシ側で行うことを示します。ツールが端末側で先に名前解決するわけではありません。その後のDNS経路は、コアの設定によって異なります。明示的なプロキシでのテストが成功したら、次にアプリ独自のプロキシ設定を確認してください。環境変数の認識方法は統一されていません。小文字の変数しか読まないツールや、独自の設定で上書きするツールもあります。1種類の環境変数設定を、すべてのコマンドラインアプリに適用できるものと考えないでください。
接続記録で通信の入口を切り分ける
接続先にアクセスしたとき、接続パネルにまったく記録が出ない場合は、まずシステムプロキシが有効か、待ち受けポートが一致しているか、アプリにプロキシを迂回する設定がないか、他のプロキシ拡張機能が動作していないかを確認します。記録はあるもののDIRECTに接続されている場合は、モードとルールを調べてください。プロキシが選ばれているのに失敗する場合は、接続エラーとリモート側の状態を確認します。画面の更新や接続時間の短さによって記録を見つけにくいこともあります。必要に応じて一時的にログを確認し、最初から詳細ログを長時間有効にするのは避けましょう。
| 症状 | まず確認する項目 | 次に行うこと |
|---|---|---|
| アプリの通信がコアに入らない | システムプロキシ、明示的なプロキシ設定、迂回設定 | プロキシ指定のリクエストと比較する |
| 通信は入るが接続先が想定と異なる | モード、ルールの順序、プロキシグループ | 適用ルールと最終ノードを記録する |
| プロキシの接続先は明確だが接続に失敗する | ノードの状態、DNS、リモート側のエラー | 別の接続先で同じ経路を検証する |
使用を終えるときは、まずシステムプロキシを無効にするか、クライアントの終了時に自動で元に戻ることを確認してから、コアを終了してください。プロセスが終了してもシステムプロキシがローカルのポートを指したままだと、その設定に従うアプリは停止済みの待ち受け先にアクセスし、広範囲で通信できなくなります。モバイル端末では、OSのVPN構成が接続中のままになっていないかも確認してください。各方式の違いはTUNモードとシステムプロキシの違いをご覧ください。「グローバルモード」と「システム全体の通信の接管」は同じ意味ではありません。
6. ルールの順序・プロキシグループ・ルールセット
最初に一致したルールで接続先が決まる
ルールは記述された順に評価され、通常は最初に一致したルールで処理方法が決まります。個別の例外は広い範囲を対象とするルールより前に置き、最後にフォールバック用のルールを置きます。DOMAINは完全一致するドメインを、DOMAIN-SUFFIXは指定したドメインとそのサブドメインを、IP-CIDRは接続先のIPアドレス範囲を照合します。MATCHは、前のルールに一致しなかった接続を処理します。ルールの種類によって必要な情報も異なるため、ドメインを判別できない接続にドメインルールだけを使っても、期待した動作にならないことがあります。
次の例は、ルールの順序とグループ参照を理解するための、単体で動作するDIRECTの設定です。リモートのプロキシ接続には対応していません。「日常の接続先」には現在DIRECTしかないため、許可された通信はすべて端末のネットワークから直接接続します。実際に利用するときは、ノードまたはプロバイダーを用意してから、該当する名称をプロキシグループに追加してください。参照するルールだけをコピーし、参照先のグループ定義を忘れないようにしましょう。コアが設定を読み込む際には、こうした名称を依存関係として解決する必要があります。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxy-groups:
- name: 日常の接続先
type: select
proxies:
- DIRECT
rules:
- DOMAIN,example.com,日常の接続先
- DOMAIN-SUFFIX,localhost,DIRECT
- IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- MATCH,日常の接続先プロキシグループはルールとノードをつなぐ安定した接点
手動選択のグループを使うと、動作を把握しやすくなります。ルールは固定のグループを参照し、ユーザーはグループ内で接続先を切り替えます。自動テストグループは測定結果をもとにノードを選べますが、テスト先、タイムアウト、測定間隔によって選択結果が変わります。測定値が主に示すのはリクエストの接続や応答状況であり、ファイルのダウンロード速度や、すべての接続先での最適性を保証するものではありません。接続先の切り替えはログイン状態やリモートセッションに影響する場合があります。頻繁な自動切り替えを避け、実際のアプリで動作を確認してください。
no-resolveは一部のIPルールで使う設定で、そのルールの判定だけを目的としたドメイン名解決を行わないことを示します。クライアント全体のDNSを無効にするものではありません。接続に宛先IPアドレスが含まれている場合は、その情報を使って照合できます。このパラメーターを追加する前に、ルールの役割を明確にしてください。すでにあるIPアドレスの接続だけを処理するのか、ドメインを解決してから判定するのかを確認します。すべてのアドレスルールに機械的に付けると、意図と異なる動作になることがあります。
ルールセットの管理と更新時の注意点
ルールプロバイダーを使うと、ルールを別ファイルやリモートソースにまとめ、メイン設定からRULE-SETで参照できます。プロバイダーの動作タイプと内容の形式が合っているか確認してください。たとえば、ドメイン一覧と従来形式のルール行は、同じ入力として扱えません。まず少量のローカルルールで検証し、その後、信頼できる配布元のルールセットを追加します。ルールセットのダウンロード失敗、古いキャッシュ、形式の不一致が疑われる場合は、メイン設定の構文チェックだけで判断せず、プロバイダーの読み込みログを確認してください。
新しいルールを追加したら、対象の接続をいったん終了して再接続し、動作を確認します。すでに確立した長時間接続は、ルールを変更してもすぐに切り替わらないことがあります。ブラウザーのキャッシュが新しいリクエストを隠す場合もあります。トラブルを調べる際は、ルール全体を貼り付けるよりも、接続先、適用ルール、グループ、ノードの4点を記録すると役立ちます。ルールを増やしても、振り分けの精度が上がるとは限りません。重複するルールが増えるほど、理解やメンテナンスが難しくなります。用途、配布元、適用順を説明できるルールだけを長期的に残しましょう。
LAN、社内ネットワーク、開発環境は、特に個別のテストが必要です。プライベートIPアドレスをDIRECTにするのは一般的ですが、ローカルサービスが独自ドメイン、分割DNS、特定のルーティングを使うこともあり、IPアドレスのルールだけでは対応できない場合があります。社内ネットワーク向けの例外を追加するときは対象をできるだけ絞り、範囲の広いドメインサフィックスで他のサービスの経路まで変えないようにしてください。ルールが反映されない場合は、ヘルプセンターで具体的な問題を調べ、個人情報を隠した適用結果を添えてください。
7. TUN・DNS・仮想ネットワークインターフェース
基本のプロキシ接続が使えることを確認してからTUNを有効にする
TUNは、仮想ネットワークインターフェースとルート設定を使って通信を受け付けます。システムプロキシに従わないアプリの通信を接管したい場合に便利です。ただし、すべての通信が必ずプロキシを通るという意味ではありません。OSのルート、除外アドレス、プロセスの権限、他のトンネル、コアの制約によって結果が変わります。有効にする前に、通常のプロキシ経由で接続先にアクセスできることを確認し、現在のネットワーク状態を記録してください。そうしないと、ノードの障害、DNSの問題、仮想ネットワークインターフェースの問題が同時に起きたとき、追加した設定の影響を切り分けにくくなります。
デスクトップクライアントでは、バックグラウンドサービスのインストールや管理者権限の取得が必要な場合があります。モバイル端末では通常、OSが提供するトンネル機能を利用します。有効化に失敗したら、まず権限とサービスの状態を確認し、その後、ネットワークインターフェースやルートのログを調べてください。会社のVPN、仮想マシンのネットワーク、コンテナブリッジ、他のプロキシトンネルがルートの優先順位を変えることもあります。テスト中は必要な通信接管ツールだけを有効にし、維持が必要な社内接続先を記録してください。リモートワークで特定のトンネルが必要な場合は、元に戻せる環境で段階的に検証しましょう。
DNSの待ち受け・上流サーバー・リダイレクトを理解する
DNS設定は、少なくとも次の3つに分けて考えます。コアがDNSサービスを提供しているか、OSやアプリの問い合わせがそのサービスに届くか、コアがどの上流サーバーを使って名前解決するか、の3点です。dns.enableを有効にしても、すべての問い合わせが自動的にコアへ送られるとは限りません。次の例はTUNとDNSの連携を説明するマージ用の断片です。既存の有効な設定に追加し、クライアント側で別の設定に上書きされないよう確認してください。すでにdnsやtunの項目がある場合は、最上位のキーを重複させず、既存の項目に統合します。
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://dns.google/dns-query
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53例にある上流DNSサーバーが利用できるかどうかは、ネットワーク環境によって異なります。すべての環境で使える標準設定とは限りません。暗号化DNSでサーバーアドレスにドメイン名を使う場合、そのサーバー自体を名前解決する必要が生じることがあります。これはブートストラップ名前解決の問題です。dns-hijackのポート指定だけでは、すべてのアプリ内蔵の暗号化DNSを捕捉できません。ブラウザーやアプリが直接確立するHTTPSのDNS接続は、DNS名を使っていても、通常の53番ポートの問い合わせに自動変換されるわけではありません。
fake-ipの役割と互換性を確認する
fake-ipモードはアプリに合成IPアドレスを返し、コアがそのアドレスとドメインの対応関係を保持します。これにより、後続の接続をドメイン名に基づいて処理できます。該当するアドレス範囲が表示されても、すぐにエラーと判断する必要はありません。ただし、LAN内の機器検出、特殊な認証、実際のIPアドレスに依存するアプリでは、例外が必要な場合があります。対象アプリで動作を確認してから例外を追加し、すべてのドメインを一律に除外しないでください。DNSモードを切り替えた後も、アプリやOSに古い結果が残ることがあります。必要に応じて再接続し、関連するキャッシュを消去してください。
DNSの検証では、名前解決の結果だけでなく、問い合わせ経路と最終的な接続先も確認してください。出口IPが想定どおりでも、名前解決の経路まで正しいとは限りません。オンラインの検査ページ1つで、すべてのアプリの動作を判断することもできません。IPv6は別経路として個別に確認する必要があります。DNSの設定を1つ無効にしても、OSのIPv6が停止するわけではありません。IPv6を使わない場合は、設定スイッチだけで全体の状態を判断せず、クライアント、OS、ネットワーク側それぞれの動作を確認しましょう。
有効にした後は、ブラウザー、ターミナル、LAN内のサービス、スリープからの復帰、ネットワーク切り替えを順にテストしてください。広範囲で通信できなくなった場合は、まずTUNを無効にして、動作確認済みのシステムプロキシ設定に戻します。その後、ログとルートを比較してください。ノード、上流DNS、ネットワークスタックを同時に変更しないでください。「接続済みなのにインターネットにアクセスできない」場合の段階的な確認方法は、接続後にWebページが開かないときの確認リストをご覧ください。高度な通信の接管を有効にする前に、元に戻せる手順を用意しておきましょう。
8. 日常のメンテナンス・バックアップ・トラブルからの復旧
アプリ・コア・サブスクリプションを個別に管理する
クライアントの更新、コアの更新、サブスクリプションの更新は、それぞれ別の操作です。クライアントの更新で画面、サービスコンポーネント、設定の生成方法が変わることがあります。コアの更新では項目への対応が増えたり、ネットワークの動作が変わったりする場合があります。サブスクリプションの更新では、ノード、ルール、プロキシグループが変更されます。問題が起きたら、直近で変更した層を確認し、すべてを一括して「アップデートの影響」と考えないようにしましょう。重要な環境では更新を同時に行わず、1つ終えるたびに基本動作をテストすると、元に戻す範囲を特定しやすくなります。
バックアップには、サブスクリプションの配布元を安全に記録したもの、カスタム上書き設定、重要なプロキシグループの選択、待ち受けポート、通信の接管方法を含めましょう。クライアントのスクリーンショットだけでは設定を復元できません。一方、データフォルダー全体をコピーすると、キャッシュ、古いサービスの状態、特定の端末に依存するパスまで含まれることがあります。必要な設定と一時データを分け、アクセス制御された場所にバックアップしてください。クラウドや別の端末と同期する前に、サブスクリプションURL、ノードの認証情報、コントロールインターフェースの情報をその同期先に保存してよいか確認しましょう。
決まった手順で異常の原因を調べる
端末のネットワーク、コアのプロセス、設定の読み込み、通信の入口、ルール判定、DNS、リモートノードの順に確認するのがおすすめです。まずプロキシを無効にして基本のネットワーク接続を確認し、その後プロキシを有効に戻して、対象のリクエストが表示されるかを調べます。通信がコアに入っているのに利用可能なポリシーがない場合は、設定とグループの参照を確認してください。ポリシーが明確なのに接続できない場合は、エラーの原因を調べます。タイムアウトは、指定された時間内に処理が完了しなかったことを示すだけで、DNS障害と決まったわけではありません。接続拒否、認証失敗、証明書エラーには、それぞれ異なる対処が必要です。
一度に変更する項目は1つにし、変更前後の接続先と結果を記録してください。たとえば、ノードの変更後に接続できるようになり、ルールとDNSは変えていないなら、接続先への経路を引き続き調べます。ルールを変更して適用結果が想定どおりになっても、タイムアウトが続くなら、問題が解決したとは言えません。トラブル記録に複雑な表は必要ありません。日時、症状、変更内容、結果の4点を残してください。断続的な問題では、記録を見返すことで、繰り返し再起動するよりも休止状態、ネットワーク切り替え、サブスクリプション更新との関連を判断しやすくなります。
応答時間とログを正しく読み取る
ノードのテスト値は、接続先を選ぶための参考情報であり、通信経路全体を評価する最終指標ではありません。テスト先が近くても、実際のサービスが別のネットワークにある場合があります。接続確立が速くても、混雑によってダウンロードが遅くなることがあります。実際の接続先の応答、連続アクセス時の安定性、必要なプロトコルを合わせて判断してください。自動測定に失敗しても、測定先にアクセスできないだけの場合があります。すぐにすべてのノードを削除しないでください。測定値の見方についてはurl-testの応答時間と実際の通信速度の違いをご覧ください。
ログの詳細度は、そのときの診断に必要な範囲にとどめます。通常は標準レベルを使い、問題を再現するときだけ一時的に詳細度を上げ、調査が終わったら元に戻してください。完全なログにはドメイン、アドレス、プログラムのパス、認証に関する情報が含まれる場合があります。公開前に必ず個人情報を隠してください。トラブルを報告するときは、クライアント名、OS、通信の接管方法、再現手順、重要なエラー行があれば十分です。設定全体を公開する必要はありません。安定して再現できる問題では、関係のない追加ルールを取り除いて、最小限の再現手順を残しましょう。
実行できる復旧手順を用意する
復旧するときは、まず直近の変更を取り消し、次にTUNを無効にして、明示的なプロキシまたはシステムプロキシでテストします。必要に応じて、以前の有効設定に戻してください。クライアントを終了してもネットワークに接続できない場合は、ネットワーク設定をすべてリセットする前に、システムプロキシの設定が残っていないか、他のトンネルが動作していないか確認しましょう。リモート管理する端末では、デフォルトルートの変更に注意してください。管理用の接続が失われるおそれがあります。OSのネットワークに影響する操作の前に、ローカルからアクセスできる方法や、別の復旧手段を用意しておきましょう。
9. 応用設定の進め方と確認リスト
設定項目を増やすのではなく、必要な問題に応じて機能を追加する
基本の手順が安定したら、応用編では次の3つを学ぶとよいでしょう。繰り返し使うルールをルールプロバイダーにまとめる、ノードの配布元をプロキシプロバイダーとして管理する、プロキシグループでアプリごとの接続先を整理する、の3つです。仕組みは一度に1つだけ追加し、日常設定に反映する前に複製した設定で検証してください。高度な項目は初期状態で必須ではありません。問題が明確で、項目の役割を理解し、結果を検証できる場合にのみ追加しましょう。暗黙の依存関係を減らすほうが、項目を増やすより長期的なメンテナンスに役立つことがあります。
プロキシプロバイダーを学ぶときは、ノード情報の取得元、キャッシュの保存先、更新のタイミング、グループからの参照方法を確認します。ルールプロバイダーでは、内容の形式と動作タイプを理解し、読み込みに失敗したときの確認方法を決めておきましょう。どちらも外部データを扱うため、設定の構文が正しくても実行時のダウンロードが成功するとは限りません。ダウンロード経路、ファイル権限、キャッシュの状態、参照名を個別に確認し、プロバイダーの問題をすべてのノードの障害と誤認しないようにしてください。
ドメイン情報を理解してからスニッフィングを検討する
接続時に宛先アドレスしかコアに届かず、ドメインルールの判定に必要な情報が得られない場合があります。対応するプロトコルや条件では、ドメインのスニッフィングによってドメイン情報を取得できます。ただし、これは汎用の復号機能ではなく、すべての接続からドメインを取得できるわけでもありません。有効にする前に、現在の問題が本当にドメイン情報の不足によるものか確認し、設定後の接続記録を観察してください。ガイドにスニッフィング設定が載っているからといって、内容をそのままコピーしないでください。アプリとの互換性、除外範囲、追加の処理負荷にも注意が必要です。
プロセスルール、インターフェースのバインド、ルートの除外も、OSの環境に合わせて使う必要があります。プロセスの識別は権限やプラットフォームの対応状況に左右され、バックグラウンドサービスのプロセスは画面上のアプリと異なる場合があります。プロセスごとに接続先を設定する場合は、実際のプロセス情報を確認してからルールを追加してください。画面上の表示名だけで、照合するパスを判断することはできません。仮想マシン、コンテナ、LAN内の端末にプロキシを提供する場合は、転送、アクセス制御、DNSの問い合わせ元も考慮してください。これは単一端末のブラウザープロキシの範囲を超えます。
設定の運用にセキュリティ境界を組み込む
コントロールインターフェース、LAN内の待ち受け、リモートサブスクリプションは、いずれも用途を明確にしてください。端末内だけで操作する場合は、ローカルアドレスにバインドしたままにします。別の端末からアクセスする必要がある場合は、認証、許可する接続元、OSのファイアウォールを設計してください。デバッグを簡単にするためだけに、すべての待ち受けを全ネットワークインターフェースに公開し、その状態を長期間維持しないでください。設定リポジトリや問い合わせへの添付ファイルも、公開する情報を最小限にします。公開してよい構成や匿名化した例だけを共有し、実際のサブスクリプション、認証情報、アクセス記録全体は公開しないでください。サンプル設定と本番設定は分けて保管しましょう。
応用設定の検証では、Webサイトが開くかだけでなく、DIRECTにすべき社内ネットワーク、アプリのログイン、ファイル転送、スリープからの復帰、ネットワーク切り替えも確認します。ルールを更新したら、新たな誤判定が起きていないかを確認してください。ノードの切り替え後は、長時間接続の再確立が必要かも調べます。モバイル端末では、バックグラウンド動作やバッテリー制御が接続に与える影響も確認しましょう。環境によって制約は異なります。デスクトップPCで一度成功したからといって、すべての端末で同じ動作になるとは限りません。
| 段階 | 完了条件 | 記録しておく情報 |
|---|---|---|
| 基本接続 | 明示した入口から接続先にアクセスできる | 待ち受けポートと接続記録 |
| ルールによる振り分け | DIRECTとプロキシの接続先がそれぞれ想定した経路を通る | ルール、プロキシグループ、最終ノード |
| TUNとDNS | 対象アプリとLAN内サービスが想定どおりに動作する | 通信の接管方法、名前解決の経路、例外設定 |
| メンテナンスと復旧 | 更新失敗や設定エラーの後に元へ戻せる | 有効設定のバックアップと復旧手順 |
この手順を終えたら、リクエストが失敗したときに、アプリが通信に入る入口、ルール、名前解決、接続先を順にたどって原因を調べられるようになります。何度も再インストールする必要はありません。新しいガイドを読むときは、対象のクライアント、コア、OSを確認してから、現在の環境で使える設定を判断してください。初回接続の手順を確認し直す場合は入門ガイドに戻ってください。具体的な症状から調べる場合はヘルプセンターをご利用ください。説明できて、復旧できるシンプルな有効設定を保管し、今後の検証の基準にしましょう。