V2Ray 詳細設定ガイド

1. サブスクリプションのグループ分けとサーバーの絞り込み

サブスクリプションはサーバー設定の取得元で、グループは取得元や項目をクライアント上で整理するためのものです。両者は分けて考えましょう。サーバー一覧にグループが表示されていても、そのグループがルーティングルールで使われているとは限りません。また、グループを表示しているだけでは、そこにあるサーバーが使用中とは限りません。整理を始める前に、選択中のサーバー、所属するサブスクリプション、現在のルーティングモードを確認し、接続できている設定を記録しておくと、作業後の比較に役立ちます。

取得元ごとにグループを作り、用途に応じて絞り込む

v2rayNのサブスクリプショングループ設定で、取得元が分かる名前を付けてから対応するURLを登録します。「普段使い」「テスト環境」のように、取得元や用途が分かる名前がおすすめです。一時的なサーバー名を長期的なグループ名にするのは避けましょう。保存後、対象グループを更新し、新しい項目が想定した場所に追加されたか確認します。手動で取り込んだリンクはできるだけ別のグループに分けてください。そうしないと、後でサブスクリプションの項目を整理する際に、残しておきたい手動設定まで削除するおそれがあります。

サブスクリプションURLには認証情報が含まれることが多いため、機密情報として扱ってください。URL全体をスクリーンショットや公開質問、共有ドキュメントに載せないでください。また、動作確認のために異なる取得元のURLを入れ替えるのも避けましょう。更新に失敗した場合は、内容のダウンロード段階と解析段階のどちらで失敗したかを確認します。前者はネットワーク、証明書、認証の問題、後者は形式やクライアントとの互換性が原因の可能性があります。グループ名はローカルで識別するためのものなので、名前を変更してもURLの失効は解決しません。

一覧検索と保存される絞り込み設定を区別する

サーバー一覧の検索欄は、通常、現在の表示内容だけを絞り込みます。一方、サブスクリプショングループのフィルター設定は、更新後に残す項目や表示する項目にも影響する場合があります。操作前に項目の説明を読み、サーバー名、アドレス、その他のどの属性を対象にするか確認してください。まず、存在が確かな短いキーワードで試し、結果を確認してから条件を追加します。通常のキーワードを受け付ける入力欄に汎用的な正規表現を入力したり、すべてのクライアントで同じ照合方法が使われると考えたりしないでください。

正規表現に対応している項目なら、(?i)(test|backup)で大文字と小文字を区別せずに候補を指定できます。ただし、この書式が使えるかどうかは項目で使用される正規表現エンジンによります。非対応の場合は、画面で使える通常のテキスト検索を利用してください。含める条件と除外する条件は別々に検証し、空白、全角記号、サーバー名に含まれる特殊文字にも注意します。条件が広すぎると不要な項目が残り、狭すぎると「更新は成功したのに一覧が空」という状態になります。

更新後に設定内容を確認する

サブスクリプションの更新によってサーバーが追加、削除、改名されることがあります。同じ名前でも接続パラメーターが同じとは限りません。更新後は名前だけでなく、プロトコル、サーバーアドレス、ポート、通信方式も確認しましょう。特定の項目を継続して使う場合は、更新後も選択状態が維持されるか確認してください。以前の項目が消えたとき、一覧で別の項目が選択表示されているだけで切り替え成功と判断してはいけません。対象のサーバーを選び直し、新しい接続を作って実際の動作を確認します。

項目が重複している場合は、同じ取得元から重複しているのか、複数のグループに同じサーバーが含まれているのかを先に確認します。重複項目を削除する前に元のサブスクリプションとの関係を確認しておきましょう。次回更新で再作成されたり、通信パラメーターが異なる項目を誤って削除したりするのを防げます。Androidではグループ分けや絞り込みの場所が異なる場合がありますが、基本の手順は同じです。まず取得元を一つに絞り、項目の内容を確認してから接続をテストします。名前が似ているという理由だけで一括削除すると、設定の違いを見落とすおそれがあります。

2. ルーティング設定の実践

