V2Ray設定ガイド

基本概念と接続経路

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

V2Rayは、プロキシ技術のエコシステムで広く使われる名称であり、特定のインストールパッケージを指すものではありません。v2rayN、v2rayNG、v2flyNGはGUIクライアントで、ノードの保存、サブスクリプションの管理、動作モードの選択、設定の生成を担います。実際に通信を処理するのはコアです。サーバーは遠隔地にあり、対応するプロトコルのリクエストを受け取ります。クライアントをインストールしただけでは、接続先サーバーや利用可能なサブスクリプションは自動で用意されません。

Project Vは関連技術の基礎情報を提供し、V2FlyはV2Rayのコアエコシステムを引き継いでいます。Xrayは関連する別のコア実装です。コアによって対応するプロトコル、転送方式、設定値は異なるため、ノード名だけで互換性を判断することはできません。ノードにプロトコル名が記載されていても、転送方式やセキュリティ層、追加パラメーターの確認が必要です。GUIで項目を保存できても、選択中のコアがその組み合わせに対応しているとは限りません。

アクセスを4つの段階に分けて考える

接続の流れは「アプリ、本地の入口、ルーティングの判断、リモートへの接続」の順に追えます。まずブラウザーがリクエストをプロキシに渡すかどうかを決めます。クライアントはローカルの待ち受けポートや仮想ネットワークインターフェースを通じて通信を受け取ります。次にルーティングルールが、直接接続、プロキシ、遮断のいずれに送るかを決め、最後にプロキシ経由でリモートのサービスへ接続します。どこか1段階でもつながっていないと、ウェブページが開かないという症状になりますが、対処方法は原因によって異なります。

たとえば、ブラウザーではアクセスできるのに別のアプリで接続できない場合、まずそのアプリがシステムプロキシに従うかを確認します。すぐにノードを切り替える必要はありません。クライアントのログに該当するリクエストがまったく記録されていなければ、通信がまだローカルの入口に届いていない可能性があります。リクエストは記録されているものの、リモートとのハンドシェイクに失敗している場合は、サーバーアドレス、ポート、セキュリティ設定を確認します。接続できてもドメイン名の名前解決でエラーになる場合は、DNSを個別に調べましょう。すべてを回線品質の問題として扱うべきではありません。

プロトコル、転送方式、セキュリティ層を区別する

VMessやVLESSなどはプロキシプロトコル、TCPやWebSocketなどは通信の転送方式、TLSやREALITYはセキュアな通信に関わる仕組みです。それぞれ異なる階層の要素で、相互に置き換えられるものではありません。インポート時は一連の設定値を正しくそろえる必要があります。プロトコルが合っていても、パス、サーバー名、公開鍵などが誤っていれば接続できません。REALITYの公開鍵やショートIDはサブスクリプションのパスワードではありません。他のノードの値を流用したり、クライアントの表示だけを頼りに推測したりしないでください。

ノードのアドレスにはドメイン名とIPアドレスがあります。接続先アドレスと、セキュリティハンドシェイクで使うサーバー名は異なる場合があります。ポートはリモートサーバーの待ち受け位置を示し、ローカルポートは端末上のクライアントの入口を示します。両者は別のものです。ガイドに記載されたループバックアドレスは、その端末自身を指します。別の端末に入力しても、元のクライアントには接続されません。LAN内で共有する場合は、待ち受け範囲、ファイアウォール、アクセス制御も別途設定する必要があります。

このガイドでは各段階に確認ポイントを設けています。インストールではコアが起動するか、サブスクリプションではノード情報がそろっているか、プロキシではリクエストがログに記録されるか、ルーティングでは想定した出力先に送られているかを確認します。複数のスイッチを続けて切り替えるより、この順番で結果を記録するほうが問題を特定しやすくなります。用語がわからない場合は用語集を確認してから、該当する手順に戻って設定してください。

プラットフォームとコアに合わせてクライアントを選ぶ

デスクトップではv2rayNを優先

Windows、macOS、Linuxのデスクトップ環境では、まずv2rayNを検討してください。最初にOSを確認し、次にプロセッサーのアーキテクチャ、最後にインストールパッケージの形式を選びます。アーキテクチャはプログラムが端末で動作するかを決め、パッケージ形式はインストール方法を決めます。これは別々の条件です。ダウンロードページにはプラットフォームごとの項目が掲載されています。端末の外見や購入時期から推測せず、システム情報を確認して選んでください。圧縮ファイル名に含まれるプラットフォーム名を、どの環境にも使える共通の目印と考えないようにしましょう。

Windows版にはDesktopとWPFの2種類があります。Desktopは新世代のクロスプラットフォームUIを採用し、WPFは従来型のWindows UIを維持しています。設定画面の場所、実行環境、機能の表示には違いがありますが、ノードの設定値はサーバーと一致させる必要があります。初回インストールではダウンロードページの説明をもとにどちらか一方を選び、接続を確認してください。2種類を同時に起動すると、ポートの競合やシステムプロキシ設定の上書きが起きることがあります。

