v2rayN 全プラットフォーム設定ガイド

事前準備：インストーラーとサブスク情報

クライアント、コア、サーバーの違いを確認する

v2rayNは、サーバー、サブスクグループ、プロキシモード、ルーティングルールを管理するデスクトップ向けGUIクライアントです。実際の接続は、クライアントから呼び出されるプロキシコアが処理します。Windows、macOS、Linuxではv2rayN、AndroidではXrayコアを採用するv2rayNGが主な選択肢です。V2Flyコアを採用するv2flyNGも利用できます。GUIクライアント自体は接続サービスを提供するものではなく、インストールしても利用可能なサーバーが自動生成されたり、サブスク利用権が付与されたりすることはありません。設定を始める前に、サービス提供元から有効なサブスクURL、または接続情報がすべて含まれた共有リンクを入手してください。

サブスクは更新可能な設定情報であり、WebサイトのログインIDやパスワードではありません。サービスの有効期限、通信量の上限、同時接続できる端末数を確認してください。サーバーアドレスとポート番号だけでは設定を再現できない場合があり、ユーザー識別子、通信方式、TLS設定、サービス名などが必要になることもあります。ネット上の断片的な例を参考に、足りない項目を推測で補わないでください。設定を保存できても、組み合わせが誤っているとサーバーとのハンドシェイクに失敗することがあります。サブスクURLには認証情報が含まれるため、コピー時は全文を保持し、共有するスクリーンショットではURL全体を隠してください。

OSのアーキテクチャを確認し、元に戻せる状態を保つ

ダウンロードページでOSに合った項目を選び、プロセッサのアーキテクチャも確認してください。Windowsにはx64デスクトップ版と従来のWPF版があります。macOSはApple Silicon版とIntel版、Linuxはdeb版・rpm版とx64・arm64、Androidはarm64版と汎用版から選びます。ファイルをダウンロードできても、端末で動作するとは限りません。OSのバージョンや実行環境の要件はインストーラーの説明を確認してください。古いOSでは互換性を先に調べ、クライアント名が同じという理由だけで上書きインストールしないでください。

初期設定の前に、ほかのプロキシやVPN、手動設定のDNS、ブラウザーのプロキシ拡張機能が有効か記録しておきましょう。複数の通信制御ツールを併用すると、通信経路が迂回したりループしたりすることがあります。トラブルの切り分け中は、プロキシ経路を一つに絞ってください。すでにクライアントを使っている端末では、必要な設定をエクスポートし、ローカルポート、サブスクグループ、カスタムルーティングを記録します。バックアップにも認証情報が含まれる場合があるため、管理されたローカルフォルダーに保管してください。アップグレードと画面バージョンの切り替えは別々に行い、何度も上書きするより、元に戻せる設定を残しておくほうが原因を特定しやすくなります。

必要最小限の手順で接続を確認する

まずTUNを有効にせずクライアントを起動し、コアが動作することを確認します。次にサブスクを追加してサーバー一覧を更新し、使用する設定を一つ選びます。その後、システムプロキシを有効にし、システムプロキシに従うブラウザーで目的のサイトにアクセスしてください。この基本経路を確認できてから、TUN、カスタムDNS、複雑なルーティングを追加します。こうした順番なら、インストール、サブスク、通信の取り込みに関する問題を切り分けやすくなります。複数の設定を同時に変更して、どの操作が影響したのか分からなくなるのを防げます。

システム時刻の確認も事前準備の一つです。日付やタイムゾーン、時刻同期に問題があると、証明書検証や一部プロトコルの認証に失敗することがあります。テストでは、普段から直接アクセスできるページと、プロキシ経由でアクセスする想定のページを選び、それぞれの結果を記録してください。速度テストに成功しても、すべてのサイトやアプリがプロキシ経由になるとは限りません。以降の確認ではコアのログ、実際のページ表示、接続元情報を組み合わせて判断し、通知領域のアイコンや接続ボタンの色だけで判断しないでください。

Windows：v2rayNのインストールと初期設定

画面バージョンを選び、コアの起動を確認する

Windowsのダウンロードページでv2rayNを選択します。デスクトップ版はクロスプラットフォームの画面を採用し、WPF版は従来のWindows向け画面です。メニューの場所や設定フォルダーが異なる場合があります。初めて使う場合はデスクトップ版を選び、WPF版に慣れている場合は引き続き該当版を利用できます。インストーラーの案内に従ってインストールしてください。解凍して使う配布形式の場合は、固定のフォルダーにすべて展開してから起動します。圧縮ファイルのプレビューから直接実行したり、依存ファイルを残して本体だけをコピーしたりしないでください。

