V2Ray設定完全ガイド

1. 基本概念と通信の流れ

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

V2Rayは通常、Project Vに関連するプロキシ技術のエコシステムを指し、接続先を含む単独のアカウントサービスではありません。GUIクライアントはサーバー情報やサブスクリプションを管理し、設定を生成してコアを起動します。コアは受信接続、プロトコル通信、ルーティング規則を処理します。接続先のサーバーは、定められた条件を満たす接続を受け付け、リクエストを転送します。クライアントをインストールしただけではローカルのツールが用意できただけです。通信経路を確立するには、利用権のあるサーバーの設定情報も必要です。

V2FlyとXrayは関連エコシステム内の別々のコアプロジェクトで、対応するプロトコル拡張や設定の詳細は完全には一致しません。v2rayNはデスクトップでの操作を支援し、v2rayNGはAndroidでXray設定を使う場合によく利用されます。v2flyNGではV2Fly系を選択できます。クライアントで項目をインポートできても、使用中のコアがすべての設定に対応しているとは限りません。互換性を判断するには、トランスポート、セキュリティ層、拡張パラメーターも確認してください。

サーバー設定を3つの層に分けて理解する

1つ目はVMess、VLESS、Trojan、Shadowsocksなどのプロキシプロトコルで、接続の識別方法とリクエストの形式を定めます。2つ目はTCP、WebSocket、gRPCなどのトランスポート方式で、プロトコルのデータをどう運ぶかを定めます。3つ目はTLS、REALITY、サーバー名などのセキュリティ関連設定です。この3層の組み合わせはサーバー側の設定と一致させる必要があります。アドレスとポートが正しいからといって、ほかの項目を任意に置き換えてはいけません。

サーバー名、接続先アドレス、リクエスト先はそれぞれ異なる概念です。接続先アドレスはリモートサービスを見つけるために使い、TLSのサーバー名はハンドシェイク時の認証に使われます。リクエスト先はアプリが実際にアクセスするドメインです。これらが同じ場合もあれば、異なる場合もあります。共有リンクのサーバー名を書き換えて「ドメインを直そう」とすると、かえってハンドシェイクに失敗することがあります。設定に疑問があれば、提供元の説明と項目を一つずつ照合してください。

通信の流れに沿って問題箇所を特定する

一般的なリクエストは、アプリ、本機の待ち受けポート、コアのルーティング、リモートサーバーを経由し、最後に接続先のサービスへ到達します。システムプロキシを利用するかどうかは、アプリ側の対応状況によります。ローカルプロキシに届いたリクエストも、その後コアのルールに従って出口が選ばれます。DNSはドメインをアドレスに変換する役割を担い、アプリ、OS、コアが関与する場合があります。これらをひとまとめに「プロキシのスイッチ」と考えると、問題のある箇所とは別の設定を何度も変更してしまいがちです。

トラブルシューティングでは、まずどの段階で失敗したかを特定します。クライアントが起動しない場合は、実行環境とポートを確認します。ブラウザーの通信がクライアントに届かない場合は、アプリ側のプロキシ設定を確認します。ログにハンドシェイクエラーがある場合は、プロトコルの設定と時刻を確認します。一部のドメインだけ問題が起きる場合は、ルールと名前解決の結果を調べます。ログのエラーは発生時刻と合わせて判断してください。バックグラウンドアプリの失敗が、現在開いているページと無関係なこともあります。

再現可能な最小構成を作る

設定を始めるときは、利用可能と確認できたサーバーを1つ、アプリの接続方法を1つ、シンプルなルーティング設定を1つだけ使います。不要な自動切り替えは一時的に無効にし、複数のネットワーク接続方式を同時に有効にしないでください。こうすれば、テストごとに変更する条件を1つに絞れ、結果を判断しやすくなります。接続に成功したら、クライアント名、コアの選択、待ち受けポート、ルーティングモードを記録しましょう。「昨日は使えた」という情報より、こうした記録のほうが状態の再現に役立ちます。

次の章へ進む前に、サーバー設定をどこから取得したか、どのプログラムがコアを起動するか、テスト対象のアプリがどのローカルポートに接続するかを説明できる状態にしておきましょう。まだ不明な点があれば、複雑な振り分けを設定する前に情報源と設定を整理してください。基本が分かったら、次章でプラットフォームに合うクライアントを選びます。その後、サブスクリプション、ドメインルール、仮想ネットワークインターフェースを段階的に追加し、それぞれの段階で元に戻せるテスト結果を残します。

2. クライアント選びとプラットフォームの準備

デスクトップではv2rayNを第一候補に

Windows、macOS、Linuxのデスクトップ環境では、まずv2rayNから始めると、サーバー、サブスクリプショングループ、システムプロキシ、ルーティングを同じ画面で理解できます。まずクライアントのダウンロードページでプラットフォームを選び、プロセッサーのアーキテクチャとインストール形式を確認してください。同じプラットフォーム向けでも、インストーラーを相互に使えるとは限りません。アーキテクチャを間違えると起動できなかったり、追加の互換環境が必要になったりすることがあります。

