V2Rayの使い方ガイド：インストールと設定

01 / concepts

基本概念：通信がどの層を通るかを把握する

クライアント、コア、サーバー

V2RayはProject Vのエコシステムに属するプロキシ技術であり、単独のデスクトップアプリではありません。v2rayNはノード、サブスクリプション、ルーティング、起動オプションを管理するGUIを提供し、コアはローカルポートで待ち受け、リクエストを処理してリモート接続を確立します。クライアントの画面が正常に開いても、GUIが起動したことしか確認できず、コアの起動成功を意味するわけではありません。

V2FlyはV2Rayコアの開発を引き継いでおり、Xrayも関連するコアの一つですが、対応機能は完全には同じではありません。クライアントに同じ形式のノード情報を保存できても、実際に動作するかどうかは選択したコアに左右されます。VLESS、REALITY、特定のフロー制御を使う場合は、サーバー側の設定に合うコアを選んでください。プロトコル名だけで互換性を判断することはできません。

リモートサーバーは、リクエストがローカルのプロキシ経路を抜ける先です。クライアントをインストールしても、サーバーアドレスや認証情報、サブスクリプションが自動で用意されるわけではありません。ノードの入手先は各自で確認してください。このガイドではソフトウェアの設定を説明します。接続障害はローカルのプログラム、ネットワーク経路、サーバーのいずれでも発生し得ます。原因をクライアントに決めつけず、各層を分けて確認しましょう。

入口、ルーティング、出口

一般的なリクエストの流れは、アプリがローカルのSOCKSまたはHTTP入口に接続し、コアがルーティングルールに従って出口を選び、直接接続またはプロキシ経由で送信する、というものです。システムプロキシが適用されるのは、その設定を参照するアプリだけです。ルーティングルールが処理するのはコアに届いた通信です。そのため、もともとプロキシを使わないプログラムを、ルールの変更だけでクライアントに通すことはできません。

ノード一覧の各項目には通常、サーバーアドレス、リモートポート、プロトコル、認証情報、トランスポート方式、安全層のパラメーターが含まれます。ローカルの待ち受けポートは入口の設定であり、リモートポートとは別の項目です。サーバーのポートをブラウザーのローカルプロキシ設定に入力したり、ローカルポートをノードのアドレスに指定したりすると、リクエストは誤った接続先に送られます。

「接続」にも複数の段階があります。クライアントでノードを選択した状態、コアプロセスの起動、サーバーへの接続確立、接続先サイトからの応答は、それぞれ別の状態です。一度テストに成功しても、すべてのアプリがプロキシを使うとは限りません。一つのサイトが開かなくても、ノード全体が使えないとは限りません。まず、どの段階で失敗したかを特定すると、次に確認すべき点が明確になります。

プロトコル、トランスポート、安全層

VMess、VLESS、Trojan、Shadowsocksはそれぞれ異なるプロキシプロトコルを表します。TCPやWebSocketはトランスポート方式、TLSやREALITYは接続の安全性やハンドシェイクに関わる仕組みです。各項目は自由に組み合わせられる選択肢ではありません。クライアントとサーバーで必要な設定項目を一致させる必要があり、一方の設定を変更しただけでは動作せず、もう一方も変更が必要な場合があります。

プロトコル名だけで速度の優劣を決めることはできません。実際の性能は回線、サーバー負荷、トランスポートのオーバーヘッド、接続先サービス、ローカルネットワークに左右されます。まず互換性を満たしたうえで、同じ環境で安定性を比較してください。証明書の検証を無効にしたり、ハンドシェイクのパラメーターをむやみに変更したりすることは、通常の性能改善ではありません。まず、元の設定でその項目が必要な理由を確認しましょう。

02 / clients

クライアント選び：対応プラットフォームと互換性を確認

デスクトップではv2rayNを選ぶ

Windows、macOS、Linuxのデスクトップではv2rayNを使います。ノード管理、サブスクリプションの更新、ローカル入口、ルーティング設定をGUIでまとめて扱えるため、このガイドでは主な操作対象として取り上げます。複数のOSに対応していても、システムの動作が完全に同じとは限りません。起動時の権限、システムプロキシの設定方法、仮想ネットワークアダプターの対応、設定の保存場所は、OSとインストール方法によって異なります。

Windows向けにはデスクトップ版とクラシックWPF版があります。デスクトップ版はクロスプラットフォームのGUIを採用し、WPF版は従来のWindows向けインターフェースを維持しています。初めてインストールする場合はデスクトップ版から試せます。WPF版に慣れている場合や特定の設定が必要な場合は、現在の画面や機能を比較して選んでください。両方を同時にシステムプロキシの管理に使わないでください。また、バックアップなしで同じ書き込み可能な設定フォルダーを共有するのも避けましょう。

