設定ガイド / v2rayN・v2rayNG・v2flyNG

V2Ray 高度な設定ガイド

サブスクリプションのグループ分け、ルーティング、DNS、仮想ネットワークインターフェースの設定関係を解説します。

初めて接続する場合はクイックスタートガイドをお読みください。接続できていて動作を調整したい場合は、このページの目次から該当項目をご覧ください。デスクトップでは主にv2rayNを、Androidではv2rayNGとv2flyNGを取り上げます。画面上の設定場所はクライアントによって異なります。パラメーターの意味は、実際に動作しているコアを基準に確認してください。

変更前にバックアップ 一度に検証するのは一つの項目 設定例の適用範囲を確認

01 / 設定の管理

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

まず取得元ごとにグループを分け、次に用途に応じてサーバーを絞り込みます。グループ分けは「設定の取得元と更新元」を整理するため、絞り込みは「現在の一覧に何を表示するか」を選ぶための機能です。両者を混同しないようにしましょう。v2rayNのサブスクリプショングループには通常、サブスクリプションURL、更新オプション、メモを保存します。サーバー一覧の検索やフィルターは、表示範囲を絞るために使います。サーバーが一時的に一覧に表示されない場合、削除されたとは限りません。選択中のグループや検索条件によって非表示になっている可能性もあります。

グループを作成する前に記録しておくこと

グループ名、取得元、更新方法を記録してからURLを入力します。名前は「普段使い」「予備・テスト」のように、取得元や用途が分かるものにしましょう。紛らわしい連番だけの名前は避けてください。サブスクリプションURLにはアクセス情報が含まれることがあるため、クライアントのURL欄にのみ入力し、メモやスクリーンショット、公開文書には記載しないでください。保存後はまず手動で更新し、想定したプロトコルやサーバー名が一覧に表示されることを確認してから自動更新を設定します。一覧が空でも、グループを何度も削除して対処しないでください。

v2rayNでは、サブスクリプション関連のメニューからグループを編集し、更新を実行できます。v2rayNGとv2flyNGでは、サブスクリプション設定またはグループ管理のメニューを探してください。「選択中のグループを更新」と「すべてのグループを更新」の表示は、クライアントによって異なる場合があります。実行前に対象範囲を確認しましょう。インポート後にサーバーが1件しか表示されない場合は、単一の共有リンクかサブスクリプションURLかを確認してください。どちらも長い文字列に見えますが、更新時の動作は異なります。

フィルターの設定で結果が消えるのはなぜ？

まずフィルター機能の動作を確認します。一覧検索だけを行う項目もあれば、サブスクリプションの更新時に項目を除外するものもあります。通常の文字列を使う場合、正規表現を使う場合、包含・除外条件を個別に指定する場合など、仕様はさまざまです。他のクライアント用の式をそのまま貼り付けないでください。正規表現に対応している項目では、縦棒が「または」、ピリオドが任意の1文字を意味し、サーバー名の括弧も構文として解釈されることがあります。まず具体的なキーワードを一つだけ指定して結果を確認し、少しずつ条件を追加してください。

操作主な役割確認する点
グループを切り替える現在表示する範囲を限定するサーバーが別のグループに残っているか
一覧を検索する表示結果を一時的に絞り込む検索をクリアすると再表示されるか
サブスクリプションをフィルタリングする更新後に残る項目に影響する包含・除外条件と式のルール
サーバーを削除する保存済みの項目を削除する次回の更新で再び表示されるか

除外条件は、包含条件より慎重に設定してください。すべての項目が除外されると、クライアントによっては古い一覧を維持する場合もあれば、グループを空の状態に更新する場合もあります。フィルターを変更する前に設定をバックアップし、現在使っているサーバー名とプロトコルを記録してください。フィルター適用後は、分かっている項目が表示されるかを確認しましょう。一覧が短くなっただけで正しく設定できたと判断しないでください。サーバー名は変更されることがあり、取得元側の命名変更で有効だったキーワードが使えなくなる場合もあります。フィルター条件は定期的に見直しましょう。

更新は成功したのに接続できない場合、次に確認すること

更新の成功は、サブスクリプションを取得して解析できたことを示すだけで、すべてのサーバーに接続できることを保証するものではありません。まず、現在選択中の項目が更新後も有効なサーバーを指しているか確認し、プロトコル、トランスポート、TLS、認証の各項目が正しく設定されているかを調べます。サブスクリプションの項目を手動で変更しても、次回の更新で上書きされることがあります。変更を維持する必要がある場合は、独立した設定として複製し、取得元を記録してください。元の項目を直接変更して区別を忘れると、あとで問題が取得元の変更によるものか、ローカルの変更によるものか判断しにくくなります。

02 / 接続先の振り分け

ルーティングルールの順序と確認方法

