V2Ray使い方ガイド

基本概念：取り込み・判定・通信先を区別する

クライアント、コア、サーバーの役割

V2Rayは通常、Project V関連のプロキシ技術やツールのエコシステムを指し、単一のGUIソフトウェアではありません。クライアントはサーバー情報の保存、サブスクリプションの読み込み、設定の切り替え、ログの表示を担当します。コアは接続の確立、トラフィックの識別、ルーティング、プロトコル処理を行います。サーバーはリモートで動作し、プロトコル接続を受け付けて接続先へ通信します。それぞれ役割が異なります。画面が開くのはクライアントが起動できたことを示すだけで、コアの起動やサーバーへの接続成功を意味するものではありません。

V2FlyとXrayは、関連エコシステムに属する別々のコアプロジェクトです。一部の設定概念は共通していますが、機能範囲、プロトコル拡張、パラメーターの詳細は完全には一致しません。v2rayNでは異なるコアを管理できますが、選択肢は使用している配布パッケージによって異なります。v2rayNGは主にXrayを、v2flyNGはV2Flyを使用します。設定項目が認識されない場合は、まず実際に起動しているコアを確認し、対応する設定資料を参照してください。クライアント名だけで対応状況を判断することはできません。

接続はどのような経路をたどるか

アクセスを4段階に分けると、問題の箇所を特定しやすくなります。アプリが接続をローカルの取り込み口に渡し、コアがルールに基づいて通信先を選択します。プロキシ経由でリモートサーバーに接続し、最後にそのサーバーが宛先へアクセスします。HTTPプロキシ、SOCKSプロキシ、TUNは取り込み方式の違いです。directやproxyなどのラベルは通信先の選択に使われます。取り込みに失敗しているときにリモート側のプロトコルを変えても意味はありません。ルールの選択が誤っているときにローカルの待ち受けポートを何度変更しても、根本的な解決にはなりません。

サーバー情報には通常、アドレス、ポート、プロトコル、認証情報、トランスポート方式、セキュリティ層が含まれます。プロトコルはクライアントとサーバーの通信方法を定め、トランスポート方式はデータの運び方を示します。TLSやREALITYなどは接続のセキュリティ機構です。VLESSはトランスポート方式ではなく、WebSocketも暗号化プロトコルではありません。読み込み後は各層を個別に確認してください。アドレスが同じでも、パス、サービス名、サーバー名などが異なれば接続結果が変わることがあります。

DNS名前解決とルーティングの関係

DNSはドメイン名をアドレスに変換しますが、クライアントに届く前にドメイン名が必ず消えるわけではありません。アプリによってはドメイン名のままプロキシに渡し、別のアプリではローカルで解決してからアドレスを渡します。コアが受け取る情報によって、適用できるルールも異なります。そのため、ドメインルールが適用されない場合は、すぐにルールデータの破損を疑うのではなく、取り込み方式とログに記録された宛先の種類を確認してください。同じサイトでも、アプリごとに名前解決の場所が異なり、通信先が分かれることがあります。

ルーティングの判定とDNS問い合わせは別の処理です。ドメイン解決の設定によって、アドレスベースのルール判定のためにコアがDNS問い合わせを行うことがありますが、アプリのDNS要求すべてが指定した経路を通るわけではありません。TUNを使う場合は、システムのリゾルバー、クライアントによるDNSの引き継ぎ、ブラウザー独自の名前解決機能なども考慮する必要があります。実際の問い合わせがどのコンポーネントを通るかを整理してから設定を確認すると、DNS関連の項目をいくつも同時に有効にするより効果的です。

検証可能な出発点を作る

初回設定では、提供元が明確なサーバー情報、1つの取り込み方式、説明しやすいルーティングがあれば十分です。まずシステムプロキシ経由でブラウザーにアクセスさせ、接続ログに宛先と想定したアウトバウンドが表示されるか確認します。TUN、独自DNS、アプリ別プロキシ、複雑なルールを一度に有効にすると、失敗時に原因を特定できません。基準となる状態を作る目的は設定を減らすことではなく、各手順を直前の状態と比較できるようにすることです。

このガイドの設定例は個別の項目を説明するもので、完全なサーバー接続情報は含みません。実際の設定はまずGUIから変更し、クライアントが生成した内容を確認してください。実行時設定を直接編集すると、再起動、サーバー切り替え、サブスクリプション更新の際に上書きされることがあります。この章を読み終えたら、アクセスについて「どこからトラフィックが入り、どのルールに一致し、どのアウトバウンドに渡るか」を説明できる状態を目指します。用語が不明な場合は用語ガイドも参照してください。

クライアント選び：プラットフォーム・コア・情報の互換性

デスクトップはまずv2rayNを選ぶ

Windows、macOS、Linuxのデスクトップ環境では、まずv2rayNを検討してください。サーバー、サブスクリプショングループ、ルーティング、実行ログをGUIでまとめて管理でき、再現性のある操作手順を作りやすいクライアントです。Windowsではデスクトップ版と従来のWPF版を選べます。デスクトップ版はクロスプラットフォームのUIを採用し、WPF版は従来のデスクトップ操作を維持しています。OS環境と使い方に合わせて選び、同じ接続で両方を同時に起動する必要はありません。