ルーティングが処理するのは、コアに届いた接続です。システムプロキシはアプリの接続をローカルの入口に送るかどうかを決め、ルーティングはその接続にどのアウトバウンドを使うかを決めます。この二つは互いに代用できません。設定前に、アプリ、入口、宛先の識別、ルール照合、アウトバウンドという実際の経路を整理しましょう。アプリがシステムプロキシを使っていなければ、ドメインルールを変更しても通信方法は変わらないことがあります。二つの設定の違いは、システムプロキシとルーティングモードの比較も参考にしてください。

ルールは上から照合し、具体的な条件を先に置く

一般的なルールは上から順に照合され、最初に一致したルールの出口が使われます。そのため、例外は広い条件より前に置きます。基本の並びは、個別の例外、ブロック対象、ローカルネットワーク、よく使う直接接続先、最後にデフォルト出口です。「直接接続・プロキシ・ブロック」の大分類だけで適当に整理しないでください。先行ルールが宛先に一致すると、後ろの詳細ルールは正しく設定されていても適用されません。

同じルールにドメイン、ポート、ネットワーク種別など複数の項目を指定すると、通常はすべての条件を満たす必要があります。一方、ドメイン配列内の複数項目は、いずれかに一致する候補を表します。「このドメインまたはこのポート」という条件を一つのルールに入れると、意図と異なるAND条件になることがあります。OR条件が必要な場合は、ルールを分けてください。変更前に、ドメインで判定するのか、名前解決後のIPアドレスで判定するのかを決めておきます。それによってDNSが必要かどうかも変わります。

最小限の設定で直接接続とブロックを試す

以下はXray / V2Flyでよく使われる形式のルーティング設定例であり、起動可能な完全な設定ではありません。既存設定にdirect、block、デフォルトのプロキシアウトバウンドがあり、該当カテゴリを含むルールリソースが導入済みであることを前提としています。ここではAsIsを使い、まだアドレスが得られていないドメインをIPルールのために積極的に名前解決しません。すでにIPアドレスとして渡された宛先は、引き続きIPルールの照合対象になります。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

ここではfinalという名前のルール項目を使っていません。この項目は、一般的なJSON形式のルーティングで共通して使えるキーワードではないためです。ルールに一致しない場合、通常はアウトバウンド一覧の先頭が使われます。GUIクライアントが独自のフォールバックルールを生成することもあります。画面上の省略表示だけでなく、最終的に生成された設定を確認してください。残りのTCPとUDP接続をプロキシに通したい場合は、最後に対応するネットワークルールを追加できますが、出口とUDPの対応状況も確認が必要です。

ドメインの認識状況とルールリソースを確認する

ドメインルールを適用するには、コアが宛先ドメインを取得できる必要があります。HTTPやSOCKSの入口からドメイン名が渡される場合と、アプリがシステムで名前解決してからIPアドレスを渡す場合とでは状況が異なります。トラフィックのスニッフィングで一部のプロトコルからドメインを復元できることもありますが、すべての通信を識別できるわけではありません。ルールが正しく見えるのに一致しない場合は、同じドメインの表記を増やす前に、ログで宛先の形式を確認し、スニッフィング設定を見直してください。

geositeとgeoipには、それぞれ対応するリソースファイルとカテゴリが必要です。リソースがない、または現在のファイルにカテゴリが含まれていない場合、起動に失敗したり設定チェックでエラーになったりすることがあります。クライアントのリソース管理機能を使い、ファイルの配置場所が実際に使うコアと一致しているか確認してください。任意の作業フォルダーにファイルを置くだけでは不十分です。ルールカテゴリを追加するたびに、再現可能な宛先を一つ選んで新しい接続を作り、適用された出口を記録します。ルールの数を増やすだけでは、振り分けの精度は上がりません。

3. DNS設定の最適化

DNS設定では、誰が問い合わせを行うのか、どのリゾルバーに問い合わせるのか、リゾルバーへの通信がどの経路を通るのか、という三点を確認します。システムの名前解決、アプリ内蔵のDNS、コアのDNSはそれぞれ異なるレイヤーにあり、「DNSを有効化」という一つの設定では説明できません。変更前に、問題が名前解決の失敗なのか、出口に合わない解決結果なのか、ルーティングでドメインを取得できないことなのかを切り分けましょう。問い合わせがどこで発生しているかが分かれば、システム、クライアント、アプリのどこを変更すべきか判断できます。

まず通常の名前解決を整え、次にドメイン別の振り分けを検討する

