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

共通の準備と設定の範囲

インストール前に、デバイスのアーキテクチャ、サブスクリプションの種類、プロキシの対象、現在のネットワーク状態を確認します。準備を明確にしておくほど、接続に失敗した際に問題箇所を絞り込みやすくなります。

まずクライアント、カーネル、サブスクリプションを区別する

v2rayN、v2rayNG、v2flyNGはグラフィカルクライアントで、サーバー情報の保存、実行設定の生成、カーネルの起動、システムプロキシの制御を担当します。XrayとV2Flyは、接続、トランスポート、ルーティングを実際に処理するカーネルの系統です。サブスクリプションはサービス側が提供するサーバー設定の集合で、通常はアドレス、ポート、ユーザー識別子、プロトコル、トランスポート方式、TLSパラメータ、サーバー名などが含まれます。3者は同じ階層ではありません。クライアントが操作画面を提供し、カーネルが設定を実行し、サブスクリプションが利用可能な接続パラメータを提供します。

デスクトップではv2rayNを優先します。Windows、macOS、Linuxでサブスクリプションのグループ、サーバー一覧、ルーティング設定の構成が近く、デバイス間で移行する際にも確認しやすいためです。Androidでは通常、Xrayカーネルを使用するv2rayNGを選びます。V2Flyカーネルの動作に合わせる必要がある場合はv2flyNGを使用してください。プロトコル名だけで接続可否を判断せず、トランスポート層、TLS、セキュリティパラメータ、サーバー側設定が完全に一致していることも確認します。

プロセッサのアーキテクチャとインストールパッケージの種類を確認する

Windowsの一般的なデスクトップではx64パッケージを使用します。macOSではチップに応じてApple Silicon版またはIntel版を選びます。Androidの主流デバイスは通常arm64に対応しています。アーキテクチャを確認できない場合や互換性が複雑な場合はユニバーサル版を使用できます。Linuxではプロセッサのアーキテクチャに加えてパッケージ体系も区別します。Debian、Ubuntuとその派生版ではdeb、Fedora、Rocky Linux、openSUSEなどでは通常rpmを使用します。パッケージの種類を間違えると、インストーラーが実行を拒否したり、アーキテクチャ不一致が表示されたり、起動直後に終了したりします。

元の情報を保存し、基準構成を作る

インポート前にサブスクリプションURLの原文を保存し、チャットでの転送、ノートの同期、QRコードのスクリーンショットなどで長期間公開しないでください。サブスクリプションURLには通常、ノード一式を読み取る権限があり、漏えいすると第三者に利用される可能性があります。初回設定ではサブスクリプションを1つのグループだけインポートし、利用できることを確認したサーバーを1台選び、デフォルトのルーティングとDNSで基準構成を作ります。基準接続が成功してから、カスタムルーティング、TUN、FakeDNS、Mux、アプリ別プロキシを1項目ずつ有効にしてください。複数のパラメータを一度に変更すると原因が重なり、どの項目が異常を招いたのか判断できなくなります。

開始前に、同種のプロキシクライアントを終了し、システム時刻、タイムゾーン、ネットワーク自体が正常であることも確認します。TLSハンドシェイクには正確な時刻が必要で、大きなずれは証明書エラーや接続直後の切断として現れます。社内ネットワーク、ゲストネットワーク、公共Wi-Fiでは特定のポートやUDPが制限される場合があるため、まずブラウザーで通常のWebサイトに直接アクセスし、DNSと基本ネットワークが利用できることを確認します。手動プロキシを設定済みの場合は元の値を記録してからクライアントに管理させ、終了時に古いアドレスが残らないようにします。

再現可能な手順を作る

1. 対応するインストールパッケージを選ぶプラットフォーム、プロセッサアーキテクチャ、パッケージ体系に基づいて選び、名前が似ている別ビルドで代用しません。
2. サブスクリプショングループを1つインポートする名前とURLを入力し、更新後にサーバー項目が正常に生成されたことを確認します。
3. 使用するサーバーを選ぶまず実際の接続をテストし、その後で一括速度測定や並び順の調整を行います。
4. 適用方法を1つ有効にするシステムプロキシとTUNはまずどちらか一方だけで検証し、ネットワーク経路を同時に変えないようにします。
5. 有効な設定を記録するルーティングモード、DNS方式、クライアント設定を保存し、アップグレードや移行後に復元できるようにします。

準備段階の目的は、すべての項目を先に調整し終えることではなく、再現可能で元に戻せる設定経路を作ることです。どのプラットフォームで問題が起きても、「インストールは完全か、サブスクリプションは解析されたか、サーバーは利用可能か、カーネルは起動したか、トラフィックはクライアントに入っているか、DNSは適切か」の6層の順に確認します。これにより、ノード障害をインストール障害と誤認したり、システムプロキシの残留中にサブスクリプションを何度も変更したりするのを防げます。

Windowsのインストール、システムプロキシとTUN

Windowsではv2rayNを使用します。デスクトップ版はクロスプラットフォームのUIを採用し、クラシックWPF版は従来のWindows操作を好むユーザーに適しています。どちらもサブスクリプション、サーバー、ルーティングの考え方は共通です。

ダウンロードとインストールの選択

Windowsダウンロードエリアで、使い方に応じてデスクトップ版またはクラシックWPF版を選びます。新規インストールでは通常デスクトップ版から始めます。従来のトレイ操作、既存のWPF設定ディレクトリ、以前の手順を引き続き利用する場合はクラシック版を選べます。インストール前に旧クライアントを終了し、使用中のファイルをインストーラーが置き換えられない状態を避けてください。インストール後はスタートメニューから起動し、初回起動時にメインウィンドウ、通知領域のクライアント入口、カーネル種別が正常に表示されることを確認します。

システムがネットワークアクセスの許可を求めた場合は、実際のネットワーク環境に応じてクライアントの通信を許可します。この通知は受信待ち受けやLAN機能に関するもので、システムプロキシの有効化とは別です。管理対象デバイスでは、一般ユーザーによるネットワークコンポーネントのインストールやサービス作成が禁止されている場合があります。権限を求められたら、別のディレクトリに何度も展開するのではなく、管理者が許可した方法でインストールしてください。ポータブル利用では、自動削除の対象、読み取り専用、またはパスが長すぎる場所も避けます。

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

