V2Ray初心者から上級者まで完全設定ガイド

01

仕組みを理解する

基本概念：クライアント、コア、通信経路

まずGUIクライアントとプロキシコアを区別する

v2rayN、v2rayNG、v2flyNGは、それぞれ異なるプラットフォーム向けのGUIクライアントです。サブスクリプションの保存、ノードの表示、実行設定の生成、システムプロキシの変更、起動と停止をわかりやすい画面で行います。実際に接続、プロトコル、トランスポート、ルーティングを処理するのは、クライアントが呼び出すコアです。v2rayNはデスクトップ環境で対応するコアを管理でき、v2rayNGは主にXrayコアを実行コンポーネントとして使用し、v2flyNGはV2Flyコアに対応します。トラブルシューティングでは、問題が画面、システムプロキシ、コアのどの層で起きているかを切り分ける必要があります。画面に起動済みと表示されても、プロセスが開始されたことを示すだけで、対象アプリの通信がローカルプロキシに入ったとは限りません。

Project Vは、関連するプロトコル、ツール、実装によって形成された技術エコシステムです。V2FlyとXrayは、その中でよく使われるコアの系統です。一般ユーザーにとって、コアの違いは主にプロトコル対応、設定フィールド、トランスポートの組み合わせに現れます。クライアントを選ぶ際に、すべての基盤フィールドを先に調べる必要はありませんが、サブスクリプション内のノードプロトコルが現在のコアで認識される必要があります。たとえば、ノードがVLESSとREALITYの組み合わせを使用する場合、クライアントとコアの両方が対応するフィールドをサポートしていなければなりません。サブスクリプションの更新に成功しただけでは、ノードのパラメータが実行可能とは限りません。

インバウンド、アウトバウンド、ルーティングでリクエストを理解する

V2Rayの設定は、まず3つの要素に分けて考えられます。インバウンドはローカルアプリからの通信を受け取り、一般的にはローカルのSOCKSまたはHTTPポートを使います。TUNが取り込む仮想ネットワーク通信もインバウンドに含まれます。アウトバウンドは通信の次の行き先を決め、通常はプロキシ、直接接続、ブロックの少なくとも3種類があります。ルーティングはその間に位置し、ドメイン、IP、ポート、ネットワーク種別、プロセスなどの条件からアウトバウンドを選びます。この流れを理解すれば、GUIの各項目も独立したものではなくなります。システムプロキシはアプリに使用するインバウンドを伝え、ノード選択はプロキシアウトバウンドのパラメータを決め、ルールはリクエストごとに渡すアウトバウンドを振り分けます。

ブラウザでウェブサイトにアクセスする場合を例にします。ブラウザはまずシステムプロキシの設定に従い、クライアントが待ち受けるローカルポートへリクエストを送ります。コアは対象ドメインを取得すると、ルールを上から順に確認します。プロキシルールに一致すれば現在のノードへ渡し、直接接続ルールに一致すればローカルネットワークから直接接続します。ブラウザがシステムプロキシを読み取らない、アプリが独自のネットワークスタックを実装している、またはルール判定前に対象アドレスが誤って解決される、といった場合は通信経路が変わります。そのため、「クライアントが起動している」「システムプロキシが有効」「アプリの通信が取り込まれている」は、それぞれ別に確認する必要があります。

ノード、共有リンク、サブスクリプションは別の概念

ノードは接続を確立するためのパラメータ一式で、通常はサーバーアドレス、ポート、ユーザー識別子、プロトコル、トランスポート方式、TLS関連の設定、サーバー名などを含みます。共有リンクは単一ノードをシリアライズした表現で、たとえば vmess:// や vless:// から始まるテキストです。サブスクリプションURLは複数のノードやグループ設定を取得し、後から更新するために使います。サブスクリプション自体はプロキシサーバーではなく、更新可能な一覧に近いものです。ローカルのサブスクリプションを削除してもリモートの内容は変わりません。サブスクリプションから生成された単一ノードへの変更は、次回更新時に上書きされる可能性があります。

プロトコルとトランスポートも層を分けて理解しましょう。VMessやVLESSは接続プロトコルを表し、TCP、WebSocket、gRPCなどは通信を載せる方式を表します。TLSやREALITYなどは、特定のセキュリティとハンドシェイクの組み合わせを担います。各フィールドはサーバー側の設定と一致していなければならず、ローカルの項目を何度も切り替えて当てずっぽうで試すものではありません。用語を詳しく確認したい場合は、用語解説 →を参照してください。この構造を先に理解しておけば、後のインストールや設定で「サブスクリプション更新失敗」「ノードのハンドシェイク失敗」「システムが通信を取り込んでいない」を同じ問題として扱わずに済みます。

02

環境を整える

クライアントの選択とインストール

プラットフォームとコアの要件でクライアントを選ぶ

デスクトップではv2rayNが第一候補です。Windows、macOS、Linuxに対応し、サブスクリプション管理、システムプロキシ、ルーティング、TUNを使いたいユーザーに適しています。Androidではv2rayNGまたはv2flyNGを選べます。v2rayNGはXrayコアを使用するため、新しいXrayプロトコルの組み合わせを含むサブスクリプションに向いています。v2flyNGはV2Flyコアを使用し、V2Flyの設定体系に対応する選択肢です。3つのクライアントのインストール先、システムアーキテクチャ、パッケージ形式はダウンロードページ →にまとめています。ファイル名の似た単語だけでプラットフォームを判断しないでください。

Windows、macOS、Linuxでのインストール時の確認点

