V2Ray全プラットフォーム
インストール・設定ガイド

準備：OS、コア、接続情報

クライアントとコアの違い

v2rayN、v2rayNG、v2flyNGはいずれも、接続情報の保存、サブスクリプションの管理、ルールの設定、コアの起動に使うGUIクライアントです。プロトコルの処理、サーバーへの接続、通信の処理を担うのはコアです。Project Vは関連技術の重要な出発点であり、V2FlyとXrayはそれぞれ異なるコアの開発系統です。名前が似ていても、設定項目やプロトコル拡張、リソースファイルを自由に流用できるわけではありません。デスクトップではv2rayN、Androidでは通常Xrayを使うv2rayNGから試してください。V2Flyとの互換性が必要な場合は、v2flyNGも検討できます。

インストール前に、OS、CPUアーキテクチャ、使用するパッケージ形式を確認してください。OS名だけでは選択肢を絞るにとどまり、実行できるかどうかはアーキテクチャ、ショートカットや権限、更新方法はパッケージ形式によって決まります。ダウンロードできたからといって、そのファイルが端末に適しているとは限りません。デスクトップでは「このMacについて」などの情報画面でプロセッサを確認し、Androidでは端末情報からOSのバージョンを確認してください。アーキテクチャが分からない場合は、異なるインストーラーを試すのではなく、端末メーカーの仕様を参照しましょう。

入手元を確認できる設定情報を用意する

クライアントに利用可能なサーバーが付属しているわけではありません。使用権限のあるサブスクリプションURL、単一ノードの共有リンク、または使用するコアに対応した設定ファイルをあらかじめ用意してください。情報の種類によってインポート方法は異なります。サブスクリプションは再取得できるリモートURL、共有リンクは通常一つの接続情報、設定ファイルには待ち受けポートやアウトバウンド、ルーティングまで含まれることがあります。提供元に形式と対応クライアントを確認してからインポート方法を選べば、WebページのURLをサブスクリプションと誤認したり、JSON設定をノードリンク欄に貼り付けたりするのを防げます。

接続情報には、少なくともサーバーアドレス、ポート、プロトコル、対応する認証情報が必要です。TLSなどのセキュリティ層を使う場合は、サーバー名、トランスポート方式、関連パラメーターも確認してください。必要な項目はプロトコルごとに異なるため、警告を消す目的で適当な値を入力しないでください。端末の時刻は自動同期に設定しましょう。時刻が大きくずれていると、証明書の有効性判定に影響することがあります。また、リモート接続を試す前に、ローカルゲートウェイや通常のWebサイトにアクセスできることを確認してください。

シンプルな条件で接続を試す

初回の検証ではプロキシクライアントを一つだけ起動し、ほかのVPNやプロキシアプリ、通信を制御する可能性のあるブラウザー拡張機能を終了してください。元のシステムプロキシ設定を記録し、最初から複雑なルールやカスタムDNS、TUNを同時に有効にしないようにします。まずは一つのノードを一つの方式で接続し、動作を確認してから設定を追加してください。一度に変更する項目は一つにし、変更前の画面や設定を記録しておきましょう。すべてのオプションを一度に有効にするより、問題の原因を特定しやすくなります。

トラブル対処に備えて、クライアント名、OSのアーキテクチャ、使用中のコア、通信の制御方式、エラーが発生した操作手順を控えておきましょう。必要なのは利用環境の情報であり、設定ファイル全体ではありません。別の端末へ移行する場合は、新しい端末に必要な情報を再インポートして動作を確認してから、古い端末のデータを整理してください。「インストール成功」「サブスクリプション更新成功」「アプリの通信がプロキシを通過」は、それぞれプログラムの起動、設定の取得、実際の通信経路という別々の段階です。

Windows：v2rayNのインストールとプロキシ設定

デスクトップ版と従来のWPF版の選び方

Windowsクライアントからv2rayNを選択してください。デスクトップ版はクロスプラットフォームのUIを採用し、従来のWPF版はWindows向けの従来型UIを備えています。どちらも接続を管理する目的は同じですが、設定画面や実行環境、一部のメニュー位置が異なる場合があります。初めて使う場合はデスクトップ版から試すとよいでしょう。従来のUIを使った運用に慣れている場合は、用途に合わせてWPF版を選んでください。接続を比較するために2つのバージョンを同時に起動するのは避けましょう。ローカルの待ち受けポート、システムプロキシ、バックグラウンドプロセスが競合する可能性があります。

