V2Ray全プラットフォーム インストール・設定完全ガイド

01 / PREPARATION

共通の準備：クライアント、コア、サブスクリプション、ノードを区別する

4つの要素はそれぞれ役割が異なる

インストールを始める前に、画面操作を担うアプリ、プロキシコア、サブスクリプション、ノードを分けて理解しましょう。v2rayN、v2rayNG、v2flyNGは設定管理と操作の入口となるクライアントです。Xray、V2Flyなどのコアは、プロトコルの解析、トランスポートの確立、ルーティング判定、ローカル待ち受けを担当します。サブスクリプションは更新可能なサーバー設定の集合で、ノードはその中の個別のアウトバウンド設定です。クライアントをインストールしただけではサブスクリプションは自動生成されず、サブスクリプションを取り込んでも利用可能なノードが選択されたことにはなりません。完全な通信経路には、クライアント、起動可能なコア設定、現在のノード、正しいローカルプロキシ入口が順番に必要です。

デスクトップ環境では原則として v2rayN を使用します。Windowsではデスクトップ版と従来のWPF版から選択でき、macOSとLinuxでは対応アーキテクチャの v2rayN インストールパッケージを使用します。AndroidではXrayコアを採用する v2rayNG を優先し、V2Flyコアが必要な場合に v2flyNG を選択してください。3つのクライアントのインストール入口はインストールパッケージページにまとめています。このガイドではファイルを直接配布せず、バージョン番号も固定しません。

ダウンロード前にOSとプロセッサのアーキテクチャを確認する

Windowsの一般的な端末ではx64を選択します。macOSでは、まずプロセッサの種類を確認してください。「システム情報」にAppleチップと表示される場合はarm64、Intelと表示される場合はx64を選びます。Linuxではアーキテクチャに加え、パッケージ形式も区別します。Debian、Ubuntuおよび派生ディストリビューションは通常deb、Fedora、Rocky Linux、openSUSEなどは通常rpmを選択します。Androidの近年の主流端末は一般にarm64です。アーキテクチャを確認できない、またはインストール時に互換性エラーが出る場合は、汎用パッケージを試してください。

サブスクリプションを保存する前に、提供元と項目を確認する

サブスクリプションURLはサービス提供者が発行するもので、通常はアクセス資格情報を含むため、機密性の高い設定として管理してください。URLを公開ログ、スクリーンショット、オンライン解析ページに貼り付けないでください。取り込む前に、チャットアプリでURLが途中で切れていないか、先頭と末尾に空白がないか、ブラウザーからのコピー時に改行が混入していないか確認します。提供元が通常のサブスクリプション、クライアント専用サブスクリプション、単一ノードURLを併記している場合は、現在のクライアントに対応すると明記された形式を優先してください。更新が継続的に失敗するときだけ、単一ノードURLでクライアント自体が正常か検証します。

ノード設定には少なくともサーバーアドレス、ポート、プロトコルの認証項目、トランスポートパラメーターが関係します。TLSまたはREALITYを有効にする場合は、サーバー名、フィンガープリント、公開鍵、短いID、パスなどが含まれることもあります。手動編集ではこれらの項目を一組として整合させ、アドレスとポートだけを置き換えないでください。VMess、VLESS、Trojanなどは認証とセッション方式を表し、WebSocket、gRPC、TCPなどはトランスポートを表します。両者は互いに置き換えられません。

まず最小構成で検証できる通信経路を作る

初回設定でTUN、カスタムDNS、複雑なルーティング、複数のサブスクリプションを同時に有効にしないでください。より確実な順序は、クライアントをインストールし、1つのサブスクリプションを取り込み、サーバー一覧を更新し、1つのノードを選択してコアを起動し、その後システムプロキシを有効にしてブラウザーでアクセスを確認する方法です。この最小構成が正常に動作してから、グループ、自動更新、TUN、カスタムルールを追加します。問題が起きたとき、どの段階で変数が増えたかを判断しやすくなります。

テスト中はクライアントのログ画面を開いたままにしてください。正常に起動すれば、少なくともローカルのSOCKSまたはHTTP待ち受けが確立され、ポート競合、設定解析エラー、権限拒否がないことを確認できます。アクセス結果は通信経路全体の可否を示すだけで、特定の層が正しいことを単独で証明するものではありません。クライアントが接続済みでもWebページを開けない場合は、ノードを何度も切り替えるのではなく、システムプロキシがクライアントの実際の待ち受けポートを指しているか確認してください。より詳しい切り分けはプロキシは接続済みなのにWebページを開けない場合の確認項目を参照してください。

02 / WINDOWS

Windows：v2rayNのインストール、サブスクリプション取り込み、システムプロキシ

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

Windowsの入口では、v2rayNデスクトップ版と従来のWPF版を提供しています。デスクトップ版はクロスプラットフォームのUIを採用し、macOSやLinuxと近い画面構成を希望するユーザーに適しています。WPF版は従来のWindows操作を踏襲しており、既存の解説に近いメニュー構成です。どちらもサブスクリプション、ノード、コア、ルーティングを管理でき、同時にインストールする必要はありません。バージョンを切り替える前にカスタムサーバーとルールをエクスポートし、旧クライアントを終了してください。2つのプロセスが同じローカルポートを取り合うのを防げます。

