v2rayN全プラットフォームのインストール・設定完全ガイド - Windows、macOS、Android、Linux

1. 読み進め方と設定の全体像

クライアント、コア、サブスクリプションの役割

使える設定を構築するには、クライアントの画面、プロキシコア、サブスクリプションの3層を区別する必要があります。v2rayN、v2rayNG、v2flyNGは、ノードの表示、設定の保存、システム機能の呼び出しを担うGUIクライアントです。XrayやV2Flyはプロトコル、ルーティング、接続を処理するコアにあたります。サブスクリプションはサービス提供元が用意する設定一式で、通常はサーバーアドレス、ポート、ユーザー識別子、通信方式、TLSパラメーター、名前などを含みます。クライアントにサブスクリプションを追加しても、すぐに全アプリの通信を引き受けるわけではありません。まずノードをコアに渡し、システムプロキシまたはTUNによって、どのアプリの通信をローカルプロキシの入口へ送るかが決まります。

そのため、「クライアント画面では起動中」と「ブラウザーがプロキシを使っている」は別の話です。コアが正常に動作していることは、ローカルの待ち受けポートが作られたことを示すだけです。ブラウザーがそのポートを経由するかどうかは、システムプロキシの設定、ブラウザー独自のプロキシ設定、ルーティングルール、DNSリクエストの処理方法によって決まります。トラブルシューティングではデータの流れに沿って、サブスクリプションを解析できるか、選択したノードに接続できるか、ローカル入口が待ち受けているか、アプリがリクエストを入口へ渡しているか、ルーティングが正しい出力先を選んでいるか、DNSが利用可能な結果を返しているかを順に確認します。これらを混同して再インストールを繰り返しても、根本原因の特定にはつながりません。

4つのプラットフォームで推奨されるクライアント

プラットフォーム	クライアント	主な通信の取り込み方法	インストール時の確認事項
Windows	v2rayN	システムプロキシ、TUN	権限、ファイアウォール、システムプロキシの状態
macOS	v2rayN	システムプロキシ、TUN	チップアーキテクチャ、アプリ権限、ネットワーク許可
Linux	v2rayN	デスクトッププロキシ、環境変数、TUN	ディストリビューションのパッケージ形式、デスクトップ環境、権限昇格
Android	v2rayNG、v2flyNG	システムVPNインターフェース	バックグラウンド制限、省電力設定、アプリごとの振り分け

デスクトップでは、似た画面構成でサブスクリプション、ルーティング、ログを管理できるため、v2rayNを優先します。Androidではv2rayNGを第一候補とし、V2Flyコアを使う場合はv2flyNGを選べます。Android向け2クライアントの基本操作は似ていますが、設定データベースやコアの機能が完全に互換性を持つとは限りません。クライアントを変更するときは、別のクライアントの内部データフォルダーをコピーせず、元のサブスクリプションを再度追加してください。

設定を完成させる標準手順

プラットフォームとアーキテクチャを確認。まずデバイスのOS、プロセッサーアーキテクチャ、ディストリビューションのパッケージ形式を確認し、ダウンロードセンターで対応するインストールファイルを選びます。
クライアントをインストール。初回起動時にシステム権限、ファイアウォール、ネットワークインターフェースの許可を処理し、画面が正常に開くことを確認します。
サブスクリプションを追加・更新。サブスクリプショングループを作成し、完全なURLを入力して一度手動更新し、ノード一覧が表示されるか確認します。
ノードとモードを選択。まず基本的なシステムプロキシで動作を確認し、対象アプリの範囲に応じてTUNを有効にするか決めます。
リクエスト経路を確認。クライアントのログ、ブラウザーのアクセス、システムプロキシの状態を確認し、単一の遅延結果だけで実際の接続を判断しないでください。
最後にルーティングを調整。基本接続が確立してから、直接接続、プロキシ、ブロックのルールを追加し、変更する条件は毎回1種類に限定します。

システムプロキシは、ブラウザーやシステムのネットワーク設定に従うデスクトップアプリに適しており、設定が簡単で影響範囲も明確です。TUNは仮想ネットワークインターフェースを通じてより広い通信を取り込むため、システムプロキシを参照しないアプリ、UDPのみを使うアプリ、独自のネットワークスタックを構築するプログラムに向いています。一方で、管理者権限、ルーティングテーブル、DNSの取り込み、他のネットワークツールとの競合といった要素が増えます。最初からすべての機能を有効にするのではなく、最小構成で始め、基本経路を確認してから対象範囲を広げるのが適切です。そのため本ページの各プラットフォーム章も「インストール、サブスクリプション、システムプロキシ、TUN、プラットフォーム固有の問題」の順で構成しています。

2. インストール前の準備：プラットフォーム、アーキテクチャ、サブスクリプション、権限

システムとプロセッサーアーキテクチャを確認

ダウンロード前に、OSのバージョン、プロセッサーアーキテクチャ、インストールパッケージの種類を確認してください。Windowsの一般的なデスクトップではx64を使用します。macOSではApple SiliconとIntelを区別する必要があります。Linuxではx64、arm64に加えて、ディストリビューションがdebとrpmのどちらを採用しているかも確認します。Androidの近年の主流デバイスは通常arm64です。アーキテクチャが不明な場合やインストールに失敗した場合のみ、汎用パッケージを検討してください。アーキテクチャの選択を誤ると、インストーラーが起動しない、パッケージが非対応と表示される、インストール後すぐ終了するといった症状が出ます。これはサブスクリプション、ノード、ネットワーク状態とは無関係であり、プロキシ設定の変更で解決する問題ではありません。

Windowsでは「設定 → システム → システム情報」でシステムの種類を確認できます。macOSでは「このMacについて」を開き、チップ欄にAppleシリーズの名称が表示される場合はApple Silicon、Intelプロセッサーと表示される場合はIntelを選びます。Linuxではターミナルでuname -mを実行します。x86_64はx64、aarch64またはarm64はarm64に対応します。Androidのアーキテクチャは通常、追加ツールで調べる必要はありません。まずarm64パッケージをインストールし、システムに明確に拒否された場合のみ汎用パッケージを使用してください。出所の不明な判定サイトにデバイス情報をアップロードしないでください。

uname -m

# Debian、Ubuntuおよび派生ディストリビューションでパッケージアーキテクチャを確認
dpkg --print-architecture

# Fedora、Rocky Linuxなどのディストリビューションでマシンアーキテクチャを確認
rpm --eval '%{_arch}'