インストーラーを実行する前に、使用するパッケージの要件をシステムが満たしているか確認してください。ウィザードでインストール先を指定します。初回起動時に実行環境の不足が表示された場合は、案内されたコンポーネントを追加してからクライアントを再起動してください。名前の似た別のプログラムをダウンロードする必要はありません。ユーザー設定フォルダーに書き込めることも確認しましょう。制限された場所にインストールしたり、異なるアカウントで交互に起動したりすると、設定を保存できないことがあります。セキュリティソフトがブロックした場合は、ファイルのパスと理由を確認し、システムの保護機能全体を無効にしないでください。

サブスクリプションを追加して接続先を確認する

サブスクリプショングループの設定を開き、識別しやすい名前を付けて、完全なサブスクリプションURLを入力します。保存後に更新を実行してください。更新後は通知が消えたかだけでなく、サーバー一覧に項目が追加されたかを確認します。提供元から単一ノードの共有リンクを受け取った場合は、クリップボードからインポートする機能を使えます。ただし、継続的に更新されるサブスクリプションにはなりません。最初の接続テストでは、必要なパラメーターがそろったサーバーを一つ選んで有効にし、設定と現在のコアに互換性があるか確認しましょう。

更新に失敗した場合は、まずクライアントが設定内容を受信できたか確認してください。ログインページが返る、権限エラーが出る、形式に対応していないといった問題は、ノードへの接続タイムアウトとは別です。現在のネットワークからサブスクリプション元へ直接接続できない場合、利用可能な接続がすでにあることを前提に、プロキシ経由で更新を試せます。接続手段がない状態で更新方法を何度切り替えても、新たな通信経路は作られません。詳しい確認手順はサブスクリプション更新失敗・解析エラーのチェックリストをご覧ください。

まずシステムプロキシを使い、必要に応じてTUNを検討する

初めて接続する場合は「システムプロキシを自動設定」を有効にし、クライアントのコアが起動してからシステムプロキシを使うアプリを開くことをおすすめします。Windowsのシステムプロキシには通常、ローカルのループバックアドレスとクライアントの待ち受けポートが設定されます。これはリモートサーバーのアドレスではありません。ブラウザーからアクセスできても、その経路が使えることを示すだけで、すべてのデスクトップアプリがシステムプロキシを利用するとは限りません。独自のプロキシ設定を持つアプリでは、システム設定を使うか、対応するローカルの接続先を手動で指定してください。システム側とアプリ側の設定が食い違わないようにしましょう。

システムプロキシを使わないアプリの通信も制御する必要がある場合は、使用中のv2rayNで利用可能なTUN設定を確認してください。有効化には管理者権限や仮想ネットワークインターフェースの作成が必要な場合があります。クライアントに表示される許可内容を確認しましょう。TUNの起動後は、ネットワークインターフェース、ルート、DNSがすべて設定されたか確認します。スイッチがオンになっただけで成功と判断しないでください。リモートデスクトップ、業務用VPN、仮想マシンのネットワークはルーティング変更の影響を受けることがあります。テスト中もローカルで操作できる状態を保ち、通常のネットワークが切断されたらTUNを停止して元に戻してください。

終了、更新、プロキシ設定の戻し方

利用を終えるときは、クライアントでシステムプロキシを解除してから、通常の終了メニューでプログラムを閉じてください。プロセスが異常終了すると、Windowsの設定だけが残り、停止したローカルポートを参照し続ける場合があります。その場合は、システムプロキシの設定を確認して元に戻してください。更新前に設定をバックアップし、古いプロセスを終了して、問題があれば戻せる状態を保ちましょう。スタートアップに失敗する場合は、同じユーザーで起動しているか、ショートカットが有効か、セキュリティポリシーによって起動が制限されていないか確認してください。回避のためにスタートアップタスクを重複登録しないでください。

macOS：チップの選択、許可設定、ネットワークサービス

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

「このMacについて」でチップ情報を確認してください。Apple Siliconはarm64、Intelはx64に対応します。macOSダウンロードページから、対応するv2rayNを選択してください。CPUアーキテクチャとOSのバージョンは別のものです。同じOSでも搭載チップが異なる場合があります。ディスクイメージを開いたら、パッケージの案内に従ってアプリを「アプリケーション」フォルダーへ移し、そこから起動してください。マウントしたディスクイメージから使い続けると、更新や権限、ショートカットの動作が想定と異なる場合があります。

