V2Rayクライアントのインストールサブスクリプション・プロキシ・トラブル対処

事前準備：プラットフォーム、サブスクリプション、設定のバックアップ

クライアント、コア、ノードの違い

v2rayNはデスクトップ向けのノード一覧、サブスクリプション管理、プロキシ接続、コアの実行を担います。v2rayNGとv2flyNGはAndroid向けの操作画面を提供します。コアはプロトコルの処理、ルーティング、接続の確立を担当し、ノードは接続先サーバーの設定情報です。クライアントをインストールしただけでは、接続可能なノードは使えません。利用前に、有効なサブスクリプションURL、共有リンク、または完全な設定ファイルを用意し、利用権限のあるサービスから提供されたものか確認してください。

デスクトップではv2rayNがおすすめです。Androidでは、まずXrayコアを使用するv2rayNGを試してください。V2Flyの設定が必要な場合は、v2flyNGを検討します。同じプロトコル名でも、拡張フィールドがすべて互換性を持つとは限りません。トランスポート方式、セキュリティ設定、コアの対応状況を合わせて確認してください。インポートできても接続できない場合は、クライアントを次々に入れ替える前に、設定元が指定するコアを確認しましょう。

インストーラーはCPUアーキテクチャにも合わせる必要があります。このページではWindows向けに、ダウンロードページで提供するx64デスクトップ版とWPF版を説明します。macOSはApple SiliconとIntel、Linuxはアーキテクチャとパッケージ形式、Androidはarm64版と汎用版を区別します。OS名、CPUアーキテクチャ、アプリの画面方式はそれぞれ別の要素です。ファイル名にOS名が含まれているだけで適合すると判断しないでください。

サブスクリプション情報と端末環境の確認

サブスクリプションURLには認証情報が含まれることが多く、パスワードと同じように慎重に管理してください。コピー時は前後の空白、改行、チャットアプリが付加した句読点がないか確認します。スクリーンショットを共有する場合は、URL、ユーザー識別情報、ノードの認証情報を隠してください。更新に失敗しても、URLの期限切れやWebページが返されたことが原因かもしれません。ステータス欄のエラーだけでソフトウェアの破損とは判断できません。エラーの概要だけを記録し、個人用URL全体を公開の掲示板に投稿しないでください。

接続前に、システムの日付、時刻、タイムゾーンが正しいことを確認し、自動時刻合わせを有効にしてください。証明書の検証や一部プロトコルのハンドシェイクには正確な時刻が必要です。時刻が大きくずれていると、安全な接続に失敗することがあります。基本のネットワーク接続、ネットワークへのログインの要否、ほかのプロキシや仮想ネットワークアダプターの稼働状況も確認しましょう。最初のテストでは通信を振り分ける仕組みを1つだけ使い、リクエストの経路を把握しやすくします。

サブスクリプション、共有リンク、ネイティブJSONは異なる形式です。サブスクリプションは通常、複数ノードの一括更新に使います。共有リンクは通常、単一ノードを表します。ネイティブJSONには、インバウンド、アウトバウンド、ルーティング、DNSを含む設定一式が記述されている場合があります。クライアントに合ったインポート方法を使い、完全な設定ファイルをサブスクリプションURLとして更新しないでください。形式の違いについては、サブスクリプションと共有リンクの違いもご覧ください。

元に戻せる最小構成から始める

初期設定に必要なのは、有効なノード、通信の振り分け方法1つ、明確なルーティングモードです。最初からカスタムDNS、複雑なルール、アプリごとの振り分けを追加するのは避けましょう。サブスクリプションの更新、ノードへの接続、ブラウザーからのアクセスをそれぞれ確認してから、設定を1つずつ追加します。変更前後を比べやすくなり、問題が起きても直前の正常な状態に戻せます。複数の設定を同時に変更して、原因を見失うことも防げます。