通常のシステムプロキシ利用では、常に管理者権限で実行する必要はありません。初回起動時に実行環境が不足していると表示された場合は、プログラムの案内に従って必要なコンポーネントを追加してください。不足しているコンポーネントをサーバーの障害と取り違えないようにしましょう。ログ画面を開き、クライアントが呼び出したコアがすぐに終了していないか確認します。起動に失敗する場合は、セキュリティソフトの検出履歴、フォルダーへの書き込み権限、同名プロセスの残存を確認してください。原因を特定せずにシステム保護をすべて無効にしないでください。プログラムを一時ダウンロード用フォルダーに置くと、削除時に設定や依存ファイルを失うおそれがあります。安定した場所に配置してください。

サブスクグループ、サーバー、システムプロキシ

サブスクグループの設定を開き、提供元が分かる名前でグループを作成します。サブスクURLを省略せず貼り付けて保存し、メイン画面からサブスクを更新してください。更新方法を選べる場合は、初回は現在のプロキシを経由しない方法を試します。クライアントがまだ接続できていないのに、自分自身を経由して設定を取得しようとする事態を避けられます。更新後、サーバーが想定したグループに追加されていることを確認し、一つ選んで使用中の設定に指定します。一覧で行を選択しただけでは有効にならないことがあります。画面にある「使用するサーバーに設定」などの操作を行い、状態が変わったことを確認してください。

実際の接続テストを実行し、一覧の並び順だけでなく失敗理由も確認します。接続できるサーバーを選び、システムプロキシを「システムプロキシを自動設定」にして、通常のブラウザーでテストしてください。ルーティングは、初期設定を簡単にするため「中国本土をバイパス」などの既存プリセットから始められます。切り分けが必要なときは、同じ接続先を使って一時的にグローバルプロキシルールに切り替えてください。ただし、システムプロキシとルーティングは別の段階の設定です。前者はアプリからローカルプロキシへリクエストを送るかどうかを決め、後者はコアが受け取ったリクエストの出口を選びます。ブラウザーのプロキシ拡張機能がシステム設定より優先される場合があるため、確認中は拡張機能を一時停止してください。

TUNの権限とWindows特有の問題

システムプロキシ経由の接続が確認でき、対象アプリがシステムプロキシに従わない場合に限り、Tunモードを検討してください。クライアントの案内に従って管理者権限を許可し、必要なコンポーネントをインストールするか、必要なサービスを起動して、仮想ネットワークアダプターとコアのログを確認します。権限を許可しても、起動エラーを無視してよいわけではありません。TUNの確立に失敗していても、クライアントの画面は正常に表示されることがあります。仮想ネットワークアダプターの作成失敗や権限不足が起きた場合は、残存プロセスを終了し、通常のシステムプロキシで接続を確認してください。ネットワークアダプター関連のコンポーネントを何度もインストールしたり、物理ネットワークアダプターやシステムルートを不用意に削除したりしないでください。

ローカルポートが使用中の場合、コアのログに待ち受け失敗が記録されることがあります。まずクライアントの設定で実際のポート番号を確認し、OSで使用中のプロセスを調べて、別のクライアントが起動していないか確認してください。ポートを変更した場合、プロキシを手動設定したアプリ側も変更しないと、古いポートへの接続を続けます。スリープ復帰後や有線・無線ネットワークの切り替え後に接続できなくなったら、まずTUNを無効にして接続し直し、ネットワーク自体が復旧してからプロキシを確認します。スタートアップへの登録は、手動接続が安定してから行い、ログイン時に異なる画面バージョンのクライアントが同時に通信を取り込まないよう確認してください。

正常に終了する前にTUNを無効にし、「システムプロキシをクリア」して通常のネットワーク設定に戻してください。異常終了後にWebページを開けなくなった場合は、Windowsのプロキシ設定が、停止したローカルポートを指したままになっていないか確認します。削除するのは残存プロキシ設定であり、ネットワーク設定全体をリセットする必要はありません。組織のポリシーで管理されている端末では、指定されたプロキシ設定を上書きしないでください。初回インストールの詳しい手順はv2rayNの初回インストールと初期設定を参照してください。トラブル時は、フォルダーと起動確認の項目も役立ちます。

macOS：チップに合った選択、権限、プロキシの復旧

チップに合ったインストーラーを選ぶ