Androidではまず必要なプロトコル、次にパッケージのアーキテクチャを確認

Androidではv2rayNGを第一候補とします。Xrayコアを使用しており、V2Fly系を使う場合はv2flyNGも選択肢になります。名前が似ているだけで、2つのクライアントの機能が完全に同じとは限りません。特定のセキュリティ通信パラメーターが必要なノードは、クライアントとコアが対応しているかを事前に確認してください。利用可能なサブスクリプションがある場合は、ノード名の略称から推測するより、提供元のプロトコル説明を確認するほうが確実です。必須項目が不足している場合は提供元に問い合わせ、手動で設定を組み立てないでください。

ダウンロードページではarm64版と汎用版を提供しています。比較的新しい一般的な端末ではarm64が使われますが、旧型端末、特殊な端末、エミュレーター環境では実際のアーキテクチャを確認してください。汎用版はアーキテクチャが不明な場合や複数の端末に対応させる場合に便利ですが、ファイルサイズは大きくなる傾向があります。インストールできないと表示されたら、ボタンを何度も押さず、OSとの互換性、端末に合ったパッケージかどうか、インストール済みアプリとの署名や入手元の競合を確認しましょう。

パラメーターの互換性を確認してからコアを選ぶ

コアの切り替えは、どんな場合でも使える高速化ボタンではありません。ノードが接続できない原因は、パラメーターの不足、サブスクリプションの解析漏れ、ネットワークへの到達不能などの可能性があり、コアを変えても解決しないことがあります。切り替える場合は、ノードのプロトコル、転送方式、セキュリティ層、エラー内容を記録し、新しいコアの対応範囲を確認してください。ノードごとにコアを選べるクライアントもあれば、コアが固定されているものもあります。実際の設定を確認し、他のプラットフォームのメニュー手順を流用しないでください。

macOSでは「このMacについて」でチップの種類を確認し、Apple SiliconまたはIntel向けの項目を選びます。Linuxではディストリビューションのパッケージ形式とアーキテクチャの両方を確認してください。debとrpmは、同じファイルの別名ではありません。デスクトップ環境、権限管理、システムプロキシの実装も使い方に影響します。ダウンロードが完了しただけでは、デスクトップアプリが自動でプロキシに従うとは限りません。後のモード確認で引き続き検証してください。

クライアントを選んだら、まず1つをメインにして使い方を覚え、データの保存場所、現在の動作モード、終了時の挙動を記録しておくと便利です。移行が必要な場合は、元の設定をバックアップしてから、サブスクリプション、ルーティング、DNSを個別に確認してください。ノードだけをコピーして、すべての設定が移行できたと思い込まないようにしましょう。詳しい違いはクライアント比較をご覧ください。インストール先はダウンロードページにまとめています。このページではインストールパッケージを直接提供していません。

インストールと初回起動の確認

デスクトップ版は保存先と権限を確認してインストール

Windowsではインストーラーの案内に従ってインストールします。展開形式の場合は、先に固定のフォルダーへすべてのファイルを展開してからメインプログラムを起動してください。圧縮ファイルのプレビュー画面から直接実行したり、実行ファイルだけを取り出したりしないでください。コアや関連リソースが圧縮ファイル内に残る場合があります。管理しやすく、現在のユーザーが書き込みできる場所を選び、頻繁に書き込む設定ファイルを厳しく保護された場所に置かないようにしましょう。権限の確認が表示されたら、どの処理に対するものかを先に判断してください。

初回起動時に実行環境が不足していると表示されたら、GUIの依存関係とコアの起動失敗を区別します。WPF版とDesktop版では必要な環境が異なる場合があるため、現在のリリース情報とシステムの案内を確認してください。不明なポップアップから修復ツールをインストールしたり、起動失敗をすべてランタイム不足と決めつけたりしないでください。画面は開くのにコアが終了する場合は、ログで原因を確認します。よくある原因には、ファイルの不足、設定の解析エラー、ポートの競合、システムによる制限があります。

macOSとLinuxのインストール上の注意

macOSではチップに合ったディスクイメージを選び、画面の案内に従ってアプリケーションフォルダーへ移動してから、その場所から起動してください。システムのセキュリティ確認には、システム設定内の正規の手順を使い、クライアントを起動するためだけにセキュリティ保護を全体的に無効にしないでください。アプリを開けないと表示された場合は、端末に対応したファイルか、インストールが正しく完了したか、システムが示す原因を確認してから次の対応を決めます。すべての確認を回避するターミナルコマンドを安易に使わないでください。

