V2Ray総合ガイドv2rayNの設定とメンテナンス

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

GUIクライアントとプロキシコアの役割

V2Rayは一般に、Project Vに関連するプロキシ技術やツール群を指し、特定のデスクトップアプリだけを意味するものではありません。v2rayNはGUIクライアントで、サーバー情報の保存、サブスクリプションの管理、実行用設定の生成、コアの起動を担います。コアはローカルポートで待ち受け、プロトコルを処理し、ルールに従ってルーティングして、外部への接続を確立します。画面が正常に開いていても、コアが正常に動作しているとは限りません。サーバー一覧に項目があっても、利用可能なサーバーが選択されているとは限りません。

V2FlyはV2Ray関連の開発を引き継いでおり、Xrayは同じエコシステムにおける別のコア開発系統です。対応プロトコルや設定の詳細は異なるため、名前が似ているだけで設定項目をすべて置き換えることはできません。v2rayNGは主にXrayコアを採用し、v2flyNGはV2Flyコアを使用します。ノードをインポートできない場合は、接続先を何度も変更する前に、クライアントとコアがそのプロトコルとトランスポートの組み合わせに対応しているか確認してください。

アプリからサーバーまでの通信経路

通常のシステムプロキシでは、まずアプリがシステムのプロキシ設定を参照し、リクエストをローカルの待ち受けポートに送ります。コアはリクエストを受け取るとルールを照合し、宛先へ直接接続するか、リモートサーバーを経由するかを決定します。その後、リモートサーバーが宛先サービスにアクセスして応答を返します。この経路には少なくとも、アプリ、ローカルの待ち受け、ルール判定、リモート接続の4段階があります。原因を切り分けるには段階ごとに確認し、アプリがプロキシを使っていないのか、コアが起動していないのか、ルールが誤っているのか、サーバーに到達できないのかを見極めます。

ノードは接続に必要なパラメーターのまとまりで、一般的な項目にはサーバーアドレス、ポート、ユーザー識別子、プロトコル、トランスポート方式、セキュリティ設定があります。サブスクリプションは、これらのパラメーターをまとめて取得するためのURLで、グループ情報や提供元からのお知らせが含まれることもあります。サブスクリプションURLはローカルプロキシのアドレスではなく、ブラウザーのプロキシポート欄に入力するものでもありません。クライアントは接続用のツールです。実際に接続するには、利用許可があり、有効なサーバー設定が必要です。

プロトコル、トランスポート、セキュリティ層

VMess、VLESS、Trojanなどは主にプロキシプロトコルを、WebSocketやgRPCなどはトランスポート方式を表します。TLSやREALITYなどは接続のセキュリティ機構に関わります。ノードにはこれら複数の層が含まれることがあり、どれか一つでも設定を誤ると接続に失敗します。サーバーアドレスとTLSで使うサーバー名は、必ずしも同じとは限りません。パスやサービス名も正確に一致させる必要があります。設定提供元の案内に従って各項目を取り込み、異なる設定例のパラメーターを混ぜないでください。

DNSはドメイン名をアドレスに変換する仕組みで、システム、アプリ、クライアント、リモート側のいずれかが処理する場合があります。名前解決を行う場所は、特にアドレスに基づくルール判定に影響します。ドメイン名を解決できたということは、アドレスを取得できたというだけです。ポートに接続できた場合も、通信経路がある段階まで確立したことを示すにすぎません。ブラウザーで最終的にコンテンツを取得できるかどうかは、ハンドシェイクのパラメーター、証明書、宛先サービス、アプリ側の設定にも左右されます。単一のテストだけでアクセス全体の成否を判断しないでください。

設定を始める前に、自分の通信経路を簡単に書き出してみましょう。どのアプリがリクエストを送るのか、どの入口を使うのか、どのルールに一致するのか、どのサーバーを選ぶのか。この4点を記録すれば十分です。最初からコアの設定項目をすべて読む必要はありません。各章では、この経路に機能を一つずつ追加していきます。知らない用語に出会ったら、入口、ルール、出口のどれに関係するかを先に判断してから、変更箇所を選びましょう。複数の場所を同時に変更して混乱するのを防げます。

クライアント選び：プラットフォーム、アーキテクチャ、画面の種類

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

デスクトップではv2rayNを優先し、OS、プロセッサーのアーキテクチャ、配布形式に応じてインストール方法を選びます。クロスプラットフォームのデスクトップ版はWindows、macOS、Linuxに対応し、WPF版はWindows向けです。どちらもサーバー、サブスクリプション、ルーティングを管理できますが、メニューの場所やウィンドウ構成、実行に必要な環境は異なる場合があります。古いスクリーンショットと画面を完全に一致させるために、インストール方法を丸ごと変える必要はありません。機能名と設定の目的を確認してください。

