V2Ray完全ガイド：クライアント・ルーティング・TUN

01 / concepts

基本概念：まず通信経路を図にする

クライアント、コア、設定ファイルの役割

V2Rayで混同しやすいのは、グラフィカルクライアント、プロキシコア、設定データの3つです。v2rayN、v2rayNG、v2flyNGはグラフィカルクライアントに分類され、サブスクリプションの取り込み、ノード選択、システムプロキシ、ルーティング規則、実行ログなどの操作画面を提供します。Xray、V2Flyなどのコアは、接続、プロトコル、トランスポート、ルーティングを実際に処理します。設定ファイルは、待受ポート、アウトバウンドのパラメーター、ドメイン規則、DNSポリシーをコアに渡します。画面上の切り替えは通常、複数の設定項目に変換され、コアが再読み込みします。

そのため、トラブル対処では「クライアントが起動しているか」だけを確認してはいけません。より正確な順序は、設定が存在するか、現在の設定が選択されているか、コアが正常に読み込まれたか、ローカルのインバウンドポートが待ち受けを開始したか、アプリの通信がそのポートに入っているか、ルーティング規則が正しいアウトバウンドを選んだか、リモート接続が完了したか、です。どこか1つが途切れるだけでも、ブラウザーではアクセス不能に見えますが、必要な修正はそれぞれ異なります。この経路を把握することが、以降の全章における判断の基礎になります。

inbounds、outbounds、routingの関係

inboundsは通信がコアに入る方法を定義します。デスクトップクライアントでは、ローカルのSOCKSとHTTPの待受ポートが一般的です。TUNを有効にすると、システムのネットワーク層からの通信を受け取る仮想入口も追加されます。outboundsは通信がどこから出ていくかを定義し、リモート設定、直接接続、遮断用のアウトバウンドなどを指定できます。routingはその間に位置し、ドメイン、IP、ポート、プロトコル、インバウンドタグなどに基づいて使用するアウトバウンドを判断します。

リクエストは「アプリ → ローカルインバウンド → ルーティング判定 → 目的のアウトバウンド」と考えると分かりやすくなります。たとえばブラウザーにSOCKSポートを設定すると、リクエストはいったんローカルの待受ポートに入ります。ルーティング規則が対象を直接接続の集合と判定すれば、directアウトバウンドへ渡されます。それ以外は現在のリモートアウトバウンドへ渡されます。規則で使うtagは各要素をつなぐ識別子です。名前は自由に付けられますが、参照先は一致していなければなりません。outboundTag: "direct"と記述するなら、設定にはdirectというタグのアウトバウンドが必要です。