初回起動時にセキュリティ警告が表示されたら、ダウンロード元、アプリ名、警告の具体的な理由を確認してから、システムの「プライバシーとセキュリティ」設定で対処してください。セキュリティポリシー、組織の管理制限、ダウンロードファイルの破損は、それぞれ原因と対応方法が異なります。制限をすべて解除するターミナルコマンドを一律に実行しないでください。管理対象の業務端末では、ネットワークインターフェースの作成やプロキシの変更が許可されていない場合があります。何度も再インストールするのではなく、まず許可条件を確認しましょう。

サブスクリプションの追加と基本接続の確認

v2rayNでサブスクリプショングループを作成し、完全なURLを貼り付けて保存してから更新します。初回はサーバーを一つ選んで有効にし、プロトコル、サーバー名、トランスポート方式が提供元の説明と一致しているか確認してください。クロスプラットフォームクライアントでは、バージョンによってメニューの構成が変わることがあります。同じ名前の項目が見つからない場合は、「サブスクリプショングループ」「システムプロキシ」「ルーティング設定」などの機能を探してください。Windowsの設定フォルダーやショートカットをmacOSにそのまま当てはめないようにしましょう。インポート後は基本接続を確認してから、ほかのカスタム設定を移行してください。

システムプロキシを有効にしたら、システムのネットワーク設定を開き、現在使っているネットワークサービスにプロキシアドレスが設定されているか確認します。Wi-Fi、有線LANなどのサービスごとにプロキシ設定が保存されている場合があるため、ネットワークを切り替えたら再確認してください。自動プロキシ設定スクリプトと、HTTP・HTTPS・SOCKSの手動設定は別の項目です。ほかのツールを使っていた場合は、まず以前の設定を記録しましょう。スクリプトのURLを残したまま手動プロキシも追加すると、アプリが別の経路を選ぶ可能性があります。

TUN、権限、スリープ復帰時の確認

macOSでTUNを利用できるかどうかは、クライアントのビルド、コアの統合方法、システムの許可設定によって異なります。画面に機能が表示される場合は、案内に沿って補助コンポーネントや権限を設定し、ログでインターフェースの作成結果を確認してください。デスクトップ版のすべてのバージョンで同じ権限手順を使えるとは限りません。有効化後は通常のWebサイト、プロキシが必要な接続先、ローカルネットワーク上のサービスをそれぞれテストします。Webは見られるのにプリンターや共有フォルダーに接続できない場合は、ローカルネットワーク宛ての通信が直接接続される設定になっているか確認してください。

スリープからの復帰後や、Wi-Fiから有線LANへの切り替え後は、以前の接続が切れていてもローカルのプロキシ設定が残っていることがあります。まずネットワーク自体が復旧していることを確認し、接続先のサーバーに再接続してください。TUNインターフェースが復旧しない場合は、いったん無効にしてから再度有効にし、インターフェースの重複や権限エラーがないか確認します。最初からすべてのサブスクリプションを削除する必要はありません。ブラウザーの接続キャッシュ、リモートセッション、システムのネットワークサービスはそれぞれ別の状態を持ちます。アプリ、クライアントの接続、通信の制御方式の順に再起動すると、問題のある層を特定しやすくなります。

更新前に移行可能な情報を保存する

アプリを更新する前に接続を正常に停止し、サブスクリプショングループ、必要なローカルノード、カスタムルールを保存してください。プログラムを再インストールしても、ユーザー設定がすべて削除されるとは限りません。反対に、アプリを削除してもシステムプロキシが解除されるとは限りません。アンインストールまたは無効化した後、現在のネットワークサービスでプロキシが解除されているか確認してください。別のMacへ移行する場合は、サブスクリプションと読み込み可能なルールを優先して移行し、ローカルポート、起動時の動作、システム権限は改めて設定しましょう。これらは端末の環境に依存するため、古いMacの実行フォルダー全体を新しいMacへ上書きするのは避けてください。

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

ディストリビューションに合ったパッケージを選ぶ