Linuxではディストリビューションに合ったdebまたはrpmを選び、システムのパッケージ管理ツールで依存関係を処理してください。依存関係の競合が報告されたら、別のディストリビューションからライブラリファイルをコピーせず、まずパッケージの状態を解決します。通常のプロキシモードでは、GUIクライアントを常に高い権限で実行する必要はありません。仮想インターフェースやルーティングの変更を行う場合に限り、追加の許可が必要になることがあります。許可の範囲や方法はパッケージによって異なるため、現在のクライアントの案内に従ってください。

Androidのインストールと初回の権限設定

Androidではインストール前にパッケージのアーキテクチャを確認します。システムで現在の入手元からのインストールが許可されていない場合は、実際に使う入手元だけを許可してください。同じ名前のアプリを上書きできない場合は、署名の違いやダウングレード制限が原因かもしれません。アンインストールするとアプリのデータが削除されるため、先に設定をエクスポートできるか確認しましょう。初めて接続を有効にすると、システムからVPN接続の許可を求められます。これはクライアントが通信を取り込むための権限であり、リモートとのハンドシェイク完了やノードの利用可能性を示すものではありません。

端末上でVPNインターフェースを使う別のアプリが動作している場合は、通常、先にその接続を停止してから現在のクライアントを起動します。バッテリー管理によってバックグラウンドでの動作が中断されることはありますが、初回インストール時にすべての権限を一度に許可する必要はありません。まず前面で接続をテストし、実際に切断が起きた場合にバックグラウンド動作やバッテリー制限を調整してください。システム通知、VPNアイコン、クライアントの状態はプロセスの動作確認に役立ちます。最終的にはリクエストのテストとログも確認してください。

インストール後は、画面が正常に開くこと、コアが起動していること、ローカルの待ち受けアドレスとポートを順番に確認します。次に、同じ入口を別のクライアントが使っていないか調べましょう。ノードがなくてもローカルの状態は確認できます。ポートを変更する場合は、アプリの手動プロキシ設定も合わせて変更してください。変更しないとアプリは古いポートに接続し続けます。ポート番号は現在のクライアント画面で確認し、他のガイドにある番号を固定値として扱わないでください。

最後に終了時の挙動を確認します。ウィンドウを閉じてもタスクトレイに残るデスクトップクライアントでは、トレイメニューから終了する必要があります。終了時にシステムプロキシを解除する設定がある場合もあります。初回設定の際は、一度終了して再起動し、プロキシが正常に戻ることを確認してください。Windows版のインストールについて詳しくはWPF版とDesktop版のインストールガイドをご覧ください。インストールが安定するまでは、ルーティングやTUN設定を追加しないでください。

サブスクリプションの追加・更新と設定確認

サブスクリプションURLと単一ノードのリンクを区別する

サブスクリプションURLは複数のノードを取得するためのものです。通常はサブスクリプショングループに登録してから更新します。単一ノードのリンクは個別の接続情報を表し、クリップボードやQRコードからインポートできます。2種類では使用する画面が異なります。サブスクリプションURLを単一ノードの設定欄に貼り付けたり、ノードリンクをサブスクリプションとして扱ったりすると、一覧が空になったり解析に失敗したりすることがあります。追加する前に提供元の説明を読み、形式と現在のクライアントへの対応状況を確認してください。

v2rayNではサブスクリプショングループの管理画面からグループを追加し、見分けやすい名前とサブスクリプションURLを入力して保存した後、更新します。v2rayNGとv2flyNGでは、サイドバーのサブスクリプショングループ設定から管理画面を開けます。画面の名称は多少異なっても、グループ作成、URLの保存、内容の取得、ノードの確認という手順は同じです。URLを保存しただけで更新していない場合、一覧が空でもサブスクリプションの無効を意味しません。すぐにクライアントをアンインストールする必要もありません。

更新エラーは取得と解析に分けて確認する

更新エラーは主に「URLにアクセスできない」と「取得した内容を解析できない」の2種類に分かれます。前者では端末のネットワーク、サブスクリプションの有効期限、URLの完全性、リクエストに既存のプロキシが必要かを確認します。後者では、取得内容がログイン画面、ウェブページの案内、非対応形式ではないかを調べます。クライアントにプロキシ経由で更新する設定があっても、既存のプロキシが使える場合にのみ適しています。利用できるノードがない段階で有効にすると、接続がないため更新できず、更新できないため接続できないという循環に陥ることがあります。

サブスクリプションの更新後は、プロトコル、サーバーアドレス、リモートポート、セキュリティ通信の設定を確認してください。ノード名だけを判断材料にしないでください。同じ地域のノードでも転送方式が異なる場合があります。名前が似ていても互換性があるとは限りません。インポート後に設定項目が明らかに欠けている場合は、まず形式とクライアントの互換性を確認してください。他のノードのサーバー名、パス、公開鍵をコピーして試すのは避けましょう。設定値は組み合わせて対応させる必要があります。