macOSでは、プロセッサに応じてApple Silicon版またはIntel版のインストーラーを選びます。チップの種類は「このMacについて」で確認できます。Linuxでは、プロセッサに加えてディストリビューションのパッケージ形式も確認してください。一般的なデスクトップPCはx64、一部の端末はarm64です。debとrpmはパッケージ管理形式の違いであり、コアのプロトコル対応を表すものではありません。ファイル名だけ変更して互いの代わりにインストールすることもできません。

Androidクライアントとデスクトップの違い

Androidではv2rayNGが第一候補です。V2Flyコアが必要な場合はv2flyNGも検討できます。比較的新しい一般的な端末ではarm64版を選び、アーキテクチャが分からない場合は汎用版を検討できますが、最終的には端末の対応状況を確認してください。インストールできたからといって、すべての機能に互換性があるとは限りません。プロセッサのアーキテクチャはアプリが動作するかを左右する要素であり、ノードのプロトコルとOSの制約も別途確認が必要です。

Androidクライアントは通常、OSのVPNサービスを使って通信を処理するため、起動時にシステムの許可を求められます。デスクトップのシステムプロキシとAndroidのVPNによる通信の取り込みは、設定名だけで単純に比較できません。Androidではバッテリー最適化、バックグラウンド動作の制限、ほかのVPNアプリとの競合も確認します。デスクトップでは、待ち受けポートの競合、権限不足、システムプロキシを無視するアプリがよく問題になります。

デスクトップとAndroidで同じサブスクリプションを読み込めますが、どちらもすべての項目に対応しているとは限りません。一方では動作し、もう一方では失敗する場合は、すぐにサブスクリプションの破損を疑わず、解析後のプロトコル、トランスポート、安全層、コアの対応状況を比較してください。サブスクリプションの内容、クライアントの設定、OSによる通信の取り込みは別々に確認します。端末間で設定をコピーしても、この確認を省略することはできません。

クライアントを決めてからダウンロード

クライアント選びの段階で3つすべてをインストールする必要はありません。まず1つで安定した基本設定を作り、明確な互換性要件がある場合に別のクライアントを試してください。頻繁に切り替えると確認項目が増えます。古いクライアントが残したシステムプロキシ設定やバックグラウンドプロセスが、新しいプログラムの動作に影響する場合もあります。長期間使う端末では、画面を次々に変えるより、元に戻せる設定を残しておくほうが役立ちます。

ダウンロードページには、4つのプラットフォーム向けのインストーラーがあります。ページを開く前にOS、プロセッサのアーキテクチャ、パッケージ形式を確認し、ダウンロード後にインストールの章へ進んでください。既存のクライアントから移行する場合は、ローカル入口のポート、ルーティング設定、サブスクリプションのグループも記録しておきましょう。これらの情報は通常のノード共有リンクに含まれないことがあるため、別途保存が必要です。

03 / installation

インストール確認：プログラムの起動とポートの待ち受け

OSのインストール手順を完了する

Windowsではインストーラーの案内に従って保存先を選び、インストールを完了します。初回起動後、画面とログに問題がないか確認してください。クラシック版とデスクトップ版では設定の保存場所が異なることがあるため、フォルダー名だけを見て上書きしないでください。追加のランタイムが必要な場合は、現在のインストーラーの案内に従ってください。古い手順をもとにコンポーネント名を推測したり、複数のインスタンスを同時に起動して待ち受けポートを競合させたりしないでください。

macOSではチップに合ったディスクイメージを開き、案内に従ってアプリケーションフォルダーに移動します。セキュリティ警告が表示された場合は、インストール元と警告の理由を確認してから、システム設定で起動を許可してください。システムのセキュリティ設定を恒久的に弱めることを、一般的なインストール手順にしないでください。アップデート時に古いプロセスが動作している場合は、終了してから新しいアプリを起動し、設定の読み込み先を確認します。

Linuxでは、ディストリビューションのグラフィカルなソフトウェアインストーラーでdebまたはrpmパッケージを開きます。依存関係は対応するパッケージ管理ツールで処理されます。インストール後はアプリメニューから起動し、まず一般ユーザーで画面、設定フォルダー、ログを確認してください。追加権限が必要な機能を有効にする場合に限り、必要な許可を設定します。GUIクライアント全体を常に高い権限で動かすと、設定ファイルやネットワーク操作に与える権限の範囲が広がります。