インストール後、スタートメニューから v2rayN を起動します。初回起動時にネットワークアクセスの許可が表示された場合は、実際に利用するネットワークの種類だけを許可してください。会社や公共のネットワークでは、追加のネットワーク範囲を無条件に開放しないでください。クライアントのローカル待ち受けアドレスは通常ループバックアドレスのままでよく、LANで待ち受ける必要はありません。ポータブル版を使う場合は、システムの一時ディレクトリや同期ソフトが継続的にロックするディレクトリを避け、設定ファイルとログを安定して書き込める場所に置きます。

サブスクリプションを取り込み、現在のサーバーを選択する

サブスクリプショングループの管理を開き、新しいグループを作成してURLを入力します。グループ名にはサービスの提供元や用途を使い、「グループ1」のように判別しにくい名前は避けてください。保存後にサブスクリプションを更新し、メイン一覧にノードが表示されれば解析完了です。名前、地域、プロトコルで絞り込み、サーバーを1つ選んでアクティブにします。一覧でクリックしてハイライトしただけでは現在のアウトバウンドが切り替わっていない場合があります。ステータス欄に表示される現在のサーバー名を確認してください。

サブスクリプションの更新では、リモートの一覧を再取得します。手動で追加したノードは専用グループに入れ、更新でサブスクリプションの内容に上書きされないようにしてください。複数のサブスクリプションを使う場合は、グループごとに更新間隔を設定できますが、短すぎる間隔は避けます。起動後に1回更新し、必要なときに手動更新するほうが、変更元を把握しやすいでしょう。ノードが多い場合は、サブスクリプショングループとサーバーフィルターの実践を参考に、メモ、キーワード、並び順を整理してください。

システムプロキシから検証を始める

システムプロキシは、ブラウザーやWindowsのプロキシ設定に従うアプリをまず検証するのに適しています。コアを起動したら、トレイメニューでシステムプロキシを設定し、対象サイトにアクセスします。このモードでは通常、システムのHTTP・HTTPSプロキシをv2rayNのローカル待ち受けポートへ向け、コアが現在のルーティングルールに基づいて直接接続、プロキシ、ブロックを決定します。ブラウザーだけ使えて特定のアプリが使えない場合、そのアプリがシステムプロキシを無視している可能性が高く、ノードが無効とは限りません。

ポートを確認するときは、ターミナルで待ち受け状態を確認できます。具体的なポートはクライアントの設定画面を基準にし、すべての環境が同じ値を使うと決めつけないでください。

netstat -ano | findstr LISTENING
Get-NetTCPConnection -State Listen | Sort-Object LocalPort

ログにポート競合が記録された場合は、まず設定でSOCKS、HTTP、APIのポートが重複していないか確認し、次にプロセス番号から使用中のプログラムを調べます。正体の分からないシステムプロセスを直接終了しないでください。旧クライアントを終了し、重複した自動起動項目を無効にするか、v2rayNのローカルポートを未使用の範囲へ変更してからコアを再起動するのが安全です。

TUNモードとWindows固有の問題

TUNは仮想ネットワークインターフェースを通じて、システムプロキシ設定を読まない通信も広く取り込みます。有効にする前に、同種のネットワークツールを終了し、v2rayNが仮想インターフェースを作成する権限を持つことを確認してください。初回有効化時にシステムがネットワークを再認識し、短時間切断されることがあります。長時間ネットワークが戻らない場合は、すぐにTUNを無効にし、システムプロキシが使えることを確認してから、仮想インターフェース、DNS、ルーティングルールを調べます。クライアントを同時に再インストールする必要はありません。

Windowsでは、セキュリティソフトによるコア子プロセスの一時的なブロック、スリープ復帰後の仮想インターフェース状態の不整合、クライアント異常終了後に残るシステムプロキシ、企業ポリシーによるプロキシ設定の上書きがよくあります。クライアントを正常終了するときは、先にシステムプロキシまたはTUNを無効にしてください。プログラム終了後もブラウザーがローカルプロキシへ接続しようとする場合は、Windowsのプロキシ設定で手動プロキシを無効にしてからクライアントを再起動します。スリープ復帰後に通信できないときは、まずコアを再起動し、それでも改善しなければTUNをいったん無効にして再度有効にします。通常、設定をすべて削除する必要はありません。

03 / MACOS

macOS：チップに合ったv2rayNのインストールと権限・プロキシ残留への対処

チップを確認して対応パッケージをインストールする

「システム情報」または「このMacについて」を開き、まずプロセッサの種類を確認します。Appleチップ搭載端末はarm64、Intel端末はx64のインストールパッケージを選択してください。アーキテクチャを間違えると、アプリが起動しない、起動直後に終了する、互換変換レイヤーに依存して動作するといった問題が起きます。正しくはmacOSダウンロード入口に戻り、対応パッケージを選び直してください。アプリの権限を何度も変更してアーキテクチャの問題を隠そうとしないでください。

インストール時は v2rayN を「アプリケーション」フォルダに移し、その場所から起動します。初回起動でネットワークアクセス、通知、バックグラウンド項目の許可を求められた場合は、クライアントに実際に必要な項目だけを許可してください。開発元を確認できないという警告が出た場合は、まずファイルが当サイトのダウンロード入口から取得されたものか確認し、システムの「プライバシーとセキュリティ」でブロックされたアプリを確認して許可します。不明な転載サイトから依存ファイルを追加しないでください。