手動ノードとサブスクリプションのノードを分けて管理する

サブスクリプションのノードは次回の更新時に再生成されることが多く、直接変更すると上書きされる場合があります。設定項目を検証する場合は、まず独立した手動グループにコピーし、テスト用コピーだと分かるメモを付けてください。テスト後も元のサブスクリプションを基準として残し、複数のコピーが混在しないようにします。グループを削除する前に、ノードも同時に削除されるか、他の設定がそのグループや選択中の項目を参照していないか確認してください。

ノード選びでは、クライアントの接続テストで目安をつけてから、実際に使うアプリでも確認します。テストによって確認対象はポートへの到達、ハンドシェイク、単一リクエストなど異なり、すべての利用状況を示すわけではありません。結果が空、テストがタイムアウト、ノードがまったく使えないという状態は同じではありません。通信量、利用状況、地域の選択はサブスクリプション提供元の説明と合わせて確認してください。クライアントはサーバー側の権限を補ったり、停止されたサービスを復旧したりするものではありません。

ノード一覧が突然空になった場合は、まず選択中のグループと絞り込み条件を確認し、次に更新履歴を見ます。別のグループに切り替わっただけの場合もあれば、提供元から一時的に空の内容が返されていることもあります。直近の利用可能なバックアップを残し、すべてのグループを削除して作り直すのは避けましょう。一部のノードだけが使える場合は、サブスクリプション全体を何度も更新するより、プロトコルと転送方式ごとに比較するほうが有益です。すべてのノードが失敗する場合に、ローカル環境とサブスクリプションの状態を調べてください。

更新するたびに、現在選択されているノードを確認してください。元のノードが削除された後、クライアントが意図した項目を自動選択していない場合があります。ノードの選び方は遅延、倍率、地域、プロトコルの選び方をご覧ください。この章の完了条件は、一覧に項目が表示されることではありません。設定がそろい、次の検証に使える接続を確保し、どのサブスクリプショングループから取得したか把握できていることです。

システムプロキシとアプリへの適用範囲

システムプロキシはアプリとの取り決めであり、端末全体の通信を取り込む仕組みではない

デスクトップのシステムプロキシは、その設定に従うアプリに対して、リクエストをローカルのプロキシ入口へ送るよう指示します。すべてのプログラムを自動で取り込むわけではなく、アプリごとのネットワーク処理も変えません。ブラウザーでは比較的確認しやすい一方、ゲーム、コマンドラインツール、アプリ内のネットワーク機能などはシステムプロキシを無視することがあります。そのため「ブラウザーは使えるが、他のソフトは使えない」という場合は、まず適用範囲を確認します。すぐにクライアントの故障と判断しないでください。必要に応じてアプリ独自のプロキシ設定やTUNを検討できます。

v2rayNのシステムプロキシには、「システムプロキシをクリア」「システムプロキシを自動設定」「システムプロキシを変更しない」「PACモード」などがあります。「クリア」は通常、現在のシステムプロキシの参照先を解除しますが、コアの停止を意味しません。「自動設定」はシステムの参照先をクライアントのローカル入口に変更します。「変更しない」は現在のシステム設定を維持するという意味で、接続を自動的に開始するものではありません。選択前に、システムに手動プロキシや他のソフトが管理する設定がないか確認し、互いの設定を上書きしないようにしましょう。

PACとコアのルーティングは別の段階で判断する

PACは自動プロキシ設定スクリプトを使い、対応するアプリが直接接続するかプロキシに送るかを決めます。この段階でアプリが直接接続すると、リクエストはクライアントのコアに届かず、コアのルーティングルールも適用されません。コアのルーティングが処理するのは、ローカルの入口に届いたリクエストです。両方を組み合わせることはできますが、トラブル時の確認項目が増えます。初回の検証では入口の方法を1つに絞り、接続を確認してからPACが必要かどうか判断してください。

アプリに手動プロキシを設定する場合は、入口のプロトコルも確認してください。HTTPプロキシとSOCKSのポートは異なることがあります。1つの混合入口で両方を受け付ける場合もあるため、現在の待ち受け設定を確認します。ローカルのループバックアドレスは同じ端末上のクライアントにしか接続できません。ブラウザーに古いポートが保存されている場合、システムプロキシを更新してもブラウザー独自の設定が優先されることがあります。ブラウザー拡張機能がプロキシを制御している場合もあるため、テストでは管理元を1つに絞りましょう。

AndroidのVPNモードとルーティング

AndroidクライアントはシステムのVPNインターフェースを通じて通信を受け取ります。すべてのアプリが対象になるかどうかは、アプリごとのルールとルーティング設定にも左右されます。システムにVPNの表示が出ていても、すべてのリクエストがリモートのプロキシを経由しているとは限りません。除外されたアプリは元のネットワーク経路を使うことがあり、直接接続のルールが適用された宛先もローカルネットワークに接続できます。アプリの問題を調べる際は、接続スイッチだけでなく、対象アプリの範囲とコアの出力先も確認してください。

