V2Ray インストール・設定ガイド

設定前の確認

共通の事前準備：プラットフォームと設定情報を確認

クライアント、コア、サーバー設定の違い

デスクトップではv2rayNが利用でき、Windows、macOS、Linuxに対応しています。AndroidではXrayコアを採用するv2rayNGが第一候補です。V2Flyコアの環境が必要な場合はv2flyNGを検討してください。GUIクライアントは設定の保存、サブスクリプションの更新、実行パラメーターの生成、コアの制御を担い、実際の接続処理はコアのプロセスが行います。クライアントをインストールしても、利用可能なサーバーが自動で用意されたり、サブスクリプションが作成されたりするわけではありません。開始前に、正規に取得した有効な設定を用意し、対応するプロトコルとトランスポートの組み合わせを確認してください。

サーバーアドレス、ポート、ユーザーID、トランスポート方式、安全設定は一組で使用します。同じプロトコル名だからといって、別の設定のTLS、パス、サーバー名を組み合わせてはいけません。特にVLESSやTrojanでは、認証情報と通信経路のセキュリティ設定はそれぞれ役割が異なり、どれか一つが欠けても接続タイムアウトとして現れることがあります。リンクをインポートできない場合は、単一サーバーの共有リンク、サブスクリプションURL、設定ファイルのどれなのかを確認し、それぞれに対応した方法で取り込んでください。同じテキスト欄に何度も貼り付けても解決しません。

デバイスのアーキテクチャ、時刻、ネットワークの基本状態を確認

ダウンロード前にシステム情報を確認します。Windowsでは「システムの種類」、macOSでは「このMacについて」のチップ情報、Linuxではプロセッサーアーキテクチャとディストリビューションのパッケージ形式を確認してください。最近のAndroid端末の多くはarm64ですが、実際に対応するABIを基準に選びます。購入時期だけで判断しないでください。インストーラーの形式とCPUアーキテクチャは別の要素です。debとrpmはパッケージ管理方式、x64とarm64は実行可能なプログラムを決めます。ダウンロードページの表記が両方に合っているか確認してください。

システムの自動時刻設定を有効にし、タイムゾーンが適切であることを確認してください。時刻がずれていると証明書の有効期間判定に影響し、時刻に依存する認証にも支障が出ることがあります。次に、プロキシを無効にした状態で普段使うWebサイトを開き、ネットワークの基本状態を確認します。通常のネット接続自体に問題がある場合は、Wi-Fi、ゲートウェイ、ネットワークのログイン画面などを先に確認してください。テスト中は他のプロキシやVPNアプリを一時終了し、同じシステム設定が何度も上書きされないようにします。企業の端末では管理者がプロキシポリシーを適用している場合があり、ボタンの切り替えを繰り返しても解決しません。

元に戻せる初期状態を用意する

初回は設定を1組だけインポートし、サーバーを1台選び、クライアントの基本ルーティングを使用してください。TUN、独自DNS、リモートルール、複数の実験的なオプションを同時に有効にしないでください。設定を一つ変えるごとに同じテスト先へ再接続し、変更前後の違いを記録します。こうすれば、問題の原因を直前に変更した層に絞り込めます。設定を変更する前に、現在の状態を保存するか画面を撮影してください。ただし、スクリーンショットではサブスクリプションURL、ユーザーID、認証情報を隠します。リンクに見える情報でも、アカウントへのアクセス権を含むことがあります。

最後に、検証方法を決めます。目的のページがブラウザーで開くか、クライアントに該当する接続ログがあるか、通常は直接接続するサイトに引き続きアクセスできるかを確認してください。遅延テストが一度成功しても、特定のテストへの応答を確認できたにすぎず、Webページ、DNS、すべてのアプリの設定が済んだことを意味しません。以降のプラットフォーム別の説明は「インストール、インポート、通信の振り分け、検証」の順に進みます。該当するプラットフォームの章へ直接進む場合も、最初の基本状態の確認は省略しないでください。

デスクトップ / Windows

Windows：v2rayNのインストールとシステムプロキシ

デスクトップ版と従来のWPF版を選ぶ

Windowsのダウンロードからv2rayNを選択します。デスクトップ版は新世代のクロスプラットフォームUIを採用し、従来のWPF版はWindows向けのデスクトップUIを引き続き使用します。使い方や実際の互換性に応じて選び、接続状況を比較するために両方を同時に起動しないでください。ダウンロードページにあるx64インストーラーは、対応するシステムアーキテクチャで利用できます。実行前にインストーラーの案内を確認してください。システムに実行コンポーネントが不足している場合は、クライアントまたはインストーラーの説明に従って追加します。出所不明のサイトから同名のDLLファイルをダウンロードし、プログラムに上書きしないでください。

