V2Ray 上級設定：サブスクリプション、ルーティング、DNS、TUN

02 / サブスクリプション整理

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

サブスクリプションはサーバーをまとめて提供しますが、サーバー数が増えると選択の負担と誤操作も増えます。有効な整理方法は、すべてのノードを長い1つのリストに入れることではなく、まず提供元でグループ分けし、用途に応じて絞り込むことです。v2rayNでは、既定のグループ、外部サブスクリプション、自分で構築したノードを分けて管理するとよいでしょう。v2rayNGとv2flyNGでは、サブスクリプション設定やメモ欄で提供元を区別できます。グループの境界は安定させ、ノードのメモは変更できても、提供元、用途、管理担当を混在させないことが重要です。

各サブスクリプションには「日常利用」「テスト回線」「自分で構築したサービス」のように、識別しやすい名前を付けます。名前には提供元だけを表し、時間とともに変わる現在のノード状態は書き込まないでください。手動追加したサーバーは別に保存し、自動更新されるサブスクリプショングループへ移動しないようにします。更新後に上書きされたか判断しづらくなるためです。使わなくなったサブスクリプションは、まず自動更新を停止してしばらく様子を見てからグループを削除します。すぐに空にすると、既存のメモや選択履歴も失われます。

フィルターで解決する問題

サーバーフィルターは、長いリストから候補を絞り込むために使います。一般的な条件は、メモのキーワード、プロトコルの種類、トランスポート方式、サブスクリプションの提供元です。フィルター条件はまず説明可能であるべきです。キーワードを1つ入力したとき、サーバーのメモを見れば一致した理由が分かる状態にします。複雑な正規表現は柔軟ですが、サブスクリプション側の命名が少し変わるだけで選択漏れが起こります。同じサブスクリプション内でメモの形式を統一し、地域、用途、回線種別をキーワードにする方法が安定します。

絞り込みとルーティングは別のものです。絞り込みは画面に表示するサーバーや一括テストの対象を決め、ルーティングは接続後の各リクエストがどのアウトバウンドを通るかを決めます。サーバーフィルターで通信の分流を代用したり、ノードを非表示にしただけで設定から完全に削除されたと考えたりしないでください。クライアントによっては、フィルターがリスト表示だけを変え、使用中のノードは引き続き動作します。一括削除の前に、現在の選択項目とグループ範囲を確認してください。

キーワードと正規表現を使い分ける

日常の選択には、「仕事用」「自作」「プロトコル名」のような単純なキーワードが適しています。複数の候補語を指定する場合は、正規表現の選択記号を使えます。テストノードを除外する場合は否定条件も使えますが、まず小さな範囲で検証してください。クライアントによってフィルターの入口や正規表現の対応範囲が異なるため、式をコピーする前に、対象がサーバーのメモ、アドレス、完全な表示名のどれか確認します。以下の式は、特定のノード数や速度データに依存しない一般的な考え方を示します。

仕事用|自作
^(?!.*テスト).*
(VLESS|VMess|Trojan)

1行目はメモに「仕事用」または「自作」を含む項目に一致します。2行目は「テスト」を含む名前を除外します。3行目は表示名に含まれるプロトコル名で絞り込みます。サブスクリプションの命名方法が異なる場合は、実際のメモを確認してから調整してください。結果が空になったら、まず境界記号と除外条件を外し、基本キーワードが一致することを確認してから条件を少しずつ追加します。最初から長い式を書くと、どの部分で不一致になったか分かりにくくなります。

更新、重複排除、無効項目への対応

サブスクリプションの更新は、まず1つのグループだけで実行します。更新後は項目が正常に解析されたことを確認してから、使用中のノードを切り替えます。同じサーバーがメモの違いで重複して表示されることもあれば、パラメーターが異なるためアドレスだけ同じに見えることもあります。重複排除ではドメインとポートだけでなく、ユーザー識別子、プロトコル、トランスポート方式、TLS、パスなどの重要なパラメーターも比較してください。完全に一致する項目には自動重複排除が適していますが、差異がある場合は残して名前を付け直す方が安全です。