Androidでは、OSが許可するインストール手順でインストーラーを開きます。初回起動後にノードを追加し、VPNの許可を確認してください。「アプリをインストールできません」と表示された場合は、アーキテクチャ、空き容量、署名の異なる旧アプリの有無を確認します。アンインストールするとアプリのデータが消えることがあるため、旧アプリを削除する前に必要な設定をエクスポートしてください。バックアップなしの再インストールを、最初のトラブル対処にしないでください。

コアと待ち受けアドレスを確認する

クライアントの画面が起動したら、まずログでコアの起動結果を確認してください。有効なノードがない場合、クライアントがプロキシサービスをまだ起動していないことがあります。エラーがある場合は、まず関連する最初のエラーを解消してからネットワークをテストします。ポートの競合、設定ファイルの構文エラー、コアの互換性不足は別々の問題です。接続ボタンを繰り返し押しても原因は変わらず、ログが読み取りにくくなるだけです。

ローカル入口は、127.0.0.1のようなループバックアドレスで待ち受ける設定を優先してください。この設定なら同じ端末からのリクエストだけを受け付けられ、通常の初期設定に適しています。「LANからの接続を許可」を有効にするとアクセス可能な範囲が広がるため、ファイアウォールとアクセス制御も必要です。ブラウザーを接続するだけの目的で、すべてのネットワークインターフェースに公開しないでください。端末内の接続失敗は、通常LANの許可とは無関係です。

ss -tlnp
ss -tlnp 'sport = :10808'

Linuxでは、1つ目のコマンドでTCPの待ち受け状態を一覧表示し、2つ目で例示したポートだけを確認します。権限が不足しているとプロセス名が正しく表示されないことがありますが、まずアドレスとポートの有無を確認できます。該当ポートで待ち受けていない場合は、クライアントの設定と起動ログを確認してください。別のプロセスが使用している場合は、用途を確認してからクライアントのポートを変更するか、競合するサービスを停止します。

インストール後の確認基準を作る

初回確認では通信の取り込み方法を1つだけ有効にし、システムプロキシとTUNを同時に使わないでください。有効なノードを追加し、ローカルプロキシを明示的に指定するツールでコアを確認してから、システムプロキシをテストします。この順番なら、「プログラムが待ち受けていない」状態と「アプリがプロキシを使っていない」状態を切り分けられます。最初から複数のモードを重ねると、どの設定が影響したのか判断しにくくなります。

インストール完了の基準は、画面が開くこと、有効な設定でコアが起動すること、ローカル入口が待ち受けること、終了後にネットワーク設定を復元できることです。複雑なルーティングを急いで設定する必要はありません。まずシンプルな基本状態を保ち、その後の機能追加を比較できる基準にしましょう。

04 / subscription

サブスクリプションの追加：グループ、更新、ノードの確認

サブスクリプションと共有リンクを区別する

サブスクリプションのリンクは更新可能なノードの一覧を指し、ノード共有リンクは通常、1つのノード情報を記述します。内容をコピーしたら、まず配布元の説明でどちらの形式か確認し、適切な方法で追加してください。サブスクリプションのアドレスを単一ノードのリンクとして解析したり、ノード共有テキストをサブスクリプション欄に入力したりすると、一覧が空になることがあります。プロキシモードを切り替えても解決しません。

v2rayNでは、サブスクリプションのグループ設定を開き、新しいグループを追加して名前と完全なアドレスを入力します。保存後、そのグループのサブスクリプションを更新してください。名前は用途や入手先で分けると、更新エラーを確認しやすくなります。アドレスのクエリーパラメーターはアクセス認証に使われることが多いため、コピー時に省略しないでください。改行、引用符、末尾の句読点、チャットアプリが挿入した余分な空白にも注意しましょう。

サブスクリプションのアドレスにはアクセス認証情報が含まれることがあるため、機密情報として扱ってください。スクリーンショットを公開する場合は全体を隠し、ログを共有する前にもクエリーパラメーターが含まれていないか確認します。サブスクリプションからノード設定を取得できても、配布元の信頼性が保証されるわけではありません。用途が分からないサブスクリプション、QRコード、設定ファイルは、内容と入手元を確認してからクライアントに追加してください。

更新成功だけではノードが使えるとは限らない

更新後は、ノードが表示されたか、正しいグループに入ったか、想定したプロトコルかを確認してください。サブスクリプションの取得に成功したことは、内容を取得できたことを示すだけです。ノードの期限切れ、サーバーへの到達不可、現在のコアが未対応の設定項目などが残っている場合があります。まず1つのノードをテスト対象にし、グループ、コア、ルーティング、通信の取り込み方法を同時に変更しないでください。比較の基準が失われます。