サブスクリプショングループの管理を開き、グループ名を追加してURLを貼り付けます。保存後に更新すると、メイン一覧にプロトコル、別名、サーバー情報が表示されます。一覧が空の場合は、URLが完全か、空白が混入していないか、ブラウザーで開いた際にサーバーが有効な内容を返すかを確認します。更新に成功したらサーバーを1台選び、使用するサーバーに設定します。速度測定は特定の測定方法における応答を示すだけで、すべての通信に適しているとは限りません。初回確認では、実際のWebリクエストと対象アプリの接続を基準にします。

サブスクリプションの更新では、サーバー側の内容に応じて項目が追加、変更、削除されます。サブスクリプションから生成されたサーバーパラメータを手動で変更すると、次回更新時に上書きされる可能性があります。個別設定を保持したい場合は、クライアントのルーティング、DNS、または独立した手動サーバーグループに変更を置くのが基本です。サブスクリプションを削除する前に、そこに唯一利用可能な設定がないことを確認してください。同じURLを再追加すると新しいグループIDが生成され、以前の並び順や選択状態が維持されない場合があります。

システムプロキシの3つの状態

Windowsのシステムプロキシは、システムプロキシ設定に従うブラウザーやデスクトップアプリに主に影響します。一般的な状態は、システムプロキシを解除、システムプロキシを設定、システムプロキシを変更しない、の3つです。通常は「システムプロキシを設定」を選び、終了時に「システムプロキシを解除」を実行します。「変更しない」は、ブラウザーだけに手動でプロキシを設定する場合、特定のアプリだけをローカルポートに接続する場合、別のネットワークツールが一括管理する場合に適しています。切り替え後はWindowsのプロキシ設定を開き、アドレスがローカルループバックを指し、ポートがv2rayNの現在の待ち受けと一致するか確認します。

クライアント終了後にブラウザーが接続できなくなった場合は、まずシステムプロキシが残っていないか確認します。v2rayNを再起動して解除を実行するか、システム設定で手動プロキシを無効にします。ローカル待ち受けポートをサブスクリプション内のリモートサーバーポートに変更してはいけません。前者はアプリがv2rayNへ接続する入口で、後者はカーネルがサーバーへ接続する宛先であり、役割がまったく異なります。

ipconfig /flushdns
netsh winhttp show proxy
Get-NetTCPConnection -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess

上記のコマンドは、WindowsのDNSキャッシュの更新、WinHTTPプロキシ状態の確認、本機の待ち受けポートの確認に使用します。ブラウザーのシステムプロキシとWinHTTPプロキシは同じ設定ではありません。そのため netsh winhttp show proxy が直接接続を表示していても、ブラウザーがシステムプロキシを使用している可能性があります。トラブル対処では、Windows設定、クライアントの状態、対象プログラム自身のプロキシ設定を同時に確認します。

TUNモードとプラットフォーム固有の問題

TUNは仮想ネットワークインターフェースを作成し、システムプロキシを参照しないプログラムの通信もクライアントに取り込めるようにします。有効化前にシステムプロキシで安定した接続を1度確認し、v2rayNのTUNコンポーネントと権限が準備できているか確認します。初回有効化では管理者権限の要求やネットワークインターフェースのインストールが発生する場合があります。成功するとシステムのルーティングテーブルに対応するインターフェースが現れ、クライアント停止時には元の経路へ戻る必要があります。スリープ、ネットワーク切り替え、異常終了によって仮想インターフェースだけが残り、カーネルが動作していない状態になると、すべてのアプリが接続できなくなることがあります。

ゲーム、仮想マシン、コンテナソフト、企業ネットワーククライアントは、ルーティングやDNSを同時に変更する場合があります。競合したら、まずTUNを無効にしてシステムプロキシを復元し、接続を確認します。その後、ルールで対象ネットワークを除外するか、仮想NICの優先順位を調整します。LANプリンター、ネットワークストレージ、リモートデスクトップのアドレスは通常、直接接続にします。プライベートアドレス帯をすべてリモートへ送ると、LAN機器に届かない、ドメイン認証が遅い、ローカル開発サービスに接続できないといった問題が起きます。

Windowsの更新やネットワークドライバーの変更後にTUNが突然機能しなくなった場合は、システムを再起動し、仮想インターフェースが正常に読み込まれているか確認します。セキュリティソフトが新しい待ち受けポートやネットワークインターフェースを制限することがあるため、プロセスのパスとローカル待ち受けの用途に基づいて明確なルールを設定します。ログにカーネル起動済みと表示されるのにブラウザーのリクエスト記録がない場合、問題は通常システムプロキシまたはアプリのプロキシ層にあります。リクエストがクライアントに入った後でリモート接続に失敗する場合は、サーバーパラメータ、DNS、TLS、現在のネットワーク制限を確認します。

macOSのインストール、チップの選択とネットワーク権限

macOSではv2rayNデスクトップ版を使用します。正しいチップ向けビルドを選び、初回起動の許可を完了し、システムプロキシとネットワーク拡張の権限範囲を理解することが重要です。

チップを確認してインストールする

システムの「このMacについて」でチップまたはプロセッサを確認します。Appleチップの名称が表示される場合はApple Silicon版、Intelプロセッサと表示される場合はIntel版を選びます。macOSダウンロードエリアから対応するDMGを取得し、ディスクイメージを開いてアプリを「アプリケーション」フォルダへドラッグし、アプリケーションフォルダから起動します。マウントしたディスクイメージから長期間直接実行すると、アップグレード、権限の保存、自動起動が不安定になる場合があります。

初回起動時に、システムがアプリの入手元とネットワークアクセス権限を確認します。システムの指示に従って許可を完了してから設定をインポートしてください。ダブルクリックしても反応しない場合は、「プライバシーとセキュリティ」で起動を阻止された項目がないか確認し、パッケージのアーキテクチャがデバイスと一致しているか確認します。Apple SiliconデバイスにIntel版を誤ってインストールすると互換変換レイヤーが必要になる場合があります。動作する環境もありますが、標準の選択にはしないでください。ネイティブ版のほうが起動、リソース使用量、ネットワークコンポーネントの互換性で有利です。

サブスクリプションのインポートとメニューバーの状態