無効な項目は、一時的に到達できないもの、パラメーターが誤っているもの、サブスクリプション提供元が取り消したものの3種類に分けられます。1回の接続失敗だけで長期的な無効化と判断せず、まずローカルネットワークを切り替えるか、回線の復旧を待ちます。プロトコル解析エラーが続く場合は、現在のクライアントが認識できないフィールドをサブスクリプションが使っていないか確認します。更新後にサブスクリプションから消えた項目は、通常は提供元による取り消しです。自動更新グループへ手動で戻すことはおすすめしません。速度測定は現在のネットワーク条件での比較に使うもので、永久的な順位付けの根拠にはなりません。

3つのクライアントで異なるグループ管理のポイント

v2rayNはデスクトップのリスト領域が広く、複数サブスクリプションの管理、一括更新、細かな絞り込みに適しており、デスクトップでは第一候補です。v2rayNGはタッチ操作のリストを使うため、同時に有効化するサブスクリプションを減らし、短い名前と明確な接頭辞を使うとよいでしょう。v2flyNGの管理方法はAndroidの利用感覚に近い一方、コアの系統が異なります。同じサブスクリプションを読み込んでも、プロトコルとトランスポートのパラメーターが完全に認識されているか確認してください。再インストールやプラットフォーム変更が必要な場合は、ダウンロードページでシステムに合うクライアントを選びます。

整理が終わったら、復元性を確認します。現在使用中のサブスクリプションとサーバーを記録し、1つのグループだけ手動更新して、自作ノードが変わらないことを確認します。その後クライアントを再起動し、選択状態が保持されるか確認してください。更新後に使用中の項目が切り替わった場合は、自動選択が有効になっていないか、現在の項目がサブスクリプションで置き換えられていないかを確認します。サブスクリプションURLは継続して利用する認証情報にあたるため、公開スクリーンショット、ログ、共有ルールファイルに記載しないでください。トラブル対処では、解析結果とエラーの種類だけを伝えれば十分です。

04 / 名前解決

DNS設定の最適化と分流解析

DNS設定は、ドメインからアドレスを取得する方法を決め、ドメインルールとIPルールの連携にも影響します。システムDNS、クライアント内蔵DNS、ブラウザーの暗号化DNS、アプリ独自の解決が同時に存在することがあります。クエリが想定した経路を通らないと、「ルーティングは正しいのにアウトバウンドを誤る」状態になります。最適化の前に、どこからクエリが送られているか確認してください。システムプロキシは通常、すべてのDNSを自動的に引き受けません。TUNモードはシステムのクエリをクライアントへまとめて送るのに適していますが、ブラウザーやアプリが独自に発行する暗号化クエリにも対処が必要です。

DNS分流の基本目標は、ドメインごとに適切なDNSサーバーを選び、クエリ自体も正しいアウトバウンドから送ることです。ドメイン分類、問い合わせ先サーバー、ルーティングのアウトバウンドは、それぞれ独立した判断です。ドメインを特定のDNSサーバーへ割り当てても、業務接続が同じアウトバウンドを使うとは限りません。対応するルーティングルールも必要です。逆に、業務ルーティングだけを書いて解決経路を処理しないと、アプリが不適切なアドレスを先に取得し、誤ったIPルールに一致することがあります。

サーバーの順序と一致範囲

コアのDNSには複数のサーバーを設定し、サーバーごとにドメインの一致リストを付けられます。専用の一致条件は汎用サーバーより前に置きます。内部ドメインはLANのDNSへ送り、指定した外部ドメインは暗号化クエリを使い、その他は既定のサーバーへ渡せます。クライアントが skipFallback のような制御項目に対応していれば、一致済みのドメインをフォールバックサーバーへ再度問い合わせないようにできます。ただし有効化する前に専用サーバーの安定性を確認してください。専用サーバーから結果を得られない場合でも、フォールバックへ自動移行しなくなるためです。

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "192.168.1.1",
        "domains": [
          "full:intranet.example",
          "domain:office.example"
        ],
        "skipFallback": true
      },
      {
        "address": "https://dns.example/dns-query",
        "domains": [
          "domain:service.example"
        ]
      },
      "localhost"
    ]
  }
}

例では内部ドメインをLANのDNSサーバーへ送り、指定したサービスをサンプルの暗号化問い合わせ先へ送り、その他のリクエストはローカルの名前解決を使います。実際の設定では、暗号化問い合わせ先のドメイン自体も解決して接続を確立する必要があります。この初期解決を、まだ使えない同じ暗号化経路に依存させてはいけません。システムまたは基本DNSで問い合わせ先のドメインを先に解決するか、クライアントが対応するブートストラップ機構を使います。ログに問い合わせ先ドメインの解決失敗が続く場合は、まずこの依存関係を解消してください。

