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

クライアントとプラットフォームの対応

デスクトップでは v2rayN を優先して使います。Windows、macOS、Linuxに対応し、グラフィカルな画面からサブスクリプション、ノード、ルーティング、プロキシ状態を管理できます。Androidでは v2rayNG が基本です。サブスクリプションや利用環境が V2Fly カーネルを前提としている場合は、v2flyNG も選択できます。2つのAndroidクライアントは画面構成やカーネルの重点が異なりますが、基本的な流れは同じです。サブスクリプションをインポートし、ノードを更新し、設定を選び、ローカルVPNで通信を引き継いでから接続を確認します。

クライアント、カーネル、サブスクリプションを同じものとして扱わないでください。クライアントは画面、設定管理、システムとの連携を担当します。XrayやV2Flyなどのカーネルは、設定に従って接続を確立し、通信を処理します。サブスクリプションURLはサービス提供者が生成するもので、通常はサーバーアドレス、ポート、ユーザー識別子、通信方式、TLSやREALITYなどのパラメータを含みます。クライアントをインストールしても利用可能なノードが自動で生成されるわけではなく、サブスクリプションのインポートに成功しても、すべてのノードが接続できるとは限りません。

サブスクリプション情報を準備し、何度もインポートするのは避ける

開始前に、有効期限内で正常にアクセスできるサブスクリプションURLを1つ用意します。サブスクリプションURLは機密性の高い設定情報なので、公開投稿、スクリーンショット、複数人で共有する文書に貼り付けないでください。提供元から単一のVMess、VLESSなどの共有リンクが渡された場合は、クライアントの「クリップボードからインポート」機能を使えます。サブスクリプションURLの場合は、サブスクリプショングループを作成して1回更新します。2つの入口で扱う対象は異なります。単一リンクは通常1つのノードを作成し、サブスクリプションURLでは提供元が管理する複数のノードが追加される場合があります。

初回インポート前に、URLの先頭や末尾に空白がないか、チャットアプリがパラメータを切り詰めていないか、ブラウザーが特殊文字を書き換えていないかを確認します。インポート後は、すぐに更新を連打するのではなく、ノード名と数が想定どおりかを確認してください。更新に失敗した場合は、URL自体にアクセスできないのか、システム時刻が正しくないのか、証明書のハンドシェイクに失敗したのか、現在のネットワークからサブスクリプションサービスへアクセスするために既存のプロキシが必要なのかを切り分けます。更新を繰り返しても同じログが増えるだけで、根本原因は変わりません。

既存のプロキシとDNSの状態を記録する

設定前に、システムプロキシが有効か、LANアドレスが手動設定されているか、ブラウザーに独自のプロキシルールがあるか、システムDNSが手動設定かを記録します。最も確実なのは、システムのネットワーク設定をスクリーンショットで保存するか、重要な値をローカルのメモに書き留める方法です。後でウェブページが開けない、LAN機器に接続できない、クライアント終了後もプロキシが残るといった問題が起きても、元の状態に戻せます。会社、学校、固定プロキシが必要なネットワークでは、既存設定を記録せずに上書きしないでください。

システム時刻とタイムゾーンが正しいことも確認します。TLSとREALITY接続はいずれも妥当な時刻判定に依存するため、大きなずれがあると証明書エラー、ハンドシェイク中断、接続直後の切断として現れることがあります。時刻の問題はルーティングルールを変更しても解決しないため、プロトコルパラメータより先に確認してください。

ダウンロード入口とアーキテクチャの選択

すべてのクライアントはダウンロードページから入手できます。Windowsの一般的な端末ではx64を選択します。macOSでは「このMacについて」に表示されるチップに応じてApple SiliconまたはIntelを選びます。近年のAndroid端末は通常arm64です。不明な場合はユニバーサルパッケージを選べます。Linuxではx64とarm64に加え、ディストリビューションに応じてdebまたはrpmを選択します。アーキテクチャを間違えると、インストーラーが起動しない、形式エラーが表示される、起動直後に終了するといった状態になります。これはサブスクリプションの有効性とは無関係です。

インストール前に旧クライアントを終了し、まだ有効なシステムプロキシを解除します。複数のクライアントが同じローカルポートを奪い合う状態は避けてください。どうしても並行して比較する場合は、各クライアントに異なるローカル待受ポートを設定し、どのクライアントがシステムプロキシを変更しているかを明確にします。準備が整ったら、対応するプラットフォームの章に進みます。

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

ダウンロードページにはv2rayNデスクトップ版と従来のWPF版があります。デスクトップ版は新世代のクロスプラットフォームUIを採用しており、異なるデスクトップシステムでも似た操作感を求めるユーザーに向いています。WPF版はWindowsで長く使われてきた従来のUIで、メニュー位置や解説資料が比較的安定しています。どちらでもサブスクリプション管理、ノード選択、ルーティング設定、システムプロキシ制御を行えます。初回はどちらか一方だけをインストールし、2つのインスタンスが同じシステムプロキシを同時に変更しないようにしてください。

Windowsのダウンロード入口から適切なパッケージを入手したら、まず起動中の旧バージョンを終了します。インストール形式の場合は、インストール画面で現在のユーザーが書き込める場所を選びます。解凍して実行する場合は、長期保存でき、書き込み権限のある場所に置いてください。圧縮ファイルのプレビュー画面から直接起動しないでください。クライアントは設定、ログ、カーネル関連ファイルを書き込むため、書き込み不可のディレクトリでは設定保存に失敗したり、起動のたびに初回起動のような状態になったりします。

初回起動とサブスクリプショングループ