具体的な例外を先に、広範囲を対象とするフォールバックを後に配置します。V2Ray系コアでは一般に、ルールを上から順に確認し、最初に一致したルールに対応するアウトバウンドを選択します。クライアントが設定を生成すると独自のルールが追加される場合もあるため、画面上の順序と最終設定を照らし合わせてください。ルールが何に一致するかは、接続にドメイン名とIPアドレスのどちらが含まれるか、スニッフィングが有効か、ドメイン戦略によって名前解決が行われるかなどで変わります。ドメインルールを追加しただけで、すべての接続に利用可能なドメイン名が含まれるとは限りません。

ドメイン・IPアドレス・アウトバウンドタグとは

domainはドメイン名の一致条件、ipは接続先IPアドレスの一致条件、outboundTagは定義済みのアウトバウンドタグを参照します。タグは内部識別子であり、画面に表示するメモとして自由に入力するものではありません。例にあるdirect、proxy、blockは、いずれもアウトバウンド設定に定義されている必要があります。ドメインやIPアドレスなど異なる種類の条件を一つのルールに記述すると、通常はすべての条件を満たす必要があります。「ドメインかIPアドレスのどちらかに一致」を意図する場合は、ルールを分けてください。

以下は、Xray/V2Rayでよく使われる形式のルーティング例です。クライアント設定全体としてはインポートできません。必要なgeositeデータとgeoipデータが利用でき、対応するアウトバウンドが定義済みであることを前提としています。まず広告カテゴリを遮断し、次にプライベートアドレスと中国のドメインを処理します。それ以外の接続は、クライアントのデフォルトアウトバウンドで処理します。ドメインカテゴリの内容は、実際に使用するデータファイルによって異なり、固定ではありません。カテゴリが見つからないというエラーが出た場合は、ルールの順序を何度も変えるのではなく、データが対応しているか確認してください。

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

ドメイン戦略の選び方

AsIsは、ルーティング時にIPルールとの照合を目的としたドメインの名前解決を行いません。IPIfNonMatchは一般に、ドメインがルールに一致しない場合に名前解決を試み、その結果で照合を続けます。IPOnDemandは、照合にIPアドレスが必要になった時点で名前解決を行います。これらの戦略はルーティング時の判定方法を決めるもので、システム全体のDNS動作を指定するものではありません。特定のドメインだけを直接接続したい場合は、まず明確なドメインルールを設定してください。そのためだけに、すべてのリクエストを事前にIPアドレスで照合する必要はありません。

「日本国内のサイトも遠回りする」場合、まずルールの一致状況を確認してください。いきなりすべての接続を直接接続に切り替える必要はありません。対象ドメインがカテゴリに含まれているか、前に広範囲を対象とするプロキシルールがないか、アプリがキャッシュ済みのIPアドレスへ直接接続していないかを確認します。最終設定でデフォルトアウトバウンドがプロキシになっている場合、ルールに一致しない接続がプロキシ経由になるのは想定どおりです。調査時は対象ドメインを指定したルールを一時的に追加し、同じアプリで新しい接続を確立してください。既存の長時間接続は設定変更後も自動で切り替わるとは限らず、ページを再読み込みしても以前の接続が再利用されることがあります。

ルールが増えて整理できなくなるのを防ぐには

ルールを「ローカルリソース、個別の例外、カテゴリルール、フォールバック」に分けて記録し、例外ごとに用途を明記します。LAN内の機器へ接続する場合、プライベートIPアドレスを直接接続する設定は、機器のドメイン名による分類に頼るより確実です。社内ドメインでは専用DNSが必要になる場合もあり、アウトバウンドだけを変更しても名前解決の問題は解消しません。すべてのポートやネットワークを対象とする広範囲なルールを前方に置かないでください。後続の細かなルールが適用されなくなります。変更後は、明確な直接接続先、プロキシ接続先、LAN内の接続先をそれぞれテストします。

動作確認では、接続先のドメイン、アプリ名、一致したルール、アウトバウンドタグを記録してください。「サイトが開いた」だけでは不十分です。サイトによっては、ページ本体と画像で異なるドメインを使うため、ページが直接接続できても、すべてのリソースが同じ経路を通るとは限りません。プロトコルの項目についてはVMessとVLESSの違いも参照してください。ルーティングの選択とプロトコルの選択は別の設定です。

03 / 名前解決

DNS設定の最適化はどの層から始める？

まず問い合わせの経路を整理してから、DNSリゾルバーを選びます。アプリはシステムDNSやブラウザー独自の暗号化DNSを使うことも、プロキシプロトコル経由でドメイン名をコアに渡すこともあります。コアがルーティング判定用と直接接続用に別々に名前解決する場合もあります。そのため、「クライアントにDNSを設定した」だけでは、すべてのアプリの問い合わせがそこを通るとは限りません。最初に確認するのは、誰が問い合わせを送るのか、どの出口を通るのか、応答を誰が使うのかです。複数のパブリックDNSを次々とリストに追加することから始めないでください。