Windowsでは、デスクトップ版と従来のWPF版を選ぶ際、まず普段の使い方を考えましょう。複数のデバイスで近い操作感を求めるなら、デスクトップ版を試すのがおすすめです。WPF版で安定した作業環境と設定を使っている場合は、先にバックアップを取り、移行を検討してください。両方で同じ書き込み可能な設定フォルダーを共有したり、システムプロキシを同時に制御したりしないでください。画面の違いについてはデスクトップ版とWPF版の違いもご覧ください。

プロセッサーアーキテクチャとインストール形式

アーキテクチャは、プログラムがどの種類のプロセッサー向けかを示すもので、ネットワークモードとは異なります。macOSでは「このMacについて」でチップ情報を確認し、対応するインストール方法を選びます。Linuxでは下記のコマンドでマシンのアーキテクチャを確認できます。一般にx86_64はx64、aarch64はarm64に対応します。ディストリビューションのパッケージ形式も合わせる必要があります。あるディストリビューション向けのパッケージを、別の形式としてそのまま使うことはできません。インストールに失敗したら、実行ログを調べる前にこれらの基本条件を確認してください。

uname -m
cat /etc/os-release

Androidでは通常、v2rayNGを優先して選びます。最近の一般的な端末はarm64が多いものの、端末が実際に対応しているアプリのアーキテクチャを確認してください。判断できない場合やアーキテクチャ不一致の警告が出た場合は、汎用版の配布ページを確認できます。v2flyNGはV2Flyコアが必要な場合や、互換性を確認したい場合に適しています。クライアントの変更を最初のトラブル対応にするのではなく、サブスクリプションが有効か、プロトコルに対応しているか、端末の時刻とネットワークに問題がないかを先に確認してください。

移行前に確認する設定の範囲

クライアントごとの画面設定やバックアップデータは、別のクライアントにそのまま読み込めるとは限りません。ノード共有リンクは、通常、設定フォルダー全体をコピーするより移行しやすいものの、双方のプロトコル項目への対応状況に左右されます。サブスクリプションのグループ、ルーティングルール、ショートカット、画面設定は、クライアント固有の設定である場合があります。移行する際は元のクライアントを残し、プロキシ制御を解除してから新しいクライアントでノードを一つ検証してください。基本の通信経路を確認した後で、複雑なルールを移行しましょう。

インストール方法はクライアントのダウンロードページをご覧ください。選ぶ順番は、OS、アーキテクチャ、画面の種類、最後に個人の好みです。組織管理端末を使っている場合、管理者権限がない場合、仮想ネットワークアダプターをインストールできない場合は、アプリ単位のプロキシだけで利用できるかも事前に検討してください。通常のプロキシを使えるからといって、必ずTUNを有効にできるわけではありません。権限の制限を導入条件として考えるほうが、インストーラーを何度も変えるより適切な方法を見つけやすくなります。

インストールと設定：作業フォルダーと初回起動

管理しやすいインストール先を用意する

まずダウンロードページで適切なインストール方法を選びます。インストーラーは案内に従って保存先を指定してください。圧縮ファイルの場合は、すべて展開してから展開先のフォルダーでプログラムを起動します。圧縮ソフトのプレビュー画面から直接起動すると、一時展開先にコアやリソースがなかったり、書き込み権限がなかったりする可能性があります。作業フォルダーは判別やバックアップがしやすい場所にし、異なるビルドのファイルを混在させないでください。ポータブル版を使う場合は、設定が実際に保存される場所も確認しましょう。すべてのデータが実行ファイルの隣にあるとは限りません。

Windowsでv2rayNを初めて起動したとき、実行コンポーネントが不足しているという警告が出た場合は、案内に従って対応するアーキテクチャのランタイムをインストールし、クライアントを再起動してください。システムライブラリを手当たり次第にコピーして依存関係を解決しようとしないでください。プログラムがすぐ終了する場合は、クライアントのフォルダーにあるログやシステムイベントを確認し、依存関係の不足、権限不足、セキュリティソフトによるブロックを切り分けます。詳しくはWindowsでのインストールと初回起動時のトラブル対処をご覧ください。

コアと待ち受け状態を確認する

画面が起動したら、ログ欄に起動失敗、ファイルが見つからない、ポートのバインド失敗などが記録されていないか確認します。ノードがあり、サービスを有効にして初めて、コアが実際に待ち受けているかを調べられます。一般的なローカル接続先はループバックアドレスと待ち受けポートの組み合わせですが、ポート番号は現在の設定に従ってください。古いガイドのポート番号は仕組みを理解するための例にすぎず、現在の設定をその値で上書きしないでください。ビルドによっては、個別の2種類のポートではなく、統合された接続先を使うこともあります。