Windowsユーザーは、まずデスクトップ版とクラシックWPF版のどちらを使うか選びます。デスクトップ版はクロスプラットフォームのUIを採用しており、異なるデスクトップ環境で操作方法をそろえたい場合に適しています。クラシックWPF版は、従来のWindows UIや既存の設定手順に慣れているユーザー向けです。どちらもシステムプロキシを同時に制御させないでください。バージョンを変更する前に、実行中のクライアントを終了し、サブスクリプションURL、ルーティング設定、カスタムポートを記録します。システムトレイに古いプロセスが残っている場合は、使用中のプログラムフォルダーを直接削除せず、先に通常の手順で終了してください。

macOSではチップのアーキテクチャが最も重要です。Apple Silicon搭載デバイスはarm64向け、Intel搭載デバイスはx64向けのインストーラーを選びます。チップの種類は「システム情報」で確認できます。初回起動時にはアプリの実行許可を求められることがあります。システムプロキシやTUNを有効にすると、ネットワーク設定の許可が表示される場合もあります。許可は該当するシステムネットワーク設定を書き込むために使われ、拒否すると対象モードを完全には有効化できないことがあります。アプリを別のフォルダーへ移動すると、システムに記録されたパスが変わる可能性があるため、配置を固定してからログイン時の自動起動を設定することをおすすめします。

Linuxでは、まずディストリビューションに合わせてdebまたはrpmパッケージを選び、次にプロセッサのアーキテクチャを確認します。Debian、Ubuntuおよび派生ディストリビューションでは通常debを使い、Fedora、Rocky Linuxなどrpm系ではrpmを使います。デスクトップ環境によってシステムプロキシのインターフェースが異なるため、クライアントが設定を書き込んだ後、デスクトップのネットワーク画面でHTTP、HTTPS、SOCKSプロキシがローカルの待ち受けアドレスを指しているか確認してください。ターミナルだけで動くプログラムはデスクトッププロキシを自動的に読み取らないことが多く、環境変数の明示設定やTUNが必要になる場合があります。

Androidのインストールとバックグラウンド動作

近年の主要なAndroidデバイスは通常arm64を使用します。アーキテクチャを確認できない場合は、ユニバーサルパッケージを選べます。インストール後、初回接続時にシステムのネットワーク接続許可が表示されます。これはローカル通信の取り込みに必要な標準手順です。v2rayNGとv2flyNGを同時に接続状態にしないでください。後から起動したクライアントが、システムのネットワーク取り込み用チャネルを占有します。クライアントを切り替える前に現在の接続を切断し、同じサブスクリプションを読み込んで互換性を比較してください。

モバイルOSでは、画面消灯後にバックグラウンドプロセスが制限されることがあります。ロック画面にしてしばらくすると接続が切れる場合は、まずクライアントのバッテリー使用設定、バックグラウンド動作の許可、省電力ルールを確認してください。最初からノードのパラメータを変更する必要はありません。モバイル通信とWi-Fiの切り替えでは既存の接続が無効になり、コアがアウトバウンドを再接続します。このときの一時的な切断はネットワーク環境の変化によるものです。復旧しない状態が続く場合にログを確認します。クライアントを最近使ったアプリ一覧に固定するか、バックグラウンド動作を許可すると、システムによる回収を減らせます。

インストール後は最小構成で確認する

インストール後はクライアントを起動しますが、TUN、複雑なルーティング、カスタムDNSはまだ有効にしないでください。画面が正常に開くこと、コアが起動すること、ログフォルダーに書き込めることを確認し、デフォルトのローカルポートを記録します。その後、確実に有効なサブスクリプションまたはノードを1つ読み込み、システムプロキシで初回接続を行います。最小構成を基準にすると、正常に動作した場合の問題は追加したルーティング、DNS、TUNの項目に絞れます。最小構成でも失敗する場合は、サブスクリプション、ノードパラメータ、ローカルポートの競合を先に確認してください。

03

設定を作る

サブスクリプションの追加、ノード選択、更新

追加前にサブスクリプションURLの範囲を確認する

サブスクリプションURLは通常HTTPSのアドレスで、クライアントがノード一覧を取得するために使います。コピー時はパスとクエリパラメータを含む完全なURLを保持し、ドメイン部分だけをコピーしないでください。ページの表示用URLとサブスクリプションAPIのURLを混同してはいけません。URLの前後に空白や改行がある場合は、保存前に削除します。サブスクリプションは慎重に管理すべき設定入口であり、公開スクリーンショット、ログ投稿、他人が読める同期ドキュメントに載せないでください。提供元がURLを変更した場合は、クライアントのサブスクリプション項目を更新し、古いURLから生成されたノードを修正し続けないようにします。

v2rayNでは通常、サブスクリプショングループの管理画面を開き、名前とURLを追加して保存した後、更新を実行します。v2rayNGまたはv2flyNGでは、サブスクリプション設定から項目を追加し、メイン画面に戻って更新します。名前はローカルで識別するためだけのものなので、用途や環境名を付けられます。追加後はサブスクリプショングループだけでなく、ノード項目が表示されることを確認してください。更新成功と表示されたのに一覧が空の場合は、レスポンスがクライアントで認識できる形式か、現在のグループフィルターが新しい項目を隠していないかを確認します。

サブスクリプション更新で上書きされる内容

サブスクリプションのノードはリモートの一覧から生成され、再更新すると同じノードのサーバー、ポート、プロトコル、トランスポートパラメータが置き換わる可能性があります。サブスクリプションノードを直接編集する方法は一時的な診断には使えますが、長期的な変更には向きません。カスタムノードを残したい場合は、独立した手動グループを作るか、ローカルノードとして複製し、わかりやすい名前を付けてください。ルーティングルール、システムプロキシモード、ローカル待ち受けポートは通常クライアント設定に属し、サブスクリプション更新でリモート値に自動変更されることはありません。ただし、グループやルール情報を含むサブスクリプションもあるため、詳細はインポート時のプレビューを確認してください。