ノードの編集画面を開き、サーバーアドレス、リモートポート、認証情報、トランスポート方式、安全層を確認します。WebSocketのパスとホスト名、TLSのサーバー名、REALITYの公開鍵などは、むやみに削除しないでください。サブスクリプションの解析後に必要な項目が欠けている場合は、配布元の形式とクライアントの対応状況を確認しましょう。セキュリティチェックを無効にして、欠けたパラメーターを補うことはできません。

v2rayNGとv2flyNGでも、サブスクリプションは用途が分かるグループに保存してから更新し、ノードを選びます。Androidでは画面上の項目名が異なることがありますが、「サブスクリプションの保存」と「プロキシ接続の開始」は別の操作です。一覧の更新後、現在選択しているノードが削除済みの項目ではないか確認し、起動ログも確認してください。一覧の項目数が増えたかだけでは判断できません。

更新に失敗したときに確認する2つの通信経路

サブスクリプションの更新リクエストは、直接接続する場合と現在のプロキシを経由する場合があります。ローカルに使用可能なノードがない場合は、配布元の案内に従って直接接続を試してください。安定したノードがある場合は、プロキシ経由の更新も試せます。接続経路を変えても、期限切れのアドレス、無効な認証、サーバーから返される不正な形式は解決しません。まずログを確認し、そのうえでリクエスト方法を変更するか判断しましょう。

一覧が空の場合は、リクエスト自体の失敗、サブスクリプションではなくWebページが返された、対応していない形式、フィルターによる全項目の非表示を区別します。ログインページが返された場合、何度インポートしても有効なノードは追加されません。グループの絞り込みが原因なら、一覧の表示範囲を戻してください。具体的なエラー内容を記録しておけば、無意味な再試行を減らし、配布元にも正確に伝えられます。

複数端末で同期する場合は、まず共通のサブスクリプションを共有し、システムプロキシ、ポート、ルーティングなど端末固有の設定はそれぞれ管理してください。通常の共有リンクには、すべての全体設定が含まれるわけではありません。詳しくは複数端末間で設定を同期する方法をご覧ください。初回追加の簡単な手順はクイックスタートのサブスクリプション手順で確認できます。

05 / proxy modes

プロキシモード：通信の取り込み方法と出口の選択

システムプロキシはアプリの入口を決める

システムプロキシは、OSにローカルのHTTPまたはSOCKSアドレスを登録し、その設定に従うアプリにクライアントを使わせる仕組みです。すべてのネットワークパケットを自動的にプロキシへ転送するものではありません。システム設定を参照するブラウザーもあれば、独自のネットワーク設定を使うプログラムもあります。コマンドラインツール、ゲーム、バックグラウンドサービスもシステムプロキシを無視する場合があります。テストでは、対象アプリがこの入口に対応しているか確認してください。

v2rayNの「システムプロキシを設定」「システムプロキシを解除」などの操作は、OSに保存されたプロキシ設定を変更します。設定後はローカルの待ち受けが続いているか、解除後はアプリ側に別のプロキシ設定が残っていないか確認してください。システムプロキシを起動時にしか読み込まないアプリは、切り替え後に再起動が必要です。長時間の接続が以前の経路を使い続けることもあるため、ページの再読み込みだけで判断しないでください。

Linuxデスクトップ環境のネットワーク設定では、手動でプロキシアドレスを入力できることが一般的です。SOCKSのホストにはローカルのループバックアドレス、ポートにはクライアントの対応する入口を入力します。HTTP欄にはクライアントが提供するHTTPまたは互換性のある混合入口を指定してください。すべてのプロトコルを任意のポートに向けることはできません。デスクトップの設定がターミナルのプロセスに適用されるかどうかは、アプリと環境変数の扱いにも左右されます。

グローバル設定とバイパスルールで出口を決める

グローバルプロキシは通常、コアに届いた宛先を主にプロキシ経由で送る設定を指します。OS上のすべてのアプリがプロキシを使うという意味ではありません。「中国本土のサイトをバイパス」などの事前設定済みルーティングは、ドメインやアドレスの分類とルールの順序に基づき、直接接続するかプロキシ経由にするかを決めます。設定が作用する層は異なるため、グローバルに設定していても特定のプログラムが直接接続することはあり、必ずしもコアの障害ではありません。

初めて使う場合は既定のルーティングから始め、一般的な接続先にアクセスできることを確認してから用途に応じて調整します。Web閲覧や日常業務では、ローカルサービスとリモートサービスの両方を考慮する必要があります。開発ツールには個別のプロキシ設定が必要な場合があり、ゲームではUDP、サーバーの地域、遅延も影響します。モード名だけで選ばず、アプリの通信がクライアントに届くか、選択した出口がそのリクエストに対応しているかを確認してください。