macOSでインストーラーを選ぶ前に、「このMacについて」でチップを確認してください。Apple Siliconはarm64、Intelはx64に対応します。Linuxではアーキテクチャに加えて、ディストリビューションのパッケージ形式も確認します。debパッケージを使う環境ではdeb、rpmパッケージを使う環境ではrpmを選びます。アーキテクチャはプロセッサー上でプログラムを実行できるかを決め、パッケージ形式はインストールツールによるファイル管理に関わります。拡張子だけを見て判断せず、両方を合わせてください。

Androidは第一候補と代替候補を選ぶ

Androidではv2rayNGを第一候補とし、主にXrayコアを使用します。V2Flyの設定との互換性が必要な場合は、v2flyNGも検討してください。どちらもGUIクライアントですが、対応プロトコルが完全に同じとは限りません。特定のコア拡張に依存するサーバー情報を使う場合は、まずクライアント側のコアが対応しているかを確認してから、読み込み方法を検討してください。読み込みに成功しただけでは互換性の証明になりません。リンクの解析と実際の接続確立は別の段階です。

Androidのパッケージアーキテクチャは、端末のOSとプロセッサーの対応状況を基準に選びます。比較的新しい端末の多くはarm64に適していますが、プロセッサーが対応していてもシステム環境が合わない場合があります。判断できない場合は汎用パッケージも選べますが、通常はファイルサイズが大きくなります。インストーラーが非対応と表示した場合は、端末情報とパッケージの選択を見直してください。同じファイルのインストールを繰り返す必要はありません。配布先はAndroidのダウンロード一覧にまとめてあります。複数の配布元からインストールファイルを寄せ集める必要はありません。

名称で推測せず、要件に照らして確認

選ぶ前に、サーバーのプロトコルとトランスポート、対象にするアプリ、TUNが必須かの3点を整理します。ブラウザー中心のデスクトップ利用なら、まずシステムプロキシから始められます。システムプロキシに従わないアプリは、個別設定またはTUNを検討します。Androidでは、システムVPNによる取り込みとアプリ別リストの仕組みを理解する必要があります。機能が多ければ最適とは限りません。現在の要件を満たし、無理なく管理できる組み合わせを選んでください。

サブスクリプションの互換性も別途確認してください。同じ「サブスクリプションURL」でも、返される内容はプロトコルリンクの一覧、エンコードされたリスト、専用設定ファイルなどさまざまです。あるプロトコルに対応したクライアントでも、すべてのサブスクリプション形式を読み込めるとは限りません。サーバー情報をすでに持っている場合は、ダウンロード前に提供元が案内するクライアントと読み込み方法を確認してください。形式が合わない場合は正しい元のURLを入手し、個人用のサブスクリプションURLを出所不明のオンライン変換サイトに入力しないでください。

移行時はロールバック手段を残す

別の端末から移行する場合は、新しいクライアントに独立したサブスクリプショングループを作り、まずサーバーを1つだけ検証してください。ルーティング、DNS、取り込み設定をすべて一度にコピーするのは避けます。プラットフォームによってシステムプロキシ、権限管理、ネットワークインターフェースの挙動が異なり、元の端末の設定をそのまま使えるとは限りません。接続の基準を確立してから、業務上のルールを1つずつ移行し、それぞれがアプリのアクセスに与える影響を記録してください。

複数のクライアントを同時に起動すると、プロキシポートの競合、システムプロキシの変更、VPN接続の占有が起きることがあります。別のクライアントに切り替える場合は、まず旧クライアントの取り込み機能を停止してから新しいクライアントを起動してください。ロールバック用に旧設定は残しつつ、複数のクライアントにシステムトラフィックを同時管理させないようにします。3つのクライアントの詳しい違いはクライアント・コア・プラットフォームの比較メモを参照してください。クライアントを選んだら、次の章でインストールと初回起動を進めます。

インストールと初期設定：権限・保存先・待ち受け

インストール前にファイルとデータの保存先を決める

クライアントのダウンロードページでプラットフォームとアーキテクチャに合った配布物を選びます。インストール前に既存のクライアントを終了し、これから使うクライアントのパッケージであることを確認してください。インストーラーを使う場合は、ウィザードに従ってインストールします。配布物を展開して実行する場合は、まず専用のディレクトリにすべて展開してから起動してください。圧縮ファイルのプレビュー画面から直接実行すると、関連ファイルを見つけられず、更新やデータ保存に問題が生じることがあります。

プログラムの保存先と設定データの保存先は異なる場合があります。ユーザーディレクトリにデータを保存する配布形態もあれば、独立したデータディレクトリを使えるものもあります。初回起動後、設定画面のデータ保存先やバックアップ項目を確認し、サブスクリプションやルーティングがどこに保存されるか把握してください。端末の移行を予定している場合は、デスクトップのショートカットだけでなく、クライアントが管理するデータをバックアップします。実行ディレクトリを複数人が書き込める場所や、頻繁に削除される一時ディレクトリに置くことも避けてください。

デスクトップで初回起動する

Windowsではインストール後、まず通常ユーザーで起動し、画面とログが正常に表示されるか確認します。WPF版で実行コンポーネントの不足が表示された場合は、その配布物が必要とする環境を追加するか、現在のシステムに適した配布方法を選び直してください。起動に失敗したからといって、管理者権限での常時実行を習慣にしないでください。通常のプロキシ利用と仮想ネットワークアダプターの管理では必要な権限が異なります。後者を有効にするときに、案内に従って許可してください。

