V2Rayクライアントのインストール・設定ガイド

共通の準備：設定と通信の入口を把握する

クライアント・コア・サブスクリプションの役割

GUIクライアントは、サーバーの表示やサブスクリプションの管理、設定の保存を行い、コアを起動して接続を処理します。コアはプロトコルや通信方式、ルーティングを実際に処理します。サブスクリプションはサーバー設定を取得する方法のひとつで、設定内容を返すURLです。この3つは連携しますが、互いに代用できるものではありません。クライアントをダウンロードしても、使えるサーバーが自動的に用意されるわけではありません。サブスクリプションを追加しても、すべてのアプリが自動的にプロキシを使うわけではありません。始める前に有効な設定を用意し、どのアプリの通信をプロキシ経由にするか決めておきましょう。

デスクトップでは、このガイドに沿ってv2rayNを使うのが基本です。Androidでは、通常はXrayコアを使うv2rayNGを利用し、V2Flyに対応した設定が必要な場合はv2flyNGを検討してください。同じプロトコル名でも、拡張フィールドがすべて共通とは限りません。特にREALITY、特定のフロー制御、通信方式のオプションは、クライアントに含まれるコアの対応状況を確認してください。サーバーから提供されたアドレス、ポート、ユーザーID、安全設定は一組として使います。別々のサーバー設定から項目を寄せ集めないでください。

OS・プロセッサ・インストーラーの形式を確認する

まずシステム情報でプロセッサのアーキテクチャを確認し、クライアントのダウンロードページから対応するインストーラーを選びます。一般的なIntel・AMDのデスクトップ向けCPUはx64、ARMベースの端末はarm64に該当しますが、ブランド名や外観だけで判断しないでください。macOSではApple SiliconとIntelの違いも確認します。Linuxではアーキテクチャに加え、ディストリビューションがdebとrpmのどちらを使うか確認してください。Androidでアーキテクチャが分からない場合は汎用パッケージを選べますが、通常はファイルサイズが大きくなるだけで、接続性能が上がるわけではありません。

インストール前に、旧クライアントのデータ保存先、サブスクリプションのグループ名、カスタムルールを控えておきましょう。アップグレードと移行は別の作業です。アップグレードでは通常、既存データを引き継ぎますが、移行では新しい設定ディレクトリが作成される場合があります。バックアップにはクライアントのエクスポート機能を使い、個人で管理できる場所に保存してください。サブスクリプションURL、ユーザーID、設定のQRコードには認証情報が含まれる場合があります。公開の掲示板にスクリーンショットを投稿したり、オンラインの整形ツールにそのまま貼り付けたりしないでください。

最小構成で動作を確認する

最初のテストでは、起動するクライアントを1つに絞り、利用可能なサーバーを1つ選んでください。カスタムDNS、複雑なルーティング、複数の通信制御ツールは同時に使わないようにします。ほかのプロキシや仮想ネットワークソフトが動作していると、ポート、ルート、DNSが競合することがあります。ウィンドウを閉じるだけでなく、これらのプログラムを終了してください。システムの日付、タイムゾーン、自動時刻設定も確認しましょう。時刻が大きくずれていると、安全な接続の検証に失敗し、サーバー側の問題に見えることがあります。

接続の流れは、設定を正常に取り込めたか、コアが正常に起動したか、アプリがリクエストをクライアントに渡しているか、クライアントがルールに従って接続できたか、の4段階に分けて確認できます。一度に変更するのは1つの段階だけにし、変更前後の状況を記録してください。たとえばサブスクリプション一覧にサーバーが表示されているなら、グループを何度も削除する必要はありません。ブラウザーではアクセスできるのに他のアプリではできない場合、すぐにプロトコルを変更するのではなく、まずアプリの通信経路を確認します。こうして切り分ければ、原因の範囲を絞りながら、正常に動作している部分を保てます。

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

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

Windowsのダウンロードページを開き、v2rayNを選びます。デスクトップ版はクロスプラットフォームのUIを採用し、従来のWPF版はWindowsらしい操作感を維持しています。画面構成やデータの保存先が異なる場合があるため、一方の画面での位置をもう一方の固定メニューとして覚えないでください。初めて導入する場合は、どちらか一方を選んで設定すれば十分です。すでに使い慣れた版があるなら、そのまま使い続けても構いません。どちらの版も、必要なランタイムとコアの要件を満たす必要があります。詳しくはインストール時の案内を確認してください。