{
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

設定、ノード、サブスクリプションは別のもの

1つのノードは、通常、サーバーアドレス、ポート、ユーザー識別子、プロトコル、トランスポート設定などの接続パラメーターで構成されます。サブスクリプションは更新可能なデータソースで、複数のノードやグループ情報を返すことがあります。クライアント設定はさらに広く、ノードだけでなくローカルポート、プロキシモード、DNS、ルーティング、ログ、画面設定も含みます。サブスクリプションを削除しても、生成済みのローカル設定が直ちに消えるとは限りません。ノードを切り替えても、システムプロキシモードが自動で変わるわけではありません。操作前に、対象がサブスクリプションのソース、設定一覧、現在の実行インスタンスのどれなのかを確認してください。

設定を項目単位で理解したい場合は、config.jsonの構造を項目ごとに解説した記事も参照してください。インバウンド、アウトバウンド、ルーティングタグを、最小構成の設定で比較しながら説明しています。

02 / client and install

クライアントの選択と導入：プラットフォームを合わせて動作条件を確認

3つのクライアントの使い分け

デスクトップではv2rayNが第一候補です。Windows、macOS、Linuxに対応し、設定一覧、サブスクリプション管理、システムプロキシ、ルーティング、TUNなどの主要機能を共通の導線で利用できます。Windowsのダウンロードページにはデスクトップ版とクラシックWPF版があります。デスクトップ版はクロスプラットフォームのUIを採用し、異なるデスクトップ環境でも近い操作感を保ちたいユーザーに向いています。WPF版はWindowsの従来の操作習慣を重視し、画面とシステム連携がより集約されています。主な違いはUIフレームワークとシステムへの適応であり、ノードのプロトコル性能を単純に比較するものではありません。

Androidではv2rayNGが第一候補です。Xrayコアを使用し、一般的なサブスクリプション、アプリ別プロキシ、ルーティング、接続テストを画面上で完了できます。v2flyNGはV2Flyコアを使用するため、その実装が必要な場合の選択肢になります。2つのAndroidクライアントは設定一覧を共有しないため、切り替える場合はサブスクリプションまたは設定を再度取り込む必要があります。一方のクライアントが生成した内部データベースを、もう一方へ直接コピーしないでください。移行には、汎用的なサブスクリプションリンク、共有リンク、標準設定のほうが適しています。

導入前にシステムアーキテクチャと旧インスタンスを確認

ダウンロード前に、プロセッサーのアーキテクチャとOSの種類を確認します。macOSでは「このMacについて」でチップ名を確認できます。Linuxではuname -mを実行し、x86_64はx64、aarch64はarm64に対応します。近年のAndroid端末は通常arm64ですが、アーキテクチャが分からない場合はユニバーサルパッケージを選べます。パッケージのアーキテクチャが合わないと、起動できない、インストーラーが実行を拒否する、起動直後に終了するといった症状が出ます。この種の問題をノードパラメーターの変更で解決しようとしてはいけません。

アップグレードまたはUI版の変更前に、実行中の古いインスタンスを終了します。デスクトップクライアントはトレイプロセスを保持することがあり、メインウィンドウを閉じてもプロセスが終了したとは限りません。トレイメニューから終了するか、システムのタスク管理ツールでプロセスが停止したことを確認してください。古いインスタンスがローカルポートを使用中の場合、新しいインスタンスはログに待受失敗を記録します。既存のサブスクリプションURL、ルーティング規則、カスタムポートを記録してから移行すると、導入後にどの設定が旧環境由来かを判断しやすくなります。

初回起動後に行う最小限の確認

初めてクライアントを開いたときは、システムプロキシとTUNを同時に有効にしないでください。正しい順序は、画面が正常に動作することを確認し、設定を1つ取り込み、その設定を選択してコアを起動し、ログにローカル待受成功が出ることを確認してから、システムプロキシを有効にしてテストすることです。段階的に進めれば、「プログラムの起動問題」と「ネットワークの取り込み問題」を分けられます。Windowsで実行環境の案内が出た場合は、クライアントページに示されたランタイムを追加してください。Linuxでは導入後にメニュー項目が表示されなければ、一度ターミナルから起動してエラーを確認します。macOSでは初回起動時に、システムのセキュリティ設定でアプリの実行が許可されているか確認します。

インストールが完了しても、プロキシが有効になったとは限りません。クライアントの起動、コアの実行、システムプロキシの有効化は別々の状態です。画面を開いただけで設定を起動していなければ、ローカルポートは待ち受けません。コアが動作していてもシステムプロキシが無効なら、手動でプロキシを指定したアプリだけがクライアントを利用します。システムプロキシが設定済みでもコアが停止していれば、アプリはサービスのないポートへリクエストを送ります。この3つの状態を理解すると、導入の問題をリモート接続の問題と誤認しにくくなります。

Windowsでより詳しい導入手順と実行環境の対処を確認するには、Windowsにv2rayNを導入する全手順を参照してください。2つのUI版の選び方は、v2rayNデスクトップ版とクラシックWPF版の違いで比較しています。

03 / subscription

サブスクリプションと設定管理：取り込み、更新、選択、実行を分ける

サブスクリプション取り込み後の4つの操作

サブスクリプションの追加は、通常、クライアントにデータソースを保存するだけです。完全な流れは、サブスクリプション情報の保存、サブスクリプションの更新、結果からの設定選択、選択した設定の起動という4つの独立した操作で構成されます。保存後すぐに更新するクライアントもあれば、手動で「サブスクリプションを更新」する必要があるクライアントもあります。追加に成功したのに設定一覧が空の場合は、すぐに削除して再追加せず、まず更新を実行したか確認してください。更新後は現在のグループとフィルター条件も確認し、設定が存在するのに一覧で非表示になっていないか確かめます。

サブスクリプション名はローカルで識別するためだけのもので、接続には関与しません。用途と提供元を区別できる短い名前を使い、日付を名前に入れて頻繁に変更するのは避けるとよいでしょう。複数のサブスクリプションがある場合、名前から更新範囲を判断できるようにします。更新によって、そのサブスクリプションから生成された古い設定が置き換えられ、手動で変更したノードパラメーターも次回更新で上書きされる可能性があります。長期的に残したい変更は、クライアントのルーティング、DNS、全体設定に保存してください。1つの設定だけを変更する場合は、まずローカル項目として複製し、用途を明記します。

サブスクリプション更新時に現在の動作状態を守る方法

更新前に、現在の設定名と動作状態を確認します。更新後、固有識別子に基づいて選択状態が維持される場合もあれば、設定の置き換えによって別の項目に戻る場合もあります。最も安全なのは、更新後に現在の設定を再確認し、接続テストをもう一度行うことです。サブスクリプションが空の内容を返した場合は、すべての設定を連続して上書き・削除しないでください。まずクライアントログのHTTPステータス、レスポンス形式、解析メッセージを確認し、前回動作した設定を比較用に残します。

更新失敗は、「アドレスにリクエストできない」「リクエストは成功したが内容を解析できない」「解析できたが利用可能な設定がない」の3種類に分けられます。1つ目ではネットワーク経路、システム時刻、サブスクリプションURLの完全性を確認します。2つ目では、返された内容がクライアント対応のサブスクリプション形式か、ウェブページのURLをサブスクリプションURLとして指定していないかを確認します。3つ目では、サブスクリプションのグループ、フィルター規則、クライアントとコアの互換性を確認します。ログにリクエスト成功と解析数0が出ているなら、プロキシモードを何度も変えても効果は薄く、サブスクリプションの内容と形式を見直すべきです。

共有リンク、JSON設定、サブスクリプションの使い分け

単一の共有リンクは、1つの設定を取り込み、アドレス、ポート、トランスポート設定を個別に確認するのに適しています。JSON設定は、インバウンド、アウトバウンド、ルーティング、DNSを完全に制御したい場合に向いています。サブスクリプションは、同じ提供元が複数の設定を管理し、定期的に更新する場合に適しています。3つを併用することはできますが、複数のソースから同じ名前の設定を生成しないようにしてください。切り替え時にどれが実行中なのか分かりにくくなります。

JSONを手動で取り込む前に、それが完全なコア設定なのか、クライアントが認識できる設定の一部なのかを確認します。完全な設定には通常、inbounds、outboundsなどのトップレベル項目が含まれます。一方、共有リンクは1つのアウトバウンド接続だけを記述します。グラフィカルクライアントは、自身の設定に基づいてインバウンドやルーティングを再生成することがあるため、実行時に生成された一時ファイルを直接編集しても、次回起動時に上書きされることが多いです。永続化したい設定は、クライアントの画面、自動設定の入口、または明確な設定ファイル管理機能から行ってください。

サブスクリプションデータを扱う際の基本ルール

サブスクリプションURLにはアクセス識別子が含まれることがあるため、使用するクライアント内だけに保存し、公開ページ、ログのスクリーンショット、共有ドキュメントに掲載しないでください。診断のためにログを見せる場合は、完全なサブスクリプションURL、サーバーアドレス、ユーザー識別子を隠し、エラー種別、ステータスコード、発生順序だけを残します。クライアントのエクスポート機能にも接続パラメーターが含まれる場合があるため、送信前に範囲を確認してください。

日常の運用では、サブスクリプション更新とクライアントのアップグレードを分けて実行します。まず現在のクライアント環境で更新を検証してからアップグレードするか、先にクライアントをアップグレードして既存設定が動くことを確認してから更新します。2つの変数を同時に変えると、互換性の問題が出た際に、パーサー、コア、サブスクリプション内容のどれが原因か判断しにくくなります。安定したメンテナンスの要点は、頻繁に操作することではなく、1回の変更に明確な目的を1つだけ持たせることです。

04 / proxy mode

プロキシモードとローカルポート：クライアントを利用するアプリを決める

システムプロキシ、手動プロキシ、TUNの適用範囲

システムプロキシは、デスクトップで最初の動作確認を行うのに最も適したモードです。v2rayNはシステムプロキシのアドレスをローカルの待受ポートに設定し、システムプロキシに従うブラウザーやアプリのリクエストをクライアントへ渡します。動作が分かりやすく、無効化も簡単なのが利点です。一方、一部のアプリはシステムプロキシを読み込まず、コマンドラインツールや独立した実行環境が独自のプロキシ設定を使うこともあります。「ブラウザーは使えるが特定のアプリは使えない」場合は、まずそのアプリがシステムプロキシに対応しているか確認し、設定全体が無効だと決めつけないでください。

手動プロキシは、対象を絞ったテストに適しています。ブラウザー、開発ツール、コマンドラインプロセスに127.0.0.1とSOCKS/HTTPポートを明示的に入力できます。他のアプリには自動適用されないため、ローカルインバウンドが動作しているかを判断しやすくなります。TUNはシステムのネットワーク層に近く、明示的なプロキシに対応しない通信も受け取れますが、仮想NIC、ルーティングテーブル、DNSの取り込み、権限に関する問題が増えます。まずシステムプロキシで接続を確立し、その後TUNへ進むのが適切です。初回接続からTUNを既定のスイッチとして使うべきではありません。

SOCKSとHTTPのポートの選び方

SOCKSインバウンドはTCPを処理でき、設定が許可していればUDPにも対応します。HTTPプロキシは主にHTTP CONNECTに対応するアプリ向けです。クライアントが2つのローカルポートを同時に作成する場合や、混合インバウンドを提供する場合もあります。アプリのプロキシ設定では、プロトコルとポートを必ず対応させてください。SOCKSポートをHTTPプロキシ専用の項目に入力すると、接続失敗やプロトコルエラーになります。逆の場合も同じです。ポート番号に固定の正解はなく、クライアントの実際の待受値、システムプロキシの値、アプリの設定が一致していることが重要です。

ローカルの待受アドレスは通常127.0.0.1に設定し、本機からの接続だけを受け付けます。同じLAN上の別端末から接続する明確な理由がある場合だけ、LAN接続を許可することを検討し、システムファイアウォールとアクセス範囲も同時に確認してください。LAN待受を開放するなら、アドレスだけを変更して認証やネットワーク範囲を無視してはいけません。一般的な単体利用では、本機待受を維持するほうが管理しやすく、LAN環境の変化が切り分けに与える影響も抑えられます。

ポート競合と残留したシステムプロキシ

コアの起動時にアドレスが使用中と表示される場合、待ち受け予定のポートを別のプロセスが使用しています。まず古いクライアントのインスタンスを終了し、使用中のプロセスを調べます。Windowsではnetstat -ano | findstr :10808を実行してプロセスIDを確認できます。macOSではlsof -nP -iTCP:10808 -sTCP:LISTEN、Linuxではss -lntp | grep 10808を実行します。プロセスの用途を確認してから終了するか、クライアントのポートを変更してください。使用中だからといって、正体不明のシステムサービスをすぐ終了してはいけません。

netstat -ano | findstr :10808
lsof -nP -iTCP:10808 -sTCP:LISTEN
ss -lntp | grep 10808

ポートを変更したら、システムプロキシやアプリ側のプロキシポートも同じように変更します。クライアントの待受値だけを変更して古いシステムプロキシを残すと、「クライアントは動作しているのに、アプリは古いポートへ接続する」状態になります。クライアントが異常終了すると、システムプロキシだけが残ることもあります。その場合、コアが停止していてもブラウザーはローカルプロキシへ接続し続けます。クライアントを再度開いてシステムプロキシを無効にするか、システムのネットワーク設定から手動で元に戻してください。詳しい切り分けはポート競合の調査と変更方法を参照してください。

05 / routing

ルーティング：規則で通信ごとの出口を決める

規則の数より、マッチング順序が重要

ルーティング規則は通常、上から順に評価され、マッチすると指定されたアウトバウンドへ渡されます。規則が多いほど正確になるわけではありません。重要なのは、条件が重複していないか、優先順位が適切か、フォールバック先が明確かです。具体的な規則は、広い規則より前に置きます。たとえば、あるドメインがカスタムの直接接続リストにも、後方の汎用プロキシ規則にも該当するなら、カスタム規則を先に置きます。クライアントにプリセットのルーティングモードがある場合は、目的に近いプリセットを選び、少数のカスタム規則を追加するほうが、白紙から大量の集合を積み上げるより保守しやすくなります。

一般的な条件には、ドメイン、IP、ポート、ネットワーク種別、プロトコル、インバウンドタグがあります。ドメイン規則は完全なドメイン名、サフィックス、GeoSite分類に適しています。IP規則はプライベートアドレスやGeoIP分類に適しています。ポート規則は特定のサービスに、インバウンドタグはローカル入口ごとに異なるポリシーを適用する場合に便利です。ドメイン条件と、最終的に解決されたIP条件を完全に同じものと考えないでください。ルーティング段階でドメイン名が保持されるかどうかは、DNSの流れとdomainStrategy設定に左右されます。

direct、proxy、blockの3種類の出口

読みやすいルーティングでは、少なくとも3つの結果を区別します。directは直接接続、proxyは現在のリモートアウトバウンドへ渡すこと、blockは遮断を意味します。名前は単なるタグで、実際の動作は対応するアウトバウンドのプロトコルによって決まります。規則でタグを参照する場合は、アウトバウンドのタグと一字一句一致させてください。画面で「直接接続」「プロキシ」「遮断」を選べる場合、タグの管理はクライアントが行います。JSONを手書きする場合は、参照関係を自分で保証する必要があります。

プライベートアドレスは通常、ルーター、プリンター、LANサービスへのアクセスがリモートアウトバウンド経由にならないよう、直接接続を優先します。遮断したい通信には明確な条件を使い、広すぎるドメインキーワードは避けてください。最後に、理解しやすいフォールバックを残します。規則に一致しない通信を既定でプロキシ経由にするのか直接接続にするのかを、現在のクライアントモードと一致させます。トラブル対処では、一時的に単純なグローバル設定へ切り替えて、原因がルーティングにあるか確認できます。検証後は分流へ戻し、一時モードを常用しないでください。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "protocol": ["bittorrent"],
        "outboundTag": "direct"
      }
    ]
  }
}