サブスクリプションを取り込み、設定フォルダを管理する

サブスクリプション設定を開き、グループを追加して完全なURLを貼り付け、保存後に更新します。更新に成功したのに一覧が空の場合は、キーワードフィルターや特定グループのみの表示が有効になっていないか確認し、ログでサブスクリプションの解析結果を確認してください。ブラウザーでは内容が返るのにクライアントで失敗し続ける場合は、システム時刻、プロキシのループ、証明書のサーバー名を確認します。すぐにサブスクリプションが無効だと判断しないでください。

手動ノードとサブスクリプションノードはグループを分けて保存します。インストールパッケージのアーキテクチャを切り替える、またはクライアントを再インストールする前に、クライアントのエクスポート機能でカスタムノードとルーティングルールを保存してください。設定フォルダは複数人で共有する場所には適しません。同期ツールがクライアントの書き込み中に競合コピーを作成し、JSON設定が重複または途中で切れることがあります。起動後に設定が突然戻った場合は、まずクライアントを終了し、複数の設定コピーが同時に同期されていないか確認します。

システムプロキシの適用範囲

システムプロキシを有効にすると、v2rayNは現在のネットワークサービスのWebプロキシ設定を変更します。ブラウザーやシステムのネットワーク設定に従うアプリは、ローカルHTTPまたはSOCKS入口へ接続しますが、独自のネットワークスタックを実装するアプリは設定を無視することがあります。Wi-Fi、USBネットワーク、有線ネットワークを切り替えた後は、新しいネットワークサービスにもプロキシ設定が適用されているか確認してください。macOSではネットワークサービスごとに一部の設定が保存されるためです。

システムコマンドで現在のネットワークサービスを確認してから、プロキシ状態を調べられます。ネットワークサービス名はローカライズされることがあるため、1つ目のコマンドの出力を基準にしてください。

networksetup -listallnetworkservices
scutil --proxy

クライアントを終了した後にWebページを開けない場合は、まずシステムのネットワーク設定で現在のネットワークサービスのWebプロキシとセキュアWebプロキシを無効にし、その後 v2rayN を再起動します。クライアント起動中にシステムプロキシのポートを手動で別の値へ変更しないでください。画面表示と実際のシステム設定が分離します。ポートを変更する場合はクライアント側で変更し、コアを再起動してシステムプロキシ設定も更新させます。

TUN、DNS、スリープ復帰

macOSのTUNモードでは仮想ネットワークインターフェースを作成してルーティングを変更するため、初回有効化時にシステムの許可が必要になることがあります。許可後はまずデフォルトのルートとDNS設定でテストし、カスタムドメインルールをすぐに追加しないでください。TUNを無効にしても通信が戻らない場合は、仮想インターフェースが消えたか、デフォルトルートが現在の物理ネットワークへ戻ったか、システムDNSが停止済みのローカルポートを指していないかを順に確認します。

蓋を閉じたスリープ、ネットワーク切り替え、テザリングの切り替えによって、インターフェースの順序が変わることがあります。復帰後にクライアントが動作中と表示されてもアクセスできない場合、先にサブスクリプションを更新しても意味はありません。まずコアを再起動し、待ち受けポート、ルート、DNSを現在のネットワークへ再バインドします。システムプロキシが正常で、単一ノードのテストが成功している場合に限り、TUNを再度有効にしてください。TLS接続エラーが続く場合は、システム時刻の自動同期と、サーバー名がノード設定と一致しているかも確認します。判断方法はTLSハンドシェイクと証明書エラーの対処を参照してください。

macOSのファイアウォールや端末管理ポリシーによって、バックグラウンドのネットワーク拡張が制限されることがあります。ログに権限拒否が明確に記録されている場合は、何度も再インストールせず、端末管理のルールに従って対処してください。管理対象端末ではログイン時にプロキシポリシーが一括適用される場合があり、その場合クライアント設定に問題がなくてもシステムプロキシを維持できません。システムのプロキシ照会結果とクライアントの待ち受け状態を突き合わせ、ポリシー層とコア層のどちらに問題があるか判断できます。

04 / LINUX

Linux：パッケージインストール、デスクトッププロキシ、環境変数、TUN

ディストリビューションとアーキテクチャに合うパッケージを選ぶ

Linux版 v2rayN にはdebとrpmのパッケージがあり、x64とarm64も分かれています。まずアーキテクチャ確認コマンドを実行します。出力が x86_64 ならx64、aarch64 または arm64 ならarm64を選択してください。Debian、Ubuntuおよび派生ディストリビューションは通常deb、Fedora、Rocky LinuxなどRPMパッケージ管理を採用するディストリビューションはrpmを使用します。その他のディストリビューションで無理に展開してインストールすると、デスクトップエントリー、依存関係、アンインストール情報を正しく管理できない場合があります。

uname -m
cat /etc/os-release

ダウンロード後、ファイルのあるディレクトリで対応するインストールコマンドを実行します。コマンド内のファイル名は、ダウンロードページに表示された実際のファイル名へ置き換えてください。