検証には安定してアクセスできるテスト先を1つ選び、接続を有効にして新しいリクエストを送信します。該当する接続がクライアントのログに記録されるかを確認してください。ブラウザーのキャッシュがあると、通信が発生していなくてもページが表示されることがあります。既存の長時間接続が古い経路を使い続ける場合もあります。新しいページリクエストを送り、接続を張り直して確認しましょう。ログにリクエストがなければ入口を調べます。リクエストはあるものの失敗する場合は出力先を確認し、成功しているのに内容がおかしい場合は接続先サービスとDNSを調べます。

終了する前に、現在のシステムプロキシをどのソフトが管理しているか確認してください。クライアントを停止した後もシステムがそのローカルポートを参照していると、プロキシに従うアプリは接続できなくなります。残ったシステムプロキシを解除するか、該当クライアントを再起動すればよく、すぐにネットワーク設定全体をリセットする必要はありません。別のクライアントに切り替える場合も、まず元の接続を停止してシステムの状態を確認してください。一方のソフトが設定したプロキシアドレスを、もう一方が解除してしまうことを防げます。

この段階の完了条件は「対象アプリのリクエストが実際にクライアントへ届いていること」です。まずは複雑なルーティングを設定する必要はありません。手早く接続を確認する場合は入門ガイドの接続・確認手順をご覧ください。モード名と実際の適用範囲が一致しない場合はヘルプセンターを確認してください。次の段階では、コアに届いた通信の出力先を扱います。通信の取り込みとルーティングを同じスイッチの問題として混同しないようにしましょう。

ルーティングルール、DNS、照合順序

入口、ルール、出力先の関係を理解する

コアに届いたリクエストはルーティングによって出力先が決まります。ルールは通常、設定順に照合され、条件に一致すると指定された出力先へ送られます。同じ照合に対して後続のルールは適用されません。そのため、広い範囲を対象にするルールを先に置くと、後の詳細なルールが適用されないことがあります。変更前に、クライアントがどの出力先タグを生成しているか、どのルールにも一致しない通信をどう処理するか確認してください。画面上の「プロキシ」や「直接接続」という名称が、設定ファイル内の実際のタグ名とは限りません。

直接接続は現在の端末から宛先へ接続し、プロキシは設定済みのリモート出力先を使い、遮断は該当する通信を拒否します。これはネットワーク品質の段階を示すものではありません。LAN内のサービスをプロキシ経由にすると、プリンター、ルーターの管理画面、ローカルの開発サービスにアクセスできなくなることがあります。リモート経由が必要な宛先を直接接続すると、アクセス結果が異なる場合があります。ルールは明確な目的に合わせ、すべての項目を同じ方向へ変更しないようにしましょう。

最小限のルールで設定項目を理解する

以下はXray形式のルーティング例です。特定のドメイン群とプライベートアドレスを、directという名前の出力先へ送ります。クライアント設定全体を置き換えるための完全なファイルではありません。実行時には同名の出力先が存在し、コア環境で対応するルールデータを利用できる必要があります。クライアントがルーティングを管理している場合は、手動設定と画面からの設定が互いに上書きしないよう、ルーティング画面で同等のルールを追加してください。

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

domainStrategyは、ルーティングでドメインとアドレスをどのように扱うかを指定します。IPIfNonMatchでは、ドメインの照合に失敗した後でアドレスを解決し、アドレスのルールを続けて照合できます。すべてのDNSリクエストが自動的にプロキシ経由になるわけではなく、すべてのアプリの名前解決が同じ設定で制御されるわけでもありません。コアやクライアントには独立したDNS設定もあります。ルーティング方針を変更したら、名前解決の経路と実際の接続経路を別々に確認してください。

ドメインルールとアドレスルールの適用範囲

ドメインルールを適用するには、コアが宛先のドメイン名を把握している必要があります。アプリがIPアドレスに直接接続する場合や、リクエストが届いた時点でドメイン名を取得できない場合、設定したドメインルールに一致しないことがあります。条件によっては、スニッフィングで一部のプロトコルから宛先情報を識別できますが、すべての通信を識別できるわけではなく、正しいDNSや入口の設定を代替するものでもありません。スニッフィングを有効にした後もログを確認し、ルール名だけで動作を判断しないでください。

DNSの問題では、ドメイン名ではアクセスできないのにIPアドレスには接続できないことがありますが、これはあくまで手がかりです。セキュアな接続ではサーバー名も必要になる場合があるため、IPアドレスで直接アクセスしても同じ条件になるとは限りません。まず名前解決の結果を確認し、次にその結果への接続が成功するか、最後にセキュリティハンドシェイクを確認します。DNSサーバーの変更、スニッフィングの有効化、ルーティングの変更を同時に行わないでください。問題が解消しても、どの変更が効果をもたらしたのか分からなくなります。