Linuxでv2rayNのGUIクライアントを使う場合は、まずディストリビューションがdebとrpmのどちらに対応するかを確認し、続けてCPUアーキテクチャを確認してください。Debian系のディストリビューションやその派生版では通常deb、RPMパッケージを採用するディストリビューションではrpmを選びます。x64とarm64は互換性がありません。サイトのLinuxクライアントページに各パッケージがあります。パッケージ形式が合っていても、古いシステムでは依存関係を満たせない場合があります。インストーラーの依存関係に関する案内を読み、無視して互換性があると判断しないでください。

ダウンロードしたファイルは、できるだけディストリビューションのパッケージインストーラーで開いてください。依存関係の解決、インストール先、アンインストール情報をシステムのパッケージマネージャーに任せられます。ターミナルにグラフィックライブラリの不足が表示された場合は、まず対応システムの範囲を確認し、ディストリビューションの正規の方法で追加してください。GUIを起動するためにクライアント全体を常に管理者権限で実行するのは避けましょう。設定ファイルの所有者が変わり、サブスクリプションやローカルファイルを扱う際の権限も広がります。一般ユーザーの設定と、管理者権限で起動した際に作成される設定は、保存先が異なる場合があります。

デスクトップセッションとアプリのプロキシ設定は別の仕組み

GUIでサブスクリプションを追加して一覧を更新し、接続先を有効にしたら、まずクライアントのローカル待ち受けが正常か確認してください。Linuxではデスクトップ環境ごとにシステムプロキシの対応が異なります。デスクトップ設定を参照するアプリ、環境変数を参照するアプリ、アプリ独自の設定だけを使うアプリがあります。そのため「システムプロキシを設定済み」という表示は、クライアントが何らかのデスクトッププロキシ機能に設定を行ったことを示すだけです。ターミナル、ソフトウェアインストーラー、すべてのGUIアプリが同じ経路を使うとは限りません。

個別に設定が必要なアプリでは、クライアントでローカルHTTPまたはSOCKSの接続先アドレス、ポート、対応方式を確認してから入力してください。環境変数は通常、その後に起動したプロセスにのみ反映されます。起動済みのターミナルやアプリには反映されない場合があります。リモートノードのアドレスをローカルプロキシ欄に入力したり、ポート番号だけでプロトコルを推測したりしないでください。同じポートで複数のプロトコルを受け付ける場合は、クライアントの表示を確認します。専用の接続先を使う場合は、HTTPとSOCKSそれぞれのプロトコルを正しく指定してください。

# 現在のデスクトップセッションとカーネルのアーキテクチャを確認
printf '%s\n' "$XDG_CURRENT_DESKTOP"
uname -m

# このマシンで待ち受け中のTCPポートを確認
ss -ltn

TUNの権限設定とDNSのトラブル対処

TUNインターフェースの作成やルートの変更には、通常、追加の権限が必要です。具体的な許可方法はクライアントのビルドやディストリビューションの環境によって異なります。現在のクライアントが案内する手順に従い、失敗した場合は権限やインターフェースに関する具体的なエラーを確認してください。出所不明のファイルに、コピーした管理者権限のコマンドを実行しないでください。ファイアウォール、ほかのVPN、コンテナネットワーク、ポリシールーティングが同時に経路を変更している場合もあります。最初はネットワーク構成をシンプルに保ち、各要素を一つずつ戻しながら、どの段階で接続状況が変わるか記録してください。

DNSはデスクトップのネットワーク管理サービス、ローカルの名前解決サービス、ほかのネットワークツールによって管理されている場合があります。TUNの通信制御は動作しているのにドメイン名で接続できない場合は、ドメイン名での接続と、接続先アドレスが分かっている場合の接続結果を比べ、ログの名前解決リクエストと上流への到達性を確認してください。システムの名前解決設定ファイルをすぐに上書きしないでください。サービスが自動生成している場合、手動変更は元に戻されるだけでなく、ほかのネットワークにも影響する可能性があります。クライアントのDNS設定、現在のネットワークサービス、競合するプログラムの三つから、実際にどれが管理しているか確認しましょう。

トレイ、スタートアップ、設定の保存

デスクトップ環境によっては、従来型のトレイアイコンが標準で表示されないことがあります。ウィンドウを閉じてアイコンが見えなくなっても、プロセスが終了したとは限りません。複数のプロセスが同じポートを取り合わないよう、再起動する前にプロセスと待ち受けポートを確認してください。自動起動は、現在のユーザーのデスクトップセッションが正常に始まった後に実行する必要があります。早すぎるとプロキシ機能を読み込めない場合があります。更新前にクライアントを終了して必要な設定をバックアップし、インストール後にファイルの所有者と書き込み権限を確認してください。管理者権限でしか設定を保存できない場合は、日常的に管理者権限で起動するのではなく、設定フォルダーの所有者を修正してください。