ローカルドメインと外部ドメインを分ける理由

LAN内の機器名や社内ドメインは、ローカルまたは組織内のDNSでしか解決できないことがあります。一方、インターネット上のドメインは、DNSリゾルバーの場所によって異なるCDNの接続先が返される場合があります。内部ドメインをすべてパブリックDNSに送ると、名前解決できないことがあります。逆に、外部ドメインの問い合わせを常にローカルで処理すると、プロキシの接続元と合わないIPアドレスが返される場合があります。DNSを振り分ける目的は、名前解決の結果とその後の接続経路を一致させることです。特定のDNSリゾルバーが常に優れていると決めつけることではありません。

以下は、中国のドメインカテゴリに対して優先的に一方のDNSリゾルバーを使い、それ以外の問い合わせには別のリゾルバーを使う基本例です。dns.serversの構造を示すもので、問い合わせがプロキシ経由または直接接続で送られることを保証するものではありません。実際の問い合わせ経路は、コアの実装、問い合わせプロトコル、ルーティング設定によって決まります。この例でクライアントのDNS設定全体を置き換えないでください。特にTUN環境では、仮想ネットワークインターフェースやDNS制御のためにクライアントが生成する関連設定を維持する必要があります。

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

暗号化DNSでも接続できないことがあるのはなぜ？

HTTPS形式のDNSリゾルバーを使う場合、まずリゾルバー自体に接続する必要があります。接続先がドメイン名なら、その名前を先に解決しなければならず、ブートストラップの問題が発生することもあります。プロキシサーバーのアドレスもドメイン名で、まだ接続できていないプロキシ経由でしか名前解決できない設定にすると、依存関係が循環します。まずサーバー名とDNSリゾルバー名を独立した経路で解決できるようにしてから、他のドメインの問い合わせ先を設定してください。一時的にサーバーのIPアドレスを固定して長期間使うのは避けましょう。接続先が変更されることがあります。

症状優先して確認する項目次に行うこと
ドメイン名では失敗するが、IPアドレスでは接続できる名前解決の結果と問い合わせのタイムアウトアプリが使用しているDNSリゾルバーを確認する
内部ドメインを解決できない内部DNSが迂回されていないか内部ドメイン用の経路を設定する
プロキシの起動時に名前解決がタイムアウトするサーバー名のブートストラップ名前解決未確立のプロキシに依存しない経路にする
アプリによって結果が異なる独自の暗号化DNSとアプリのキャッシュテスト条件をそろえて再接続する

ドメイン戦略とDNSサーバーの選択は別々に考えます。ルーティングのdomainStrategyは、ルールの照合に必要なときに名前解決するかを決めます。直接接続のアウトバウンドにも、独自のドメイン解決戦略がある場合があります。ルーティングでAsIsを使っていても、ドメイン名に直接接続する際には名前解決が必要になることがあります。逆に、ルーティングでIPアドレスが得られても、ブラウザーなどのアプリが別途DNS問い合わせを送らないとは限りません。「DNS問い合わせの経路」と「実際の通信の経路」を分けて調べ、DNSテストサイト一つだけで結論を出さないでください。

キャッシュとデュアルスタック環境の確認

設定を変更したら、関連する接続を再確立し、システム、アプリ、コアそれぞれのキャッシュも考慮します。キャッシュの有効期限が切れていないと、テストに古い結果が使われることがあります。デュアルスタック環境では、アドレスレコードの種類も確認してください。IPv4で成功しても、IPv6の通信が想定した経路を通るとは限りません。特定の層でIPv6の問い合わせを無効にしても、アプリがキャッシュ済みのアドレスを使うことがあります。実際にデュアルスタックに対応したネットワークでは、名前解決、ルーティング、出口の対応状況をあわせて確認します。IPv6を無効にすることを、あらゆる問題に対する解決策にしないでください。

DNS問い合わせが正常でもWebページを開けない場合は、ルーティングとトランスポートのログを確認してください。サーバーによる拒否、TLSパラメーターの不一致、接続先によるリセットは、DNSリゾルバーを変更しても解決しません。よくある接続の症状はヘルプセンターで確認できます。

04 / システムの通信制御

TUNモードとシステムプロキシの違い

TUNは仮想ネットワークインターフェースを通じてシステムの通信を受け取ります。システムプロキシは、その設定に対応したアプリにプロキシのアドレスを提供します。ブラウザーはシステムプロキシに対応していることが多い一方、ターミナルツール、バックグラウンドサービス、独自のネットワークスタックを使うアプリは従わない場合があります。TUNはより広範囲の通信を制御したい場合に適していますが、権限、ルーティング、DNS、仮想ネットワークインターフェースの関係が加わります。まず通常のプロキシ接続が使えることを確認してからTUNを有効にしてください。そうしないと、基本的な接続とシステムの通信制御が同時に失敗し、原因の切り分けが難しくなります。