v2rayNのサブスクリプション手順はWindows版と同じです。グループを作成し、URLを入力し、更新して、使用するサーバーを選びます。メインウィンドウを閉じてもメニューバーで動作している場合があるため、終了状態はウィンドウだけでなくメニューバーで確認します。サブスクリプション更新後にサーバー一覧が変わらない場合は、選択中のグループを確認してから更新ログを確認します。同じ名前のグループが複数あると誤選択しやすいため、用途やサービス元に基づく短く明確な名前を付けてください。

サーバーを選んだらまずカーネルを起動し、ログに設定解析エラーがないことを確認します。その後システムプロキシを有効にします。macOSではネットワークサービスごとにプロキシ設定が保存されるため、Wi-Fi、有線、その他のネットワークサービスで状態が異なる場合があります。ネットワークを切り替えた後にブラウザーが突然直接接続する場合は、現在のアクティブなネットワークサービスがクライアントによってプロキシ設定されているか確認します。逆にクライアント終了後にWebページへアクセスできない場合は、システムのネットワーク設定でHTTP、HTTPS、SOCKSプロキシに古いアドレスが残っていないか確認します。

システムプロキシ、ターミナル、独立したプロキシプログラム

システムプロキシは、macOSのネットワークプロキシ設定に従うアプリを主に対象とします。ターミナルのコマンド、開発ツール、一部のクロスプラットフォームプログラムは環境変数を読む場合もあれば、システム設定を完全に無視する場合もあります。特定のコマンドラインプログラムにローカルプロキシを使わせる場合は、現在のターミナルセッションだけで対応する変数を設定し、ポートをv2rayNの実際の待ち受け値に置き換えます。作業後にターミナルを閉じれば解除できるため、プロキシ変数をグローバルな起動スクリプトへ恒久的に書き込まないでください。

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ポート
env | grep -i proxy

ここでいう「ローカルHTTPポート」と「ローカルSOCKSポート」はクライアントの設定から確認し、他のデバイスの値をそのまま使用しないでください。プログラムがHTTPプロキシにしか対応していない場合、SOCKSアドレスを入力してはいけません。コマンドラインツールによっては大文字と小文字の環境変数の扱いが異なるため、トラブル対処ではツールのドキュメントを確認し、env | grep -i proxyで現在のセッションにどの変数が存在するか確認します。

TUN、DNS、スリープからの復帰

TUNモードにはより高いレベルのネットワーク権限が必要です。初回有効化時には、ネットワーク拡張の確認、デバイスパスワードの入力、バックグラウンド項目の許可を求められる場合があります。許可はコンポーネントの読み込みを解決するだけで、ルーティングが正しいことを意味しません。有効化後は、通常のWebページ、LANアドレス、ターミナルのリクエスト、対象アプリを順番に確認します。LANだけが使えない場合はプライベートアドレスの直接接続ルールを確認します。すべてのドメインに失敗して既知のアドレスへは直接アクセスできる場合はDNSを重点的に確認します。スリープ復帰後に完全に接続できない場合は、まずTUNを停止し、クライアントを終了してから再起動します。

macOSのネットワークサービスの順序、プライベートリレー系のネットワーク機能、企業の構成プロファイル、その他の仮想ネットワークプログラムは、通信経路を変更する可能性があります。トラブル対処では、デフォルトルートを管理するプログラムを一度に1つだけ実行します。家庭のWi-Fiから公共Wi-Fiへ切り替えると、サーバーへの到達性、UDPの利用可否、DNSの応答が変わる場合があります。切り替え前の状態だけでクライアントの故障と判断しないでください。まず接続の適用を停止して直接接続へ戻し、次にカーネルを再起動し、最後にプロキシを再び有効にするのが安全な復旧手順です。

アップグレードと設定の移行

アップグレード前にメニューバーのv2rayNを終了し、現在のサブスクリプショングループ、ルーティングモード、カーネル種別、ローカルポートを記録します。アプリを上書きしても通常は設定が変更されませんが、古いディレクトリから実行ファイル一式をそのままコピーすると、無効なキャッシュや古いコンポーネントが混入する可能性があります。サブスクリプションURLと明確なカスタムルールだけを保持し、新しいプログラムで基本機能を確認してから移行するのが安全です。新旧ビルドで設定構造を共有できない場合は、内部データベースを手で編集せず、サブスクリプションを再インポートします。

移行後はログイン時の起動とバックグラウンド項目の一覧を確認し、旧プログラムと新プログラムが同時に起動しないようにします。メニューバーに似た入口が2つ表示される場合は、すべてのインスタンスを終了してから「アプリケーション」フォルダの対象バージョンを起動します。ログや一時設定にサーバー情報が含まれる場合があるため、診断資料を外部へ渡す前にURL、ユーザー識別子、ドメイン、ポートを削除します。通常はエラーの種類、発生段階、必要なカーネルメッセージだけで十分に問題を特定できます。

Linuxのインストール、デスクトップ統合と権限

Linuxではv2rayNデスクトップ版を使用します。インストール前に、ディストリビューションのパッケージ体系、プロセッサアーキテクチャ、デスクトップセッション、グラフィック依存関係を確認し、UIの問題をカーネルの問題と取り違えないようにします。

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

Debian、Ubuntu、Linux Mintなどでは通常debを選び、Fedora、Rocky LinuxなどRPMベースのパッケージ管理を使用するディストリビューションではrpmを選びます。デバイスのアーキテクチャはuname -mで確認できます。一般的なx86_64はx64、aarch64はarm64に対応します。Linuxダウンロードエリアでは、この2つの条件を同時に一致させてください。パッケージ形式だけ一致してアーキテクチャを間違えると、インストーラーは拒否します。アーキテクチャだけ一致してパッケージ体系を間違えると、対応するパッケージ管理メタデータが不足します。

uname -m
cat /etc/os-release
echo "$XDG_CURRENT_DESKTOP"
echo "$XDG_SESSION_TYPE"

/etc/os-releaseはディストリビューションと基本体系の識別に、XDG_CURRENT_DESKTOPとXDG_SESSION_TYPEはデスクトップ環境およびX11かWaylandかの判定に使用します。v2rayNのプロキシカーネルは特定のデスクトッププロトコルに依存しませんが、トレイアイコン、ウィンドウの拡大縮小、自動起動、システムプロキシの書き込みはデスクトップ環境の影響を受ける場合があります。サーバー版や最小構成のシステムに完全なグラフィカルセッションがない場合、グラフィカルクライアントをシステムサービスとして配置するのは適していません。