Android：VPNの許可、バックグラウンド動作、アプリ別プロキシ

v2rayNGとv2flyNGの選び方

Androidでは、まずXrayコアを使用するv2rayNGを試してください。V2Fly関連の互換性が必要な場合は、v2flyNGも検討できます。名前が似ていても、両方のクライアントですべてのプロトコル拡張を使えるとは限りません。Androidダウンロードページでアーキテクチャに合ったパッケージを選びます。比較的新しい端末の多くはarm64です。判断できない場合や特殊な端末を使う場合はメーカーの仕様を確認し、必要に応じて汎用版を選んでください。汎用版は対応アーキテクチャの範囲を広げるもので、サーバーや接続機能が異なるわけではありません。

インストール時は、システムの案内に従って現在のファイル提供元からのインストールを許可してください。実際に必要な提供元に限って一時的に有効化し、インストール後は元の権限設定に戻してかまいません。既存クライアントを更新する場合、アプリの識別情報と署名に互換性が必要です。上書きインストールできないと表示されたら、すぐにアンインストールせず、同じクライアントをダウンロードしたか確認してください。アンインストールすると、ローカルノード、カスタム設定、アプリ別のリストが削除される場合があります。再インストールが必要なら、先にクライアントのエクスポート機能で必要な情報を保存してください。

接続情報の追加と初回VPN接続

クライアントのサブスクリプション設定でグループ名と完全なURLを追加し、保存してから更新します。単一ノードの場合は、対応するクリップボードまたはQRコード読み取り機能を使ってください。サーバーの項目が追加されたことを確認し、接続先を選びます。接続を開始するとAndroidにVPNの許可画面が表示されます。これはVpnServiceがローカルの仮想インターフェースを作成するために必要なシステム権限です。アプリ名を確認して許可してください。許可しない場合や、別の画面に遮られて手続きが完了しない場合、ほかのVPNがすでに使われている場合は、端末の通信を制御できないことがあります。

Androidでは通常、現在のユーザー領域で有効にできるVPNサービスは一つだけです。別のVPNやローカルVPN機能を持つフィルタリングアプリを起動すると、現在の接続が置き換わることがあります。競合するサービスを終了し、システムのVPN表示とクライアントログを確認してください。VPNの表示は仮想インターフェースが作成されたことを示すだけで、リモートサーバーへの接続成功を保証するものではありません。実際のアプリでアクセスを試し、ログに対応するリクエストがあるか確認しましょう。ネットワーク全体は正常なのに特定のアプリだけ失敗する場合は、許可を繰り返すのではなく、アプリ別ルールを確認してください。

バックグラウンドで切断される場合とネットワーク切り替え

省電力機能によってバックグラウンド通信が制限されたり、クライアントのプロセスが終了したりすることがあります。画面をロックしてしばらくすると切断され、画面を点灯すると復旧する場合は、バッテリー最適化、バックグラウンド動作の制限、メーカー独自の自動起動管理を確認してください。設定名は端末ごとに異なるため、クライアントに対して調整すれば十分で、すべてのアプリに影響する設定を変える必要はありません。常時表示される通知はフォアグラウンドサービスの維持に必要な場合があります。非表示にできるか、どのような影響があるかはOSのバージョンによります。通知を消すためだけに、接続維持に関係する権限やサービスを無効にしないでください。

Wi-Fiとモバイルデータを切り替えるとネットワークが変わり、以前の接続を再確立する必要が生じることがあります。まず新しいネットワークが使えることを確認し、クライアントがトンネルを再接続したか確認してください。「常時接続VPN」や「VPNを使用しない通信をブロック」といったシステム設定は、切断時のネットワーク動作を変えます。有効にする前に影響を理解してください。クライアントが起動していないとすべてのアプリが通信できない場合は、これらの設定を確認し、意図した遮断か障害かを見分けましょう。サブスクリプションの失効とすぐに判断しないでください。

アプリ別ルールと別クライアントへの移行