v2rayNを起動したら、まずサブスクリプショングループの管理を開き、グループ名を追加してサブスクリプションURLを貼り付けます。グループ名は「日常用サブスクリプション」や「テスト用グループ」のように用途が分かるものにし、URL全体を名前にするのは避けます。保存後にサブスクリプションを更新し、メインリストにノードが実際に追加されたことを確認します。リストが空のままなら、通知とログを確認してください。URLがサブスクリプションではなくウェブページを返している、リンクの期限が切れている、ログインページへリダイレクトされているといった場合は解析に失敗します。

サブスクリプショングループは管理の入口であり、接続状態そのものではありません。更新成功は、クライアントが設定を取得して解析できたことを示すだけです。次にノードを1つ選んで現在のアクティブ項目にし、実接続テストを行います。テストでは接続を確立できるか、ログに明確なエラーが出ていないかを優先して確認してください。ダウンロード速度だけを見ないでください。速度は対象サーバー、回線の混雑、ローカル帯域幅にも左右されるため、システムプロキシがブラウザーを引き継いでいる証明にはなりません。

単一リンクのインポートとパラメータ確認

単一の共有リンクを受け取った場合は、コピーして「クリップボードからURLを一括インポート」を使います。インポート後にノード編集画面を開き、サーバーアドレス、ポート、ユーザー識別子、通信方式、セキュリティ層、サーバー名などが揃っているか確認します。VLESSでTLSまたはREALITYを使う場合は、flow、フィンガープリント、公開鍵、ショートID、serverNameが含まれることもあります。見慣れないパラメータを「互換性」のために勝手に削除しないでください。これらの値はサーバー側との一致が必要な場合があります。

VMessとVLESSのどちらを選ぶか迷ったとき、プロトコル名だけで速度を判断する必要はありません。プロトコルは認証情報とデータ形式を担当し、TLS、REALITY、WebSocket、gRPCなどはセキュリティと通信方式の組み合わせです。最終的な可否は、全パラメータが一致しているかで決まります。詳しくはVMessとVLESSのパラメータの違いを確認し、クライアントで項目ごとに照合してください。

まずシステムプロキシを試す

多くのブラウザーやWindowsのシステムプロキシに従うデスクトップアプリでは、初回設定にシステムプロキシを使うと問題を切り分けやすくなります。v2rayNのシステムプロキシメニューで「システムプロキシを自動設定」を選び、必要に応じてルーティングモードを指定します。これによりシステムプロキシはクライアントのローカル待受ポートを指しますが、すべてのアプリが自動的に従うわけではありません。ゲーム、コマンドラインツール、仮想マシン、独自のネットワークスタックを使うソフトは、システムプロキシを迂回することがあります。

有効にしたら、まず普段安定して開ける一般的なウェブサイトにアクセスし、基本ネットワークが途切れていないことを確認します。次にプロキシ経路の確認用サイトへアクセスし、クライアントログに対応する接続が出ているか確認します。ブラウザーが古い接続を使っている場合は、ブラウザーを完全に終了して再起動するか、キャッシュを使わない新しいウィンドウで再試行します。詳しい確認方法はv2rayN初回接続の確認方法を参照してください。

TUNの権限と適用範囲

アプリがシステムプロキシに従わない場合や、より多くの通信をまとめて引き継ぐ必要がある場合にTUNを検討します。TUNは仮想ネットワークインターフェースを作成し、ルーティングルールを通じて通信を受け取るため、通常は管理者権限とドライバーのサポートが必要です。有効にする前にシステムプロキシを解除するか、両者の役割を明確にして、同時に有効にした際の経路を判断できるようにします。権限不足と表示された場合は、クライアントを終了して管理者として起動します。仮想インターフェースの作成に失敗する場合は、古いTUNドライバー、他のVPNソフト、セキュリティポリシーの競合を確認してください。

TUNは「接続を速くする」スイッチではなく、通信の引き継ぎ範囲を変える機能です。LANアクセス、仮想マシン、開発環境、社内ネットワークはルーティングの影響を受ける可能性があります。有効にした後は、ローカルゲートウェイ、LAN機器、よく使う社内ドメインを確認し、プライベートアドレスが直接接続ルールの対象になっていることを確認します。社内ネットワークに到達できない場合は、まずTUNを無効にして復旧するか確認し、その後 geoip:private またはプライベートセグメントの直接接続ルールを確認してください。すぐにノードを変更するのは避けます。

Windowsでよくある競合

Windowsではポートの競合がよく起こります。ログにローカル待受の失敗が出た場合は、別のv2rayNインスタンス、旧クライアント、デバッグツールが同じポートを使っていないか確認します。ポート番号を適当に大きくするだけでは不十分です。変更後は、システムプロキシ、ブラウザー拡張機能、該当ポートに依存するアプリも同じ値に更新する必要があります。セキュリティソフトがカーネルプロセスを遮断すると、画面は正常でもログに接続がまったく出ないことがあります。システムイベントとクライアントログを合わせて判断してください。

もう1つの誤解は、「遅延テストに結果が出た」ことを接続完了とみなすことです。遅延テストはTCP接続だけを確認している場合がありますが、実接続テストはノードのプロトコルに従って実際のリクエストを送ります。実接続に成功しても、システムプロキシが有効でなければブラウザーは直接接続する可能性があります。確認の順序は、ノードを選択、実接続テストを実行、1つの通信引き継ぎ方法を有効化、ブラウザーから新しいリクエストを送信、ログで該当ドメインまたは対象接続を確認し、最後に他のアプリをテストする、という流れです。

Apple SiliconかIntelかを確認する