有効にする前に確認すること

まず利用可能な設定を保存し、現在のシステムプロキシの状態を記録して、使用中のクライアントが対象プラットフォームでTUNに対応していることを確認します。v2rayNはデスクトップのプラットフォームによって、異なる補助コンポーネントや動作方式を使うことがあります。TUN機能も、選択中のサーバーと同じコアが直接実装しているとは限りません。サーバーのプロトコルだけを見て仮想インターフェースへの対応を判断しないでください。有効にする際は、クライアントの指示に従って必要な権限を付与します。インターフェースの作成やルートの変更に失敗した場合は、サブスクリプションのサーバー設定を調整するのではなく、まず権限とコンポーネントの問題を解決してください。

Android版のv2rayNGとv2flyNGは通常、システムのVPNインターフェースを使って通信を制御します。権限の確認ダイアログはシステムの動作です。同じシステムインターフェースを使う他のネットワークツールとは競合する場合があるため、まず競合する機能を停止してからテストしてください。デスクトップ環境では、企業VPN、仮想マシンのネットワーク、セキュリティソフトがルートやDNSを変更する場合にも注意が必要です。調査のためにすべてのネットワークインターフェースを削除しないでください。関連ソフトを一時停止して元の設定を維持し、クライアント終了後にネットワークが自動的に復旧するか確認します。

TUNを有効にするとLAN内の機器に接続できないのはなぜ？

まずLAN内のアドレスが制御対象になっているか、より具体的なルートや迂回設定がないかを確認します。プリンター、ファイル共有、管理画面では、プライベートIPアドレス、内部ドメイン、LAN内の機器検出プロトコルが使われることがありますが、それぞれ別の種類の通信です。プライベートIPアドレスを直接接続する設定で処理できるのは、通常、コアに届いた通信だけです。ブロードキャスト、マルチキャスト、機器検出は、システムインターフェースや通信制御の方式にも左右されます。まず機器のIPアドレスを指定して接続を試し、その後で名前解決や機器検出を確認してください。一度に多数のドメイン例外を追加しないでください。

確認項目システムプロキシTUNによる通信制御
アプリの対応状況アプリがプロキシ設定に従う必要があるシステムのルーティングと制御範囲に依存する
DNSの動作アプリが独自にDNS問い合わせを行う場合があるDNS問い合わせが制御対象に含まれるか確認が必要
必要な権限通常は少ないインターフェースの作成やルートの変更が必要な場合がある
終了時の復旧システムプロキシが解除されているか確認する仮想インターフェース、ルート、DNSを確認する

サーバーへの接続自体が再び通信制御の対象になり、ループしないようにする必要があります。クライアントは通常、インターフェースの指定、ルートの除外、その他の方法でこれを処理します。ただし、デフォルトのネットワークインターフェースが変わった場合、別のトンネルを同時に有効にした場合、ルートを手動で変更した場合は、前提が崩れることがあります。起動後にログで同じサーバーへの接続が繰り返される場合や、TUNを無効にするとすぐ復旧する場合は、出口インターフェースと除外ルールを優先して確認してください。通信制御を「強化」するためにサーバーアドレスを通常のプロキシルールへ追加しないでください。問題が複雑になるおそれがあります。

UDP、MTU、スリープ復帰後の問題を調べる方法

Webページは開けるのに音声通話、ゲーム、その他のUDPアプリが使えない場合、選択中のプロトコル、サーバー、トランスポート経路が必要な転送に対応しているかを確認します。TUNが通信を受け取れるからといって、接続先でも転送できるとは限りません。小さなリクエストは成功するのに、大きなデータで止まる場合は、経路MTUやフラグメントの問題を検討します。タイムアウトが発生したからといって、すぐにMTUを下げないでください。まずサーバーや接続先の障害を除外してから、クライアントが対応する範囲内で少しずつ調整し、元の値も記録しておきます。

スリープからの復帰後やWi-Fiの切り替え後は、元のインターフェースやデフォルトルートが変わっていることがあります。まずクライアントの接続を再確立し、仮想インターフェースが再びバインドされているか確認してから、システムDNSが有効なアドレスを参照しているかを調べます。クライアントを終了してもインターネットに接続できない場合は、ウィンドウを閉じるだけで済ませず、システムプロキシ、DNS、ルートの状態を個別に復旧してください。ブラウザーとターミナルで動作が異なる場合はシステムプロキシのアプリ別トラブルシューティングを参照し、アプリの対応状況とシステムの通信制御のどちらに問題があるかを確認します。

05 / ドメイン名の復元

FakeDNSが機能する条件