システムのパッケージマネージャーでインストールする

debパッケージはグラフィカルなソフトウェアインストーラーで開くことも、システムのパッケージ管理コマンドでインストールすることもできます。rpmも同様です。コマンドラインでのインストールには、不足している依存関係を明確に表示できる利点があります。ディストリビューションのパッケージ管理を回避するためのものではありません。インストールファイル名は実際にダウンロードした結果を使用し、例の文字列をそのままパスとして入力しないでください。

sudo apt install ./ダウンロードしたv2rayNパッケージ.deb
sudo dnf install ./ダウンロードしたv2rayNパッケージ.rpm

インストール後はデスクトップアプリ一覧から起動します。ウィンドウが表示されない場合は、まずターミナルからアプリの入口を実行してエラー出力を確認し、グラフィックランタイム、ディスプレイサーバーの環境変数、ユーザーディレクトリへの書き込み権限を確認します。グラフィカルクライアントをrootで常用しないでください。rootで起動すると管理者のホームディレクトリに別の設定が作成され、後から生成されたファイルを一般ユーザーが読めなくなる可能性があります。ソフトウェアパッケージのインストール、TUNの設定、システム全体のネットワーク設定変更時だけ、指示に従って権限を昇格します。

サブスクリプション、システムプロキシ、デスクトップ環境の違い

サブスクリプションのインポートは、グループの追加、内容の更新、サーバーの選択、カーネルの起動という順序で行います。カーネル起動後はまずローカルHTTPとSOCKSの待ち受けポートを確認し、アプリの通信をクライアントへ送る方法を決めます。GNOME、KDE Plasmaなどのデスクトップ環境ではシステムプロキシの保存場所が異なり、v2rayNが自動で書き込めるかはデスクトップ統合に左右されます。自動設定後もブラウザーがプロキシを通らない場合は、デスクトップのネットワーク設定でループバックアドレスとポートを確認します。ただし、旧クライアントのプロキシ値を同時に残さないでください。

ターミナルプログラムは通常、http_proxy、https_proxy、all_proxyの環境変数を読み取ります。グラフィカルプログラムはデスクトッププロキシに従う場合もあれば、独自設定を使う場合もあります。systemdが管理するバックグラウンドサービスは、ログイン中のターミナルの環境変数を自動的には引き継ぎません。サービス自身の設定で明示する必要があります。トラブル対処では対象がブラウザー、ターミナルプロセス、デスクトップアプリ、システムサービスのどれかを確認し、対応する入口を調べます。デスクトップのプロキシスイッチだけを見てはいけません。

TUN、ルーティングテーブル、ローカルサービス

LinuxのTUNには、カーネルの対応、デバイスノード、ネットワークインターフェースを作成する権限が必要です。有効化前に/dev/net/tunが存在するか確認できます。コンテナ、仮想マシン、ネットワーク名前空間、ファイアウォール管理ツールは、ポリシールートやパケットマークを追加することがあります。v2rayNでTUN起動済みと表示されてもトラフィックがカーネルに入らない場合は、デフォルトルート、ポリシールート、DNSの向き先、ファイアウォールが仮想インターフェースの転送を許可しているか確認します。既存ルールを理解しないままファイアウォール全体を消去しないでください。システムサービスやコンテナネットワークに影響します。

ip address
ip route
ip rule
ss -lntup
resolvectl status

ip routeはデフォルトルートとプライベートネットワークへの経路の確認に、ip ruleはポリシールートの確認に、ssはローカルプロキシポートの待ち受け確認に使用します。resolvectl statusではsystemd-resolvedを使用するシステムの現在のDNSを確認できます。ディストリビューションが別のリゾルバーを使用している場合は、対応するネットワーク管理サービスを確認し、/etc/resolv.confを何度も上書きしないでください。このファイルは多くのディストリビューションでNetworkManagerや名前解決サービスが動的に生成しており、手動変更はネットワーク再接続時に消える場合があります。

トレイ、自動起動、アップグレード

一部のデスクトップ環境では従来のトレイアイコンが初期状態で表示されず、ウィンドウを閉じた後にクライアントがまだ動作しているか確認しにくいことがあります。初回利用時にウィンドウを閉じたときの動作を確認し、プロセス一覧で終了方法を確認します。自動起動を設定する場合はデスクトップの自動起動入口を1つだけ残し、ユーザー単位の自動起動ファイルとデスクトップ設定が重複しないようにします。重複したインスタンスは同じローカルポートを奪い合い、2つ目の起動失敗、サブスクリプション更新は成功するのにプロキシが待ち受けない、といった状態になります。

アップグレード前にすべてのインスタンスを終了し、ディストリビューションのパッケージマネージャーで新しいパッケージをインストールします。依存関係の衝突が起きた場合は、まずパッケージマネージャーが示す具体的なパッケージ名とバージョン条件を確認し、デスクトップランタイムをむやみに削除しないでください。設定移行はサブスクリプション、ルーティング、DNS設定を中心に行い、キャッシュや実行時に生成されるファイルは一括コピーする必要がありません。アップグレード後は「UI起動、カーネル起動、ローカル待ち受け、システムプロキシ、TUN」の順に確認し、どの層で変化が起きたかを特定します。

Androidのインストール、バックグラウンド動作とアプリ別プロキシ

Androidではv2rayNGを第一候補とし、デフォルトでXrayカーネルを使用します。V2Flyカーネルの動作が必要な場合はv2flyNGを選びます。どちらもインポート、接続、アプリ別プロキシの考え方は近いものです。

arm64またはユニバーサル版を選ぶ

近年の主流Androidスマートフォンやタブレットは通常arm64を使用するため、対応するパッケージを優先します。デバイスのアーキテクチャを確認できない場合、システムが古い場合、インストール時に互換性エラーが表示される場合は、ユニバーサル版を使用できます。ユニバーサル版は複数のアーキテクチャ用コードを含むためファイルサイズは大きくなりますが、互換範囲は広くなります。Androidダウンロードエリアでは、まずクライアント、次にアーキテクチャを選びます。通常はv2rayNGを使い、V2Flyカーネルが明確に必要な場合だけv2flyNGをインストールします。