macOSではアプリを使用する場所に配置してから起動し、一時的なマウント先からの繰り返し実行は避けてください。システムのセキュリティ警告が表示された場合は、ファイルの配布元、パッケージの種類、OSの対応状況を確認し、システムが提供するアプリのセキュリティ手順に従います。Linuxでは対応するパッケージ管理ツールでインストールしてから、アプリ一覧より起動しログを確認します。デスクトップ環境や権限が不足している場合は、具体的なメッセージに対処してください。問題を回避するために、システムディレクトリの権限を広範囲に変更しないでください。

Androidのインストール後に必要な許可

Androidでは、インストール時に実際に使う配布元に限って必要な許可を与え、完了後は必要に応じて取り消せます。初回起動ではサーバー情報を1つ読み込んでから接続を開始してください。システムに表示されるVPN接続要求は、クライアントがローカルのトラフィックを取り込むための許可です。許可しただけではリモート接続の成功を意味しません。利用できるかどうかは、サーバー設定とアクセス結果を確認してください。別のVPNアプリが動作中の場合は、接続の競合を防ぐため先に停止します。

インストールの問題とバックグラウンド動作の問題を切り分けるため、初回テストはアプリを前面に表示し、画面を点灯させた状態で接続を確認してください。その後で画面ロックやバックグラウンド動作をテストします。ロック後にだけ切断される場合は、再インストールではなく、バッテリー最適化、バックグラウンド実行制限、メーカー独自のタスク終了設定を確認してください。詳しくはAndroidの権限・省電力・アプリ別設定を参照してください。

コアとローカル待ち受けを確認する

デスクトップクライアントを開いたら、ログまたはステータス欄でコアが実際に起動していることを確認します。実行ファイルが見つからない、設定の解析に失敗する、ポートが使用中という問題は、それぞれ原因が異なります。1つ目はインストール内容、2つ目は直近の変更、3つ目は古いプロセスや同じポートを使う別のプログラムを確認してください。待ち受けが始まる前にブラウザーでプロキシをテストすると、ローカル接続拒否のエラーが表示されるだけです。

待ち受けアドレス、ポート、プロキシプロトコルを確認してから、アプリの接続方法を決めてください。システムプロキシはクライアントが実際に待ち受けている場所を指定します。アプリに手動で設定する場合も、HTTPとSOCKSの入口を区別してください。ポート番号に一律の指定はなく、現在の設定に従います。ポートを変更したらアプリ側の設定も更新してください。古いポートに接続し続けたり、リモートサーバーのポートをローカルプロキシのポートに入力したりしないようにします。

初期設定中は、OS起動時の自動起動や自動取り込みを有効にしないでください。まず「コア起動、アプリ接続、取り込み停止、プログラム終了」の一連の操作を行い、終了後にネットワークが正常に戻ることを確認してから、自動化の設定を有効にします。これにより、クライアントがシステム設定に加えた変更を把握できます。終了後もアクセスできない場合は、ネットワーク環境全体をリセットする前に、システムプロキシの設定が残っていないか確認してください。よくある対処方法はFAQ・トラブル対処を参照してください。

サブスクリプションの読み込み：グループ・更新・項目の確認

情報の種類とアクセス範囲を確認する

サブスクリプションURLは更新に使う入口であり、単一のサーバー接続を表すものではありません。複数のサーバー情報が返され、更新時に内容が追加・削除されることがあります。単一のプロトコルリンクは1つの接続を表し、QRコードはリンクを受け渡す手段です。読み込む前に、手元の情報がサブスクリプションURL、単一の共有リンク、完全な設定ファイルのどれに当たるかを見極め、適切な操作を選んでください。サブスクリプションURLを単一サーバーのアドレス欄に貼り付けても、接続できない設定になることがほとんどです。

サブスクリプションURLには、個人用のサーバー情報にアクセスできる識別情報が含まれることがあります。接続認証情報と同じように扱い、第三者に調査を依頼する際はURL全体を送らないでください。QRコードも公開ページに掲載しないようにします。初期調査には、返される形式、エラーの種類、クライアント名を伝えれば通常は十分です。URLを誤って公開した場合は、提供元の管理手段でURLを変更してください。チャット履歴やブラウザーの履歴を削除するだけでは不十分です。

グループを作成して更新を管理する

v2rayNではサブスクリプショングループの管理画面からグループを追加し、識別しやすいメモと実際のサブスクリプションURLを入力して保存し、更新を実行します。更新による影響範囲を把握しやすいよう、提供元ごとにグループを分けてください。メモはローカルでの識別に使うもので、接続機能には影響しません。初回更新後は、サーバー項目が作成されたか、正しいグループに属しているか、ログに形式の解析エラーがないかを確認します。画面に成功と表示されたかだけで判断しないでください。

v2rayNGとv2flyNGでは、サブスクリプション管理の項目からURLを追加して更新します。メニュー名は実際の画面に従ってください。単一の共有リンクを持っている場合は、クリップボードからの読み込みやQRコードのスキャンなど、対応する入口を使います。読み込み前にクリップボードに説明文が混ざっていないか確認し、スキャン後はプロトコル、アドレス、メモを確認してください。QRコードを続けて複数読み込む場合は、重複登録がないか確認し、一覧から古い項目を誤って選ばないようにします。

更新エラーはネットワークと形式に分けて確認する