sudo apt install ./v2rayN-package.deb
sudo dnf install ./v2rayN-package.rpm

apt install ./ファイル.deb はリポジトリから取得できる依存関係も同時に処理するため、低レベルの展開コマンドを直接使うより一般的なインストールに適しています。rpm系ディストリビューションでは dnf install でも依存関係を解決できます。依存関係を満たせない場合は、まずディストリビューションのソフトウェアソースを更新し、不足しているライブラリ名を確認してください。異なるディストリビューションの基盤ライブラリを混在させないでください。インストール後はデスクトップのアプリメニューから起動し、ターミナルから起動する場合はグラフィック環境や権限エラーを記録できるよう出力を残します。

サブスクリプションの取り込みとデスクトップセッション

v2rayNのサブスクリプション操作は他のデスクトップ環境と同じです。グループを作成し、URLを入力してサーバーを更新し、アクティブなノードを選択してコアを起動します。Linuxではグラフィカルセッションにも注意が必要です。管理者権限でグラフィカルクライアントを起動すると、設定フォルダの所有者が変わり、後で一般ユーザーが設定を書き込めなくなることがあります。ソフトウェアパッケージのインストールやTUN権限の設定以外では、昇格した権限を使わず、v2rayNを管理者として常用しないでください。

デスクトップ環境によってシステムプロキシの入口は異なります。GNOMEやKDEなどには通常ネットワークプロキシ設定がありますが、各アプリがそれを読み取るかどうかはネットワーク実装によって決まります。v2rayNのシステムプロキシを有効にしたら、ブラウザーとターミナルのプログラムを個別にテストしてください。ブラウザーは正常でもコマンドラインツールが直接接続する場合、ターミナルがデスクトッププロキシを読み取っていないのであり、コアのエラーとは限りません。

ターミナルプログラムのプロキシ環境変数

現在のターミナルセッションだけをローカルHTTPプロキシ経由にする場合は、環境変数を一時的に設定できます。ポートは v2rayN のHTTPインバウンドと一致させてください。コマンドの終了後は unset で消去し、パッケージマネージャーや社内ツールが意図せずローカルプロキシへ接続し続けるのを防ぎます。

export http_proxy=http://127.0.0.1:ローカルHTTPポート
export https_proxy=http://127.0.0.1:ローカルHTTPポート
export no_proxy=localhost,127.0.0.1
unset http_proxy https_proxy no_proxy

ここでいう「ローカルHTTPポート」は説明用の文字列であり、実行前にクライアントの設定画面に表示された数字へ置き換える必要があります。ログイン、更新、コンテナ、バックグラウンドタスクの動作を十分に確認しない限り、環境変数を全ユーザーのグローバル設定へ永続的に追加しないでください。SOCKSプロキシは、すべてのプログラムでHTTPプロキシとして直接利用できるわけではありません。プログラムがSOCKSに対応している場合は、パラメーター形式に従って socks5://127.0.0.1:ポート と入力します。

TUNの権限、ルーティング、DNS

LinuxのTUNは、仮想ネットワークデバイス、ルーティング機能、それに対応する権限に依存します。有効化に失敗した場合は、まずデバイスの存在を確認し、ログから権限不足、モジュールが利用できない、ルート追加に失敗した、のどれかを判断してください。クライアント全体に無制限の管理者権限を与えないでください。ディストリビューションが能力ベースの権限やサービスコンポーネントでTUNを提供している場合は、クライアントのインストール手順を使い、更新後も権限が有効か確認します。

ls -l /dev/net/tun
ip address
ip route
resolvectl status

TUNを有効にした後、ドメインを解決できない一方で既知のアドレスには応答がある場合、問題は通常DNS経路にあります。両方とも失敗する場合は、デフォルトルート、ポリシールート、ファイアウォールを優先して確認します。systemd-resolvedを使用するシステムでは、/etc/resolv.conf の表面的な内容だけでなく、現在のインターフェースが実際に使用しているDNSも確認してください。NetworkManagerは再接続後にDNSとルートを書き換えることがあるため、ネットワーク切り替え後はコアを再起動して再確認します。

Linux固有の別の問題として、デスクトップセッションとバックグラウンドプロセスが分離することがあります。ウィンドウを閉じてもクライアントがトレイに残る場合もあれば、デスクトップ環境の終了とともに停止する場合もあります。リモートセッションを終了する前に、システムプロキシまたはTUNを明示的に停止し、ローカル待ち受けが消えた後も環境変数だけが残らないようにしてください。ログに「address already in use」と出た場合は、ss -lntup で待ち受けプロセスを調べ、v2rayNや古いコアの重複起動がないか確認します。

05 / ANDROID

Android：v2rayNG・v2flyNGのインストールとアプリ通信の取り込み

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

Androidでは v2rayNG を優先します。Xrayコアを使用し、一般的なプロトコルとトランスポート設定に対応しています。V2Flyコアが必要な場合は v2flyNG を選択してください。両方を個別にインストールすることはできますが、日常の利用では1つのクライアントだけがシステムVPNインターフェースを確立する状態にしてください。後から起動したアプリが先の接続を置き換えるためです。インストールパッケージはarm64版と汎用版があり、近年の主流端末ではarm64を優先します。インストール互換性エラーが出る、またはアーキテクチャを確認できない場合は汎用版を使用してください。