設定 → パラメーター設定 → Core基本設定付近で、ローカル待ち受けに関する項目を確認してください。SOCKSとHTTPでは対応するアプリの種類が異なります。アプリにプロキシを設定するときは、プロトコル、アドレス、ポートを一致させましょう。初回設定ではループバックアドレスでの待ち受けを維持してください。他の端末にサービスを提供する必要がある場合に限り、LANからの接続を検討します。LANに公開するとアクセス可能な範囲が広がるため、アクセス制限、ファイアウォール、信頼する端末の範囲もあわせて設定してください。

netstat -ano | findstr :10808

上記はWindowsでポートの使用状況を確認するコマンド例です。実際に調べるときは、ポート番号を設定画面にある値に置き換えてください。出力の最後の列からプロセスを特定できます。所有者を確認してから、停止するかポートを変更するかを判断してください。見慣れないシステムプロセスを、ポートを使っているという理由だけで終了しないでください。別のプロキシソフトが使用している場合は、重複して起動したインスタンスを終了します。正常なアプリが使用している場合は待ち受けポートを変更し、プロキシを手動設定しているアプリの値も合わせて変更してください。詳しくはローカルポートの競合を解消する方法をご覧ください。

その他のデスクトップ・モバイル端末

macOSではインストール後、システムの案内に従ってアプリの起動を許可します。インストール元とアプリの提供元を確認し、システム保護を全体的に無効にする方法で個別のアプリを許可しないでください。Linuxでは、ディストリビューションに合ったパッケージ管理ツールでインストールします。依存関係の警告が出たら、不足しているコンポーネントを確認してください。デスクトップ環境、グラフィック表示のバックエンド、トレイ機能は画面の動作に影響する場合があります。ウィンドウを閉じてもプロセスが終了するとは限らないため、トレイとプロセス一覧でバックグラウンド動作を確認しましょう。

Androidにクライアントをインストールして初めて接続するとき、通信の入口を作成するためにシステムのVPN権限を求められることがあります。有効な設定をインポートしてから、表示された許可画面が現在のアプリのものか確認してください。初回の接続確認では、ネットワークを制御する他のツールを終了し、複数の入口が競合しないようにします。初回起動の完了基準は「アプリが開いたこと」ではありません。設定の場所を見つけられること、起動ログを読めること、サービスの稼働状態を把握できることが重要です。次の章でサブスクリプションを追加する準備を整えましょう。

サブスクリプション管理：追加・更新・グループ分け

グループを作成してからサーバーを更新する

サブスクリプションURLには個人のアクセス識別情報が含まれることが多いため、認証情報として扱ってください。許可を得て利用している設定提供元からのみURLを取得し、完全なリンクを公開コメント、スクリーンショット、オンライン変換サイトに掲載しないでください。ブラウザーでURLを開けても、返された内容が現在のクライアントで使えるとは限りません。アカウントページ、エラーメッセージ、別形式のデータが返る場合もあります。追加する前にURLが完全で、説明文、改行、チャットアプリが付けた句読点などが混ざっていないことを確認してください。

v2rayNでサブスクリプショングループ → サブスクリプショングループ設定を開き、新しいグループを追加して、見分けやすいメモとサブスクリプションURLを入力します。保存したら該当グループを更新するか、すべてのサブスクリプションを更新する操作を実行してください。ビルドによっては、グループ操作がメニューや一覧のツールバーにあります。まずURLを保存してから更新する点が重要です。URLを貼り付けただけでは、サーバー一覧にすぐ表示されないことがあります。メモを追加しただけでは、ノードは作成されません。

更新が終わったらログを確認し、一覧で対象のグループを選んでいるかを確かめます。更新成功と表示されても一覧が空の場合は、内容の形式に対応していない、URLからエラーページが返された、検索やフィルターですべてのサーバーが隠れている、といった可能性があります。既存の設定をすぐに削除せず、まず検索やフィルターを解除してから該当グループに切り替えてください。同じURLが別の端末では正常に使える場合、両方のクライアントの対応機能や更新時刻を比較すると、互換性の差かネットワーク取得の失敗かを判断しやすくなります。

ノードの更新と手動変更の関係

サブスクリプション提供元はサーバーアドレス、メモ、パラメーターを変更することがあり、次回の更新時にクライアントのルールに応じて一部の項目が再作成または置換されます。サブスクリプションのノードを直接編集しても、その変更が保持されるとは限りません。試す必要がある場合は、先にノードを手動設定として複製し、用途をメモしてからパラメーターを一つ変更してください。更新後、古いメモだけを根拠に同じ設定だと判断しないでください。テストが終わったら一時的な複製を削除し、期限切れの設定を選んでしまわないようにしましょう。

