V2Ray入門から応用まで
クライアント設定完全ガイド

基本概念：設定の階層を理解する

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

まず、GUIクライアントを設定の入口として捉えましょう。v2rayNはサブスクリプションの管理やノードの選択、実行用設定の生成を行い、適切なコアを起動します。プロトコル接続やトラフィック転送を実際に処理するのはコアです。サーバーは接続先にあり、クライアントと同じプロトコルや認証情報を使用する必要があります。クライアントは無料でダウンロードできますが、インストールしただけで利用可能なサーバー設定が手に入るわけではありません。作業を始める前に、提供元が明確で有効なノード情報またはサブスクリプションURLを用意してください。

Project Vは関連するプロキシ技術エコシステムの出発点です。V2FlyはV2Rayのコミュニティ開発を引き継ぎ、Xrayは関連する別のコア開発系統です。sing-boxも一部のクライアントから利用できるプロキシコアですが、V2Rayの別名ではありません。コアによって設定構造、機能対応、パラメーターの意味は異なります。GUIで同じ項目が表示されていても、あらゆる設定をどのコアでもそのまま実行できるとは限りません。

プロトコル、トランスポート、セキュリティ設定をまとめて理解する

VMess、VLESS、Trojan、Shadowsocksはプロキシのプロトコルを表します。一方、TCP、WebSocket、gRPCなどは接続に使うトランスポート方式です。TLSやREALITYは接続のセキュリティに関わる仕組みで、プロトコル名と混同しないようにしましょう。アドレスとポートが正しくても、トランスポート経路、サービス名、セキュリティ設定が一致しなければ接続に失敗することがあります。インポート後はパラメーター一式を保ち、名前が似ているからと手動で項目を置き換えないでください。

VLESSを例にすると、ノードの設定を確認する際は、サーバーアドレス、ポート、ユーザーID、トランスポート方式、セキュリティ設定をまとめて見る必要があります。TLSではサーバー名が必要な場合があり、REALITYでは対応する公開鍵やショートIDなどのパラメーターが一致していなければなりません。VLESSだけで暗号化接続の仕組みがすべて決まるわけではなく、セキュリティレイヤーを有効にするか、どの組み合わせにするかはサーバー設定に従います。別のノードのパラメーターを継ぎ足して試すのは避けてください。

トラフィックの経路に沿って設定箇所を特定する

通常、アクセスはアプリからリクエストが送られ、クライアントに入り、ルーティングルールで出口が選ばれ、コアがサーバーに接続し、サーバーが宛先にアクセスするという流れをたどります。システムプロキシとTUNは主にトラフィックの入口を決め、ルーティングルールは入口の後に直結、プロキシ、遮断のどれにするかを決めます。ノードの設定はプロキシ接続を確立できるかどうかに関わります。DNSも名前解決を通じてルールの一致や実際の接続先に影響します。階層を分けて考えれば、トラブル時にノード一覧だけを確認することはなくなります。

この章の目標は、すべての用語を暗記することではなく、現在の構成を説明できることです。使用しているクライアント、呼び出すコア、ノードのプロトコル、アプリの接続経路、既定のルーティングを把握しましょう。これらを短く記録しておけば、以降の変更を一度に一つの階層に限定できます。見慣れない名称は用語集で確認してください。エラーが出たら、起動、解析、ハンドシェイク、宛先へのアクセスのどの段階かを見極めてから、次に確認する箇所を決めましょう。

クライアントの選び方：OSと設定要件に合わせる

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

Windows、macOS、Linuxのデスクトップではv2rayNを第一候補にすると、このガイドで扱うサブスクリプショングループ、システムプロキシ、ルーティングの操作を活用できます。ダウンロード前にOSとプロセッサーのアーキテクチャを確認し、対応する配布パッケージを選んでください。同じOS向けでも、x64とarm64は異なるプロセッサー命令セットを対象としており、パッケージを共用できるとは限りません。起動できない場合はノードを次々と変えるのではなく、まずパッケージの対応環境を確認してください。この時点ではネットワーク設定がまだ動作していない可能性があります。

Windowsのダウンロードページには、Desktop版と従来のWPF版があります。Desktop版はクロスプラットフォームのUIを採用しており、複数のデスクトップOSで似た操作感を求める方に適しています。WPF版は従来のWindows UIを維持しており、これまでの操作に慣れている方に向いています。主な違いはUIと配布方式であり、特定のノードが速いことを意味するものではありません。実行時の依存関係、画面上の項目、設定の保存方法は、実際の配布パッケージの説明を確認してください。異なるパッケージのプログラムファイルを同じディレクトリで混在させないようにしましょう。

Androidは標準と互換用の選択肢を分ける