アップグレードや移行の前に、クライアントのバックアップ・エクスポート機能で設定を保存してください。手動でバックアップする場合は、クライアントを完全に終了してから実際の設定フォルダーをコピーします。インストール方法によってデータの保存先は異なるため、画面やログで確認し、古い情報にあるパスを信じてファイルを上書きしないでください。バックアップにはサブスクリプショングループ、ルーティング設定、必要なカスタム設定を含めます。ノードの認証情報が漏れないよう、バックアップファイルへのアクセスも制限してください。

Windows：v2rayNのインストールとシステムプロキシ

デスクトップ版と従来のWPF版を選ぶ

Windows版インストーラーからv2rayNを選択します。デスクトップ版は新世代のクロスプラットフォームUIを採用し、WPF版は従来のデスクトップ操作を引き継いでいます。どちらを選んでも、ノードサービス自体は同じです。使い慣れた画面がある場合はそれに合わせ、初めて使う場合はデスクトップ版から試せます。ダウンロードページの提供パッケージはx64版です。インストール前にシステム情報でCPUアーキテクチャを確認し、OSが動作要件を満たしているかチェックしてください。

インストーラーを実行し、画面の案内に従ってインストール先を選びます。ダウンロードしたものが解凍して実行する形式の場合は、安定した場所にすべて展開してからメインプログラムを起動してください。圧縮ファイルのプレビューから直接実行してはいけません。フォルダーは一時的なダウンロード先を避け、付属ファイルを残さずメインプログラムだけをコピーすることも避けてください。コア、ルールデータ、実行に必要なファイルが不足すると、画面は開いても接続時に失敗することがあります。

通常のシステムプロキシを試す段階では、最初から管理者権限で常用する必要はありません。通常のユーザーとして起動し、ログで待ち受けポートの作成、設定の読み込み、コアの起動を確認してください。セキュリティ機能がコンポーネントをブロックした場合は、対象ファイルと操作の出所を確認します。セキュリティ機能全体を無効にしないでください。TUN操作で昇格が必要な場合は個別に対処し、パスの誤りやポートの競合を権限の引き上げで隠さないようにしましょう。

サブスクリプションをインポートして接続する

サブスクリプション管理でグループを追加し、識別しやすい名前と完全なURLを入力して保存したら、そのグループを更新します。画面によってメニュー名は多少異なりますが、登録とノードの取得は通常別の操作です。更新後、グループ内にノードが表示されるか、ログに認証エラー、解析エラー、形式不一致がないか確認してください。ノードが空のグループを、インポート済みと勘違いしないようにしましょう。

新しいグループからノードを選び、有効な設定として指定してから実際に接続します。遅延測定で応答があっても、プロトコルのハンドシェイク、接続先へのアクセス、DNSがすべて正常とは限りません。まず接続テストが完了するノードを選び、名前とプロトコルを記録しましょう。グループ内のノードがすべて失敗する場合は、サブスクリプションの有効性とシステム時刻を確認します。1つだけ失敗する場合は、全体設定をリセットする前に、同じグループの別ノードを試してください。

コアを起動してシステムプロキシを有効にすると、システム設定に従うアプリの通信がローカルの待ち受けアドレスに送られます。プロキシモードの名称は画面によって異なります。重要なのは、システムに設定が反映され、クライアントが引き続き実行中であることです。次にブラウザーで利用可能なテストページを開き、出口IPとクライアントログを確認して、想定したアウトバウンドを通っているか判断します。詳しい確認方法は初回接続とプロキシの動作確認をご覧ください。

システムプロキシの範囲とTUNのトラブル対処

システムプロキシですべてのプログラムの通信が自動的に振り分けられるわけではありません。コマンドラインツール、ゲーム、独自のネットワーク機能を持つアプリでは、個別にプロキシ設定が必要な場合があります。ブラウザー拡張機能がシステム設定より優先されることもあります。ブラウザーは使えても特定のアプリだけ失敗する場合は、そのアプリがシステムプロキシを参照するか、どの通信方式を使うか、独自のネットワーク設定がないか確認してください。1つのアプリがプロキシを使わないだけで、ノード全体が使えないとは限りません。