適切な更新手順は、まず重要な接続を停止し、サブスクリプションを更新してから、追加・削除・名前の変化を確認し、1つのノードでテストすることです。更新後にDNS、ルーティング、プロキシモードを同時に変更しないでください。異常の原因を特定しにくくなります。古いノードが消えた場合は、まずサブスクリプションの一覧が変更されたか確認します。ノードが残っているのに接続できない場合は、プロトコルフィールドの変更とコアの対応状況を調べます。

ノード選択では単一のテスト結果に頼らない

クライアントが提供する疎通テスト、遅延テスト、実接続テストは、検査対象が完全に同じではありません。TCPポートに接続できるのは、指定ポートまでネットワークが到達できることを示すだけです。プロトコルのハンドシェイクに成功して初めて、主要パラメータの一致をさらに確認できます。対象サイトにアクセスできるかどうかは、DNS、ルーティング、サービスの状態にも左右されます。そのため、1つのテスト結果だけで完全なアクセス確認を代用することはできません。より確実なのは、ノードを選び、システムプロキシを有効にし、既知のHTTPSページへアクセスしながら、クライアントログに対応する接続記録が出るか確認する方法です。

ノード名は用途の識別に役立ちますが、プロトコルの事実として扱わないでください。ノード詳細でaddress、port、プロトコル種別、トランスポート方式、TLSの有効状態、serverName、関連する識別子を確認します。複数のプロトコル構成を含むサブスクリプションでは、現在のクライアントコアが明確に対応しているノードを優先してください。v2rayNGとv2flyNGで同じサブスクリプションの表示項目が異なる場合があります。これは通常、コアの対応範囲やサブスクリプション変換結果によるもので、URL自体が無効とは限りません。

共有リンクとJSONを手動で追加する

単一ノードの共有リンクは、一時的な追加や個別テストに適しています。追加前に、先頭部分がクライアント対応プロトコルか確認し、「クリップボードから追加」のような入口を使います。複数のリンクを一度にコピーする場合は、1行につき完全なリンクが1つだけになるようにしてください。JSON設定には、より詳細なインバウンド、アウトバウンド、ルーティング、DNS情報が含まれます。通常、GUIクライアントが自動生成する設定と直接混在させるべきではありません。クライアントに「カスタム設定」機能がある場合は独立した設定項目として実行し、自動ノード設定でフィールドが上書きされないようにします。

{
  "address": "server.example.com",
  "port": 443,
  "id": "11111111-2222-3333-4444-555555555555",
  "security": "auto",
  "network": "tcp",
  "tls": "tls",
  "serverName": "service.example.com"
}

上記のフィールドはノードパラメータ同士の関係を示すもので、実際に接続できるサービスを表すものではありません。実際の設定では、アドレス、ポート、ユーザー識別子、トランスポート方式、サーバー名をサーバー側と一致させる必要があります。ハンドシェイクエラーが出た場合は、暗号化やTLSの項目を適当に変更せず、1つずつ照合してください。共有リンクとサブスクリプションの違いを詳しく知りたい場合は、vmessリンクとサブスクリプションURLの違い →をご覧ください。

04

通信を取り込む

システムプロキシ、ローカルポート、アプリの範囲

システムプロキシが変えるのはアプリの接続入口

システムプロキシモードは、OSのプロキシアドレスをクライアントのローカル待ち受けポートへ向けます。システムプロキシを読み取るブラウザやデスクトップアプリは、そのポートへリクエストを渡し、コアがルーティングとアウトバウンド接続を処理します。ただし、すべてのパケットを自動的に書き換えるわけではなく、すべてのプログラムがシステム設定に従うとも限りません。一部のコマンドラインツール、ゲーム、仮想マシン、コンテナ、独自のネットワークスタックを使うプログラムは、システムプロキシを無視することがあります。「ブラウザは使えるのに別のプログラムは使えない」場合は、まず対象プログラムがHTTPまたはSOCKSプロキシに対応しているか確認し、いきなりノードを疑わないでください。

クライアントの画面には、「システムプロキシを解除」「システムプロキシを設定」「システムプロキシを変更しない」といった状態がよくあります。システムプロキシの設定は一般的なデスクトップアプリに適し、解除は終了時にシステムネットワークを元へ戻すために使います。「変更しない」はローカルポートだけを起動し、各アプリで手動入力する方式です。クライアントを終了する前に、通常の終了手順を使って以前の設定を復元してください。プロセスを強制終了すると、システムにローカルポートを指すプロキシアドレスが残り、クライアント終了後にウェブページへアクセスできなくなることがあります。その場合はクライアントを再起動してシステムプロキシを解除するか、システムのネットワーク設定から手動で戻します。

HTTP、SOCKS、混合ポートの違い

HTTPプロキシはブラウザやCONNECTに対応するアプリに適しています。SOCKSプロキシはより汎用的なTCPリクエストを扱え、アプリの実装によってはドメイン解決にも対応できます。一部のクライアントには、同じ待ち受けアドレスでHTTPとSOCKSを識別する混合ポートがあります。ポート番号そのものにプロトコルの機能があるわけではなく、そのポートに対応するインバウンドの種類が重要です。アプリを手動設定する場合は、選択したプロキシ種別とクライアントの待ち受け種別を一致させてください。SOCKSポートをHTTPプロキシ専用の入力欄に入れると、通常はすぐに接続に失敗します。