最初は動作を確認しやすい通常の名前解決を維持し、サーバーのドメインと一般的なアクセス先の両方が解決できることを確認してから、ドメイン別のDNSサーバーを追加します。以下はコアのDNS部分だけの例です。指定したドメインは優先的に一つのDNSサーバーへ送り、それ以外の問い合わせには別のサーバーを使えます。この設定だけで問い合わせが自動的にプロキシ経由になるわけではなく、すべてのアプリのシステムDNSを制御するものでもありません。利用前に、DNSサーバーへの接続性と、端末の利用環境における要件を確認してください。

{
  "dns": {
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"]
      },
      "1.1.1.1"
    ]
  }
}

domainsを含むサーバー設定は、指定ドメインに優先的に使われます。ただし、一致しない場合の処理、失敗時のフォールバック、結果のフィルタリングは、コアや他の項目の設定にも左右されます。優先設定だけで厳密に経路が分離されるとは限りません。フォールバックを禁止する必要がある場合は、現在のコアが対応するフォールバック設定を確認し、ログで挙動を検証してください。特定クライアントの「リモートDNS」という画面表示を、すべてのコアに共通するJSON項目とみなさないようにしましょう。

ルーティング時の名前解決とアウトバウンド側の名前解決を区別する

ルーティング側のdomainStrategyは、IPルールとの照合のために名前解決を行うかどうかに影響します。直接接続アウトバウンド側の同名項目は、接続先をどのように解決して接続するかに影響します。設定場所も役割も異なります。たとえば、ルーティングにIPIfNonMatchを設定すると、ドメインルールに一致しなかった後で宛先を解決し、IPルールを試すことがあります。これは、すべての接続で特定のリモートリゾルバーを使うという意味ではありません。方針を変更したら、ルールの一致状況とDNS問い合わせの増減を両方確認してください。

プロキシサーバー自体のドメインを解決する場合は、起動順序にも注意が必要です。DNSサービスへのアクセスにプロキシが必要で、そのプロキシの接続にも同じDNSサービスが必要だと、依存関係が循環します。サーバーのドメインには単独で完了できる名前解決経路を用意するか、取得元が明確で継続的に管理できるサーバーアドレス設定を使いましょう。一時的な解決結果を長期間固定してドメイン管理の代わりにすると、サーバーアドレスの変更後、設定を変えていないのに接続できなくなることがあります。

キャッシュ、デュアルスタック、アプリ独自の名前解決

DNSを変更しても、ブラウザー、OS、コアに古い結果が残ることがあり、既存の接続もすぐには再解決されません。テスト時は対象アプリの既存接続を終了し、必要に応じてOSの手順に従ってキャッシュを消去してから、新しいリクエストを送信してください。IPv4とIPv6の結果も別々に確認します。IPv6アドレスが返されても、選択中の出口や現在のネットワークで接続できない場合、DNSエラーではなく、しばらく待ってから復旧するように見えることがあります。

アプリ内蔵の暗号化DNSは、システムの名前解決経路を迂回することがあります。その場合、システムDNSだけを変更しても期待する変化は確認できません。TUN環境でも、すべての暗号化問い合わせをポートルールで識別できるとは限りません。まず制御できるテスト環境でアプリ独自の名前解決を一時的に無効にし、システム経由の挙動を確認してから、必要な互換設定を検討してください。企業ドメイン、LAN内のデバイス名、スプリットDNSを使う環境では、既存の名前解決経路を維持しましょう。内部名を知らないパブリックDNSへ送らないようにしてください。

4. TUNモードとシステム通信の取り込み

TUNは仮想ネットワークインターフェースを使ってシステムのIP通信を受け取るため、HTTPやSOCKSプロキシを簡単に設定できないアプリに適しています。システムプロキシとの違いは通信の入口であり、「有効にすればすべての通信が必ずプロキシ経由になる」という意味ではありません。TUNに入った接続もルーティングルールで処理され、LANへの通信、直接接続、ブロックを引き続き使えます。クライアントのTUN機能が追加のネットワークコンポーネントで実装されていることもあります。そのため、現在のXrayやV2Flyの設定に同じTUN項目が標準で備わっているとは限りません。

通信を取り込む前に基準状態を確認する