より広い範囲の通信を振り分ける必要がある場合は、使用中のv2rayN、選択したコア、システム環境がTUNに対応しているか確認してください。有効にする前にシステムプロキシの状態と元のネットワーク設定を記録し、案内に従って必要な権限やコンポーネントを設定します。ほかの仮想ネットワークアダプターを使うアプリを停止してから、LAN、名前解決、接続先へのアクセスを確認してください。TUNは通信をクライアントに取り込む方法であり、直接接続かプロキシ接続かはルーティングで決まります。

終了後にネットワークがおかしくなった場合は、まずWindowsの手動プロキシが、停止したローカルポートを指したままになっていないか確認してください。元の設定に戻してから再テストします。ポートの競合はログで該当ポートを特定し、クライアントの二重起動を解消するかローカルの待ち受け設定を変更します。リモートサーバー側のポートは変更しないでください。アップグレード後のルール消失、起動パスの変更、自動起動の失敗も、それぞれ個別に確認します。ノード障害と混同しないようにしましょう。

macOS：チップに合ったパッケージとネットワーク権限

チップに合ったv2rayNをインストールする

システムの「このMacについて」でチップ情報を確認し、macOS版インストーラーから適切なv2rayNを選びます。Apple Siliconはarm64版、Intelはx64版です。パソコンの外観、購入年、製品名からアーキテクチャを推測しないでください。アーキテクチャが合わないと、起動できない、互換環境が必要になる、コンポーネントが正常に動作しないといった問題が起きます。こうした場合はサブスクリプションを変更する前に、ダウンロードしたパッケージを確認しましょう。

DMGを開き、インストーラーの案内に従ってアプリケーションフォルダーにアプリを配置してから、安定した場所から起動します。マウントしたインストールイメージから長期間実行しないでください。イメージの取り出し、ダウンロードファイルの削除、再ログイン後に、起動パスが無効になることがあります。初回起動時にセキュリティ警告が表示された場合は、アプリの提供元とファイルを確認したうえで、システム標準の「開くことを許可」する手順を使います。セキュリティ設定全体を無効にする必要はありません。

ウィンドウが表示されても、必要なネットワーク権限がすべて設定済みとは限りません。システムプロキシの変更、バックグラウンドコンポーネント、TUNによる通信の振り分けでは、実際に機能を有効にしたときに許可を求められることがあります。権限の内容を確認し、使用する機能に必要なものだけを許可してください。過去に要求を拒否した場合は、システム設定で該当項目を確認します。起動を何度も繰り返しても権限は付与されません。また、権限ダイアログのエラーをリモートノードへの接続失敗と混同しないでください。

サブスクリプション、システムプロキシ、接続確認

サブスクリプション管理でグループを追加してURLを保存し、グループを更新してノード一覧が実際に更新されたことを確認します。別の端末からURLをコピーする際は、クリップボードに空白や改行が含まれないか確認してください。同じURLがほかの端末では使えるのに、このMacではノードが表示されない場合は、更新ログと現在のネットワークのアクセス条件を確認します。共有リンクは専用のインポート方法で取り込み、完全なネイティブ設定はクライアントが対応するカスタム設定の手順で扱ってください。

ノードを1つ選んでコアを起動し、まず接続テストが完了することを確認してからシステムプロキシを有効にします。macOSのプロキシ設定はネットワークサービスごとに関連付けられており、Wi-Fi、有線LAN、その他のサービスで状態が異なることがあります。ネットワークを切り替えて動作が変わった場合は、別のインターフェースではなく、実際に使用中のネットワークサービスを確認してください。クライアントの表示だけでなく、現在のネットワーク設定も照合しましょう。

ブラウザーがシステムプロキシを使うかどうかは、ブラウザー独自の設定にも左右されます。テスト中はプロキシを制御する拡張機能を一時的に無効にし、経路を1つに絞って、到達可能なページを開きながらログを確認してください。ページが表示されても、すべての通信が振り分けられたとは限りません。直結で表示されている可能性もあります。プロキシが必要な接続先は、ルーティングログと出口情報で判断します。すべてのサイトで同じ出口が表示される必要はありません。

TUN、スリープ、ネットワークサービスの切り替え