AndroidではXrayコアを使用するv2rayNGを第一候補とし、V2Flyコアを使用するv2flyNGは、互換性が必要な場合の選択肢にします。どちらもノードのインポートや接続管理に使えますが、共有リンク、トランスポート設定、高度な機能がすべて同じように動作するとは限りません。既存設定が特定のコア機能に依存している場合は、対象クライアントがその組み合わせに対応していることを確認してからインポートしてください。名前が似ているという理由だけでアプリを切り替えると、プロトコルの対応問題をサブスクリプションの不具合と誤認するおそれがあります。

Androidのインストールパッケージは、通常arm64版と汎用版から選びます。比較的新しい主流のスマートフォンでは、まずarm64対応を確認してください。アーキテクチャが分からない場合や互換性の問題がある場合は、汎用版の対応条件も確認しましょう。汎用版は接続品質が高いという意味ではなく、対応アーキテクチャの範囲が異なります。インストール前に、現在のファイルの提供元からのインストールをシステムが許可しているかも確認してください。インストール後の権限許可は別の手順であり、インストールに成功してもプロキシが起動したことにはなりません。

機能比較の前に実際の用途を整理する

機能の数を比べるより、具体的な用途を書き出すほうが役立ちます。ブラウザーだけにプロキシを使うなら、まずシステムプロキシやアプリ内のプロキシ設定を確認します。システムプロキシを参照しないアプリの通信も通したい場合は、TUNを検討します。アプリごとに通信を振り分けるには、対象プラットフォームのアプリ別ルーティング機能を確認してください。これらの用途は、それぞれ異なるシステム機能に依存します。クライアントにスイッチが表示されていても、現在のシステム権限、ネットワーク環境、コアの組み合わせが有効化の条件を満たしているとは限りません。

クライアントを選ぶ際は、メンテナンスの負担も考慮しましょう。現在の構成が安定している場合、移行前にサブスクリプションの提供元、ルーティング方針、特殊なパラメーターを記録し、新しいクライアントで同じ設定を再現できるか確認してください。エクスポートしたファイルを別のクライアントでそのまま復元できるとは限りません。可能であれば元のサブスクリプションや標準の共有リンクから再構築してください。詳しくはクライアント選びのガイドを、インストール先はダウンロードページを参照してください。この章を終えたら、まず第一候補を一つに絞り、動作する基本構成を作ってから乗り換えの必要性を検討しましょう。

インストールと起動：まず動作する基本構成を作る

アーキテクチャ、インストール先、権限を確認する

クライアントのダウンロードページを開き、OSに合った配布パッケージを選んでください。Windowsではシステム情報からシステムの種類を確認し、macOSではデバイス情報からチップを確認します。Linuxではアーキテクチャとパッケージ形式の両方を確認してください。ファイルの拡張子だけで対応機種を判断しないようにしましょう。ダウンロード後はインストールまたは展開を完了してから、メインプログラムを起動します。展開して使う配布パッケージの場合、圧縮ファイル内のプレビューから直接起動しないでください。相対パス、リソースファイル、設定の保存に問題が起きることがあります。

Windowsではクライアント専用のディレクトリを用意し、異なる配布パッケージを同じ場所に上書きしないようにしましょう。現在のユーザーが設定を保存できる場所を選び、初回設定時には終了後も変更が保持されるか確認してください。通常の利用で、手間を省くために常時すべての権限を昇格させる必要はありません。追加権限が必要な機能を有効にする場合に限り、クライアントの案内に従ってください。実行時ファイルがないというエラーが出た場合は、エラーメッセージに応じた依存関係をインストールし、別のPCから実行ライブラリを適当にコピーするのは避けてください。

macOSではチップに合ったインストール方法を選び、システムの手順に沿って適切な場所に配置して起動します。システムに起動を阻止された場合は、まずファイルの提供元と警告内容を確認し、セキュリティ設定から正規の手順で許可してください。Linuxではディストリビューションに適したdebまたはrpmパッケージを選び、システムのパッケージ管理手順で依存関係を解決します。デスクトップ環境、権限の許可方法、仮想ネットワークインターフェースの対応状況はディストリビューションごとに異なる場合があります。起動エラーとネットワーク接続エラーは分けて記録し、ひとまとめにしないでください。

初回起動では必要な項目だけを確認する

メイン画面が開いたら、設定を正常に保存できるか、コアが起動できるか、ローカルの待ち受けアドレスとポートが競合していないかを確認します。待ち受けポートはアプリからクライアントに接続する入口であり、サーバーのポートとは役割が異なります。ログにアドレスが使用中と表示された場合は、ほかのプロキシプロセスを終了するか、ローカルの待ち受け設定を変更してから再起動してください。見慣れないシステムプロセスを終了したり、複数のクライアントを同じポートで同時に起動したりすると、後のテスト結果が不明確になります。