アプリ別プロキシには通常、「選択したアプリのみ使用」と「選択したアプリを除外」という、動作の異なるモードがあります。意味を確認してからアプリを選んでください。ブラウザーが除外されていれば、ノードが正常でもそのブラウザーの通信はプロキシを通りません。仕事用プロファイル、アプリの複製、別ユーザー領域ではアプリの識別情報が異なるため、以前のリストが適用されないことがあります。設定を変更したら、クライアントの案内に従って再接続し、VPNの対象アプリ一覧を反映してください。詳しくはVPN権限、省電力の例外設定、アプリ別プロキシをご覧ください。

v2rayNGからv2flyNGへ切り替える場合は、まず旧クライアントのVPNを停止してから、新しいクライアントにサブスクリプションを再インポートし、プロトコルの対応状況を確認してください。内部設定をそのままコピーしてアプリデータ全体を上書きしないでください。アプリ別のリスト、通知権限、省電力の許可は端末ごとのアプリ設定なので、改めて確認が必要です。基本接続を一つ確認してから複雑なルールを戻しましょう。特定のプロトコルだけ失敗する場合は、すべてのノードを同時に変更するのではなく、コアの対応範囲と提供元のパラメーターを比較してください。

サブスクリプションと移行：形式、グループ、情報の保護

サブスクリプション更新とノードのインポートの違い

サブスクリプションの更新では、クライアントがURLからデータを取得し、サーバーの項目として解析します。成功には少なくとも、URLにアクセスできること、設定データが返ること、現在のクライアントが形式を認識できることが必要です。同じドメインのWebページを開けても、サブスクリプションのエンドポイントには別の権限が必要だったり、エラーページが返されたりすることがあります。反対に、インポートに成功しても、すべてのノードに接続できるとは限りません。通常、クライアントは解析時に各リモートサーバーの稼働状況までは確認できません。

単一ノードの共有リンクには、その時点の接続パラメーターだけが保存されているのが一般的です。提供元が後からアドレスやポートを変更しても、自動では同期されません。完全なカスタム設定は適用範囲が広く、受け口、出口、ルーティング、DNSまで独自に定義して、GUIの設定を一部上書きすることがあります。インポート前に、入力先と情報の種類が一致しているか確認してください。完全な設定を似た名前の項目に分解して手動入力したり、ブラウザーに保存したサブスクリプション管理ページを実際のURLとして使ったりしないでください。

https://subscription.example.net/client?token=xxxx

グループ、更新による上書き、ローカルでの変更

複数のサブスクリプション元は、個別のグループに分け、提供元や用途を識別できる短い名前を付けるのがおすすめです。まず一つのグループだけを更新し、正常な内容が取得できることを確認してから、一括更新を検討してください。ノード名は表示用であり、安定した識別子とは限りません。提供元による名称変更、ノードの統合、並び順の変更によって、以前の接続先が選択できなくなることがあります。更新後に接続できなくなった場合は、以前の名前だけを頼りに同じ接続先だと判断せず、接続先が現在も一覧にあるか、実際のパラメーターが変わったかを確認してください。

サブスクリプション管理下の項目は、次回の更新で上書きされることがあります。ノードを変更する必要がある場合は、クライアントにローカルの独立項目として複製する機能があるか確認してください。複製後は元の提供元の情報に自動追従しなくなります。カスタムルール、サブスクリプションのノード、一時的なテスト用ノードは分けて管理し、グループの整理時に手動設定を誤って削除しないようにしましょう。一括フィルターや速度テストも対象範囲を限定してください。すべての提供元に一度に大量のテストを行うと余計なリクエストが発生し、ローカルの帯域や接続数の制限で結果に影響することがあります。

サブスクリプション変換が有効な範囲

設定形式の違いは、変換すれば必ず解決するわけではありません。変換ツールで項目を並べ替えたり、別のクライアント向けの形式を生成したりできますが、変換先のコアに未対応のプロトコル機能を追加したり、不足している認証情報を正しく補ったりすることはできません。変換が必要な場合は、入力形式と出力形式、変換先コアの対応状況を先に確認してください。アクセス情報を含むサブスクリプションを、信頼できないオンラインサービスに渡すと、内容を読み取られる可能性があります。提供元が用意した対応形式を優先し、不要なデータの受け渡しを減らしましょう。

更新時に文字コードや解析エラーが出たら、まず短いエラーメッセージを保存し、URLに空白や改行、チャットアプリが追加した文字が含まれていないか確認してください。ブラウザーでクエリパラメーターを書き換えたり、応答内容をそのまま公開したりしないでください。特定のグループだけで問題が起き、ほかのグループは正常な場合は、その提供元のアクセス権、返される形式、プロトコルの互換性を重点的に確認しましょう。複数の提供元を管理する方法は、サブスクリプショングループとサーバーフィルターの活用方法もご覧ください。