Windows版にはクロスプラットフォーム対応のデスクトップ版と、従来の操作性を維持するWPF版があります。初めて使う場合はデスクトップ版から試せます。従来の画面に慣れている場合は、用途に応じてWPF版を選んでもよいでしょう。画面構成は異なるため、チュートリアルのスクリーンショットだけを頼りにボタンを探さないでください。移行前に必要な設定をエクスポートし、新しい画面でサーバーをインポートできることを確認してから、既存の環境を置き換えるか判断しましょう。

チップとディストリビューションに合わせてインストール形式を選ぶ

macOSでは、まずシステムのデバイス情報でチップの種類を確認します。Apple Siliconはarm64、Intelはx64に対応します。パソコンの外観や購入時期から推測しないでください。インストール後は、正常に動作するための権限がアプリに付与されていることも確認します。TUNの利用には通常の起動とは異なる権限が必要なため、画面が開けるだけでネットワーク機能の準備がすべて整ったとは限りません。初回のテストでは、まずシステムプロキシで基準となる状態を作ってください。

Linuxでは、プロセッサーのアーキテクチャ、ディストリビューションのパッケージ管理方式、デスクトップセッションを合わせて確認します。debとrpmは異なるパッケージ体系、arm64とx64は異なる命令セットに対応します。パッケージのインストール後に、トレイアイコンやシステムプロキシの挙動が違う場合は、デスクトップ環境の対応状況も調べてください。アプリごとにローカルプロキシを設定すると、動作を検証しやすいことがあります。トレイアイコンの有無だけでコアの状態を判断しないでください。

Androidでは必要なコアを基準に選ぶ

Androidではまずv2rayNGを検討し、V2Fly関連の設定を使う場合はv2flyNGも候補にします。比較的新しい一般的なデバイスの多くはarm64を選べます。アーキテクチャが分からない場合は、システム情報を確認するか、ダウンロードページの説明に従って汎用版を検討してください。接続テストとして2つのクライアントを同時に起動するのは避けましょう。システムのVPNインターフェースを奪い合い、後から起動した接続が先の接続を置き換えることがあるため、結果を判断しにくくなります。

AndroidクライアントがシステムのVPNインターフェースを使って通信を取り込む際、OSの許可画面が表示されます。これはローカルのネットワーク入口を作成する許可であり、リモートサーバーが利用可能だとOSが確認したわけではありません。バッテリー最適化、バックグラウンド実行の権限、アプリごとのプロキシ対象リストも確認してください。画面を開いている間は使えても、ロック後に切断される場合は、すぐにプロトコルを変えるのではなくバックグラウンド制限を調べましょう。設定画面の場所はメーカーによって異なるため、権限の項目名から探してください。

パラメーターの数ではなく、必要な機能で選ぶ

クライアントが適しているかどうかは、必要なプロトコル、サブスクリプション形式、ルール機能、通信の入口によって決まります。ブラウザーだけで使うなら、通常のローカルプロキシで十分な場合が多く、より多くのアプリを対象にするならTUNを検討します。REALITYなど特定の設定を使う前に、選んだコアが必要なパラメーターに対応しているか確認してください。画面に多くの機能があっても、すべてを有効にする必要はありません。設定を増やすほど、問題を切り分ける範囲も広がります。

クライアントを変えても、サーバー自体が利用できない問題は解決しません。同じ設定とネットワーク環境を保ったまま、2つのクライアントのログと動作を比較して初めて参考になります。管理方法の違いを詳しく比べるには、3種類のクライアント機能比較をご覧ください。選択した後は、まず1つのクライアントに決めてインストールを進めましょう。基準となる状態ができる前に、頻繁に設定を移行するのは避けてください。

3. インストールと初回起動の基準作り

継続して書き込み可能な場所にインストールする

まずダウンロードページの説明に従ってインストールまたは展開し、クライアントを起動します。展開が必要な場合は、アーカイブ内から直接実行せず、独立したフォルダーへ完全に展開してください。設定やログを書き込めて、後からバックアップしやすい場所を選びます。ファイルを頻繁に書き換える同期フォルダーでのテストは避けましょう。古いコピーで設定が上書きされたり、複数のデバイスが同じ実行状態に書き込んだりすることがあります。

初回起動時に実行環境についての案内が表示されたら、指示に従って必要なコンポーネントを追加し、クライアントを再起動します。画面は表示されるのにコアが起動しない場合は、コアの実行ファイルの場所、実行権限、セキュリティソフトのブロック履歴を確認してください。システムの保護機能を一括で無効にするのではなく、どのファイルが何を理由に阻止されたかを調べます。システム権限を使う操作は必要最小限にし、通常のプロキシテストでは最初からTUNを有効にする必要はありません。

コアとローカルの待ち受けポートを確認する