domainStrategyとDNSの組み合わせ

AsIsは、ルーティングに入ったドメイン名をそのまま照合する傾向があり、IP規則のために追加の名前解決を行いません。IPIfNonMatchはドメイン規則に一致しなかった場合に解決を試み、その後IP規則を評価します。IPOnDemandはIPが必要になる可能性のある規則に遭遇したとき、より積極的に解決します。どれを選ぶかは規則の構成次第です。ドメイン規則が中心ならAsIsのほうが分かりやすく、GeoIP条件を多用するならIPIfNonMatchのほうがIP規則を評価しやすい一方、DNS結果への依存も増えます。

DNSとルーティングは一体で動作します。DNSリクエスト自体にも出口を選ぶ必要があり、解決結果は後続のルーティングにも影響します。ドメイン解決が不適切なネットワーク経路を通ると、到達できないアドレスが返ることがあります。IPでの判定が必要なのに有効な解決結果を得られなければ、規則は期待どおりに一致しません。切り分けでは、「どこがドメインを解決したか」「DNSリクエストがどのアウトバウンドから出たか」「結果がどのルーティング規則に入ったか」を個別に記録してください。DNSアドレスだけを変え、出口経路を無視しないことが重要です。

GeoIPとGeoSiteの更新範囲

GeoIPはIPアドレスを、GeoSiteはドメインの集合を分類します。どちらのデータベースも古くなると、新しいドメインやアドレス帯が想定した分類に入らないことがあります。更新後に分流が突然変わった場合は、データベースのバージョン変更による分類調整を確認し、すぐにコアの異常と判断しないでください。優先度の高いカスタム規則は少数に抑え、追加理由を記録します。データベースの更新で対象をカバーできるようになったら、重複する規則を削除して競合を防ぎます。