システムプロキシに従わないアプリがある場合は、クライアントとシステムの対応状況を確認してTUNを検討してください。有効にする前に、ネットワークフィルター、仮想ネットワークアダプター、トンネル機能が通信経路を使っていないか確認し、デフォルトルートを複数の機能で同時に振り分けないようにします。権限を許可した後、まず基本の名前解決を確認し、次に接続先とLANへのアクセスをテストします。有効化後に端末全体がネットワークにつながらなくなった場合は、TUNを無効にしてシステムプロキシの状態に戻し、ルーティングとDNSを確認してください。

スリープからの復帰後や、有線からWi-Fiに切り替えた後は、既存の接続が切れてもローカルの待ち受けが残っている場合があります。まず基本のネットワーク接続が復旧しているか確認してから、接続またはコアを再起動してください。すぐにサブスクリプションを削除する必要はありません。名前解決だけが失敗する場合は、システムDNSとクライアントDNSが実際に使われる経路を確認します。すべての接続がタイムアウトする場合は、ノードへの到達性、ネットワークへのログイン状態、無効なルーティング設定が残っていないかを調べましょう。

設定の移行には、まずクライアントのエクスポート・インポート機能を使ってください。別の端末の実行フォルダー一式で、このMacのアプリを上書きしないでください。アーキテクチャの異なる実行コンポーネントは互換性がなく、設定内の絶対パスも移行先では使えないことがあります。アップグレード前にサブスクリプション、ルーティング、カスタム設定をバックアップし、アップグレード後はコアの起動、システムプロキシ、必要な権限を順に確認します。完全に終了したらプロキシが元に戻ったことを確認し、停止したローカルサービスへのアクセスが残らないようにしてください。

Linux：パッケージ形式、デスクトッププロキシ、権限

ディストリビューションの形式とアーキテクチャを確認する

Linux版インストーラーからv2rayNを選びます。deb形式を使うディストリビューションでは対応するdebパッケージ、rpm形式を使うディストリビューションではrpmパッケージを選び、さらにx64かarm64かを確認します。デスクトップ環境の名称だけではパッケージ形式は決まりません。CPUメーカー名もアーキテクチャの確認にはなりません。システム情報でディストリビューションとアーキテクチャを確認してください。コマンドで確認する場合は、システム設定を変更しない次の読み取り専用コマンドを使えます。

uname -m
cat /etc/os-release

x86_64は通常、ダウンロードページのx64に、aarch64は通常arm64に相当します。確認後、ダウンロードしたパッケージをグラフィカルなソフトウェアインストーラーで開き、依存関係の案内に従ってインストールします。形式が合っていても、システムライブラリーのバージョンによっては制限されます。インストーラーが示す依存関係のエラーを確認してください。警告を消すために依存関係を強制的に無視したり、別のアーキテクチャ用パッケージを代わりに使ったりしないでください。

インストール後、アプリメニューからv2rayNを起動し、GUI、設定の書き込み、コアの起動が正常か確認します。デスクトップセッションによってはシステムトレイに対応していない場合があります。メインウィンドウを閉じた後の状態は、トレイアイコンの有無だけで判断せず、プロセスとログを確認してください。画面が起動しない場合は、実行依存ファイルやグラフィカルセッションの問題を先に解決します。ノードの読み込み前に起きる問題なので、サブスクリプションの内容とは直接関係ありません。

サブスクリプションのインポートとデスクトッププロキシの範囲

サブスクリプショングループを追加し、URLを保存して更新します。ノードが取得できたことを確認してから有効な設定を選んでください。Linuxでは、GUIクライアントとターミナルのネットワーク環境を区別することが特に重要です。ターミナルからサブスクリプションURLにアクセスできても、GUIアプリが同じプロキシ環境変数を引き継ぐとは限りません。更新に失敗した場合はクライアントのログを確認し、直結、システムプロキシ、その他の設定済み経路のどれを使っているか調べます。自分自身の待ち受けポートに依存する循環を作らないようにしてください。