まずシステムの「このMacについて」でプロセッサ情報を確認します。Appleチップ搭載端末にはApple Silicon版、Intelプロセッサ搭載端末にはIntel版を選択してください。各版はmacOSのインストーラーからダウンロードできます。ディスクイメージを開き、案内に従ってアプリケーションフォルダーにアプリを移動し、固定の場所から起動してください。一時的にマウントしたディスクイメージから長期間起動すると、イメージを取り出した後にログイン項目やショートカットが存在しない場所を参照することがあります。インストールを済ませてから初回起動時の確認を行い、インストール、更新、権限変更を同時に進めないようにしましょう。

システムのセキュリティ警告が表示された場合は、まず選択したダウンロードページから入手したファイルであることを確認し、「プライバシーとセキュリティ」に表示された具体的な案内に従って起動を許可するか判断してください。アプリを起動するためにシステム全体のセキュリティ機能を無効にしたり、出所不明のターミナルコマンドで制限を解除したりすることは避けてください。アーキテクチャの不一致、OSのバージョン要件、アプリの破損はそれぞれ異なる問題なので、個別に確認します。画面が開いた後はコアが起動するかも確認してください。GUIが動いていても、コアのプロセスやTUNに必要なコンポーネントを実行する権限があるとは限りません。

サブスクを追加してシステムプロキシを確認する

v2rayNでサブスクグループを作成し、名前と完全なサブスクURLを入力して保存したら更新を実行します。更新に失敗した場合は、TUNを有効にせず、現在のネットワークとURLの有効性を確認してください。サブスクURLを通常のサーバーアドレス欄に貼り付けないようにしましょう。更新できたら使用するサーバーを選び、実際の接続テストを行ってからシステムプロキシの自動設定を有効にします。ブラウザーのテストでは、独自のプロキシ設定や拡張機能がリクエストを処理していないか確認してください。ネットワークを切り替えた前後で同じページにアクセスし、テスト先の違いによる誤判定を避けます。

macOSのプロキシ設定は、通常、個々のネットワークサービスに紐づいています。有線、無線、ほかのネットワークインターフェースに別々の設定がある場合があるため、接続先を切り替えた後は、使用中のサービスが想定したローカルポートを指しているか確認してください。業務用端末には構成プロファイルや管理ポリシーが設定されている場合もあります。クライアントで設定を変更できないときは、まず制限の適用元を確認してください。システムプロキシが影響するのは、その設定に従うアプリだけです。ターミナルツールや一部アプリは独自の接続方法を使うため、ブラウザーが使えるからといって、すべてのプログラムが同じプロキシ経路を使うとは限りません。

TUN、スリープ復帰、終了時の処理

通信の取り込み範囲を広げる必要がある場合は、画面の案内に従ってTUNの権限や補助サービスを設定します。パッケージ形式によって権限設定の手順が異なることがあるため、別のプラットフォーム向けの管理者操作をそのまま流用せず、現在のプログラムの案内に従ってください。有効にした後は、コアが動作し続けているか、ルート作成、デバイスアクセス、DNSに関するエラーがないか確認します。別のVPNがデフォルトルートやDNS設定を使用中の場合は、競合する接続を終了してからテストしてください。複数のツールを重ねてデフォルトの出口を何度も切り替えると、ログと実際の通信経路を照合しにくくなります。

スリープ後に復帰すると、ネットワークインターフェース、ゲートウェイ、DNSが変わることがあります。まず直接接続でネットワークが使えることを確認し、その後プロキシに再接続してください。TUNだけが失敗し、システムプロキシが使える場合は、サブスクを再度追加する前に仮想インターフェースとルートの復旧を確認します。Webログインが必要な公衆ネットワークでは、通常、通信の取り込みを一時停止してネットワーク認証を済ませてからプロキシを再開します。認証ページが開かない原因はサーバー障害とは限りません。端末が外部ネットワークへのアクセスを許可されていない可能性があり、その場合はサーバーを何度切り替えても解決しません。

ウィンドウを閉じただけではクライアントが終了していない場合があります。メニューバーの状態やバックグラウンドプロセスを確認してください。通常のネットワークに戻すには、先にTUNを無効にし、クライアントが設定したシステムプロキシをクリアします。クライアントが異常終了した場合は、現在のネットワークサービスのプロキシ設定にローカルアドレスが残っていないか確認し、今回のクライアントが設定した項目だけを削除してください。組織の既存設定は残します。接続手順が安定してからログイン項目に登録してください。アップデート後に古いプログラムがバックグラウンドで動き続ける場合は、古いプロセスを終了してから新しいアプリを起動し、同じポートを複数のプロセスが待ち受けないようにします。