有効なサブスクリプションと基本情報を準備

サブスクリプションURLは、クライアントが設定一式を取得する入口であり、完全な状態を保つ必要があります。コピー時には、末尾パラメーターの欠落、改行の混入、実際のURLではなくウェブページ上の表示テキストのコピー、サービス側でのサブスクリプション停止などがよく起こります。サブスクリプション名、更新URL、用途を記録しておくと便利ですが、アカウント識別用のトークンが含まれる可能性があるため、スクリーンショット、ログ、公開質問に完全なURLを載せないでください。クライアント内では提供元ごとに別のグループを作り、複数のサブスクリプションを同じグループに上書きして、ノードの出所が分からなくなる事態を避けます。

サービス提供元が複数のサブスクリプション形式を用意している場合は、V2Ray、Xray、または対応クライアント向けと明記された形式を優先してください。通常のウェブページURL、管理画面のログインURL、サブスクリプションURLは別物です。追加成功の判断基準も「エラーが表示されない」ことではなく、サブスクリプショングループに識別可能な設定項目が現れ、手動更新時のログに取得と解析の完了が記録されることです。リストが空の場合は、まずサブスクリプションの応答と形式を確認し、すぐにTUN、DNS、ルーティングモードを切り替えないでください。

権限、時刻、ネットワーク環境

クライアントの通常のプロキシ機能は一般ユーザー権限で使えることが多い一方、TUNでは仮想ネットワークインターフェースの作成、ルーティングテーブルへの書き込み、DNSの変更が必要になるため、管理者の許可を求められることがあります。許可はシステム本来のダイアログで行ってください。組織のポリシーで管理されているデバイスでは、権限が制限される場合があります。その場合はクライアントの起動を繰り返すのではなく、デバイス管理ルールを確認します。Windowsでは初回のコア起動時にファイアウォールがネットワークアクセス範囲を尋ねることがあります。macOSではネットワーク設定の許可が必要になる場合があります。Linuxではpolkitやターミナルからの権限昇格が使われることがあります。Androidでは初回接続時にシステムVPNの許可ダイアログが表示されます。許可を拒否しても画面上のボタンは操作できる場合がありますが、通信の取り込みは完全には構築されません。

デバイスの時刻はTLSハンドシェイクや有効期限付き認証にも影響します。システムの自動時刻合わせを有効にし、タイムゾーンが正しいことを確認してください。日付、時刻、タイムゾーンが間違っていると、証明書がまだ有効でない、期限切れ、認証の時間枠が一致しないといった問題が起こります。もう一つの準備として、初回設定ではネットワーク要因を一時的に減らします。他のプロキシ、ネットワークフィルター、同種の仮想ネットワークアダプターを停止し、現在のクライアントだけを残してください。まずは安定した家庭内ネットワークやモバイルネットワークで確認します。公共ネットワークで先に認証ページを開く必要がある場合は、プロキシを有効にする前に認証を完了してください。そうしないと接続がすべてログインページへリダイレクトされることがあります。

復元しやすい設定習慣を作る

インストール前に、出所の不明な設定一式を移行する必要はありません。サブスクリプションの提供元、ルーティングルールの意図、必要最小限の設定だけを保存し、新しいクライアントで再構築する方が安全です。旧版クライアントを更新する場合は、まず動作中のコアを終了し、現在のインストール方法に従って上書きまたは並行インストールします。同じローカルポートで待ち受ける2つのインスタンスを同時に起動しないでください。後から起動したプロセスがアドレス使用中のエラーを出します。ポータブル版のフォルダーも、頻繁な書き込み許可が必要な場所には置かないでください。ログ、データベース、更新ファイルには安定した書き込み権限が必要です。

準備ができたらダウンロードセンターでプラットフォームに合うクライアントを選びます。ダウンロードページには、Windowsデスクトップ版とクラシックWPF版、macOS向けの2種類のチップアーキテクチャ、Linux向けのdeb・rpmパッケージ、Android向けv2rayNG・v2flyNGのインストール入口があります。インストールファイルはプラットフォームとアーキテクチャだけで決まり、サブスクリプションのプロトコルでは決まりません。VMess、VLESS、Trojanなどのプロトコルは追加後のコア設定に属するため、プロトコルごとに別のクライアントをインストールする必要はありません。

3. Windows：v2rayNのインストール、サブスクリプション、システムプロキシ

デスクトップ版とクラシックWPF版を選ぶ

Windowsではv2rayNを第一候補にします。ダウンロードセンターにはデスクトップ版とクラシックWPF版があります。デスクトップ版は新世代のクロスプラットフォームUIを採用し、macOSやLinuxと近い操作感を求めるユーザーに適しています。WPF版は従来のWindows画面構成を踏襲しており、旧版のメニュー位置や操作に慣れているユーザー向けです。どちらもサブスクリプションの管理、コアの起動、システムプロキシの設定に使えますが、画面レイアウトは異なる場合があります。2つのバージョンを同時に起動しないでください。ローカルの待ち受けポート、システムプロキシの状態、設定フォルダーを競合させる可能性があります。

インストールまたは解凍するフォルダーには、一般ユーザーが書き込める権限を設定し、パスはできるだけ固定してください。インストーラーを使う場合はシステムのウィザードに従えば完了します。単体実行型パッケージの場合は、まず完全に解凍してから起動し、圧縮ファイルのプレビュー画面から直接実行しないでください。初回起動時にファイアウォールの確認が表示されたら、信頼できる現在のネットワーク範囲でアクセスを許可します。これにより、ローカルアプリがクライアントの待ち受けポートへ接続できます。通常、クライアント自体がLANへサービスを公開する必要はないため、明確な目的がない限り「LANからの接続を許可」は有効にしないでください。

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

サブスクリプショングループの管理画面を開き、識別しやすい名前のグループを作成して、完全なサブスクリプションURLを貼り付けて保存します。保存は提供元の情報を登録するだけなので、その後に「現在のサブスクリプションを更新」または「すべてのサブスクリプションを更新」を実行してください。更新後はサーバー一覧に戻り、名前、アドレス種別、通信情報が表示されていることを確認します。ノード数は利用可能性の証明ではありません。設定項目を1つ選んで使用サーバーに指定し、実際の接続テストを行います。更新後も一覧が空なら、ログのHTTPステータス、解析エラー、形式に関するメッセージを先に確認し、同じグループを繰り返し作成しないでください。