インストーラーを実行し、ウィザードに従ってインストール先を選んだら、スタートメニューまたはアプリ一覧から起動します。ランタイムが不足していると表示された場合は、必要なコンポーネント名とアーキテクチャを確認し、信頼できる公式のインストール手段で追加してください。不明なポップアップから同じ名前のファイルをダウンロードしないでください。起動後にメイン画面が見当たらない場合は、タスクトレイを確認します。クライアントがバックグラウンドで動作していることがあります。複数回起動すると、後でポート競合の原因を特定しにくくなるため、すでに起動していないか先に確認してください。

通常のシステムプロキシを使うだけなら、常に管理者として実行する必要はありません。一部の通信制御、仮想ネットワークアダプター、システムレベルの操作では追加の権限が必要になることがあります。セキュリティソフトの警告が表示されたら、対象がインストーラー、GUIクライアント、コアのどれなのかを確認し、ファイルの保存場所も照合してください。起動のためにシステム保護を長期間無効にしないでください。起動直後に終了する場合は、エラー内容を保存し、インストールが完了しているか、データディレクトリに書き込みできるか、セキュリティソフトが必要なファイルを隔離していないか確認します。

サブスクリプションを追加・更新してサーバーを選ぶ

サブスクリプションのグループ管理を開き、新しいグループを追加します。見分けやすい名前を別名に入力し、完全なサブスクリプションURLをアドレス欄に貼り付けてください。別名はローカルで使うラベルで、接続には影響しません。URLのクエリパラメーターもURLの一部です。コピーするときは「?」以降を省略せず、チャットアプリが自動で加えた引用符や改行も含めないようにします。グループを保存したらサブスクリプションを更新し、一覧に実際の項目が表示されたことを確認してから、使うサーバーを選んで有効にします。

初回の更新では、現在のネットワークで利用できる方法を選びます。画面によっては、プロキシ経由と直接接続の更新を選べます。利用可能なプロキシがまだない状態でプロキシ経由の更新を行うと、循環依存になることがあります。ブラウザーでURLを開いてテキストが表示されても、クライアントが解析できるとは限りません。ログイン画面、エラーページ、別形式の設定データが返っている可能性があります。更新後も一覧が空なら、まずサブスクリプション関連のエラーを確認してください。サーバー編集画面に不明な項目を手入力するのは避けましょう。

グループ内の項目を手動で変更している場合、更新時にサブスクリプションの内容で再作成されることがあります。ローカルでの変更がすべて保持されるとは限りません。長期的に使う特殊なサーバーは、クライアントの機能に応じて別管理の項目にコピーし、サブスクリプション更新で上書きされないことを確認してください。インポート後は、現在選択されているサーバーが目的のグループに属しているかを確認します。グループ内に多数の項目が表示されていても、使用中のサーバーが切り替わったとは限りません。実際に動作するのは、最後に保存された設定のままの場合があります。

システムプロキシを有効にし、必要に応じてTUNを使う

システムプロキシのメニューで「システムプロキシを自動設定」を選び、Windowsのプロキシ設定に従うアプリの通信をローカルクライアントに送ります。その後、ブラウザーでページを開き直して確認してください。ルーティングは、まず「中国本土をバイパス」など、クライアントに用意された標準プリセットを選びます。出所不明の複雑なルールを同時に追加しないでください。特定のアプリに変化がない場合は、そのアプリがシステムプロキシを使うか確認します。ゲーム、コマンドラインツール、一部の組み込みネットワーク機能は、独自の接続方法を使うことがあります。

システムプロキシ：システムプロキシを自動設定
ルーティング：中国本土をバイパス
使用中のサーバー：インポート済みの設定から選択
TUN：必要なアプリに応じて別途有効化

システムプロキシに従わないアプリの通信を取り込む必要がある場合は、TUNを有効にして案内に従って許可します。有効化後にシステム全体で名前解決できなくなったら、まずTUNを無効にし、通常のシステムプロキシが使えることを確認してから、仮想ネットワークアダプター、DNS、ほかのネットワークソフトとの競合を調べてください。クライアント終了後もブラウザーがネットワークに接続できない場合は、Windowsのプロキシ設定にローカルアドレスが残っていないか確認します。「システムプロキシを解除」はクライアントが設定した通信の入口を元に戻す機能で、サブスクリプションは削除しません。「システムプロキシを変更しない」は、以前の設定を解除する機能ではありません。