複数のサブスクリプションは、すべてを一つのグループに入れてメモで見分けるのではなく、提供元や用途ごとにグループを分けてください。キーワードフィルターは表示を絞り込むためのもので、ノードの削除やルーティングの変更を意味しません。フィルター後に利用するサーバーを設定するときは、想定しているグループのノードか確認してください。更新後に選択中の項目が変わっていたら、もう一度確認しましょう。整理方法についてはサブスクリプショングループとサーバーの絞り込みをご覧ください。

更新に失敗したときの切り分け

更新に失敗したら、まず取得処理でエラーが起きた段階を確認してください。接続タイムアウトはURLへの通信経路に問題があることを示します。取得内容を解析できない場合は、レスポンスが本当にサブスクリプションデータか確認しましょう。クライアントに直接更新とプロキシ経由の更新がある場合は、現在の通信経路に応じて選びます。有効なプロキシをまだ確立できていないのにプロキシ経由の更新を強制すると、「接続するには更新が必要だが、更新には接続が必要」という状態になりかねません。まず利用可能な設定で取得経路を確認してください。

更新ボタンを何度も押しても、問題の解決にはなりません。まずサブスクリプションのアカウントとURLの状態を確認し、次にネットワーク、システム時刻、エラーログを調べてください。サーバー側が一時的に利用できない場合は、既存の有効な項目を残しておくほうが、削除して作り直すより安全です。ログを共有する前に、完全なURL、ユーザー識別子、サーバー情報を隠してください。項目ごとの確認にはサブスクリプションの更新失敗・解析結果が空のときの確認リストを参考にしてください。対処後は一度だけ再試行し、エラーに変化があったか記録します。

この段階の完了条件は、少なくとも一つのグループを更新でき、その中の設定を見つけ、どのように利用するサーバーを設定するか把握できていることです。サブスクリプションの更新成功とノードへの接続成功は別の結果です。前者は設定を取得できたことを示し、後者はサーバー、プロトコル、入口の設定にも左右されます。この違いを理解しておけば、次の章でシステムプロキシを調べる際に、設定の取得問題と実際のアクセス問題を混同せずに済みます。

プロキシモード：システムの入口と接続確認

システムプロキシは端末全体の通信をすべて中継する機能ではない

利用するサーバーを選び、コアが起動していることを確認してから、システムプロキシを設定します。v2rayNではメイン画面またはトレイのシステムプロキシ関連メニューから、自動設定を選べます。項目名は現在の画面に従ってください。この操作でローカルプロキシアドレスがシステム設定に登録され、その設定に従うアプリがプロキシを使います。独自のネットワーク機能を持つアプリや、アプリ内でプロキシ方式を固定している場合は、システムプロキシを有効にしても直接接続を続けることがあります。

システムプロキシを解除すると、通常はシステム側の入口だけが元に戻り、コアの待ち受けが停止するとは限りません。ローカルポートを手動で指定したアプリは、その後もクライアントを経由する可能性があります。反対に、クライアントを直接終了しても、環境によっては書き込まれた設定がすべて自動で消えるとは限りません。そのため、トレイアイコンだけで判断せず、システムプロキシ、コアの稼働状況、アプリ側の設定を個別に確認してください。終了する前にシステムプロキシを解除してから通常の方法で終了すると、無効になったローカルポートへアプリが接続し続けるのを防ぎやすくなります。

アプリの手動プロキシとポートの対応

アプリが手動プロキシに対応している場合、ホストには通常127.0.0.1を指定し、ポートにはクライアントが現在待ち受けている番号を入力して、HTTPまたはSOCKSの対応する種類を選びます。このループバックアドレスが示すのは自分の端末であり、リモートのノードサーバーではありません。ノードのポートを一般のアプリのプロキシ欄に直接入力しても、通常は接続できません。アプリはクライアントの代わりにノードのプロトコルや認証を処理しないためです。他の端末と共有する場合は、ループバックアドレスをそのまま使うこともできません。

初回の接続確認では、結果を再現しやすいアクセス先を一つ選び、プロキシを無効にした状態で試した結果を記録してから、システムプロキシを有効にして再試行します。アプリに接続プールや古いページのキャッシュが残っている場合は、完全に終了して再起動してください。クライアントに該当する接続記録があるか、通信の出口が適切かを確認します。リクエストがクライアントに届いていなければ、リモートサーバーを変更する前にアプリの入口を調べます。リクエストが届いて失敗した場合に、ルーティングと出口の経路を確認してください。

テスト結果と実際の使用感を分けて考える

一覧の遅延テスト、接続テスト、実際のウェブサイトへのアクセスは、対象、プロトコル、計測方法が異なる場合があります。一度のテスト結果だけであらゆるサイトの速度を判断したり、動画、ダウンロード、リアルタイムアプリが必ず正常に動くと結論づけたりすることはできません。テストに失敗した場合も、原因を確認してください。テスト用サーバーに到達できないことと、ノードに接続できないことは別の問題です。同じ端末、同じ接続先、同じモードで比較して初めて、結果を参考にできます。