インストール後は、まず通常のユーザー権限で起動してください。メイン画面が開いても、コアが起動したとは限りません。ログ画面で設定の読み込みとローカルの待ち受け状態を確認します。プログラム本体とユーザーデータは別の場所に保存される場合があります。更新や移行の前に、クライアントのエクスポート機能で設定をバックアップしてください。展開先の一時フォルダーにインストールして後から削除したり、起動中にプログラムのフォルダーを移動したりしないでください。次回起動時にコア、ルールファイル、保存済み設定が見つからなくなることがあります。

サブスクリプションを追加して使用するサーバーを選ぶ

サブスクリプショングループまたは管理画面を開き、見分けやすいグループ名を付けます。完全なサブスクリプションURLをURL欄に入力して保存し、更新を実行してください。単一の共有リンクの場合は、クリップボードからのインポートなど適切な機能を使い、無理にサブスクリプショングループを作成する必要はありません。更新後、想定した設定が一覧にあることを確認し、ダブルクリックするか、メニューから使用するサーバーに設定します。一覧にサーバーが表示されることと、実際にそのサーバーを使用していることは別です。有効状態の表示とコアの実行状態の両方を確認してください。

サブスクリプションの更新に失敗した場合は、ログで解析エラー、認証エラー、リクエストのタイムアウトのどれかを確認します。初回接続が確立していない状態では、プロキシ経由での更新が循環依存になることがあります。直接接続での更新を試すか、設定の提供元が許可する別の取得方法を利用してください。一覧に内容を表示させるために、セキュリティチェックをすべて無効にしてはいけません。更新に成功しても一覧が空の場合は、グループのフィルター、アカウントの有効性、応答の形式を確認します。コピーしたサブスクリプションURLに改行や末尾の句読点が混入していないかも確認してください。

まずシステムプロキシを使い、必要に応じてTUNを設定

使用するサーバーを選んだら、システムプロキシを「システムプロキシを自動設定」にするか、実際の画面で同じ意味の項目を選択します。Windowsのシステムプロキシ設定に従うアプリはローカルプロキシを経由しますが、すべてのネットワークアプリが対象になるわけではありません。ブラウザーの拡張機能やアプリ独自のプロキシ設定が優先される場合もあります。コマンドラインツールもシステムプロキシを参照しないことがよくあります。その場合、すぐにサーバーを変更するのではなく、リクエスト時にクライアントのログへ接続が記録されるかを確認し、リクエストがローカルの接続口に届いているかを判断してください。

より多くのアプリの通信を扱う必要がある場合に、TUNを有効にし、プログラムの案内に従って必要な権限を許可してください。TUNは仮想ネットワークインターフェース、ルーティング、DNSに関わる機能で、システムプロキシボタンの別表現ではありません。初回テストではシステムプロキシを無効にして接続経路を一つに絞り、検証後にクライアントの推奨に従って組み合わせを設定できます。ドライバー、仮想NIC、ルーティングのエラーが発生した場合は、ログを記録して権限や他のVPNアプリを確認してください。原因の切り分けにファイアウォール全体を無効にしてはいけません。

接続を確認し、終了後に設定を戻す

ブラウザーでプロキシが必要なサイトと、直接接続するサイトの両方にアクセスし、ログに記録されたアウトバウンドを確認してください。ブラウザーでは使えるのにターミナルでは使えない場合は、システムプロキシとターミナルを分けて確認する方法を参照し、アプリごとの差をサーバーの問題と決めつけないでください。使用を終える前にシステムプロキシを解除してからクライアントを終了します。異常終了後にブラウザーでプロキシに接続できないと表示された場合は、Windowsのネットワークプロキシ設定が停止中のローカルポートを指したままになっていないか確認してください。設定を戻してからクライアントを再起動し、接続をテストします。

デスクトップ / macOS

macOS：チップ、権限、ネットワークサービスの設定

チップに合ったv2rayNをインストール

macOSのダウンロードを開き、Apple Silicon搭載端末ではarm64、Intel搭載端末ではx64を選択します。チップの情報は「このMacについて」で確認できます。外観や機種名だけで判断しないでください。DMGをダウンロードして開き、インストール画面の案内に従ってアプリを「アプリケーション」フォルダーへ移動し、正式な保存先から起動します。ディスクイメージ内で長期間アプリを実行すると、イメージの取り出し、アプリの更新、再起動後にパスや権限の問題が起きやすく、メンテナンスもしにくくなります。