コマンドラインツールではプロキシ変数を明示的に確認する

Linux、macOS、Windowsのターミナルでは、多くのツールがデスクトップのプロキシ設定を自動的に読み取りません。現在のコマンドまたはターミナルセッションに対して、プロキシの環境変数を設定できます。以下の例では、クライアントのHTTPインバウンドがローカルの10809ポートで待ち受けているものとします。実際にはクライアント画面の表示値を使用してください。環境変数の名前は大文字・小文字やツールによって異なるため、設定後はツール自身の詳細出力で採用されたか確認します。

export http_proxy="http://127.0.0.1:10809"
export https_proxy="http://127.0.0.1:10809"

curl -I https://example.com

unset http_proxy
unset https_proxy

SOCKSインバウンドを使う場合、一部のツールは socks5h://127.0.0.1:10808 に対応しています。h付きの形式は通常、ドメイン解決もプロキシ側で行うことを示し、ローカルの解決結果とルーティングの想定が食い違うのを防ぐのに役立ちます。ただし、すべてのプログラムがこの記法を認識するわけではないため、各プログラムの引数を確認してください。クライアントが安定して起動することを確認するまでは、環境変数をグローバルな起動ファイルへ永続的に書き込まないでください。クライアント停止後も、変数を継承したすべてのターミナルプログラムが存在しないローカルサービスへ接続し続けることになります。

ローカルポートが実際に待ち受けているか確認する

アプリが「接続を拒否されました」と報告した場合は、まずリモートサーバーではなくローカルインバウンドを確認します。WindowsではPowerShellで待ち受け状態を確認でき、Linuxでは ss が使えます。ポートが待ち受けていない場合、コアが起動していない、設定生成に失敗した、他のプロセスがポートを使用している、セキュリティポリシーがバインドを阻止している、といった原因が考えられます。ポートが正常に待ち受けているのにアクセスログがない場合、アプリの通信がそのインバウンドに入っていません。インバウンドの記録があり、リモートのハンドシェイクエラーが出ている場合に初めて、ノードパラメータを調べます。

Get-NetTCPConnection -State Listen |
  Where-Object LocalPort -In 10808,10809

ss -lntp | grep -E '10808|10809'

複数のクライアントを同時に実行する場合、同じローカルポートを使わせたり、2つのクライアントに同時にシステムプロキシを書き込ませたりしないでください。テスト中の2つ目のクライアントには別のポートを割り当て、システムプロキシは検証対象の1つだけを指すようにします。比較が終わったら、使わなくなった待ち受け設定を削除し、ログイン時の自動起動でポートが競合しないようにします。プロキシモードの目的は、明確で観察可能な通信入口を作ることであり、すべてのスイッチを同時に有効にすることではありません。

05

出口を制御する

ルーティングルールと判定順序

ルーティングルールの本質はアウトバウンドの選択

ルーティングはノードのプロトコルを変更せず、どの通信をどのアウトバウンドへ送るかだけを決めます。代表的なアウトバウンドタグには proxy、direct、block があり、それぞれプロキシ接続、直接接続、ブロックを表します。ルールはドメイン、IP、ポート、ネットワーク種別、インバウンドタグなどで一致させられます。GUIにある「グローバル」「LANをバイパス」「ルールモード」などの名称は、複数のルーティング動作をまとめたものです。最終的な判定は、生成された設定のルール順序、条件、デフォルトのアウトバウンドによって決まります。

ルールを作るときは、まず対象が明確な狭い範囲のルールを書き、次に広い集合を処理し、最後にデフォルトの行き先を残します。たとえば、ローカルやLANのアドレスは通常、優先して直接接続します。明確にブロックしたいドメインは、一般的なプロキシルールより前に置きます。残りのリクエストはプロキシまたは直接接続へ送ります。適用範囲の広いルールを先頭に置くと、後続の細かなルールは実行されません。「ルールを書いたのに効かない」場合、最初に確認すべきなのは、より前のルールに一致していないかどうかです。

ドメインルールとIPルールは異なる段階で判定される

ドメインルールはリクエスト中のドメインで判定し、完全なドメイン、サブドメインのサフィックス、キーワード、geosite分類などを使えます。IPルールは対象IPで判定し、CIDRネットワークやgeoip分類を使えます。リクエストがドメイン情報とIP情報を同時に持つかどうかは、インバウンドのプロトコル、DNSポリシー、ドメイン解決の有無によって変わります。IPルールだけに頼る場合、コアが先にドメインを解決する必要があることがあります。解決経路が想定したアウトバウンドと一致しないと、ループや誤判定が起きる可能性があります。そのため、ドメインで安定して表現できるサービスにはドメインルールを優先し、ネットワーク範囲にはIPルールを使います。

domain: は通常、正確なドメインを表します。full: は完全一致を強調し、keyword: は指定した文字列を含むドメインに一致するため、範囲が広く慎重な使用が必要です。geosite: と geoip: は分類データの集合を参照し、大量のルール管理に適していますが、分類データはクライアントのリソースとともに更新する必要があります。カスタムルールには説明しやすい名前を付け、出典と必要性を外部ドキュメントに記録しておくと、数か月後でも判断できます。

最小ルーティング設定の構造

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:intranet.example.com"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:service.example.net"
        ],
        "outboundTag": "proxy"
      }
    ]
  }
}