ブラウザーは正常でも別のアプリが失敗する場合は、そのアプリがシステムプロキシに対応しているか、独自のプロキシ設定が有効になっているか、古い環境変数が残っているかを確認してください。開発ツール、ターミナル、デスクトップアプリの設定は、それぞれ独立していることがよくあります。すべてのアプリに一度にプロキシを設定すると、どの入口が有効だったのか分からなくなります。まず一つのアプリを明示的な設定で動作させ、その後、他のアプリの元の設定を段階的に戻すと、設定の競合を特定しやすくなります。

システムプロキシを有効にした後、設定に従うアプリがすべてアクセスできなくなった場合は、ローカルポートが待ち受けているか、利用中のサーバーが削除されていないか、コアのログにエラーが出ていないかを確認してください。一時的にシステムプロキシを解除し、通常のネットワーク接続が戻るか確認することは、ローカルの入口の問題とネットワーク自体の問題を切り分けるうえで重要です。簡単な疑問はよくある質問をご覧ください。この章を終える頃には、リクエストがクライアントに届いているかどうかを説明できるようになります。

ルーティング：ルールの照合順序とDNSの条件

まずプリセットを使い、必要に応じて例外を追加する

ルーティングは、コアに届いたリクエストを分類し、直接接続、プロキシ経由、ブロックなどの処理方法を選びます。v2rayNではルーティング設定から、たとえば中国本土を迂回（Whitelist）のようなプリセットを選べます。この種のモードは通常、ドメインやアドレスのルールに基づいて直結とプロキシを振り分けますが、実際の対象範囲はルールの内容とデータファイルによって異なります。プリセット名は用途の目安にすぎず、特定のドメインがどのルールに一致するかは判断できません。

初めて使う場合は用途に合ったプリセットを一つ選び、よく使うアプリを確認してから、明確な理由のある例外を少数追加してください。すべての通信をプロキシにするモードに一時的に切り替えてアクセスできるようになった場合は、元のルールで別の出口が選ばれている可能性があります。ただしログでも確認してください。この比較結果だけを根拠に「常にすべてをプロキシにするのが最適」と判断しないでください。ローカルサービス、LAN内のアドレス、一部のアカウント関連サービスは、直接接続が必要な場合があります。

照合順、適用範囲、該当ルールがない場合の動作

一般的なルールは上から順に確認され、最初に一致した有効なルールで処理が決まります。詳細はコアとクライアントが生成する設定に従ってください。特定ドメインの例外は、広い範囲を対象とする分類ルールより前に置かないと、適用されないことがあります。ルールを追加するときは、条件、出口、挿入位置、期待する結果を記録しましょう。ドメインだけを登録して出口を正しく選んでいない場合や、対象をすでに含むルールの後ろに例外を置いた場合は、「ルールが効かない」と誤解しやすくなります。

完全一致のドメイン指定とドメインのサフィックス指定では、対象範囲が異なります。一つのホストだけを対象にするなら、ドメイン全体に適用される書式を誤って使わないようにしてください。ウェブサイトはログイン、画像、APIなど別のドメインにも依存する場合があり、トップページが表示できても関連リクエストがすべて正常とは限りません。失敗したリクエストを確認し、必要な条件だけを追加しましょう。無関係なドメインを大量に例外へ追加しないでください。入力欄がどの構文に対応しているか分からない場合は、まず項目の説明を確認します。コアの生の設定項目を、どの画面にもそのまま貼り付けないでください。

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

上記はXrayのルーティングルールオブジェクトの例であり、実行可能な設定全体ではありません。完全一致のドメイン、ドメインのサフィックス、出口タグの関係を示しています。設定ルールの配列に追加され、directという名前の出口が存在する場合にのみ、示した動作になります。例のドメインは書式の説明用です。GUIクライアントで設定を管理する場合はルーティング編集画面を優先してください。自動生成ファイルを直接編集すると、次回の起動やノード切り替え時に手動変更が上書きされることがあります。

DNSとアドレスルールの関係

ドメインベースのルールには、コアがドメイン情報を認識できることが必要です。アドレスベースのルールは、実際に取得したアドレスに依存します。アプリが先に名前解決を行い、アドレスだけを送信すると、ドメインルールの照合に必要な情報が不足する場合があります。設定によってはコアが追加で名前解決することもあります。スニッフィングは一部のプロトコルでドメイン情報の取得を補助できますが、すべての通信から情報を復元できるわけではなく、互換性への配慮も必要です。スニッフィングを有効にすれば分流の問題がすべて解決する、と考えないでください。