FakeDNSが返すのは、コアが識別に使う合成アドレスであり、接続先サイトの実際のアドレスではありません。アプリが合成アドレスを受け取って接続すると、コアがそのアドレスを、先ほど問い合わせたドメイン名に戻してからルーティングまたはリモート接続を行います。システムの名前解決後に失われやすい「接続先の元のドメイン名」を維持できることが利点です。特に通信制御下で役立ちます。DNS問い合わせとその後の接続の両方が、関連付け可能な同じ処理経路に入ることが前提です。片方だけしか制御されないと、接続に失敗することがあります。

DNS問い合わせと接続の両方を制御する必要がある理由

コアがDNS問い合わせに応答しても、実際の通信がコアを迂回すると、システムは実在するサーバーのアドレスではない宛先へ直接接続しようとします。反対に、アプリが独自の暗号化DNSで実際のIPアドレスを取得し、接続だけがTUNに入る場合は、FakeDNSに対応するマッピングがないことがあります。まずDNS問い合わせがどこに送られるか、次に応答されたアドレス宛ての通信を誰が受け取るかを確認してください。「TUNを有効にした」だけでマッピングの経路がすべて整っていると判断してはいけません。FakeDNSの組み込み方はクライアントによって異なり、別の設定形式を使う通信制御方式もあります。実際のコンポーネントに合わせて確認してください。

以下は、関連する設定形式を使うXray/V2Rayコアの設定例です。合成アドレスプールとDNSサーバーの選択のみを示しています。対応するインバウンド、スニッフィングによる復元、ルーティングも設定する必要があり、この部分だけを貼り付けても機能は有効になりません。アドレスプールは、実際に使われているテストネットワークと重複しないようにしてください。環境内に同じネットワークセグメントへのルートがある場合は、先に競合を解消します。GUIクライアントでは、関連設定を一つずつ変更して不足を招かないよう、クライアントが用意する設定一式を優先してください。

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

FakeDNSとスニッフィングは同じ機能？

別の機能です。FakeDNSは以前のDNS問い合わせの記録を使ってドメイン名を復元します。スニッフィングは接続の初期データから、HTTPやTLSなどのアプリケーション層情報を識別しようとします。スニッフィングですべてのプロトコルを識別できるわけではなく、どのIPアドレスからでも自動的にドメイン名を復元できるわけではありません。FakeDNSはマッピングが存在することが前提です。一部のコアでは、スニッフィング設定の特定オプションを使ってFakeDNSと連携しますが、両者が異なるデータを元にする点は変わりません。有効にする前に、現在のコアが対応する項目を確認してください。異なる設定形式のオプション名を混同しないようにしましょう。

「ルーティング判定にのみ使用する」設定と、「実際の接続先を書き換える」設定も区別してください。スニッフィングで識別したドメイン名をルール照合に使うだけで、実際の接続先アドレスは変更しない設定があります。一方、後続のアウトバウンドがドメイン名を使って再度名前解決する設定もあります。これらの動作は、CDN、証明書検証、特殊なアプリとの互換性に影響します。スニッフィングを有効にしてアプリが動かなくなった場合は、まず接続先の書き換えを無効にするか、クライアントが対応する除外ルールを使って比較してください。すべてのドメインルールを削除しないでください。

通信制御を停止したのに、アプリが接続できないのはなぜ？

アプリに合成アドレスがキャッシュされている可能性があります。FakeDNSを停止した後も、キャッシュ内のアドレスは新しい接続に使われることがありますが、その時点でコアはアドレスを復元できません。まず関連アプリの接続を終了してDNSキャッシュを消去し、必要であればアプリを再起動してください。システムキャッシュだけでなく、コアのマッピングも考慮します。システムキャッシュを消去してもブラウザーに以前の結果が残っていれば、問題は続く可能性があります。設定を切り替える際は、古いマッピングと新しい名前解決結果が混在しないよう、アプリが接続を繰り返す状態を避けてください。

互換性を確認する際は、ブラウザー、LAN内の機器検出が必要なアプリ、独自のDNSを使うプログラムをテストしてください。通常のDNSでドメイン名を維持でき、必要なルーティングを実現できるなら、設定項目が多いという理由だけでFakeDNSを有効にする必要はありません。必要な場合は、まず一つのアプリでDNS問い合わせ、マッピングの復元、アウトバウンドが想定どおりかを確認してから、通信制御の範囲を広げます。異常があれば通常のDNS設定に戻し、スニッフィングや接続先の書き換えをさらに重ねないでください。

06 / 更新と管理

複数のサブスクリプションを上書きせずに管理する方法

複数のサブスクリプションを上書きせずに管理する方法

同じ名前のサーバーや重複インポートへの対処