macOS：チップの選択、権限、通信の制御

チップに合った版をインストールして初回起動の警告に対処する

まず「このMacについて」でチップを確認し、macOSのダウンロードページからv2rayNを選びます。Apple Siliconはarm64、Intelはx64です。ディスクイメージを開き、アプリを「アプリケーション」フォルダにコピーしてから、そこから起動してください。マウントしたディスクイメージから長期間直接起動すると、アップデートや権限の記録、起動場所に不整合が生じやすくなります。インストール後はディスクイメージを取り出し、「アプリケーション」フォルダにコピーしたアプリを使います。

初回起動がシステムのセキュリティ機能によってブロックされた場合は、まずダウンロード元と、システムに表示されたアプリ名を確認してください。問題がないことを確認したら、現在のmacOSの手順に従い、「システム設定」の「プライバシーとセキュリティ」で今回の起動に関するメッセージを確認し、開くことを許可します。macOSのバージョンによって表示文やボタンの位置は異なります。単一のアプリの警告を回避するために、システム全体のセキュリティ機能を無効にしないでください。詳しくはmacOSでの初回起動と権限の設定を参照してください。

アプリが開くことと、コアが動作することは別の確認事項です。GUIが表示された後も、コアの起動結果とデータディレクトリへの書き込み権限を確認してください。アプリをダウンロードフォルダから「アプリケーション」に移動した後でネットワーク関連の権限を再度求められた場合は、表示された対象を確認してから対応します。以前の許可が新しい場所にも適用されるとは限りません。許可を何度も求められる、または起動に問題がある場合は、アプリを正常に終了して固定のインストール先から開き直し、複数のコピーが同時に動作していないことを確認してください。

サブスクリプションを追加して現在の設定を確認する

サブスクリプショングループに項目を追加し、別名と完全なURLを入力して保存した後、更新を実行します。サブスクリプションURLにはアクセス用トークンが含まれることがあります。クリップボードから貼り付けた後、プロトコルの先頭部分と末尾のパラメーターが欠けていないか確認してください。単体設定の共有リンクをインポートする場合は、専用のインポート機能を使い、サブスクリプションURLとして入力しないでください。どちらの方法でもサーバー一覧に項目が表示される場合がありますが、その後の更新方法は異なります。見た目が似ていても、同じ方法で扱わないでください。

更新が完了したら、サーバーを1つ選んで有効化し、接続を開始します。同じサブスクリプションがほかの端末で使えたとしても、それだけで端末固有の差を否定できません。ローカルのコア対応、システム時刻、ネットワーク環境、DNSは異なる場合があります。サブスクリプションに含まれる通信方式や安全設定は、まず変更せずに使ってください。分からない項目を理由に初期値へ変更するのは避けましょう。特にサーバー名、通信経路、公開鍵に関する設定を変更すると、ハンドシェイクに失敗することがあります。

システムプロキシは通信サービスに適用、TUNには追加権限が必要

通常のブラウザーを使う場合は、まずv2rayNでシステムプロキシの自動設定を有効にし、現在使用中のネットワークサービスに正しく反映されたか確認します。macOSのプロキシ設定はネットワークサービスごとに管理されます。Wi-Fi、有線ネットワーク、その他の接続方式で設定が異なる場合があります。ネットワークを切り替えた後に「昨日は使えたのに今日は使えない」場合は、以前の接続だけでなく、現在有効なサービスの設定を確認してください。アプリがネットワーク設定の変更を求めたときは、システムの案内に従って必要な権限を許可します。

ブラウザーは使えるのに特定のアプリが直接接続する場合は、そのアプリに独自のプロキシ設定がないか確認してください。より広範囲のIP通信を取り込むにはTUNを検討できますが、追加のネットワーク権限や補助コンポーネントが必要になることがあります。実際の案内に従ってください。許可画面で求められるシステムアカウントのパスワードを、サブスクリプションのパスワードと取り違えないでください。用途は異なります。有効化後にLAN内の端末へアクセスできなくなった場合は、ローカルネットワークの経路が除外されているか、ほかの仮想ネットワークサービスがルートを書き換えていないか確認します。