プラットフォーム間の移行は自動同期ではない

複数のプラットフォーム間で移行する場合は、サブスクリプションを再インポートし、必要なローカル接続情報と互換性のあるルールを移すのが基本です。クライアント間にクラウド同期機能があるという意味ではありません。デスクトップの待ち受けアドレス、ウィンドウ設定、権限コンポーネント、システムプロキシの状態をAndroidへそのまま移行するのは適切ではありません。バックアップ前にクライアントを正常終了し、書き込み途中のファイルをコピーしないようにしてください。復元後は基本ノードを確認してから、ルーティングを一つずつ戻します。古い端末を使わなくなったら不要な情報を整理してください。サブスクリプションが漏えいした可能性がある場合は、提供元で認証情報を無効化または変更します。ローカルの記録を削除しても、古いURLは無効になりません。

プロキシとルーティング：接続口、出口、DNS

まず通信がコアに届いているか確認する

通信は、アプリがリクエストを生成し、ローカルの接続口が受け取り、ルーティングで出口が選ばれ、コアがリモート接続を確立する段階に分けられます。システムプロキシとTUNは通信をクライアントへ渡す仕組みで、ルーティングルールは受け取った通信をどう処理するかを決めます。アプリがシステムプロキシを参照していない場合、リモート側のルールを変更しても通信経路は変わりません。まずログに該当アプリのリクエストがあるか確認し、その後で直結とプロキシのどちらに振り分けられたかを調べましょう。すべてのモードを何度も切り替えるより、原因を把握しやすくなります。

システムプロキシはシステム設定に従うアプリに適しており、ローカルのHTTPまたはSOCKS接続口は、独自のプロキシ設定を持つプログラムからも利用できます。待ち受けアドレスは通常、ループバックアドレスのままにし、ローカル端末だけに公開してください。外部からアクセスできる設定にすると、LAN上のほかの端末が接続できるようになる可能性があり、認証やファイアウォールの対応も必要です。通常の接続障害を直すために変更する設定ではありません。ポート番号に決まった「速さ」はありません。使用中でないこと、プロトコルが一致すること、システムとアプリの設定が実際の待ち受けポートと一致することが重要です。

ルールの順序と出口名

コアは通常、ルールの順番に照合し、先に一致したルールの処理を適用します。適用範囲の広いルールが前にあると、後続の詳細なルールが使われないことがあります。直結、プロキシ、ブロックなどの出口は、設定内に実際に存在している必要があります。ルールから参照するタグも完全一致が必要です。クライアントに組み込まれた「中国本土をバイパス」などのプリセットは、現在のルール実装やリソースファイルに依存します。あらゆる環境での動作を保証するものではありません。LAN、社内ネットワーク、特定のドメインについては、実際の環境で確認してください。

以下は構造を示すためのXrayルーティング設定例であり、単体で動作する設定ではありません。directというタグの出口がすでに定義され、参照するルールリソースを読み込めることを前提としています。プライベートアドレス宛ての通信を先に直結へ振り分け、その他の通信は後続ルールとデフォルトの出口で処理します。GUIクライアントは起動時に設定を再生成する場合があります。生成済みのファイルを直接編集しても変更が保持されないことがあるため、クライアントが備えるルール編集機能を優先してください。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

DNSとルーティングはセットで考える

DNSはドメイン名をIPアドレスに変換し、ルーティングはリクエストの出口を決めます。この二つは相互に影響します。アプリがシステム側で先に名前解決すると、コアには接続先のIPアドレスだけが渡ることがあります。ドメイン名を含むリクエストが渡されれば、コアがドメインルールを適用できる場合があります。接続口、スニッフィング設定、名前解決の方針によって参照できる情報が変わるため、同じ接続先でもアプリによって経路が異なることがあります。「ドメインルールを追加した」だけで、すべての通信に適用されると判断してはいけません。接続口の種類とログを確認してください。