問い合わせ戦略とアドレスファミリー

queryStrategy は返すアドレスの種類を制御します。UseIP は利用可能なアドレスファミリーを使い、UseIPv4 はIPv4だけ、UseIPv6 はIPv6だけを要求します。選択は、ローカルネットワークとアウトバウンド経路が該当するアドレスファミリーを完全にサポートしているかで決めます。システムがIPv6アドレスを取得しても、プロキシ経路がIPv6接続を確立できなければ、アプリは失敗を待ってからフォールバックし、初回アクセスが明らかに遅くなることがあります。その場合は一時的にIPv4戦略で確認できますが、長期的にはローカルネットワーク、ノードのアウトバウンド、ルーティングルールがIPv6をどう扱うかを確認してください。

すべての名前解決問題を固定のアドレスファミリーで隠さないでください。サービスによってはアドレスファミリーごとに接続先が異なり、LAN内のサービスも特定のアドレスファミリーでしか利用できないことがあります。変更後は、内部ドメイン、よく使う公開ドメイン、IPアドレスだけの接続をそれぞれテストし、他の経路を壊していないことを確認します。1つのアプリだけ異常なら、独自DNSや接続最適化機能が有効になっていないか確認してください。そのアプリのクエリはクライアントに入っていない可能性があります。

DNSとルーティングの連携

DNSクエリ自体もネットワーク通信であり、直接接続かプロキシかをルーティングで決める必要があります。暗号化DNSが通常のTCPまたはHTTPS接続を使う場合、サーバーのドメインまたはIPに基づいてアウトバウンドを指定できます。クエリをプロキシ経由で送る場合は、解決より前にプロキシのアウトバウンドが接続可能なサーバーアドレスを持っていることを確認します。ノードのサーバーアドレスにドメインを使う場合は、起動時の解決依存に特に注意が必要です。最も安定する起動経路は、基本DNSでノードのサーバードメインを解決し、確立済みのプロキシで後続の専用クエリを処理する方法です。

ルーティングで IPIfNonMatch を使うと、ドメインルールに一致しなかった場合にDNS解決が発生し、その後IPルールと照合されます。このとき、DNSサーバーが返すアドレスがルーティング結果を直接左右します。同じドメインに複数のアドレスがあると、キャッシュ結果の変化によって異なるルールに一致することがあります。安定したドメインルールを優先し、IPルールは地域集合、プライベートアドレス、アドレス単位の判定が本当に必要な対象に使ってください。各ドメインのアドレスを手作業で管理する用途には向きません。

キャッシュ、漏洩経路、確認方法

DNSを確認するときは、ブラウザー独自の解決機能を無効にするか、テスト対象に含めることを明確にします。クライアントに再接続してから、システムとブラウザーの関連キャッシュを消去し、新しいクエリを1回発行します。ログにはドメイン、選択されたDNSサーバー、返されたアドレス、後続の業務接続のルーティング結果が表示されるはずです。Webベースの検査ツールだけでは、すべてのシステムクエリ経路は分かりません。確認できるのは現在のブラウザーであり、ターミナル、バックグラウンドサービス、他のアプリではないためです。

通常のシステムプロキシ使用時もDNSがローカルネットワークで処理されるなら、それは接続範囲の違いであり、必ずしも設定ミスではありません。より多くのアプリをまとめて接続する必要がある場合にTUNを有効にし、DNSには明確なインバウンドとルーティングを設定します。TUN有効後に解決ループが起きたら、DNSクエリが再びTUNへ入っていないか、問い合わせ先サーバー用の直接接続またはプロキシ例外が不足していないか、FakeDNSと実DNSのルールが重複していないかを確認してください。分流解析の詳しい例は、V2Ray DNS分流解析設定の詳しい解説でも確認できます。

05 / ドメインマッピング

FakeDNSの仕組みと適用範囲

FakeDNSは、ドメインに対して予約アドレスプール内の一時アドレスを返し、コア内部にドメインとそのアドレスの対応を保存します。アプリがこの一時アドレスへ接続すると、コアは対応表から元のドメインを復元し、ルーティングと実際の接続を実行します。主な用途は、アプリが先に独自のDNSクエリを発行し、その後IP接続だけをTUNへ渡すことで、コアが元のドメインを失い、ドメインルールに一致できなくなる問題の解決です。FakeDNSは後続の接続段階までドメイン情報を保持するため、分流の判定が安定します。