設定を開き、使用中のコアがサーバー設定に対応していることを確認してから、ローカルの待ち受けアドレスとポートを確認します。このガイドではポートの例として10808を使用しますが、実際の値はクライアントの画面に従ってください。HTTP、SOCKS、混合の入口を別々に表示する画面もあれば、1つの入口にまとめている画面もあります。アプリ側のプロキシ種別は対応する待ち受け方式と一致させてください。ポート番号だけをコピーしても設定は完了しません。

本機のアプリは通常、127.0.0.1に接続します。このアドレスは現在使用しているデバイス自身を指すため、別のデバイスで指定しても、そのデバイス自身にしか接続できません。初回の設定では本機のみで待ち受け、LAN接続は有効にしないでください。ほかのデバイスにも接続を提供する必要がある場合は、待ち受け範囲、アクセス制御、ファイアウォールのルールを確認します。ポートを開放するとアクセス可能な範囲が広がることを理解しておきましょう。単に便利な入口が増えるだけではありません。

変数を絞って初回テストを行う

利用許可のあるサーバーを1つインポートして有効にし、TUNは無効のままにします。システムプロキシの自動設定を選び、その設定に従うブラウザーから新しいリクエストを送信しながら、クライアントのログを確認します。ブラウザーのキャッシュや既存の長時間接続が古い経路を使い続けることがあるため、必要に応じてテスト用のタブを閉じてから開き直してください。テストした時刻を記録しておくと、過去の出力すべてに目を通さず、該当するリクエストをログから探せます。

「コアが起動した」という表示は、プロセスが実行状態になったことを示すだけで、リモートとのハンドシェイクに成功したことを意味しません。ページが開かない場合、まずログに該当するリクエストがあるか確認します。記録がなければアプリ側の入口を調べ、記録があるのに接続できない場合はサーバーのアドレス、ポート、セキュリティ層を確認します。設定の読み込みエラーが出ている場合は、まずそのエラーを修正してください。同じ設定のまま接続先だけ変えても、結果は変わらないことがあります。

ネットワークへのアクセス権限とプログラムの権限を分けて考える

システムのファイアウォールでプログラムの通信を許可することと、LAN内のデバイスからローカルポートへの接続を許可することは、別方向の権限です。初回の利用では、現在のテストに必要な経路だけを許可し、トラブルシューティングのためにすべての受信ルールを一度に開放しないでください。macOSのセキュリティ通知、Linuxの実行権限、Windowsの実行環境の問題も、それぞれ個別に対処します。インストール時の注意点は初回インストール設定メモをご覧ください。

接続に成功したら、プログラムの保存先、設定の保存場所、使用中のコア、待ち受けポート、テストに使ったアプリを記録します。次にクライアントを正常終了し、システムプロキシが想定どおり解除されることを確認してから再起動し、設定が保持されることを確かめます。終了後もブラウザーがローカルポートに接続し続ける場合は、システムプロキシの設定が残っていないか確認してください。起動、接続、終了の一連のテストを終えて初めて、再現可能なインストールの基準ができます。その後にサブスクリプションやルールを追加しましょう。

4. サブスクリプションの追加とサーバー管理

サブスクリプションURLと共有リンクを区別する

サブスクリプションURLは複数のサーバー情報をダウンロードして更新するためのものです。一方、共有リンクは通常、1つのサーバーを表します。vmess://、vless://、trojan://、ss://で始まる文字列は、共有リンクのインポート画面から取り込みます。サブスクリプションURLはサブスクリプショングループのURL欄に入力してください。入力先を取り違えると、解析エラーになったり、テキストとして読み込まれるだけで利用可能なサーバーが作られなかったりします。

サブスクリプションURLにはユーザー固有の認証情報が含まれることが多いため、機密情報として管理し、公開スクリーンショットやチャットに貼らないでください。コピーする際は先頭と末尾、改行を確認し、説明文や句読点、空白まで含めないようにします。QRコードから読み取った場合も、クライアントが認識した内容の種類を確認してください。提供元が不明な変換サービスにサブスクリプションを渡すのは避けましょう。URLやサーバー設定を第三者に読まれる可能性があります。

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

v2rayNのサブスクリプショングループ管理でグループを追加し、識別しやすい名前とサブスクリプションURLを入力して保存します。その後、該当グループを更新してください。初回の更新時には結果のメッセージを確認し、サーバー一覧が実際に変わったことを確かめます。グループ名はローカルでの管理用であり、リモートの接続先には影響しません。提供元ごとに分けておくと、後から更新に失敗した提供元を特定しやすくなります。また、手動で追加したサーバーがサブスクリプションの項目と混ざって上書きされるのを防げます。

更新に失敗したら、まずダウンロードエラーと解析エラーを区別します。ダウンロードに失敗する場合は、現在のネットワークからURLにアクセスできるか、利用可能なプロキシ経由での接続が必要か、証明書とシステム時刻に問題がないかを確認します。解析エラーの場合は、応答内容がクライアント対応のサブスクリプション形式かを確認してください。アカウントページ、エラーページ、期限切れの応答が通常のテキストとして返ることもあります。「ダウンロード完了」と表示されても、インポートが成功したとは限りません。