Linux：パッケージ形式、デスクトップ環境、実行権限

ディストリビューションに合う形式とアーキテクチャを選ぶ

Linuxのダウンロードページでv2rayNを選択します。debは対応するパッケージ管理方式を使うディストリビューション向け、rpmは対応する方式を使うディストリビューション向けです。拡張子だけで判断せず、x64とarm64の違いも確認してください。端末のアーキテクチャやOS情報は、以下のコマンドで確認できます。一般にx86_64はx64、aarch64はarm64に対応します。OS名とプロセッサは別々の情報です。コンテナ、互換レイヤー、リモートセッションでは、実際の実行環境も踏まえて判断してください。

uname -m
cat /etc/os-release

まずはディストリビューションのソフトウェアインストーラーやパッケージ管理ツールでローカルパッケージをインストールし、依存関係はシステムに処理させてください。GUIの実行コンポーネントが不足していると表示されたら、具体的な依存パッケージ名を確認し、依存関係を強制的に無視してインストールしないでください。インストール後に画面が開かない場合は、インストール済みアプリをターミナルから起動してエラー出力を確認します。表示環境、ランタイム、コアの起動に関する問題を切り分けてください。GUIクライアント全体を常にスーパーユーザーで実行しないでください。設定ファイルの所有者が不一致になり、以後の操作の影響範囲も広がるおそれがあります。

サブスクの追加とデスクトッププロキシの違い

v2rayNを起動したら、まずサブスクを追加してサーバー一覧を更新し、使用する設定を選びます。コアがローカルポートで待ち受けていることを確認してからプロキシを設定してください。Linuxのデスクトップ環境によってシステムプロキシの仕組みは異なります。統一されたネットワークプロキシ画面を備える環境もあれば、アプリごとの設定や環境変数しか読み取らない環境もあります。そのため「システムプロキシを自動設定」が成功しても、すべてのデスクトップアプリがその設定に従うとは限りません。まず、選択したプロキシ方式に対応するブラウザーで確認し、反映されないアプリは個別のプロキシ設定を調べましょう。最初からシステム全体に取り込む範囲を広げないでください。

ターミナルのHTTPツールでプロキシを明示的に指定すると、プロキシ経路とデスクトップ設定のどちらに問題があるか切り分けられます。以下のコマンドは、クライアントでHTTPまたは混合ポートが10808に設定されている場合にのみ使用できます。実際のポートが異なる場合は、実行前にコマンドを修正してください。このコマンドは今回のリクエストだけをローカルプロキシ経由でサンプルサイトに送信します。システムプロキシは変更せず、ほかのプログラムの通信も転送しません。終了コードだけで判断せず、応答ステータス、接続エラー、クライアントログが一致しているか確認してください。

curl --proxy http://127.0.0.1:10808 --head https://example.com

ターミナルにプロキシ環境変数を設定している場合は、テスト時に適用範囲を記録してください。ターミナルのセッションに設定した変数が、すでに起動しているGUIアプリに渡されるとは限りません。GUIアプリの設定がターミナルに反映されるとも限りません。クライアント終了後も環境変数が残っていると、停止したローカルポートへの接続をコマンドが続けることがあります。明示的なプロキシ指定で動作を確認してから、現在のセッション設定を見直してください。一つのコマンドを使えるようにするために、設定元が分からないプロキシ変数を全体の起動ファイルへ追加しないでください。

TUN、DNS管理、権限の範囲

LinuxでTUNを使うには、仮想ネットワークデバイス、ルート操作の権限、クライアントの起動方法が関係します。クライアントのドキュメントや画面に示された手順で権限を設定し、デバイスが見つからない、権限不足、ルート競合などのエラーがないかログを確認してください。すべてのプログラムに一律で権限を与えたり、影響を理解せずに実行ファイルの権限を変更したりしないでください。コンテナ、制限付きのデスクトップセッション、リモート環境では仮想デバイスやネットワーク管理権限を利用できないことがあります。その場合はGUIの再起動を繰り返さず、アプリ単位のプロキシに切り替えてください。

DNSには、ネットワーク管理サービス、システムの名前解決サービス、手動編集したファイルが影響する場合があります。TUNを有効にした後、既存の接続は維持されるのにドメイン名だけ解決できない場合は、クライアントのDNS設定とシステムの名前解決経路を確認し、別のサービスが設定を上書きしていないか調べてください。システムの名前解決設定を安易に削除しないでください。ネットワークサービスが自動生成している場合、再接続後に内容が変わることがあります。TUNを切断した後は、デフォルトルートとDNSが復旧しているか確認します。クライアントを終了して通常のネットワークをテストすると、リモート側の障害と端末に残った設定を切り分けやすくなります。