終了する前に接続を停止し、クライアントが設定したシステムプロキシを解除して、通常のネットワークが復旧したか確認します。クライアントが予期せず終了し、システムが停止済みのローカルポートを参照していると、ブラウザーにプロキシサーバーへ接続できないと表示されます。その場合は、サブスクリプションを削除して再インストールするのではなく、システムのネットワーク設定から残ったプロキシを解除してください。新しいMacへ移行する場合、サブスクリプションは再インポートできますが、システム権限は新しい端末で改めて許可する必要があります。旧端末のデータを復元しても、新しいシステムでの権限確認に代わるものではありません。

Android：v2rayNG・v2flyNGの設定

クライアントとパッケージのアーキテクチャを選ぶ

Androidのダウンロードページを開き、通常はv2rayNGを選びます。V2Flyに対応した設定が必要な場合はv2flyNGを検討してください。両者は同じアプリの見た目違いではなく、コアの機能や一部の設定が異なります。特定のプロトコル拡張を使う場合は、アプリを何度も切り替えて試すのではなく、まず対応範囲を確認してください。サーバー名にプロトコルの略称が含まれていても、すべてのパラメーターが互換とは限りません。実際の設定内容を確認しましょう。

端末のアーキテクチャを確認してからarm64または汎用パッケージを選びます。近年の多くのスマートフォンはarm64ですが、プロセッサがそのアーキテクチャに対応していても、OSが該当アプリの実行環境を提供するとは限りません。最終的にはシステム情報を基準にしてください。インストーラーで形式が合わないと表示されたら、同じファイルを何度も開くのではなく、ダウンロードページに戻って汎用パッケージを選べます。ファイル管理アプリやブラウザーからアプリをインストールする許可が必要な場合は、現在使っている入手元に限って許可し、インストール後は必要に応じて取り消してください。

同じ名前のアプリがすでにインストールされている場合、アップグレードの失敗には署名の入手元、アーキテクチャ、OSの制限が関係していることがあります。最初からアンインストールしないでください。通常、アンインストールするとローカルのサブスクリプションやカスタム設定が削除されます。まず元のアプリの入手元を確認し、残す設定をエクスポートしてサブスクリプショングループを記録します。2つのクライアントを個別にインストールすることはできますが、同じ端末のVPN接続を同時に制御させないでください。テストの前にもう一方のクライアントを停止し、仕事用プロファイルでネットワークツールが動作していないかも確認します。

サブスクリプションを追加してVPNモードを起動する

クライアントのサブスクリプション管理でグループを追加し、名前と完全なURLを入力して保存したら、メイン画面に戻って更新します。配布元がQRコードを提供している場合は、クライアントのスキャン機能を使えますが、単体設定とサブスクリプションURLのどちらを表すQRコードか、先に確認してください。内容に合ったインポート方法を選びます。QRコード画像やサブスクリプションURLにも機密情報が含まれるため、設定画面を撮影するときはサーバー名だけでなく、これらの情報も隠してください。

更新後に項目が表示されたら、使うサーバーをタップして接続します。初回起動時は通常、AndroidのVPN接続リクエストが表示されるため、利用者が許可する必要があります。このリクエストは端末内で通信を取り込むためのもので、クライアントがリモートサーバーを提供するという意味でも、サブスクリプション購入の案内でもありません。許可してもすぐ停止する場合は、クライアントのログやエラー情報を確認し、設定の解析失敗、コアの起動失敗、接続後のネットワークエラーのどれかを切り分けてください。

ほかのアプリの通信をクライアントに通すにはVPNモードを使います。ローカルプロキシの待ち受けだけを行うモードでは、アプリ側でプロキシを設定する必要があります。明確な用途がある場合に利用してください。ステータスバーのVPNアイコンは、システムの通信経路が確立したことを示すだけで、対象への接続成功までは示しません。接続後は対象のアプリを実際に操作して確認し、クライアントに戻って該当するログを確認してください。「接続ボタンの色が変わった」「システムアイコンが表示された」だけで、検証が完了したと判断しないでください。

アプリ別の振り分け、LAN、バックグラウンド制限