有効化する前に、システムプロキシモードでサーバーに接続できること、一般的なドメインを解決できること、基本的なルーティングが想定どおりであることを確認します。次に、システムの通信を取り込む他のツールを終了し、現在のネットワークアダプター、デフォルトゲートウェイ、DNSの状態を記録してからTUNを有効にしてください。初回のテストでは必要最低限の取り込み設定だけを有効にし、プロセスルール、複雑な除外リスト、FakeDNSを同時に追加しないようにします。こうすれば、問題の原因が入口の変更なのか、元のアウトバウンド設定なのかを切り分けやすくなります。

権限の問題とネットワークの問題は分けて対処します。デスクトップでは管理者権限、仮想インターフェースの作成権限、補助コンポーネントの許可が必要な場合があります。Androidクライアントは通常、システムのVPN許可を通じてアプリの通信を取り込みます。許可されたことは入口を作成する権限があるという意味であり、通信がリモート側まで届いたことを示すものではありません。起動に失敗した場合は、サーバーのプロトコルを何度も変更する前に、権限、コンポーネントのファイル、インターフェースの競合を確認してください。

ループバックを防ぎ、LANへのアクセスを維持する

プロキシコンポーネント自身の外向き通信が同じTUN入口に再び入ると、ループが発生することがあります。接続が繰り返し再試行されたり、ログが急速に同じ内容で埋まったりするのが典型的な症状です。クライアントが自動ルーティングや自身の通信の除外を処理する場合もありますが、ネットワーク設定をカスタマイズすると、こうした初期設定が崩れることがあります。有効化後にシステム全体が通信できなくなったら、まずTUNを終了してネットワークを復旧し、自動ルーティング、インターフェースのバインド、除外設定を確認してください。通信できない状態で複数のネットワークコンポーネントを同時に再インストールするのは避けましょう。

LANへのアクセスには、プライベートアドレス、マルチキャストによるデバイス検出、ブロードキャスト、ローカルDNSも関係します。ルーティングでプライベートアドレスを直接接続にしても、通常のアドレスアクセスが可能になるだけで、すべてのデバイス検出プロトコルが通信を取り込む環境を通過できるとは限りません。確認時は、まず明示的なアドレスでゲートウェイや既知のデバイスにアクセスし、次に名前解決と自動検出を試します。アドレス指定ならアクセスできて名前指定で失敗する場合はDNSを優先して確認します。自動検出だけが失敗するなら、マルチキャストとアプリの検出方式を調べてください。

DNSとUDPを段階的に確認する

TUNがUDPを受け取れることと、選択中のサーバーやプロトコル経路がその通信を転送できることは別です。一般的なWebページ、UDPに依存するアプリ、LANへのアクセスをそれぞれテストしてください。ブラウザーでページが一つ開けたからといって、すべての通信が検証できたとは言えません。特定のアプリだけ失敗する場合は、独自の名前解決、特殊な宛先ポート、別のネットワークインターフェースを使っていないか確認します。そのうえで、取り込み範囲、DNS経路、必要な機能を持つ既存のアウトバウンドのどれを調整するか判断してください。

テストを終える際は、まずTUNを無効にし、仮想ルートとDNSが元に戻ったことを確認してから、システムプロキシが必要な状態か確認します。異常終了後にネットワークが復旧しない場合は、クライアントを再度起動して通信の取り込みを正常に終了し、その後システム設定を確認してください。macOSのインストール許可とネットワーク権限については権限設定の解説を参照してください。インストーラーとプラットフォーム別の案内はダウンロードセンターにまとめています。この章では追加コンポーネントを配布していません。

5. FakeDNSとドメインのマッピング

FakeDNSは、通常のDNS結果の代わりに仮想アドレスを返し、ドメインと仮想アドレスの対応関係を内部に保存します。アプリが仮想アドレスを受け取って接続すると、通信を取り込むコンポーネントやコアが対応関係から本来のドメインを復元します。目的はドメイン情報を保持してルーティングや後続の名前解決と連携しやすくすることであり、そのまま接続できる実アドレスを提供することではありません。FakeDNSで名前解決した後、対応する経路を通らずに接続すると、アプリが仮想アドレスへ直接通信して失敗することがあります。

DNS問い合わせと接続を同じマッピング経路に通す