ルールの管理では、「例外を先に置く、対象範囲を明確にする、変更を元に戻せるようにする」を基本にしてください。まず個別のルールを1つ追加し、対象アプリから新しいリクエストを送って、ログで一致結果を確認します。正常に動作した後で、対象をドメイン群に広げましょう。ルールデータベースもグループの照合結果に影響します。クライアントの更新後に動作が変わった場合は、画面上の設定だけでなくルールデータと設定ファイルも確認してください。設定の構造についてはinbounds、outbounds、routingの解説をご覧ください。

TUNモードとシステムルーティングの範囲

仮想ネットワークインターフェースが必要なケース

TUNは仮想ネットワークインターフェースを通じてシステムの通信を受け取り、クライアントまたは対応するコアコンポーネントへ渡します。システムプロキシに従わず、アプリ独自のプロキシ設定も使えない場合に適しています。解決するのは通信をクライアントに取り込む方法であり、ノードの設定ミスを修正したり、停止済みのサブスクリプションを復旧したりするものではありません。システムプロキシで必要な用途を満たせるなら、「より完全だから」という理由だけでTUNを有効にする必要はありません。取り込み方法を増やすほど、権限、DNS、ルーティングの切り分けは複雑になります。

有効にする前に、通常のプロキシ方式で利用可能なノードがあることを確認し、現在のシステムプロキシ、ルーティングモード、DNS設定を記録してください。元の接続に問題がある状態でTUNを直接有効にすると、接続の基本的な障害とシステムへの通信取り込みの問題が混在します。配布形態によっては、追加のサービス、仮想インターフェース用コンポーネント、権限が必要です。実際の対応状況はクライアント、システム、選択中のコアの組み合わせによって異なります。画面にスイッチがあるだけで、システム側の条件も満たしているとは限りません。

一度に1項目ずつ有効にする

まず、ルーティングを変更したりVPNインターフェースを使用したりする可能性のある他のプログラムを停止してから、クライアントの案内に従ってTUNを有効にします。権限を求められた場合は、要求元と操作内容を確認してください。通常の起動エラーをすべて高い権限で実行して解決しようとしないでください。起動後はコアとインターフェースのログを確認し、権限不足、デバイス作成エラー、ルーティング設定エラーがないことを確かめてから対象アプリをテストします。インターフェースが正常に作成されていない場合、ノードを何度も切り替えても意味がありません。まずローカル側の通信取り込み条件を解決してください。

初回テストでは、理由が分からないままシステムプロキシとTUNを重ねて有効にしないでください。両方を連携できるクライアントもありますが、手動で組み合わせると通信経路が重複し、ログを読み取りにくくなることがあります。まず通信の取り込み方法を1つに絞って確認し、その後、他の設定を1つずつ戻します。テストではリモートの宛先だけでなく、LAN内のサービスや通常のネットワーク接続も確認し、もともと使えていた経路が損なわれていないか確認してください。

通信のループとプライベートネットワークの例外を理解する

クライアントは通常のネットワークを通じてリモートのサービスに接続する必要があります。この通信自体が仮想インターフェースに取り込まれると、ループが発生することがあります。適切に実装されたクライアントでは、インターフェースの割り当て、ルーティングの除外などで対処されますが、システムルーティングを手動で変更したり、他のネットワークツールと併用したりすると条件が崩れることがあります。接続が何度も繰り返される、接続直後にタイムアウトする、TUNを有効にするとすべてアクセスできなくなるなどの症状が現れます。まずTUNを無効にして元の状態に戻し、ルーティングの競合を調べてください。

LANへのアクセスにも明確な範囲設定が必要です。ルーターの管理アドレス、プリンター、リモートデスクトップ、ローカルの開発環境はプライベートアドレスへの直接接続を必要とすることがあります。TUNの有効化後にこれらのサービスへアクセスできなくなった場合は、プライベートアドレスのルール、LANの除外設定、仮想インターフェースのルーティングを確認してください。すべての通信をプロキシに切り替えるだけでは解決しません。ネットワーク環境によってアドレス範囲は異なり、企業ネットワークには独自の方針もあります。ネットワーク管理者の指示に従い、既存のルーティングを無断で上書きしないでください。

DNSとUDPも確認が必要です。TUNが起動しても、すべてのドメイン名の問い合わせが想定した経路を通るとは限りません。アプリ独自の暗号化DNS設定が挙動を変える場合もあります。リアルタイム通信やゲームでUDPが使えるかどうかは、コア、ノード、サーバーの対応状況にも左右されます。ウェブページが表示できても、これらの通信も正常だとは限りません。検証ではウェブページ、名前解決、対象アプリの結果を分けて記録し、1種類のテストですべての状況を判断しないでください。