起動時やログイン後に自動起動する場合は、GUIセッション、認証情報の保管機能、ネットワークの準備が整っているか先に確認します。ログイン時の自動起動とバックグラウンドサービスは別の実行方法です。明確な設計がないまま両方を有効にしないでください。アップデート後に一般ユーザーで設定を保存できない場合は、以前に高い権限で実行したことでフォルダーの所有者が変わっていないか確認します。修正前にバックアップを取り、クライアントが実際に使うフォルダーだけを対象にしてください。ログではローカル待ち受けが正常なのにブラウザーが失敗する場合は、サーバー設定を変える前にデスクトップ環境のプロキシ設定を確認します。

Android：v2rayNGとVPN接続の管理

クライアントをインストールして接続を許可する

AndroidではXrayコアを採用するv2rayNGが第一候補です。V2Flyコアが必要な場合はv2flyNGを選べます。どちらも独立したアプリであり、サブスク、使用中のサーバー、VPNの状態が共有されるとは限りません。Androidのダウンロードページでインストーラーを選び、多くの新しい端末ではまずarm64版を確認してください。アーキテクチャが不明な場合やarm64版をインストールできない場合は、システム情報を確認して汎用版を選びます。汎用版は幅広い環境に対応しますが、すべてのOSバージョンで動作するわけではありません。既存アプリを更新する前に、サブスク情報と必要な設定を保存してください。

インストール時はAndroidの案内に従い、今回使うファイルの入手元にインストールを許可します。完了後、必要に応じてその入手元への許可を取り消してください。「アプリをインストールできません」と表示された場合は、最初にデータを消去せず、アーキテクチャ、空き容量、OSの互換性、既存アプリの入手元を確認します。初回接続時にはシステムのVPN許可画面が表示されます。これは、クライアントがシステムのネットワーク機能を使って通信を取り込むための確認です。許可後もアプリ内のログと状態を確認してください。システムの確認画面を完了しただけでは、リモートサーバーへの接続成功を意味しません。

サブスクを追加し、サーバーを選んで接続を確認する

サブスクグループの設定を開き、新しいグループに完全なURLを貼り付けて保存し、メニューからサブスクを更新します。クリップボードから共有リンクを読み込む方法では、単一または複数の設定が追加されるだけで、自動更新できるサブスクとして登録されるとは限りません。更新時に手動追加したサーバーが変わらない事態を避けるため、二つの方法を区別して管理してください。更新に成功したら、一覧に想定した設定があることを確認して一つ選びます。使用中のサーバーが選択されていないと、接続ボタンを押しても有効なリモート接続を確立できません。

実際の接続テストを実行し、テストに成功したサーバーを選んで接続ボタンを押し、状態が変わったことを確認します。続いてブラウザーで目的のサイトを開き、必要に応じて接続元情報とログを確認してください。テストに成功しても特定のアプリがプロキシを使わない場合は、アプリ単位のプロキシ設定範囲を確認します。選択したアプリだけをプロキシ経由にするモードと、選択したアプリを除外するモードは意味が逆です。アプリ一覧で選択したからといって、必ずプロキシ経由になるとは限りません。現在のモードを確認してください。アプリ一覧やルーティングを変更した後は、画面の案内に従ってVPN接続を再確立し、新しい設定を反映させます。

バックグラウンド制限、ネットワーク切り替え、コアの違い

Androidでは通常、同じユーザー環境で有効にできるVPN接続は一つです。別のVPN、一部のVPN方式を使うネットワークフィルタリングツール、仕事用プロファイルが競合することがあります。接続直後に切断される場合は、別のツールが自動的に接続を再開していないか確認してください。アプリ単位のルーティングと、システムVPNが取り込む範囲もあわせて確認します。コアのルーティングだけを変更しても、すべてのアプリがプロキシ経由になるわけではありません。デスクトップ環境の「システムプロキシ」をAndroidにそのまま当てはめないでください。Androidでは、クライアントがシステムのVPNサービスを利用して通信を取り込むのが一般的です。