FakeDNSは通常のDNSサーバーの代わりではなく、すべての名前解決を改善するものでもありません。コアがドメインを復元した後も、実際の接続には設定に従った解決、または対応するアウトバウンドが必要です。ルーティング、実DNS、アウトバウンドの設定が誤っていれば、FakeDNSによって問題が見えにくくなるだけです。そのため、TUNの基本経路と通常のDNSが安定してから有効にし、どのクエリをFakeDNSへ送り、どの内部ドメインが実アドレスを返す必要があるかを明確にします。

アドレスプールとマッピング容量

FakeDNSの設定にはアドレスプールとマッピング容量が含まれます。アドレスプールには専用の予約範囲を使い、LAN、企業ネットワーク、コンテナネットワーク、既存の仮想インターフェースと重複させないでください。重複すると、システムが一時アドレスを実ネットワークへ送ったり、実際の内部アドレスをFakeDNSへ渡したりすることがあります。容量は同時に保存できるドメインマッピング数を決めます。容量不足で古いマッピングが破棄されると、アプリが古いアドレスを保持している間にドメインを復元できなくなることがあります。通常はクライアントの既定値を使い、大量のドメインを同時に扱い、ログでマッピングの破棄を確認した場合だけ調整してください。

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

198.18.0.0/15 は、仮想マッピングに使われることが多いベンチマーク用の予約アドレス範囲です。使用前に、ローカルネットワークや他のツールがこの範囲を使っていないか確認してください。設定断片はコア内のFakeDNSオブジェクトを表すだけです。クエリを実際に送り込むには、対応するDNS設定、インバウンドのスニッフィング、TUN接続も必要です。オブジェクトを単独で追加しても、システムのクエリ経路は自動的に変わりません。

スニッフィングと対象の上書き

インバウンドのスニッフィングは、接続からドメインやプロトコル情報を識別します。FakeDNSと組み合わせる場合、一般的な対象の上書きにはHTTP、TLS、FakeDNSマッピングが含まれます。対象の上書きを有効にするかは、クライアントのテンプレートに従って決めてください。上書きによってルーティングで復元後のドメインを使える一方、特殊な接続の対象処理が変わる可能性もあります。まずクライアントが提供する標準のFakeDNSモードを使い、生成された設定を確認してからカスタマイズします。すべてのプロトコル識別オプションを一度に有効にしないでください。

{
  "inbounds": [
    {
      "tag": "tun-in",
      "protocol": "tun",
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls",
          "fakedns"
        ],
        "routeOnly": true
      }
    }
  ]
}

routeOnly は、識別結果を主にルーティング判定に使い、最終的な接続先を直接置き換えないことを示します。対象の書き換えによる影響を抑えたい環境に適しています。対応するフィールドが現在のコアとクライアントの設定方式で使えるかどうかは、クライアントの生成結果を基準にしてください。設定読み込み時に未知のフィールドが報告された場合は、まずカスタム断片を取り消し、画面のFakeDNSオプションを使ってから、コアの系統と設定形式が一致しているか確認します。

FakeDNSに渡さない方がよい対象

LANのドメイン、企業内部のドメイン、プリンターや検出サービスは、通常実アドレスが必要です。FakeDNSをバイパスして内部DNSへ渡してください。ローカルアドレスの判定、証明書のバインディング、特殊な解決結果に依存するアプリも、仮想マッピングに適さない場合があります。除外ルールはできるだけ具体的にし、明確な内部ドメインと予約済みサフィックスを先に除外してから、他の異常がないか確認します。広範囲のドメインをすべて除外すると、FakeDNSでドメインを保持する意味が失われます。

アプリによっては、DNSの返却アドレスを検証したり、システムの名前解決を迂回したり、独自の暗号化クエリを使ったりします。前2者ではFakeDNSが機能しないことがあり、後者ではクエリが通常のHTTPS接続としてTUNへ入るため、コアは接続の特徴からドメインの復元を試みるしかありません。ログにFakeDNSのクエリが表示されない場合は、アドレスプールを何度も変更せず、まずアプリのクエリがクライアントへ入っているか確認してください。