まず取得元と接続に関わる主要項目を比較してから、重複かどうかを判断します。サーバー名が同じでも、ポート、プロトコル、トランスポートが異なる場合があります。設定内容が同じでも、名前を変更しただけで別のサーバーになるとは限りません。クライアントの重複排除機能は、アドレス、プロトコル項目、内部IDなどを基準に動作することがあり、実行すれば手動変更が必ず保持されるとは限りません。まとめて整理する前にバックアップをエクスポートし、分かっている項目をいくつか選んで動作を確認してから、広範囲の整理を行ってください。一覧から探しにくいだけなら、似た項目をすべて削除するのではなく、グループ分けと絞り込みを改善しましょう。

デバイス間の移行では、設定の管理関係も維持する必要があります。共有リンクを1件だけエクスポートしても、サブスクリプションの更新設定、ルーティング、DNS、クライアントの各種設定は通常含まれません。設定全体をエクスポートすると、より多くの機密情報が含まれる可能性があります。移行するのがサーバーの接続情報だけなのか、クライアント環境全体なのかを明確にしてください。デスクトップ版とAndroid版のクライアントで、完全に同じ設定形式が使えるとは限りません。最も確実なのは、サブスクリプションを新しく設定してから、各章を参照しながらルールを移行する方法です。デスクトップの内部設定を、そのままモバイル版にインポートしないでください。

自動更新を有効にするタイミング

まず手動で更新して動作を確認してから、更新間隔を設定します。更新頻度は配信元が実際に変更される頻度に合わせましょう。新しい状態を保つためだけに、頻繁にリクエストする必要はありません。端末のスリープ、ネットワークの切り替え、配信元への一時的な接続不能によって、定期更新が失敗することがあります。クライアントによっては起動中にしかタスクを実行しないため、更新間隔を設定しても電源オフの間に更新されるわけではありません。プロキシ経由での更新と通常の更新も区別してください。通常の更新は直接接続で取得することがありますが、プロキシ経由の更新は接続が使えることが前提です。サブスクリプションの取得にプロキシが必要な場合は、動作確認済みの接続設定を一つ残しておきましょう。

サブスクリプションの更新と現在のサーバーの切り替えは別の操作です。配信元から現在使用中の項目が削除された場合、クライアントは再起動まで読み込み済みの設定を使い続けることもあれば、再読み込み時に無効だと表示することもあります。更新後は、現在選択中の項目が残っているか確認し、接続を再確立して動作を確認してください。クライアントが対応する選択機能を実際に設定していない限り、特定のサーバーが自動的に選ばれるとは考えないでください。画面上の並び順、テスト結果の並び順、現在の選択状態はそれぞれ別です。一覧の先頭にあっても使用中とは限りません。

サブスクリプションの取得に失敗したときの確認手順

まずURLが完全かを確認し、次に取得経路、最後に形式を確認します。コピー時にクエリパラメーターが欠けた、末尾に空白が入った、配信元がログインページを返したなどの理由で、解析エラーになることがあります。エラーが接続タイムアウト、認証拒否、内容の解析失敗のどれに当たるかを確認してから、次の対処を決めてください。接続エラーならネットワークとプロキシ経由の更新経路、認証拒否なら配信元のアクセス権、解析エラーなら形式の互換性を確認します。完全なサブスクリプションURLを公開の質問掲示板に貼らないでください。エラーメッセージに認証情報が表示されることもあります。

記録項目記録する内容記録を避ける内容
配信元用途とグループ名サブスクリプションURLを全文公開する
ローカルでの変更変更理由と対象項目認証情報をメモに記載する
更新結果成功・失敗の種類と影響範囲曖昧なエラーメッセージだけを記録する
元に戻す方法利用可能なバックアップと復元手順唯一の過去設定を上書きする

バックアップファイルも機密情報として保管してください。スクリーンショットを共有する前に、URL、認証項目、個人用のメモを隠しましょう。移行が終わったら、一時的にエクスポートしたファイルを削除してください。クライアントを入れ替える場合は、クライアントのダウンロードページからプラットフォームに合うものを選び、旧環境を削除する前に新環境の動作を確認します。複数サブスクリプションを管理する目的は、配信元、更新、ローカルの変更を追跡できるようにすることです。一覧をできるだけ長くすることではありません。各グループの用途が明確なほうが、重複した設定を大量に残すより役立ちます。

07 / 設定の組み合わせ

カスタムアウトバウンドをルーティングに接続する方法

まずアウトバウンドを定義し、次にルーティングからそのタグを参照します。アウトバウンドはコアから接続をどのように送出するかを定義し、ルーティングはどの接続をどのアウトバウンドへ割り当てるかを定義します。クライアントの「カスタム設定」は、既存設定への追加ではなく設定全体の置き換えを意味する場合があります。「カスタムアウトバウンド」も、特定の項目だけを編集できる場合があります。操作前に編集範囲を確認してください。そうしないと、アウトバウンドの設定オブジェクトだけを貼り付けたつもりが設定全体として解析されたり、クライアントが自動生成するローカル待ち受けやDNS設定を上書きしたりすることがあります。