Androidダウンロード入口からインストールパッケージを取得すると、現在のブラウザーまたはファイルマネージャーによるアプリのインストール許可を求められることがあります。インストール後は、その提供元に対する一時的なインストール許可を無効にしてください。アップグレードでは同じクライアントに対応するパッケージを上書きインストールすれば、既存の設定を保持できます。署名が一致しないと表示された場合は、いきなりアンインストールして再インストールせず、まずダウンロード元とアプリ名を確認し、必要なら設定をエクスポートしてから対応します。

サブスクリプションを取り込み、ノードを選択する

v2rayNGを開き、サブスクリプショングループ設定からURLを追加して保存し、メニューのサブスクリプション更新を実行します。更新後にメイン一覧へ戻り、ノードを1つ選択して現在の設定にします。現在のノードは、一覧左側またはステータス領域の選択マークで確認できます。更新成功と表示されたのに新しいノードがない場合は、別のグループを開いていないか、サブスクリプションが空の内容を返していないか、一覧フィルターが新しい項目を隠していないか確認してください。

クリップボードから単一リンクを取り込み、特定ノードの検証やサブスクリプション解析問題の切り分けに使うこともできます。クリップボードにチャットの文章とURLが同時に入っている場合があるため、取り込む前に設定リンク全体だけをコピーしてください。QRコードは別の端末から単一設定を移すのに便利ですが、アクセスパラメーターを含むため公開しないでください。大量のノードはサブスクリプショングループで管理し、サーバーパラメーターを1件ずつ更新する方法は避けます。

接続を開始し、アプリごとに通信を振り分ける

ノードを選択して接続ボタンをタップすると、システムが初めてVPNインターフェースを作成する際に許可ダイアログが表示されます。許可後、クライアントは端末上に通信入口を作り、ルーティング設定に従ってプロキシ経由にする接続を決定します。ステータスバーの接続マークはインターフェースが確立したことを示すだけで、リモートのハンドシェイク成功までは保証しません。クライアントのテスト結果とログも確認してください。ノードテストに失敗したら、まず同じサブスクリプション内の別ノードへ切り替え、単一ノードの問題か全設定の問題かを判断します。

Androidのアプリ単位プロキシでは、クライアントを経由するアプリを指定できます。不要なローカル通信を減らすのに適しています。設定時は「選択したアプリのみプロキシ」か「選択したアプリを除外」かを明確にしてください。2つの動作は正反対です。リストを変更したら再接続し、システムインターフェースに新しいルールを読み込ませます。ブラウザーは使えるのに対象アプリが使えない場合は、まずアプリ単位のリスト、対象アプリ独自のDNS動作、バックグラウンド通信制限を確認してください。

バックグラウンド制限、プライベートDNS、モバイルネットワーク切り替え

省電力設定によって v2rayNG や v2flyNG のバックグラウンド動作が制限され、画面ロック後しばらくすると接続が切れ、アプリへ戻ると復旧することがあります。システムのバッテリー管理でクライアントに必要なバックグラウンド動作を許可し、データセーバーが通信を妨げていないことを確認してください。ネットワーク機能と無関係な権限まで与える必要はありません。バックグラウンドクリーナーがVPNアプリを強制停止する場合は、現在のクライアントを自動終了対象から除外します。

システムの「プライベートDNS」を有効にすると、ドメイン要求がクライアントの想定するDNS経路を迂回したり、ノード設定と異なる解決結果になったりすることがあります。ドメインに接続できないのにアドレスには接続できる場合は、一時的にDNSを自動設定へ戻して比較し、システム設定を維持するかクライアントに統一して処理させるか判断してください。複数のカスタムDNS層を同時に有効にすると、ログには最終的な失敗しか残らず、どの層で書き換えられたか確認しにくくなります。

Wi-Fiとモバイルネットワークの切り替えによって、端末の外向き経路が変わります。切り替え後も接続中に見えていても、基盤のセッションが無効になっていることがあるため、切断して再接続してください。公共ネットワークでWeb認証が必要な場合は、まずクライアントを一時停止してネットワークへログインし、その後接続を再開します。特定のネットワークだけ使えない場合は、そのネットワークのDNS、IPv6、ポート制限を比較し、すぐにサブスクリプションを削除しないでください。TLSエラーではシステム時刻の自動同期と、ノードのサーバー名が完全かどうかも確認します。

06 / SUBSCRIPTION · ROUTING

サブスクリプション、ノード、ルーティング：プラットフォームをまたいだ統一管理

サブスクリプションの更新とノードの切り替えは別の操作

サブスクリプションの更新は指定URLからノードの集合を再取得する操作で、ノードの切り替えは現在使うアウトバウンドを変更する操作です。両者は独立しています。更新後に元のノードが削除、改名、パラメーター変更されることがあるため、クライアントに古い名前が表示され続ける場合はサーバー一覧に戻り、現在の選択項目を確認してください。自動更新を設定する場合は適切な間隔を保ち、まず手動更新の結果を確認します。頻繁なリクエストでノードの可用性が上がるわけではなく、設定変更の追跡が難しくなります。