AndroidのVPNによる通信の取り込みは、デスクトップのシステムプロキシとは異なります。クライアントにアプリごとの選択やLANのバイパス設定があっても、コアのルーティングとは分けて考えてください。アプリが取り込み対象から除外されている場合、その通信はコアのドメインルールを通りません。コアのルーティングを変更しても、OSですでに適用された除外設定を上書きすることはできません。

入口を指定して通信を確認する

curl -x socks5h://127.0.0.1:10808 -I https://www.example.com

このコマンドはSOCKS入口を明示しているため、プロキシ自体とシステムプロキシ設定を切り分けるのに役立ちます。socks5hでは、接続先のホスト名をプロキシ側で解決します。ポートはクライアントで現在設定されている値に置き換えてください。HTTPレスポンスが返れば、そのリクエスト経路が機能していることを確認できます。具体的なステータスコードは接続先サイトによって異なるため、特定のコードだけでネットワーク全体が正常だとは判断できません。

コマンドでローカルポートへの接続に失敗した場合は、まず待ち受けアドレスとポートを確認します。入口に接続できてもハンドシェイクに失敗する場合は、ノードとログを確認してください。コマンドは成功するのにブラウザーで失敗する場合は、ブラウザー独自のプロキシ設定、拡張機能、安全なDNSを確認します。この順番で調べれば、アプリの問題をサーバー障害と誤認せず、最初からTUNを有効にする必要もありません。

この章を終えたら、次の2点を説明できるようにしましょう。アプリの通信がどの入口からクライアントに届くか、届いた通信の出口をどのルールが選ぶか。この2点が明確になって初めて、ルーティングを検証できます。

06 / routing

ルーティング：ルールの優先順位とDNSの境界

少数の明確なルールから始める

ルーティングルールは、リクエストを指定した出口へ振り分けます。条件にはドメイン、宛先アドレス、ポート、ネットワーク種別などがあります。通常、ルールは上から順に照合され、最初に一致したルールで出口が決まります。そのため、特定の宛先に対する例外は、範囲の広いルールより前に置いてください。すべてをプロキシ経由にするルールの後に直接接続の例外を追加しても、先のルールに処理されたリクエストには適用されないことがあります。

ドメインルールでは、full:は完全一致、domain:は指定したドメインとそのサブドメイン、geosite:はドメイン分類の一覧を参照します。プレフィックスのない文字列はキーワードとして照合される場合があり、意図しない範囲まで一致することがあります。初心者は明示的なプレフィックスを優先してください。アドレスルールのCIDRはネットワーク範囲を表し、分類一覧はローカルのリソースファイルを参照します。リアルタイム検索サービスではありません。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:www.example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

これは設定の一部であり、そのまま起動できる完全な設定ではありません。使用前に、現在のコアにproxyとdirectという出口があり、対応する分類リソースも利用できることを確認してください。v2rayNのGUIのルーティング画面はコア設定を生成します。ルールを追加する際は、画面に登録済みの出口に割り当ててください。クライアントが生成したファイルを直接上書きすると、再起動やノード切り替え時に変更が失われることがあります。

DNS設定：どこでドメインを名前解決するか

DNSはドメイン名をIPアドレスに変換しますが、名前解決はアプリ、OS、コア、プロキシ経路の向こう側で行われる場合があります。ブラウザーの安全なDNS、独自の名前解決ライブラリ、システムのDNS設定は、それぞれ独立していることがあります。コアのDNSを特定のサーバーに変更しても、すべてのアプリがすぐにその設定を使うとは限りません。アプリがすでにドメインをIPアドレスに変換している場合、ドメインベースのルーティングでは元の名前を取得できないことがあります。

AsIsは、ルーティング時にアドレスとの照合を目的とした名前解決を積極的に行わないことを示します。ほかのドメインポリシーでは、必要に応じて名前解決が行われる場合があります。コアのDNS設定、ルーティング時のドメイン処理、出口側の名前解決は関連していますが、別々の設定です。アドレスルールが一致しない原因をDNSサーバーの障害と決めつけず、リクエストがドメイン名とIPアドレスのどちらを使っているか、現在のポリシーが変換を行うかを確認してください。

トラブル対処では、同じ接続先に対するアプリからの直接接続、明示的に指定したSOCKS入口、システムプロキシの結果を比較します。ブラウザーだけで問題が起きる場合は、ブラウザーの名前解決とキャッシュを確認してください。ログに名前解決のタイムアウトが出る場合は、DNSリクエストのルーティングと到達性を確認します。IPアドレスの固定で名前解決を恒久的に回避しないでください。アドレスの変更、証明書の名前、コンテンツ配信の振り分けに影響します。