有効にする前に、現在のコアとクライアントが、DNS応答、アドレスプールの取り込み、ドメインの復元まで一貫して対応していることを確認してください。設定項目を保存できるだけで機能全体が動作すると判断しないでください。以下はこの構成に対応するコアの設定例で、アドレスプールとDNSサーバーの関係を示しています。既存設定への統合が必要であり、入口、ルーティング、アウトバウンドも適切に設定してください。例のアドレスプールはベンチマークテスト用のアドレス範囲です。通常のインターネット接続先として使わないでください。

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": ["fakedns"]
  }
}

ipPoolは割り当て可能な仮想アドレスの範囲を指定し、poolSizeはプールの容量を設定します。アドレスプールは実ネットワークや他の通信制御ツールのアドレス範囲と調整する必要があります。「特殊に見える」という理由だけで、使用中のネットワーク範囲に変更しないでください。容量も大きければよいわけではなく、コアの実装と実際の用途に合わせて選びます。アドレスプールを変更しても、アプリのキャッシュに残る古いアドレスは自動更新されません。再度名前解決し、新しい接続を作成してください。

入口でドメインを復元し、仮想アドレスだけを返さない

FakeDNSからの復元に対応する入口では、一般に対応するスニッフィング機能を有効にします。以下も入口オブジェクト内に追加する部分的な設定であり、inbounds配列全体を置き換えるものではありません。fakednsはマッピングからドメインの復元を試み、HTTPとTLSのスニッフィングは一部のアプリケーション層の識別を補います。使用できる値や追加の入口設定が必要かどうかは、現在のコアの対応状況を確認してください。GUIが異なる設定を生成する場合もあります。

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["http", "tls", "fakedns"]
  }
}

設定によってはrouteOnlyも使えます。スニッフィング結果をルーティングの判定にだけ使い、実際の接続先は書き換えない設定です。この項目をFakeDNSに一律に適用してはいけません。最終的な接続先が仮想アドレスのままだと、実際のドメインへ接続できません。まずドメインの復元と接続先の処理が完了していることを確認してから、ルーティングだけに使うスニッフィング方針を検討してください。複数の記事から異なるスニッフィング設定を寄せ集めると、クライアントの初期設定を維持するより原因を追いにくくなります。

キャッシュの残存と迂回された問い合わせを見分ける

FakeDNSを無効にした後も、アプリがキャッシュ済みの仮想アドレスを使い続けることがあります。対象アプリの既存接続を終了し、必要に応じて名前解決キャッシュを消去してから再テストしてください。コアを再起動するだけでは、ブラウザーやシステムに残った結果が消えない場合があります。逆に、有効化後もアプリが以前の実アドレスを使っているからといって、FakeDNSが動作していないとはすぐに判断できません。まず対象の名前解決経路を確実に通る新しい問い合わせを発生させ、返されたアドレスと、その後のドメイン復元ログを確認しましょう。

アプリ内蔵DNS、固定IPへの接続、LAN内の名前は例外になりやすいケースです。固定IPには復元するドメインがなく、内部ドメインの解決には、その名前を扱える実際のDNSリゾルバーが必要です。まず制御できる範囲だけでFakeDNSを使い、Web、LAN、必要なアプリが正常に動作することを確認してから対象を広げてください。有効化後にだけ問題が発生する場合は、アドレスプールの拡大や複数のフォールバックDNS追加を同時に行わず、通常のDNSと従来の取り込み方式に戻してログを比較します。

6. 複数サブスクリプションの管理と更新時の注意

複数のサブスクリプションを管理する目的は、取得元、更新、利用状況を追跡できるようにすることであり、すべての項目を判別しにくい大きな一覧にまとめることではありません。それぞれのサブスクリプションに個別の名前、更新方法、用途を記録し、テスト用と普段使い用を分けましょう。サブスクリプションが提供するのは接続パラメーターであり、すべてのアプリ設定まで管理するものと決めつけないでください。取り込む前に、内容がサーバー一覧なのか、ルーティングやDNSを含む完全な設定なのかを確認します。大規模な設定変更を通常のサーバー更新と誤認しないようにしましょう。

取得元からのダウンロードと設定の適用を区別する