ルーティングを調べるときは、対象と利用中のサーバーを一つに固定し、元のモードを記録してから、対象範囲が最小限の例外を一つだけ一時的に追加します。接続ログで対象と出口を比較し、必要であればアプリのキャッシュを消して接続し直してください。ルールを保存しても、既存の長時間接続が必ずすぐ再接続されるとは限りません。テストが終わったら、効果のなかった例外を削除し、不要なルールが増えないようにしましょう。安定したルール構成では、各ルールが必要な理由を説明できることが重要です。場当たり的な追加を続けて一時的な動作を保つ構成は避けてください。

TUNモード：通信の制御範囲と復旧手順

通常のプロキシが使えることを確認してから有効にする

TUNは仮想ネットワークインターフェースと関連するルーティング設定を使い、条件に合う通信をクライアントへ取り込みます。通常のシステムプロキシを使えないアプリに便利ですが、すべてのプロトコル、ネットワークアダプター、ネットワーク環境で必ず動作するわけではありません。先に通常のプロキシで接続を確認しておけば、失敗したときに問題が通信の取り込み段階にあるかを判断できます。ノード自体が接続できない状態でTUNを有効にしても、調査すべき段階が増えるだけで、出口の設定ミスは解消されません。

v2rayNでTUNモードのスイッチと関連設定を見つけ、現在のビルドで必要な権限やコンポーネントを確認してください。有効にする際、インターフェースの作成やシステムルートの変更のために権限の昇格を求められる場合があります。提供元が明確なクライアントに、必要な範囲の権限だけを与えてください。組織管理端末、制限付きアカウント、特殊なデスクトップ環境では、こうした操作が禁止されていることがあります。端末の管理方針に従い、セキュリティ設定全体を変更して制限を無理に回避しないでください。

入口の重複とルーティングの競合

初めて有効にする際は、ほかの条件を変えず、TUNだけを追加してください。システムプロキシを残す必要があるかは、使用中のクライアントの実装と説明に従って判断します。複数の入口を重ねるとリクエスト経路が変わる場合があるため、設定を切り替えながら結果を判断しないでください。ほかのVPN、仮想ネットワークアダプター、ルートを制御するソフトウェアも一時的に終了します。複数のツールが同時にデフォルトルートを変更すると、通信経路や復旧の順序が把握しにくくなります。

LANへのアクセスは、TUN有効化後すぐに確認すべき項目です。ルーターの管理画面、プリンター、ファイル共有、ローカルの開発サービスなどを試してください。これらに接続できない場合は、プライベートアドレス、ループバック、ローカルサブネットの迂回設定を確認し、すべてのローカルアドレスをリモートへ送らないようにします。複数のネットワークアダプター、テザリング、仮想マシンのネットワークも、異なるサブネットを使う可能性があるため個別に確認してください。適切な制御範囲は実際のネットワーク構成に基づいて決め、他の人の除外リストをそのまま流用しないでください。

DNS、UDP、アプリの動作

TUNでは、DNSリクエストが通常とは異なる経路を通ることがあります。アプリ独自の暗号化DNS、システムに残ったキャッシュ、想定した入口を通らないクエリなどによって、通常のプロキシ使用時と結果が異なる場合があります。まずドメインを解決できるか、DNSリクエストがどこへ送られているかを確認し、その後に接続が想定した出口へルーティングされているかを調べてください。DNSの上流、ルーティングモード、TUNのネットワークスタックを同時に変更しないでください。一度に一つの条件だけを変更すれば、正常だった状態へ戻すことができます。

一部のリアルタイムアプリやプロトコルはUDPを使用します。正常に動くかどうかは、ローカルでの取り込み方法、コアの機能、ノード設定、リモートサービスにも左右されます。ブラウザーでページを表示できても、同じ経路のUDPが利用できるとは限りません。問題が起きているアプリで個別に検証し、該当する接続やエラーを確認してください。特定の種類のアプリだけで問題が起きる場合は、そのアプリのトランスポートやDNSの特徴を比較し、TUN全体の障害だと決めつけないでください。

スイッチを無効にしても問題が続く場合は、クライアントを通常の方法で終了し、仮想インターフェース、以前のプロキシ設定、他のツールの接続状態がシステムに残っていないか確認してください。まずクライアントの復旧機能を利用し、必要に応じてシステムを再起動します。用途の分からないネットワークアダプターやルートをむやみに削除しないでください。基本のネットワーク接続が復旧したら、通常のプロキシを確認してからTUNだけを有効にします。最初に異常が起きたのがインターフェースの作成、DNSクエリ、宛先への接続のどの段階かを記録しておくと、次に確認する範囲を絞り込めます。

この章の完了条件は、次の3点です。制御対象のアプリが使えること、ローカルネットワークのサービスに引き続きアクセスできること、モードを無効にした後にネットワークが復旧すること。最初の2点を満たしても、終了後にネットワークを復旧できなければ、日常的な標準設定として使うのは適切ではありません。TUNは用途が明確な入口として使い、すべての端末で必ず有効にする機能とは考えないほうが、把握しやすく元に戻せるネットワーク環境を保てます。