更新方法と置き換え範囲を理解する

クライアントによっては、直接更新とプロキシ経由で更新する方法があります。利用可能なサーバーがまだない初期設定でプロキシ経由の更新を選ぶと、接続が循環してしまうことがあります。利用可能な接続ができてからであれば、プロキシ経由でサブスクリプションURLへアクセスできます。更新方法を選ぶ前に、更新通信がどの経路を通るか確認してください。同じ誤った入口を何度もクリックするのは避けましょう。提供元が特定の形式を指定している場合は、その形式に対応したクライアントのインポート機能を使ってください。

サブスクリプションの更新で、そのグループ内の項目が置き換わることがあります。サブスクリプションのノードを直接変更しても、変更が長期的に保持されるとは限りません。ローカルで調整する場合は、別の手動グループにコピーし、変更理由を記録してください。更新の前後に、有効なサーバーが残っているか確認します。特に項目名や識別子が変わった場合は注意が必要です。クライアントに以前と同じ名前が表示されても、同じアドレスに接続している証拠にはなりません。詳細を開いて確認してください。

インポート後の主要な項目を確認する

共有リンクを正常に解析できたら、プロトコル、アドレス、ポート、ユーザーIDまたはパスワード、トランスポート方式、セキュリティ層の順に確認します。WebSocketではパスとHost、gRPCではサービス名、REALITYでは公開鍵、ショートID、サーバー名なども関係します。これらの項目は提供元の設定と一致させてください。ほかのサーバーの設定をまとめて流用しないでください。別名は自由に整理できますが、接続パラメーターは本来の意味を保つ必要があります。

更新後は、まず現在のサーバーをテストしてから自動更新を設定します。自動更新の頻度は提供元の案内に合わせてください。更新を頻繁にしても安定性が高まるわけではありません。長期間使わないグループでは、自動更新を停止し、必要な記録だけ残すこともできます。特定のグループだけに問題があり、ほかのグループが正常なら、まずそのサブスクリプションの提供元を調べます。よくある対処方法はヘルプセンターで確認できます。部分的な問題をクライアント全体の再インストールに広げないようにしましょう。

5. システムプロキシと通信の入口

システムプロキシはデバイス全体の通信を取り込む機能ではない

システムプロキシはアプリにローカルのプロキシアドレスを提示しますが、それを使うかどうかはアプリ側の仕様によります。ブラウザーは通常システム設定を参照しますが、独自のプロキシ設定を持つツールや、システムプロキシをまったく使わないアプリもあります。そのため、「システムプロキシを自動設定」に切り替えた後、1つのアプリでの結果だけを見て、すべての通信がコアに入ったと判断しないでください。入口の動作確認には、システム設定に従うことが分かっているアプリを使います。

通常、「システムプロキシを解除」は現在のシステムプロキシ設定を取り除く操作で、「システムプロキシを変更しない」は既存の状態を保持する操作です。両者は同じではありません。システムに別のプロキシ設定がある場合は、切り替える前に内容を記録し、元に戻せるようにしてください。クライアントを終了してもローカルのプロキシアドレスがシステムに残っていると、アプリはすでに閉じたポートに接続し続け、終了後にネットワークが不調になることがあります。

ルーティングモードは入口の後に働く

グローバル、特定地域を除外した接続、直接接続などのルーティングモードは、コアに入ったリクエストの出口を決めます。システムプロキシとは別の階層です。グローバルに切り替えても、システムプロキシを無視するアプリの通信は自動的に取り込まれません。システムプロキシを自動設定にしても、すべてのリクエストがリモートへ送られるとは限りません。まずリクエストがクライアントに届いているか確認し、それから出口の選択を調べることで、モード切り替えの影響を正しく判断できます。

グローバルプロキシは、リモート接続が機能しているかを一時的に確認するのに向いています。ただし、現在のプリセットでプライベートネットワークなどの例外が維持されているかは確認してください。特定地域を除外する設定では、通常ドメインやIPのデータセットを使い、該当する宛先を直接接続にします。直接接続モードでは、コアに入った通信を優先して直接アクセスさせます。クライアントごとにプリセットの内容は異なる場合があります。モード名だけで動作を推測せず、ルールの内容を確認してください。

アプリごとにプロキシを設定する

アプリに独自のプロキシ設定がある場合は、クライアントの実際の待ち受け方式に合わせてHTTPまたはSOCKSを選び、アドレスにループバックアドレス、ポートに対応するローカルポートを指定します。通常のプロキシ欄にリモートサーバーのアドレスを直接入力しないでください。リモートのプロトコル処理は通常コアが担います。アプリに「プロキシ経由でドメインを解決」のような項目がある場合、その設定によってどちら側で名前解決するかが変わります。後続のルーティング方針と合わせて理解してください。