TUNを無効にしてもネットワークが復旧しない場合は、まずクライアントを正規の手順で停止し、システムプロキシと現在のVPN接続を確認してから、仮想インターフェースがまだ動作していないか調べてください。クライアントの停止機能や復元機能を優先して使い、システムのネットワークアダプターを一括削除しないでください。有効化前の設定を記録し、必要であればシステムを再起動して設定の残留を確認します。この章の完了条件は、通信の取り込み範囲と対象アプリの確認方法を説明でき、通常のプロキシ方式へ安全に戻せることです。スイッチがオンになっているだけでは完了ではありません。

日常のメンテナンスと段階的なトラブル対処

更新前に復元できる状態を保つ

日常のメンテナンスでは、クライアント、コア、サブスクリプション、ルールデータの更新を区別してください。変更される内容がそれぞれ異なるため、問題が発生したときに一度にすべて更新するのは避けましょう。クライアントの更新は画面や設定の生成方法に影響し、コアの更新はプロトコル対応に影響します。サブスクリプションの更新ではノードが変わり、ルールデータの更新ではルーティングの照合結果が変わる場合があります。現在の利用可能な設定を記録し、必要なものを1つずつ更新して正常に動作することを確かめてから次へ進めば、問題の発生箇所を特定しやすくなります。

バックアップには、サブスクリプショングループ、手動ノード、ルーティングとDNSの設定、アプリへの通信取り込み範囲を含めてください。クライアントにエクスポート機能がある場合は、それを優先します。データフォルダーをコピーする際は、ファイルが書き込み途中でバックアップされないよう、先にプログラムを停止してください。バックアップに認証情報が含まれる場合があるため、管理された場所に保管します。別のクライアントや配布形態に復元する際、内部設定の形式がすべて互換性を持つとは限りません。必要に応じて標準のノード情報を使って再インポートしてください。

まずエラーが発生した段階を確認する

接続に失敗した場合、まず通常のネットワークアクセスができるか確認し、次にクライアントのコアが動作しているか、さらにリクエストがログに届いているかを調べます。コアが起動していなければ、リモートノードをテストする必要はありません。ログにリクエストが届いていない場合は、プロキシやVPNによる通信の取り込みを確認します。リクエストがコアに届いている場合は、その後にリモート接続、名前解決、ハンドシェイクの結果を調べます。この順番なら「ローカルでリクエストを受け取っていない」状態と「受け取った後の処理に失敗した」状態を区別でき、無駄な切り替えを減らせます。

ログのタイムアウトは、ある処理の待ち時間が制限を超えたことを示すだけで、原因までは特定しません。接続先へのタイムアウトはネットワーク経路やサービスの状態、ハンドシェイクエラーはサーバー名、鍵、システム時刻、プロトコルの組み合わせ、名前解決エラーはDNSに関係している可能性があります。エラーの単語だけを検索するのではなく、前後のログにある宛先や処理段階を確認してください。ログを共有して相談する場合は、エラーの種類と発生順を残し、ノードの認証情報や個人のネットワーク情報は隠しましょう。

条件を絞った比較テストで原因を調べる

比較テストでは一度に変更する条件を1つにします。クライアントとモードを維持して、利用可能と分かっている別のノードに切り替えれば、ノード側に問題があるかを調べられます。ノードを維持して別のネットワークに接続すれば、現在のネットワーク環境の影響を確認できます。ネットワークとノードを固定し、ルーティングだけを初期状態に戻せば、カスタムルールが原因かを調べられます。ネットワーク、クライアント、サブスクリプションを同時に変更して成功しても、特定の設定が有効だった証拠にはなりません。

システム時刻は、信頼できる時刻同期の仕組みで管理してください。証明書の有効期間や時刻に関係する認証では特に重要です。時刻が大きくずれていると、設定が正しくても失敗することがあります。もう1つよくある原因は、システムプロキシの設定が残っていることです。クライアント終了後にローカルポートの待ち受けが停止しても、アプリが古い入口へリクエストを送り続ける場合があります。その場合は、ノードをすべて削除したりOSを再インストールしたりするのではなく、まずシステムプロキシを復元してください。

トラブル対処のときだけ必要に応じてログレベルを上げ、作業後は通常のレベルに戻してください。アクセスの詳細を過剰に記録した状態を長く続けないようにしましょう。スクリーンショットしか共有できない場合は、エラーの前後の関連行と現在のモードも含めてください。「接続に失敗しました」という1行だけでは十分な情報になりません。ノードのタイムアウトを詳しく確認するには7つの確認ポイントをご覧ください。一般的な使い方の問題はヘルプセンターをご利用ください。メンテナンスの目的は安定した基準状態を保ち、すべての変更を記録して元に戻せるようにすることです。