更新は、リモートの内容を取得する、クライアントの項目に解析する、選択した項目を現在の接続に使う、という三段階に分けて考えられます。ある段階が成功しても、後続の処理が完了したとは限りません。更新完了後は項目の変化と選択状態を確認し、新しい接続を一度作成してください。新しい設定を読み込んでも、アプリが既存のセッションを使い続けることがあります。開いたままのWebページで切り替わったかどうかを判断せず、新しい接続の出口と実行ログを確認しましょう。

サブスクリプション更新時の通信経路も個別に確認してください。現在のプロキシ経由で更新すれば、直接接続できない場合に取得できることがあります。しかし、更新対象のサブスクリプションが現在使えないサーバーを直すためのものだと、「更新に失敗中の接続が必要」という状態になります。更新手段として使える別の経路や独立した予備設定を残し、どの取得元にプロキシが必要か明確にしましょう。項目の意味が分からないまま更新用プロキシを何度も切り替えず、エラーが接続、認証、証明書、名前解決のどの段階で起きたか確認してください。

自動更新の不確実性を抑える

自動更新は安定した取得元に適していますが、最初から頻繁に更新するのではなく、結果を確認できる時間帯を選びましょう。まず手動で数回更新し、取得元の形式が安定していること、サーバーの選択状態を維持できることを確認してから、自動更新を設定します。サブスクリプションに有効期限のある認証情報が含まれる場合は、URLが失効しないかにも注意してください。何度も再試行しても認証の問題は解決せず、ログに同じエラーが増えて最初の原因が見えにくくなることがあります。

更新時に既存の項目を残すか、使えなくなった項目を削除するか選べる場合は、それぞれの利点と注意点を理解しておきましょう。項目を残せば一時的な復旧に使えますが、使えない設定が一覧に蓄積することがあります。削除すれば取得元との整合性を保てますが、使用中の項目がすぐに消える可能性があります。先に独立したバックアップがあることを確認し、そのうえで整理方法を決めてください。手動で変更したサーバー設定が次回の更新後も残るとは限りません。必要なら、用途が分かる名前を付けて独立した設定として複製します。

統合、重複の整理、取得元の信頼性

重複を整理する際は、名前だけでなく実際の接続パラメーターを比較してください。同じサーバーアドレスでもポート、通信経路、安全設定が異なることがあり、そのまま統合できるとは限りません。名前が違っても同じ接続を表す場合もあります。まず一つの取得元の中を整理し、次に複数の取得元間で重複を確認して、取得元の識別情報を残しましょう。クライアントの自動重複削除で何を比較するか分からない場合は、テスト用グループで試し、結果を確認してから普段使いの項目全体に適用してください。

取得元にリモートリソースのURLや見慣れない拡張項目が含まれることもあります。必要な内容だけを取り込み、システム設定の上書き、全ルーティングの変更、追加の許可を求められた場合は、用途を確認するまで進めないでください。サブスクリプションURLには認証情報が含まれることがあるため、知らないオンライン変換サービスに送らないでください。変換によって設定の意味が変わるおそれもあります。形式に互換性がない場合は、まず提供元が対応するクライアント形式を確認し、その後、内容を確認できるローカルでの処理を検討します。

端末を移行するときは設定間の関係を引き継ぎ、実行中の状態を丸ごと複製しない

端末間で移行する際は、グループ名、サブスクリプションの用途、必要なルール、手動設定を記録し、クライアントのエクスポート・インポート機能を使うことをおすすめします。デスクトップのパス、ポート、ネットワーク権限をそのままAndroidに適用したり、端末固有のTUN設定を未確認のまま使ったりしないでください。取り込み後は取得元ごとに更新し、まず基本接続を復元してから詳細ルールを追加します。変更を一度にまとめて発生させずに済むため、取得元の問題とプラットフォームの違いを切り分けやすくなります。

7. 自作アウトバウンドとタグの参照

アウトバウンドは、コアから接続を外部へ送る際の処理方法を定義し、ルーティングはタグで対象を指定します。プロキシ、直接接続、ブロックは固定の三つのボタンではなく、設定オブジェクトとその関連付けです。カスタマイズを始める前に、クライアントで編集できるのが完全な設定なのか、一部のアウトバウンドなのか、GUIのルーティング項目なのかを確認してください。それぞれ設定の統合方法が異なります。実行時の一時ファイルを直接変更すると、サーバーの切り替えや再起動時に上書きされることがあるため、長期的に使う設定の保存先には適しません。