日常のメンテナンス：バックアップ、更新、トラブル記録

設定のバックアップと各種更新を分けて考える

安定して動作するようになったら、まずクライアントの設定保存場所を確認してからバックアップを行います。必要なサブスクリプショングループ、手動ノード、ルーティング、個人設定を保存しましょう。フォルダーをそのままコピーできるかは、現在のインストール方法によって異なります。コピーする前にクライアントを終了し、データベースや設定ファイルへの書き込みが続いていないことを確認してください。サブスクリプションURLやユーザー識別子は機密情報です。バックアップファイルへのアクセスを制限し、共有端末や公開領域に無条件で同期しないでください。

クライアント、コア、サブスクリプション、ルールデータの更新は、それぞれ別の操作です。クライアントを更新すると画面や設定形式が変わる可能性があり、コアの更新はプロトコルの動作に影響する場合があります。サブスクリプションの更新ではサーバーのパラメーターが変わり、ルールデータの更新では分類の判定結果が変化します。問題が起きたとき、直前にどの更新を行ったか分かるようにしてください。同じメンテナンス中にクライアント、コア、ノード、ルールを一度に変更すると、結果の変化を引き起こした原因を特定しにくくなります。

更新前後の確認手順

更新前に現在のインストール方法、利用中のサーバー、プロキシの入口、ルーティングモードを記録し、復元可能な設定をバックアップしてください。クライアントを通常の方法で終了してから更新し、バックグラウンドのコアがファイルを使用したままにならないようにします。更新後は元のシンプルな設定で確認し、すぐに新しい複雑なルールをインポートしないでください。設定の移行に関する案内が出た場合は、内容を先に確認します。新しい設定形式を古いビルドで読み込めるとは限らないため、プログラムを以前のバージョンに戻す場合は、対応する古い設定のバックアップも復元してください。

自動起動や自動接続の設定も、基本の通信経路が安定してから行います。起動時にはネットワークがまだ準備できていないことがあり、サブスクリプションの更新や接続に失敗しても、ノードが無効とは限りません。ネットワークの準備が整ってから手動で再試行し、その結果を見て起動順序を検討してください。Android端末でバックグラウンド接続が頻繁に切れる場合は、クライアントに対するバッテリー最適化やバックグラウンド動作の制限を確認します。必要な範囲だけを変更し、一つのアプリのために端末全体の管理機能を無効にしないでください。

段階ごとにログを読む

ログを確認するときは、最後の行だけでなく、関連するエラーが最初に記録された箇所を探してください。起動時のポートバインド失敗は、その後のアプリからのリクエストすべてに影響します。一方、サブスクリプションの取得エラーは、すでに存在するノードには影響しない場合があります。接続タイムアウト、名前解決の失敗、認証エラー、ハンドシェイクの失敗は、それぞれネットワーク、DNS、設定項目の観点から切り分けてください。同じエラーメッセージでも対象が異なる可能性があるため、時刻、宛先、操作手順とあわせて読みます。

操作：指定したサブスクリプショングループを更新
入口：通常のシステムプロキシ、TUNは無効
状況：更新に失敗したが、既存のノードには接続できる
比較：システムプロキシを解除してから再度更新
記録：該当する時間帯のエラーを残し、機密性のあるアドレスを削除

上記の記録形式には実際の認証情報が含まれていないため、自分のトラブル対応を整理するのに使えます。共有する際は、完全なサブスクリプションURL、サーバーのドメイン名やアドレス、ユーザー識別子、個人のフォルダー名を隠してください。ログにアクセス先が含まれる場合も、必要に応じて情報を伏せます。前後の状況が分からないエラー画像だけを送らないでください。クライアントの種類、OS、操作手順、最後に正常だった状態を説明すると、問題の再現に役立ち、スクリーンショットを何枚も送るより効果的です。

終了時と復旧時の定期確認

通常は、不要になったTUNを先に無効にし、次にシステムプロキシを解除してから、クライアントを正常に終了します。アプリにローカルプロキシを手動設定している場合は、その設定も元に戻してください。システム設定を解除しても、アプリがローカルポートへ接続し続ける可能性があります。ネットワークを切り替えた後に問題が起きたら、まず基本のネットワーク接続と認証ページが利用できるかを確認しましょう。公衆ネットワークのログインが済んでいない場合、プロキシソフトでネットワーク自体への接続条件を代替することはできません。