更新に失敗したら、まずプロトコルのプレフィックス、パス、クエリパラメーターを含め、URLが完全かどうか確認します。コピー方法によっては末尾が欠けることがあります。次に、接続タイムアウト、アクセス拒否、証明書エラー、内容の解析失敗のどれかを特定します。タイムアウトとアクセス拒否ではネットワーク経路やアクセス権限を優先して確認します。証明書エラーではシステム時刻と証明書環境も確認してください。解析失敗の場合は、返された内容がクライアント対応のサブスクリプション形式か、Webログイン画面やエラー説明ではないかを確認します。

クライアントによっては、プロキシ経由でサブスクリプションを更新する設定があります。直接取得できない場合は、すでに使える接続があることを前提に試せます。利用可能な接続がない状態では、「プロキシ経由で更新」を自動的な解決策にはできません。まず使える初期接続を確立するか、提供元にアクセス可能な更新方法を確認してください。更新経路、DNS、コアを同時に切り替えると、どの変更が結果に影響したのか特定しにくくなります。

メモだけでなく読み込み結果を確認する

一覧からサーバーを1つ選び、プロトコル、アドレス、ポート、認証情報、トランスポート方式、セキュリティ層を順に確認します。WebSocketではパスとHost、gRPCではサービス名、TLSではサーバー名と証明書の検証条件を重点的に確認してください。異なるプロトコルの項目を相互に置き換えることはできません。項目が空でも問題ない場合と、情報が不足している場合があります。サーバー側の要件に照らして判断してください。

更新前に選択中のサーバーとグループを記録し、更新後に選択状態をもう一度確認してください。クライアントによっては一致する項目を維持しますが、元の項目が置き換えまたは削除されることもあります。似たメモが画面に残っていても、実際のパラメーターが変わっていないとは限りません。更新後にのみ問題が起きた場合は、すべてのデータを削除する前に項目の詳細とコアのエラーを比較してください。検証済みの独立したテスト項目を残しておくと、サブスクリプションとローカル環境のどちらが変わったのか切り分けやすくなります。

サブスクリプション管理の完了条件は、提供元が明確で、グループを識別でき、更新の挙動を説明でき、少なくとも1つの項目で接続を確立できることです。サーバー一覧のテスト結果はその時点での参考情報にすぎず、実際の用途での検証に代わるものではありません。次は決めた取り込み方式で対象アプリを接続し、その後でルーティングを調整します。初回操作だけを済ませたい場合はクイックスタートガイドに戻ってください。プロトコル項目に関する疑問はプロトコル・トランスポート用語を参照してください。

プロキシモード：取り込み範囲とトラフィックの流れ

システムプロキシはアプリの接続方法を決める

システムプロキシは、OSがアプリ向けに提供するプロキシ設定です。デスクトップクライアントを有効にすると、通常はHTTPなどのプロキシ入口がシステム設定に登録され、その設定に従うアプリが接続をクライアントに渡します。ブラウザーは利用できることが多い一方、一部のゲーム、コマンドラインツール、独自のネットワーク機能を持つアプリは従わない場合があります。システムプロキシを有効にしても一部のアプリでしか動作しない場合は、取り込み範囲の問題です。リモートサーバーが原因だと決めつけないでください。

v2rayNでは、まず利用可能なサーバーを起動し、次にシステムプロキシを設定してから、ブラウザーで新しい接続を試します。テスト前にブラウザー独自のプロキシ拡張を無効にするか、設定を確認し、システム設定が上書きされないようにしてください。すでに確立した長時間接続は元の経路を使い続けることがあります。プロキシ設定を変更したらページを再読み込みし、必要ならアプリを再起動します。スイッチの色を見ただけでは、新しい接続が実際にクライアントへ渡ったかは確認できません。

グローバルモードとバイパスモードは接続後の経路を決める

グローバルプロキシは通常、クライアントに取り込まれ、必要な例外ルールに該当しないトラフィックをプロキシ経由で送ります。OS内のすべてのアプリが自動的に取り込まれるという意味ではありません。中国本土向けなどのバイパスモードでは、ドメインやアドレスのルールに応じて、一部の宛先を直接接続し、それ以外をプロキシ経由にします。どちらもルーティングの選択であり、システムプロキシとは異なる層です。システムプロキシを有効にしてバイパスルールを使うことも、TUNで取り込んで同じ考え方でルーティングすることもできます。

グローバルモードで問題を調べる目的は、宛先ごとの振り分けによる変数を一時的に減らすことであり、ローカルで必要な通信をすべて無視することではありません。LAN内の端末、ループバックアドレス、リモートサーバー自体への接続も適切に処理する必要があります。クライアントによって例外の設定方法は異なるため、「グローバル」をすべてのルールを削除するモードだと捉えないでください。特定の宛先が実際にどこへ接続されるかを確認するには、現在のプリセットと実行ログを確認し、モード名だけで推測しないようにします。

アプリを1つ選んで経路を確認する

まず繰り返しテストしやすいアプリを1つ選び、システム設定と独自プロキシ設定のどちらを使うか確認します。プロキシを手動入力する場合は、リモートサーバーではなくローカルの待ち受けアドレスと対応するプロトコルのポートを指定してください。SOCKS経由でドメイン名をプロキシに渡して名前解決させられるかは、アプリの対応状況によります。ローカル解決とリモート解決で適用されるルールが異なることがあります。操作前に元の設定を記録し、テスト後に戻して、気づきにくい設定の上書きを残さないようにします。