データベースの役割、更新場所、確認方法はGeoIP・GeoSiteデータベース更新ガイドで説明しています。複数クライアントのルーティング機能と対応プラットフォームを比較する場合は、クライアント比較も確認できます。

06 / tun

TUNモード：システムプロキシからネットワーク層の取り込みへ

TUNを有効にするタイミング

TUNモードは仮想ネットワークインターフェースでシステム通信を受け取るため、システムプロキシを読み込まないアプリ、UDPが必要なプログラム、アプリごとの設定を減らしたいデスクトップ環境に適しています。ただし、接続品質を高めるスイッチではなく、誤ったリモートパラメーターを自動修正する機能でもありません。システムプロキシで基本的なページすら開けない場合は、まず設定、ポート、DNS、リモート接続の問題を解決してからTUNを有効にしてください。そうしないと、追加されたルーティングテーブルと仮想NICが切り分けの変数を増やすだけになります。

有効化する前に、3つの基準テストを完了します。現在の設定が起動できること、システムプロキシで少なくとも1つのアプリが安定してアクセスできること、クライアントログに接続または解決の継続的なエラーがないことです。その後、システムプロキシを無効にするか、クライアント推奨の方法で両者の関係を整理してからTUNを有効にします。テストではまず既定のネットワークスタックとMTUを維持し、DNS、厳格ルーティング、バイパス規則、NICパラメーターを同時に変更しないでください。既定設定に具体的な問題があると確認できた場合だけ、該当項目を調整します。