初回起動時にシステムのセキュリティポリシーで制限されることがあります。アプリの入手元と選択したプラットフォームを確認し、「システム設定」の「プライバシーとセキュリティ」に許可する項目があるか確認してください。管理対象のデバイスでは、ユーザー自身で許可できない場合があり、その際は管理者への相談が必要です。一つのアプリを実行するためにシステム全体のセキュリティ機能を無効にしたり、内容を理解せずにシステム属性をまとめて削除したりしないでください。アーキテクチャが一致しないという警告が出た場合は、ダウンロードページに戻って正しいパッケージを選び直します。起動エラーをすべて権限の問題と判断しないでください。

設定をインポートしてコアの状態を確認

v2rayNでサブスクリプショングループを作成し、URLを保存して更新した後、設定の一つを使用するサーバーに指定します。共有リンクを1件だけ取り込む場合はクリップボードからのインポート機能を使い、設定ファイルを読み込む場合は現在のクライアントに対応する形式か確認してください。コア専用のJSONファイルをサブスクリプションURLとして扱わないでください。設定が表示されたら実行ログを確認し、コアがすぐに終了していないことを確かめます。バックグラウンドプロセスだけに問題が起きても、メイン画面は操作できる場合があります。「画面が開く」ことだけをインストール完了の判断基準にしないでください。

まず初期設定または基本ルーティングで接続をテストし、その後DNSとルールによる振り分けを一つずつ調整します。コアを切り替える前に、使用するプロトコルとトランスポート方式が切り替え先のコアでサポートされているか確認してください。同じ設定名が表示されても、生成されるパラメーターまで互換性があるとは限りません。切り替え後に未知のフィールドや設定の解析エラーが出た場合は、元のコアに戻して、クライアントが生成した設定に関する案内を確認します。UIと手書きの設定を何度も上書きすると、次回の保存で変更が元に戻ることがあるため避けてください。

システムプロキシとネットワークサービスの関係

macOSのプロキシ設定はネットワークサービスごとに管理されます。システムプロキシを有効にした後、現在使用しているのがWi-Fi、有線LAN、その他のサービスのどれかを確認してください。インターフェースを切り替えた後に一部のアプリだけ直接接続へ戻った場合、新しいネットワークサービスに対応する設定がない可能性があります。システム設定のHTTP、HTTPS、SOCKSの各プロキシ欄にはそれぞれ異なる役割があります。アドレスがすべてローカルでも、ポートを相互に使い回すことはできません。クライアントによる自動設定を使う場合は、まず自動生成された設定を保ち、接続を確認してから必要な項目だけ手動で変更してください。

ブラウザーはシステムプロキシに従うこともありますが、拡張機能やアプリ独自のネットワーク設定が優先される場合もあります。ターミナルのプログラムでは独自のプロキシ引数や環境変数が必要になることが多く、メニューバーでプロキシが有効になっていても自動的には切り替わりません。ネットワークを切り替えた後は、既存の接続が以前の経路を使い続けることがあるため、新しい接続でテストしてください。同じ接続先に新しいリクエストを送り、ログを確認します。ページのキャッシュ、既存の接続、アプリのバックグラウンド再試行を、現在の設定が適用された結果と取り違えないようにしてください。

TUNの許可、スリープ、復帰

TUNが必要な場合は、クライアントの案内に従って権限を許可してください。仮想インターフェースの作成やルーティングの変更には追加権限が必要なことがあります。具体的な方法は、現在のアプリの実装に従ってください。有効にした後、すべてのネットワーク接続が切れた場合は、まずTUNを無効にしてネットワークを復旧させ、ログからインターフェース作成、ルート設定、DNSのエラーを確認します。別のVPNの全通信を同時に有効にして問題を「補おう」としないでください。デフォルトルートを取り合い、問題の再現が難しくなることがあります。業務用デバイスでは、セキュリティソフトがネットワーク操作を制限している場合もあります。

終了前にシステムプロキシを解除し、ブラウザーが直接接続に戻るか確認してください。アプリの終了後もWebページでローカルプロキシへの接続エラーが表示される場合は、現在のネットワークサービスのプロキシ設定に項目が残っていないか確認します。最初からネットワークサービス全体を削除したり、すべてのネットワーク設定をリセットしたりしないでください。サブスクリプションとルーティングの設定は残し、通信の振り分け部分だけを元に戻せば、影響を抑えられます。復旧を確認した後、クライアントに戻り、機能を一つずつ有効にして検証してください。

デスクトップ / Linux

Linux：パッケージ、デスクトッププロキシ、実行権限

アーキテクチャとディストリビューションの形式を合わせる