初回起動ではシステムプロキシとTUNを無効にしたまま設定を一つインポートし、クライアントの接続テスト、またはプロキシを明示的に設定したアプリで確認します。これにより、コアの動作とシステムトラフィックの取り込みを切り分けられます。画面は正常でもコアが何度も終了する場合は、起動ログの最初のエラーを確認し、設定の互換性、リソースファイルの不足、権限不足、ポート競合を重点的に調べてください。ウィンドウが表示されたままでも、バックグラウンドのプロキシサービスが正常に動作しているとは限りません。

起動と終了を一度ずつ確認する

Androidでは、インストール後の初回接続時にシステムのVPN権限ダイアログが表示されます。これはアプリがシステムのネットワーク機能を通じてトラフィックを取り込むための許可であり、サーバーへの接続が完了したことを意味しません。許可を求めているアプリを確認してから、クライアントの動作状態を確認してください。端末ですでに別のVPN接続が使われている場合、通常はいずれか一方を選ぶ必要があります。デスクトップでも、ほかのネットワークツールに古いプロキシ設定が残っていることがあります。初回のトラブルシューティングでは、こうしたツールを一時停止し、新しいクライアントが正常に動作していても古い入口に影響される状況を避けましょう。

最後にクライアントを終了し、もう一度起動して、サブスクリプショングループと設定が保持されていることを確認してください。さらに終了後にシステムプロキシが元に戻るか、ローカルの待ち受けが停止しても基本的なネットワークアクセスができるかを確認します。インストール段階の完了条件は、プログラムを起動でき、設定を保存でき、コアの起動エラーがなく、起動中と停止中を明確に区別できることです。Windowsの画面表示や依存関係の詳細は、Windowsのインストール手順とよくある問題も参照してください。インストールが安定する前に複雑なルーティングを重ねないようにしましょう。

サブスクリプションとノード：継続して更新できる設定元を用意する

まず、どの種類のリンクを受け取ったか確認する

サブスクリプションURLは複数の設定を取得するためのもので、更新時も同じ提供元にアクセスします。共有リンクは通常、特定のプロトコル名で始まる単一ノードの情報です。インポート方法は異なり、サブスクリプションはグループに登録し、単一ノードのリンクはクリップボードまたは共有リンクから取り込みます。ブラウザーで開けるURLがサブスクリプションとは限りません。アカウントページや説明ページの場合もあります。インポート前に提供元の案内を確認し、ログインページのURLをクライアントが解析できる設定データと取り違えないようにしてください。

v2rayNでサブスクリプショングループを作成し、提供元を識別できる名前を付けて、URL全体を貼り付けます。コピー時は先頭のプロトコル、パス、クエリパラメーターがすべて含まれているか確認してください。特に疑問符以降を省略したり、空白、改行、全角記号を混ぜたりしないようにしましょう。保存したら対象グループを更新し、ノードが表示されるか確認します。グループ名はローカル管理用のラベルで、サーバー認証には関係ありません。名前を変更しても、期限切れのURLや無効な認証情報は直りません。

更新方法はURLにアクセスできるかどうかで選ぶ

サブスクリプションをプロキシ経由で更新するかどうかは、現在のネットワークとURLへの到達性に応じて決めます。まだ利用可能なプロキシがない場合は、まずプロキシを経由せずに更新してください。直接アクセスがネットワーク経路の影響を受け、利用できるノードがすでにある場合は、プロキシ経由での更新を試します。この2つはサブスクリプションの取得経路の違いであり、形式を修復するための切り替えではありません。サーバーからログイン画面、エラーページ、空の内容が返ってくる場合は、経路を切り替えても解決しないことがあります。URLの権限と提供元の状態を確認してください。

更新に失敗しても、既存ノードはすぐに削除せず残しておきましょう。ログを確認し、接続タイムアウト、名前解決の失敗、認証拒否、内容の解析エラーのどれかを見極めます。最初の2つは取得経路、後の2つは提供元の権限や内容形式が原因の可能性があります。必要に応じて設定の提供元にURLの状態を確認してください。ただし、サブスクリプションURL全体を公開の場に貼り付けないでください。クエリパラメーターにはアクセス用の認証情報が含まれることがあるため、漏えいした場合はチャット履歴を消すだけでなく、提供元の手順に従って変更してください。

更新後は実際に利用できるかも確認する

ノード一覧を取得できたことは、内容を読み込んで解析できたことを示すだけで、すべてのノードが接続できるとは限りません。まず、必要なパラメーターがそろい、現在の用途に合うノードを選んで有効にし、実際のリクエストを試してください。一覧の名前はラベルにすぎず、プロトコル、セキュリティ方式、利用可能な地域を確実に示すものではありません。単一ノードを長期間使う場合は、提供元と用途を記録しておきましょう。元の提供元がサービスを終了している場合、表示名を変更したり同じリンクを再インポートしたりしても接続は復旧しません。