domainStrategy は、ドメインルールだけで結果が出ない場合に、IPを解決するかどうか、またいつ解決するかを決めます。AsIs は元のドメインでの判定を優先し、IPルールのために積極的な解決を行いません。IPIfNonMatch はドメインルールに一致しなかった場合にIPを解決し、その後でIP条件を確認します。コアによっては、さらに積極的な解決方式も用意されています。選択時はDNS設定とルールの目的を考慮し、「より多く解決すれば必ず正確になる」と考えないでください。ドメインルールが十分に整っている場合は、シンプルな方式を優先します。対象ネットワークで振り分ける必要がある場合にだけ、追加の解決を導入します。

シンプルなルールから段階的に拡張する

初めてルーティングを設定する場合は、プライベートネットワークの直接接続、明確なドメインルール、その他の通信をデフォルトのアウトバウンドへ送る3層だけにするのがおすすめです。安定動作を確認してから、広告ブロック、特定プロセス、ポート、プロトコルのルールを追加します。出典不明のルールを一度に大量追加すると、原因の特定が難しくなります。また、ソフトウェア更新、LAN機器の検出、DNSリクエストが誤ったアウトバウンドへ送られることもあります。ルールを追加するたびに、直接接続すべき対象とプロキシすべき対象を少なくとも1つずつ確認し、ログで最終アウトバウンドタグを確認してください。

ポートルールは対象ポートが明確なプロトコルに適していますが、現在のサービスは443ポートを共有することが多く、ポートだけではサイトを区別できません。プロセスルールはプラットフォームと取り込み方式に依存し、システムプロキシモードでは完全なプロセス情報を取得できないことがあります。TUN環境の対応状況もクライアントの実装に左右されます。あるプラットフォームで使えるプロセスルールを、すべてのデバイスへそのままコピーしないでください。複数のプラットフォームで同期する場合は、まずドメインとIPルールを同期し、プロセス条件は各プラットフォームで個別に管理します。

ルーティングのトラブルシューティングでは最終一致結果を見る

特定のウェブサイトが誤った出口を通る場合は、まずリクエストのドメインを記録し、ログから対応する接続のoutboundタグを探します。ログにIPしか表示されない場合は、DNSとスニッフィング設定でドメインが保持されているか確認します。その後、ルール一覧の先頭から、対象ドメインまたはIPが早い段階で一致する可能性を1つずつ確認します。対象ドメインを一時的に最初の明確なルールへ追加すると、優先順位が原因か検証できます。検証後は適切な位置へ移動し、先頭の例外に依存し続けないでください。

中国本土のネットワーク環境で、中国国内は直接接続し国外向け通信をプロキシする考え方については、ルーティング実践ガイド →も参照してください。設定前に、ルールデータとクライアントリソースが利用可能な状態か確認します。ルーティングは決定的なマッチング処理です。対象、ヒットしたルール、アウトバウンドタグの3つを記録すれば、ノードを何度も切り替えて運任せにすることなく、段階的に原因を特定できます。

06

より多くのアプリをカバーする

TUNモード、DNS、ルーティングテーブルの連携

TUNはシステムプロキシでカバーできない通信に対応する

TUNモードは仮想ネットワークインターフェースでシステム通信を受け取り、コアにルーティングと転送を行わせます。システムプロキシを読み取らないアプリ、一部のコマンドラインプログラム、デスクトップ環境の通信を一括して取り込みたい場合に適しています。システムプロキシよりネットワーク層に近いため、設定範囲も広くなります。仮想インターフェースのアドレス、システムルート、DNSの取り込み、MTU、バイパスするアドレス、権限などが結果に影響します。初めてTUNを使う前に、同じノードが通常のシステムプロキシモードで接続できることを確認し、ノードの問題とTUN環境の問題を切り分けてください。

有効化時には通常、仮想インターフェースの作成とルートの書き込みにシステムネットワーク管理権限が必要です。クライアントを正常に終了したら、これらの一時設定も削除されるはずです。プロセスが異常終了すると、古いインターフェースやルートが残ることがあります。「クライアントを閉じてもネットワークが不安定」な場合は、まずクライアントを再起動してTUNを正常に停止し、その後システムのネットワークインターフェースとデフォルトルートを確認します。仮想NICやルーティングテーブルを変更するネットワークツールを複数同時に動かすと、同じ宛先ネットワークが異なるルールで繰り返し上書きされるため避けてください。

DNSはルーティングが参照できる情報を決める

アプリがドメインへアクセスするには、まず名前解決の結果が必要です。DNSリクエストがクライアントを迂回すると、コアには後続接続のIPしか見えない場合があります。DNSリクエストがTUNに取り込まれると、ドメインルールに応じてDNSサーバーとアウトバウンドを選べます。目的はすべての問い合わせを同じ経路へ送ることではなく、解決結果、ルーティング判定、実際の接続を一致させることです。たとえば直接接続する内部ドメインは、その内部ゾーンを解決できるDNSで処理する必要があります。ドメインでプロキシするリクエストでは、コアがルール判定用の元のドメインを取得できるようにします。

よくある異常には、名前解決は成功するが到達不能なアドレスが返る、DNSリクエストがローカルインバウンドへ戻ってループする、アプリが古い結果をキャッシュしている、IPv6の結果が優先されるが現在の経路が対応していない、ブラウザ独自のDNS設定がシステム設定を迂回する、といったものがあります。調査ではまず、アプリとシステムのDNSキャッシュを削除し、クライアントログに問い合わせ記録があるか確認します。対象IPへ直接アクセスできるのにドメインで失敗するならDNSを重点的に調べます。ドメインが解決済みでハンドシェイク時に失敗するなら、ノードとトランスポートパラメータへ戻ります。

Fake DNSと実DNSの使い分け