検証ではアプリの結果とクライアントのログを同時に確認します。アプリが接続できず、ログにも宛先がまったく記録されない場合は、まず取り込みを確認してください。ログに記録はあるものの通信先が違う場合はルーティングを確認します。想定どおりのプロキシ経由でも接続に失敗するなら、プロトコルとリモート側を調べます。ログレベルが低く詳細が不足する場合は、一時的に上げて再現を1回試してください。ページが開くかどうかだけで原因の層を判断せず、キャッシュされたページを新たな通信結果と見なさないようにします。

Androidのアプリ別設定とデスクトップの例外

AndroidのVPN接続では、アプリ別のリストを併用できます。リストの意味が「選択したアプリだけをプロキシする」のか「選択したアプリを除外する」のかは設定によって異なり、両者は正反対です。設定前に現在の項目の説明を読んでください。リストを変更したら接続を再確立し、テストするアプリでも新しい接続を作り直します。リストから除外されたアプリはクライアントの処理経路に入らないため、グローバルルーティングを切り替えても自動的に対象にはなりません。

デスクトップ環境にも、システムプロキシの例外リスト、ブラウザー独自の設定、アプリ固有のネットワーク設定があります。ローカルの管理ページにアクセスできない場合は、不適切なプロキシ経路に送られていないか確認してください。特定のアプリが常に直接接続する場合は、システム設定を無視していないか確認します。取り込み方式の分析をせずに、グローバルモードとバイパスモードを何度も切り替えても解決にはなりません。詳しい比較はシステムプロキシとルーティングモードの解説を参照してください。取り込みを確認できたら、次の章でルールを設定します。

ルーティング：順序・条件・アウトバウンドラベル

まずルールを実行する主体を確認する

ルーティングルールを実行するのは動作中のコアで、GUIは設定の生成や管理を担います。変更前に、現在のコア、使用中のルーティングプリセット、サーバー設定の種類を確認してください。独自設定によってルーティングが定義されている場合、クライアント標準のルール画面が使われていないことがあります。変更しても何も変わらない場合は、使われていないプリセットを繰り返し調整するのではなく、編集内容が実行中の設定に反映されているか確認します。

通常はルールの順番に従って判定され、最初に一致したルールがアウトバウンドを決定します。具体的な業務用ドメインを広範な分類より前に置き、LANの例外を一般的なプロキシルールより前に置くと、ルールの競合を減らせます。同じルール内にある条件の組み合わせ方も確認してください。一般的なfieldルールでは、異なる種類の条件は通常すべて一致する必要があり、同じ種類のリストでは候補値のいずれかが一致します。ドメインとポートを含む1つのルールを、独立した2つのルールと読み違えないようにします。

domainStrategyとラベルを理解する

domainStrategyはルーティング判定のためにドメインを名前解決する動作に影響します。AsIsはアドレス条件との照合のためにドメインを積極的に解決しません。IPIfNonMatchはドメインルールに一致しない場合、アドレス条件で判定を続けるために解決を試みます。IPOnDemandは関連するアドレスルールに応じて、早い段階で解決することがあります。これはプロキシプロトコルの切り替えではなく、クライアントのDNS転送方式全体を直接決めるものでもありません。ルールの内容と名前解決のコストを考慮して選んでください。

outboundTagは実際に定義されているアウトバウンドラベルを参照します。direct、proxy、blockはよく使われる名前にすぎず、対応するアウトバウンド定義がなければ機能しません。次の例はルーティング部分のみを示しており、実行設定にdirectとproxyが定義され、必要なルールデータファイルがあることを前提とします。この部分だけを完全な設定ファイルとして保存したり、ラベルを確認せずにクライアントが生成した内容を上書きしたりしないでください。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

ルールデータとドメインの指定方法

geositeはドメインの集合を、geoipはアドレスの集合を参照します。集合名と利用できる内容は、実際にインストールされているデータファイルによって異なります。ネットワークからリアルタイムで取得される絶対的な判定ではなく、更新によって分類が変わる場合もあります。サイトが複数の関連ドメインを使っている場合、トップページのドメインだけではログイン、リソース、API通信を網羅できないことがあります。ログを確認して個別に判断し、無関係な分類全体に対象を広げないようにしてください。

ドメインを正確に除外・指定する場合は、完全一致とサブドメインを含む一致を区別します。たとえばfull:example.comはその完全な名前だけを対象にし、domain:example.comは通常、サブドメインも対象にします。例のドメインは構文の説明用です。実際のルールには対象サービスのドメインを入力してください。曖昧なキーワード一致で明確な範囲指定を代用すると、同じ文字列を含む別サービスまで対象に入ることがあり、問題の発見が難しくなります。

ログを使ってルールの適用を確認する

ルールを検証するときは、変更を1つに絞って保存し、クライアントの指示に従って再読み込みしてから、新しい接続を行います。宛先がドメイン名かアドレスか、どの条件に一致したか、最終的にどのアウトバウンドを使ったかを記録してください。宛先がアドレスだけの場合、ドメインルールを判定する情報が不足している可能性があります。先に広範なルールが一致していれば、後続の詳細なルールは実行されません。調査のため一時的にルールの順序を変更する場合は、元の位置を記録し、テスト後に戻してください。