画面消灯後に切断され、アプリに戻るとすぐ復旧する場合は、バッテリー最適化とバックグラウンド実行の制限を確認します。端末の設定で必要なバックグラウンド動作を許可し、安定するか様子を見てください。すべてのアプリに一度に権限を与える必要はありません。常時表示の通知は動作状態の確認に使われます。通知を隠してもバックグラウンドサービスが維持されるとは限りません。Wi-Fiとモバイルデータを切り替えると、接続を再確立する必要があることがあります。Webログインが必要なネットワーク、モバイルデータがまだ使えない場合、省電力状態への移行時には特に注意が必要です。まず直接接続を確認してからクライアントを再接続し、ネットワーク切り替えの問題をサブスクの失効と取り違えないようにしましょう。

v2rayNGとv2flyNGではコアの系統が異なります。設定が使えるかどうかは、共有リンクを読み込めるかではなく、コアがそのプロトコル、通信方式、設定項目に対応しているかで決まります。別のクライアントに切り替える場合は、サブスクを改めて追加して個別に動作を確認し、もう一方のアプリの内部ファイルをそのままコピーしないでください。サービス提供元から特定のコア機能を求められている場合は、その要件に従います。互換性に関する明確な要件がなければ、まず一つのクライアントの設定を安定させてから、別の選択肢を検討してください。二つのアプリを交互に起動すると接続状態が分かりにくくなります。

システムプロキシとTUN：通信の取り込み範囲とローカルポート

通信の入口とルーティングの出口を分けて考える

システムプロキシは、その設定に従うアプリに対し、リクエストを本機のHTTPまたはSOCKSプロキシへ送るよう指定します。すべての通信を強制的に取り込むものではありません。一方、TUNは仮想ネットワークインターフェースとルートを使い、該当する経路に入ったパケットをプロキシコアへ渡します。より広い範囲を扱えますが、ルーティング、アプリの除外、システムの制限に左右されます。グローバルプロキシルールはコア内部で出口を選ぶ設定であり、すべてのアプリがコアに通信を渡しているという意味ではありません。まずリクエストがクライアントに届いているかを確認してから、直結かプロキシかを検討すると、異なる段階の問題を混同せずに済みます。

「システムプロキシを自動設定」は、通常、現在のローカルプロキシの接続先を設定します。「システムプロキシをクリア」は関連設定を解除し、「システムプロキシを変更しない」は現在の状態を維持します。最後の選択肢は、コアが停止したり、以前の設定が自動で復元されたりするという意味ではありません。トラブルの切り分けでは、クライアントが待ち受け中か、システムがそのポートを指しているか、アプリがシステム設定に従っているかを確認してください。異常終了後もシステムプロキシ設定が残ると、ブラウザーは待ち受けプロセスのないポートに接続し、すべてのサイトが同時に開けなくなることがあります。

ローカル待ち受け、LAN、モードの併用

ローカルのHTTP、SOCKS、または混合ポートは、アプリからクライアントへ接続するための入口であり、リモートサーバーのポートではありません。混合ポートは通常、コアが対応する複数のプロキシリクエストを受け付けますが、対応プロトコルは設定の説明を確認してください。初めて使う場合は既定の待ち受け設定を維持します。ログにアドレスの使用中と表示されたら、競合プロセスを調べるか、空いているポートを選んでください。待ち受けアドレス、サーバーアドレス、サブスクURLを取り違えないようにしましょう。ループバックアドレスで待ち受けている場合、基本的に本機からのみアクセスできます。ほかの端末から、その端末自身のループバックアドレス経由でこのPCに接続することはできません。

「LANからの接続を許可」は接続できる範囲を広げる設定です。プロキシを共有する明確な目的がある場合にのみ有効にしてください。有効にすると、待ち受けアドレス、ファイアウォール、プロキシ認証も関係します。LANを信頼できるという理由だけで入口を長期間公開しないでください。別の端末から接続する場合は、クライアントを実行しているPCのLANアドレスと実際の待ち受けポートを使い、アクセス可能なネットワークを制限します。通常の1台だけでの利用なら、ローカルからの接続に限定するほうが管理しやすくなります。トラブルの切り分け中にLAN接続を許可し、ポートを変更し、TUNを有効にすると、どの変更が結果に影響したのか分かりにくくなります。

TUNの有効化と元に戻す手順

TUNを有効にする前に、使用可能なシステムプロキシ設定を保存し、リモートへの接続を確認します。その後、プラットフォームの要件に従って権限、コンポーネント、サービスを設定してください。有効化したら、コアが動作し続けているか、ルートとDNSが想定どおりに設定されたかを確認します。ネットワーク全体が使えなくなった場合は、まずTUNを無効にして残存するシステムプロキシをクリアし、直接接続を確認してください。直接接続が復旧したら、動作が確認できているシステムプロキシ経由の手順に戻します。TUNの障害中にサーバーの通信設定を次々と変更すると、正常に動作していた比較対象を失うため避けてください。