一部のTUN設定ではFake DNSを使います。コアがまずアプリへ予約アドレスを返し、マッピングを通じて元のドメインを復元してからルーティングします。これによりドメイン情報を保持しやすくなり、アプリがドメインルールを迂回するケースも減らせます。ただし、対象通信が常に同じコアのマッピングを通過する必要があります。アプリが予約アドレスをキャッシュしたままクライアント停止後もアクセスすると、接続に失敗します。LANサービス、実IPを必要とするプログラム、一部のP2P用途は通常除外範囲に入れるべきで、すべてをFake DNSに任せるのは適切ではありません。

有効にするかどうかは実際の用途で決めます。通常のブラウザやシステムプロキシ対応アプリが安定して動作しているなら、「設定を完全にする」ためだけに有効化する必要はありません。システムプロキシに従わない特定プログラムをカバーする必要がある場合は、まず実DNSを使うTUN設定でルーティングとMTUが正常か確認し、その後Fake DNSの導入を検討します。処理層を追加するたびに、無効化した状態との比較結果を残してください。

MTU、IPv6、LANバイパス

MTUは仮想インターフェースが1つのパケットで運べるデータ量を決めます。大きすぎるとネットワーク経路によってはフラグメント化やパケット損失が起き、小さなページは開けるのに大きなレスポンスが止まることがあります。小さすぎるとオーバーヘッドが増えます。明確な症状がない場合はクライアントのデフォルト値を使ってください。特定のネットワークでTLSハンドシェイクが止まる、またはアップロードに失敗する場合は、MTUを少しずつ下げて比較します。変更ごとにTUNインターフェースを作り直し、結果を記録してください。複数のネットワークパラメータを連続して変更しないことが重要です。

IPv6は、システム、DNS、ノード、アウトバウンド経路の4層で確認します。システムがIPv6アドレスを取得していても、プロキシのアウトバウンドが対応しているとは限りません。DNSがAAAAレコードを返すと、アプリがIPv6を優先することがあります。現在の設定に完全なIPv6ルーティングがない場合は、クライアントが提供する方針を明確に使い、システムとクライアントで片方だけ有効・片方だけ遮断する状態を作らないでください。LANのネットワーク帯域は通常直接バイパスし、プリンター、ルーター管理画面、ファイル共有、ローカル開発サービスがリモートのアウトバウンドへ送られないようにします。

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "port": "53",
        "network": "udp",
        "outboundTag": "dns-out"
      }
    ]
  }
}

この例はルールの関係を示すもので、プライベートアドレスを優先して直接接続し、条件に合うDNS通信を専用アウトバウンドへ渡します。実際の設定では、dns-out という名前のアウトバウンドも定義しなければ、ルールの参照に失敗します。GUIクライアントがこれらの構造を自動生成することもあるため、生成ロジックを理解しないまま設定全体を上書きしないでください。カスタマイズする場合は、まず現在の実行設定をエクスポートし、インバウンドとアウトバウンドのタグを確認してから最小限のルールを追加します。

4ステップでTUNを有効にする

第1段階ではシステムプロキシモードでノードとサブスクリプションを確認します。第2段階では、ネットワークルートを書き込む他のプログラムを停止します。第3段階でTUNを有効にしますが、DNSとMTUはデフォルトのままにし、ブラウザ、コマンドラインツール、LANアドレスをテストします。第4段階で、ログを見ながらDNSの振り分けやバイパスルールを追加します。どこかで失敗したら前の段階へ戻って確認し、Fake DNSの有効化、MTU変更、IPv6切り替え、大規模なルーティングの追加を同時に行わないでください。安定したTUN設定は、スイッチの数ではなく層ごとの検証から生まれます。

07

使える状態を保つ

日常のメンテナンス、ログの読み方、トラブルシューティング

更新対象をクライアント、コア、サブスクリプション、ルールデータに分ける

日常のメンテナンスは、何度も再インストールすることではありません。少なくとも4種類の対象を確認します。GUIクライアントは画面と設定生成を担当し、コアはプロトコルを実行し、サブスクリプションはノードパラメータを提供し、ルールデータはgeositeとgeoipの分類を提供します。それぞれ更新のタイミングが異なり、クライアントが個別に管理する場合もあります。問題が起きたら、最近変更された層を記録してください。クライアント更新後の画面動作の異常と、サブスクリプション更新後に単一ノードが使えなくなる問題は別物です。ルールデータが古い場合は、すべてのノードが起動しないというより、分類の一致がずれる形で現れることが多いです。

更新前に、サブスクリプション名、カスタムルーティング、ローカルポート、重要な画面のスクリーンショットを保存します。更新後は、まず既存ノードとシンプルなシステムプロキシで確認し、その後TUNや複雑なルールを戻します。クライアント更新、サブスクリプション更新、ルーティングの大幅変更を同じ操作で行わないでください。戻す必要がある場合は、直近に変更した項目を1つだけ戻し、設定フォルダーに互換性があるか確認します。自動起動を使っている場合は、更新後に起動パスが変わっていないか、システムトレイに古いプロセスが残っていないかも確認してください。

ログは時系列と接続段階に沿って読む

有効なログには通常、設定読み込み、インバウンドの待ち受け、DNS問い合わせ、ルーティング結果、アウトバウンドのダイヤル、プロトコルハンドシェイクなどの段階が含まれます。調査時は古いログを消去するか現在時刻を記録し、対象操作を1回だけ実行してください。大量の過去ログは本当のエラーを隠します。connection refused が出たら、拒否元がローカルポートかリモートアドレスかを区別します。タイムアウトの場合は、DNS、TCP接続、プロトコルハンドシェイクのどの段階で起きたかを判断します。設定フィールドのエラーなら、コアはまだネットワーク接続段階に入っていません。