システムの「このMacについて」を開き、チップ情報を確認します。Apple Mシリーズと表示される場合はarm64パッケージ、Intelプロセッサーと表示される場合はx64パッケージを選びます。アーキテクチャによる機能の優劣はなく、端末に合っていれば問題ありません。Apple Silicon端末にIntel版を誤ってインストールすると、追加の変換環境を求められたり、性能や互換性に問題が出たりする可能性があるため、原生arm64版を優先してください。

macOSのダウンロード入口から対応するdmgを入手し、ディスクイメージを開いてアプリを「アプリケーション」フォルダへドラッグします。そのフォルダから起動してください。読み取り専用のディスクイメージから長期間実行しないでください。アプリの更新、補助コンポーネント、設定の書き込みが制限される場合があります。初回起動がシステムに阻止された場合は、「プライバシーとセキュリティ」で今回のブロック記録を確認して実行を許可します。システム全体のセキュリティ機能を無効にする必要はありません。

サブスクリプションのインポートとノード選択

サブスクリプショングループの管理を開き、名前とURLを追加して保存した後、更新を実行します。macOSでよくある更新失敗は、必ずしもクライアントが原因とは限りません。システムDNSで名前解決できない、現在のネットワークでウェブ認証が必要、時刻がずれている、サブスクリプションサービスの証明書に問題がある、といった原因もあります。まずブラウザーでネットワーク認証を済ませ、ログで名前解決失敗、接続タイムアウト、認識できない内容の返却のどれかを確認します。

ノードが表示されたら、まず設定を1つ選び、実接続テストを行います。同じサブスクリプションで一部のノードだけが失敗する場合は、失敗したノードのサーバー名、ポート、通信方式、TLSまたはREALITYのパラメータを比較します。サブスクリプション全体を削除する必要はありません。すべてのノードがハンドシェイク段階で失敗する場合は、システム時刻、対象ポートがネットワークで遮断されていないか、サブスクリプションが新しいユーザー識別子に更新されているかを優先して確認します。

システムプロキシが適しているアプリ

macOSのシステムプロキシは、現在のネットワークサービスのプロキシ項目に書き込まれます。ブラウザーやシステムのネットワーク設定に従うアプリは通常利用できますが、ターミナルコマンド、開発ツールの一部、独自に接続を管理するプログラムは従わない場合があります。有効化後はシステムネットワークの詳細でプロキシ状態が変化したか確認し、現在使用中のネットワークサービスを操作していることを確認してください。無線、有線、複数のネットワーク環境を併用している場合、別のサービスを変更すると、クライアントでは有効に見えても実際の通信が変わりません。

コマンドラインツールには通常、独自の環境変数または設定が必要です。現在のターミナルセッションだけでクライアントの待受ポートを使う場合は、クライアントに表示される実際のローカルポートを使って環境変数を設定します。以下は書式の例です。ポートは本体の設定に合わせてください。

export http_proxy="http://127.0.0.1:ローカルHTTPポート"
export https_proxy="http://127.0.0.1:ローカルHTTPポート"
export all_proxy="socks5://127.0.0.1:ローカルSOCKSポート"

この種の環境変数は現在のshellと子プロセスにだけ影響します。ポートを確認せずに起動ファイルへ永続的に書き込まないでください。テスト後は unset http_proxy https_proxy all_proxy を実行して元に戻せます。ツール自体に独立したプロキシ設定がある場合は、後で設定元を確認しやすいよう、ツール内で明示的に設定することを優先します。

TUNとネットワーク拡張の許可

システムプロキシを読み取らないアプリを引き継ぐ必要がある場合は、TUNを検討できます。初回有効化時に管理者認証やネットワーク拡張の許可を求められることがあります。許可後もクライアントに戻り、仮想インターフェースが正常に作成されたか、ログにルート設定の結果が出ているかを確認してください。システムのダイアログで許可を押しただけでは、TUNが安定して動作しているとは限りません。インターフェースの作成、DNSの引き継ぎ、ルートの適用はそれぞれ失敗する可能性があります。

macOSで他のVPNソフト、ネットワークフィルター、企業向けセキュリティソフト、仮想化ネットワークを同時に動かすと、ルートの優先順位が影響し合うことがあります。トラブル対処では、デフォルトルートやDNSを変更する他のプログラムをいったん終了し、v2rayNと基本ネットワークだけを残します。問題が解消したら、プログラムを1つずつ戻してください。ノード、ルーティングモード、複数のネットワーク拡張を同時に切り替えると、ログの時系列が混乱します。

スリープ復帰とDNSキャッシュ

端末がスリープから復帰すると、ネットワークインターフェースやデフォルトルートが再設定されることがあります。クライアント画面が動作中でも新しいリクエストがタイムアウトし続ける場合は、いったん通信の引き継ぎを停止し、ネットワークが復旧してから再起動します。無線ネットワークを頻繁に切り替える場合も同様です。ドメイン接続だけが失敗し、既知のIPアドレスへのテストが成功する場合は、DNS経路の問題が考えられます。クライアントDNS、システムの名前解決結果、DNSリクエストを到達不能な出口へ送っていないかを確認してください。

DNSキャッシュの削除を常に行う必要はありません。ドメイン情報が明らかに古い、または名前解決方式を変更しても古い値が返る場合だけ対処します。多くのプロキシ問題は、通信の引き継ぎ方法、ルーティングの一致、ノードパラメータに起因します。キャッシュを何度更新してもハンドシェイク失敗は直りません。クライアントを終了する前にシステムプロキシを解除してください。TUNを使っている場合は、まず正常にTUNを停止し、インターフェースとルートが撤回されたことを確認してから終了します。

arm64またはユニバーサルパッケージを選ぶ