サブスクリプション由来のノードと手動登録ノードは分けて管理するのがおすすめです。クライアントによっては、グループの更新時にその中の項目を再生成するため、サブスクリプションから作成されたノードのパラメーターを直接編集すると、次回更新で上書きされることがあります。ローカルで変更する必要がある場合は、クライアントの設定保持機能を確認するか、独立した設定として複製し、提供元を記録してください。サブスクリプションの更新ですべてのローカルルーティング設定が置き換わるとも、まったく影響しないとも決めつけず、更新後に選択中のノードと重要なパラメーターを確認しましょう。

安定した提供元を確保してから自動更新を検討しましょう。更新頻度は提供元の利用条件に合わせてください。頻繁に更新しても最新の状態になるとは限らず、アクセス制限の原因になることがあります。大きな更新の後はノード数に異常がないか、有効なノードが変わっていないか、実際のリクエストが成功するかを確認してください。単一ノードとサブスクリプションの違いは共有リンクとサブスクリプションURLの解説を参照してください。更新に失敗した場合は、サブスクリプション更新失敗時のチェックリストに沿って取得結果から確認し、次に内容の互換性を調べましょう。

プロキシモード：アプリの接続経路を確認する

システムプロキシは入口を制御するもので、ルーティングを直接決めるものではない

システムプロキシは、アプリが参照するシステムのネットワーク設定です。有効にすると、その設定に従うアプリはローカルのプロキシ待ち受けにリクエストを送ります。システムプロキシを参照しないアプリは、そのまま直接接続する場合があります。そのため、システムプロキシを有効にしても端末内のすべての通信が取り込まれるわけではなく、すべてのリクエストがリモートノードを使うとも限りません。クライアントに入った後で直結するかどうかは、ルーティングによって決まります。入口と出口を分けて考えれば、アプリが接続していない問題をグローバルルーティングで直そうとする誤りを防げます。

v2rayNの主な選択肢には、システムプロキシの解除、自動設定、変更しない、PACモードがあります。自動設定は該当するシステム設定をクライアントのローカル入口に向け、解除はその設定を取り除きます。「変更しない」はシステムの現状を保つ設定で、強制的に直結させるものではありません。PACでは、この仕組みに対応するアプリがスクリプトに従って接続経路を選びます。どのシステム項目が変更されるかは、OSとクライアントの実装によって異なるため、切り替える前に現在のネットワーク設定を記録しておくと安心です。

アプリを使って入口が機能しているか確認する

まずTUNを無効にしたまま利用可能なノードを選び、コアを起動してからシステムプロキシの自動設定を有効にします。システムプロキシに従うことが明確なブラウザーで新しいリクエストを送り、クライアントのアクセスログに対象が記録されるか確認してください。接続が再利用されて判断に影響しないよう、必要に応じて既存の接続を閉じるかブラウザーを再起動します。該当するリクエストがまったく記録されない場合は、リモートノードの切り替えやトランスポート設定の変更ではなく、アプリ独自のプロキシ設定、システム設定、ローカルの待ち受けを確認してください。

アプリにHTTPまたはSOCKSプロキシを手動で入力する項目がある場合は、クライアントに表示されている待ち受け方式、アドレス、ポートに従って設定してください。ガイドの例にある数字をそのまま使わないようにしましょう。HTTPの待ち受けをSOCKSとして使うことはできません。複数方式の待ち受けに対応するクライアントでも、その機能が有効になっていることを確認してください。アプリに個別のプロキシを設定した場合、システムプロキシのスイッチは動作に影響しないことがあります。アプリごとの設定を記録しておけば、同じ端末で一部のアプリだけに影響する理由を説明しやすくなります。

PAC、グローバル、特定地域の通信を迂回する設定は、それぞれ別の階層にある

PACはアプリからクライアントへ接続する前に一部の経路を選びます。一方、クライアント内のグローバルや中国本土向け通信を迂回するルーティングプリセットなどは、トラフィックが入った後の出口を決めます。両方のルールを重ねると、直結するリクエストが入口側で処理され、コアのログに表示されない場合があります。使い始めの段階では、確認しやすい入口を一つだけ使ってからコアのルーティングを設定してください。PACが必要な場合は、スクリプトの提供元、更新方法、対応範囲を確認し、複数の自動判定を同時に重ねないようにしましょう。

プロキシの検証には、クライアントのアイコン色を見るだけでなく、実際のアプリ通信を使ってください。ある宛先にアクセスできたとしても、確認できたのはその宛先と現在のリクエスト経路だけです。別のアプリでは、異なるプロトコル、DNS経路、独自のプロキシ設定が使われる可能性があります。ブラウザーは使えても別のプログラムが失敗する場合は、まず入口の違いを比べてください。ページの一部のリソースが読み込めない場合は、リソースごとのドメインのルーティングと名前解決を確認しましょう。トップページが表示されたからといって、すべての接続が正常とは限りません。