インストール前に、現在使用しているブラウザーまたはファイルマネージャーからダウンロードしたパッケージを開くことがシステムで許可されているか確認します。この権限は通常、提供元アプリごとに管理され、インストール後は該当する提供元のインストール許可を無効にできます。上書きアップグレードではアプリIDを一致させてください。署名が一致しないと表示された場合は強制的に上書きせず、サブスクリプションURLとカスタム設定を保存してから、インストール済みアプリと新しいパッケージの提供元が一致するか確認します。アンインストールするとアプリ固有の設定が消えるため、サブスクリプション情報を保存せずにアンインストールしてトラブル対処しないでください。

サブスクリプションのインポートとQRコード

サブスクリプションURLをコピーし、サブスクリプショングループで設定を追加して更新します。QRコードは単一サーバーやサービス側が提供するサブスクリプション情報のインポートに便利ですが、スキャン前に出所を確認してください。ギャラリーからの読み取りにはストレージまたは写真へのアクセス権限、カメラでのスキャンにはカメラ権限が必要です。機能を使うときだけ許可すれば十分です。インポート後は、サーバー項目にアドレス、ポート、プロトコル、トランスポート情報が含まれているか確認します。名前が文字化けしていても接続に影響しないことがありますが、すべての項目が空ならサブスクリプションが正しく解析されていません。

サーバーを選んで接続ボタンをタップすると、システムにネットワーク接続の許可ダイアログが表示されます。確認後にステータスバーへネットワーク接続の表示が現れれば、アプリが通信の入口を取得したことを示しますが、リモート接続の成功を意味するわけではありません。v2rayNGのログを確認し、実際のWebページを開いて検証してください。接続をタップした直後に切断へ戻る場合は、設定の解析、ポートの競合、システムによるアプリ起動制限を重点的に確認します。接続状態が続くのにWebページを開けない場合は、サーバーへの到達性、DNS、ルーティングモードを確認します。

バックグラウンド維持とバッテリー設定

Androidメーカーの省電力機能が画面消灯後にv2rayNGを制限することがあります。一定時間ロックすると接続が切れる、通知は残るのに通信がない、アプリへ戻ると再接続される、といった症状が現れます。システムのバッテリー設定でクライアントのバックグラウンド動作を許可し、保護対象アプリまたはバックグラウンド許可リストに追加します。メニュー名はデバイスによって異なりますが、バックグラウンド活動を許可し、自動凍結を無効にし、システムのクリーナーがクライアントのプロセスを終了しない状態にすることが基準です。

バックグラウンド維持のために、すべての省電力機能を無効にする必要はありません。問題がロック中、モバイルネットワークへの切り替え後、長時間の待機後だけ発生するかを確認してから、v2rayNGの設定を調整します。消費電力が明らかに増えた場合は、不要な全体プロキシ、頻繁なサブスクリプション更新、継続的な速度測定、高負荷なMux設定が有効になっていないか確認します。v2rayNGのバックグラウンド維持とバッテリー消費の対処を参考に、システム制限、アプリ別プロキシ、接続パラメータを順番に確認してください。

アプリ別プロキシとLANのバイパス

アプリ別プロキシでは、どのアプリをv2rayNGに通すかを制御します。対象を選ぶ方式では、選択したアプリだけがプロキシを使用します。選択を除外する方式では、選択したアプリが直接接続を維持します。有効化前に現在のモードを明確にし、決済、LAN制御、社内認証アプリを意図せずリモートへ送らないようにします。システムコンポーネント、ブラウザーエンジン、アプリ間には呼び出し関係があるため、主要アプリだけを選んでも、外部から開かれたWebページやダウンロードサービスが同じ経路を使うとは限りません。

LAN機器のアドレス、ルーター管理画面、キャスト機器、ネットワークストレージは通常、直接接続にします。v2rayNG接続後にこれらへアクセスできない場合は、ルーティングモードにプライベートアドレスの直接接続ルールが含まれているか確認します。モバイルネットワークとWi-Fiを切り替えるとローカルネットワークが変わるため、以前のネットワーク用の特定サブネットルールが新しいネットワークに適用できるとは限りません。一般的なプライベートアドレスルールは機器ごとの指定より安定しますが、企業ネットワークでは複雑な内部サブネットを使うことがあるため、実際の環境に応じて追加します。

モバイルネットワーク切り替えと接続復旧

Wi-Fiからモバイルデータへ切り替えると、基盤ネットワークのアドレス、DNS、IPv6の条件が変わります。アプリがシステム上は接続状態を維持していても、以前のリモートセッションは無効になっている可能性があります。通常はカーネルが接続を再構築します。長時間通信がない場合は、サブスクリプションをすぐ削除せず、まずクライアントの接続を一度切り替えます。公共Wi-Fiでは先にWeb認証が必要なことがあるため、プロキシを一時停止して認証を完了し、その後再接続します。

特定のアプリだけアクセスできない場合は、まずアプリ別プロキシを無効にして確認し、そのアプリがプライベートDNS、内蔵QUIC、独自プロキシ設定を使用していないか確認します。すべてのアプリで失敗する場合は、ログにDNSタイムアウト、接続拒否、TLS関連のメッセージがないか確認します。ログを共有する際はエラーの段階と種類だけを残し、完全なサーバーアドレス、ユーザー識別子、サブスクリプション内容を削除します。モバイルの問題はバックグラウンド制限やネットワーク切り替えと関係することが多いため、「フォアグラウンドでは正常か、バックグラウンドで異常か」「Wi-Fiでは正常か、モバイルネットワークで異常か」を必ず記録します。

サブスクリプション管理、プロトコルパラメータとルーティング

サブスクリプションは設定を配布し、ルーティングは通信ごとにどの出口から送るかを決めます。安定した設定のポイントは、サーバー側のパラメータとローカルのポリシーを区別し、誤った階層を繰り返し変更しないことです。

サブスクリプション更新の全プロセス

クライアントがサブスクリプションを更新すると、URLへリクエストを送り、返された内容を読み取り、各サーバー項目を解析してローカルグループへ書き込みます。どの層で失敗しても「更新失敗」と表示されますが、対処方法は異なります。リクエスト段階のタイムアウトでは現在のネットワークとURLの到達性を確認します。空の内容が返る場合はサブスクリプションの状態を確認します。解析に失敗する場合はエンコード、形式、クライアントの対応状況を確認します。書き込み後に一覧が空の場合はグループのフィルターと除外ルールを確認します。サブスクリプションリンクの無効化・解析失敗を6段階で確認する方法に沿って切り分けてください。