ルールの検証と競合の解消

ルーティングを変更する前に元のルールを保存し、追加するルールは再現可能な宛先1つだけを扱うようにします。テストではアクセスログに記録された宛先と出口を確認してください。Webページが開くかどうかだけでは、ルールに一致したか判断できません。直接接続とプロキシのどちらでも成功する場合があるためです。ログにリクエストがなければ、前の章に戻って通信の取り込み方法を確認します。出口が想定と違う場合は、前にあるルール、分類リソース、宛先の形式を確認してからルールの順序を調整してください。

1つのルールに複数の条件を指定すると、通常はすべての条件を満たす必要があります。同じ項目に複数の候補値を指定した場合は、いずれかに一致すればよいのが一般的です。ドメインとアドレスを同時に入力すると、想定より条件が厳しくなることがあります。「ドメインまたはアドレスに一致」の動作が必要なら、2つのルールに分けると明確になり、失敗した条件も個別に検証できます。

07 / tun

TUNモード：通信の取り込み範囲を広げ、復旧手段を確保する

仮想ネットワークアダプターが必要な場合

TUNは仮想ネットワークデバイスで通信を受け取り、明示的なプロキシを設定できないアプリ、システムプロキシを無視するアプリ、より広い範囲の通信を処理したい場合に適しています。変わるのはプロキシ経路に通信を取り込む方法であり、使えないノードが再び使えるようになるわけではありません。SOCKSを明示したテストがすでに失敗している場合は、まずノードとコアを修復してください。そうしないと、TUNによって同じ障害がより多くのアプリに広がります。

TUNの動作は、クライアントの実装、使用するコア、ネットワークスタック、OSの権限によって異なります。「TUNモードを有効化」という項目があっても、現在の環境で必要な条件がすべて整っているとは限りません。仮想ネットワークアダプター、ルーティング、DNSの処理に専用コンポーネントを使うクライアントもあります。現在のログで起動結果を確認し、すべてのデスクトップ環境で同じ実装だと考えないでください。

有効にする前に、使用中のノード、システムプロキシの状態、デフォルトルートを記録し、機能を無効にする手段が引き続き使えることを確認してください。リモート管理中の端末では特に注意が必要です。ルーティングの変更によって現在のセッションが切断されることがあります。まず直接操作できる環境で検証してから、常時接続が必要な端末で使ってください。プロキシネットワークに頼らず実行できる復旧方法も残しておきましょう。

権限、ルーティング、ループバック

仮想デバイスの作成やルーティングの変更には、管理者権限が必要な場合があります。LinuxではOSが提供するTUNデバイスと関連権限も確認してください。macOSやWindowsでは、システムの許可やコンポーネントのインストールを求められることがあります。権限エラーが出たら、ログで失敗した手順を特定します。設定フォルダー全体の権限を再帰的に変更したり、問題を隠すためにすべてのプログラムを高い権限で起動したりしないでください。

プロキシ自身がサーバーに接続する通信は、仮想デバイスの外へ出られる必要があります。そうでないと、コアの通信が再び取り込まれてリモートサーバーに届かない、トラフィックのループが発生することがあります。通常は自動ルーティングや除外機能で対処されますが、別のVPN、仮想ネットワークアダプター、カスタムルートを併用すると競合する場合があります。テスト前にほかの通信取り込みソフトを停止し、経路を1つにしてください。

LAN内への接続も個別に確認します。プリンター、ファイル共有、開発用サービス、ルーターの管理画面では、ローカル経路を残す必要があります。LANのバイパスは、正体不明のアドレスすべてを直接接続にする設定ではありません。ローカルアドレス帯と関連する名前解決を適切に扱うものです。外部サイトには接続できるのにローカルサービスが使えない場合は、ノードをすぐに変更せず、ローカルルーティングとDNSを確認してください。

すべてを一度に有効にせず、段階的に検証する

検証済みのノードとシンプルなルーティングを維持し、不要なシステムプロキシを解除してからTUNを有効にします。起動ログを確認した後、ブラウザー、システムプロキシに従わないアプリ、LAN内のサービスを順番にテストしてください。これで通信の取り込み範囲が実際に広がったか確認できます。DNSとルーティングを同時に変更すると、仮想デバイスと新しいルールのどちらが問題の原因か分かりにくくなります。

UDPの利用には、アプリの通信が取り込まれる方法、コアの処理、サーバーの対応を含む経路全体のサポートが必要です。TUNを有効にしても、すべてのUDPリクエストが成功するとは限らず、ゲームの通信品質が向上するとも限りません。アプリによっては、独立した認証サービス、音声サービス、特定のネットワークインターフェースも関係します。Webページを1つ試しただけで、すべてのプロトコルが使えると判断せず、問題が発生した機能のログを確認してください。