1回のテストでは、アプリのプロキシ設定を1つだけ使ってください。ブラウザー拡張、システムプロキシ、アプリ内の設定が同時にある場合は、まず優先順位を確認します。システムプロキシを変更したつもりでも、実際のリクエストが拡張機能に保存された古いポートを使っていることがあります。設定を切り替えたら既存の接続を閉じて再試行し、どの設定が有効になったか記録してください。長期的には入口の重複を減らしましょう。設定元が少ないほど、復元や移行が簡単になります。

利用場面に合わせて接続方法を選ぶ

一般的なブラウジングなら、システムプロキシの自動設定と明確な振り分けルールから始められます。特定の開発ツールだけを対象にする場合は、アプリごとにプロキシを設定します。システムプロキシに従わないアプリも取り込みたい場合は、TUNを検討してください。LAN内のデバイスからアクセスする場合は、待ち受け範囲とファイアウォールの設定も必要で、システムプロキシのスイッチだけでは対応できません。入口を追加するたびに個別のテストを行い、既存の通信の出口が想定どおりか確認します。

ブラウザーは正常なのにほかのアプリで失敗する場合は、まずそのアプリの通信がクライアントに届いているか確認し、すぐにドメインルールを変更しないでください。すべてのアプリがクライアントに届いているのに一部の宛先だけ失敗する場合は、ルーティング、名前解決、リモートへの接続状況を調べます。具体例はシステムプロキシとルーティングモードの違いをご覧ください。次章では入口を確認したうえで、ルールの順序とドメインの扱いを解説します。

6. ルーティングとDNSの設定

上から順にルールの適用を確認する

ルーティングルールは、どのリクエストをどのアウトバウンドへ送るかを定めます。よく使われる条件には、ドメイン、宛先IP、ポート、ネットワーク種別などがあります。同じルール内の異なる種類の条件は通常、すべて一致する必要があります。同じ種類の条件を複数指定した場合は、それぞれの条件の意味に従って判定します。コアはルールを上から順に確認し、一致した時点で対応するアウトバウンドを選択するため、特定の例外は広い範囲に適用するルールより前に置くのが一般的です。一致するルールがない場合の処理は、デフォルトのアウトバウンドとクライアントが生成した設定を確認してください。

まず実現したい動作を明確にし、その後で条件を決めます。たとえば内部ドメインを直接接続させる場合、クライアントがドメイン名を受け取るのか、IPアドレスしか受け取らないのかを確認してから、ドメインルールかアドレスルールを選びます。公開ドメインを1つ直接接続にしても、そのページが読み込むすべてのリソースを対象にできるとは限りません。別のドメインへのリクエストが含まれる場合があります。実際のログを見ながら少しずつ追加し、一度の失敗で広範囲の宛先を同じ出口に変更しないでください。

ドメインの扱い方で名前解決のタイミングが変わる

AsIsは、既存の宛先情報を使ってルールを照合し、ルーティングのために追加のドメイン解決を行いません。IPIfNonMatchは、ドメインが該当するルールに一致しなかった場合にIPアドレスへの解決を試み、IP条件でも照合します。IPOnDemandは、IPを必要とするルールを照合する際に名前解決を試みます。具体的な動作は、使用するコアの実装に従って確認してください。ドメインの扱い方を変更するとルーティングの判定方法が変わりますが、すべてのアプリが使うシステムDNSを置き換えるわけではありません。

geosite:cnはドメインのデータセット、geoip:cnはアドレスのデータセットを指定する方法であり、相互に置き換えることはできません。データファイルの有無や内容が現在の要件に合うかどうかも、照合結果に影響します。名前解決で得られるアドレスはネットワークや時間によって変わることがあるため、一度のIPアドレスの所在地だけでルーティングが常に正しいとは判断できません。データを更新した後は、主要なドメインを実際に確認してください。ルールの動作が完全に変わらないと決めつけないようにしましょう。

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

上の例はルーティングの断片であり、実行可能な完全設定ではありません。利用可能なデータファイルと、directという名前の直接接続アウトバウンドが必要です。また、それ以外のリクエストに対する最終的な出口は定義されていません。GUIクライアントでは異なるタグ名が生成される場合があるため、対応するルール画面で読み替えてください。設定全体をそのままクライアントの内容と置き換えないでください。1つ目のルールはプライベートアドレス、2つ目はドメインの集合を処理します。ほかの通信の動作は、残りのルールとデフォルトのアウトバウンドによって決まります。

DNSの問題と接続の問題を切り分ける

ドメインを解決できない場合、通常は接続先とのハンドシェイクまで到達していません。名前解決は成功したのに接続がタイムアウトする場合は、アドレスへの到達性、ルーティングの出口、リモート側の状態などが関係している可能性があります。ログに記録されたエラーの段階を確認してから変更箇所を決めてください。アプリによっては独自に名前解決し、プロキシにはアドレスだけを渡します。その場合、ドメインルールを追加するだけでは効果がないことがあります。トラフィックの検出機能で宛先情報を補える場合もありますが、すべてのプロトコルを識別できるわけではありません。