システムプロキシを有効にしたら、デスクトップのネットワーク設定に反映されたホスト、ポート、除外リストを確認します。システムプロキシの実装はデスクトップ環境によって異なり、アプリによっては独自設定や起動時に引き継いだ環境変数だけを参照します。ブラウザーは使えるのにターミナルツールが使えない場合は、そのツールのプロキシ対応を確認してください。反対に、ターミナルにプロキシを設定しただけでは、デスクトップセッション全体が振り分けられるわけではありません。

ローカルのHTTP／SOCKS接続先には、クライアントに表示されている実際のポートを指定します。他人の設定にあるポート番号をそのまま使わないでください。アプリがSOCKSを要求する場合、HTTPアドレスとして入力してはいけません。名前解決をリモートとローカルのどちらで行うかは、アプリが使うプロトコルと設定によって異なります。最初の確認ではアプリと接続方法を1つに絞り、リクエストがログに記録されてから範囲を広げましょう。デスクトッププロキシ、ターミナルの環境変数、クライアントのルーティングを同時に変更しないでください。

TUNの権限と複数のネットワークインターフェース

TUNでは通常、仮想インターフェースの作成やルーティングの変更に権限が必要です。利用できるかどうかは、v2rayN、コア、システム環境によって異なります。クライアントが案内する権限設定の手順を使い、GUI全体を常に高権限で実行しないでください。権限不足、デバイスノードの利用不可、ルーティングの競合はそれぞれ別の問題です。ログで失敗した段階を確認しましょう。コンテナー、制限付きセッション、カスタムOSでは、一般的なデスクトップ環境とネットワーク機能が異なる場合もあります。

有線LAN、無線LAN、コンテナーネットワーク、仮想マシンを併用する場合は、直接接続が必要なLANアドレスがないか確認します。デフォルトルートを振り分けると、従来のLANへの経路が変わることがあります。必要なプライベートネットワーク範囲には、ルーティングで明確な方針を設定してください。システムファイアウォール全体を無効にするのは避けましょう。DNSはシステムの名前解決サービス、ネットワークマネージャー、その他のコンポーネントが管理している場合があります。設定を手動で変更する前に、現在どのサービスが管理しているか確認してください。

クライアントを終了してもコマンドラインから通信できない場合は、ターミナルのセッションにローカルポートを指すプロキシ環境変数が残っていないか確認します。デスクトップアプリだけが使えない場合は、デスクトッププロキシが有効なままかを調べてください。アップグレード後は、インストール依存ファイル、設定ディレクトリの権限、ルールデータのパスを先に確認します。設定を移行するときに古いアーキテクチャのコアをコピーしないでください。アンインストール前に通信の振り分けを解除し、使えないプロキシ接続先が残らないようにします。

Android：サブスクリプションのインポートとVPN接続

v2rayNGとv2flyNGから選ぶ

Android版インストーラーからクライアントを選びます。v2rayNGはXrayコアを使用し、このページでAndroid向けにまずおすすめするクライアントです。v2flyNGはV2Flyコアを使用し、対応する設定が必要な場合に適しています。画面やコアの機能は同じではありません。特定の拡張フィールドを含む設定では、対象のコアがそのフィールドを解釈できるか確認してください。共有リンクをインポートできても、接続できるとは限りません。

一般的なarm64端末ではarm64版を選びます。CPUやシステムのアーキテクチャがわからない場合は、システム情報を確認してから汎用版を検討してください。CPUが特定の命令セットに対応していても、システムのユーザー空間が同じアーキテクチャとは限りません。インストーラーで解析エラーが出た場合は、パッケージが端末に合っているか、システム要件を満たしているか、ダウンロードが完了しているかを確認してから汎用版を試します。インストール時の問題とリモートサーバーの問題を混同しないでください。

インストール時は、システムの案内に従って、ダウンロードに使用したアプリまたはファイルマネージャーにインストール権限を許可します。インストール後、必要に応じて権限を取り消せます。上書きインストール時に署名が一致しないと表示された場合は、既存アプリの入手元を確認し、サブスクリプションと設定をバックアップしてから移行方法を決めてください。すぐにアンインストールすると、グループやカスタムルールを失う可能性があります。更新前に現在使えるノードとルーティングモードも記録し、更新後に同じ条件で再テストできるようにしましょう。