遅延テストは初期選別の目安にすぎません。通常の探測に応答しなくても実際のプロキシ接続は確立できるサーバーがあります。逆に探測値が正常でも、実際のハンドシェイクに失敗することがあります。より確実なのは、ノードを選択して実接続の遅延テストを行い、その後システムプロキシを有効にして、キャッシュされていないページを開く方法です。テスト中は、接続成功、ハンドシェイク失敗、タイムアウト、認証拒否がログに出ていないか確認します。ノード選びを詳しく知りたい場合は、v2rayN初回接続ガイドをご覧ください。

システムプロキシモードの適用範囲

システムプロキシを有効にすると、v2rayNはWindowsのプロキシ設定をローカルの待ち受けアドレスへ向けます。システム設定に従うブラウザーやデスクトップアプリは、HTTP・HTTPSリクエストをクライアントへ渡し、ルーティングルールによって直接接続かプロキシかが決まります。初回確認では「システムプロキシを自動設定」または画面上の同等の標準モードを使い、デフォルトのローカルポートを維持して、急いで手動変更しないことをおすすめします。ノード切り替え時に通常システムプロキシを無効にする必要はありません。新しい設定が以後の接続を引き継ぎます。ただし、確立済みの長時間接続は古い経路を使い続けることがあるため、必要に応じてアプリを開き直してください。

コマンドラインプログラムがWindowsのGUI上のシステムプロキシを読み取るとは限りません。PowerShell、パッケージマネージャー、開発ツールはそれぞれ異なるプロキシ規則を持ち、環境変数を読むもの、個別の引数が必要なもの、WinHTTPを使うものがあります。「ブラウザーは使えるのにターミナルは使えない」場合は、ノードが突然無効になったのではなく、アプリごとのプロキシ方式の違いと考えてください。まずWinHTTPの現在の状態を確認できますが、その結果をブラウザーのプロキシ設定と同一視しないでください。

netsh winhttp show proxy

# 現在のセッションでプロキシ環境変数が設定されているか確認
Get-ChildItem Env: | Where-Object Name -Match 'proxy'

現在のターミナルセッションだけでローカルのSOCKSまたはHTTP入口を使いたい場合は、使用するツールのドキュメントに従って一時的な引数を設定し、セッション終了後に戻してください。影響範囲が分からないままプロキシ環境変数をシステム全体の設定に書き込まないでください。クライアントが起動していないと、プログラムが存在しないローカルポートへ接続し続けるためです。ブラウザーとターミナルを分けた詳しい確認手順は、システムプロキシが効かない場合の対処法をご覧ください。

TUN、権限、Windows固有の問題

TUNモードは、システムプロキシを参照しないアプリ、UDPが必要なアプリ、より多くのアプリをまとめて取り込みたい場合に適しています。有効にする前に、同種のクライアントを終了し、システムの許可を与えて仮想インターフェースを作成します。その後、v2rayNのログでインターフェースの初期化、ルーティングの書き込み、DNSの待ち受けが完了したか確認してください。有効にした直後にインターネットへ接続できなくなった場合は、まずTUNを無効にしてシステムプロキシへ戻し、基本接続が成立していることを確認します。そのうえで、他の仮想ネットワークアダプター、企業向けネットワークソフト、ゲーム向け通信最適化ツール、安全対策ソフトがルーティングテーブルを同時に変更していないか調べます。デフォルトルートを担当するツールは1つだけにしてください。

Windowsのスリープ、ネットワーク切り替え、クライアントの異常終了後には、システムプロキシが有効なまま残ることがあります。典型的には、v2rayNを閉じた後もブラウザーがローカルの待ち受けポートへアクセスしようとします。クライアントを再起動し、システムプロキシを正常に無効化すれば通常は復旧できます。Windowsのプロキシ設定で手動プロキシが無効になっているか確認しても構いません。原因が分からないうちにすべてのネットワークアダプターを削除したり、ネットワーク設定全体をリセットしたりしないでください。無線ネットワーク、仮想化環境、組織の設定にも影響します。ログにポート使用中と表示された場合は、重複インスタンスを終了してからシステムツールで待ち受けプロセスを確認します。

netstat -ano | findstr LISTENING

# DNSキャッシュの状態を確認し、調査前の状態を記録
ipconfig /displaydns

4. macOS：チップアーキテクチャ、ネットワーク権限、プロキシ

チップに合ったv2rayNインストールパッケージを選ぶ

macOSでv2rayNを使う場合、最初に正しいアーキテクチャを選びます。Apple Siliconデバイスにはarm64パッケージ、Intelデバイスにはx64パッケージを使用します。システムの「このMacについて」に表示されるチップまたはプロセッサー情報を判断材料にしてください。アーキテクチャが合わないとアプリが開かない、または互換変換レイヤーに依存して動作することがあります。これをサブスクリプションの問題と誤認しないでください。インストール時はアプリを通常のアプリケーションフォルダーへ移し、ダウンロードフォルダーやディスクイメージから長期間直接起動しないでください。設定の保存、更新、権限記録には安定したパスが必要です。

初回起動時に、アプリの出所やネットワーク権限の確認を求められることがあります。システム設定のプライバシーとセキュリティ画面で、現在のアプリに関する通知を処理してください。アプリを何度もコピーして複数のインスタンスを作らないでください。クライアント画面は開くのにコアが起動しない場合は、アプリのログで実行権限不足、実行ファイルの非実行状態、アーキテクチャエラーがないか確認します。コアが起動してローカルで待ち受けを開始して初めて、システムプロキシとTUNの入口が利用可能になります。

サブスクリプション管理とノード検証

v2rayNで独立したサブスクリプショングループを作成し、完全なURLを入力して手動更新します。macOSでもサブスクリプションの操作手順はWindowsと同じです。提供元を保存し、更新を実行し、一覧を確認し、使用ノードを選び、実接続を検証します。クリップボードに前後の空白や改行が含まれている場合は、URLをコピーし直してください。サブスクリプションの応答がタイムアウトする原因は、現在のネットワーク、DNS、サービス側の状態などです。解析に失敗する場合は、形式の不一致である可能性が高くなります。2種類のエラーでは対処の方向が異なるため、実行ログの最初に出た明確なエラーが、画面に最後に表示されるメッセージより重要です。