サブスクリプションURLにはアクセス認証情報が含まれる場合があるため、公開してはいけません。複数のデバイスで同じサブスクリプションを使う場合、短時間に連続更新しないよう更新頻度を適切に保ちます。クライアントが定期更新に対応している場合は、実際の用途に合う周期を設定できます。ただし、ノードの速度測定とサブスクリプション更新を同じ作業と考えないでください。更新は設定を同期するだけで、速度測定はサーバーへ能動的にアクセスします。サーバー側で項目が削除されると、次回更新で削除が反映される可能性があるため、重要な手動設定は独立したグループに置きます。

プロトコルとトランスポートのパラメータは一組で一致させる

VMess、VLESS、Trojan、Shadowsocksは異なるプロトコル体系を表し、WebSocket、gRPC、TCPなどはトランスポート層に属します。TLSとREALITYは安全なハンドシェイクおよびサーバーの識別パラメータに関係します。接続が成立するかどうかはプロトコル名だけでなく、パラメータ一式がサーバー側と一致するかで決まります。VLESSでよく使う項目にはユーザー識別子、トランスポート方式、セキュリティ種別、サーバー名、フロー制御があります。TrojanではパスワードとTLS関連情報、Shadowsocksでは暗号化方式とパスワードを一致させる必要があります。

サブスクリプションから正常に生成された設定では、通常プロトコル項目を手動で変更する必要はありません。サーバー側から明確な変更指示がある場合だけ、対応するパラメータを調整します。WebSocketパス、gRPCサービス名、サーバー名、公鍵のいずれかを空欄にすると、接続に失敗する可能性があります。クライアントに表示されるサーバーの備考は識別用であり、ハンドシェイクには使われません。備考を変更しても接続は変わりません。プロトコル選択の比較はVMess、VLESS、Trojan、Shadowsocksの用途別選び方を参照してください。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "server.example.com",
            "port": 443,
            "users": [
              {
                "id": "11111111-1111-4111-8111-111111111111",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "wsSettings": {
          "path": "/vless"
        }
      }
    }
  ]
}

この断片はフィールドの階層を説明するためのもので、例示されたドメインやユーザー識別子をそのまま接続に使用することはできません。実際の設定には、サーバー側と一致するTLSサーバー名、リクエストヘッダー、その他のトランスポートパラメータが必要です。グラフィカルクライアントでは通常、サブスクリプションが完全な構造を自動生成するため、日常の設定でJSONを直接編集する必要はありません。ログの確認、項目の照合、カスタムルールの移行時にだけ、これらの階層を理解していれば十分です。

ルールの照合順序

ルーティングは通常、ドメイン、IP、ポート、ネットワーク種別、プロセス情報に基づいて出口を照合します。上から順に判定する場合は、具体的なルールを前に、デフォルトルールを最後に置きます。一般的な出口はプロキシ、直接接続、ブロックです。LANと本機のアドレスは直接接続にし、リモート出口が必要なドメインはプロキシへ送ります。不要なテレメトリや悪意のあるアドレスはブロックできます。どのルールにも一致しない場合はデフォルト出口へ進むため、デフォルト値が設定全体の方向性を決めます。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.net"],
        "outboundTag": "proxy"
      }
    ]
  }
}

IPIfNonMatchは、ドメインルールに一致しなかった場合にアドレスを解決し、IPルールで判定することを示します。DNSの関与が増えるため、DNS設定は安定していなければなりません。AsIsを使用すると、ルーティングは元のドメインルールにより依存し、一致しなかったすべてのドメインをIP照合のために能動的に解決することはありません。利用できるポリシー名、ルールセットの提供元、更新方式はカーネルやクライアントによって異なるため、現在のクライアント画面に表示される選択肢を基準にしてください。

全体、バイパス、カスタムルールの選び方

全体モードは、ほぼすべての対象がプロキシへ入るため変数が少なく、短時間でサーバーの利用可否を確認するのに適しています。ただし、どの環境でもデフォルトにするものではありません。LAN機器、ローカル開発アドレス、社内サービスに届かなくなる可能性があります。中国本土をバイパスするプリセットは、内蔵のドメイン・アドレスルールで分流するため管理負担が少ない一方、クライアント更新に合わせてルールセットの更新が必要です。カスタムルーティングは、業務範囲が明確なユーザーに適しています。少数のルールから始め、追加するたびに照合目的と想定出口を記録してください。

ルーティングが有効かどうかを、Webページが開くかだけで判断しないでください。クライアントのログで対象ドメイン、照合されたルール、最終出口を確認します。アプリが先にドメインを解決してアドレスへ変換すると、クライアントにはIPしか見えない場合があります。スニッフィングを有効にすると一部の接続からドメイン情報を復元できますが、すべてのプロトコルを確実に識別できるわけではありません。ルーティングの問題では、アプリのリクエスト形式、DNSの応答、ルールの順序を同時に考慮します。デフォルトルーティング設定を1つ保存しておけば、カスタムルールが機能しないときにすぐ戻せます。

システムプロキシ、TUNとDNSの連携

システムプロキシはアプリがローカルポートへ能動的に接続するかを決め、TUNはネットワーク層から通信を取り込み、DNSはドメインからアドレスを取得する方法を決めます。役割は異なりますが、設定を誤るとどれも「Webページが開けない」という似た症状になります。

システムプロキシが適する場面

システムプロキシは設定の負担が小さく、ブラウザーやOSのプロキシインターフェースに従うデスクトッププログラムに適しています。クライアントは通常、本機でHTTP、SOCKS、混合ポートのいずれかを待ち受け、システムプロキシをループバックアドレスへ向けます。アプリのリクエストがローカルポートに入ると、カーネルがルーティングに従ってプロキシまたは直接接続の出口を選びます。システムプロキシですべてのプログラムをカバーできるわけではありません。コマンドラインツール、ゲーム、バックグラウンドサービス、独自のネットワークスタックを持つアプリは無視する場合があります。

システムプロキシを有効にする前に、ローカルポートがすでに待ち受けていることを確認します。ポートが別のプロセスに使用されていると、カーネルが別のポートへ切り替えるか、起動に失敗することがあります。その場合でもシステムは古いポートを指し続けます。クライアント終了時はシステムプロキシを解除し、異常終了後に全体が接続できなくなった場合は、まず残留設定を確認します。システムプロキシの向き先は127.0.0.1またはクライアントが明示的に許可する本機アドレスだけにし、リモートサーバーのアドレスを直接入力しないでください。