職場のネットワークでは、管理ポリシーによってプロキシ設定が指定されている場合があります。変更前に端末の権限と組織のルールを確認してください。個人用のプロキシ設定を、変更が許可されていない環境にそのまま適用しないようにしましょう。終了、スリープ、ネットワークの切り替え後も、システムの入口が想定どおりか確認してください。この章の目標は、どのアプリが接続するか、入口のアドレスをどこから取得するか、クライアント終了後にどう復元するかを説明できることです。より広い範囲の通信を取り込みたい場合はTUNの章に進み、システムプロキシの不具合をすべてノードの問題と決めつけないようにしましょう。

ルーティング：必要なことを最小限のルールで表す

プリセットを使って説明可能な既定動作を設定する

まず現在の用途に合ったルーティングプリセットを選び、必要に応じて少数のカスタムルールを追加します。グローバルでは、クライアントに入った通信を通常プロキシ経由にしますが、アプリがクライアントに接続しているかどうかは変わりません。「中国本土向け通信を迂回」する設定は通常、ドメインやアドレスのルールで一部の宛先を直結させますが、実際の適用範囲はプリセットの内容とルールデータに依存します。プリセット名だけで仕組み全体を判断しないでください。選択後は具体的なルールと既定の出口を確認し、どのルールにも一致しない通信が最終的にどう処理されるかを確認しましょう。

ルーティングルールは通常、上から順に照合され、先に一致したルールで処理が決まります。範囲の広すぎるルールを先頭に置くと、後にある細かいルールが適用されない場合があります。変更前に、どのドメインを直結するか、どの宛先をプロキシ経由にするか、どの通信を遮断するかを書き出し、照合する条件が適切か確認してください。ドメイン、宛先アドレス、ポート、アプリの情報を常にすべて取得できるとは限りません。現在の入口からアドレスしか渡されない場合、ドメインルールを追加しても機能しないことがあるため、ドメイン情報の取得元も確認する必要があります。

設定の一部を理解し、実行用ファイル全体をそのまま継ぎ足さない

以下はXray形式のルーティング設定例です。ループバックアドレスとプライベートアドレスを直結し、指定ドメインをプロキシに送る基本的な書き方を示しています。クライアント全体の設定ではなく、参照先の出口タグが実際の設定に存在している必要があります。GUIクライアントでは異なるタグが使われる場合もあります。まずは画面上で同じ目的の設定を行い、カスタム設定が必要な場合は現在のコアのドキュメントを確認してください。sing-boxはルール構造が異なるため、この内容を別のコアの設定項目にそのまま貼り付けることはできません。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["127.0.0.0/8", "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "::1/128", "fc00::/7"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "proxy"
      }
    ]
  }
}

この例のドメインサフィックス指定は、対象ドメインとそのサブドメインに一致します。同じ文字列を含むだけの任意のアドレスに適用されるわけではありません。アドレス指定のルールは、宛先アドレスを取得して一致させられる場合にのみ有効です。元のドメイン名を使う方針では、すべてのドメインをアドレスルールのために自動解析することはありません。そのため、LAN内のサービスには、できるだけ明確なローカルドメイン名やアドレスを使い、実際のアクセス方法で動作を確認してください。プライベートアドレスの範囲を記述しただけで、あらゆる入口が必ず対象になると思い込まないようにしましょう。

DNSとスニッフィングがルールの参照情報に与える影響

DNSはドメイン名をどのようにアドレスに変換するかを決め、ルーティングは接続に使う出口を決めます。互いに影響しますが、同じ設定ではありません。名前解決で得られるアドレスはネットワーク、リゾルバー、時刻によって変わることがあるため、一時的なアドレスを完全なドメインルールの代わりにすると不安定になりやすいでしょう。スニッフィングは一部のプロトコルデータから宛先名を判別できる場合がありますが、すべての通信を識別できるわけではなく、万能な修復手段でもありません。用途を理解してから有効にし、互換性にも注意してください。関連する設定を一度にすべて有効にしないようにしましょう。

新しいルールを試すときは、まず対象を一つ決め、変更前の出口を記録します。ルールを追加したら接続を作り直してください。ログにルールや出口が表示される場合は、実際の適用結果を確認します。接続情報しか表示されない場合は、条件を制御できる宛先とリクエスト結果を組み合わせて判断してください。以前の経路が使われ続ける場合は、接続の再利用、アプリのキャッシュ、ルールの順序を確認してから、名前解決の違いを調べます。一度に変更する項目は一つにし、効果を確認してから次に進んでください。そうしないと、どの変更が影響したか分からなくなります。