トラフィックの検出機能は接続情報からドメインを識別しようとします。検出結果をルーティングに使うか、宛先アドレスを変更するかは、設定によって異なります。あらゆるDNS問題を自動修復するスイッチとして扱わないでください。LAN内の名前にアクセスする場合は、不適切なリモート名前解決によってローカルの解決経路が置き換えられていないかも確認します。会社や学校のネットワークでは内部ドメインが使われている場合があるため、変更前に既存の名前解決方法と利用要件を記録してください。

変更範囲を絞って回帰テストを行う

ルールは一度に1つだけ追加し、適用されるべき宛先と適用されるべきでない宛先を1つずつテストして、出口が想定どおりか確認します。結果が問題なければ範囲を広げ、ルールの目的を記録してください。異常が出たら直近の変更を戻し、最小限のルール構成にしてから一つずつ追加します。DNS、ドメインの扱い方、サーバーを同時に切り替えると、接続が復旧しても何が効いたのか判断できません。その後の保守にも根拠が残らなくなります。

7. TUNモードとシステム通信の取り込み

仮想ネットワークインターフェースで通信の入口を広げる

TUNは仮想ネットワークインターフェースを通じて、システムのルーティングで送られたIPパケットを受け取り、対応するコンポーネントに渡します。主にプロキシ処理へ通信を取り込む方法を広げるもので、サーバー設定、サブスクリプション、リモートネットワークの問題を自動修復する機能ではありません。有効にする前に、通常のプロキシで同じサーバーが使えることを確認してください。基本の接続ができていない状態で仮想インターフェースを追加すると、権限、システムルート、DNSなどの変数も増え、原因の特定が難しくなります。

TUNを有効にしても、すべてのリクエストが必ずリモートプロキシを通るとは限りません。取り込み対象の通信も、ルールに従って直接接続、プロキシ、その他の処理に振り分けられることがあります。システムルーティングやアプリによるネットワークインターフェースの固定などが原因で、取り込み範囲に入らない通信もあります。画面に有効と表示されるだけでは不十分です。仮想インターフェースが作成されたか、関連するルートが有効か、テスト対象のリクエストがログに記録されているかも確認してください。

有効にする前にインターフェースの競合を解消する

ネットワークを取り込んでいるほかのVPN接続や、重複したTUNのインスタンスを先に停止します。通常のネットワークが利用できることを確認して、現在の設定を保存してください。クライアントの案内に従って必要な権限を付与し、起動後はドライバー、インターフェースの作成、ルートの追加、権限に関するエラーがログにないか確認します。スイッチを何度もクリックして復旧を待つだけでは解決になりません。起動に失敗した場合は、最初に出た明確なエラーから対処してください。その後の接続タイムアウトは、インターフェースが作られなかった結果かもしれません。

リモートサーバーへの接続には、到達可能な出口を確保する必要があります。同じ取り込み経路へ再びルーティングしてループさせないでください。クライアントが必要なルート設定を自動で処理する場合が多いものの、複数のネットワークインターフェース、ほかのネットワークツール、手動ルートによって結果が変わることがあります。有効にした直後にネットワーク全体が使えなくなったら、まずTUNを無効にして基準の状態に戻し、デフォルトルートと競合するツールを確認してください。通信できないままルールやサブスクリプションを一括更新しないでください。

DNS、UDP、LANを個別に確認する

TUNを有効にしたら、まず通常のWebページをテストし、次にUDPを必要とする実際のアプリを確認します。その後、ルーターの管理画面、プリンター、内部サービスへのアクセスも検証してください。Webページが見られても、一部の通信経路が動作していることしか分からず、すべてのプロトコルが正常とは限りません。UDPの転送可否は、クライアントの取り込み方式、コア、リモートのプロトコル、サーバー設定に関係します。テストに失敗した場合は、同じ経路に沿って確認し、すべてをシステム権限の問題にまとめないでください。

DNSの取り込みによって従来の名前解決経路が変わることがあります。有効にする前後でドメインへの接続状況を比較してください。公開ドメインは正常なのに内部名が使えない場合は、ローカルDNSとLAN向けの例外を確認します。特定のアドレス範囲だけに接続できない場合は、プライベートアドレスのルールとルーティングを調べます。MTUを調整する場合は、断片化や特定の通信での異常といった根拠を確認してください。理由なく小さな値を設定すると、根本原因が隠れたり、ほかの接続効率に影響したりすることがあります。

デスクトップとAndroidで別々に復旧方法を確認する

デスクトップ版のTUNは追加のネットワークコンポーネントを使う場合があります。具体的な機能はクライアントへの同梱状況や実装によって異なり、すべてのコアに同じネイティブインターフェースがあるとは限りません。AndroidクライアントでシステムのVPNインターフェースを使う場合は、アプリごとの対象リストとバックグラウンド制限も確認してください。対象リストからアプリが除外されていたり、OSがクライアントを停止したりすると、一部だけ動かなくなることがあります。これはリモートサーバーの障害とは異なる対処が必要です。