アプリ別プロキシで許可リストを使う場合、リストに含まれるアプリだけが通信の取り込み対象になります。除外リストでは逆に、チェックしたアプリが対象外になります。変更する前に現在のモードを確認し、「プロキシを使うアプリ」を除外リストに登録しないようにしてください。変更を反映するにはVPN接続を再確立する必要がある場合があります。ブラウザーでは使えるのに特定のアプリで使えない場合は、サーバーをすぐにリセットせず、まずリストとアプリのネットワーク権限を確認し、その後、サーバーが必要な通信方式に対応しているか調べます。

VPNモード：アプリのIP通信を取り込む
LANをバイパス：ローカルネットワークへの経路を維持
アプリ別プロキシ：許可リストと除外リストを確認
Mux多重化：互換性を確認してから変更

画面消灯後に切断され、アプリに戻ると復旧する場合は、バックグラウンドのバッテリー管理が原因のことがあります。システムのバッテリー設定でクライアントのバックグラウンド動作制限を確認し、必要に応じて許可してください。設定名はメーカーによって異なるため、別の端末のメニュー手順をそのまま使わないでください。Wi-Fiからモバイルネットワークに切り替えた後で切断される場合は、まず再接続し、現在のネットワークに接続できるか確認します。特定のネットワークだけで失敗するなら、DNS、ネットワークのアクセス制限、サーバー側の接続先も調べてください。すべてをバッテリー最適化の問題と決めつけないようにしましょう。

Linux：パッケージ、デスクトッププロキシ、TUN

ディストリビューションとアーキテクチャに合ったv2rayNをインストールする

Linuxではデスクトップ版のv2rayNを使います。まずディストリビューションのシステム情報でCPUアーキテクチャとパッケージ形式を確認し、Linuxのダウンロードページから対応するパッケージを選びます。Debian・Ubuntu系では通常deb、Fedoraなどでは通常rpmを使いますが、互換性はディストリビューションのバージョンや依存関係にも左右されます。ファイルの拡張子から分かるのはパッケージ形式までで、同じパッケージ管理方式のすべてのOSで動作する保証にはなりません。

ダウンロードしたパッケージは、まずディストリビューションのソフトウェアインストーラーで開き、依存関係とインストール時の案内を確認してから実行します。依存関係を満たせないというエラーが出た場合は、エラー全文を保存し、パッケージのアーキテクチャ、ディストリビューションの環境、ソフトウェアリポジトリの状態を確認してください。依存関係を強制的に無視して、インストールが成功したように見えるだけで起動できない状態にしないでください。インストール後はアプリメニューから起動します。GUIクライアントはデスクトップセッションがある環境向けです。リモートターミナルしか使えないサーバーで、デスクトップ画面の手順をそのまま使うことはできません。

GUIは通常ユーザーで起動してください。デスクトップクライアント全体を管理者として実行すると、管理者の設定ファイルが作られ、通常ユーザーに戻した後で設定を保存できなくなることがあります。書き込みに失敗する場合は、アプリのデータディレクトリとファイルの所有者を確認してください。ユーザーディレクトリ全体のアクセス権を安易に変更しないでください。ディストリビューションのセキュリティ機能がネットワーク操作をブロックした場合も、具体的な拒否対象を確認し、システムの手順に従って対処します。アクセス制御全体を無効にしないでください。

サブスクリプションの追加とデスクトップ環境ごとのプロキシの違い

サブスクリプショングループを作成し、別名とURLを入力して保存・更新した後、使用するサーバーを選びます。基本的な流れはほかのデスクトップOSと同じです。更新に失敗した場合は、クライアントがURLにアクセスできないのか、ダウンロードした内容を解析できないのかを切り分けます。直接アクセスしたときにログインフォームやネットワーク認証ページが表示される場合は、まず現在のネットワークの認証を完了してください。Linuxのデスクトップでは、ブラウザーからURLを開けてもクライアントから開けないことがあります。2つのアプリが異なるプロキシ経路やDNS経路を使っている可能性があります。

システムプロキシの適用範囲は、デスクトップ環境やアプリの実装によって異なります。デスクトップの設定を参照するアプリもあれば、独自の設定を使うものや、環境変数を参照するコマンドラインツールもあります。v2rayNでシステムプロキシの自動設定が有効になっていても、すべてのターミナルアプリにすぐ反映されるとは限りません。まずデスクトッププロキシに従うことが明確なアプリで試し、ローカルの待ち受けが動作していることを確認してから、特定のプログラムを設定します。ターミナルツールの問題だけで、システム全体のルートやDNSを変更しないでください。