仮想NIC、ルーティングテーブル、権限

TUNは仮想ネットワークインターフェースを作成し、システムのルーティングを変更するため、デスクトップ環境では通常、適切な権限が必要です。権限が不足すると、仮想NICの作成失敗、ルート追加の失敗、クライアント上では有効に見えるのに通信が入らない、といった症状が出ます。クライアントログで失敗した手順を特定し、OSの権限モデルに従って対処してください。スイッチを何度も押すと、一時的なインターフェースや残留ルートが複数残り、症状が複雑になることがあります。

ルーティングテーブルは、どの宛先を仮想NICへ入れるかを決めます。バイパス規則は、LAN、特定アドレス、指定アプリを元の経路に残します。厳格ルーティングを有効にすると、明示的に処理されていない迂回通信をOSが阻止する場合があります。経路の一貫性には役立ちますが、ローカル開発環境、仮想マシン、LANサービスに影響することもあります。有効化後にLAN機器へアクセスできなくなったら、まずプライベートアドレスのバイパスとdirect規則を確認し、すべての分流を無効にしないでください。

MTU、ネットワークスタック、UDPの問題

MTUはインターフェースが扱えるパケットサイズを示します。値が大きすぎると、一部の経路で正しく分割できず、小さなページは開けるのに大きなファイルや特定サイトで停止することがあります。小さすぎると分割のオーバーヘッドが増えます。明確な根拠がない場合は、クライアントの既定値を維持してください。MTUを疑う場合は、異なるネットワーク環境で比較し、大きなレスポンスや特定プロトコルだけで再現するか観察します。その後、少しずつ下げてテストし、変更値と結果を毎回記録します。