スリープからの復帰、Wi-Fiの切り替え、有線ネットワークへの接続後は、仮想デバイスとデフォルトルートを改めて確認してください。ネットワークインターフェースが変わると以前の状態が無効になることがあります。ノードをむやみに変更するより、通信取り込みサービスを再起動するのが適切な場合があります。同じ問題が頻繁に起きる場合は、発生前後のインターフェース、ルート、ログを保存し、再現できる記録を作ってからTUNを常用するか判断してください。

08 / maintenance

日常のメンテナンス：更新、バックアップ、障害記録

3種類の更新対象を分けて管理する

クライアントプログラム、サブスクリプションの内容、ルーティング用の分類リソースは、それぞれ別のものです。クライアントの更新は画面や機能の実装を変え、サブスクリプションの更新はノード一覧を変え、分類リソースの更新はドメインやアドレスのルールに影響します。トラブル対処中にこれらを同時に変更しないでください。1種類の更新が終わるたびに、現在の基本設定をテストして結果を確認してから次に進みます。

クライアントを更新する前に、使用中の機能に関係する変更内容を読み、必要なコアや設定形式が引き続き使えるか確認してください。バージョン番号を上げるためだけに頻繁に再インストールする必要はありませんが、互換性やセキュリティ修正に関わる更新を無視するのも避けてください。更新後は、画面が開くことだけでなく、ノードの起動、サブスクリプションの解析、ルーティング、通信の取り込みを確認します。

サブスクリプションの更新頻度は、配布元で実際に内容が変更される頻度に合わせます。過度に頻繁にリクエストしても認証エラーは解決せず、サーバー側の制限を受けることもあります。更新後に元のノードが消えた場合は、通常の置き換えか確認してから新しい項目を選んでください。分類リソースの更新後に特定の宛先の出口が変わった場合は、分類の一致状況と例外ルールを確認します。すべての宛先をグローバルプロキシに変更しないでください。

復元できるバックアップを作る

バックアップには、サブスクリプショングループ、手動ノード、ルーティングルール、重要な全体設定を含めてください。まずはクライアントが提供するエクスポート機能を使います。設定フォルダーをコピーする場合は、データベースや設定ファイルへの書き込みを避けるため、事前にプログラムを終了してください。パスや保存方法はプラットフォームによって異なるため、別のOSのフォルダーから推測せず、現在のプログラムが使っている場所を確認しましょう。

設定のバックアップには、サーバーの認証情報、サブスクリプションのアクセス情報、端末固有の設定が含まれることがあります。アクセス制限のある場所に保存してください。相談用のスクリーンショットやログは、元データとは別に機密情報を隠したコピーを作り、バックアップをそのまま公開しないでください。移行時は新しい端末に読み込んでから、待ち受けアドレス、ポート、権限、通信の取り込み方法を手動で確認します。旧端末の環境設定をそのままコピーするのは避けましょう。

復元できるかどうかは、小規模なテストで確認してください。設定をエクスポートし、重要な項目を記録してから、独立したテスト環境に読み込んで確認できます。ファイルが存在するだけでは、バックアップを使えるとは限りません。プラットフォームをまたいで復元する場合は、互換性のないパス、起動項目、権限に特に注意してください。ノード情報は再利用できても、OSとの連携設定は作り直しが必要なことがあります。

通信経路に沿ってトラブルを確認する

接続に問題が起きたら、まずシステム時刻と基本ネットワークを確認し、次にローカル入口、コアのログ、ノード接続、DNS、ルーティングを調べます。システム時刻の大幅なずれは、ハンドシェイクや認証に影響することがあります。基本ネットワーク自体が使えない場合は、先にネットワークを復旧してください。ローカルポートが開いていない場合はコアの起動を確認し、リモートサーバーや分類ルールを推測で疑う段階ではありません。

障害を記録する際は、発生時刻、クライアントの種類、使用中のコア、通信の取り込み方法、接続に失敗した宛先、エラーの原文を明記します。「開けない」だけでは、接続タイムアウト、名前解決の失敗、証明書エラー、アプリ自体のエラーを区別できません。ログは問題の前後に関係する部分を順序を保って抜き出し、機密情報を隠してください。ログレベルを上げるのは短時間の診断だけにし、完了後は通常のレベルに戻します。

日常のメンテナンスでは、使わなくなったサブスクリプション、重複ノード、一時的なルール、古い起動項目も確認し、用途がないものを整理してください。削除前にバックアップを取り、整理後に動作を再確認します。用途の分からない設定を重ねないことで、今後の障害原因を特定しやすくなり、古いプログラムが不要なシステムプロキシ設定をバックグラウンドで復元することも防げます。