Linuxではデスクトップ版v2rayNを使用します。まずLinuxのダウンロードでdebとrpmを選び、次にx64またはarm64を選択してください。DebianやUbuntuなどでは一般にdeb、Fedoraなどでは一般にrpmを使いますが、実際には本機のパッケージ管理システムに合わせてください。次の読み取り専用コマンドでアーキテクチャとシステム情報を確認できます。出力のx86_64は通常x64、aarch64は通常arm64に対応します。別形式のパッケージとしてインストールするために、ファイルの拡張子だけを変更しないでください。

uname -m
cat /etc/os-release

ダウンロード後は、デスクトップのソフトウェアインストーラーでパッケージを開くか、ディストリビューションのドキュメントに沿ってパッケージ管理ツールからインストールします。依存関係が不足している場合は、パッケージ管理ツールが示す項目を確認し、現在のデスクトップ環境とシステムバージョンが要件を満たしているか判断してください。別のディストリビューションのシステムライブラリをシステムフォルダーへ直接コピーしないでください。インストールの失敗とクライアント設定の失敗は別の段階です。前者ではパッケージ、依存関係、アーキテクチャを解決してから、後者のサブスクリプションやコアのパラメーターを確認します。混同すると調査する要素が増えてしまいます。

まず通常ユーザーで起動してインポートする

インストール後、アプリメニューからv2rayNを起動し、通常ユーザーとしてサブスクリプショングループを作成してURLを保存、更新してください。更新に成功したら使用するサーバーを選び、コアのログが待ち受け状態になっているか確認します。デスクトップのアイコンからメイン画面が開かない場合は、デスクトップ環境のアプリログ機能からエラーを確認してください。すぐに管理者権限で画面全体を実行しないでください。ユーザーが異なるとデータの保存先やファイルの所有者も変わり、通常のユーザーでは元の設定を書き込めなくなることがあります。

高い権限で起動したため設定を書き込めなくなった場合は、まずプログラムを終了し、実際のデータディレクトリを特定してください。その後、システムの管理方法に従ってディレクトリの所有者を修正します。ホームディレクトリ全体の権限を再帰的に緩めないでください。サブスクリプションURLやエクスポートした設定は機密情報です。必要なユーザーだけがアクセスできるよう、ディレクトリの権限を制限します。クライアントの更新時はユーザーデータを保持し、更新後にコアのパスやルールファイルが引き続き見つかることを確認してください。GUIアプリの更新に成功しても、外部ファイルへの既存のパスが有効とは限りません。

デスクトップのシステムプロキシが適用される範囲

Linuxのシステムプロキシは、すべてのアプリで共通の一つのスイッチではありません。GNOMEやKDEなどのデスクトップ環境にはそれぞれプロキシ設定があり、アプリによっては環境変数、独自の設定ファイル、起動引数だけを参照します。v2rayNがデスクトップのプロキシ設定を変更するとブラウザーでは使えるようになっても、ターミナルのリクエストは直接接続のままの場合があります。まずはアプリごとの差として切り分け、リクエストがクライアントに届いているか確認してください。そのうえで、個別のツールに設定を追加するか、より多くの通信を扱えるTUNを使うかを判断します。

以下のコマンドはローカルSOCKSの接続口を使ってサンプルサイトへリクエストを送り、「ツールからローカルプロキシまで」の経路を確認するものです。ポート番号はクライアントで実際に待ち受けている値に置き換えてください。例ではsocks5hを使っており、接続先ドメインの名前解決をプロキシ側で行います。このテストの成功で確認できるのは、指定した接続口を経由したリクエストが成功したことだけです。デスクトップのシステムプロキシ、他のターミナル、すべてのアプリで設定が有効とは限りません。接続拒否が表示された場合は、まずコアの起動状態とポート番号を確認してください。

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

TUNの権限とネットワーク管理の競合

TUNは仮想ネットワークデバイスへのアクセスと関連ルートの管理を必要とします。権限を付与する方法はクライアントのパッケージ方法やシステムポリシーによって異なるため、まずアプリが用意する手順を使ってください。インストールディレクトリ全体にむやみに強い権限を付与しないでください。有効化に失敗した場合は、仮想デバイスの使用可否、権限拒否の有無、他のVPNとのデフォルトルートの競合を個別に確認します。コンテナや制限されたデスクトップセッションでは、必要なデバイスや権限自体がない場合があります。スイッチを何度も操作しても解決せず、システム全体のセキュリティを緩めることも避けてください。

Linuxでは、システムの名前解決サービスとクライアントのDNSの境界にも注意が必要です。システムがローカルのスタブリゾルバーで問い合わせを処理する一方、TUNが別の名前解決経路を引き受けることがあります。ドメイン名だけで失敗する場合は、システムの名前解決とプロキシ経由のリクエストを比較してください。ネットワーク管理ツール、名前解決サービス、クライアントの3か所を同時に変更しないでください。終了後はデスクトッププロキシと一時的な環境変数が元に戻っていることを確認します。特定のターミナルだけで問題が起きる場合は、そのセッションの環境変数を調べ、クライアントを再インストールしないでください。