TUNの適用範囲が広い理由

TUNは仮想ネットワークインターフェースを作成して、システムルーティングから送られるパケットを受け取るため、HTTPやSOCKSプロキシに対応しないプログラムも対象にできます。クライアントはパケットをカーネルが処理できる接続へ変換し、ルールに従って直接接続またはプロキシの出口へ送ります。通常はより高い権限が必要で、他の仮想ネットワーク、企業のセキュリティプログラム、仮想マシン、コンテナのルーティングと競合しやすくなります。TUNを有効にする前に、同じサーバーがシステムプロキシモードで正常に接続できることを必ず確認します。

TUN設定には少なくとも、インターフェースアドレス、ルートの注入、DNSの引き継ぎ、MTU、バイパス範囲が関係します。MTUが大きすぎると、一部のネットワークでハンドシェイクは成功するのに大きなページの読み込みに失敗することがあります。小さすぎると断片化とオーバーヘッドが増えます。デフォルト値は多くのネットワークに適しているため、根拠がない状態で変更しないでください。問題がモバイルテザリング、企業ネットワーク、特定のブロードバンド環境だけで起きる場合は、MTUを段階的に下げて検証できますが、変更するたびに接続を再構築し、古いセッションを消去します。

DNSクエリはどの層で発生するか

アプリはドメインをシステムリゾルバーへ渡すことも、独自の暗号化DNSを使うこともできます。システムプロキシモードでは、SOCKSリクエストにドメインが含まれる場合もあれば、アプリが先に解決したIPだけが含まれる場合もあります。TUNモードでは、DNSの引き継ぎによってクエリをクライアントへ送り、ルーティングルールでドメイン情報を利用することがよくあります。DNSが直接接続を通り、対象接続がプロキシを通ると、現在の出口に適さないアドレスが返る場合があります。すべてのDNSをリモートへ強制すると、LAN名や社内ドメインに影響する可能性があります。

安定した構成では、公共ドメインと内部ドメインを分けて処理します。LANや社内ドメインはローカルDNSへ渡し、それ以外のクエリはルーティングポリシーに応じてリゾルバーを選びます。ドメインベースの分流には、クライアントがドメインを認識できること、またはスニッフィングで情報を補えることが必要です。スニッフィングはアプリの内容を復号するものではなく、接続のハンドシェイクから見える対象名を識別するものです。暗号化の度合いが高い通信や標準外の通信では、識別結果が限られる場合があります。

FakeDNSの適用範囲

FakeDNSは予約済みアドレスプールから仮想IPを返し、クライアント内部に仮想アドレスと元のドメインの対応を保存します。その後アプリが仮想IPへ接続すると、クライアントはドメインを復元して、ドメインルーティングを先に実行できます。TUN環境で安定したドメイン分流が必要で、接続からドメインを直接取得できない場合に適しています。動作原理と組み合わせ方はFakeDNSの仕組みと適用場面を参照してください。

FakeDNSはクライアントを経由しない通信には適しておらず、実アドレスに依存する診断ツール、LAN検出、一部アプリのアドレス検証に影響する場合があります。有効化後にシステムが予約済みサブネットのアドレスを表示しても、想定された動作であり、DNSが改ざんされたと判断してはいけません。確認すべきなのは、仮想アドレスへの接続をクライアントが受け取っているか、対応関係が存在するか、最終出口から実際の対象を解決して接続できるかです。FakeDNSを無効にするときは影響を受けたアプリを再起動し、必要に応じてシステムDNSキャッシュを更新して、古い仮想アドレスが残らないようにします。

段階的に設定する方法

1. まずシステムプロキシでノードを確認するサブスクリプション、プロトコル、TLS、リモート接続に基本的なエラーがないことを確認します。
2. デフォルトDNSのままドメインを確認する通常のWebページ、LANアドレス、対象アプリの基本動作を確認します。
3. TUNだけを有効にする複雑なルーティングはまだ追加せず、仮想インターフェース、デフォルトルート、アプリの適用範囲を確認します。
4. プライベートアドレスの直接接続を追加するルーター、プリンター、ネットワークストレージ、内部サービスへのアクセスを復旧します。
5. 最後にDNSとFakeDNSを調整する一度に1項目だけ変更し、ログでドメイン、アドレス、出口の対応関係を確認します。

設定が完了したかを判断するには、4種類のテストを行います。通常のWebページが読み込めるか、LANリソースへ直接接続できるか、システムプロキシを読まない対象プログラムが想定どおりTUNへ入るか、クライアント終了後に直接接続が復旧するかを確認します。1項目だけ成功しても、経路全体が正しいとは限りません。複雑なネットワークでは「システムプロキシ、デフォルトDNS、デフォルトルート」の基準設定を保存し、TUN設定を別に保存します。環境を切り替える際、毎回パラメータを手動で変更するより確実です。

設定のよくある問題と層別トラブル対処

トラブル対処はデータ経路に沿って外側から内側へ進めます。システムネットワーク、クライアントの入口、カーネルの起動、サブスクリプションパラメータ、リモート接続、DNSとルーティングの順です。各段階で観察できる結果を用意します。

第1層：直接接続とシステム状態を確認する

まずクライアントによる通信制御を停止し、TUNを無効にしてシステムプロキシを解除し、現在のネットワークで通常のWebサイトへ直接アクセスできることを確認します。直接接続自体が失敗する場合は、サーバー設定を変更する前に、Wi-Fi認証、モバイルデータ、ルーター、システム時刻、DNSを処理します。公共ネットワークでは認証ページを開く必要があり、企業ネットワークでは未知のポートが制限される場合があります。スリープ復帰後は、ネットワークアダプターが正しくアドレスを取得していないこともあります。直接接続の基準が正常であって初めて、後続のテストに意味があります。

同時に、他のプロキシクライアント、仮想ネットワークプログラム、残留した環境変数がないことを確認します。Windowsではシステムプロキシとローカル待ち受け、macOSでは現在のネットワークサービスとターミナル変数、Linuxではデスクトッププロキシ、環境変数、ポリシールート、Androidではシステム接続状態とバックグラウンド制限を確認します。v2rayNやv2rayNGを終了してもネットワークが制御されたままなら、システム層に残留設定があります。先に復元してから続行してください。