近年のAndroidスマートフォンは通常arm64アーキテクチャです。端末のアーキテクチャが分かっている場合はarm64パッケージを優先し、不明またはインストーラーで互換性エラーが出る場合はユニバーサルパッケージを使います。ユニバーサルパッケージは対応範囲が広い一方、複数アーキテクチャのリソースを含むため、サイズが大きいことがあります。アーキテクチャはアプリがプロセッサー上で動くかどうかだけを決め、ノードのプロトコルやサブスクリプション内容は変えません。ダウンロード入口はv2rayNG、v2flyNGの順に並んでいるため、Androidダウンロード区から選択できます。

インストール前に同名アプリが端末にある場合は、署名元と既存設定を保存する必要があるか確認します。システムが上書きインストールを拒否しても、サブスクリプションをバックアップせずにすぐアンインストールしないでください。サブスクリプションURL、ルーティングモード、アプリごとの振り分け、DNS設定を先に記録してから、アップグレードまたは再インストールを判断します。サブスクリプションURLは機密情報なので、バックアップファイルも管理された場所に保管してください。

サブスクリプションと単一ノードリンクのインポート

v2rayNGを開き、サブスクリプショングループからURLを追加して更新できます。クリップボードから単一の共有リンクをインポートすることも可能です。QRコードを使う場合は、信頼できる提供元のものか確認し、読み取り後もサーバーアドレス、ポート、ユーザー識別子、通信方式、セキュリティパラメータを確認します。QRコードは手入力を減らすだけで、設定が正しいことを検証するものではありません。

サブスクリプションを更新したら、ノード名をタップして現在の設定にし、接続を開始します。AndroidはVPN接続の作成を要求します。これはローカル通信を引き継ぐための標準的なシステム許可です。端末に別のVPN接続がある場合、通常は1つしか有効にできないため、先に古い接続を停止します。許可ダイアログを拒否すると、クライアントはバックグラウンドサービスだけで通信を引き継げません。再起動して許可し直してください。

アプリごとの振り分けと除外設定

アプリごとの振り分けでは、どのアプリをローカルVPNインターフェースへ送るかを決めます。初回接続では複雑な振り分けを一時的に使わず、まず1つのブラウザーで確認することをおすすめします。基本接続が正常になってから、「選択したアプリのみプロキシ」または「選択したアプリを除外」の考え方で設定します。2つのモードは意味が逆なので、切り替え後にリストを再確認し、対象アプリを反対側に入れないようにしてください。

銀行、LAN制御、画面投影、デバイス検出のアプリはローカルネットワークに依存することがあります。必要に応じて直接接続にします。アプリを直接接続にしても、DNSの影響を受けなくなるとは限りません。DNSリクエストをクライアントが引き継いでいる場合、名前解決結果も変わる可能性があります。ブラウザーは正常なのに特定のアプリだけ異常な場合は、まずそのアプリの振り分け制限を解除して再確認し、QUIC、プライベートDNS、固定アドレスを使っていないかを確認してください。最初から全体のノードを変更する必要はありません。

バックグラウンド制限と再接続

Android端末メーカーは、バッテリー最適化、休止、自動起動の制限をバックグラウンドサービスに適用することがあります。画面ロック後に接続が停止する、ネットワーク切り替え後に復旧しない、システムがクライアントプロセスを終了するといった症状が典型です。まずシステムのバッテリー使用状況でクライアントが制限されているか確認し、適切なバックグラウンド設定を選びます。すべての端末で制限を完全に解除する必要はありません。まず状況を観察し、接続に影響する項目だけを調整してください。常時通信をシステム制限と誤認しないことも重要です。

頻繁な再接続は消費電力も増やします。ログにネットワーク変化、接続タイムアウト、即時再試行が繰り返し出る場合は、モバイル回線の不安定さ、到達不能なノード、システムによるバックグラウンド通信の停止を切り分けます。同じ場所で画面を点灯したまましばらく試し、その後ロックして比較できます。詳しい手順はv2rayNGのバックグラウンド消費電力異常の対処を参照してください。

プライベートDNSとクライアントDNS

システムのプライベートDNS、ブラウザー内蔵のセキュアDNS、クライアントDNSが同時に存在することがあります。初回のトラブル対処では、現在どれがドメインを解決しているかを明確にします。システムのプライベートDNSが厳格なホスト名設定で、そのサービスに現在のネットワークから到達できない場合、プロキシ起動前から名前解決に失敗することがあります。まず自動モードに戻して確認し、その後クライアントにDNSを任せるか判断してください。

クライアントDNSの役割は、単に「別のサーバーに変える」ことだけではありません。ドメインリクエストをどの出口から送るか、ルーティングルールがドメインと解決後のIPのどちらで一致するか、ローカルの結果とプロキシ出口の不一致を避ける必要があるかにも関係します。ドメインだけが失敗し、ノードのサーバーアドレスがIPの場合はDNSを重点的に確認します。サーバーアドレス自体でTCP接続やプロトコルハンドシェイクを確立できない場合、DNSサーバーを変更しても効果はありません。

無線ネットワークとモバイルネットワークの切り替え

ネットワークを切り替えると、ローカルアドレス、デフォルトルート、NAT状態が変わり、既存の接続を再利用できなくなることがあります。切り替え後はシステムネットワークが安定するまで待ち、クライアントが自動的に再接続するか確認します。画面では接続済みなのに新しいログが出ない場合は、ローカルVPNを停止して再起動します。インターフェースが解放される前に新しいインスタンスを作らないよう、起動ボタンを連続して押さないでください。