接続確認では、いきなりTUNを有効にせず、まずシステムプロキシを使います。システムプロキシは現在のネットワークサービスのプロキシ設定を変更し、Safariやシステムのネットワーク設定に従う多くのアプリがこの入口を使用します。有効化後はターミナルでシステムプロキシの状態を確認し、HTTP、HTTPS、SOCKSの項目がローカルアドレスを指しているか確認できます。

scutil --proxy

# システムの現在のデフォルトルートを確認
route -n get default

scutil --proxyはシステム設定が書き込まれたことを示すだけで、ノード接続の成功を保証するものではありません。続けて実際のウェブページを開き、クライアントのログを確認してください。システムプロキシが有効なのにアプリのリクエストがログに現れない場合は、そのアプリが独自プロキシを使っていないか、バイパスルールが有効でないか、プロキシ有効化前の接続を再利用していないかを確認します。アプリを終了して再起動すると、接続の再利用による影響を切り分けられます。

システムプロキシと異なるネットワークサービス

macOSは、無線、有線、その他のネットワークサービスごとに設定を保存します。ネットワークを切り替えると、プロキシ状態を再適用する必要が生じることがあります。v2rayNではシステムプロキシが有効なのに、新しく接続したネットワークが直接接続になる場合は、いったんシステムプロキシを無効にしてから再度有効にし、現在アクティブなサービスへ設定を書き込ませます。公共ネットワークに認証ページがある場合は、まずプロキシを無効にして認証を完了し、その後再び有効にしてください。認証へのリダイレクトがプロキシへ送られると、すべてのページが開けないように見えることがあります。

ターミナルツールとGUIアプリの間にもプロキシ方式の違いがあります。一部のコマンドはHTTP_PROXY、HTTPS_PROXY、ALL_PROXY環境変数を読み取り、一部のツールはGUIのシステムプロキシを無視します。変数は現在のターミナルセッションだけに設定する方が復元しやすく、ターミナルを閉じれば他の作業へ影響し続けません。v2rayNのローカル入口が常に同じで、クライアント未起動時の解除方法も分かっている場合を除き、固定ポートをグローバルなシェル設定へ書き込まないでください。

TUNとネットワーク拡張機能の競合

macOSでTUNを有効にすると、ネットワーク関連の許可を求められることがあります。許可後は、仮想インターフェースの作成とルーティングの書き込みが成功したかログで確認してください。接続ボタンを有効にした直後にネットワーク全体が切断された場合、別のネットワークツールが動作中、複数のフィルター拡張が存在する、複数のプログラムがDNSを変更している、スリープ復帰後に古いインターフェースが解放されていない、といった原因が考えられます。まず他の取り込みツールを終了してv2rayNを再起動し、システム再起動が必要か判断してください。正体の分からないシステムネットワークサービスを直接削除しないでください。

TUNは通常、システムプロキシより広い範囲を取り込むため、LAN上のデバイス検出、印刷サービス、開発環境にも影響しやすくなります。有効化後にインターネットは使えるのにLANアドレスへ接続できない場合は、geoip:privateなどのプライベートアドレス向けルール、または同等のLANルールが一般的なプロキシルールより前にあるか確認します。ルールの順番を誤ると、LANリクエストが遠隔の出力先へ送られ、デバイスが応答できなくなります。ローカルサービスへアクセスするユーザーは、TUN有効化前にLANの直接接続を残すことを必ず確認してください。

アプリが終了できない、またはシステムプロキシが元に戻らない場合は、まずv2rayN内でシステムプロキシを無効にしてから正常終了します。アプリがすでに異常終了した場合は、システムのネットワーク設定で現在のサービスのプロキシ項目を確認してください。復旧後にクライアントを再起動し、デフォルト設定で接続を一度確認します。同じ問題が繰り返される場合に限り、ログを使って権限、インターフェース、アプリのライフサイクルのどこに原因があるか判断します。

5. Linux：パッケージ、デスクトッププロキシ、環境変数、TUN

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

Linuxでv2rayNを使うには、アーキテクチャとパッケージ体系の両方を確認する必要があります。Debian、Ubuntuおよび派生ディストリビューションは通常deb、Fedora、Rocky Linuxなどは通常rpmを使用します。x64デバイスにはx64パッケージ、arm64デバイスにはarm64パッケージを選びます。パッケージ形式を誤るとパッケージマネージャーに拒否され、アーキテクチャを誤ると実行できない、依存関係を満たせないといった問題が起こります。インストール前にuname -mでアーキテクチャを確認し、ディストリビューション標準のパッケージマネージャーでインストールすると、デスクトップメニュー、依存関係、アンインストール情報を揃えやすくなります。

# debパッケージのインストール例。ファイル名は実際のダウンロード結果に合わせる
sudo apt install ./v2rayN-linux-x64.deb

# rpmパッケージのインストール例。ファイル名は実際のダウンロード結果に合わせる
sudo dnf install ./v2rayN-linux-x64.rpm

上記のコマンドはローカルパッケージのインストール方法を示すものです。ファイル名はダウンロードセンターから実際に取得したものに置き換えてください。パッケージマネージャーで依存関係の問題が表示された場合は、まず現在のディストリビューションのソフトウェアソースを更新し、システムの依存関係を解決します。不明な場所から共有ライブラリを組み合わせないでください。GUIアプリの起動後は、設定フォルダーに現在のユーザーが書き込める必要があります。デスクトップクライアント全体をroot権限で常用しないでください。TUNの作成やルーティング変更が必要な場合だけ、必要なネットワーク操作に対してシステムの許可で権限を昇格します。

サブスクリプション追加とデスクトップ環境の違い

サブスクリプションの流れは他のデスクトッププラットフォームと同じです。グループを作成し、URLを貼り付け、保存、手動更新、使用ノードの選択を行います。アプリがクリップボードを読み取れない場合は、通常のテキストエディターでURLが完全か確認してから貼り付けてください。WaylandとX11ではクリップボード、トレイ、ウィンドウの動作が異なることがありますが、サブスクリプションの形式は変わりません。トレイアイコンが表示されなくても、コアが動作していないとは限りません。クライアントのメインウィンドウとプロセスログを基準にしてください。一部のデスクトップ環境では、従来型トレイ項目の表示に拡張機能が必要です。

サブスクリプション更新後は、まずサーバー一覧に内容が表示されていることを確認してからコアを起動します。ログにローカルポート使用中と表示された場合は、ssで待ち受け状態を確認できます。ポートが存在するからといって、すぐにシステムプロセスを終了しないでください。別のv2rayNインスタンス、残存しているコア、他のプロキシプログラムが同じポートを使用していないか先に確認します。