モバイル / Android

Android：VPNの許可とバックグラウンド実行

v2rayNGとv2flyNGを選ぶ

AndroidではXrayコアを採用するv2rayNGが第一候補です。V2Flyコアの環境が必要な場合はv2flyNGを選べます。Androidのダウンロードでは、各クライアントのarm64版と汎用インストーラーを配布しています。最近の端末の多くはarm64に対応していますが、OSのビット数や端末の対応状況を実際に確認してください。判断が難しい場合は汎用パッケージを検討できます。画面の見た目が似ていても、設定機能が完全に同じとは限りません。プロトコル、トランスポート、安全設定の対応状況は、それぞれのコアによって異なります。

APKをインストールする際、Androidからブラウザーやファイル管理アプリにアプリのインストール権限を許可するよう求められることがあります。今回使用する入手元に限って必要な権限を許可し、インストール後に必要であれば取り消してください。アプリをインストールできないと表示された場合は、端末のアーキテクチャ、空き容量、既存アプリとの署名の競合を確認します。上書きインストールに失敗しても、パッケージが壊れているとは限りません。アンインストールして再インストールする前に、クライアントの機能で必要な設定をバックアップしてください。アンインストールするとグループ、ルーティング、アプリの選択が消えることがあり、再インストール後に自動で復元されるとは限りません。

サブスクリプションの追加と初回のVPN許可

サブスクリプション設定を開き、グループを追加して完全なURLを入力し、保存します。次に一覧に戻ってサブスクリプションを更新し、使うサーバーを選択してください。共有リンクを1件だけ読み込む場合は、クリップボードまたはQRコードからインポートします。ただしQRコードにアカウント情報が含まれることもあるため、公開の場で共有しないでください。インポート後は、プロトコルと必要な設定項目を確認し、表示名だけで判断しないでください。複数のグループがある場合は、現在のフィルターでインポートした設定が隠れていないか確認します。更新が完了しても、使用するサーバーが自動で切り替わるとは限りません。

接続をタップするとAndroidのVPN接続許可が表示されます。許可すると、クライアントはAndroidのVpnServiceを通じて通信を扱えるようになります。VPNのアイコンが表示されても、システムのインターフェースが作られたことを示すだけで、接続先サーバーの認証成功やWebページの表示を保証するものではありません。クライアントのログを確認し、テスト先へ実際にアクセスしてください。通常のアプリが同時に使えるシステムVPNは一つです。他のVPN、広告ブロック、ネットワーク保護アプリが使用中の場合があります。どのアプリを使うか決めてから、接続を再試行してください。

ルーティング、アプリごとの振り分け、ローカルプロキシ

まずクライアントの基本ルーティングで接続し、必要に応じてアプリごとのプロキシ設定を行います。画面によって「選択したアプリをプロキシ経由にする」と「選択したアプリを除外する」の意味が逆になることがあります。保存前に現在のモードを確認してください。ブラウザーを選ぶ場合は、外部アプリ、ダウンロード管理アプリ、システムサービスを呼び出すページにも注意します。これらはブラウザーと同じアプリとして扱われないことがあります。特定のアプリの問題を調べるときは、一時的に通信を広い範囲で振り分けてみてください。使えるようになった場合は、対象範囲を一つずつ狭めて不足している項目を特定します。

AndroidのVPNによる通信の振り分けは、デスクトップのシステムHTTPプロキシとは異なります。通常はWi-Fiの詳細設定にローカルプロキシを追加する必要はありません。追加すると、クライアントを停止した後にネットワークへ接続できなくなることがあります。クライアントに表示されるローカルSOCKSポートは、プロキシを明示的に使うアプリ向けです。通常、同じLAN上の他の端末からアクセスできるわけではありません。テストのために待ち受けアドレスをすべてのインターフェースへ変更しないでください。端末間共有にはアクセス制御、ネットワーク分離、権限に関する新たな問題が伴います。

バッテリー管理、ネットワークの切り替え、切断からの復帰

画面を表示している間は正常でも、画面をロックしてしばらくすると切断される場合は、まずバッテリーの最適化とバックグラウンド動作の制限を確認してください。設定画面の場所はメーカーによって異なります。アプリ情報から必要なバックグラウンド実行を許可し、必要に応じて常時通知を有効にしてください。省電力設定の対象外にしても、バックグラウンドで終了されにくくなるだけで、サーバーやDNSの設定ミスは解決しません。画面消灯時に接続ログが止まり、アプリを開き直すと復旧する場合は、バックグラウンド制限の影響が考えられます。継続してハンドシェイクエラーが出る場合とは分けて確認してください。