TUNのネットワークスタックには、互換性、性能、システム統合の方法に違いがあります。まずクライアント推奨の既定項目を使い、UDP、スリープ復帰、仮想化との競合など、具体的な問題がある場合だけ切り替えてください。スタックを変更したらTUNを再起動し、古い仮想インターフェースが削除されていることを確認します。AndroidのVPNによる取り込みはシステムが提供します。v2rayNGとv2flyNGは接続開始時に必要な権限を要求します。端末上ですでに同種の取り込み機能を使うアプリが動作している場合、同時実行が競合することがあります。

DNS漏洩と誤認しないための解析経路確認

TUNを有効にすると、DNSリクエストをクライアントが取り込む場合もあれば、システムのネットワークインターフェースから送信し続ける場合もあります。これはクライアント設定によって異なります。よくある症状は、ドメインでは開けないのに既知のIPへ直接アクセスすると応答があるケースです。この場合はリモートプロトコルより先にDNSを確認します。DNSが結果を返していても、その結果が誤った出口を通ることがあります。切り分けではDNSログ、ルーティングの一致、接続ログを同時に確認し、3者の時刻が対応しているかを見ます。

LAN内の一部ドメインがローカルDNSを必要とする場合は、そのドメインにローカルの名前解決経路を残し、パブリックドメインは既定のポリシーで解決します。1台のDNSサーバーですべてを処理し、大量の固定アドレスで後から補修する方法は避けてください。企業ネットワーク、家庭内LAN、公衆ネットワークを切り替えると、ローカルDNSへの到達性も変わります。そのため、モバイル端末やノートPCではネットワーク切り替え後の復旧動作を重点的に確認します。

TUNを有効にした直後にシステム全体が接続不能になった場合は、まずTUNを無効にして既定ルートを復元し、ログで権限、インターフェース、ルート追加のエラーを確認します。ネットワークが完全に切れている状態でDNSや分流の変更を重ねないでください。復旧経路が追跡しにくくなります。

07 / maintenance

日常のメンテナンスとトラブルの切り分け：層ごとに証拠を集める

再現可能なメンテナンス手順を作る

安定運用には、元に戻せる変更手順が必要です。クライアントのアップグレード、コアの更新、サブスクリプション更新、ルーティングデータベースの更新、システムネットワークの変更は分けて実行します。各変更の前に、クライアントの種類、選択中の設定、ローカルポート、プロキシモード、ルーティングプリセット、DNSポリシーを記録し、変更後は同じチェックリストで確認します。これにより、異常が出ても変更前後の差分を明確に比較できます。