スリープからの復帰、Wi-Fiの切り替え、有線ネットワークへの接続後は、通信の取り込み状態をもう一度確認してください。古いインターフェースや名前解決の状態が一時的に残ることがあります。クライアントを正常に停止して再起動すると環境を作り直せますが、まず異常を記録して証拠を残しましょう。ネットワークを切り替えるたびに同じ問題が起きる場合は、ネットワークの種類、発生までの操作、インターフェースの状態、関連ログを整理し、症状に応じてヘルプセンターを確認してください。プロセスを強制終了する方法に頼り続けないようにしましょう。

8. 日常の保守とトラブルシューティング

プログラム、設定、サブスクリプションを分けて管理する

日常の保守で扱う対象は、クライアントとネットワークコンポーネント、ユーザーが保存した設定、リモートのサブスクリプション内容の3つです。クライアントを更新してもサブスクリプションが更新されるとは限らず、サブスクリプションを更新してもローカルのルーティングルールは自動で変わりません。保守を始める前に、今回解決したい問題を確認し、関連する部分だけを更新します。クライアント、コア、ルールを一度に置き換えると、異常が起きても、どの層が変化の原因か判断できません。

プログラムを更新する前に必要な設定をエクスポートし、バックアップの対象範囲を確認してください。エクスポートによってはサーバー情報だけが保存され、ルーティング、サブスクリプショングループ、画面の設定が含まれないことがあります。実行ディレクトリ全体をコピーしても、別のプラットフォームで復元できるとは限りません。バックアップ後に、対象のインポート機能でファイルを読み込めることを確かめます。バックアップにはアカウント情報やサブスクリプションの認証情報が含まれる可能性があるため、適切なアクセス制限がある場所に保存し、公開共有フォルダーには置かないでください。

決まった順序で確認する

まったく接続できない場合は、まず通信の取り込みを無効にして基礎的なネットワークを確認し、クライアントのプロセスとコアの状態、アプリの入口、有効なサーバー、ハンドシェイク、接続先への到達性の順に確認します。一部のアプリだけに問題がある場合は、同じ入口を使っているか比較します。一部のドメインだけ失敗する場合は、ルーティングとDNSを重点的に調べてください。この順序は依存関係に沿っているため、上流が正常でないうちに下流のルールを変更し、原因不明の変更を増やすことを防げます。

ログは、目的を明確にした1回の操作に絞って収集します。テスト時刻、アプリ、接続先の種類、そのときのモードを記録し、無関係な古い出力を整理してから再現してください。設定の解析エラーがある場合は、該当する項目とコアの互換性を確認します。認証やハンドシェイクのエラーなら、設定とシステム時刻を確認します。タイムアウトなら、接続先アドレス、出口、ネットワーク環境を調べます。「タイムアウト」という表示だけで、サーバーが恒久的に使えない、あるいは特定のプロトコルが不適切だとは判断できません。

テスト指標は実際の用途に合わせる

遅延は通常、特定の方法で測定した往復時間を示し、速度テストは特定の接続条件におけるデータ転送状況を示します。両者は互いに代用できません。サーバーの応答時間が良好でも、接続先のサービス、同時接続数、時間帯によっては用途に合わない場合があります。日常の確認には実際に使うアプリを含め、テスト回数を抑えてください。一括テスト自体が接続や通信量を発生させ、進行中のダウンロードや会議に影響することもあります。

システム時刻の誤りはセキュリティハンドシェイクに影響することがあり、スリープから復帰した後も時刻とネットワークの状態を確認してください。別のネットワークに接続するとすぐ復旧する場合は、元のネットワーク経路に調査すべき点がありますが、特定の機器が原因だとまでは断定できません。同じクライアントと設定を使い、ネットワークだけを変えて比較できます。あるいはネットワークを変えず、利用可能と確認済みのサーバーを1つだけ変えて比べます。比較のたびに、主要な条件は1つだけ変更してください。

診断情報を共有する前に機密項目を削除する

サポートを依頼する際は、クライアント名、OS、使用中のコア、モード、エラーが起きた段階を伝えると調査を始めやすくなります。スクリーンショットでは、サブスクリプションURL、ユーザーID、パスワード、公開鍵に関連する情報、公開に適さないサーバーの詳細を隠してください。設定フォルダー全体をそのままアップロードしないでください。ログには接続先のドメインやローカルのパスが含まれる場合もあります。共有前に前後の内容を確認し、原因の調査に必要なエラー情報は残しつつ、個人情報を必要最小限にしてください。

動作が安定したら、最近変更した内容、変更理由、確認方法、元に戻す手順を簡潔な保守メモに残します。異常時は、同じサブスクリプションを何度も取り込んだりプログラムを再インストールしたりせず、直近の正常な状態に戻してください。よくある質問は初心者向け接続トラブルの早見表を参照できます。復旧後も問題が再現する場合は、入口、名前解決、ルーティング、リモート接続の順に調査を続けましょう。