ルーティングの管理では、ルールを少数に絞り、目的を明確にすることが重要です。不要になった一時的なルールを定期的に削除し、例外ルールは理由を記録してください。ルールデータを更新した後は、よく使う宛先とLANへのアクセスを再テストします。問題が起きたら、直近で正常だったプリセットに戻し、カスタムルールを一つずつ追加してください。複雑さを追求して設定の分かりやすさを損なわないようにしましょう。学習段階で目指すのは、既定の出口、例外条件、照合順序を説明でき、保存完了の表示だけでなく実際のリクエストでルールの動作を確認できることです。

TUNモード：安定した設定を基に通信の取り込み範囲を広げる

仮想ネットワークインターフェースの役割を理解する

TUNは仮想ネットワークインターフェースを介してシステムから通信データを受け取り、システムプロキシを参照しないアプリの通信もプロキシ処理に取り込めるようにします。解決するのはトラフィックの入口の範囲であり、期限切れのサブスクリプション、誤った認証情報、接続できないサーバーを自動的に直すものではありません。有効にする前に、同じノードが基本的なプロキシ経路で動作することを確認してください。そうしないと、入口、ルーティング、サーバー接続の問題が重なってしまいます。ブラウザーだけを使う簡単な用途では、追加の階層が必要とは限りません。

デスクトップOSでは、管理者権限、サービスのサポート、追加のネットワーク権限が必要な場合があります。必要な手順はOSと配布パッケージによって異なります。クライアントの案内に従い、出所の分からない「汎用ドライバー」はダウンロードしないでください。有効にした後は、仮想インターフェースが作成されていること、コアが継続して動作していること、ルーティング設定ですぐにエラーが発生していないことを確認します。Androidクライアントは通常、システムのVpnServiceを通じて通信を取り込みます。権限画面とデスクトップ版のTUNスイッチは操作方法が異なるため、項目ごとにそのまま置き換えることはできません。

プロキシ接続が自身のTUNに再取り込みされるのを防ぐ

TUNではプロキシサーバー自身への接続を適切に処理する必要があります。処理が不適切だと、通信が再び仮想インターフェースに入り、ループすることがあります。GUIクライアントでは通常、自動処理が用意されていますが、複数のクライアントの同時使用、手動のルーティング変更、別のVPNの併用によって想定どおりに動作しない場合があります。初めて有効にする際は、ほかのネットワーク制御ツールを一時停止し、入口を一つにしてください。ログに接続の繰り返し、リクエストの滞留、起動直後のネットワーク切断が見られたら、まずTUNを無効にして基本構成に戻し、出口とシステムルートを確認します。

システムプロキシも同時に有効にするかは、現在のクライアントが推奨する組み合わせに従ってください。併用が必ず誤りとは限りませんが、経路を把握しにくくなります。テスト中はシステムプロキシを無効にし、普段はシステムプロキシに従わないアプリを一つ選んで、TUNの有効化前後でアクセスログがどう変わるか確認できます。クライアントに自動ルーティング、厳格ルーティング、インターフェース選択などの項目がある場合は、役割を理解するまでは初期値のままにしてください。同じ名前の項目でもコアによって挙動が異なることがあり、名前だけを頼りに設定を移行できるとは限りません。

DNS、LAN、スリープ復帰も含めて確認する

TUNではDNSの取り込みや専用の名前解決経路が関係することがあります。有効化後にIPアドレスではアクセスできるのにドメイン名では失敗する場合は、まず名前解決の経路を確認してください。ドメイン名は解決できても接続がタイムアウトする場合は、出口の選択とサーバーへの到達性を調べます。合成アドレス方式を使う場合は、対応するマッピングとルーティングの仕組みが必要です。合成アドレスを宛先の実アドレスとして恒久的なルールに書き込まないでください。社内ドメイン、LAN機器名、特定のリゾルバーが必要なサービスは、それぞれ正しく名前解決できるかテストしましょう。

確認項目には、一般的なWebページ、個別にプロキシを設定していたアプリ、LAN機器へのアクセス、スリープからの復帰を含めてください。Wi-Fiと有線ネットワークを切り替えた後は、出口のインターフェースが変化していないかも確認します。特定のネットワークだけで失敗する場合は、そのネットワークのDNS、ポータル認証、管理ポリシーが関係している可能性があります。まずネットワークに必要なログインを済ませてから、トラフィックの取り込みを有効にしてください。システムがネットワーク設定を正常に取得できていない段階でコアを何度も再起動し、ネットワーク接続の問題をクライアントの障害と取り違えないようにしましょう。

Androidではバックグラウンド制限も確認してください。省電力設定によって画面消灯後にアプリが停止すると、接続が断続的に失敗することがあります。すべての権限を無制限に緩和するのではなく、必要なバックグラウンド動作を端末の設定で許可しましょう。アプリ別のルーティングでは、一覧が対象アプリを含むのか除外するのかを確認し、意図と逆の範囲にアプリを入れないようにしてください。詳しくはVPN権限、省電力、アプリ別プロキシの解説を参照してください。この章の完了条件は、取り込み範囲を説明でき、よく使う用途で動作を確認でき、無効化後に通常のネットワーク状態へ戻せることです。