ss -lntp

# 現在のユーザーセッションに設定されたプロキシ変数を確認
env | grep -i proxy

# デフォルトルートを確認
ip route show default

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

Linuxには、すべてのデスクトップアプリとコマンドラインプログラムをカバーする統一プロキシ設定がありません。GNOMEやKDEなどのデスクトップ環境はGUIプロキシを保存できますが、ブラウザーがそれを読み取るかはブラウザーの設定にも左右されます。ターミナルプログラムは環境変数や独自設定でプロキシを決めることが多くあります。v2rayNがシステムプロキシを書き込んだ後は、まず現在のデスクトップのブラウザーで確認し、その後にターミナルツールを個別に調べてください。ターミナルが直接接続になるからといってシステムプロキシ全体が無効とは限りません。ブラウザーが使えるからといって、すべてのバックグラウンドサービスが自動的にプロキシを使うとも限りません。

特定のターミナルセッションでローカルHTTP入口を使う場合は、環境変数を一時的に設定できます。SOCKSを使う場合は、対象ツールが対応する変数と名前解決方式をサポートしているか確認してください。一時設定では、v2rayNの画面に表示される実際の待ち受けアドレスとポートを使います。以下ではループバックアドレスと一般的なローカルポートで構文を示します。

export HTTP_PROXY=http://127.0.0.1:10809
export HTTPS_PROXY=http://127.0.0.1:10809

# 現在のセッション終了後に解除
unset HTTP_PROXY
unset HTTPS_PROXY

クライアントのポートが異なる場合は、画面のパラメーター設定を優先してください。変数名の大文字・小文字への対応はプログラムによって異なるため、グローバル変数を設定する前に対象ツールを確認する必要があります。システムサービスは通常、ユーザーのターミナル環境を継承しません。デスクトップセッションの変数も、すべてのコンテナへ自動的に渡るわけではありません。開発ツールを調査するときは、ホストシステム、コンテナ、リモートセッション、統合ターミナルを別々に確認し、複数のネットワーク名前空間を同じ環境として扱わないでください。

TUN、権限、DNS

LinuxのTUNは、システムの仮想ネットワークインターフェース、ルーティング、権限に依存します。有効化前にTUNデバイスがシステムで利用できることを確認し、デフォルトルートを変更する他のプログラムを終了してください。v2rayNが権限昇格を求めた場合は、現在必要なネットワーク操作だけを許可します。有効化後はip addrとip routeでインターフェースとルートの変化を確認できます。デフォルトルートが誤って置き換えられた場合は、まずクライアント内でTUNを無効にしてから再確認します。リモート管理中のデバイスでは、誤ったルーティングが現在のリモート接続を切断する可能性があるため、特に慎重に操作してください。

DNSはsystemd-resolved、NetworkManager、デスクトップ環境、手動設定ファイルなどが共同で管理している場合があります。TUNを有効にした後、ウェブのドメイン名だけ解決できず既知のアドレスには応答がある場合は、DNSリクエストがクライアントへ入っているか、システムが現在どのリゾルバーを参照しているか、他のネットワークツールが設定を上書きしていないかを優先して確認します。問題を隠すためにシステムの名前解決ファイルを長期的に直接書き換えないでください。次回の接続時にネットワークマネージャーが再生成する可能性があります。システム、クライアント、ローカル名前解決サービスのどれがDNSを担当するかを明確にし、複数のコンポーネントが同じ待ち受けポートを奪い合わないようにするのが正しい方法です。

Linuxでは、層ごとに確認する方法が最も安定しています。まずv2rayNのGUIとコアが動作することを確認し、次にブラウザーのシステムプロキシ、続いてターミナルの環境変数を検証し、最後にTUNを有効にします。各層で明確な結果を残せば、問題がデスクトップ設定、アプリ設定、権限、ルーティング、DNSのどこにあるか分かります。ログにtimeout、rejected、解析エラーが繰り返し出る場合は、実行ログの読み方ガイドと照らし合わせて具体的な段階を特定してください。

6. Android：v2rayNG、v2flyNG、アプリごとの振り分け

クライアントとインストールパッケージを選ぶ

Androidではv2rayNGを第一候補とします。Xrayコアの系統を使用し、一般的なサブスクリプションやルーティング設定に適しています。V2Flyコアが必要な場合は、v2flyNGを代替として利用できます。どちらもシステムVPNインターフェースで通信を取り込みますが、コアの対応範囲、設定名、設定の保存方法が完全に一致するとは限りません。クライアントを切り替える場合は、元のサブスクリプションを再度追加し、別アプリのデータフォルダーをコピーしないでください。近年の主流デバイスではarm64パッケージを優先し、アーキテクチャが不明な場合やarm64のインストールをシステムに拒否された場合のみ、汎用パッケージを使います。

インストール後、初回接続時にシステムのVPN許可画面が表示されます。許可すると、ステータスバーにシステムが管理する接続アイコンが表示されます。この表示は仮想インターフェースが作成されたことを示すだけで、遠隔ノードが利用可能とは限りません。実際の確認には、クライアントログと実際のウェブリクエストを組み合わせます。デバイスにシステムVPNインターフェースを使用中の別ツールがある場合、新しいクライアントの接続時に既存の接続が終了することがあります。2つのアプリが同じシステムインターフェースを同時に制御することはできません。

サブスクリプションの追加、更新、ノード選択

v2rayNGまたはv2flyNGでサブスクリプショングループの設定を開き、完全なサブスクリプションURLを追加して名前を付け、保存後に更新を実行します。システムによってはバックグラウンドのネットワークアクセスが制限されます。更新が止まったまま、またはすぐ失敗する場合は、まずアプリを前面に表示し、現在のネットワークからサブスクリプションの提供元へアクセスできることを確認してください。更新に成功したら設定一覧が表示されるため、1つを使用設定に指定して実接続をテストします。QRコードは単一設定の追加に向き、サブスクリプションは継続的な更新に向いています。用途が異なるため、単一ノードのQRコードを自動更新可能なサブスクリプショングループとして扱わないでください。