モバイルデータ通信とWi-Fiを切り替えた後は、通常のネットワークでログインが必要な場合はそれを済ませてから、接続を確立し直してください。ネットワークによってUDP、DNS、接続先ポートの扱いが異なる場合があり、一つのネットワークでの結果だけでサーバー全体の状態は判断できません。バックグラウンドでの切断だけが問題の場合は、v2rayNGのバッテリー最適化とアプリごとの設定を参照してください。どちらのネットワークでもページを読み込めない場合は、アプリを何度も再インストールするのではなく、記事末尾のログを使った段階的な確認方法に従ってください。

プラットフォーム共通 / 設定の管理

サブスクリプション管理：更新、選択、バックアップ

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

サブスクリプションURLは通常、ネットワーク経由でサーバー設定の一覧を取得するために使います。単一の共有リンクは、一つのサーバーの情報を直接表します。どちらもクリップボードにコピーできますが、取り込み方は異なります。サブスクリプションはグループに保存して更新し、共有リンクは専用のインポート機能で読み込みます。WebページのURLがサブスクリプションURLとは限りません。アカウント管理ページ、説明ページ、ログイン後の転送先を設定情報の入手元として使うことはできません。更新ログに解析エラーが表示された場合は、URLの用途と返されるデータ形式を提供元に確認してください。

サブスクリプションURLにはアクセス認証情報が含まれることが多く、URLを知る人が同じアカウントのリソースを取得できる場合があります。完全なURLを公開フィードバック、オンライン解析サイト、スクリーンショットに貼り付けないでください。問題を説明する際は、エラーの種類、クライアント名、必要な範囲の機密性のないパラメーターだけを記載します。QRコード、エクスポートしたファイル、バックアップディレクトリも同様に扱ってください。URLが漏えいした場合は、提供元が用意する管理画面から再発行するか、古いURLを無効にします。ローカルの履歴を削除するだけでは、外部に保存されたコピーは無効になりません。

更新に使う経路と実際の通信経路を区別する

直接接続で更新するかプロキシ経由で更新するかは、サブスクリプション取得時の通信経路を決めるもので、サーバーのルーティングモードとは別です。利用できるサーバーがまだない初期状態では、プロキシ経由の更新が開始できない場合があります。既存の接続は使えるのに直接接続ではサブスクリプションにアクセスできない場合は、プロキシ経由の更新が必要なことがあります。リクエストのタイムアウト、認証拒否、内容の解析結果を見て判断してください。認証エラーが明確な場合は、更新経路を切り替えても通常は解決しません。アカウントの権限とURLの有効性を先に確認してください。

更新に失敗しても、すぐに既存の一覧を消去しないでください。まだ利用できる設定を残し、グループとエラー情報を記録してから、現在のネットワークでサブスクリプションの提供先へアクセスできるか確認します。古い設定を保持するクライアントもあれば、更新時にグループ内の項目を作り直すクライアントもあります。画面の案内と実際の結果で動作を確認してください。サブスクリプションから生成された項目を手動編集すると、次回の更新で上書きされることがあります。長期的に独自設定を使う場合は、クライアントが対応する複製機能や、個別に管理する方法を利用してください。

更新後に使用中の設定を確認する

サブスクリプションの更新成功は、取得と解析が完了したことを示すだけです。現在使用中のサーバーがまだ存在することや、そのサーバーに接続できることを保証しません。更新後は、有効状態、プロトコル、グループのフィルターを確認してから実際にリクエストを送ってください。表示名は重複したり変わったりするため、名前だけで同じ設定か判断できません。ポート、トランスポートのパス、安全設定が更新されることもあります。更新後に問題が起きた場合は、クライアントが新しい実行設定を読み込んだか確認してください。

遅延テスト、接続テスト、実際のWebページ表示は同じものではありません。テスト先、名前解決の方法、確認に使うプロトコルが違えば結果も異なります。サーバーがテストに応答しても、特定のサイトにアクセスできるとは限りません。並べ替え後の先頭にあるサーバーが、すべての用途に最適とは限りません。一つの設定を選び、決めたテスト先でページ表示、DNS、直接接続の例外を確認し、実際の利用状況に基づいて採用するか判断してください。一つのテスト数値だけを基準にしないでください。

設定の境界を含めてバックアップ・移行する

デバイスを移行する場合は、クライアントが対応する設定のエクスポートを優先してください。別のプラットフォームにプログラムのフォルダー全体を直接上書きしないでください。サブスクリプションURLは再インポートできますが、ローカルポート、ルーティングルール、アプリごとの選択、システムで通信を振り分ける権限は一緒に移行されない場合があります。特にAndroidのアプリ一覧とデスクトップのアプリパスには直接の対応関係がないため、プラットフォーム間で復元した後に改めて確認してください。バックアップファイルはアクセス制御された場所に保存します。個人的なメモであっても、認証情報をそのまま公開の同期データに含めないでください。