実装によっては、二つのモードを必ず排他的に使う必要はありません。ただし、初回の切り分けでは経路を一つに絞ってください。ローカルプロキシに明示的に接続するアプリの通信をTUNが取り込み、除外設定やループバック処理が適切でない場合、処理がループしたり重複したりすることがあります。クライアントのプリセットに従い、プロキシサーバーのアドレス自体を同じプロキシの出口へ強制的に戻さないでください。UDPを使うアプリ、ゲーム、リアルタイム通信に問題がある場合は、アプリの通信がコアに届いているか、リモート側が該当する転送に対応しているか、現在のネットワークで通信が許可されているかを個別に確認します。Webページのテストだけで、すべての通信を検証したことにはなりません。

設定後は、接続、停止、再接続の一連の動作を確認してください。接続中に目的のサイトが開けること、停止後に直接接続が復旧すること、再起動時にポートやルートの競合が起きないことが確認できてから、自動接続や常時バックグラウンド動作を有効にします。システムのネットワーク設定を変更する前に元の値を記録し、管理対象端末の制限を無理に上書きしないでください。モードは、必要なアプリに合わせて選びます。通信の取り込み範囲が広いほど適切とは限りません。

ルーティングとDNS：ルールの順序と振り分けの確認

プリセットから始め、ルールの適用順を確認する

ルーティングは、ドメイン、宛先IP、ポートなどの条件に応じて通信の出口を選びます。前提として、通信がプロキシコアに届いている必要があります。初めて使う場合はクライアントのプリセットを選び、通常のアクセスが安定してからカスタムルールを一つずつ追加してください。「中国本土をバイパス」などのプリセットは、ルールリソースを使って直接接続とプロキシの範囲を分けますが、実際の動作は使用中のコアとルールファイルによって異なります。「グローバル」もクライアント内の出口ポリシーとして捉え、OS上のすべてのアプリを取り込む設定とは区別してください。設定前に、直接接続したいサービスとプロキシ経由にしたいサービスを明確にしておきましょう。

ルールは通常、設定された順に評価され、最初に一致したルールが適用されます。そのため、範囲の広いルールより具体的な例外を先に置いてください。広範囲を対象とする直接接続ルールがあると、後に追加した詳細なプロキシルールが評価されないことがあります。変更は一度に一つにし、テストしたドメイン、想定した出口、実際のログを記録します。異なるコア向けのルールをそのまま結合しないでください。フィールド名が似ていても、リソース形式、タグ名、既定の動作が異なる場合があります。GUIのルーティング編集機能とコアの生設定は別の階層です。画面で対応しているインポート方法を使用してください。

ドメイン、IP、ルールリソースの関係

ドメインルールはサイトやサービスの振り分けに、IPルールは明確なネットワーク範囲や名前解決後のアドレスの指定に適しています。通信がコアに届いた時点ですでにIPアドレスしかない場合、ドメインルールが一致するかどうかは、アプリのリクエスト方法、DNSの経路、スニッフィング設定にも左右されます。geositeやgeoipを使う場合は、対応するルールリソースが存在し、コアと互換性があることを確認してください。リソースの欠落やタグの誤りは、起動失敗や想定外のルール適用につながることがあります。ルールリソースの更新とサブスクの更新は別の処理です。トラブル時は個別に結果を確認してください。

以下はXray/V2Ray形式のルーティング例で、特定ドメインのサフィックスとプライベートIPv4ネットワークを直接接続する方法を示しています。完全な接続設定ではありません。directというタグの直接接続用出口が既存の設定に定義されている必要があり、定義がなければそのまま使用できません。この例にはプロキシサーバーの設定も、ルールに一致しない通信の既定の接続先も含まれていません。GUIがルールを一件ずつしか受け付けない場合は、項目ごとに入力してください。オブジェクト全体をドメイン入力欄に貼り付けたり、クライアントが生成した完全な設定を置き換えたりしないでください。

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

DNSとルーティングの問題を分けて調べる