ノード一覧に表示される遅延は、判断を補助する情報にすぎません。モバイルネットワークは基地局の切り替え、電波の弱さ、省電力状態によって大きく変動するため、1回の結果で継続的な品質は判断できません。ノードを選択して接続を開始し、新しいブラウザーページを開いてから、すぐにログへ戻り実際のリクエストが発生したか確認します。ログにインターフェース起動の情報しかなく出力接続の記録がない場合、アプリの通信がクライアントに入っていない可能性があります。timeout、TLS、認証エラーが出ている場合は通信がクライアントに入っており、問題は遠隔接続または設定パラメーターにあります。

システムVPNインターフェースとアプリごとの振り分け

Androidクライアントでは通常、アプリごとにプロキシを経由するか決められます。よくある方式は、選択したアプリだけを対象にする方法と、大半のアプリを対象にして一部を除外する方法です。ルールが複雑になるほど、新しくインストールしたアプリを設定し忘れやすくなります。初回設定ではアプリごとの振り分けを無効にし、全体の取り込みが機能することを確認してから、必要に応じて許可リストや除外リストを作成してください。「ブラウザーは使えるのに特定のアプリは使えない」場合は、まずそのアプリが除外されていないか確認し、サーバーパラメーターを変更しないでください。

アプリによってはIPアドレスを直接使ったり、特定のUDP通信を使ったり、従来のHTTPプロキシに従わなかったりします。そのためAndroidクライアントは、デスクトップのシステムプロキシよりシステムVPNインターフェースで広く通信を取り込めます。一方で、LAN、画面投影、印刷、デバイス検出にも影響することがあります。同じネットワーク上のデバイスへアクセスする場合は、LANバイパスを有効にするか、プライベートアドレスを直接接続するルールを作成してください。アプリごとの振り分けとルーティングルールが同時にある場合、まずシステムがクライアントへ入れるかを決め、入った後にコアが出力先をルーティングします。システム側で除外されたアプリは、コアのルールには一致しません。

バックグラウンド制限、バッテリー、ネットワーク切り替え

Androidの省電力機能は、クライアントのバックグラウンド動作を制限することがあります。典型的には、画面ロック後しばらくすると接続が切れ、画面を点灯すると戻る、またはシステムがバックグラウンドアプリを終了して接続アイコンが消えるといった症状です。システムのアプリ設定で必要なバックグラウンド動作を許可し、積極的な自動クリーンアップ機能は避けてください。設定項目の名称はデバイスによって異なりますが、画面消灯後もクライアントがシステムVPNサービスを維持できることが判断基準です。ネットワークと無関係な権限を与える必要はありません。

無線ネットワークからモバイルネットワークへ切り替えると、既存の接続が無効になり、コアが出力接続を再確立する必要があります。切り替え後も長時間復旧しない場合は、クライアントをいったん停止して再起動してください。サブスクリプションを削除する必要はありません。公共無線ネットワークでウェブ認証が必要な場合は、まずクライアント接続を切り、認証完了後に再接続します。無線では使えるのにモバイルネットワークで失敗する場合は、モバイルネットワークのDNS、IPv6、通信事業者ごとの接続経路を確認します。すべてのノードが特定のネットワークだけで失敗するなら、各サブスクリプションが同時に無効になったのではなく、ネットワーク経路の問題である可能性が高いです。

「常時接続」などのシステムオプションを有効にする前に、クライアントが安定して動作することと、システムのブロック方針を理解していることを確認してください。「未接続時にネットワークをブロック」も同時に有効にすると、クライアントの異常終了や更新中に他のアプリも通信できなくなります。この設定は長期間検証済みの構成向けで、初回インストール時の標準手順ではありません。通信が切断された場合は、システムVPN画面でこの種の制限が有効になっていないか確認し、システムによる遮断をノード障害と誤認しないようにしてください。

v2rayNGとv2flyNGではログ入口の位置が異なる場合がありますが、トラブルシューティングの考え方は同じです。連続再試行後に大量に出る重複情報ではなく、最初の失敗の前後に注目してください。ログを共有するときは、サブスクリプションURL、ユーザー識別子、サーバーアドレスなどの機密情報を削除し、エラーの種類、発生段階、システム環境だけを残します。クライアントでは接続済みなのにウェブへアクセスできない場合は、プロキシ接続済みなのにネットが使えない場合の確認リストをご覧ください。

7. ルーティング、DNS、TUN：デフォルトルールから管理しやすい振り分けまで

ルーティングルールの適用順

ルーティングは、クライアントに入ったリクエストをどの出力先へ送るかを決めます。一般的な出力先には、直接接続、プロキシ、ブロックがあります。ルールは通常上から順に評価され、一致すると後続のルールには進みません。そのため、具体的なルールを一般的なルールより前に置きます。例えばLANと明確な直接接続ドメインを先に処理し、最後にフォールバックルールで残りの通信をプロキシへ渡します。「すべてプロキシ」を最初に置くと、その後のLAN直接接続は永遠に適用されません。範囲の広すぎる直接接続ルールを前に置くと、本来プロキシへ送るべきリクエストも先に処理されます。

ドメインルールとIPルールは、異なる段階の問題を解決します。最初にドメインしかない場合は、geositeや明示的なドメインに一致させられます。名前解決後にIPが得られると、geoip、プライベートアドレス、ネットワークセグメントに一致させられます。1つの接続がドメインと宛先IPの両方を持つことはありますが、クライアントが取得できる情報は入口プロトコル、DNSの流れ、アプリの動作によって異なります。特にIPへ直接接続するアプリはドメインルールを通らないため、単一のルールだけですべてを処理しようとしないでください。より完全な構成では、ドメイン集合、IP集合、最終フォールバックを併用します。

推奨される基本ルーティング構成

基本設定は3層から始められます。LANとプライベートアドレスは直接接続、ローカルネットワークに属することが明確なサイトとアドレス集合も直接接続、それ以外はプロキシです。ブロックルールを追加するかどうかは実際の要件に応じて個別に管理し、影響を確認せず広範囲のドメインリストへ直接追加しないでください。以下のJSON断片はXray形式のルーティング構造における主要な関係を示しています。実際にはGUIクライアントのルーティング設定画面から同等のルールを作成できます。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

domainStrategyは、ドメインルールに一致しなかった場合にIPをさらに名前解決するかどうかを制御します。IPIfNonMatchは、まずドメインの一致を試み、該当しなければ名前解決してIPルールを試す設定です。積極的にすればよいとは限りません。追加の名前解決はDNSの関与を増やし、逆にまったく解決しないとドメインリクエストにIPルールを適用できないことがあります。GUIクライアントでは「ドメイン戦略」などのプルダウンで表示される場合があります。変更前に解決したい問題を明確にし、設定がより包括的に見えるという理由だけで切り替えないでください。