トラブル対処後、特定の無線ネットワークだけで失敗し、モバイルネットワークでは正常な場合は、そのネットワークでウェブ認証が必要か、対象ポートが制限されているか、DNSが異常な結果を返していないかを確認します。どちらのネットワークでも失敗する場合は、ノードパラメータ、サブスクリプションの有効性、システム時刻に戻って確認します。この比較により、端末設定の問題と現在のネットワークの問題を分けられます。

deb、rpm、プロセッサーアーキテクチャ

Debian、Ubuntuおよび一般的な派生ディストリビューションでは通常debを使います。Fedora、Rocky Linux、openSUSEなどではrpmが一般的ですが、最終的には各ディストリビューションのパッケージ管理方式に従ってください。一般的なデスクトップPCはx64が多く、arm64は一部の開発ボードやARMデスクトップ端末で使われます。uname -m を実行してアーキテクチャを確認できます。一般的な出力では、x86_64 がx64、aarch64 がarm64に対応します。

uname -m
cat /etc/os-release

Linuxのダウンロード入口から対応するv2rayNパッケージを入手します。ローカルのdebをインストールする場合は、パッケージがあるディレクトリでシステムのパッケージマネージャーを使って依存関係を処理します。rpm系でも同様に、ファイルを解凍するだけでなく、ディストリビューションのパッケージマネージャーを使ってください。以下のコマンドにあるファイルパターンは、実際にダウンロードした名前と一致させます。ディレクトリに古いパッケージが複数残っていないことも確認してください。

sudo apt install ./v2rayN*.deb
sudo dnf install ./v2rayN*.rpm

システムがアーキテクチャ不一致を報告した場合は、ダウンロードページに戻って選び直し、強制オプションでスキップしないでください。依存関係が不足している場合は、まずディストリビューションのソフトウェアソースを更新し、デスクトップ環境のバージョンがサポート対象か確認します。依存関係を強制的に無視してインストールすると、起動時まで問題を先送りするだけです。

初回起動と設定ディレクトリ

デスクトップのアプリメニューからv2rayNを起動し、画面、トレイ、設定保存が正常か確認します。端末から起動するとエラーが見えるのに、デスクトップメニューでは反応しない場合は、端末からアプリの起動エントリを実行して、不足ライブラリ、表示サービス、権限に関するメッセージを確認します。グラフィカルクライアント全体をrootで常用しないでください。設定ディレクトリがroot所有になり、一般ユーザーで起動したときに書き込めなくなる可能性があります。

サブスクリプション管理の流れは他のデスクトッププラットフォームと同じです。グループを追加し、サブスクリプションURLを貼り付け、保存、更新、ノード選択、実接続テストを行います。Linuxデスクトップでは、システム設定とユーザーセッションのプロキシが分かれていることがあります。クライアントに「設定成功」と表示されても、デスクトップのネットワーク設定で現在のユーザーのプロキシ値を確認してください。軽量デスクトップや独立したウィンドウマネージャーでは、統一されたシステムプロキシの入口がない場合があり、ブラウザーや各アプリに個別設定が必要です。

デスクトッププロキシと環境変数

GNOME、KDEなどのデスクトップ環境にはシステムプロキシ設定がありますが、アプリが従うかどうかはネットワーク実装によります。ブラウザーはデスクトッププロキシに従えることが多い一方、端末ツールは環境変数や独自設定を読むことがよくあります。一時的なテストでは現在のshellにプロキシ変数を設定し、終了後すぐに解除します。

export http_proxy="http://127.0.0.1:ローカルHTTPポート"
export https_proxy="$http_proxy"
export all_proxy="socks5://127.0.0.1:ローカルSOCKSポート"

# テスト終了
unset http_proxy https_proxy all_proxy

ここで使うポートはv2rayNの設定から確認してください。クライアントがローカルループバックアドレスだけで待ち受けている場合、LAN上の他の端末はそのポートを直接利用できません。これはより安全なデフォルト境界です。プロキシを共有する明確な必要がある場合だけLANアドレスでの待受を検討し、ファイアウォールとアクセス制御も確認してください。同じネットワーク上の他の端末に、許可のないプロキシ入口を公開しないようにします。

TUN、権限、ルーティングの競合

LinuxのTUNは、カーネルデバイス、ネットワーク管理権限、ルートを書き込む権限に依存します。まず /dev/net/tun が存在することを確認し、クライアントログでデバイスが利用できないのか、権限不足なのか、ルーティングルールの書き込みに失敗したのかを判断します。アプリ全体に永続的なroot権限を与えないでください。クライアントが提供する許可フローやシステム機能設定を優先し、更新後に実行ファイルが変わると以前の許可が無効になる可能性も理解しておきます。

ls -l /dev/net/tun
ip route
ip rule

コンテナ、仮想マシン、社内VPN、多数のネットワークインターフェースがある環境では、ポリシールーティングがすでに設定されていることがあります。TUNを有効にする前に ip route と ip rule の出力を保存し、有効化後に追加項目を比較します。社内ネットワークに接続できない場合は、プライベートセグメントがTUNへ送られていないか、デフォルトルートの優先順位が変わっていないか、DNSリクエストが別の名前空間へ入っていないかを重点的に確認します。TUNを無効にした後は、追加されたインターフェースとルールが撤回されたことを確認してください。

DNSとsystemd-resolved

Linuxの名前解決経路には、アプリ、glibc、NetworkManager、systemd-resolved、上流DNSが含まれることがあります。クライアントDNSを変更した後も、/etc/resolv.conf の表面だけを見ないでください。ローカルの名前解決サービスを指すリンクになっている場合があります。resolvectl status を使って各インターフェースのDNSとドメイン設定を確認し、クエリが実際にプロキシへ入っているかをクライアントログと照合します。