複数のサブスクリプションを使う場合は、提供元ごとにグループを作り、メモで地域、回線、用途を表すと管理しやすくなります。ノードの元の名前だけでプロトコルやセキュリティパラメーターを判断しないでください。名前は表示用の文字列にすぎません。設定を確認するときは詳細を開き、プロトコル、アドレス、ポート、トランスポート、セキュリティ層、サーバー名を確認します。提供元が管理するサブスクリプションノードは、差異を明確に把握していない限り、主要項目を個別に変更しないでください。次回更新でローカルの変更が上書きされる可能性があります。

元に戻せる設定の基準を作る

複雑なルールを追加する前に、動作確認済みの基本設定を1つ残します。内容は、1つのサブスクリプション、検証済みの1ノード、デフォルトルート、デフォルトDNSです。変更は一度に1種類だけ行い、たとえばドメインの直接接続ルールを追加して検証してから、アドレスルールを追加します。異常が起きても直前の動作状態へ戻しやすくなります。クライアントにエクスポート機能がある場合は、グループやルーティングを大幅に変更する前に設定を保存してください。ただし、エクスポートファイルにはノードのアクセスパラメーターが含まれるため、機密ファイルとして扱います。

ノードテストはあくまで選別用です。TCP接続が確立したことは、サーバーのポートへ接続できることを示すだけで、認証、TLS、トランスポート経路、最終アウトバウンドがすべて正常とは限りません。実際の判断にはコアのログと完全なアクセス結果を組み合わせます。テストが突然すべて失敗した場合は、全ノードを削除するのではなく、まず本体のネットワーク、システム時刻、DNS、サブスクリプション項目を確認してください。

ルーティングのマッチング順を理解する

ルーティングルールは通常、上から順に評価され、最初に一致したルールが直接接続、プロキシ、ブロックを決めます。範囲の広いルールを先に置くと、後ろの具体的なルールが上書きされることがあります。たとえば全ドメインを対象にするプロキシルールを先に書くと、後に置いた特定ドメインの直接接続ルールは実行されません。保守しやすい順序は、明示的なLAN・本体宛先、個別処理が必要な具体的ドメイン、分類ルール、最後にデフォルトアウトバウンドです。

以下はコアのルーティング構造を簡略化した例で、項目の階層とマッチング方法を示しています。実際のアウトバウンドタグはクライアントが生成した設定と一致させる必要があり、名前を推測してはいけません。

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

geoip:private は一般的なプライベートアドレス範囲に一致させ、LAN機器の通信がリモートへ送られるのを防ぐために使います。例のドメインはルール形式の説明用です。クライアントのGUIではこれらの項目がプリセットルールとしてまとめられていることがありますが、有効にする前にプリセットのマッチング順とデフォルトアウトバウンドを確認してください。アドレスルールとドメインルールは完全に同じではありません。アプリが先にドメインを解決してからアドレスへ接続する場合、コアがどの層の情報を見られるかは、取り込みモードとDNS処理によって変わります。

ルーティングが効かないときは、確認できる情報から調べる

システムプロキシモードでは、HTTPプロキシに対応するアプリは通常ドメインをプロキシ入口へ渡すため、ドメインルールが適用されやすくなります。一部のアプリは本体で先に名前解決してからアドレスへ接続するため、IPルールだけに一致することがあります。TUNモードはより広い通信を取り込めますが、DNSスニッフィングとルーティング設定も必要です。想定と異なる振り分けになった場合は、サイトの表示だけで判断せず、まずログで対象が実際にどのルールへ一致したか確認してから順序を調整します。

LANプリンター、ルーター管理画面、開発サービスを直接接続のままにする場合は、プライベートアドレスの直接接続ルールを残し、クライアントがローカルネットワークへのアクセスを許可しているか確認します。システムプロキシがループバックアドレスだけで待ち受けている場合、本体上のアプリは利用できますが、LAN上の他の端末はプロキシ入口として利用できません。明確な必要性がない限り、LAN待ち受けを有効にしないでください。共有待ち受けにはファイアウォール、アクセス制御、ネットワーク境界の検討も必要で、通常の単一端末設定の範囲を超えます。

07 / PROXY · TUN · DNS

システムプロキシ、TUN、DNS：3つの経路を連携させる方法

システムプロキシは、明示的にプロキシを使うアプリだけを取り込む

システムプロキシは、OSのHTTP、HTTPS、SOCKSプロキシ設定をクライアントのローカル待ち受けポートへ向ける仕組みです。ブラウザーやシステム設定に従うプログラムはそのポートへ自発的に接続し、クライアントが要求を現在のノードへ渡します。経路が分かりやすく、必要な権限が少なく、問題が起きても復旧しやすい点が長所です。一方、システムプロキシを読まないプログラムや、UDP通信、独自ネットワークスタックはこの入口を通らないことがあります。

システムプロキシを調べるときは、システム設定のプロキシアドレス、プロキシポート、クライアントの実際の待ち受けアドレスという3つの値を同時に確認します。よくある間違いは、クライアントでローカルポートを変更したのにシステムには古い値が残っている、またはクライアント終了後もシステムが存在しないローカルポートへ接続し続けることです。正常終了の前にシステムプロキシを停止すると残留を減らせます。システムプロキシは使えるのに特定のアプリだけ使えない場合は、そのアプリ自身のプロキシ設定を確認し、すぐに全体ルーティングへ変更しないでください。