DNSリクエストが接続に影響する理由

DNSはドメイン名をアドレスへ変換します。この処理はシステムが行うこともあれば、クライアントが転送、取り込み、ルールに従って振り分けることもあります。よくある異常には、システムが到達できないアドレスを取得する、クライアントとシステムで異なる結果になる、TUN有効化後にDNSリクエストが想定した待ち受けへ入らない、IPv4とIPv6の返却順が現在のネットワークに合わない、といったものがあります。症状としては、ドメインが開けない、アドレスを直接使うと応答がある、特定のサイトだけ使えて他はタイムアウトするなどが現れます。このときノードを何度も変更しても一時的に症状を回避できるだけで、名前解決の経路自体は直りません。

DNSを調べるときは、まず3つの質問に答えます。アプリは誰に問い合わせを渡しているか、名前解決リクエストはどの出力先から送られるか、最終的にどの種類のアドレスが返ったかです。システムプロキシモードでは、ブラウザーが独自のセキュアDNSを使う場合も、システムへ渡す場合もあります。TUNモードでは、クライアントがより多くの問い合わせを取り込めることが一般的です。ブラウザーに独自DNS設定があると、システムやクライアントが想定する経路を迂回することがあります。まずブラウザーのデフォルトネットワーク設定で確認し、必要になってからカスタムDNSを追加してください。複数の名前解決方式を同時に有効にすると、ログと結果の対応が難しくなります。

システムプロキシとTUNの選び方

比較項目	システムプロキシ	TUN
対象範囲	主にシステム設定に従うアプリ	より広いTCP・UDP通信を取り込める
必要な権限	通常は低い	仮想インターフェースとルーティング権限が必要
トラブルシューティングの難易度	入口が明確で、アプリごとに判断しやすい	ルーティング、DNS、インターフェースの競合が関係する
適した用途	ブラウザー、一般的なデスクトップソフト	プロキシ設定を参照しない、またはUDPが必要なプログラム

まずシステムプロキシで基本接続を確認し、その後TUNが必要か判断してください。対象アプリがすでにシステムプロキシで動作しているなら、TUNを有効にしてもノードの品質が自動的に向上するわけではなく、通信の取り込み方法が変わるだけです。システムプロキシを参照しないアプリ、UDPが必要なアプリ、通信をまとめて管理したい場合に限ってTUNを有効にし、LANの直接接続を残します。有効化前に現在のシステムプロキシ、DNS、他の仮想ネットワークアダプターの状態を記録しておくと、異常時に復元できます。

ルール変更の検証方法

ルールは毎回1グループだけ変更し、明確な対象で検証します。例えばLANの直接接続を追加したら、LANデバイスとインターネットをそれぞれ1回ずつテストします。geositeルールを変更したら、ログの対象ドメインと最終出力先を確認します。DNSを調整したら、新しいドメインとキャッシュ済みドメインを別々に試します。大量のルールを一度に読み込み、DNSを切り替え、TUNを有効にしてノードまで変更すると、成功しても失敗しても原因となった変更を特定できません。

ルーティングルールの名前は、「LAN直接接続」「よく使うローカルドメインの直接接続」「その他はプロキシ」のように意図を表すものにし、分かりにくい仮番号は避けてください。長期的に管理する場合は、まずルールの目的を書き、その後に一致条件と出力先を記録します。サブスクリプション更新は通常サーバー設定だけを更新し、ユーザー定義のルーティングを上書きするものではありません。ただし、クライアントによって追加方法が異なるため、更新後に挙動が変わった場合は、使用中のルーティング設定が正しいか確認してください。

8. よくある設定問題と層別トラブルシューティング

まずデータ経路から問題の層を特定

効果的なトラブルシューティングは「クライアントを再インストールする」ことから始まりません。リクエストがどの層で止まっているかを判断します。第1層はサブスクリプション取得で、更新、解析、ノード生成ができるかを確認します。第2層はコア起動で、設定を読み込めるか、ローカルポートで待ち受けられるかを確認します。第3層は遠隔接続で、ノードがDNS、TCP、TLS、プロトコルのハンドシェイクを完了できるかを確認します。第4層はアプリの取り込みで、システムプロキシ、環境変数、システムVPNインターフェースによって通信がクライアントへ入るかを確認します。第5層はルーティングとDNSで、入ってきたリクエストが正しい出力先を選び、ドメインが到達可能なアドレスへ解決されるかを確認します。各層には独立した証拠があるため、最初に失敗した地点を探してください。

ログを読むときは、1回の操作に対応する時間帯に注目します。まずログを消去するか現在位置を記録し、サブスクリプション更新、接続、ウェブアクセスのいずれかを1回実行してから、新しく追加された内容を読みます。その後に何度も再試行するとtimeoutが大量に重複し、最初の解析、権限、認証エラーが隠れてしまいます。よくあるキーワードでは、timeoutは規定時間内に処理が完了しなかったことを示し、ネットワークに到達できない、サービスが応答しない、DNSが遅いなどの原因が考えられます。rejectedはルール、遠隔側、プロトコル条件によって接続が拒否されたことを示します。invalid userは通常、ユーザー識別子、認証情報、サービス側の設定不一致に関係します。詳しい判断は実行ログの読み方で確認してください。

サブスクリプションの更新失敗、または更新後にノードがない

まずサブスクリプションURLが完全で、省略記号を含む表示テキストをコピーしていないことを確認します。URLの前後の空白と改行を削除し、元のパラメーターを残してください。次にクライアントで該当グループを手動更新し、ログを確認します。ログがネットワークタイムアウトを示す場合は、現在のネットワークとDNSを確認します。応答内容を解析できない場合は、選択したサブスクリプション形式がクライアントに対応しているか確認します。応答が空、または権限拒否の場合は、提供元側で状態を確認する必要があります。同じサブスクリプションを繰り返し追加しないでください。失敗したコピーが増えるだけです。

更新成功と表示されても一覧が空の場合は、現在の画面でグループ、検索語、設定種別によるフィルターが有効になっていないか確認し、ノードがどのグループへ追加されたかも確認します。別のクライアントから移行する場合、内部データベースを直接コピーせず、元のサブスクリプションを再追加する方が確実です。更新後も古いノードが残る場合は、クライアントが旧設定を保持する設定になっている可能性があります。まず新しい内容が生成されたか確認してから削除を判断し、提供元情報のバックアップがない状態で全グループを一度に削除しないでください。