詳細な情報が必要な場合は、一時的にログレベルを上げられます。ただし長期間高いレベルにすると大量のファイルが生成され、アクセス先のドメインなどの実行情報が記録される可能性があります。調査後は通常のレベルに戻してください。ログを共有する前に、サブスクリプションURL、サーバーアドレス、ユーザー識別子、認証フィールド、ローカルパスを削除し、エラーの種類、発生段階、必要な文脈だけを残します。最後の1行だけを切り取らないでください。本当の原因は、その前の設定読み込みやDNS記録にある可能性があります。

症状に応じて調査分岐を選ぶ

システム時刻、ポート競合、権限は頻出する基本問題

TLSやREALITYなどのハンドシェイクは、正確なシステム時刻に依存します。デバイスの時刻が大きくずれていると、証明書の有効期間やハンドシェイクに関するエラーが発生することがあります。システム時刻の同期を有効にし、タイムゾーンが正しいことを確認してください。ポート競合は、古いクライアント、テスト版、別のローカルプロキシを同時に実行している場合によく起こります。システムコマンドで待ち受けプロセスを確認するほうが、ランダムなポートへ何度も変更するより直接的です。ポートを変更する場合は、システムプロキシ、アプリの手動プロキシ、環境変数もすべて更新します。

権限の問題は、TUN、システムプロキシへの書き込み、設定フォルダー、ログフォルダーで主に発生します。通常のシステムプロキシに高い権限で常時実行する必要はありません。TUNで仮想インターフェースを作る場合は、システムの許可が必要になることがあります。権限を上げたときだけ起動できる場合は、具体的に失敗したファイルやネットワーク操作を確認し、高権限での常時実行を標準的な解決策にしないでください。設定フォルダーが書き込み不可の場所にあると、クライアントは開けてもサブスクリプションやルールを保存できず、終了後に変更がすべて失われることがあります。

ネットワークを復旧する際は、まず取り込みを解除し、その後ノードを確認する

クライアントの異常後にシステム全体でネットワークへ接続できなくなった場合、最初の目標はローカルネットワーク設定の復旧です。まずTUNを停止し、システムプロキシを解除し、システムDNSとデフォルトルートが戻ったことを確認してから、クライアントを経由しない通常接続をテストします。基本ネットワークが復旧してからクライアントを再起動し、ノードを確認してください。最初からノードを次々に切り替えると、誤ったシステムプロキシや仮想ルートが残り、すべてのノードが無効に見えることがあります。

モバイル端末で通信が途切れた場合は、まずWi-Fiからモバイル通信へ切り替わっていないか、クライアントがバックグラウンドで制限されていないか、システムのネットワーク取り込み表示が残っているかを確認します。デスクトップでスリープ復帰後に接続できない場合は、いったん接続を停止してコアを再起動し、古いソケットとDNS状態を再構築します。頻繁に起きる場合は、ログイン時の自動起動、スリープ設定、ネットワークインターフェースの変化を記録したログを確認します。

毎月のメンテナンス項目を作る

安定して使えているなら、軽いメンテナンスを月1回行えば十分です。サブスクリプションを更新し、明らかに無効なローカルコピーを削除する。クライアントとコアに互換性のある更新があるか確認する。ルールデータが正常に読み込めるか確認する。大きくなりすぎたログファイルを整理する。ログイン時の自動起動と、システムプロキシ解除時の復旧を確認する。直接接続対象とプロキシ対象を1つずつ選び、ルーティングを検証する。変更記録には日付、変更項目、戻し方を記載してください。障害時に環境全体をリセットせず、最近の変更から確認できます。

デバイスを変更する場合は、クライアントがエクスポートを許可しているローカル設定を保存し、サブスクリプションの入口とカスタムルールも別途記録します。新しいデバイスでは、まず対応するプラットフォームのクライアントをインストールし、次にサブスクリプションを復元し、最後にルーティングとTUNを移行します。異なるOSのパス、プロセスルール、ネットワークインターフェース名をそのままコピーしないでください。すぐに設定したい場合は使い方ガイド →へ戻り、クライアントの違いは選び方ガイド →で確認できます。

08

基盤を理解する

上級設定への道筋と設定ファイルの構造

GUIの項目を基盤設定へ対応付ける

上級設定へ進むとき、すぐにGUIクライアントを手放す必要はありません。まずクライアントが生成した実行設定をエクスポートまたは表示し、画面上のローカルポート、現在のノード、ルーティングモード、DNS項目をJSONフィールドに対応付ける方法が効果的です。システムプロキシはOSの設定であり、コア設定に直接現れるとは限りません。ローカルのSOCKSまたはHTTPポートは inbounds、ノードと直接接続の出口は outbounds、振り分けは routing、ドメイン解決は dns にあります。この対応関係を理解して初めて、GUIのスイッチが設定ファイルを変更しているのか、システム環境を変更しているのかを判断できます。

クライアントは通常、起動するたびに実行設定を再生成するため、一時ファイルを直接編集しても次回起動時に消えることがあります。カスタムJSONを長期利用する場合は、クライアントが提供するカスタム設定の入口を使うか、対応するテンプレートやルーティングエディターへ変更を書き込みます。変更前に元の設定をコピーし、JSONパーサーで構文を確認してください。JSONではコメント、末尾のカンマ、エスケープされていない特殊文字は使えません。これは「設定は正しそうなのにコアが起動しない」直接の原因になります。