TUNが取り込むのはネットワークインターフェースとルーティング

TUNモードは仮想ネットワークインターフェースを作成し、システムルートを通じてより多くの通信をクライアントへ送ります。システムプロキシに対応しないアプリ、統一的な振り分けが必要なデスクトップ環境、一部のUDP通信に適しています。低い層で動作するため、インターフェース権限、デフォルトルート、DNS、ファイアウォール、他の仮想ネットワークツールの影響を受けます。有効にする前に、同じノードがシステムプロキシモードで使えることを確認してください。リモートノードとローカルインターフェースを同時に調べる負担を減らせます。

TUNを有効にすると、通常は物理インターフェース、ループバックインターフェース、仮想インターフェースが同時に存在します。デフォルトルートまたはポリシールートが、通信の経路を決めます。有効化直後に全通信が途切れた場合は、まずTUNを無効にして基本ネットワークを復旧し、ログでインターフェース作成とルート追加の結果を確認します。通信が切れた状態でDNSやMTUを次々に変更しないでください。復旧後にどの変更が有効だったか分からなくなります。

DNSがドメインをルーティング判定へ渡す方法を決める

DNSはドメインをアドレスへ変換するだけでなく、ドメインルールを正確に適用できるかにも影響します。システムプロキシモードでは、アプリがドメインをローカルプロキシへ渡す場合もあれば、自分で先に解決する場合もあります。TUNモードでは、クライアントがDNSを取り込むことでドメインと接続の関連を保持できます。名前解決がクライアントを迂回すると、ルーティング層には宛先アドレスしか見えず、ドメインで設定したルールが期待どおりに実行されないことがあります。

DNSの異常は、主に3種類に分けられます。要求が想定したリゾルバーへ届いていない、解決結果は正しいが誤った経路へ振り分けられている、リゾルバーには到達できるが現在のネットワークに適さない結果が返る、の3つです。まずシステムツールでドメインが解決できるか確認し、次にクライアントのログにDNS要求とルール一致が記録されているか調べます。ブラウザーのキャッシュだけを消して判断しないでください。OS、クライアント、ブラウザーがそれぞれキャッシュを持つ場合があります。

グローバルプロキシとルールプロキシの使い分け

グローバルプロキシは、取り込み可能な通信を現在のプロキシアウトバウンドへ一律に送る設定で、ノードを短時間検証するのに適しています。グローバルモードでは使えるのにルールモードでは使えない場合、原因は多くの場合、ルーティングルール、DNS、マッチング順にあります。LAN、システム更新、ローカルサービスには直接接続が必要なことがあるため、すべての環境での既定設定には向きません。検証が終わったら、確認済みのルールモードへ戻してください。

ルールプロキシは、ドメイン、アドレス、ポート、ネットワーク種別、プロセス条件などで出口を選択します。ルールが増えるほど保守の負担も増します。用途を説明できるルールだけを残し、カスタム項目には分かりやすいメモを付けてください。ルールを削除する前に、他の項目がそのアウトバウンドタグに依存していないか確認します。クライアント更新やサブスクリプション更新で独立して保存したルーティング設定が通常上書きされることはありませんが、設定一式を取り込むと現在の設定が置き換わる場合があります。取り込み前に、元へ戻せるコピーをエクスポートしてください。

要求がどの入口を実際に通ったか確認するには、まずコアのアクセスログを確認し、アプリのプロキシ設定と照合します。ログに接続記録がまったくない場合は、アプリからローカル入口までに問題があります。インバウンド記録はあるのにリモート接続がない場合は、ルーティングとアウトバウンドを確認します。リモート接続を開始しているのにハンドシェイクに失敗する場合は、ノードパラメーター、システム時刻、ネットワーク到達性を調べます。この層別の判断は、モードを何度も切り替えるより効率的です。

08 / TROUBLESHOOTING

よくある設定トラブル：本体、コア、サブスクリプション、リモートを層ごとに切り分ける

まず現象を記録し、問題の層を絞り込む

トラブル対処の前に、現在のプラットフォームとクライアント、システムプロキシかTUNか、すべてのノードに影響するか、ログにある最初の明確なエラーという4点を記録します。「使えない」とだけ記録しないでください。起動失敗、ドメイン解決失敗、リモートハンドシェイク失敗、特定アプリだけプロキシを使わないケースでは、対処手順がまったく異なります。設定は一度に1項目だけ変更して再テストし、複数の変更が互いに原因を隠さないようにします。

最短の確認手順は、通常のネットワークが使えること、クライアントとコアのプロセスが動作していること、ローカル待ち受けポートが存在すること、現在のノードが選択されていること、システムプロキシまたはTUNが有効なこと、最後にリモートハンドシェイクとルーティング一致を確認することです。すべてのノードが同時に失敗する場合は、本体のネットワーク、時刻、DNS、サブスクリプション、クライアント設定を優先して確認します。1つのノードだけ失敗する場合は、そのノードと利用可能なノードのアドレス、ポート、トランスポート、セキュリティパラメーターを比較します。

コア起動後すぐに終了する