設定の読み方と応用学習の進め方

まず生成された設定を読み、自分で設定を追加する

ここまでの手順を終えた後、応用設定の第一歩はルールを増やすことではなく、クライアントが生成した設定を理解することです。ローカルのインバウンド、リモートへのアウトバウンド、直接接続用のアウトバウンド、ルーティング、DNSがそれぞれどこにあるかを確認し、タグの参照関係をたどります。画面は操作しやすいように抽象化されていますが、設定ファイルにはコアが実際に受け取る指示が記載されています。両者の表示が異なる場合は、現在動作中のインスタンスが生成したファイルかを確認してください。古い設定を読んで、現在の挙動を誤って判断しないようにしましょう。

インバウンドは通信の受け取り方と待ち受け範囲を決め、アウトバウンドは宛先やリモートサービスへの接続方法を定義し、ルーティングはタグを使って両者を結び付けます。タグは設定内で参照する名前であり、自動的に関連付けられるものではありません。例のアウトバウンドタグを変更した場合は、それを参照するすべてのルールも合わせて変更する必要があります。設定の構文が正しくても、ロジックが正しいとは限りません。ルールを解析できても、先行する広範なルールに遮られて適用されないことがあります。リクエストを送って動作を確認してください。

個別のルールで設定値の範囲を試す

次のルールはドメイン照合の学習に適しています。full:は完全一致、domain:は指定したドメインとそのサブドメインに一致します。例の宛先にはドキュメント用のサンプルドメインを使用しています。追加する際は既存のルーティングルール配列に含め、directアウトバウンドが存在することを確認してください。この例自体は完全な設定ではなく、リモートへの接続情報も含みません。元のファイルをそのまま置き換えるのではなく、ルールの順序、一致条件、参照先のタグを確認することが目的です。

{
  "type": "field",
  "domain": [
    "full:example.com",
    "domain:example.org"
  ],
  "outboundTag": "direct"
}

カスタム設定を始める前に、起動時にクライアントが設定ファイルを再生成するか確認してください。再生成される場合、生成済みファイルを直接編集しても一時的にしか有効にならず、次に設定を保存したときに上書きされることがあります。クライアントが提供するカスタム設定、ルーティング管理、テンプレートの機能を使い、画面上の設定と統合されるのか、置き換えられるのかを確認してください。同じ項目が複数の場所で管理されていると、最終的にどの値が使われるか分かりにくくなります。設定の管理元はできるだけ整理し、それぞれの項目の担当を明確にしましょう。

実際の必要に合わせてプロトコルを学ぶ

プロトコルの応用学習は、VMessとVLESSの基本的な違いから始め、その後でセキュリティ層と転送方式の組み合わせを理解しましょう。プロトコル名だけで速度や安定性を判断しないでください。実際の動作はサーバー、ネットワーク経路、アプリの挙動にも左右されます。REALITY、TLS、WebSocketにはそれぞれ必要な設定値と利用条件があります。提供元が明確なノードの設定を項目ごとに読み、無作為な例にある設定値を組み合わせて接続を作らないでください。基本的な比較はVMessとVLESSの解説をご覧ください。

その後、DNSの方針、ルールセット、スニッフィング、アプリごとの適用範囲を調べます。各テーマについて、たとえばLAN内のサービスを直接接続にする、特定アプリのリクエストを指定した出力先に送るなど、検証できる目標を1つ決めてください。想定される結果を書き出してから設定し、テストではルールに一致したか、どの段階で失敗したかを記録します。設定項目を変更すると何が変わるのか説明できない場合は、ひとまず初期値のままにしてください。複雑な項目を必須機能の一覧として扱う必要はありません。

長期間使う場合は、変更内容の簡単な記録を残します。どの項目を変更したか、何を解決するためか、どの条件で確認したか、どうすれば元に戻せるかを記録してください。更新後に動作が変わった場合は、すぐに環境全体を作り直すのではなく、変更記録と実際の設定を比較します。別の端末へ移行する場合も、システムプロキシ、権限、インターフェースの範囲をあらためて確認してください。ノードの設定値が同じでも、OSによって通信の取り込み方法は異なります。設定を共有する際は、機密情報を隠してから利用してください。

ここまでで学習の流れが一通り完成します。接続経路を説明し、適切なインストールパッケージを選び、サブスクリプションを追加・管理し、通信の取り込みとルーティングを区別し、TUNを検証して元に戻し、最後にログでカスタムルールを確認できるようになります。次に調べるときは、毎回最初から読む必要はありません。ページ上部の目次から該当するステップに戻ってください。利用可能な最小構成の接続を作り直す場合は、クイックスタートに戻り、必要な設定を1つずつ復元しましょう。過去の設定が新たなトラブルの原因になるのを防げます。