追跡できるタグの関係を作る

参照するアウトバウンドには、それぞれ重複のない分かりやすいtagを付け、ルーティングのoutboundTagを完全に一致させます。大文字・小文字、空白、綴りの違いでも参照に失敗することがあります。以下の例は基本的なアウトバウンドオブジェクトを二つ示す完全な断片ですが、クライアントのアウトバウンド配列全体を置き換えるためのものではありません。置き換えると既存のプロキシアウトバウンドも失われます。現在の設定に同じ名前のオブジェクトがないか確認してから追加してください。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

freedomは端末のネットワーク環境を通じて宛先へ直接接続し、blackholeは一致した接続を破棄します。直接接続を指定しても宛先へ必ず到達できるわけではありません。端末のDNS、IPアドレスの種類、ゲートウェイ、ファイアウォールの影響を受けます。ブロック時の表示も一律ではなく、アプリが接続エラーを表示したり、再試行したりすることがあります。Webページの表示だけでルールの動作を判断せず、実際の出口ログも確認してください。

デフォルトの出口と明示的なルーティングをあわせて確認する

ルーティングルールに一致しない場合、一般的なコア設定ではアウトバウンド一覧の先頭が使われます。クライアントがフォールバックルールを生成する場合もあります。そのため、アウトバウンドの順番変更は単なる一覧整理ではなく、動作に影響する変更です。上記の断片だけを使うと先頭は直接接続になり、「デフォルトのプロキシ」とは異なります。デフォルトでプロキシを使う場合は、既存のプロキシオブジェクトの順番や、クライアントが生成した最終ルールを確認してください。画面でサーバーを選択していても、完全な設定の処理順を無視しないようにしましょう。

特定の用途に専用の出口を使う場合は、まず最終設定に対象のアウトバウンドが存在することを確認し、最も具体的な条件をルーティングに追加します。サブスクリプショングループ内の複数サーバーが、自動的にすべて参照可能なアウトバウンドになるとは限りません。選択中のサーバーが常に固定タグを使う場合もあります。複数の出口を同時に使うには、クライアントが対応する設定生成機能を備えているか、正常に起動できる完全なカスタム設定を管理する必要があります。サーバー名をタグとして入力するだけでは、アウトバウンドは作成されません。

プロキシチェーンでは接続経路を明確にする

多段転送と複数出口の選択は別の仕組みです。複数出口の選択では接続ごとに異なる経路を使い、プロキシチェーンでは同じ接続を複数の処理段階に順に通します。チェーン接続を設定する前に、現在のコアが対応する項目、各サーバーへの到達性、ループが発生しないことを確認してください。対応範囲を確認せずに、あるコアの接続先指定項目を別のコアへコピーしないようにしましょう。まず各出口を個別にテストし、その後でチェーンを組み合わせると、問題がどの区間で起きているか特定できます。

アウトバウンドにインターフェースや送信元アドレスを指定する場合は、ネットワークの変化も考慮します。無線インターフェースを固定すると、有線接続へ切り替えた後に使えなくなることがあります。送信元アドレスを固定すると、アドレスの再取得後に端末のアドレスでなくなる場合があります。こうした項目はネットワーク条件が明確な環境向けで、接続失敗全般に対する修正方法ではありません。通常の直接接続だけなら、システムのルート選択を維持した方が管理しやすいでしょう。複数のネットワークインターフェースが必要な場合は、インターフェース変更時の確認と復旧手順も記録してください。

生成結果を確認してから長期運用に移す

カスタム設定を保存したら、まずクライアントの設定チェックを実行し、続いて起動ログを確認してください。タグが重複していないか、参照先が存在するか、デフォルトの出口が正しいか、カスタムオブジェクトが統合されているか上書きされているかを確認します。画面の設定と実際の動作が一致しない場合は、実際に適用された設定を基準に調べましょう。エコシステムやコアの違いはProject V、V2Fly、Xrayの関係を参照してください。設定の対応範囲を確認してから、コアを切り替えるか判断します。

8. 検証、ログ、設定の復旧