ノードをインポートしてシステムの許可を得る

サブスクリプションURLをコピーし、サブスクリプション設定で新しい項目を追加します。名前を入力して保存したら更新してください。共有リンクはクリップボードからのインポートなど、対応する方法で取り込みます。QRコードの場合も、ノードとサブスクリプションURLのどちらが記録されているか確認しましょう。更新後にノードが表示されない場合は、ログとグループの絞り込み状態を確認します。インポート後にノードが1つだけ表示されても、必ずしも失敗ではありません。入力したものが複数ノード用のサブスクリプションではなく、単一ノードの共有リンクだった可能性があります。

ノード一覧から有効なノードを選び、接続を開始すると、システムからVPN接続の許可を求められます。このVPNインターフェースは端末の通信をローカルクライアントに渡すためのもので、リモートノードへの接続確認や、デスクトップのシステムプロキシと同じ機能を意味するものではありません。許可後、クライアントの状態とログを確認し、目的のページにアクセスしてテストします。ステータスバーのVPN表示はインターフェースの作成を示すだけで、プロトコルのハンドシェイクや実際の通信確認の代わりにはなりません。

Androidで通常のVPNを使うために、追加のシステム制御権限が必要になることは一般的にありません。ただし、同じユーザー環境で通常のVPNアプリを2つ同時に使って通信を振り分けることは、通常できません。クライアントを起動する前に、ほかのネットワークツールがVPNインターフェースを使っていないか確認してください。接続ボタンを押せてもシステムインターフェースがすぐ別のアプリに置き換わる場合は、ノードやDNSを何度も切り替える前に、通信の振り分けの競合を解消します。

アプリごとの振り分け、バックグラウンド制限、ネットワーク切り替え

アプリごとに通信を振り分ける場合は、一覧の設定が「選択したアプリのみプロキシを使用」か「選択したアプリを除外」かを確認してください。同じアプリを選んでも、モードによって結果は逆になります。変更後はクライアントの指示に従って再接続し、対象アプリでテストします。既存の長時間接続は変更前の経路を使い続けることがあります。ブラウザーが対象に含まれているかも確認してください。対象外のブラウザーで接続できても、ノードの状態は判断できません。

端末によっては、画面消灯中や長時間のバックグラウンド動作中にアプリが制限されます。画面が点灯している間は使えるのに、消灯すると切断される場合は、システムのバッテリー最適化、バックグラウンド実行、自動起動の設定を確認し、クライアントの接続が維持されているか調べてください。常駐通知やVPNアイコンは状態を知る手がかりですが、ログも合わせて確認します。「常時接続」や「VPNを使わない接続をブロック」を有効にすると、ノード障害時に端末全体が通信できなくなることがあります。設定の役割を理解したうえで使用してください。

Wi-Fiからモバイルネットワークに切り替えると、既存の接続を再確立する必要が生じることがあります。サブスクリプション更新時の経路やDNSへのアクセス条件も変わる場合があります。まず新しいネットワークから基本サービスにアクセスできるか確認し、同じノードに再接続してください。特定のアプリだけが使えない場合は、アプリごとの振り分けとアプリ内キャッシュを確認します。v2rayNGとv2flyNGの設定エクスポートは別々に保管してください。移行時はプロトコル、セキュリティ、ルーティングの各項目を確認し、画面が似ているだけで設定に互換性があると判断しないでください。

ルーティングとDNS：通信の入口からアウトバウンドまで

通信の対象範囲を確認してからアウトバウンドを決める

システムプロキシ、TUN、AndroidのVPNインターフェースは、通信をクライアントに取り込むかどうかを決めます。取り込まれた後にどのアウトバウンドを使うかは、ルールで決まります。TUNを有効にしても、すべての通信をプロキシ経由にする必要があるとは限りません。グローバルプロキシを選んでも、クライアントに取り込まれていないアプリの通信は制御できません。トラブル対処では、まずリクエストがコアのログに記録されているか確認し、その後に適用されたルールとアウトバウンドを調べます。入口の問題をルールの問題と誤認しにくくなります。