resolvectl status
getent hosts example.com
ss -lntup

ss は、ローカルのプロキシポートが待ち受けているか、競合しているかを確認するために使えます。クライアント終了後にネットワークが異常になった場合は、まずデスクトッププロキシとshellの環境変数を解除し、その後TUNインターフェースとポリシールートを確認します。再起動で状態が戻ることはありますが、重要な現場情報が失われます。再起動前にログとルーティング出力を保存すると、根本原因を見つけやすくなります。

通信の引き継ぎ方法がクライアントへ入る通信を決める

システムプロキシは本質的に、アプリへHTTPまたはSOCKSプロキシの入口を通知する仕組みです。システム設定を読み取り、従うアプリだけが利用します。境界が明確で、有効化と復旧が簡単なのが利点で、ブラウザーや多くのデスクトップアプリに適しています。TUNは仮想インターフェースとルーティングで通信を受け取るため、プロキシ設定に対応しないアプリも広く対象にできますが、LAN、仮想化環境、既存のネットワークツールに影響しやすくなります。

2つの方式を同時に有効にする必要はありません。初回設定はシステムプロキシから始めます。対象アプリを引き継げるなら、「より完全にする」ためだけにすぐTUNを追加する必要はありません。システムプロキシを迂回するアプリがあり、通信をまとめて引き継ぐ必要があると確認できた場合にTUNを有効にします。AndroidのローカルVPNによる引き継ぎは体験としてTUNに近いものですが、アプリごとの振り分けはシステムインターフェースとクライアントが共同で処理します。

ルーティングルールは順番に照合される

ルーティングは、カーネルに入った通信をどの出口へ送るか決めます。一般的な条件には、ドメイン分類、IP分類、ポート、ネットワーク種別、プロセスがあります。ルールは通常上から順に照合され、最初に一致したルールが適用されます。そのため、具体的なルールを汎用的なルールより前に置く必要があります。範囲の広いプロキシルールが先にあると、後ろのLAN直接接続ルールが実行されないことがあります。

以下は構造を説明するためのルーティング断片です。一般的なプライベートアドレスと指定した分類を先に直接接続し、それ以外は設定内の後続ルールとデフォルト出口に委ねます。実際に使う場合、出口タグはクライアントが生成した出力設定と一致している必要があります。

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

domainStrategy は、ルーティング判定でドメインを解決するか、いつ解決するかを決めます。AsIs では元のドメインルールによる照合を優先します。他の方式では必要に応じてIPへ解決してから判定する場合があります。すべての環境に適した方式はありません。ドメイン分類による振り分けを使う場合は、リクエストがカーネルに到達した時点でドメイン情報が残っていることを確認します。アプリが直接IPへ接続する場合、ドメインルールは一致しません。

GeoIPとGeoSiteのデータ

GeoIPはIP分類データ、GeoSiteはドメイン分類データです。ルーティングルールが参照するのは分類タグであり、「自動インテリジェント振り分け」ではありません。データベースの欠落、タグの不存在、カーネルバージョンの非互換があると、クライアントの起動に失敗したり、ルール読み込みエラーがログに出たりします。データを更新した後は、新しいファイルが読み込まれたことをログで確認し、復旧用に元のファイルも残してください。詳しい管理方法はGeoIPとGeoSiteデータベース更新ガイドを参照してください。

1回の変更でデータベース、ルールセット、カーネルを同時に変更しないでください。更新後に問題が出た場合は、まず元のデータを戻し、ルールは変更しないままにします。正常に戻ったら、新しいデータに必要なタグが含まれているかを個別に確認します。ルールタグの名前に誤りがある場合、ノードを変更しても解決しません。

DNSとルーティング経路を一致させる

DNSはドメインからどのアドレスを得るかを決め、ルーティングはそのアドレスへリクエストをどう届けるかを決めます。ドメインがローカルDNSで解決され、到達不能または出口に合わない結果になると、プロトコルのハンドシェイク前に接続が失敗します。DNSリクエスト自体をプロキシ経由で送る必要がある場合は、起動時点で利用可能な基本の名前解決経路を確保してください。「プロキシサーバーを解決するためにプロキシが必要」という循環を避ける必要があります。

DNSを調べるときは、まずリクエストがクライアントに到達しているかをログで確認し、システムツールとクライアント内の解決結果を比較します。ドメインだけが失敗し、直接アドレスには到達できる場合に、名前解決経路を重点的に確認します。TCP接続が確立した後、TLSまたはREALITY段階で失敗する場合は、serverName、公開鍵、ショートID、フィンガープリント、システム時刻を確認してください。ハンドシェイクエラーをDNSの問題と決めつけると、誤った方向へ進みます。

4段階の確認方法

第1段階はサブスクリプション更新結果の確認です。ノード一覧に想定した内容が表示され、現在のノードの重要パラメータが揃っていることを確認します。第2段階は実接続テストです。クライアントがプロトコルに従って実際のリクエストを確立できるか観察します。第3段階では1つの通信引き継ぎ方法を有効にし、対象アプリから新しいネットワークリクエストを送ります。第4段階では、そのリクエストの時刻に対応するドメイン、対象アドレス、ルーティング出口、エラーをログで探します。4段階すべてが成立して初めて、「ノードに接続でき、アプリ通信が実際にクライアントへ入っている」と判断できます。

実接続テストは成功したのにブラウザーに変化がない場合は、システムプロキシ、ブラウザー独自のプロキシ、古い接続キャッシュ、現在のネットワークサービスを重点的に確認します。ブラウザーのリクエストがログに入っているのに失敗する場合は、DNS、TCP、TLS、REALITY、リモート側の切断のどの段階で失敗したかを確認します。対象リクエストがログにまったく出ない場合、通信の引き継ぎがまだ成立していません。先にプロトコルパラメータを変更しないでください。