振り分け後に一部のリソースだけ失敗する場合は、そのサービスを一時的に単一の利用可能なアウトバウンドに設定し、関連ドメインの範囲を絞り込んでください。これにより、ルールの対象不足とリモート側の問題を切り分けられます。最初から大量のルールセットを追加しないでください。集合が増えるほど、適用経路の説明が複雑になります。安定したルーティングでは、各ルールの目的、順序、取り消し方法を説明できることが重要です。目的を説明できない項目は、未知の依存として残すのではなく、まず無効にして挙動を確認してください。

TUNモード：仮想ネットワークアダプター・DNS・ループバック

まず通常の接続が使えることを確認する

TUNは仮想ネットワークインターフェースを通じてシステムトラフィックを取り込み、プロキシを直接設定できないアプリやシステムプロキシに従わないアプリに適しています。変更されるのは取り込み経路であり、その先には引き続きルーティングと利用可能なアウトバウンドが必要です。有効にする前に、通常のプロキシで同じサーバーから対象へアクセスできることを確認してください。そうしないと、有効化後の問題がリモート接続とローカルのネットワークアダプターのどちらに起因するのか特定できません。TUNはサーバー情報の誤りを修正する機能ではなく、すべてのアプリのネットワーク動作を同じにするものでもありません。

GUIクライアントのTUN機能は、異なるコア、補助コンポーネント、権限の仕組みに依存する場合があります。設定項目が通常のXrayルーティング設定と一致するとは限りません。別の実装向けの設定全体を現在のクライアントに貼り付けないでください。まず現在のTUN設定画面を読み、自動ルーティング、DNSの引き継ぎ、除外するネットワーク、ネットワークスタックなど各項目の役割を確認します。明確な要件がなければ妥当な初期値を使い、すべての項目を一度に変更しないようにしてください。

権限とシステムルーティング

初回の有効化では、管理者の許可や仮想ネットワークアダプター関連のコンポーネントのインストールが必要な場合があります。許可した後、コアのログ、アダプターの作成、システムルートが想定どおりに設定されたかを確認してください。アダプター名が表示されただけでは、トラフィックがコアに取り込まれたとは限りません。スイッチがオンでも作成処理が成功したとは限りません。有効化に失敗した場合はエラー情報を保存し、まず権限とコンポーネントの状態を確認してから再試行を判断します。用途不明のインターフェースを続けて複数作成しないでください。

自動ルーティングはシステムがネットワークの出口を選ぶ方法に影響するため、クライアントからリモートサーバーへの通信を特に考慮する必要があります。この通信自体が再び捕捉され、同じプロキシ入口へ戻るとループが発生し、再接続の繰り返しやネットワーク全体の利用不能につながることがあります。通常、クライアントには専用の除外機能があります。まず設計済みの方法を使ってください。ネットワーク範囲やプロセスの例外を手動で追加する前に、実際の出口インターフェースとリモートアドレスを確認し、広範囲をまとめて除外しないようにします。

DNSの引き継ぎは個別に検証する

TUNでよくある問題は、アドレスでの直接接続はできるのにドメイン名ではアクセスできないことです。この場合はDNS要求がどこに届くか、クライアントが上流の名前解決サービスにアクセスできるか、得られた結果が後続のルーティングに使われるかを確認します。アプリはシステムDNSを使う場合もあれば、独自に暗号化された名前解決接続を確立する場合もあります。クライアントにDNSサーバーを設定したからといって、アプリの名前解決すべてが自動的に引き継がれるわけではありません。設定画面にサーバーアドレスが表示されているだけで完了と判断せず、実際の問い合わせ経路を確認してください。

実装によってはFakeDNSを使い、ドメイン名を予約アドレス範囲に割り当て、後続の接続で元のドメイン情報を復元します。DNSとトラフィックの取り込みが連携している必要があるため、あらゆる状況の標準設定として扱うべきではありません。アプリに古い結果がキャッシュされている場合、取り込み経路を迂回する場合、独自に名前解決する場合は、対応関係にずれが生じることがあります。明確な要件がなければ、まずシンプルな名前解決方式を使い、通常の接続が安定してから個別にテストしてください。

LAN・デュアルスタック・アプリの範囲

Webページ、LANサービス、スリープからの復帰、ネットワーク切り替えをテストしてください。プリンター、ファイル共有、ルーターの管理画面に接続できない場合は、まずローカルネットワークが誤ってプロキシ経由になっていないか確認します。企業ネットワークでは一般的でない内部ネットワーク範囲や専用DNSを使う場合があり、家庭用ネットワークの経験だけで除外設定を決めることはできません。内部の名前解決が必要な場合は、名前解決の経路とアクセス経路を併せて考えてください。アドレスだけを許可しても、ドメインの問題が解決するとは限りません。

IPv4とIPv6も個別に確認してください。片方のアドレスファミリーだけを取り込む設定では、アプリがもう一方を優先し、想定と異なる経路を通ることがあります。解決結果に到達できないアドレスファミリーが含まれる場合も、長時間待ってから接続するように見えることがあります。調査時は実際の宛先アドレスとシステムの接続結果を確認し、最初からアドレスファミリー全体を無効にしないでください。Androidでは、VPNの常時接続やVPNを経由しない接続のブロックなど、クライアント停止後の動作に影響するシステム設定も確認します。