タグとデフォルトアウトバウンドの制約

アウトバウンドのタグは、重複せず、安定していて、識別しやすい名前にします。ルーティングから参照するときは、大文字・小文字と綴りを一致させてください。サーバーのメモをタグと取り違えないようにします。一般的なV2Ray/Xray設定では、どのルールにも一致しない場合に先頭のアウトバウンドが使われますが、GUIクライアントが並べ替えたり、デフォルト項目を生成したりすることがあります。実際に動作する最終設定を基準に確認してください。特定の通信を直接接続にするために、すべてのアウトバウンドの順序を安易に変更しないでください。対象のルーティングルールを追加すれば、変更範囲が明確になり、元に戻すのも簡単です。

以下は、直接接続、ブロック、ローカルのSOCKSサービスへの接続という3種類の構成を示す基本的なアウトバウンド例です。完全な設定ではありません。3つ目の設定は、指定したローカルポートでSOCKSサービスが実際に動作している場合のみ意味があります。そのサービスの接続先を現在のコアのインバウンドポートにすると、ループが発生します。例では、補助サービスをLANに誤って公開しないようループバックアドレスを使っています。別のデバイスから接続する必要がある場合は、待ち受け範囲、認証、アクセス制御を別途設定してください。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    },
    {
      "tag": "local-socks",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 1081
          }
        ]
      }
    }
  ]
}

多重接続は複数サブスクリプションとどう違う？

複数のサブスクリプションは、複数の設定取得元を意味します。一方、多重接続では、あるアウトバウンドの基盤となる接続が別のアウトバウンドや補助サービスを経由します。具体的な項目は動作するコアやプロトコルの実装によって異なり、異なるコアの設定方法を使い回すことはできません。画面から前段プロキシを選べる場合でも、それがサブスクリプションの取得、サーバーへの接続、実際の通信のどれに適用されるかを確認してください。それぞれ適用範囲が異なります。「前段」という表示だけを見るより、各ホップの接続先と接続を担うコンポーネントを図にしてから設定するほうが確実です。

ホップを一つ増やすごとに依存関係も増えるため、障害時は外側から順に到達性を確認します。まずローカルの補助サービス単体を検証し、次にそのサービスから接続先サーバーへ接続できるか、最後に実際の通信が意図したアウトバウンドに振り分けられるかを確認してください。相互に接続先を向けたプロキシを複数同時に有効にしないでください。特にシステムプロキシ、TUN、ローカルSOCKSサービスを相互転送させないようにします。ログが急速に繰り返される場合や接続が何度も確立・切断される場合は、まずループを解消してから認証とトランスポートの項目を確認してください。

プロトコルとトランスポートのパラメーターは別々にコピーできる？

まとめて照合してください。アドレス、ポート、認証、トランスポートの種類、TLS名、追加のセキュリティ項目は、接続の成否を決める要素です。アウトバウンドのプロトコルだけを変更して以前のトランスポート設定を残すと、構文は正しくても動作しない設定になることがあります。REALITYと関連するフロー制御の項目もサーバー側に合わせてください。新しい機能に見えるという理由で独自に有効化してはいけません。項目どうしの関係はREALITYとXTLS Visionの仕組みを参照し、使用中のコアが対応する範囲を確認してください。

保存後に設定が元に戻る場合、サブスクリプション更新、テンプレート生成、画面による再書き込みなどが原因として考えられます。動作中の一時ファイルを何度も変更するのではなく、実際の設定元を特定するか、クライアントが対応する永続的なカスタム設定の項目を使ってください。カスタム設定全体を使うと、一部のGUI設定が適用されない場合もあります。画面に有効と表示されていても、対応する項目が設定に出力されているとは限りません。動作中のログ、生成された設定、実際の接続結果をあわせて判断してください。

08 / 動作確認と復旧

設定変更後の検証と復旧方法

「接続できる」を観察可能な複数の段階に分けると、変更が正しいか判断しやすくなります。サブスクリプションの更新、コアの起動、サーバーへの接続、DNSの応答、ルーティングによるアウトバウンドの選択、アプリでのアクセス完了は、それぞれ別の確認項目です。高度な設定を行う場合は、動作を確認済みの基準設定を残し、一度に一種類の設定だけを変更してください。プロトコル、DNS、TUN、ルールを同時に変更すると、接続が復旧しても、どの変更が結果に影響したのか分かりにくくなります。

テスト用の接続先を決める