環境変数にも適用範囲があります。現在のターミナルセッションで変数を変更しても、すでに起動しているGUIアプリには自動で引き継がれません。デスクトップの設定を変更しても、既存のターミナルの環境変数が書き換わるとは限りません。対象のプログラムが明示的なプロキシ設定に対応している場合は、その設定にクライアントが実際に待ち受けているローカルアドレス、ポート、プロトコルを入力します。HTTPプロキシとSOCKSプロキシは、ポート番号が似ているだけで互換性があるとは限りません。クライアントの設定で実際の待ち受け方式を確認してください。

TUNの権限、仮想インターフェース、復旧方法

プロキシ設定に対応していないアプリの通信を取り込む必要がある場合に、TUNを検討してください。TUNは仮想ネットワークインターフェース、ルート、DNS、必要な権限に関わる機能であり、通常のシステムプロキシを強化するボタンではありません。まず現在のクライアントとディストリビューションがこのモードに対応しているか確認し、クライアントの案内に従って権限の許可や補助サービスの設定を行います。権限の仕組みはディストリビューションごとに異なります。出所不明の特権実行コマンドを長期間使ったり、別のOS向けの手順を現在のLinux環境にそのまま適用したりしないでください。

有効化後にネットワークへ接続できなくなったら、まずTUNを無効にして、通常のシステムプロキシが動作するか確認します。無効にしても問題が続く場合は、システムのネットワークマネージャーで現在のDNSとデフォルト接続が復旧しているかを確認してください。仮想インターフェースが存在するだけでは、必ずしも問題とは限りません。重要なのは、通信が停止済みの経路に送られていないかどうかです。以下の2つのコマンドは状態を表示するだけで、ネットワーク設定を変更しません。対応するネットワークツールを使用する環境向けです。コマンドがない場合は、ディストリビューションの同等の確認機能を使ってください。

ip route show
resolvectl status

ルートを確認するときは、デフォルトの出口と仮想インターフェースの関係に注目します。DNSを確認するときは、各DNSサーバーがどのネットワーク接続に属しているかを見てください。アドレスが複数あるというだけで削除しないでください。コンテナネットワーク、仮想マシン、ほかのVPNを同時に使っている場合は、それぞれの通信制御を個別に停止して、どの操作で競合が起きるか確認します。クライアントを終了した後は、デスクトップのプロキシ設定が残っていないかも確認してください。ソフトウェアを再インストールしても、ほかのコンポーネントが追加したルートが自動で修復されるとは限りません。何度も再インストールするより、通信制御を解除して通常のネットワークに戻す手順を確保しておくことが重要です。

通信の振り分けとルーティング：システムプロキシ・TUN・ルール

まずリクエストの入口を決め、次に出口を決める

システムプロキシ、TUN、ルーティングは、それぞれ別の問題を解決します。システムプロキシは、設定に従うアプリをローカルプロキシに接続させます。TUNはネットワーク層で、仮想インターフェースに流入するIP通信を取り込みます。ルーティングルールは、コアに入ったリクエストをどの出口へ送るか決めます。「全般」や「グローバル」は通常、クライアントのルーティングプリセットを指し、すべてのアプリの通信がクライアントに入ることを保証するものではありません。システムプロキシを無視するプログラムは、ルーティングをグローバルにしても独自の方法で直接接続することがあります。

システムプロキシでブラウザーの動作を確認してからTUNを検討するのは、このためです。通常のプロキシモードで問題になるのは主に、アプリの通信経路、待ち受けポート、サーバー設定です。TUNではさらに、仮想インターフェース、ルーティングテーブル、権限、DNSが関係します。通信を取り込む範囲を広げる必要があるときにだけ、これらの要素を追加してください。すべてのスイッチを入れて、設定が完全に見える状態にする必要はありません。アプリ独自のプロキシ設定を使う場合も、システムプロキシや仮想ネットワークによる二重の通信制御にならないか確認します。

ルールの順序とデータファイルを理解する