クライアントごとのサブスクリプションとコアの対応状況を比較する場合は、クライアント比較を参照してください。入手元と形式を確認せずにクライアントを次々とインストールしても解決しません。サブスクリプション自体が不正な内容を返している場合は、別のGUIクライアントを使っても同じ問題が起きる可能性があります。

プラットフォーム共通 / 通信経路

ルーティングとDNS：通信を振り分けてから接続先を決める

システムプロキシ、TUN、コアのルーティングが担う層

振り分けを調べる前に、リクエストがクライアントへ届いているか確認します。システムプロキシは、システム設定に従うアプリがローカルの接続口に接続する仕組みです。TUNは仮想ネットワークインターフェースを通じ、対象の通信を取り込みます。コアに届いた後で、ルールに従ってプロキシ、直接接続、その他の設定済みアウトバウンドが選ばれます。アプリがシステムプロキシを使っていない場合、コアのルールを変更しても効果はありません。逆に、リクエストがコアに届いているのにルールで直接接続に振り分けられている場合は、ブラウザーのプロキシボタンを調べても解決しません。ログはこの2つの状況を見分ける重要な手掛かりです。

「グローバル」と「ルール」は、クライアントによって異なる階層に表示されることがあります。システムプロキシの全体設定は通常、より多くのリクエストをローカルプロキシへ送るだけで、コアは引き続きルールに従ってアウトバウンドを選びます。コアの全体ルーティングモードによって振り分けが変わるクライアントもあります。現在変更しているのが、システムで通信を取り込む方法なのか、コアのルーティングモードなのかを確認してください。テストでは取り込み方法を固定してからルーティングを比較します。両方を同時に変えると、どちらが改善または失敗の原因か判断できなくなります。

最小限のルールでマッチ順を理解する

以下はXray形式の部分的なルーティング例です。サンプルドメインをdirectという名前のアウトバウンドへ送る方法だけを示します。単体では起動できない設定であり、使用するには完全な設定内で同名のアウトバウンドを定義する必要があります。実際のクライアントが別のタグを自動生成する場合は、その内容に合わせて調整してください。ルーティングは通常、ルールの順序に従って一致する項目を探します。前にある広い条件が後の詳細なルールより先に一致することがあります。例外を追加するときは、末尾に同じ条件を増やすのではなく、既存ルールを先に確認してください。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "direct"
      }
    ]
  }
}

完全一致ドメインとドメインサフィックスでは対象範囲が異なります。メインドメインだけにルールを設定しても、ページに必要な画像、認証、APIのドメインが含まれないことがあります。ページ本文は表示されてもログインできない場合は、失敗したリクエストのドメインとアウトバウンドを確認してください。ネットワーク全体を別のモードに切り替えるのは避けます。IPアドレスのルールにも同様の制約があります。IPv4とIPv6は異なるアドレスファミリーなので、片方だけを扱う設定ではもう片方のリクエストも想定通りに振り分けられるとは限りません。

システムの名前解決とコアの名前解決を区別する

DNSはドメイン名からIPアドレスを取得する仕組みですが、システム、ブラウザー、プロキシのコアはそれぞれ別の名前解決経路を使う場合があります。ブラウザーで独自のセキュアDNSを有効にすると、システムのリゾルバーとは異なる結果になることがあります。アプリがSOCKS接続口にドメイン名を渡すか、すでに解決済みのIPアドレスを渡すかによっても、コアが利用できるドメイン条件は変わります。まず、どの層で名前解決しているか、問い合わせがどのアウトバウンドを通るか確認してから、変更する箇所を決めてください。すべてのDNSを一度に変更すると、原因を特定できたはずの問題が複数の変数に分かれてしまいます。

以下の断片は、コアのDNSサーバー配列と問い合わせに使うアドレスファミリーの設定を示す部分的な例です。サーバーにアクセスできるかどうかは、ネットワーク、ルーティング、クライアントが生成する設定によって異なります。特定のパブリックDNSアドレスがあらゆるネットワークに適するとは限りません。暗号化DNSの接続先を名前解決する必要がある場合は、起動時にその接続先のアドレスを取得する方法も考慮してください。まだ確立していないプロキシ接続に名前解決を依存させると、互いの処理が待ち続けることがあります。

{
  "dns": {
    "servers": ["1.1.1.1", "8.8.8.8"],
    "queryStrategy": "UseIP"
  }
}