09 / next steps

上級設定への道筋：使える設定から、説明できる設定へ

生成された設定を読み解いてからカスタマイズする

上級設定の第一歩は、スイッチを増やすことではなく、現在の設定を説明できることです。まずクライアントの設定表示やログの場所を確認し、インバウンド、アウトバウンド、ルーティング、DNSの対応関係を把握します。GUIの選択肢1つから複数のコア設定項目が生成される場合があります。この対応関係を理解すると、GUIを変更したときの動作を説明でき、使い捨ての生成ファイルを恒久的な設定元と誤認せずに済みます。

カスタム設定を使う場合は、クライアントがどのように読み込み、GUIのどの設定が有効なままかを確認してください。カスタムファイルによって、GUIからの生成処理の一部が適用されなくなる場合があります。GUIに表示されたルーティングモードが、ファイル内の実際のルールを反映するとは限りません。カスタム設定を全体に適用した後は、最終的に読み込まれたファイルと実行ログを基準にし、GUIの選択肢だけから動作を推測しないでください。

JSONファイルの構文チェックは最初の確認にすぎません。括弧、カンマ、文字列が正しくても、コアがその項目に対応しているとは限らず、出口のタグが正しく結び付くとも限りません。まず構造を確認し、次にコアとの互換性を調べ、最後にネットワーク上の動作を検証します。機能を追加するときは、具体的なテスト対象を決めてください。プログラムがエラーなく起動しただけで、すべての経路が動くと判断してはいけません。

目的を定めて検証する

開発ツールをプロキシ経由にしたい場合は、まずツール独自のプロキシ対応を確認し、システムプロキシ、明示的な入口、TUNのどれを使うか決めます。特定のドメインを直接接続したい場合は、リクエストにドメイン名が含まれることを確認してから個別の例外を追加します。名前解決の違いを解消したい場合は、アプリとコアそれぞれの解決経路を比較してください。目的を1つに絞るほうが、用途不明の大規模な設定を読み込むより安定した結果を得やすくなります。

検証前に、どのアプリ、宛先、入口、出口を使うか予想を書き出します。検証後はログで結果を照合し、失敗したら直前の使用可能な設定に戻してください。記録を残せば、更新後や端末移行後に再確認でき、「設定で意図した動作」と「実際の動作」を区別できます。テスト用サイトが表示する単一の情報だけで、端末上のすべてのアプリの通信経路を判断しないでください。

性能を比較するときも、条件をそろえる必要があります。端末、ネットワーク、接続先サービス、テスト時間帯をできるだけ統一し、接続の確立、継続的な転送、長時間の安定性をそれぞれ確認してください。1回のダウンロード速度でノード全体の性能を判断することはできません。サーバーの制限や接続先の混雑も結果に影響します。遅延を捏造したり、プロトコル名だけで順位をつけたりせず、再現可能な観察結果を記録しましょう。

プロトコルの学習とセキュリティ上の注意点

VLESS、REALITY、XTLS Visionをさらに学ぶ場合は、まずTLSハンドシェイク、認証、トランスポート層の基礎を確認してください。REALITYではクライアントとサーバーで合意したハンドシェイクパラメーターを使い、Visionでは特定のフロー制御を処理します。どちらも単独で速度を上げるスイッチではありません。ノードの配布元が示す項目はまとめて照合し、必要な値が欠けている場合は設定要件を確認してください。解説記事をもとに値を推測しないでください。

技術的な背景を知りたい場合は、REALITYとXTLS Visionの仕組みを読んでから、使用中のコアが対応しているかクライアントで確認してください。技術解説では仕組みを説明しますが、実際の接続はサーバー側の設定に従います。学習中は動作中のメイン設定を変更せず、検証用のノードを別に作ると、日常の利用に影響しません。

プロキシを使っても、アプリ自体のセキュリティ対策を代替することはできません。Webサイトの正当性、アカウント認証、ファイルの入手元、端末の権限は、それぞれ別に確認してください。LANからの接続を許可する場合、ローカル入口を公開する場合、入手元が不明なカスタム設定を読み込む場合は、アクセス範囲と実行内容を事前に把握する必要があります。設定を共有するときは必要な構造だけを示し、機密情報を隠してください。個人のサービスに直接アクセスできる認証情報を含めてはいけません。

シンプルで動作する設定を基準として残し、必要な機能を1つずつ追加してください。各設定に目的、検証方法、取り消し手順があれば、保守しやすい設定になります。上級機能をすべて同時に有効にする必要はありません。