日常のメンテナンス：基本構成を保ち、問題を階層ごとに切り分ける

更新前に復元可能な状態を記録する

日常のメンテナンスは、更新ボタンを押すだけではありません。現在のクライアントの種類、使用中のコア、サブスクリプショングループ、有効なノード、ルーティングプリセットを記録し、必要なローカル設定をバックアップしてください。サブスクリプションURLやエクスポートした設定には認証情報が含まれる場合があるため、安全に管理し、公開のクラウドストレージや掲示板にアップロードしないでください。バックアップを復元できるかも確認しておきましょう。少なくとも、インポート方法、ファイルに含まれる内容、復元時に現在の設定が上書きされるかを把握してください。問題が起きてから、保存先が空だったと気付く事態を避けられます。

クライアント、コア、サブスクリプション、ルールデータの更新はそれぞれ別の操作です。クライアントの更新では画面や設定管理が変わることがあり、コアの更新ではプロトコルの実装や動作に影響します。サブスクリプションの更新では提供元のノード情報が新しくなり、ルールデータの更新ではルーティングの判定内容が変わります。一度に一種類だけ更新し、起動後にログとよく使う宛先を確認してから次に進んでください。すべてを同時に変更すると、問題が起きたときにプログラム、ノード、ルールのどれを戻すべきか判断しにくくなり、一時的なネットワークの変化を更新の不具合と誤認しやすくなります。

接続できない場合は入口から順に範囲を絞る

まず基本的なネットワークが正常か確認し、次にクライアントとコアが動作しているか、アプリの通信が取り込まれているか、最後にルーティングとサーバー接続を確認します。アクセス記録がまったくない場合は入口を確認してください。記録はあるのにサーバー接続がタイムアウトする場合は、アドレス、ポート、ネットワーク経路を確認します。ハンドシェイクで拒否される場合は、認証、トランスポート、セキュリティの各パラメーターを調べてください。時刻に関係する認証や証明書のエラーでは、システム時刻も確認します。すべてのエラーを再インストールで解決しようとしないでください。インストールが故障している階層とは限りません。

同じノードでもアプリによって動作が異なる場合は、システムプロキシ、アプリ独自のプロキシ、DNS、必要なプロトコルを比較します。すべてのノードで失敗する場合は、ローカルの待ち受け、コアの起動、ネットワーク接続、共通の名前解決設定などを重点的に確認してください。特定のノードだけ失敗する場合は、そのノードのサーバー状態と専用パラメーターを確認します。同じ端末でネットワークを変えると復旧する場合は、経路の違いが調査対象になります。ただし、一度のテストだけで原因を断定せず、再現できる条件を記録してください。

速度テストの結果とログの証拠を読み解く

TCPingで分かるのは、通常、宛先ポートへの接続状況の一部です。プロキシのハンドシェイクや宛先へのリクエストが成功することを証明するものではありません。実接続の遅延はプロキシ経由のリクエストに近い測定ですが、テスト対象にも左右されます。ダウンロード速度の測定では帯域、サーバー負荷、対象サイト、ローカルネットワークの影響を受け、通信量も消費します。単一の数値だけでノードを選ばないでください。まず実際の用途で安定してリクエストを完了できるか確認し、同じ条件で複数回測定して比較しましょう。異なる測定方法の結果を混在させないようにしてください。

ログを読む際は、失敗が発生した時間帯を絞り、最後の要約メッセージではなく最初の具体的なエラーを探してください。タイムアウト、接続拒否、名前解決失敗、認証失敗は、それぞれ異なる段階の問題を示します。ログを共有する前に、サブスクリプションURL、ユーザーID、サーバー情報全体、ローカルの機密パスを削除してください。特定に必要なエラーの種類と操作順序だけを残しましょう。長すぎるログは重要な前後関係を見えにくくします。画面全体のスクリーンショットより、再現できる短い記録のほうが役立つことが多いです。

メンテナンスが終わったら、終了後の復元、システムプロキシの状態、よく使うアプリを再確認してください。動作確認済みの基本設定は残しつつ、使えなくなったノードや一時的なルールを無制限に蓄積しないようにしましょう。速度測定の仕組みはTCPing、実接続遅延、ダウンロード速度測定の違いを、よくある症状はよくある質問を参照してください。変更を記録し、問題を該当する階層に絞り込み、復旧手順を実行できることがメンテナンスの完了条件です。設定画面のスイッチをできるだけ多くオンにすることが目的ではありません。

応用へのステップ：接続できる状態から設定を説明できる状態へ

第1段階：試行錯誤を繰り返さず、再現可能なテストを行う