ドメイン名で接続できず、ほかの通信は正常な場合は、実際に使われているDNSリゾルバー、上流への接続性、DNSリクエストが動作可能な出口へ振り分けられているかを確認してください。リゾルバーの変更、スニッフィングの有効化、すべてのルールの編集を一度に行わないでください。一回に一つだけ変更し、エラーが名前解決失敗から接続タイムアウトへ変わったか、正常に戻ったかを確認します。TUNを有効にした後は、クライアントの設計どおりにDNSも制御されているか確認してください。システムに残っている名前解決設定が新しい経路と一致しない場合があります。社内ネットワークの内部ドメインでは、必要なDNS設定と直結のルールを維持してください。

TUNと実際の接続性を確認する

TUNはより広い範囲の通信を制御できますが、システム権限、ルートの除外設定、DNS、コアの機能に左右されます。すべてのUDP通信が必ず使えるわけでもありません。プロキシが必要な接続先、直結すべきLAN内のリソース、普段使うアプリをそれぞれ試し、通信ループが起きていないか確認してください。ノード一覧の低遅延表示は特定のテスト経路での結果であり、実際のダウンロード速度やアプリの使用感と同じではありません。詳しくはPing、実接続の遅延、速度測定結果の違いをご覧ください。一つの数値だけを根拠にネットワーク設定全体を変更しないようにしましょう。

設定に関するよくある質問：症状から原因の層を特定

決まった順序で情報を集める

接続できない場合は、どの段階で問題が起きているかをまず確認してください。プログラムが起動しない、サブスクリプションを更新できない、コアを起動できない、アプリからアクセスできない、のいずれかで対処方法が異なります。通常のネットワークが使えることを確認し、クライアントで有効な接続先と通信の制御方式を確かめてから、ログに最初に出たエラーを確認しましょう。再試行後の最後の一行だけを切り取らないでください。それ以前の失敗が連鎖した結果かもしれません。操作時刻、接続先の種類、変更した内容を記録すると、関連するリクエストをログで追いやすくなります。

プログラムは起動するのにコアが終了する場合は、設定の構文、項目の互換性、ローカルポートの競合、リソースの読み込みエラーを重点的に確認してください。コアが正常に動作しているのにアプリのリクエストが記録されない場合は、システムプロキシ、アプリ独自の設定、アプリ別リストを確認します。リクエストが記録されていてリモート接続がタイムアウトする場合は、サーバーアドレス、ポート、ネットワーク経路、サーバーの状態を順に確認してください。段階ごとの詳しい手順はノードのタイムアウト・接続できない場合のトラブル対処をご覧ください。まず原因の範囲を絞り、変更する層を決めましょう。

証明書、ポート、権限のエラーは原因ごとに対処する

証明書エラーが発生した場合は、端末の時刻、サーバー名、設定で指定されたセキュリティ層を確認し、サブスクリプションが更新済みかも確認してください。不一致を隠すために証明書検証を恒久的に無効化しないでください。接続の安全性が損なわれます。ポート競合はローカルで対処します。ほかのクライアントや重複プロセスを終了して、使用中のポートを確認してください。必要に応じてローカルの待ち受けポートを変更し、そのポートを使うアプリ側の設定も更新します。権限エラーは、設定フォルダー、インターフェースの作成、システムポリシーに関係している場合があります。常に高い権限で起動するのではなく、対象を特定してください。

最小構成での再現と更新前の状態への復元

複雑な問題では、最小構成で再現できるか確認します。設定元を一つ、接続先を一つ、通信の制御方式を一つ、テスト用アプリを一つに絞ってください。カスタムルールの影響は一時的に外しますが、先にバックアップを保存します。最小構成で正常に動く場合は、DNS、ルール、ほかのアプリ設定を一つずつ戻し、問題が再発する手順を特定しましょう。更新前後で動作が異なる場合は、設定の移行、コアの選択、ルールリソースの変更を確認してください。以前の設定を保存して状況を記録し、上書きインストールを繰り返して元に戻せる状態を失わないようにしましょう。

サポートを依頼する際は、OS、クライアント、コア、通信の制御方式、機密情報を隠したエラー概要を提示すれば十分です。サブスクリプション全文、ノードの認証情報、設定フォルダー全体を公開しないでください。一度のテスト結果を一般的な結論として扱うのも避けましょう。接続が復旧したら簡単な対処記録を残し、調査のため一時的に緩めた待ち受けアドレス、権限、セキュリティ設定を元に戻してください。初めて設定する場合はクイックスタートガイドに戻って手順を進められます。プラットフォームやパッケージ形式を変更する場合は、クライアント一覧から該当する項目を選んでください。