ルーティングは通常、ルールの順番に沿って照合されます。具体的な動作は選択したコアによって異なります。特定ドメインの例外ルールは、広い範囲に適用するルールより前に置きます。LANのルールは実際のネットワーク要件に合わせ、最後に明確なフォールバックを設けてください。同じ接続先に複数のルールが適用される場合は、ルール名だけで結果を推測せず、照合フィールド、順序、最終的なアウトバウンドを確認します。変更後は接続を再確立してテストし、既存の接続が結果に影響しないようにしましょう。

次は、プライベートアドレスを直接接続するXray設定の一部を示します。完全な設定ではなく、directという名前のアウトバウンドと利用可能なGeoIPデータが別途必要です。GUIクライアントが同様の設定を自動生成する場合は、生成ファイルを同時に編集せず、ルーティング編集画面を優先してください。次回の起動時にカスタムファイルが上書きされる場合は、そのファイルを生成する設定元を変更しましょう。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

ドメインルール、IPルール、名前解決の経路

geositeはドメインのセットを参照し、geoipはIPアドレスのセットを参照します。互換性のあるキーワードではありません。セット名は、読み込まれているデータファイルに存在し、コアが対応する形式である必要があります。ドメインルールだけでは、IPアドレスへの直接アクセスが一致しない場合があります。IPルールだけの場合は、DNSの経路によって解決結果が変わることがあります。目的を明確にしたうえで両方のルールを組み合わせ、むやみに追加しないでください。

DNSでは、アプリが開始する名前解決、システムによる名前解決、ルーティングや接続のためにコアが行う名前解決を区別する必要があります。システムプロキシの利用中は、アプリがローカルで名前を解決してからアドレスをクライアントに渡す場合も、アプリやプロキシプロトコルによってドメイン名をプロキシ側に渡す場合もあります。DNSのスイッチを1つ有効にしても、すべての名前解決経路が統一されるわけではありません。特に、対象アプリが暗号化DNSや古いキャッシュを使っていないか確認してください。

次は、Xray内蔵DNSの設定例の一部です。localhostはシステムの名前解決を使うことを示し、queryStrategyは問い合わせるアドレスの種類を制限します。この例はフィールドの説明用で、あらゆるネットワークに適した汎用設定ではありません。IPv4だけに制限すると、アドレスファミリーに関する問題を回避できる場合がある一方、利用可能なIPv6経路を使えなくなります。変更前に、ノード、接続先サイト、ローカルネットワークで必要なアドレスファミリーを確認してください。

{
  "dns": {
    "servers": ["localhost"],
    "queryStrategy": "UseIPv4"
  }
}

DNSサーバーを増やすのではなく、アクセス先に合わせて設計する

ドメインの種類ごとに名前解決を分ける場合は、どのドメインをローカルで解決し、どのドメインを別の経路で解決するかを明確にします。次に、DNSリクエスト自体がどのアウトバウンドを通るか確認してください。リモートのDNSサーバーアドレスを一覧に追加しても、そのサーバーへの通信がプロキシ経由になるとは限りません。ノードサーバーがドメイン名を使う場合は、接続前に名前を解決できる必要があります。「プロキシに接続しないとプロキシのアドレスを解決できない」という循環依存を避けてください。

ルールデータの更新とサブスクリプションの更新は別の処理です。サブスクリプションはノードのパラメーターを更新し、ルールデータはサイトやアドレスのセットを更新します。一方が成功しても、もう一方の問題は解決しません。特定のサイトの振り分けに問題がある場合は、まず明確なドメインを1つ使ってテストします。ルール名が存在するか、順序が正しいか、コアがデータファイルを実際に読み込んでいるか確認してください。詳しい手順はgeositeとgeoipを使ったルーティング実践ガイドをご覧ください。

DNSの問題は症状ごとに切り分けます。ドメインで失敗し、既知のIPアドレス経由ではアクセスできる場合は、まず名前解決を確認します。アドレスが解決できてもハンドシェイクに失敗する場合は、セキュリティ設定と接続を調べます。特定のドメインだけアウトバウンドが誤る場合は、ルールの照合とキャッシュを確認してください。DNSを変更した後は接続を再確立し、システムに合った方法でキャッシュを処理します。証明書検証を無効にして接続を維持しないでください。フィールドの詳しい説明はXrayのDNS分割設定をご覧ください。