サブスクリプションは実際の変更頻度に応じて更新すればよく、起動するたびに繰り返し更新する必要はありません。GeoIPとGeoSiteは、分流で明らかな分類ずれが出た場合や、保守計画に沿って更新します。クライアントのアップグレード前には画面の移行案内を読み、設定の保存場所と権限要件に変更がないか確認してください。更新後はまず既存設定で動作を検証し、その後に新機能を導入します。アップグレードと設定の再構成を同時に行うと、明確なロールバックポイントを失います。

ログから障害の層を判断する

ログは時系列で読みます。起動時は設定解析、ポート待受、コアプロセス、TUNインターフェースを確認します。接続時は名前解決、ルーティングの一致、アウトバウンドの発信、ハンドシェイクを確認します。動作中はタイムアウト、接続リセット、ネットワーク切り替えを確認します。最初に出た重要なエラーは、その後に繰り返されるエラーより価値があります。後続の失敗は、前の段階が中断した結果にすぎないことが多いためです。

設定解析エラーには、項目のパスやJSONの行・列位置が含まれることがあります。まず構文と項目の型を修正してください。待受エラーは通常、ポート競合または権限を示します。解決エラーはDNS経路を示します。接続タイムアウトは、リクエストが本機から出ようとしたものの、対象経路が制限時間内に完了しなかったことを意味します。ハンドシェイクエラーでは、プロトコル、トランスポート、時刻を確認します。ログの最後の1行だけを切り出さず、診断時には起動前後と完全なリクエスト1回分に対応する連続したログを残してください。

すべての設定を同時にリセットせず、最小構成で再現する

再現環境はできるだけ単純にします。既知の設定を1つ選び、既定のローカルポートを使い、カスタムルーティングを無効にし、TUNは有効にせず、システムプロキシまたは1つのアプリへの手動プロキシだけを残します。最小構成で使えるなら、DNS、ルーティング、TUN、アプリ規則を1つずつ戻します。最小構成でも失敗するなら、設定パラメーター、システム時刻、ポート、ネットワーク経路に集中して確認します。こうすれば、複雑な問題を限られた手順に分解できます。

「既定値に戻す」は設定の混入を確認するのに役立ちますが、実行前に現在の設定を記録してください。すべての設定を直接消去すると比較対象を失い、まだ使えるサブスクリプション情報まで削除する可能性があります。独立したテスト設定を作るか、クライアントのバックアップ・複製機能を使うほうが安全です。テスト後は、有効性を確認した変更を、変更項目、理由、検証方法、復旧方法とともに記録します。長文である必要はありませんが、次回の障害時に判断過程を再現できる内容にしてください。

ネットワーク切り替え、スリープ、システム更新後の確認

ノートPCを別のネットワークへ切り替えると、古いDNS、仮想NICの状態、ルーティングキャッシュが一時的に残ることがあります。切り替え後に接続が不安定になったら、現在の設定を停止して再起動します。TUNを使っている場合は、仮想インターフェースも再構築してください。スリープ復帰後、クライアント画面には動作中と表示されていても、基盤のネットワークインターフェースが変わっていることがあります。画面の状態ではなく、新しいリクエストのログで判断します。

システム更新後に問題が出た場合は、ファイアウォールの権限、仮想NICドライバーの状態、システムプロキシがリセットされていないか、クライアントにネットワークインターフェースを作成する権限が残っているかを確認します。Android端末では、ネットワーク切り替え後に接続を停止して再起動し、現在のネットワーク経路に必要な権限をシステムから再取得させます。どのプラットフォームでも、問題を安定して再現できていない段階で複数の設定を次々と変更しないでください。システム状態の変化と設定差分が混ざってしまいます。

08 / advanced route

上級設定への進め方：画面操作から保守可能な規則へ

第1段階：現在の設定を説明できるようにする

上級設定とは、最初から項目を増やすことではなく、現在の設定を説明できることです。どのインバウンドがあり、それぞれどのアドレスとポートを待ち受けているか、既定のアウトバウンドはどれか、directとblockがどう定義されているか、ルーティング規則がどの順序で評価されるか、DNSリクエストがどこから送信されるかを明確にします。クライアントからエクスポートした設定や実行ログで項目ごとに確認できますが、一時生成ファイルを直接編集しないでください。まず画面上の選択肢と最終的な項目の対応関係を把握すれば、クライアントのアップグレード後に動作が変わった理由を判断できるようになります。