エラーの段階ごとにログを読む

ログの「名前解決失敗」は通常、ドメインから利用可能なアドレスを得られなかったことを示します。「接続タイムアウト」は制限時間内にネットワーク接続を完了できなかったという意味ですが、対象への到達不能、ポート制限、ルーティングエラーなど複数の原因があります。「接続拒否」は対象アドレスから明確な応答があったものの、そのポートが接続を受け付けなかったことを示します。TLSまたはREALITYのハンドシェイクエラーでは、サーバー名、時刻、公開鍵、ショートID、フィンガープリントなどを重点的に確認します。

ログは時系列で読み、最後の1行だけを切り出さないでください。最後の行は、それ以前のエラーを上位層がまとめたものかもしれません。再現前にログを消去するか現在時刻を記録し、対象操作を1回だけ実行して、リクエスト開始から失敗終了までの連続した部分を保存します。公開して相談する場合は、サブスクリプションURL、ユーザー識別子、サーバーアドレスなどの機密パラメータを隠します。ただしエラー種別、時系列、クライアントで行った操作手順は残してください。

比較テストで範囲を絞る

有効な比較テストでは、1つの変数だけを変更します。同じノードを2つのネットワークでテストすれば、現在のネットワークが関係しているか判断できます。同じネットワークで同一サブスクリプションの別ノードへ変更すれば、ノード側の違いを比較できます。ノードを固定したままシステムプロキシとTUNをそれぞれテストすれば、通信の引き継ぎ方法を判定できます。他の設定を変えずにDNSを初期状態へ戻せば、カスタムDNSが異常を引き起こしたか確認できます。

無効な比較テストは、一度に多くの項目を変更します。サブスクリプション更新、ノード変更、TUN有効化、DNS変更、ルールデータベース更新を同時に行うと、問題が一時的に解消しても、何が効いたのか分かりません。次の障害では最初からやり直すことになります。安定した設定について、クライアント、通信の引き継ぎ方法、ルーティングモード、必要なカスタム項目を含む記録を残してください。

サブスクリプション更新と設定のバックアップ

サブスクリプションの更新によって、ノードが追加、削除、変更されることがあります。手動で重要な調整を行っている場合は、更新時にクライアントが上書きするか確認してください。サブスクリプションのノードとローカルで作成したノードは別グループで管理し、更新時にローカルの内容を誤って削除しないようにします。更新後はまずノード数と名前の変化を比較し、1つのノードを選んで確認します。すべてのノードをすぐに高頻度でテストする必要はありません。

バックアップにはサブスクリプショングループ情報、必要なルーティング設定、カスタムDNSを含めます。ただし機密情報を公開同期ストレージに置かないでください。バックアップを復元した後も、システム権限、TUNの許可、ローカルポートを再確認する必要があります。これらの状態はクライアント設定に完全には含まれない場合があります。プラットフォームをまたいで移行する場合も、すべての設定項目が1対1で対応すると考えず、まずサブスクリプションを再インポートし、必要なポリシーだけを手動で戻してください。

クライアント、カーネル、ルールデータを更新する

クライアントの画面、プロキシカーネル、GeoIP・GeoSiteデータは別の層です。クライアント更新では画面や設定形式が変わることがあります。カーネル更新ではプロトコルパラメータのサポートが変わる可能性があります。ルールデータ更新では分類タグが変わります。安定した環境では個別に更新し、更新のたびに基本接続、通信の引き継ぎ、ルーティングを確認します。問題が起きても、どの層に戻すべきか特定できます。

インターネット上の特定バージョン番号だけを根拠に、必ず更新すべきだと判断しないでください。本ページでは固定のバージョン情報を掲載せず、実際に利用できるパッケージはダウンロードページに表示される内容を基準とします。更新前に起動中のクライアントを終了し、動作している設定を保存します。更新後に旧設定を読み込めない場合は、まず移行案内とログを確認し、すぐに元の設定ディレクトリを上書きしないでください。

サブスクリプションの更新に成功したのに、なぜアクセスできないのですか？

サブスクリプションの更新成功は、クライアントが設定を取得して解析できたことを示すだけです。次にノードを選択し、ノードが実接続を完了できることを確認し、通信の引き継ぎ方法を有効にして、アプリのリクエストがログに入ることを確認します。まず現在のノードが本当にアクティブ項目になっているか確認し、実接続テストを1回行ってください。テストに失敗する場合は、ログの段階に従ってネットワーク、時刻、接続パラメータを確認します。テストに成功したのにアプリのリクエストログがない場合は、システムプロキシ、TUN、Androidのアプリ振り分けを確認します。

サブスクリプションには、一時的に利用できないノードや条件の異なるノードが含まれる場合もあります。リストの先頭だけをテストしたり、すべてのノードの失敗をクライアントのせいにしたりしないでください。同じサブスクリプション内でパラメータ構成が異なる少数のノードを比較すると、単一ノードの問題か、サブスクリプション全体の問題かを判断しやすくなります。

システムプロキシとTUNは同時に有効にすべきですか？

通常は必要ありません。対象アプリに応じて1つの方式を選びます。ブラウザーや多くのシステムプロキシ対応デスクトップアプリは、まずシステムプロキシを使います。システムプロキシを読み取らず、より広い範囲を引き継ぐ必要があるアプリはTUNを検討します。両方を同時に使える場合もありますが、特にDNS、LAN、仮想ネットワーク環境では経路の判断が難しくなります。