ルーティングルールは通常、上から順に照合されます。先に一致したルールが適用されると、それ以降のルールは判定されないことがあります。特定のドメインが直接接続される理由を調べる場合は、末尾にプロキシルールがあるかだけでなく、前方のルールを確認してください。ドメインルールはリクエストからドメイン情報を取得できること、IPルールは宛先アドレスや名前解決の設定に依存します。両者は常に同じ条件で使えるわけではありません。アプリがIPアドレスへ直接接続する場合や、コアに入る前にドメイン名が解決されている場合は、想定した条件で照合できないことがあります。

GeoIPとGeoSiteはルール用のデータであり、サーバー設定ではありません。GeoIPはIPアドレスの分類データ、GeoSiteはドメイン名の分類データです。使用できるカテゴリは、実際にインストールされているデータファイルによって異なります。クライアントのプリセットがこれらのデータを参照していても、すべてのサードパーティ製データファイルに同じ名前のカテゴリがあるとは限りません。入手元を変更して「カテゴリが見つからない」というエラーが出る場合は、ルールの参照先とデータの内容が一致しているか確認してください。更新方法はルーティング用データファイルの解説を参照してください。

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

DNS、LAN、多重化を調整する際の注意点

ドメイン名でアクセスできず、IPアドレスを直接指定すると応答がある場合は、DNSを調査対象にできます。ただし、特定の公開DNSサーバーが使えないとすぐに決めつけないでください。クライアント、OS、ブラウザー、アプリがそれぞれ異なる名前解決経路を使う場合があり、キャッシュに古い結果が残っていることもあります。まず、どのアプリで問題が起きるか、独自の暗号化DNSが有効か、TUNがシステムDNSを取り込んでいるか確認します。一度に変更するのは1か所に絞り、再接続してリクエストをやり直してください。複数のDNS設定を同時に変更すると、互いに上書きされることがあります。

プリンター、共有フォルダー、ローカルの管理画面にアクセスする場合は、LANに直接接続できる経路を適切に残す必要があります。「LANをバイパス」は通常プライベートIPアドレスを対象にしますが、具体的なネットワーク範囲やドメインの検出動作は、ルールやシステムのネットワーク環境にも左右されます。ローカル端末にアクセスするために、すべての宛先を直接接続に設定しないでください。ドメインルールを1つ追加しただけで、ローカルの検出プロトコルも正常に動くと決めつけないでください。まず実際のLAN内IPアドレスで接続し、次に名前解決とアプリの検出機能を確認すれば、ネットワーク接続と自動検出を分けて調べられます。

Mux多重化は接続を再利用する機能ですが、あらゆるネットワークやプロトコルの組み合わせに適しているとは限りません。特定のプロトコルやアプリだけで問題が起きる場合は、ほかの条件を維持したまま多重化を無効にして比較できます。ただし、サーバー、通信方式、DNSを同時に変更しないでください。カスタム設定も同じ考え方で行います。まず元のルールを保存し、目的を明確にしてから1つずつ変更を加えます。クライアントが生成する設定と手書きの設定が互いに上書きされることがあります。編集前に実際に使用されている設定を確認してください。ファイルが保存できただけで、変更が適用されたとは限りません。

設定トラブル：サブスクリプションから接続先まで順に確認

サブスクリプションを更新できない・追加後に項目が表示されない

まず、URLへのリクエストと取得内容の解析のどちらで失敗したか確認します。サブスクリプションのドメイン名を解決できない、接続がタイムアウトする、アクセスを拒否される、といったエラーは、それぞれ異なる段階を示しています。応答内容が対応する設定形式でない場合は、サブスクリプションの種類と返された内容を確認してください。URLをコピーするときは、前後の空白、改行、欠けたクエリパラメーターがないか確認します。ブラウザーでURLを開けても、クライアントが設定を受け取れているとは限りません。ログインが必要なページ、ネットワーク認証の案内、ブラウザー向けの管理画面が表示されている場合があります。

利用できるサーバーがすでにある場合は、現在のネットワークに応じて直接更新とプロキシ経由の更新を試し、エラーが変化するか確認できます。利用可能な設定が何もない場合、まだ確立していないプロキシを使って初回更新を行おうとしないでください。サーバー側でサブスクリプションURLやアクセストークンが変更された場合は、推測で一部分だけ置き換えるのではなく、新しい完全なURLを使います。複数の端末で同時に失敗する場合は、サブスクリプションの入手元やサービスの状態を優先して確認します。1台だけで失敗する場合は、その端末のネットワーク、時刻、名前解決、クライアント設定を比較してください。