第2層：クライアントとカーネルが実際に起動しているか確認する

ウィンドウが開くことは、カーネルが動作していることを意味しません。サーバーを選択したら、状態表示とログを確認し、設定生成の成功、ローカルポートの待ち受け開始、直後の終了がないことを確認します。設定解析エラーではフィールド、プロトコル、JSONの位置が明示されることが多く、ポート競合では待ち受け失敗が表示され、権限問題はTUNインターフェースやネットワーク拡張の作成段階で発生します。まずログに出た最初の重要なエラーを処理してください。後続のエラーは最初のエラーによる連鎖であることが多いためです。

ローカルポートが待ち受けていなければ、システムプロキシをそのポートへ向けても有効な接続は生まれません。ポートを変更した場合は、システムプロキシ、ブラウザー設定、ターミナルの環境変数も更新します。複数のクライアントを同時に起動すると、後から起動したクライアントがデフォルトポートを使用できない場合があります。すべてのインスタンスを終了し、ポートが解放されたことを確認してから対象クライアントだけを起動するのが、競合を切り分ける最も直接的な方法です。

第3層：サブスクリプションの失敗とサーバーの失敗を区別する

サブスクリプションの更新成功は、設定を取得して解析できたことだけを示し、含まれるすべてのサーバーが利用可能とは限りません。逆に、更新に失敗しても、保存済みの古いサーバーが影響を受けるとは限りません。トラブル対処では、サブスクリプションURLを更新できるか、既存サーバーで接続を確立できるかという2つの結果を別々に記録します。すべての項目が同時に失敗する場合は、現在のネットワーク、サブスクリプションの一斉変更、クライアントのカーネル、DNSを優先して確認します。1項目だけ失敗する場合は、そのサーバーのパラメータまたはリモート側の状態である可能性が高くなります。

設定を手動で確認する場合は、アドレス、ポート、ユーザー識別子、プロトコル、トランスポート方式、TLSセキュリティ種別、サーバー名、パス、サービス名を重点的に確認します。プロトコルを無作為に置き換えたり、TLSを無効にしたりして運任せに試さないでください。設定がサーバー側からさらに離れてしまいます。サーバー側から新しいサブスクリプションが提供された場合は、再更新して新しい項目でテストし、古い項目に変更を積み重ねないようにします。

第4層：ログの段階から方向を判断する

「接続タイムアウト」だけでサーバーが利用できないとは判断できません。現在のネットワーク、DNSの応答、IPv6経路、ファイアウォールでも同じ結果になる可能性があります。最も有効な交差テストは、サーバーを変えずにネットワークを変更し、その後ネットワークを変えずにサーバーを変更することです。同じサーバーが別のネットワークで正常なら、問題は現在のネットワーク経路に偏っています。同じネットワークで他のサーバーが正常なら、問題はその項目またはリモート側に偏っています。テストごとに変更する変数を1つだけにすると、結論の信頼性が高まります。

第5層：接続できるのに正常に使えない場合の対処

クライアントが接続済みと表示されるのにWebページを開けない場合は、まずアプリのリクエストがログに入っているか確認します。リクエストがまったくない場合は、システムプロキシ、アプリ別プロキシ、TUNルーティングを確認します。リクエストはあるがDNSに失敗する場合はデフォルトDNSへ戻します。ドメイン解決は成功するのにリモート接続がタイムアウトする場合は、サーバーとネットワークを確認します。一部のWebサイトだけ失敗する場合は、IPv6、MTU、ルーティングルール、対象アドレスの選択を確認します。ブラウザーだけが失敗する場合は、ブラウザー内蔵プロキシ、プライベートDNS、拡張機能、キャッシュも確認します。

Webページは開くのに速度が異常な場合、ノード一覧の応答時間だけを基準にしないでください。実際の速度はサーバー負荷、回線、対象サイト、トランスポート方式、現在のネットワークに左右されます。一括速度測定、ダウンロード、帯域を使用する他のプログラムを停止し、同じ対象で比較します。Muxはすべての環境で性能を高めるわけではなく、モバイルネットワークや不安定な回線では単一接続の障害を拡大する可能性があります。継続的に停止する場合はデフォルトへ戻して再テストします。

第6層：復元、移行、役立つログの提出

複雑な設定で原因を特定できない場合は、保持したいサブスクリプションURLとカスタムルールを先に保存し、最小構成を作ります。サブスクリプション1つ、サーバー1台、デフォルトDNS、デフォルトルート、システムプロキシだけにします。最小構成が成功したら、ルーティング、TUN、DNS、FakeDNS、アプリ別プロキシの順に1項目ずつ戻します。ある段階で再発すれば、その設定に範囲を絞れます。クライアントをすぐ再インストールする必要はありません。

デバイス間で移行する際は、動作中のキャッシュ、ロックファイル、一時設定をコピーしないでください。優先して移行するのは、サブスクリプションURL、独立した手動サーバー、ルーティングルールの説明、必要なDNS設定です。プラットフォームごとに権限、パス、ネットワークインターフェースの扱いが異なるため、設定ディレクトリ全体をコピーすると無効なパスやプラットフォーム固有の状態が混入する可能性があります。移行後は各プラットフォームの章に従い、システムプロキシまたはTUNの許可を改めて完了します。

ログを他人へ提供する場合は、プラットフォーム、クライアント名、システムプロキシとTUNのどちらを使ったか、問題がインストール後か設定変更後か、直接接続が正常か、最初に現れた重要なエラーを説明します。サブスクリプションURL、完全なサーバードメイン、ユーザー識別子、パス内の個人ディレクトリ名、識別可能なネットワーク情報を削除します。「使えない」という結論だけを送らないでください。再現手順と層別の結果は、大量の完全なログより価値があります。

• インストールパッケージがプラットフォーム、プロセッサアーキテクチャ、パッケージ体系と一致している。
• サブスクリプション更新とサーバー接続の結果を別々に記録し、同じ問題として扱わない。
• システムプロキシ、TUN、アプリ内プロキシは、現在必要な入口を1つだけ残す。
• LANと内部サービスに明確な直接接続ルールがある。
• ログからサブスクリプション、ユーザー識別子、サーバーの機密情報を隠している。