同時に有効にした状態から調べる場合は、まずTUNを無効にしてシステムプロキシだけを残し、ブラウザーで確認します。システムプロキシの検証に成功したら、それを解除してTUNだけをテストします。これにより、それぞれの入口が正常か確認できます。古い接続を終了せずに同じテスト中で何度も切り替えないでください。アプリが以前のセッションを再利用する可能性があります。

クライアント終了後にネットワークが異常になるのはなぜですか？

最も多い原因は、システムプロキシが停止済みクライアントのローカルポートを指し続けていることです。クライアントを再起動し、「システムプロキシを解除」を実行してから正常に終了します。WindowsとmacOSではシステムネットワーク設定でプロキシ値も確認できます。Linuxではデスクトッププロキシに加え、端末の環境変数も確認します。AndroidではシステムVPNに古い接続が残っていないか確認してください。

以前TUNを使っていた場合は、仮想インターフェースとルートが撤回されていることも確認します。通常のTUN停止で復旧しますが、プロセスの強制終了、システムクラッシュ、権限エラーによって状態が残ることがあります。Linuxでは ip route と ip rule を確認し、デスクトップシステムでは残った仮想インターフェースを無効にするかネットワークサービスを再起動します。ネットワークを復旧してからログを分析し、最初からすべてのクライアント設定を削除しないでください。

特定のアプリだけ接続できない場合、ノードを変更すべきですか？

まず変更しないでください。ブラウザーは正常で単一アプリだけ異常なら、ノードと基本的な通信の引き継ぎは利用できる可能性が高いです。そのアプリがシステムプロキシに従うか、Androidのアプリ振り分けから除外されていないか、独自プロキシ、固定DNS、QUIC、特殊なネットワーク権限を使っていないかを確認します。デスクトップアプリがシステムプロキシを読まない場合は、アプリ設定でローカルHTTPまたはSOCKSポートを指定するか、TUNを個別にテストします。

ログにそのアプリのリクエストがあり、特定のドメインが直接接続または遮断されている場合は、ルーティングルールを確認します。リクエストがログにまったくない場合は、まだ通信の引き継ぎ層の問題です。リクエストがクライアントに入り、リモート接続段階で失敗していることを確認できた場合に、ノード変更が有効な比較になります。

REALITY設定で接続に失敗した場合、どの項目を確認すべきですか？

まずサーバーアドレス、ポート、ユーザー識別子、flowを確認し、次にserverName、公開鍵、ショートID、フィンガープリントを照合します。項目名はクライアント画面によって多少異なることがありますが、値はサーバー側から提供された設定と一致していなければなりません。システム時刻の大きなずれ、チャットアプリによるサブスクリプションパラメータの切り詰め、コピー時の文字抜けでもハンドシェイクに失敗します。

不足している値を推測で補わないでください。VLESSを見たからといって、セキュリティ層を無効にするのも避けます。REALITYは接続セキュリティに関わるパラメータの組み合わせであり、単独のノード名ではありません。サブスクリプション由来なら、まず更新して提供元の説明と比較します。単一リンク由来なら、手動で修正するより元のリンクを再インポートする方が確実です。

GeoIPまたはGeoSiteの更新後にクライアントが起動しない場合はどうすればよいですか？

まずログで、データベース読み込み失敗、分類タグの不存在、ファイル形式の非互換が報告されていないか確認します。更新前のデータファイルを戻し、ルーティングルールを変更せずに再起動します。復元後に正常化した場合は、新しいデータまたは互換性に問題が集中しています。まだ失敗する場合は、ルール編集時に名前の誤りやJSON構造のエラーがないか確認します。

データの問題を隠すために、カーネルも同時に変更しないでください。カーネル、ルール、データベースを分けて検証します。安定した状態に戻ったら、現在のカーネルが参照タグをサポートしているか確認します。データ更新と読み込み失敗からの復旧手順は、ルールデータベースのメンテナンス記事で詳しく説明しています。

DNSにはどのアドレスを設定すべきですか？

すべてのネットワークに適した固定の答えはありません。まずDNSリクエストをローカルから直接送るのか、プロキシ出口経由で送るのかを明確にし、その経路で安定して到達できる名前解決サービスを選びます。特別な要件がなければ、まずクライアントのデフォルト方式で接続を確認してください。ドメイン解決の異常、振り分けの要件、プライバシー上の境界がある場合にだけ、DNSを個別に変更します。

変更後は、システムの名前解決ツール、ブラウザーのリクエスト、クライアントログを照合します。直接アドレスにも接続できない場合、問題は通常DNSではありません。ドメインがアドレスへ解決されてもTLSまたはREALITY段階で失敗する場合は、接続パラメータを確認します。複数のDNSアドレスを記録なしに連続して変更しないでください。

最小限の利用可能な設定に戻すにはどうすればよいですか？

まずTUNを停止し、システムプロキシとアプリ振り分けを解除して、DNSと基本ルーティングを初期状態に戻します。出所が明確なサブスクリプショングループを1つだけ残し、更新後にノードを1つ選んで実接続テストを行います。テストに成功したらシステムプロキシだけを有効にし、ブラウザーから新しいリクエストを送り、ログを確認します。デスクトップ環境で対象アプリがシステムプロキシに従わない場合は、システムプロキシを解除してからTUNを単独でテストします。

Androidではまず複雑なアプリ振り分けを解除し、システムVPNの許可を残してブラウザーで確認します。Linuxではshellのプロキシ環境変数も解除します。最小設定が安定したら、ルーティング、DNS、アプリ振り分け、バックグラウンド設定の順に1つずつ戻します。項目を追加するたびに再確認してください。クライアントを何度も再インストールするより速く、問題が発生した証拠も残せます。