よくある障害の確認順序

有効化後にまったく解決できない場合は、DNSがクエリをFakeDNSへ送っているか確認します。一時アドレスは返るのに接続できない場合は、TUNがそのアドレス範囲を接続対象にしているか、インバウンドがドメインを復元できるか確認します。内部サービスだけが失敗する場合は、内部ドメインの除外とLANのDNSを確認します。しばらく使った後に断続的に失敗する場合は、マッピング容量、アプリのキャッシュ、スリープ復帰を確認します。症状ごとに該当する層は異なるため、DNSサーバーの変更だけですべてを解決しようとしないでください。

確認では、クエリが予約アドレスを返したかを確認し、コアのログで同じアドレスが元のドメインへマッピングされ、最終アウトバウンドへ進んだことを確認します。システムツールで一時アドレスへ直接接続しても、サーバーの到達性は判断できません。一時アドレスは実サーバーを表していないためです。FakeDNSを無効にした後は、アプリとシステムの関連DNSキャッシュを消去し、無効になった一時アドレスへアプリが接続し続けないようにします。

実DNSの分流と併用する

成熟した設定では、FakeDNSと実DNSを併用します。一般的な公開ドメインには一時アドレスを返してドメインを保持し、内部ドメインはLANのDNSへ直接問い合わせ、ノードのサーバードメインは基本DNSで起動時に解決し、指定した一部のサービスだけ専用の暗号化クエリを使います。各ドメイングループには明確な優先順位を設定し、同じ対象が内部DNSにもFakeDNSにも一致しないようにします。変更後は、公開Webページ、内部サービス、ノードの再接続、システムのスリープ復帰を個別にテストし、ライフサイクルの変化後もマッピングを再構築できることを確認してください。

08 / アウトバウンド構成

カスタムアウトバウンド、チェーン転送、体系的なトラブル対処

アウトバウンドは、ルーティング判断の最終的な送信先です。一般的なアウトバウンドには、プロキシノード、直接接続、ブロック、ローカルまたは上流のSOCKSサービスへの転送があります。カスタムアウトバウンドは、特定の業務を独立した出口へ送る、ローカルの既存サービスを再利用する、検証経路を明確にする場合に適しています。重要なのは、タグが一意で、プロトコルパラメーターが完全で、依存関係にループがないことです。ルーティングはタグでのみアウトバウンドを参照するため、名前を変更したらすべてのルールも更新してください。

GUIクライアントは通常、現在のノードから主要なプロキシアウトバウンドを生成し、直接接続とブロックのアウトバウンドも追加します。手動で拡張するときは、クライアントの統合方法を確認していない限り、これらの基本オブジェクトを上書きしないでください。より安全なのは、クライアントが提供するカスタム設定、事前設定、テンプレートの入口を使い、一意のタグを新しく作り、具体的なルーティング1本でテストする方法です。実行時ファイルを直接編集すると、ノード切り替えや再起動後に無効になり、画面表示と実際の設定が一致しなくなる可能性もあります。

ローカルSOCKS上流を追加する

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

例では local-socks という名前のアウトバウンドを作り、ローカルホストの1081番ポートで待ち受けるSOCKSサービスへ接続を渡します。使用前にポートが実際に待ち受けていることを確認し、その通信が同じTUNに再び捕捉されて自分自身へ戻らないようにしてください。上流に認証が必要な場合は、クライアントが対応する設定構造へ実際の認証情報を追加し、ローカルだけに保存します。テストでは、まず明確な1つのドメインをこのアウトバウンドへ向け、いきなり全通信を切り替えないでください。

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": [
          "domain:service.example"
        ],
        "outboundTag": "local-socks"
      }
    ]
  }
}

ルール内のタグは、アウトバウンドのタグと一字一句一致させる必要があります。設定の読み込みに失敗した場合は、まずJSON構造、余分なカンマ、フィールドの位置を確認します。読み込みは成功したのに上流を通らない場合は、ルールの順序とドメインの一致を確認します。一致しているのに接続できない場合に、ローカルポート、上流の認証、ルーティングループを調べます。ノードを何度も交換するより、層ごとに確認する方が早く解決できます。

チェーン転送のリスク管理