DNSはドメイン名をIPアドレスに変換しますが、名前解決に使う経路とWeb接続の出口は同じとは限りません。システムDNS、クライアント内蔵DNS、ブラウザーの暗号化DNSが処理に関与することがあります。ブラウザーが独自に名前解決している場合、クライアントのログに記録されたドメイン情報とシステムの検索結果が異なることがあります。まずどのコンポーネントが名前解決しているかを確認し、それから設定を変更してください。システムのリゾルバー、ブラウザー設定、コアのDNSを同時に変更しないでください。静的IPを使った比較は原因の範囲を絞るのに役立ちますが、通常のドメイン名でのテストの代わりにはなりません。TLSや仮想ホストでは正しいホスト名が必要な場合があります。

一部のサイトだけに問題があり、大半のサイトが使える場合は、対象サイトの出口が誤っていないか、想定外のルールに一致していないか、名前解決後のアドレスが適切かを比較します。ルールの切り替え後にだけ問題が起きた場合は、サブスクを変更するより、直前に使えていたルールへ戻して確認するほうが的確です。IPv6も確認対象です。システムがIPv6アドレスを優先して取得し、通信の取り込み経路やリモート側が該当通信に対応していないと、不安定になることがあります。実際のネットワーク機能に合わせてデュアルスタックの経路を設定し、根拠なくすべてのIPv6機能を原因と決めつけないでください。

ルールをテストするときは、長時間接続したページを再読み込みするより、新しい接続を確立するほうが確実です。ブラウザーのキャッシュ、接続の再利用、アプリ内キャッシュにより、以前の出口がしばらく使われることがあります。必要に応じて対象アプリを終了して開き直し、コアのログで一致したルールを確認してください。ルールの構造に慣れていない場合は、ドメイン・IP・ルーティングルールの設定例を参照してください。複数のサブスクを使う場合は、まずグループを分けて複数サブスクのグループ管理を確認しましょう。サーバーの絞り込み条件と通信のルーティング条件を混同しないようにしてください。

設定のよくある質問：障害の段階に応じて接続を復旧する

まず、どの段階で失敗しているかを特定する

トラブルの切り分けはローカルから始めます。プログラムが起動するか、コアが動作し続けるか、ローカルポートで待ち受けているか、アプリがリクエストをクライアントに渡しているか、リモートに接続できるか、最後にルーティングとDNSが正しいかの順に確認してください。各段階で結果を一つずつ記録すると、プログラムの再インストールやサブスクの変更を同時に行うより効率的です。エラーの種類と発生時刻を記録しますが、ログを外部に共有する前にサブスクURL、ユーザー識別子などの認証情報を削除してください。診断中だけ必要に応じてログレベルを上げ、原因が分かったら通常のレベルに戻します。接続記録を不必要に長期間保存しないようにしましょう。

すべてのサーバーで同時に失敗する場合は、ローカルネットワーク、システム時刻、コアの起動状態、サブスクの有効期限、プロキシモードなど共通の要因を優先して確認します。一部のサーバーだけが失敗する場合は、その設定のアドレス、ポート、通信方式、TLSパラメーターを調べてください。サブスクの更新でサービス提供元の設定変更に対応できることはありますが、ローカルポートの競合や権限不足は解消しません。段階ごとの詳しい確認方法はノードのタイムアウト・接続失敗の確認手順を、簡潔なQ&Aはよくある質問をご覧ください。

サブスク、接続テスト、ブラウザーでのアクセス

終了時の復旧、アップデート、設定のバックアップ

アップデート前に、インストール方法、設定フォルダー、使用中の画面バージョンを記録し、サブスクグループとカスタムルーティングをエクスポートして、管理された場所にバックアップします。設定のバックアップにはサーバーの認証情報が含まれることがあるため、公開フォーラムにそのまま投稿しないでください。アップデート後は、まず以前の最小限の接続手順を確認してから新しい設定を調べます。設定の移行に問題がある場合は、同じフォルダーで複数のバージョンを交互に起動して保存を繰り返さないでください。設定を作り直す必要がある場合は、完全なサブスクからサーバーを復元してから、手動のルーティングやアプリのルールを一つずつ移行します。一度にすべてをコピーして誤った状態を持ち込まないようにしましょう。

復旧後は、接続、停止、再接続の3つの操作で最終確認し、使用したモードとポートを記録してください。次回同じ問題が起きたとき、すべての設定を最初から変更せず、動作確認済みの状態に戻せます。初めて使う方はクイックスタートガイドに戻って手順を確認してください。プラットフォームとアーキテクチャが分かっている場合は、インストーラーのダウンロードページから該当するクライアントを選べます。このガイドでは設定の適用範囲を説明しています。メニューや権限に関する表示は、使用中のクライアントとOSの画面を確認してください。