メンテナンスでは、正常に動作する基準状態を保つことが重要です。利用できるサーバーが一つ、分かりやすい入口が一つ、説明できるルーティングが一組、復元可能なバックアップが一つ。この基準に戻してから、必要な機能を一つずつ再設定してください。一時的なノード、期限切れの例外、重複したグループを定期的に整理すると、選択ミスやルールの競合を減らせます。問題を特定の種類に分類できたら、症状に応じてよくある質問を確認しましょう。毎回、再インストールから始める必要はありません。

応用テクニック：設定の理解と一項目ずつの検証

まず解決したい問題を明確にする

応用とは高度なスイッチをすべて有効にすることではなく、リクエストが設定をどう通過するか説明できるようになることです。たとえば、ある開発ツールだけに個別のプロキシが必要、特定のドメインを必ず直接接続したい、あるアプリの通信をTUNで取り込みたい、といった具体的な要件を書き出します。目的を明確にしてから、対象を絞った設定を選びましょう。通常のシステムプロキシで要件を満たせるなら、メニューにあるという理由だけで仮想ネットワークアダプター、独自DNS、複雑なマルチ出口ルールを有効にする必要はありません。

おすすめの学習順は、現在の設定を読み取る、生成される設定を理解する、ルールを一つ検証する、最後にカスタム設定を調べる、です。クライアントは通常、ノード、ルーティング、共通パラメーターを基にコアの設定を生成するため、生の設定ファイルだけがすべての設定元ではありません。まずGUIの項目に対応する設定フィールドを見つけ、保存前後の違いを確認して、その影響範囲を調べてください。実行ファイルの設定をまるごと置き換えると、画面上の状態と実際の設定が食い違い、後のメンテナンスも難しくなる可能性があります。

インバウンド、アウトバウンド、タグ参照を理解する

生の設定では、インバウンドが通信を受け取り、アウトバウンドがその後の接続を確立し、ルーティングが条件に合うリクエストの送信先を振り分けます。タグは各要素の参照に使われ、タグ名自体に決まった特別な意味はありません。存在しないアウトバウンドのタグを参照したり、混乱しやすいタグ名を重複して使ったりすると、設定が意図したとおりに動作しません。設定例を読むときは、定義と参照の両方を確認し、関係がありそうな一部分だけをコピーしないでください。

以下は単独で読めるXrayの最小設定例です。ローカルにSOCKSの入口を作り、受け取ったリクエストを宛先へ直接接続します。リモートのプロキシノードは含まれておらず、サブスクリプションの代わりにもなりません。ポートが未使用で、起動中のクライアントの入口と重複しないことを確認してください。この例は設定項目の関係を理解するためのものです。日常の設定はGUIクライアントで管理することをおすすめします。テストが終わったらテスト用インスタンスを停止し、バックグラウンドに待ち受けが重複して残らないようにしてください。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10818,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ]
}

一項目ずつ検証する

テストではアプリ、宛先、ネットワーク条件を固定し、一度に一つの項目だけを変更して、元の値を記録します。ドメインルールを検証するなら、同時にサーバーやDNSを変えないでください。TUNがローカルサービスに影響するか調べるなら、ルーティングは変えず、入口だけを切り替えます。結果が予想と違った場合は、まず元の値に戻してから次の比較方法を考えます。一見時間がかかるようでも、複数の変更が互いに影響して、どれが実際に効いたのか分からなくなるのを防げます。

複雑な要件は、それぞれ単独で確認できる小さな作業に分けてください。まずアプリにローカルプロキシを明示的に設定し、次に対象ドメインの例外を追加し、最後にネットワークを切り替えたときの動作を確認します。各段階に成功条件と元に戻す方法を用意してください。接続プール、DNSキャッシュ、長時間接続による反映の遅れは、設定の保存を繰り返すのではなく、アプリを再起動するか接続を作り直して比較します。説明できないルールを大量に管理するより、シンプルなテスト設定を残すほうが役立ちます。

拡張を止めて基準状態に戻す

サーバー側のプロトコルパラメーター、アカウントの状態、リモートサービスの制限が原因の場合、クライアント側でできることは、状況とログを正確に記録することが中心です。リモート側のエラーを覆い隠すために、ローカルのルールを際限なく追加しないでください。設定提供元に問い合わせる際は、プロトコルの種類、失敗した段階、実施済みの比較結果を伝え、個人の認証情報は削除します。対応が確認されていない機能については、クライアントとコアの対応状況を確認してください。名前が似ているだけで互換性を判断しないでください。

このガイドを終えると、入口、ルール、出口の観点から問題を説明し、クライアントに属する設定、コアに属する設定、サーバー側の対応が必要な設定を見分けられるようになります。接続手順をもう一度確認する場合はクイックスタートガイドへ、インストール形式を選び直す場合はクライアント選びガイドとダウンロードページをご覧ください。シンプルで使える基準状態を維持し、実際の要件に応じて一つずつ拡張することが、このガイドの基本的な活用方法です。