TUNで特定のアプリだけに問題が起きる場合は、そのアプリの接続方式を確認してください。UDPを使うか、ネットワークアダプターを固定しているか、独自プロキシがあるか、LAN内の機器検出が必要かを個別に検証します。根拠なくMTUを下げるより効果的です。ルーターや中継ルーターを使う場合は、ゲートウェイと戻り経路も取り込み範囲に影響します。詳しくはルーターへの導入メモを参照してください。デスクトップ向けのTUN設定をゲートウェイ環境にそのまま適用しないでください。

日常のメンテナンス：更新・バックアップ・段階的なトラブル対処

更新対象を分けて管理する

クライアント本体、プロキシコア、ルーティングデータ、サブスクリプションの内容は、それぞれ別の更新対象です。クライアント更新は画面や設定の生成方法を、コア更新は機能やパラメーターの対応状況を変えることがあります。ルールデータの更新は分類結果に影響し、サブスクリプションの更新はサーバー情報を変更します。更新後に問題が起きたら、まず直前にどの層を更新したか確認してください。すべてを一度に更新すると手間は省けますが、問題を比較する基準が失われます。

更新前にクライアントのバックアップ機能を使い、必要なデータを保存します。現在の取り込み方式、ルーティングプリセット、DNS設定、検証済みのサーバーも記録してください。バックアップには機密性の高い接続情報が含まれる場合があるため、管理された場所に保存し、公開される同期フォルダーには直接置かないでください。アップグレード後は元の最小構成で確認し、その後にTUNや特殊なルールをテストします。プログラムが起動したというだけで古いバックアップを削除したり、すぐに設定変更を続けたりしないでください。

取り込み・コア・リモートの各層でトラブルを切り分ける

まったくアクセスできない場合は、取り込み機能を一時停止し、基本ネットワークが正常か確認します。基本ネットワークにも問題があれば、Wi-Fi接続、ゲートウェイ、システムのネットワーク状態を調べます。基本ネットワークは正常でプロキシだけが失敗する場合は、ローカルの待ち受けとコアのログを確認してください。ブラウザーにローカル接続拒否と表示される場合は、多くの場合、リモートプロトコルではなく待ち受けアドレス、ポート、プロセスの状態が原因です。ログに設定解析エラーがある場合は、直前の変更を戻すのが近道です。

宛先の記録はあるのにリモート接続に失敗する場合は、名前解決の失敗、接続タイムアウト、接続拒否、セキュリティハンドシェイクの失敗を区別します。名前解決に失敗したらDNS経路、タイムアウトならアドレス、ポート、到達性を確認します。接続拒否は通常、宛先ポートが接続を受け付けていないことを示します。ハンドシェイクの問題では、システム時刻、サーバー名、トランスポート、認証パラメーターを確認してください。エラーを隠すために証明書検証を無効にせず、検証に失敗した原因を調べます。

速度を比較するときはテスト条件を揃える

速度が遅いからといって、必ずしもプロトコルに問題があるとは限りません。同じ端末、ネットワーク、宛先、時間帯で測定方法を揃えてから、サーバーを比較してください。ダウンロード先、Wi-Fiの電波状況、回線事業者の経路、ローカルのバックグラウンド処理も結果に影響します。1回の接続テストで分かることには限りがあり、長時間の通信速度を証明するものではありません。同じテストを一覧から何度も実行するより、性質の異なる複数の用途で確認するほうが実利用に近い評価になります。

Web閲覧は正常で大容量ファイルの転送だけに問題がある場合は、接続先の制限、接続の再利用、経路の安定性を確認します。特定のアプリだけが遅い場合は、独自プロキシと名前解決の経路を調べます。すべてのアプリが遅い場合は、基本ネットワークとプロキシ経路を比較してください。TUN環境では、別のVPNやセキュリティソフトが通信を取り込んでいないかも確認します。詳しい手順は速度低下の段階別チェックメモを参照し、根拠なく設定全体を何度も変更しないでください。

問題解決に必要な情報だけをログに残す

通常運用では適切なログレベルを使い、問題を再現するときだけ一時的に詳細度を上げます。発生時刻、操作手順、取り込みモード、エラーの原文を記録すると、サーバー一覧全体のスクリーンショットより役立つことが多くあります。共有前にはアドレス、認証情報、サブスクリプションURL、個人用ドメインなどが含まれていないか確認してください。調査後は通常のログレベルに戻し、ファイルが大量に生成されないようにします。長期間のアクセス記録を通常のバックアップとして安易に共有しないでください。

終了と移行もメンテナンスの一部

クライアントを終了する前に、利用状況に応じてシステムプロキシまたはTUNを停止し、ネットワークが復旧したことを確認します。異常終了後にブラウザーが接続できない場合は、停止したローカル待ち受け先がシステムに残っていないか確認してください。TUN環境ではルートとDNSの復旧状況を調べます。複数のアプリで取り込みを何度も切り替え、古い状態を残さないようにします。再インストールが必要な場合は先にバックアップし、データ破損を確認できたときだけ設定の再構築を検討してください。再インストールをあらゆる問題への共通の対処法にしないでください。

新しい端末へ移行したら、必要な情報だけを復元し、自動起動やバックグラウンド設定を一度にすべて戻さないでください。サブスクリプションの更新、コアの起動、アプリの取り込み、ルールの適用、終了後の復旧を個別にテストしてから自動化を有効にします。長期的なメンテナンスでは、設定を増やし続けるのではなく、既知の動作状態へ戻れる経路を維持することが大切です。よくある問題はFAQカテゴリ一覧から確認できます。複雑な問題は、最小限の再現手順を用意して切り分けてください。