サーバーは表示されるが、コアの起動やハンドシェイクに失敗する

サブスクリプション一覧に項目が表示されたら、まず有効なサーバーが正しく選択されているか確認し、その後コアの起動結果を確認します。設定の解析エラーは、リモートサーバーへの接続を開始する前に起きることが多いため、設定項目の対応状況とコアの互換性を調べてください。アドレスを解決できない場合は、まず名前解決を確認します。接続拒否は、通常、宛先には到達したものの、該当ポートが接続を受け付けていないことを示します。タイムアウトは待ち時間内に応答がなかったことを示すだけで、ローカルネットワーク、リモート側のファイアウォール、サービスのプロセスのどれが原因かまでは分かりません。

ハンドシェイクのエラーでは、サーバー名、通信方式、パス、ユーザーID、関連する拡張オプションなど、安全設定と通信パラメーター一式を照合します。サーバーアドレスと安全な接続に使う名前が異なる場合があります。2つの項目が重複して見えても、片方を削除しないでください。システム時刻が大きくずれていても、検証エラーが起きることがあります。証明書検証を無効にしたまま使うのではなく、証明書名、有効期間、設定の入手元、通信経路上の中継要素を確認し、安全設定をサーバーの内容に合わせてください。

同じ設定がv2rayNGでは使えてv2flyNGでは使えない場合、どちらかのアプリが壊れていると考えるのではなく、まずコアの機能差を確認してください。デスクトップでも、クライアントの更新とコア機能の更新が一致していないことがあります。プロトコルの対応範囲を比較するには、XrayとV2Flyのコアの違いを参照してください。比較するときはネットワークとサーバーを同じにし、変更する条件を1つだけにすると、結果を原因調査に活かせます。

接続済みと表示されるのにアプリからアクセスできない

問題を「アプリの通信が入っていない」と「入った後に外へ出られない」に分けます。対象アプリを操作してもクライアントに該当するリクエストが表示されない場合は、システムプロキシ、アプリ別リスト、アプリ独自の設定、TUNの対象範囲を確認します。リクエストが確認できる場合は、適用されたルーティングルールとリモート側のエラーを確認してください。一部のWebサイトだけで失敗する場合は、ドメインの名前解決、ルーティング結果、接続先サービスの状態を比較します。ブラウザーのキャッシュ、接続の再利用、バックグラウンドプロセスが以前の接続を使い続けることがあります。設定変更後はリクエストを新しく発行してから判断してください。

ローカルの待ち受けが起動しない場合は、別のクライアントが同じポートを使用していないか、前回のプロセスがバックグラウンドに残っていないか確認します。ポートを変更したら、アプリ側で手動設定したプロキシアドレスも更新してください。クライアントだけ変更してアプリを変更しないと、設定が一致しません。TUNを有効にしたときだけ問題が起きる場合は、通常のプロキシに戻し、サーバー接続が正常なことを確認してから、権限、仮想インターフェース、DNS、ほかのネットワークツールを調べます。通常のプロキシでの動作も確認できていない段階で、通信制御を複雑にしないでください。

通常のネットワークに戻し、有効な調査情報を整理する

ネットワークを復旧するには、まず接続とTUNを停止し、クライアントが設定したシステムプロキシを解除して、ほかのプロキシプロセスが残っていないか確認します。Androidでは、現在のVPNが停止しているか、VPN以外の接続をブロックする設定が有効になっていないか確認してください。デスクトップでは、アプリ独自の手動プロキシ設定も確認します。システムプロキシを解除しても、アプリ側の設定が自動で戻るとは限りません。通常のネットワークが復旧したことを確認したら、使用中のサーバーを1つ、通信の入口を1つに絞って再テストします。

問題を記録するときは、OS、クライアント名、発生した段階、直前の操作、エラーに最も近い時刻のログを残してください。共有前にサブスクリプションURL、ユーザーID、サーバーの認証情報、QRコードを削除し、データディレクトリ全体をそのままアップロードしないでください。ログのエラーはv2rayNのログエラー解説を参照して確認できます。簡潔な質問と回答はヘルプセンターをご覧ください。時間範囲の分からないスクリーンショットを大量に共有するより、再現手順を明確に記録するほうが原因を特定しやすくなります。