応用とは、すぐに完全な設定ファイルを書き始めることではありません。まず、よく使う用途について同じ条件で繰り返せるテスト方法を作りましょう。アプリ、宛先、入口を一つずつ固定し、ノード、ルーティング、名前解決の設定を記録してから、リクエストの結果を確認します。設定を変更するときは変数を一つだけ変え、結果を確認してから次に進んでください。こうすれば、特定の状況で偶然動いた組み合わせに頼らず、ほかのノードやネットワークにも応用できる知識が身に付きます。なぜ有効なのか説明できない場合は記録にとどめ、推測を一般的な結論として扱わないようにしましょう。

DNSがどの範囲で働くかを段階的に学び、システムによる名前解決、アプリ内蔵の名前解決、コアによる名前解決を区別しましょう。ドメイン名がクライアントに入る前にアドレスへ変換されるか、ルールに元のドメイン名が必要か、DNSリクエスト自体がどの出口を使うかを確認してください。最初から複雑な名前解決経路を組まず、まず各段階の担当を把握しましょう。複数の種類のアドレスを持つ宛先では、システムネットワークがそのアドレスへの接続に対応しているかも確認してください。名前解決できたことと、必ず接続できることは同じではありません。

第2段階：実際の用途を基にコアの違いを理解する

Xray、V2Fly、sing-boxのどれを選ぶかは、ノードのプロトコル、トランスポートの組み合わせ、ルーティング機能、クライアントの対応状況を総合して判断します。コアを切り替える前に維持する必要がある機能を整理し、クライアントが設定を正しく生成できるか確認してください。画面に表示される選択肢は機能の一部を反映したものにすぎない場合があり、カスタム設定がGUIの設定を迂回することもあります。切り替え後もすべての項目が同等に保たれると思い込まず、プロセスが起動するかだけでなく、接続、名前解決、ルーティングを再検証してください。

パラメーターを学ぶ際は、動作確認済みのノードを一つ選び、一項目ずつ確認します。アドレスとポートはサーバーへの接続先を示し、認証情報は利用者を確認します。トランスポート設定は通信を運ぶ方式に合わせ、セキュリティ設定は想定する保護方法を確立するために使います。TLSのサーバー名は自由に付けるメモではなく、REALITYの公開鍵も自分で生成して置き換える表示項目ではありません。各項目には対応するサーバー側の設定が必要です。こうした範囲を理解すれば、クライアントの表現能力が原因か、設定自体が不完全なのかを判断しやすくなります。

第3段階：設定構造と検証手順を学ぶ

設定ファイル全体を読むときは、まずログ、インバウンド、アウトバウンド、ルーティング、DNSの各セクションを見分け、タグの参照関係を追います。インバウンドは受け取る通信を、アウトバウンドは接続方法や通信の処理方法を記述し、ルーティングは条件を特定のアウトバウンドに結び付けます。タグは設定内部で参照する名前にすぎず、名前だけで挙動を判断できません。対応するプロトコルと設定を確認してください。異なるコアでは構造を改めて把握し、一方の形式の項目名を別の形式に当てはめないようにしましょう。

カスタム設定を作成する前に、動作中の設定を複製し、独立したテスト環境で作業してください。JSONの構文、各項目が適用される範囲、参照関係を確認してから、対応するコアで意味的な検証を行います。構文が正しいことは、形式を解析できるという意味にすぎません。項目がサポートされることも、サーバー設定と一致することも保証されません。GUIクライアントは起動時に実行用設定を再生成することがあるため、上書きされる一時ファイルを直接編集しないでください。明示されたカスタム設定の入口を使い、GUIで設定した項目のうち何が引き続き有効か記録しましょう。

自分用の最小限の操作手順書を作る

安定した手順を短い文書にまとめます。インストールとインポートの方法、通常使うモード、トラブル時に最初に確認する階層、通信の取り込みを無効にしてネットワークを復旧する方法、バックアップが必要な設定を記録してください。例外ルールには用途を、変更にはそれぞれ復旧方法を付けます。別の端末に移行する場合は、まず最小限の接続を再構築し、次にサブスクリプショングループとよく使うルーティングを復元し、最後にTUNを有効にしてください。この順序は本ページの手順に沿っており、以前の環境に隠れていた依存関係を新しいシステムへ一度に持ち込むのを防げます。

最後に、次の4つの問いに答えられる状態を目指しましょう。トラフィックはどこから入り、なぜこの出口を選び、ドメイン名はどこで解決し、失敗した場合はどう基本構成に戻すのか。説明したうえでログと実際のリクエストによって検証できれば、保守可能な設定ができています。必要に応じて用語集、よくある質問、解説ブログを参照してください。高度な機能を一度にすべて有効にする必要はありません。最短の操作手順を整理し直したい場合はクイックスタートガイドに戻り、まず動作する状態を復元してから、機能を段階的に追加しましょう。