応用編：小さな検証とメンテナンスしやすい設定

具体的な問題を起点に設定を広げる

応用設定の目的は機能を増やすことではなく、実際に確認できた問題を解決することです。まず「特定の業務ドメインを常に直接接続する」「特定のアプリをプロキシ経由にする」「ネットワーク切り替え後に自動で復旧する」など、要件を具体化してください。次に、それが取り込み、ルーティング、名前解決、実行管理のどの層に属するかを判断します。要件を分類できれば変更範囲を絞れます。「全体的に速くしたい」という要望だけの場合は、変更箇所を決める前に再現可能な測定方法と症状を明確にしてください。

それぞれの検証用に基準となる設定を残し、ルーティングプリセットを複製するか、独立したサーバーテスト項目を作成してください。日常設定を直接上書きしないようにします。入力条件、予想される結果、確認方法、元に戻す手順を記録してください。たとえば、完全一致のドメインルールを追加したら、新しい接続でアウトバウンドを確認し、他のドメインまで対象が広がっていないか調べます。検証に成功しても、その設定を長期利用できるとは限りません。再起動、サブスクリプション更新、ネットワーク変更後も同じ挙動になるか確認が必要です。

プロトコル・セキュリティ層・トランスポートを個別に評価する

VLESS、VMess、Trojanを検討するときは、名称から性能を推測するのではなく、現在のサーバーとコアで利用できる条件を確認します。プロトコルは通信方法を定め、TLSなどのセキュリティ機構は接続を保護し、トランスポート方式はサーバー側の構成や中間ネットワークの条件にも左右されます。ある環境で使える組み合わせが、別の回線でも同じように動作するとは限りません。サーバー側が対応している場合に限り、クライアントのパラメーターが意味を持ちます。

トランスポート関連の項目は、接続の両端で一致させてください。パス、サービス名、サーバー名、認証パラメーターにはそれぞれ役割があり、同じ文字列で代用することはできません。共有リンクに項目がない場合は、他のノードからコピーせず、提供元に確認してください。セキュリティハンドシェイクの前に問題が起きたか、後に起きたかによって調査すべき箇所も異なります。意味の説明がない「汎用パラメーター集」を集めるより、ログがどの段階を示しているかを理解することが実用的です。

DNSとルーティングの流れをつなげて考える

応用的なDNS設定では、まず「誰が問い合わせるか」「誰が問い合わせを処理するか」「結果をどの接続で使うか」の3点を明らかにします。ドメインルールは名前解決なしで通信先を決められる場合があり、アドレスルールでは先に名前解決が必要なことがあります。アプリ自身の名前解決はクライアントを経由しない場合もあります。これらの経路を分けて記録すると、上流DNSの設定がどの段階に影響するか分かります。画面の設定を揃えるために、内部ネットワークに適さない上流DNSへすべての問い合わせを無理に集約しないでください。

DNSを振り分ける場合は、名前解決サービス自体への接続経路と、返されたアドレスへの到達性を併せて検証します。問い合わせに成功しても、返された結果が現在のネットワークで使えるとは限りません。アドレスに接続できても、ドメイン分類が想定どおりとは限りません。検証では対象を少数に絞り、ドメイン、返されたアドレス、アウトバウンドをそれぞれ記録してください。初めから大量のルールセット、複数の上流DNS、複雑なキャッシュ設定を導入すると、再現のたびに異なるキャッシュ状態が影響します。

生成された設定を読み、情報の出所を明確にする

GUIでの操作に慣れたら、クライアントが生成した設定を確認し、インバウンドラベル、ルーティング条件、アウトバウンド定義の参照関係を追えます。すべての項目を暗記するのではなく、サーバー情報、グローバル設定、ルーティングプリセットのどれに由来するかを見分けることが重要です。実行時ファイルは再生成されることがあるため、設定を維持する変更は対応する管理画面で行ってください。独自設定が必要な場合は、どの機能を引き継ぎ、どのGUI設定が適用されなくなるかを明確にします。

一度に完成させず、段階ごとに検証する

まず安定した接続を確立し、次に説明できるルーティングを整え、その後で特殊なアプリとTUNに対応し、最後に複数のコアや複雑な名前解決を検討するのがおすすめです。各段階には完了条件があります。接続の段階では成功と失敗を再現できること、ルーティングの段階では宛先のアウトバウンドを説明できること、取り込みの段階ではシステムネットワークを正常に復旧できること、メンテナンスの段階ではバックアップから最小構成を再構築できることが必要です。前段階の確認が終わる前に、次の設定を積み重ねないでください。

複数のコアを切り替える場合は、プロトコル、ルーティングデータ、DNSの挙動を改めて検証してください。起動に成功しただけで設定が同等とは限りません。普段使うコアとプリセットを1組残し、もう1組は明確な機能テストにだけ使うと、切り替えによる不確実性を減らせます。操作手順を最初から確認する場合は使い方ガイドへ、インストール先を探す場合はクライアントのダウンロードへ進んでください。用語と問題の確認には用語ガイドとFAQを利用できます。最終的には、説明・検証・ロールバックができる設定を維持してください。