設定に関するよくある質問：ログの読み方と元に戻す手順

状況を保存してから原因を絞り込む

トラブル対処の記録には、OS、クライアント名、使用中のコア、通信の振り分け方法、失敗した手順を含めてください。ログは起動から失敗前後までの必要部分だけを抜き出し、サブスクリプションURL、認証情報、個人用サーバー情報を隠します。まず現在の設定を保存し、変更する項目は一度に1つにします。ノードの変更、DNSの再設定、TUNの有効化、ルールの更新を同時に行うと、接続が回復しても原因を特定できません。その後、問題が再発しやすくなることもあります。

ログは最後の終了メッセージだけを見るのではなく、最初に現れる明確なエラーから確認します。設定の読み込みに失敗すると、その後の待ち受けや接続もできません。ポートが使用中ならコアを起動できず、ハンドシェイクエラーなら接続処理がさらに先へ進んでいます。問題を設定、待ち受け、名前解決、ハンドシェイク、ルーティングのいずれかに分類してから対処してください。手がかりを残しやすく、再インストールを繰り返すより効果的です。

次の表は確認箇所の目安であり、特定のエラーメッセージを原因1つに機械的に結び付けるものではありません。同じタイムアウトでも、基本のネットワーク、リモートへの到達性、DNS、通信経路の循環などが原因になり得ます。ログと実際の現象を合わせて確認しましょう。ほかのノードなら接続できるか、別のアプリは正常か、通信の振り分けを無効にすると基本のネットワークが復旧するか、といった比較が、エラーの単語だけを見るより判断に役立ちます。

インストール、サブスクリプション、コアの問題を分けて対処

インストールに失敗した場合は、プラットフォーム、アーキテクチャ、パッケージ形式、システム要件、書き込み権限を確認します。実行時にコンポーネントが不足する場合は、インストールが完全に完了しているか調べ、メインプログラムだけを置き換えないでください。アップグレード後に起動しない場合は、バックアップを取って最小構成で再テストし、実行環境の変化か古い設定との互換性かを切り分けます。起動エラーの読み方はコアの起動失敗をログから調べるをご覧ください。

サブスクリプションの更新に失敗した場合は、アクセス不能、認証拒否、応答内容の解析失敗、更新後に一覧がフィルターで隠れている状態を区別します。URLをコピーし直せば入力ミスは直せますが、期限切れのサービスは復旧しません。グループを何度も削除すると、ローカルのメモを失うこともあります。更新後にノード名が変わり、手動選択に影響する場合もあるため、有効なノードを選び直してください。古いノードが一覧に残っているだけで、現在も有効だとは判断できません。

ハンドシェイクに失敗する場合は、サーバーアドレス、ポート、プロトコル、トランスポート方式、セキュリティ設定、サーバー側が要求する名前フィールドを確認します。サブスクリプションに含まれるパラメーターは通常、一式で使います。一時的に通すために一部だけ変更しないでください。証明書エラーではシステム時刻と名前の一致も確認します。検証を無効にするとセキュリティ上の条件が変わるため、一般的なトラブル対処方法として使うべきではありません。特定のフィールドに誤りがあると確認できた場合に限り、サーバーの情報に合わせて修正し、再テストしてください。

よくある質問と復旧の基本状態

基本状態に戻すときはバックアップを保管し、新たに追加したカスタムルールとDNSを無効にします。有効なことがわかっているノードを1つ選び、通信の振り分け方法も1つだけ有効にしてください。事前準備の章にある順番で再確認し、最後に成功した段階を特定します。接続が安定したら、ルールやアプリの例外を1つずつ戻し、その都度変更内容を記録しましょう。初回接続の手順をもう一度確認する場合はクイックスタートガイドへ、パッケージの選び直しや別プラットフォームへの変更はインストーラーのダウンロードページで確認できます。