9. 応用設定と検証の進め方

カスタマイズの前に生成された設定を読む

GUIに慣れたら、クライアントの設定表示またはエクスポート機能を使い、生成された内容を確認できます。受信、送信、ルーティング、DNS、ログの各部分に注目し、画面上の設定項目がどの設定フィールドに対応するかを見てみましょう。まずは読み取りにとどめ、すぐに変更しないでください。起動時にクライアントがファイルを再生成する場合があり、実行中の設定を直接編集しても保存されるとは限りません。サーバーの切り替えやサブスクリプションの更新で上書きされることもあります。

カスタム設定は、GUIで対応できない明確な要件を解決するために使います。基本的な通信経路の理解に代わるものではありません。作業を始める前に元の設定を保存し、使用するコアが該当する構文に対応していることを確認してから、最小限の変更で検証します。アウトバウンドのタグ名はルールからの参照と一致させ、ポートは既存の入口と競合しないようにしてください。設定の断片だけを、必要なデータやコンポーネントなしで動かすこともできません。起動に失敗したら、項目を追加し続けるのではなく、最後に利用できた設定に戻します。

小さなテストで設定の範囲を理解する

以下は、本機のSOCKS受信と直接接続の送信だけを行う基本設定例です。独立したテスト環境で、入口と出口の関係を理解するために使えます。リモートのプロキシサーバーには接続しないため、インポート済みサーバーの設定の代わりにはなりません。例に使うポートが未使用で、現在のコアが該当する項目に対応している場合のみ使用してください。GUIクライアントの場合は、同じ設定を画面から行う方法を優先します。

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

このテストでは、アプリが指定したポートに接続できるかを確認し、直接接続の出口が動作するかを観察します。リモート認証とセキュリティハンドシェイクはテスト対象から外しているため、ローカルの入口の問題を説明する用途には適していますが、リモートサーバーが利用可能だという証明にはなりません。テスト後は元の設定に戻し、一時的な直接接続環境を日常のプロキシ環境と取り違えないようにしてください。この例の目的は変数を見分けることであり、例をすべて1つの大きな設定ファイルにコピーすることではありません。

必要に応じてプロトコルとトランスポートを学ぶ

プロトコルを学ぶ際は、まず「一致させる必要のある項目」から確認します。ユーザーの識別情報、トランスポート方式、セキュリティ層、任意の拡張設定などです。次に各項目が通信のどの段階で使われるかを理解し、性能の検討はその後に行います。REALITYとXTLS Visionは具体的な技術構成であり、使用できるかどうかはクライアントのコアとサーバー設定によります。プルダウンを1つ変更するだけで移行できるわけではありません。仕組みの解説はREALITYとXTLS Visionのメモをご覧ください。

トランスポート方式を比較する際は、ネットワーク、サーバーのリソース、テスト対象、時間帯などの条件をできるだけ揃えてください。接続先サービスによる応答の違いを、プロトコル名だけの差だと判断してはいけません。接続の再利用、UDPの処理、DNSの設定も使用感に影響するため、個別に確認します。実際の要件がなければ、互換性と安定性のある設定を維持しましょう。理論上の利点を追い、複数の項目を同時に変えると、性能の変化がどこから生じたのか判断できなくなります。

応用設定を保守しやすい形にまとめる

応用設定を追加したら、用途、前提条件、期待する動作、元に戻す方法を記録します。たとえば、アプリの振り分けを追加した場合は、照合条件とデフォルトの出口を記録します。ドメインの扱い方を変えた場合は、影響を受ける名前解決経路を記録します。TUNを有効にした場合は、LANへのアクセスとネットワーク切り替えの検証結果を残します。画面のスクリーンショットだけでなく、実際の動作を記述してください。画面の配置が変わると、設定の背景にある仕組みがスクリーンショットだけでは分からなくなることがあります。

最終的な回帰テストでは、プログラムの再起動、サブスクリプションの更新、ネットワークの切り替え、スリープからの復帰、正常終了を確認し、偶然残った接続状態に依存していないことを確かめます。特定の順序でしか動かない機能があれば、その順序を恒久的な対処法とするのではなく、依存関係を調べてください。リクエストの入口、名前解決、ルールの照合、出口を説明でき、障害時に基準となる状態へ戻せることが、入門から応用までの設定を実際に完了した目安です。

問題に応じて該当する章を参照してください。再インストールは第3章、サーバーの更新は第4章、アプリが接続されない場合は第5章、宛先の振り分けに問題がある場合は第6章、仮想ネットワークインターフェースの問題は第7章です。最短の接続手順をもう一度確認する場合はクイックスタートガイドへ戻り、プラットフォームやインストール形式を変える場合はダウンロードページで対応クライアントを選んでください。ダウンロード、設定、診断をそれぞれ分けて進めましょう。