LAN、IPv6、UDPの範囲を確認

TUNを有効にした後、プリンター、LAN内のサービス、ローカル管理ページにアクセスできない場合は、プライベートアドレスやローカルサービスに適切な除外ルールがあるか確認してください。LAN内の一つのアドレスを解決するために、すべての通信を直接接続にしないでください。IPv6環境では、アプリが実際にどのアドレスファミリーを使うかも確認します。IPv4のテストに成功しても、デュアルスタックの通信がすべて正常とは限りません。音声通話、ゲームなどのUDPアプリでは、プロトコル、サーバー、通信の振り分け方法がその通信に対応するかも確認してください。

調整後にコアを再読み込みし、新しい接続で検証してください。既存の接続が以前のアウトバウンドを使い続けたり、アプリのキャッシュに古い名前解決結果が残ったりする場合があります。接続ログを確認せずに同じページを更新するだけでは、キャッシュによる違いをルールの不具合と誤認しやすくなります。

よくある設定トラブル / 層ごとに確認

設定トラブルの対処：ローカルの接続口からサーバーまで

現象を記録し、すべての設定を同時にリセットしない

トラブルの確認を始める際は、クライアント名、OS、使用中のコア、通信を振り分ける方法、失敗する接続先を記録してください。すべてのアプリで失敗するのか、特定のブラウザーやターミナルだけなのかも説明します。最後に成功してから変更した項目、サブスクリプションの更新、ネットワーク切り替え、システム更新、ルーティングの調整も記録してください。これらを「接続済みなのに使えない」の一言で済ませないでください。現象が具体的であれば原因を絞り込みやすくなります。ローカルポートが待ち受けていない段階でサーバーを次々と変えたり、アカウントが無効なのにDNSを変更し続けたりすることも防げます。

まずTUNとシステムプロキシを無効にして、通常のネットワークが使えることを確認します。その後、通信を振り分ける方法を一つだけ有効にしてください。無効にしても接続できない場合は、システムにローカルプロキシのアドレスが残っていないか、AndroidでVPN未接続時の通信がブロックされていないか、ネットワークへのログインが必要かを確認します。通常の直接接続が復旧して初めて、次の比較が意味を持ちます。設定を戻すときはサブスクリプションと既存ルールのバックアップを保持してください。すべてのデータを削除すると、比較に使える有効な設定まで失うおそれがあります。

ログから失敗した位置を特定

ログにポートの競合が表示された場合は、同じポートを使用している別のクライアントやアプリを終了してから、ローカルポートを変更するか判断します。ポートを変更した場合は、ブラウザー拡張機能、ターミナルの引数、その他の明示的なプロキシ設定も合わせて変更してください。接続拒否は、接続先が待ち受けていない場合によく起きます。接続タイムアウトは、指定時間内に接続が完了しなかったことを示すだけで、DNS、ネットワーク、サーバーのどれに問題があるかまでは分かりません。設定の解析エラーでは、システムプロキシを調整するより、フィールドとコアの互換性を先に確認してください。

リクエストがログに出てこない場合は、アプリからクライアントまでの経路を確認します。システムプロキシが有効か、ブラウザー拡張機能が優先されていないか、アプリごとのリストに対象が含まれているかを調べてください。リクエストが記録されていてハンドシェイクに失敗する場合は、サーバーアドレス、ポート、認証、トランスポート、安全設定が一組で正しいか、システム時刻が正確か確認します。リクエストが想定通りの経路に出ているのに特定のサイトだけ失敗する場合は、そのサイトの名前解決、証明書、ネットワーク応答を確認してください。一つの接続先の失敗だけで、クライアント全体が動いていないと判断しないでください。

よくある問題への対処範囲

問い合わせ時に必要な情報を残す

さらにサポートが必要な場合は、再現できる操作手順、失敗した時刻前後のログ、すでに確認した項目を提示してください。完全なサブスクリプションURL、ユーザーID、パスワード、その他の認証情報は隠し、原因の判断に必要な情報だけを残します。ログレベルを上げるとアクセス先が多く記録される場合があります。記録が済んだら適切なレベルに戻してください。公開の場に設定ディレクトリ全体をアップロードしたり、認証情報が写ったスクリーンショットで説明を代用したりしないでください。

接続済みと表示されるのにWebページを開けない場合は、接続後にインターネットへアクセスできない場合の確認リストに沿って確認してください。最短の手順で設定をやり直す場合はクイックスタートへ戻り、別のプラットフォーム用のインストーラーが必要な場合はダウンロードページを開いてください。正常に動作する最小限の設定を一つ保っておくと、ルールの追加、コアの切り替え、再インストールを繰り返すより、次のトラブルを特定しやすくなります。