クライアントは起動するのにシステムプロキシが効かない

まずクライアントのログを開き、ブラウザーから新しいリクエストを送ります。ログにまったく記録されない場合は、アプリからローカル入口までの間に問題があります。システムプロキシが書き込まれていない、ブラウザーが独自設定を使っている、アプリが接続を再確立していない、現在のネットワークサービスにプロキシが適用されていない、といった原因です。ログにリクエストはあるものの遠隔接続に失敗する場合は、システムプロキシは機能しているため、ノード、DNS、ルーティングを調べます。この方法なら、プロキシの取り込み問題とサーバー問題を混同せずに済みます。

WindowsとmacOSではシステムのネットワーク設定でプロキシ状態を確認できます。Linuxではデスクトッププロキシとターミナルの環境変数を別々に確認します。AndroidではシステムVPNの許可とアプリごとの振り分けを確認してください。ターミナルツールがブラウザーと同じように動作しないのは一般的な仕組みの違いであり、そのツールが対応するプロキシ引数を調べる必要があります。クライアント終了後に通信できなくなった場合は、システムプロキシや「未接続時にネットワークをブロック」が残っていないか確認します。デスクトップの詳しい確認手順は、ブラウザーとコマンドラインを分けて確認する方法をご覧ください。

接続済みと表示されるのにウェブページが開かない

「接続済み」は通常、コアまたは仮想インターフェースが起動したことだけを示します。まず実接続で確認済みのノードへ切り替え、デバイスの時刻とタイムゾーンが正しいことを確認します。次にウェブリクエストがログへ入っているかを確認し、その後DNSエラー、ルーティングの出力先、システムプロキシやTUNと他のネットワークツールの競合を調べます。同じデバイス、同じネットワークで全ノードが失敗し、別のネットワークでは使える場合は、現在のネットワーク経路を優先して調査します。1つのノードだけが失敗するなら、その設定または遠隔側の状態である可能性が高くなります。

Pingの結果だけで最終判断しないでください。サーバーが通常の探測に応答しなくても、プロキシプロトコルは接続できる場合があります。逆にアドレスが探測へ応答しても、認証やTLSハンドシェイクの成功を意味しません。実接続テストと実際のウェブリクエストの方が、利用時の経路に近い確認になります。詳しい確認項目はv2rayN・v2rayNGの段階別トラブルシューティングリストをご覧ください。ノード、時刻、DNS、ルーティング、システムプロキシの順に整理しています。

TUN有効化後に通信できない、またはLANへ接続できない

まずクライアント内でTUNを無効にし、基本ネットワークが復旧するか確認します。復旧しない場合は、システムプロキシ、システムVPNのブロック設定、残存する仮想インターフェースを確認します。基本ネットワークが戻ったら、現在のクライアントだけを残し、ルーティングやDNSを変更する他のプログラムを終了して、TUNを再度有効にし最初のエラーを確認します。権限不足は通常、インターフェース作成段階で失敗します。ポート競合は待ち受け段階で発生します。デフォルトルートやDNSの誤りは、インターフェース作成後にリクエストがタイムアウトする症状として現れることが多いです。

インターネットは使えるのにLANへ接続できない場合は、プライベートアドレスの直接接続ルールが存在し、フォールバックプロキシより前に置かれているか確認します。一般的なプライベートアドレスやローカルリンクを遠隔の出力先へ送らないでください。Androidではアプリ設定のLANバイパスも確認します。デスクトップでは、ファイアウォールが新しい仮想インターフェースを不適切なネットワーク範囲に分類していないか確認します。変更後はLANアドレスと通常のドメインをそれぞれテストし、片方だけで判断しないでください。

ポート競合、重複インスタンス、設定の切り戻し

ログにアドレスが使用中と表示される場合、通常は別のクライアントインスタンス、残存コアプロセス、他のプロキシプログラムが同じポートを使用しています。まずタスクマネージャー、アクティビティモニタ、プロセス一覧で所有元を確認し、該当プログラムを正常終了してください。ポートを変更すれば現在のインスタンスは起動できるかもしれませんが、システムプロキシ、環境変数、アプリ内の固定設定も合わせて変更する必要があり、新たな不整合を生みやすくなります。まず重複インスタンスを解消し、必要な場合だけポートを変更します。

設定を変更した直後に問題が発生した場合、すべての設定を戻すのではなく、直近の変更を1つだけ切り戻すのが最も効果的です。TUN、カスタムDNS、追加ルーティング、アプリごとの振り分けを逆の順番で無効にし、サブスクリプションと単一ノードは残します。基本接続が復旧したら、設定を1つずつ戻してください。クライアント設定の判断が難しい場合は、サブスクリプションの提供元を記録し、新しい最小構成を作って比較します。新構成が使えるなら旧設定の競合、新構成も失敗するならプラットフォーム権限、ネットワーク、サブスクリプション内容を引き続き調べます。

最終確認リスト

インストールパッケージが、現在のプラットフォーム、プロセッサーアーキテクチャ、ディストリビューションの形式に一致している。
サブスクリプショングループを手動更新でき、ノード一覧が空ではなく、フィルター条件で非表示にもなっていない。
使用ノードの実接続に成功し、システム時刻とタイムゾーンが正しい。
コアが正常に起動し、ローカルの待ち受けポートを重複インスタンスが使用していない。
ブラウザーまたは対象アプリのリクエストがクライアントログに表示される。
ルーティングルールが具体的なものから一般的なものへ並び、LANとプライベートアドレスが直接接続になっている。
DNSを担当する経路が明確に1つで、複数のツールが同時に設定を上書きしていない。
TUNは基本的なシステムプロキシの確認後にのみ有効にし、異常時に無効化して復旧できる。

以上を確認しても原因を特定できない場合は、問題を1つのプラットフォーム、1つのクライアント、1つのサブスクリプショングループ、1つのノード、1種類の通信取り込み方式に絞り、再現手順を詳しく記録してください。「どの段階で失敗したか」を先に示し、続けて「ログに何が出たか」を説明する方が、「接続できない」とだけ書くより有効な判断につながります。最短手順をもう一度試す場合はクイックスタートガイドへ、インストールパッケージの変更やプラットフォーム別の入口を確認する場合はダウンロードセンターへ進んでください。