詳細設定には、再現可能な検証手順が必要です。変更は一度に一つに絞り、変更前に「特定の業務ドメインが指定したアウトバウンドを使う」「LAN内のアドレスは引き続き直接接続する」など、期待する結果を書き出してください。サブスクリプションの更新、コアの切り替え、TUNの有効化、DNSの変更を同時に行い、一度のWebアクセスだけで成否を判断しないでください。変更範囲が大きいほど原因の特定が難しくなります。結局すべてを元に戻すことになれば、検証で得た知見も失われます。

最小限のテスト項目を用意する

少なくとも、一般的なドメインへのアクセス、直接接続が明確な宛先、プロキシが必要な通信、LAN内のリソースの4種類を確認します。それぞれ安定していてアクセス権のある対象を選び、想定する入口とアウトバウンドを記録してください。UDP、デュアルスタック、特定アプリを使う場合は、該当する項目も追加します。既存の接続を再利用している可能性のあるページを何度も更新するのではなく、新しい接続を作ってテストしてください。アプリの接続プールやブラウザーキャッシュによって、設定を切り替えても変化がないように見えることがあります。

ログは接続の段階ごとに確認する

まずコアが正常に起動したか確認してください。起動が完了していなければ、リモート接続をテストする必要はありません。次にローカルの入口が接続を受け取ったか、宛先のドメインやアドレス、適用ルール、アウトバウンドのエラーを順に確認します。ポートの競合はローカルの待ち受け段階、名前解決の失敗はDNS段階の問題です。接続タイムアウトはリモート側への到達性が関係することがあり、証明書のエラーは通常、安全な接続のハンドシェイク中に発生します。すべてを「サーバーを変える」だけで対処しないようにしましょう。

ログレベルは現在の調査に必要な範囲に設定し、完了後は通常のレベルに戻して、詳細な記録を長期間有効にしないでください。ログを共有するときは、サブスクリプションURL、ユーザー識別情報、認証項目、不要な内部ドメインを隠し、エラー前後の関連行だけを残します。発生時刻も重要です。手動テストと対応するログ行をできるだけ明確にし、バックグラウンドアプリの通信を対象の通信と取り違えないようにしましょう。よくあるエラーの詳しい見方は実行ログの読み方を参照してください。

直近の変更から順に元へ戻す

復旧時は直近に加えた変更を一つ元に戻し、基準状態で再テストします。FakeDNSが原因なら通常のDNSに戻した後、古いマッピング結果も削除します。TUNが原因なら通信の取り込みを停止し、システムのルートとDNSを確認します。自作アウトバウンドが原因ならタグとデフォルト出口の順番を元に戻してください。画面上のスイッチを一つ切るだけで、関連する状態がすべて解除されたと判断しないでください。復旧後は各段階で新しい接続を確認し、キャッシュによる誤判定を防ぎましょう。

検証済みの設定と必要な説明を長期保存してください。説明にはクライアント、実際に使うコア、入口の方式、依存するルールリソース、特別な権限を記載します。バックアップに一時的なログをすべて含める必要はありませんが、重要な設定の関係を復元できるようにしておきましょう。ソフトウェアを更新した後は、まず基本接続を確認してからカスタム設定を検証します。起動時にクラッシュする場合は起動時のクラッシュとディレクトリ権限の確認を参照してください。アプリの起動問題をルーティングの障害と混同しないようにしましょう。

動作する設定を記録にまとめる

検証に合格したら、標準設定以外の各項目に「このドメインでは内部DNSを維持する」「この通信には専用の出口を使う」のように理由を一文で記録します。値だけでなく必要性を記録しておけば、環境が変わったときに設定を残すべきか判断できます。サブスクリプション、ネットワーク、コアを変更した後は、それらに直接関係する項目を確認してください。影響を受けない項目まで毎回すべて検証する必要はありません。管理範囲を絞ることで、継続的な保守がしやすくなります。

原因を特定できない場合は、問題を一つの接続、一組のルール、一つの出口に絞り、機密情報を除いた設定例と対応するログを用意してトラブル対処のQ&Aを確認してください。基本操作からやり直す場合は入門ガイドへ、プラットフォームや端末のアーキテクチャに合わせてインストール先を選ぶ場合はダウンロードセンターへ進んでください。このガイドでは、設定変更の根拠と検証方法、明確な復旧手順を確認できます。