自分用の通信経路表を作ることをおすすめします。項目は、アプリ名、通信の入り方、インバウンドタグ、適用規則、目的のアウトバウンド、DNS経路です。各列には、設定またはログから根拠を示せるようにします。感覚だけで埋める列があるなら、その部分はまだ検証が必要です。ここまで終えてから、アプリ別設定、複数入口、複数出口などの複雑な構成に進むと、規則が増えても説明可能性を保てます。

第2段階：タグで複数の入口と出口を整理する

複数の入口は、アプリや用途を分離したい場合に適しています。たとえば、ブラウザー用のSOCKSインバウンドと開発ツール用の別インバウンドを用意し、inboundTagで異なるアウトバウンドへ振り分けられます。複数の出口では、direct、block、複数のリモート接続を組み合わせられます。タグ名は役割を表すものにし、socks-browser、direct、blockのように命名します。思い出しにくい一時的な番号は避けてください。タグ名を変更するときは、すべての参照も同時に更新します。

複数の出口があるからといって、複雑な自動選択が必要とは限りません。まず明確な静的規則を作り、通信の種類ごとに想定した出口へ安定して入ることを確認してから、フェイルオーバーや負荷分散を検討します。自動戦略はヘルスチェック、接続状態、コアの機能に依存し、障害時に必要なログも増えます。基本ルーティングが安定していない状態で自動戦略を追加すると、実際の出口が予測しにくくなるだけです。

第3段階：DNSを独立したサブシステムとして管理する

複雑な設定でDNSを単なるサーバーアドレスとして扱うべきではありません。問い合わせの種類、ドメイン分類、解決に使う出口、キャッシュ動作、フォールバック条件を明確にします。LAN内ドメインにはローカルDNSが必要な場合があり、パブリックドメインはルーティングポリシーに応じて解決経路を選べます。特定のドメインに専用規則を使うこともできます。分割には実際の要件を持たせ、項目があるからといってすべてを有効にしないでください。

DNSを検証するときは、まずどの層がリクエストを発行したかを確認し、次に返されたアドレスが想定どおりか、そのアドレスがどのルーティングを通ったかを確認します。解決結果だけを見ると問い合わせの出口による経路差を見落とし、ルーティングだけを見ると誤ったアドレスによる接続失敗を分流の問題と誤認する可能性があります。DNSの調整はGeoIPやGeoSiteの更新と分けて行い、1回の変更で変える判断材料を1つに保ちます。

第4段階：設定変更とロールバックのルールを作る

長期運用する設定には、読みやすい注記を残します。ただし標準JSONはコメントを受け付けないため、注記は別の説明ドキュメント、クライアントのメモ、変更履歴に記録します。変更ごとに目的、変更前の値、変更後の値、検証結果、復旧手順を残してください。特にルーティング規則には「なぜ存在するのか」を記録します。そうしないと、数か月後に古い規則を必須条件と誤認しやすくなります。

設定のバックアップには、サブスクリプション名、カスタムルーティング、DNS、待受ポート、TUNオプションを含めます。ただし保存場所へのアクセス範囲は制限してください。復元時に古い状態を一度にすべて取り込まず、まずサブスクリプションと基本設定を戻して動作を確認し、その後にルーティングとTUNを復元します。プラットフォームをまたぐ移行では共通するロジックだけを移し、システムプロキシ、仮想NIC、権限設定をそのままコピーできるとは考えないでください。

第5段階：固定の検証チェックリストを作る

完全な検証チェックリストには、クライアントが正常に起動すること、コア設定の読み込みに成功すること、ローカルポートが待ち受け中であること、システムプロキシまたはTUNの状態が想定どおりであること、ドメイン解決が使えること、プライベートアドレスが直接接続されること、指定ドメインが想定した規則に一致すること、ネットワーク切り替え後に復旧できること、クライアント終了後にシステムプロキシと仮想インターフェースが正しく解除されることを含めます。各項目には「ネットワーク正常」とだけ書かず、具体的な確認方法を記載してください。

新しい問題が起きたら、まず症状を設定、インバウンド、DNS、ルーティング、アウトバウンド、システムによる取り込みのいずれかに分類し、本ガイドの該当章を確認します。クイックスタートは入門ガイドに戻り、パッケージを選び直す場合はクライアントのダウンロードページへ進みます。クライアントごとの機能差はクライアント比較で確認できます。設定構造、ポート競合、ルーティングデータベースに関する問題は、本文中の各関連記事を使ってさらに切り分けてください。