最小設定に必要な要素

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "server.example.com",
            "port": 443,
            "users": [
              {
                "id": "11111111-2222-3333-4444-555555555555",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "service.example.com"
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

この例は構造の関係を示すもので、接続可能なサービスは含みません。インバウンドは 127.0.0.1 だけで待ち受けるため、ローカルからのリクエストのみ受け付けます。すべてのインターフェースで待ち受ける設定に変更するとアクセス範囲が広がるため、ファイアウォールと認証も同時に検討する必要があります。プロキシアウトバウンドには例示用のVLESSパラメータを使っています。実際にはaddress、port、id、トランスポート、TLSのフィールドを置き換えてください。directとblockのアウトバウンドはルーティング先を提供します。ルールはまずプライベートアドレスをdirectへ送り、一致しない通信はコアのデフォルト動作に従って次のアウトバウンドを選びます。

インバウンドタグとアウトバウンドタグは設定をつなぐ接点

tag は暗号化や通信を担当するものではなく、設定内部で参照する名前です。ルーティングは outboundTag でアウトバウンドを選び、inboundTag で特定のインバウンドだけにルールを適用することもできます。タグの綴りは完全に一致させる必要があり、名前を変更する場合はすべての参照も更新します。設定が複雑になったら、socks-in、tun-in、proxy、direct、block のように用途を表す名前を使い、数字だけの番号は避けるのがおすすめです。

複数のインバウンドに異なるルーティング方針を設定できます。たとえば、ローカルブラウザのSOCKSインバウンドには通常のルールを使い、TUNインバウンドではDNSを追加処理します。複数のアウトバウンドは、異なるノードや接続方式を表せます。この場合は balancers やより複雑なルーティング構造で整理できますが、明確な目的がない限り追加しないでください。ノードの切り替えをGUIクライアントが十分に管理できるなら、複数のアウトバウンドを手書きするとサブスクリプション更新との同期がかえって難しくなります。

まず設定の検証を覚え、それから機能を広げる

設定の検証は3層に分かれます。第1層はJSON構文で、括弧、配列、文字列、カンマが正しいことを確認します。第2層はコア設定の検査で、フィールド名、プロトコル構造、タグ参照が有効か確認します。第3層は実行検証で、ポートの待ち受け、ルーティングの一致、ハンドシェイクの成功を確認します。構文が通ってもプロトコルパラメータが正しいとは限らず、プロセスが起動してもアプリがそのインバウンドを使っているとは限りません。アウトバウンドやルールを1つ追加するたびに、3層すべてを再検証してください。

複雑な設定は、テスト可能な小さな段階に分けるのが適しています。まずSOCKSインバウンド1つとプロキシアウトバウンド1つを残し、プロキシを手動指定したブラウザでアクセスできることを確認します。次にdirectと基本ルーティングを追加し、その後DNSを追加します。TUNを追加するのは最後です。クライアントで最終実行設定を表示できる場合は、最終ファイルを基準にしてください。GUIテンプレートがmux、ログ、ポリシー、DNSのフィールドを自動追加することがあるためです。さらに詳しく読むには設定ファイル構造の詳しい解説 →を参照してください。

プロトコルの選択はサーバーパラメータと互換性を優先する

VMessとVLESSはいずれもエコシステムでよく使われるプロトコルです。VMessは独自の認証とデータ処理の仕組みを持ち、VLESSはよりシンプルな構造で、TLSやREALITYなどのセキュリティ層と組み合わせて使われることが多いです。クライアント側だけでプロトコルを決めることはできません。サーバーが提供するパラメータに合わせて、ローカルも一致する設定を使う必要があります。性能差も、ネットワーク品質、トランスポート方式、暗号化層、デバイス性能から切り離して判断できません。一般ユーザーはまず、コアの対応、パラメータの一致、接続の安定性を確保し、その後で細かな通信オーバーヘッドを検討してください。

サブスクリプションに複数のプロトコルがある場合は、同じネットワーク環境で接続確立、長時間接続の安定性、モバイル通信切り替え後の復旧をそれぞれテストします。ポート探査を1回比較するだけでは不十分です。プロトコルの概念についてはVMessとVLESSの違い →を参照してください。OpenWrtのメインルーターや旁路ルーターへの展開では、まずデバイスが担うインバウンド、透過的な取り込み、DNS、ルーティングの役割を理解し、その後OpenWrt展開の要点 →を確認します。

自分なりの上級設定の順序を作る

その後の学習は4段階に分けるのがおすすめです。第1段階では、アプリ、システムプロキシ、ローカルインバウンド、リモートアウトバウンドの経路を説明できるようにします。第2段階では、プライベートネットワークの直接接続、指定ドメインのプロキシ、ブロックルールを書き、ログで一致を確認できるようにします。第3段階では、TUN、DNS、MTU、LANバイパスを自分で扱えるようにします。第4段階で初めて、複数インバウンド、複数アウトバウンド、プロセス別振り分け、ルーターの透過的な取り込みへ進みます。各段階で、最小限の実用設定を復旧用の基準として保存してください。

本当の「初心者から上級者まで」とは、すべての項目を有効にすることではありません。1つのリクエストがどの層で止まったかを判断できることです。アプリがローカルポートへ送ったか、DNSが想定どおり結果を返したか、ルーティングがどのアウトバウンドに一致したか、コアがリモートのハンドシェイクを完了したかを確認します。この4点を把握すれば、クライアント画面、JSON設定、システムネットワーク設定を同じモデルで理解できます。インストーラーを選び直す場合はクライアントのダウンロードページ →へ、最短手順で再設定する場合はクイックスタートガイド →へ戻ってください。