コアの起動失敗は、通常ログの冒頭に原因が記録されます。ポート競合はローカル待ち受けをバインドできないことを示します。設定解析エラーは、生成されたJSONの項目、カンマ、型が要件に合っていないことを示します。必須パラメーターの不足は、ノードを手動編集した際にセキュリティ層の項目を漏らした場合によく起きます。権限拒否はTUNインターフェースや保護されたフォルダで発生しやすい問題です。最初のエラーから処理してください。後続のエラーは、最初の失敗による連鎖反応にすぎない場合があります。

ポート競合の場合は、重複しているクライアントを終了するか、待ち受けポートを変更します。設定エラーの場合は、直近の手動変更を元に戻すか、比較用に最小構成のノードを新規作成します。ログ全体を削除して最後の1行だけ残さないでください。設定ファイルのパスや具体的な項目は、通常その前に記録されています。ログからコア起動失敗を特定する方法を参照し、エラーの種類を1行ずつ判断できます。

接続済みと表示されるのにWebページを開けない

「接続済み」は、クライアントの状態が実行中に切り替わっただけで、ブラウザーがローカルプロキシへ接続できていることを示さない場合があります。まずシステムプロキシのアドレスとポートを確認し、ブラウザーがシステム設定を上書きしていないか調べます。TUNモードでは仮想インターフェースとデフォルトルートを確認してください。ログにブラウザーの要求がまったくない場合は、アプリとローカル入口の間が問題です。要求がありDNS失敗と表示される場合は名前解決経路を確認し、リモート接続がタイムアウトする場合はアドレス、ポート、ネットワーク到達性を調べます。

グローバルモードでは使えるのにルールモードでは使えない場合は、デフォルトのルーティングルールへ戻すか、カスタムルールの順序を確認します。アドレスには接続できるのにドメインで失敗する場合は、追加したプライベートDNS、ブラウザーのセキュアDNS、システムのカスタムDNSを一時停止して比較します。LAN宛先だけ失敗する場合は、すべてのルーティングを無効にするのではなく、プライベートアドレスの直接接続ルールを追加します。項目ごとの完全な確認手順は接続後にWebページへアクセスできない場合の切り分けを参照してください。

サブスクリプションの更新に失敗する、または更新後に空になる

まずサブスクリプションURLが完全で、空白、改行、期限切れのパラメーターを含まないことを確認します。次に、現在のネットワークからサブスクリプションサービスへ接続できるか、システム時刻が正しいか、まだ起動していないローカルプロキシを経由して更新しようとしていないか確認してください。複数のグループがある場合は、正しいグループに対して更新を実行しているか確認し、フィルターを無効にして元の結果を表示します。内容は返るのに解析に失敗する場合は、サブスクリプション形式が現在のクライアントに対応しているか確認します。

更新後にノードが減るのは、リモートのサブスクリプション内容が変わった可能性があり、クライアントがデータを削除したとは限りません。カスタムノードは専用グループに入れ、リモート項目と混在させないでください。クライアントの解析能力を確認する場合は、明確に互換性のある単一ノード設定を取り込めます。単一ノードは使えるのにサブスクリプションだけ失敗するなら、問題は取得または形式にあります。単一ノードも失敗する場合は、コアのログに戻って調べます。

TLS、サーバー名、システム時刻

TLS関連のエラーは、具体的なメッセージと照らし合わせて確認します。証明書がまだ有効でない、または期限切れという表示が出た場合は、最初にシステムの日付、時刻、タイムゾーンを確認します。サーバー名が一致しない場合は、ノードのserverNameまたはSNIがサービス設定と一致しているか確認してください。ハンドシェイクが早期終了する原因として、トランスポート経路、ポート、サーバー側の状態も考えられます。「証明書の検証をスキップ」を通常の修復方法にしないでください。本人確認の問題を隠すだけで、誤ったアドレス、サーバー名、時刻は直りません。

REALITYの設定では、公開鍵、短いID、サーバー名、フィンガープリントなどの項目も互いに一致させる必要があります。ノードのコピー時に1つでも漏れると、ハンドシェイクに失敗することがあります。サブスクリプションで管理しているノードは、別のノードから項目を推測せず、完全な設定を再更新することを優先してください。分類ごとの詳しい説明はTLSハンドシェイク、SNI、時刻の確認を参照してください。

検証可能な状態へ戻す

何度も変更して原因が分からなくなった場合は、すべてのデータを削除するのではなく、管理された手順でロールバックします。保持したい手動ノードとルールを先にエクスポートし、TUN、カスタムDNS、追加ルートを無効にして、システムプロキシモードへ戻します。サブスクリプション1つとノード1つだけを有効にし、クライアントを再起動して起動から最初の要求までのログ全体を確認してください。最小構成が使えるようになったら、設定を1項目ずつ戻し、戻すたびにテストします。

クライアントを更新する前も同じ原則に従います。現在の動作モードを記録し、実行中のコアを終了し、カスタム設定を保存してから、対応するプラットフォームとアーキテクチャのパッケージをインストールします。更新後はまず基本経路を検証し、すぐにすべての設定を変更しないでください。画面は起動するのに旧設定だけが異常な場合は、設定移行ログとファイル権限を確認します。Linuxでは設定フォルダの所有者、Windowsでは重複プロセス、macOSではネットワークサービスのプロキシ残留、AndroidではシステムVPNの許可とバックグラウンド制限に特に注意してください。