チェーン転送では、1つのアウトバウンドが別のアウトバウンドを経由して接続を確立します。明確なネットワーク構成がある環境には適していますが、名前解決の依存、接続層、障害点が増えます。開始前に経路を図にしてください。アプリがどのインバウンドへ入り、ルーティングがどの業務アウトバウンドを選び、そのアウトバウンドがどの前段アウトバウンドを通り、ノードのサーバードメインを誰が解決するのかを確認します。経路のどこかが前の入口へ戻ると、ループになる可能性があります。

チェーン構成を曖昧なグローバルルールで実現しないでください。前段アウトバウンドと業務アウトバウンドには明確なタグを付け、上流サーバーのアドレスには必要な直接接続または指定ルーティングを設定し、チェーンを経由しない基本接続を切り戻し用に残します。タイムアウトが起きたら、まず各ホップを個別に確認し、その後に組み合わせてテストします。単独では使えるのに組み合わせると失敗する場合は、DNSの起動依存、UDP対応、TUNによる上流接続の再捕捉を重点的に確認します。

直接接続とブロックのアウトバウンド

直接接続のアウトバウンドは、LAN、内部サービス、プロキシが不要な対象に使います。ブロックのアウトバウンドは、接続を明確に拒否するために使います。ブロックルールは具体的にし、広範囲のプロキシルールより前に置いてください。広い分類を直接使うと、ログイン、決済、更新、埋め込みリソースに影響することがあります。追加後は、ページのメインドメインとリソースのドメインを確認します。特定のアプリだけプロキシを使わせたくない場合は、まずプロセスルールやインバウンド分離を使います。クライアントとコアが安定したプロセス識別に対応しない場合は、説明可能なドメインとIPの条件を使ってください。

直接接続は、すべてのクライアント処理を迂回するという意味ではありません。通信がまずTUNへ入り、コアが直接接続のアウトバウンドを選ぶこともあれば、システムルートでTUNを直接迂回することもあります。2つの方法では、ログ、DNS、ローカルサービスとの互換性に違いがあります。ログを記録してルーティングを統一する必要がある場合は、通信をコアへ入れてから直接接続させます。LAN検出やデバイスアクセスなどローカルネットワークに敏感な通信は、通常システムルートで迂回させ、プライベートアドレスの直接接続ルールも残す方が適しています。

ログからトラブル対処マトリクスを作る

上級設定のトラブル対処では、4つの質問に答えます。通信はクライアントへ入っているか、ドメインは誰が解決しているか、どのルールが一致したか、最終アウトバウンドは接続を確立したかです。ログレベルはトラブル対処中だけ上げ、完了後は通常レベルに戻します。記録が増えすぎると確認しにくくなります。ログに対象リクエストがない場合は、システムプロキシ、アプリのプロキシ、TUNを確認します。リクエストはあるのにドメインがない場合は、DNS接続とスニッフィングを確認します。ルーティングタグが誤っている場合は、ルールの順序を調整します。アウトバウンド接続が失敗する場合は、対応するサーバーと上流を確認します。

長期的に保守できる設定を作る

保守しやすい設定では、ノード名、一時アドレス、画面上の並び順への依存をできるだけ減らします。ルーティングは安定したアウトバウンドタグを参照し、DNSは明確なドメイングループを使い、サブスクリプションは提供元ごとの境界を保ち、TUNとFakeDNSは必要な場合だけ有効にします。各カスタムオブジェクトには用途を記載し、正常に動作する基本設定を残してください。障害が起きたら、直近に追加したオブジェクトをまず無効にし、基準状態が戻ったことを確認してから、問題を1つのルールまたはアウトバウンドに絞り込みます。

設定後は4回の受け入れ確認を行います。クライアントを再起動して設定を読み込めることを確認し、ノードを切り替えてルーティングが古いノードに依存していないことを確認します。サブスクリプションを更新して、カスタムグループとタグが上書きされていないことを確認し、システムを再起動してTUN、DNS、システムプロキシが正しく確立・復元されることを確認します。Webページを1回開くだけでは完了とはいえません。内部ネットワークを使う場合は、LANサービス、内部ドメイン、システムのスリープ復帰も確認してください。

問題を特定できない場合は、まずクイックスタートの基本手順に戻って最小構成の接続を確認し、次にヘルプセンターでインストール設定とトラブル対処の項目を確認してください。システムプロキシ、DNS、速度の差異が関係する場合は、サイト内の技術ノートにある層別の事例も参考にして、引き続き確認できます。