自分にアクセス権があり、動作が明確な接続先を選び、直接接続、プロキシ、LAN内の各ケースを同じアプリでテストします。複数のドメイン、キャッシュ、外部リソースで構成されることがあるため、総合テスト用のWebページだけに頼らないでください。接続先、日時、現在のサーバー、モード、発生した現象を記録すれば十分です。認証情報を公開する必要はありません。テスト用ドメインのCDN接続先が変わることもあるため、一度の結果だけでルールが常に有効だと判断せず、ログで実際の一致状況を確認してください。

テスト前に既存の接続を終了してください。ブラウザーは接続を再利用することがあり、バックグラウンドアプリが長時間接続を維持している場合もあります。ルールを保存しただけでは、これらの接続が必ず再確立されるとは限りません。必要に応じてアプリを終了してから再度開き、ページを一度更新するだけで済ませないでください。比較テストでは、同じネットワーク、同じ名前解決方法、同じ接続先など、他の条件をそろえます。ネットワークを切り替えるだけでもデフォルトルートとDNSが変わるため、その後の変化すべてをクライアント設定の変更によるものと考えないでください。

ログはどこから確認する？

まず起動時に設定の読み込みが成功しているか確認し、次に対象接続付近のエラーを見ます。未対応の項目、存在しないタグ、見つからないデータファイル、ポートの競合は、起動または設定の読み込み段階で発生します。接続拒否、認証失敗、名前解決のタイムアウトは、その後の段階で発生します。対象に関するログがまったくない場合は、アプリの通信がクライアントに届いていない可能性があります。すぐにサーバーを変更しないでください。ログレベルの引き上げは短時間の調査に限り、完了後は適切なレベルに戻します。アクセス先を含む記録を長期間蓄積しないようにしてください。

確認段階正常と判断する条件失敗した場合にまず行うこと
設定の読み込みコアが起動し、項目のエラーがない直前に変更した設定部分を元に戻す
通信の到達ログにテスト対象が表示されるアプリのプロキシ設定またはTUNの通信制御を確認する
名前解決使用している解決方針に合った結果が返る問い合わせ経路とキャッシュを確認する
ルーティングの選択想定したアウトバウンドタグが使われるルールの順序、ドメイン情報、フォールバックを確認する
終了時の復旧通信制御を無効にするとネットワークが正常になるシステムプロキシ、ルート、DNSを確認する

サーバーへの接続がタイムアウトした場合は、ローカルの条件から順にリモート側へ調べます。まずシステム時刻、ネットワーク接続、サブスクリプションの設定値を確認し、次にトランスポートとセキュリティ設定に関するコアのログを確認してください。一度のサーバー一覧テストだけで、アプリから利用できることまでは判断できません。テストによってはサーバーへの接続だけを確認し、実際の接続先への通信までは確認しない場合があります。サーバーのタイムアウトを確認する手順を参照し、ローカル、通信経路、サーバー側の問題を分けて記録してください。正しく設定済みのルールを何度も変更しないようにしましょう。

実行しやすい復旧手順の組み立て方

まず直前に行った設定変更を取り消し、クライアントを再読み込みして接続を再確立します。それでも失敗する場合は、TUNや他の通信制御を無効にし、システムプロキシとDNSを元の状態に戻してください。FakeDNSを使っていた場合は、合成アドレスが残らないよう、アプリとシステムのキャッシュも処理します。復旧とは、すべての機能を無効にすることではなく、動作を確認済みの状態に戻すことです。基準となる設定を記録する際は、現在のモードとデフォルトアウトバウンドも含めてください。ルールファイルだけを戻しても、モードが異なれば別の結果になる場合があります。

バックアップは、クライアントデータ全体と他の環境でも使える設定部分に分けて管理します。データ全体は同じ環境での復元に便利で、ルールやDNSの設定部分は変更点を把握しやすい一方、どちらにも機密情報が含まれる可能性があります。クライアントのアップグレードや異なるプラットフォームへの移行前に旧設定を保存し、新しい環境で項目やデータカテゴリがサポートされるかを確認してください。他のコアが読み込める設定を共通規格だと見なさないでください。未対応の項目がある場合は、エラー項目をただ削除してコアを無理に起動するのではなく、同等の機能を設定する方法があるか調べます。

設定を元に戻したのに、症状が解消しない理由

古い接続、DNSキャッシュ、現在選択中の項目、システムに残った設定を確認してから、クライアントが書き換える一時ファイルではなく、実際の設定元を元に戻したか確認してください。それでも原因を特定できない場合は、個人情報を隠したログを保存し、ヘルプセンターで症状に当てはまる項目を確認します。初回インストールの問題はクイックスタートガイドを参照してください。

最後に、次の3点を説明できる状態を目指します。どの層を変更したか、何を根拠に設定が有効だと判断したか、失敗した場合にどう戻すか。この3点を説明できれば、設定を適切に管理できます。次に同様の問題が起きたときは、仮のルールを追加し続けるのではなく、今回と同じテスト方法と記録を活用してください。