V2Ray導入・設定ガイド

事前準備：設定の各層を把握する

クライアント、カーネル、接続パラメーター

V2Rayの設定は3つの層に分けて考えられます。クライアントはGUI、サブスクリプション管理、システム連携を担当します。カーネルは設定の読み込み、接続の確立、ルーティングを処理します。サーバー側のパラメーターは、接続先のアドレス、ポート、認証、通信方式を指定します。クライアントをインストールしただけでは、ローカルの管理ツールが準備できたにすぎず、接続先が自動的に利用可能になるわけではありません。開始前に、正規に入手したサブスクリプション URL または個別の共有リンクを用意し、有効期限内であることも確認してください。

v2rayN はデスクトップ向け、v2rayNG は Android で広く使われている Xray カーネル搭載クライアント、v2flyNG は V2Fly カーネルを選べるクライアントです。Project V、V2Fly、Xrayは関連する技術エコシステムですが、すべての設定を相互に使えるとは限りません。プロトコルや通信機能が使えるかどうかは、クライアントの設定生成機能、実際に動作するカーネル、サーバー側の要件によって異なります。スイッチを何度も切り替えるより、要件に合った組み合わせを選びましょう。

デバイス情報と現在のネットワーク設定を記録する

ダウンロード前に、OSの種類とCPUアーキテクチャを確認してください。デスクトップでは x64 と arm64 を区別し、macOSでは Apple Silicon と Intel のどちらかを確認します。Linuxではアーキテクチャに加えて、ディストリビューションが deb と rpm のどちらを使うかも確認してください。見た目だけで判断したり、互換レイヤーを標準の導入方法と考えたりしないでください。ダウンロードページで各プラットフォームの要件を確認しましょう。画面や機能の違いがわからない場合は、クライアント比較を参照してください。

続いて、ほかのプロキシツール、企業 VPN、カスタム DNS、ネットワークフィルターが動作しているかを記録します。初回テストでは、通信を制御するプログラムをできるだけ1つに絞り、システムプロキシや仮想ネットワークインターフェースの競合を避けてください。設定を取り込む前に、通常のネットワークでよく使うサイトにアクセスできることを確認します。基本のネットワークが切断されていれば、サブスクリプション更新もリモート接続も失敗します。その状態でプロトコルの設定だけを変更しても、原因が増えるだけです。

サブスクリプション URL と共有リンクは別の入力

https:// で始まる URL はサブスクリプションの取得先の場合も、通常のWebページの場合もあります。提供元の説明に従って判断してください。vmess://、vless:// などで始まるものは、通常、個別の共有リンクです。クリップボードまたは該当するインポート機能から読み込みます。共有リンクをサブスクリプション URL 欄に入れたり、説明ページをサブスクリプション URL として使ったりしないでください。QRコードは情報を伝える方法の1つにすぎません。読み取ったあと、実際に何が含まれているかを確認してください。

システムの日付、タイムゾーン、自動時刻合わせを確認してください。時刻が大きくずれていると、TLS証明書の検証や時刻に依存する認証に失敗することがあります。続いて、ログで見つけやすい設定名を付けておきましょう。サブスクリプション URL には個人を識別する情報やアクセストークンが含まれる場合があります。スクリーンショットの共有や問い合わせの前に、URL全体を隠してください。見知らぬ解析サイトに貼り付けたり、認証情報を含むQRコードを公開したりしないでください。

初回接続の基本テスト手順

設定のインポート、使用するサーバーの選択、プロキシ入口の有効化、対象アプリでの確認を順に行いましょう。デスクトップでは、まずシステムプロキシを試します。Androidでは、最初にシステム VPN の許可を得て接続してください。対象アプリがシステムプロキシを参照しないと確認できた場合に限り、TUNを検討します。各手順の結果を確認してから次に進み、ルーティング、DNS、カーネルを同時に変更しないでください。テスト終了時にはシステムプロキシが元に戻っているかも確認し、設定の残りをネットワーク障害と誤認しないようにしましょう。

Windows：v2rayN のインストール

画面と実行環境に合わせてインストーラーを選ぶ

Windows のダウンロードページを開き、まず記載されているシステム要件を確認します。v2rayN のデスクトップ版には、クロスプラットフォームのUIを採用した版と、Windowsデスクトップ向けの従来型 WPF 版があります。どちらも別の接続サービスではなく、接続のために両方をインストールする必要はありません。初めて使う場合は、ダウンロードページの推奨版から選ぶとよいでしょう。すでに使い慣れた版がある場合は、UI、システム要件、実行に必要なコンポーネントを踏まえて選んでください。詳しくはデスクトップ版と WPF 版の解説をご覧ください。

このページからダウンロードできる Windows 版は x64 パッケージです。まずシステムの「バージョン情報」でデバイスのアーキテクチャを確認してください。インストーラーはウィザードに沿って実行します。圧縮ファイルの場合は完全に展開してから起動し、圧縮ソフトのプレビュー画面から直接実行しないでください。書き込み可能な場所に置くとログや設定を保存しやすくなりますが、使用中のプログラムフォルダーを安易に移動しないでください。起動時に実行コンポーネントが不足していると表示された場合は、指定されたアーキテクチャの依存コンポーネントを追加します。出所の不明なランタイム一括パッケージを何度もダウンロードするのは避けてください。

サブスクリプションを追加して使用中のサーバーを確認する

v2rayN を開き、「サブスクリプショングループ設定」でグループを追加します。識別しやすい名前を付け、サブスクリプション URL 全体を「アドレス(URL)」欄に貼り付けてください。グループを有効にして保存したら、サブスクリプションを更新します。まだ接続を確立していない初回は、「プロキシを使用しない」更新方法を試せます。提供元から特定のネットワーク経路を指定されている場合は、その案内に従ってください。更新後は、通知ウィンドウが閉じたかどうかだけでなく、実際に設定が追加されたかを確認しましょう。

インポート済みの設定から使用するサーバーを選び、現在の接続先に指定します。サブスクリプショングループの有効化、サーバーの選択、システムプロキシの有効化は、それぞれ別の操作です。どれか1つでも欠けると、「インポートしたのに使えない」状態になることがあります。リストが空の場合は、まずサブスクリプション管理で応答内容と形式を確認してください。推測でポート、ID、TLSのパラメーターを入力すると、元の完全な設定を上書きするおそれがあります。

まずシステムプロキシを試し、TUNが必要か判断する

「システムプロキシ」で「システムプロキシを自動設定」を選び、テストするアプリを一度終了してから再起動します。システムプロキシは、その設定に対応したアプリへローカルのプロキシ入口を提供する機能であり、すべてのプロセスに強制適用するものではありません。ブラウザーは使えても特定のアプリで失敗する場合は、まずアプリ独自のプロキシ設定を確認してください。1つのアプリが追従しないからといって、すぐにサーバーが使えないと判断しないでください。「システムプロキシを解除」は、サブスクリプションを消去する操作ではありません。

システムプロキシを参照しないアプリの通信も制御する必要がある場合に、「Tun モードを有効にする」を試してください。この機能は通常、仮想ネットワークインターフェース、ルーティング、高い権限を必要とします。現在のクライアントの案内に従って許可してください。有効にしたら、まずログで起動成功を確認してから対象アプリをテストします。スイッチがオンでも、通信経路が確立したとは限りません。失敗した場合はTUNを停止して基本状態に戻し、権限、コンポーネント、ほかの VPN との競合を確認してください。あらゆる問題に対して、権限を上げたまま使い続けるのは避けましょう。

Windowsでよくある注意点

ポートが使用中と表示されたら、まず重複して起動しているクライアントを終了し、ほかのプロキシプログラムがないか確認します。ポートを何度も変更し、アプリ側の設定を更新し忘れないようにしてください。ファイアウォールの確認画面では、実際の用途に合わせて許可します。通常、パブリックネットワークで受信接続を許可する必要はありません。「LANからの接続を許可」は、共有が必要な場合だけ有効にしてください。詳しいインストール時の注意点はWindows設定でよくある落とし穴をご覧ください。変更のたびに同じアプリで再テストし、条件をそろえて判断しましょう。

macOS：チップ、権限、プロキシ

チップを確認してからアプリをインストール

「このMacについて」を開き、Appleチップと Intel プロセッサのどちらかを確認してから、macOS のダウンロードページで対応する v2rayN デスクトップ版を選んでください。Apple Silicon は arm64、Intel は x64 に対応します。OSの名前や購入年だけでアーキテクチャを判断しないでください。互換機能で起動できるパッケージでも、最適な選択とは限りません。ハードウェアに合ったインストーラーを使うと、その後の権限やコンポーネントの確認も簡単になります。

ダウンロードしたディスクイメージを開き、ウィンドウの案内に従ってアプリを「アプリケーション」フォルダーに移動し、そこから起動します。マウントしたイメージから起動し続けると、アップデート、パスの記録、権限の許可が複雑になるため避けてください。システムによって起動がブロックされた場合は、想定したダウンロード元から入手したファイルか確認してから、「プライバシーとセキュリティ」に表示された内容を確認します。入手元を確認できたアプリだけ、システムが提示する許可操作を実行してください。利便性のためにシステム全体のセキュリティチェックを無効にするのはおすすめしません。

サブスクリプションを設定し、ウィンドウを閉じる操作とアプリ終了を区別する

サブスクリプショングループ設定を開き、名前と URL を追加して保存し、更新します。URLをWebページのボタンからコピーした場合は、先頭や末尾に空白や改行が入っていないか確認してください。ボタンの文言まで一緒にコピーしないよう注意しましょう。更新できたら現在のサーバーを選び、プロキシをテストします。ウィンドウを閉じても、アプリがメニューバーで動作し続ける場合があります。完全に終了する前に、システムプロキシを元に戻す必要があるか確認してください。デスクトップにウィンドウが見当たらないだけで、クライアントが停止したと判断しないようにしましょう。

macOSのネットワーク設定はネットワークサービスごとに保存されます。Wi-Fi、有線接続、その他のインターフェースでプロキシの状態が異なる場合があります。自宅では接続できたのに別の接続方式で使えないときは、サブスクリプションをすべて再インポートするのではなく、現在有効なネットワークサービスを確認してください。システムプロキシの自動設定を有効にしたあとは、システムのネットワーク設定で実際に反映された値を確認できます。プロキシ設定を個別に持つアプリでは、以前のアドレスを使い続けていないか、システム設定に従う状態かも確認しましょう。

システムプロキシとTUNの権限範囲

初回はシステムプロキシだけを有効にしてください。ブラウザーで正常にアクセスできることを確認してから、TUNが必要か判断します。TUNにはシステムの許可、補助コンポーネント、権限の引き上げが必要な場合があります。具体的な方法は現在のクライアントに従ってください。機能を選べない場合は、そのビルドの説明を確認します。ほかのプラットフォーム向けのサービス導入手順をそのまま流用しないでください。権限の確認画面が直前に行った操作と対応しているか確認し、出所のわからない権限要求は許可しないでください。

TUNを有効にしたあとは、ドメイン名の解決、LAN機器へのアクセス、スリープからの復帰後に接続が回復するかを確認してください。復帰後に一部のアプリだけ失敗する場合は、まずクライアントの接続を切断して再接続し、ネットワークサービスが切り替わっていないか確認します。システムのネットワーク設定をすべて削除するのは避けてください。会社の VPN やネットワーク拡張機能がある場合は、それぞれを単独で有効にしてテストします。2つのツールがルーティングを変更する環境では、画面上は接続済みでも通信経路が正しくないことがあります。

アップデート、移行、接続の復旧

アップデート前に動作中のアプリを終了し、必要な設定をバックアップしてからアプリのファイルを置き換えてください。バックアップ先はクライアントが案内する設定フォルダーを使い、固定の保存先を推測しないでください。別のMacへ移行する場合、元のデバイスで許可したシステム権限はファイルと一緒に移行されないことがあります。新しいデバイスでも改めて確認が必要です。クライアント終了後にネットワークで問題が起きたら、現在のネットワークサービスにローカルホスト宛てのプロキシ設定が残っていないか確認します。元の値に戻してから機能を1つずつ有効にし、以前の状態を次のテストに持ち込まないようにしましょう。

Linux：パッケージとデスクトップ環境

パッケージ形式とCPUアーキテクチャの両方を合わせる

Linuxへのインストールでは、ディストリビューションのパッケージ形式とデバイスのCPUアーキテクチャの2点を確認します。Linux のダウンロードページにある deb と rpm は、異なるディストリビューション向けのパッケージ形式です。x64 と arm64 はCPUアーキテクチャを表します。ファイルをダウンロードできるからといって、そのままインストールできるとは限りません。システムの「バージョン情報」でアーキテクチャとディストリビューションを確認してください。わからない場合は、ディストリビューションのパッケージ管理の説明を先に確認し、異なる形式を手当たり次第に試さないでください。

デスクトップのソフトウェアインストーラーで、対応するパッケージを開きます。依存関係と権限の案内を確認してからインストールしてください。依存関係が不足している場合は、ディストリビューション標準のソフトウェアリポジトリから導入します。パッケージマネージャーのロックファイルを手動で削除したり、出所不明のサイトから共有ライブラリを集めたりしないでください。インストールできたのにメニューに表示されない場合は、デスクトップセッションに再ログインしてから、アプリの一覧を確認します。このガイドではGUIクライアントを扱い、デスクトップアプリをバックグラウンドのシステムサービスに変更することは求めていません。

サブスクリプションを追加してローカルのプロキシ入口を確認

v2rayN を起動し、サブスクリプショングループ設定で名前とサブスクリプション URL を入力して保存し、更新します。使用するサーバーを選んだら、デスクトップのプロキシ設定に進む前に、クライアントがカーネルを正常に起動できるか確認してください。Linuxのデスクトップ環境やアプリのフレームワークはさまざまです。「システムプロキシを自動設定」が有効かどうかは、対象アプリが実際に設定を参照するかで判断します。デスクトップの設定画面にプロキシアドレスが表示されても、起動中のすべてのプロセスにすぐ反映されるとは限りません。

アプリのプロキシを手動設定する場合は、クライアントの画面で現在の待ち受けアドレス、ポート、入口の種類を確認してから入力してください。HTTP の入口を SOCKS として設定したり、別のPCのポートをこのPCの標準値として使ったりしないでください。このPC内だけで使う場合は、待ち受けアドレスをループバックの範囲に保つのが適切です。アプリで接続拒否と表示された場合は、リモート認証を疑う前に、カーネルが動作中か、待ち受けポートが変わっていないかを確認しましょう。

デスクトッププロキシ、環境変数、TUNを混同しない

GUIアプリの中にはデスクトップ環境のプロキシ設定を参照するものがあり、独自の設定を使うものもあります。コマンドラインアプリでは環境変数を参照するものもあります。これらは別々の入口であり、自動的に同期されません。そのため、ブラウザーが使えてもターミナルのプログラムが失敗するからといって、ルーティングの問題とは限りません。まず対象プログラムが使うプロキシ方式を確認し、正しい入口を設定してください。「システムプロキシが有効」というだけで、すべての通信を説明しようとしないでください。

TUNは通常、仮想ネットワークデバイスへのアクセスやルーティングの変更を必要とするため、一般ユーザーの権限では不足する場合があります。クライアントに権限エラーが表示された場合は、そのビルドが案内する連携方法に従ってください。デスクトップ環境全体を高い権限で常時実行するのは避けましょう。サンドボックス形式のインストールや制限付きセッションが、ネットワークデバイスへのアクセスに影響することもあります。起動に失敗したら、ログに記録された最初の明確なエラーを残し、権限、システムコンポーネント、既存の VPN を確認します。スイッチを何度押しても不足している条件は補えません。

デスクトップ連携とネットワークの復旧

トレイアイコンが見えない場合は、まずデスクトップ環境が該当するトレイ拡張機能に対応しているか確認してください。アイコンがないだけでカーネルが停止したとは限りません。ネットワークを切り替えたあとにDNSが使えなくなった場合は、現在のネットワーク管理コンポーネントが以前の設定を上書きしていないか確認し、クライアントが対応する方法で復旧します。複数の名前解決設定ファイルを同時に手動変更しないでください。ファイルによってはシステムが動的に生成しており、次回接続時に書き換えられて、原因がわかりにくい障害につながることがあります。

アプリをアップデートする前に設定を保存し、クライアントを終了してから、同じパッケージ管理方法で更新します。異なる入手元のパッケージが互いを上書きするのを避けるためです。アンインストールする前に、クライアントが設定したシステムプロキシを解除してTUNを停止してください。アプリのファイルを削除しても、デスクトップ環境に保存されたプロキシ設定が解除されるとは限りません。再起動後もネットに接続できない場合は、まず元のネットワーク設定を復元してから再インストールとテストを行います。複雑なルールを追加し続けるより、動作する基本設定を1つ残しておくほうが、多くの場合は解決が早くなります。

Android：設定のインポートと VPN の許可

クライアントとインストーラーのアーキテクチャを選ぶ

Android のダウンロードページを開き、まず Xray カーネルを使う v2rayNG を検討してください。V2Fly カーネルが必要な場合は v2flyNG を選びます。2つのクライアントは画面や機能の対応範囲が異なるため、名前が似ていても、すべてのパラメーターをそのまま移行できるとは限りません。比較的新しいスマートフォンの多くは arm64 ですが、実際のシステムアーキテクチャを確認してください。確認できない場合は、ダウンロードページにある汎用パッケージの説明を参照します。画面サイズからアーキテクチャを判断しないでください。

インストーラーを開くと、現在使用中のブラウザーやファイル管理アプリに対して、不明なアプリのインストールを許可するよう求められることがあります。許可する対象はインストールを開始したアプリであり、システム全体ではありません。インストール後、必要に応じて権限を取り消せます。インストールに失敗したら、まずパッケージのアーキテクチャ、空き容量、同じ名前のアプリの入手元を確認してください。アップデート時に競合が発生しても、すぐにアンインストールしないでください。サブスクリプションやローカル設定が消える場合があります。先にクライアントが対応する方法で必要なデータをバックアップしましょう。

サブスクリプション、クリップボード、QRコードからインポート

サブスクリプションを追加するには、サブスクリプショングループまたはサブスクリプション設定を開き、名前と URL を入力して保存し、更新します。画面によっては、更新操作がメニュー内にある場合があります。基本の流れは「サブスクリプションの登録先を保存してから、設定を取得する」です。個別の共有リンクしかない場合は、「クリップボードからインポート」などの機能を使ってください。QRコードを受け取った場合は、読み取り後にインポート項目の種類を確認します。認証情報がそのまま含まれている可能性があるため、QRコードのスクリーンショットを公開解析サイトにアップロードしないでください。

インポート後にサーバーを1つ選び、接続ボタンをタップします。初回接続時、Android からシステム VPN の許可を求められたら、操作したクライアントからの要求であることを確認してください。許可後、クライアントはシステムの仮想ネットワークインターフェースを通じて通信を制御できるようになります。ここでいう VPN はシステムインターフェースの種類であり、特定のリモートプロトコルを選択したことを意味しません。実際の接続は、現在の設定に含まれるプロトコル、通信方式、認証パラメーターで決まります。

モバイル端末で通信を制御する方法を理解する

モバイル端末では、デスクトップの「システムプロキシを自動設定」と同じ方法を使う必要はありません。一般的な接続モードは Android VPN サービスを通じて動作します。アプリごとの対象範囲、DNSの処理、LANへの接続を除外する方法は、現在のクライアントの設定によって異なります。初回テストでは標準の対象範囲を使い、基本接続が使えることを確認してからアプリごとのルールを有効にしてください。対象範囲に含まれていないだけなのに、サーバーの障害と誤認しやすくなります。

アプリごとにプロキシを設定した場合、現在のモードが「選択したアプリのみ」なのか「選択したアプリを除外」なのかを確認してください。2つの意味は逆です。変更するたびに接続を確立し直し、対象アプリを開いてテストします。通常、アクティブにできる一般的な VPN サービスは1つだけです。ほかの VPN、広告ブロック、パケットキャプチャのツールが入口を占有することがあります。テスト時はこれらを停止し、別のクライアントが「常時接続」に設定されていないか確認してください。接続直後に別のアプリに切り替えられるのを防げます。

バックグラウンド制限、ネットワーク切り替え、接続の復旧

画面が点灯している間は正常でも、ロック後に切断される場合は、バッテリー最適化、バックグラウンド実行、メーカー独自の自動起動管理を確認してください。設定項目の名前は端末によって異なります。接続を維持する必要があるクライアントだけ制限を緩和し、省電力機能をすべて無効にしないでください。クライアントの常駐通知がバックグラウンドサービスに関係する場合もあります。通知を隠すために必要なサービスを停止しないでください。ログに記録されたプロセスの終了と、リモートとのハンドシェイク失敗は別の問題なので、分けて対処します。

Wi-Fi とモバイルネットワークを切り替えると、接続の再確立が必要になることがあります。DNSやネットワークへのアクセス条件が変わる場合もあります。まず切断して再接続し、現在のネットワークで基本的なアクセスができることを確かめてから、サブスクリプションやサーバーの問題か判断してください。テザリングでクライアントが制御する通信を中継できるかは、システムや端末の実装によります。スマートフォンで使えるからといって、テザリング先でも使えるとは限りません。終了前に「常時接続 VPN」や「VPN未接続時の接続をブロック」などのシステム設定を確認し、クライアントの停止後にすべてのアプリがネットに接続できなくなる事態を避けてください。

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

入力内容を見分けてからインポート方法を選ぶ

サブスクリプション URL は、クライアントが一連の設定を取得し、以後も更新するためのものです。共有リンクは通常、1つの接続を表します。どちらもコピーやQRコードで共有されることがありますが、同じ入力欄を使うわけではありません。受け取ったらまず内容の種類を確認し、サブスクリプション設定または共有リンクのインポートを選びます。仕組みや具体的な操作は共有リンクとサブスクリプション URL の違いをご覧ください。入力内容を見分けるだけで、多くの解析エラーを防げます。

サブスクリプショングループの名前には、区別しにくい連番ではなく、入手元や用途がわかる名前を付けましょう。提供元から受け取った URL は、長く見える部分も勝手に削除せず、パスやクエリパラメーターを含めてそのまま使います。公開の場に貼り付けないでください。チャットアプリからコピーした場合は、日本語の句読点、目に見えない改行、URLの途中での切り詰めがないか確認します。例の https://example.com/your-sub は入力欄の形式を示すだけで、設定を取得できるサービスのアドレスではありません。

サブスクリプションの更新失敗を、取得と解析に分けて確認する

サブスクリプションの更新は、「URLへのリクエスト」と「応答内容の読み込み」の2段階です。タイムアウト、ドメイン名の解決失敗、TLSエラーは前者にあたります。内容は取得できたのに設定が生成されない場合は、応答形式とカーネルの対応状況を確認してください。ステータスコードが成功でも、ログインページ、有効期限切れの案内、その他のテキストが返されていることがあります。完了と表示されたかどうかだけで判断しないでください。クライアントのログに応答の種類や解析理由があれば、まずそれを確認します。関係のないルーティング設定を何度も切り替えないでください。

更新時に直接接続するか、現在のプロキシを経由するかは、URLに到達できる経路に応じて選びます。インストール直後は通常、使えるプロキシがまだないため、プロキシを経由しない更新を試せます。すでに確立した接続を経由しないとアクセスできないURLの場合は、反対の設定が必要です。どちらでも失敗する場合は、ネットワークとURLの有効性を確認してください。短時間に何度も更新したり、テストのためにサブスクリプション URL 全体を第三者へ送ったりしないでください。詳しい確認手順はサブスクリプション更新失敗・解析結果が空の場合の対処をご覧ください。

更新による上書きとローカルの編集を分ける

サブスクリプションに含まれる設定は、次回更新時に再生成されることがあります。サーバーアドレス、名前、高度なパラメーターを直接編集しても、その変更が保持されるとは限りません。比較テストを行う場合は、設定をローカルの項目として複製し、変更の目的を記録してください。テスト用の設定をサブスクリプション由来の項目として扱わないようにしましょう。更新後は現在の接続先が残っているかも確認します。提供元が設定を削除、改名、変更していると、以前の選択先が新しい項目に自動で引き継がれない場合があります。

自動更新は、正常に取得できることを確認したサブスクリプションに適しています。初回はまず手動で更新を確認してください。クライアントが更新間隔を設定できる場合は、実際の必要性に合わせて指定します。接続の問題を頻繁な更新で解決しようとする必要はありません。更新で取得できるのは、提供元が現在返している設定だけです。ローカルのポート競合を直したり、誤ったシステムプロキシを自動解除したりはしません。更新完了後も、接続先、プロキシ入口、対象アプリを確認してください。「サブスクリプション更新済み」は接続成功の証明ではありません。

バックアップの内容とプライバシーに関する注意

バックアップ前に、エクスポート機能に何が含まれるか確認してください。接続設定だけを保存するものもあれば、サブスクリプション URL や環境設定も含むものがあります。通常、システム権限は一緒に移行できません。バックアップファイルは信頼できるローカルの場所に保存し、他人に共有する前に URL、ユーザー識別情報、認証項目を削除してください。端末を変えたら、まず設定を1つだけインポートして動作確認してから、ルーティングやその他のカスタム設定を戻します。サブスクリプションが漏えいしたおそれがある場合は、提供元に連絡して URL または認証情報を変更してください。ローカルのグループを削除するだけでは、漏えいした URL は無効になりません。

プロキシとルーティング：入口と出口は別

システムプロキシ、TUN、ルーティングの役割

システムプロキシは、対応アプリにリクエストをローカルの待ち受けポートへ渡すよう通知します。TUNは仮想ネットワークインターフェースを介して、対象範囲の通信を受け取ります。ルーティングルールは、そのリクエストの送信先を決定します。これらは異なる階層の機能であり、互いに置き換えられません。TUNを有効にしても、すべてのリクエストがリモートに送られるとは限りません。グローバルルーティングを選んでも、クライアントにまったく届いていないアプリをプロキシ経由にすることはできません。トラブルを調べるときは、まず「リクエストがクライアントに入っているか」、次に「入ったあとどこへ送られたか」を確認しましょう。

初期設定では、クライアントが提供するルーティングのプリセットを使いましょう。たとえば「中国大陸を回避（Whitelist）」は、ローカルのルールデータと実際の設定に基づいて照合します。すべてのドメインの地理的位置を正確に判定できるという意味ではありません。ルールファイル、DNSの結果、カーネルの動作が最終的な経路に影響します。まず標準のプリセットを確認し、明確な要件がある場合に限りルールを少しずつ追加してください。異なる配布元のルールをまとめて追加すると、優先順位による上書きやタグの不一致が起こりやすくなります。

ルールは順に照合され、出力タグは事前に定義されている必要がある

ルーティングは通常、ルールを上から順に照合します。先頭の広い条件に、後ろで処理する予定の通信が先に一致する場合があります。ルールを追加する前に、ドメイン、宛先アドレス、ポート、アプリのどれで振り分けるのかを決めてください。以下は、指定したドメインを direct という名前のアウトバウンドに送る Xray/V2Ray形式のルーティング例です。完全な設定ではないため、既存のルーティング構造に組み込み、該当するアウトバウンドとルールデータがすでにあることを確認してください。

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

geosite:cn は、ローカルの geosite データにあるドメインの集合を参照します。対応するデータがなければ動作しません。outboundTag は既存のアウトバウンドを参照する項目であり、英単語を書くだけで機能が作られるわけではありません。クライアントが生成するタグは例と異なる場合があるため、実際の設定を確認してください。GUIのルーティングエディターを使う場合は、別のツールから出力した形式を混在させず、エディター内で既存のアウトバウンドを選択してください。

DNSとルールの照合をあわせて確認する

ドメイン名で照合する場合とIPアドレスで照合する場合では、前提が異なります。クライアントが接続先のIPアドレスしか取得していなければ、ドメインルールが適用されないことがあります。ドメイン名を先に解決してからアドレス集合と照合する場合は、DNSの結果が判定に影響します。DNSサーバーを何度も切り替えて、ルールの確認を代替しないでください。リクエストがクライアントに入ったときにどの情報が含まれているかを確認してから、ドメインの処理方針と名前解決の経路を確認します。そうすれば、同じサイトへのリクエストが異なるアウトバウンドを通る理由を把握できます。

LANへのアクセスも個別に考慮してください。プリンター、家庭用ストレージ、ルーターの管理画面への通信は、通常リモートを経由する必要はありません。ただし、その通信が先にTUNに入ることはあります。ルーティングをすべて無効にするのではなく、クライアントのLAN向けバイパス設定または明示的なルールを使ってください。会社のイントラネットドメインでは、専用DNSが必要な場合があります。パブリックDNSに変更すると、かえって接続できなくなることがあります。イントラネットに問題がある場合は、まず元の名前解決条件に戻し、名前が正しく解決されることを確かめてからプロキシ経路を調整してください。

範囲を絞ってテストし、設定一式の入れ替えは避ける

ルールは1つずつ追加し、対象、想定するアウトバウンド、テスト結果を記録します。テスト前に接続を確立し直し、必要に応じて対象アプリも再起動してください。既存の接続が新しいルールで再度経路を選択するとは限りません。Webページが開くかどうかより、ログに記録されたルールの一致情報のほうが、ルーティングの動作を判断しやすくなります。ページが開いていても、別の経路を通っている可能性があります。新しいルールが有効だと確認できたら、安定版の設定に保存し、テストの試行錯誤を正式なルールに残さないようにしましょう。

ルールの変更後に全体が使えなくなった場合は、まず元のプリセットに戻し、接続が確立できることを確認してから追加部分を比較します。JSONのカンマや配列構造、データ名、タグ参照を重点的に確認してください。カーネルとサブスクリプションを同時に変更しないでください。用語を確認したい場合は用語解説を、初回接続の手順に戻りたい場合は入門ガイドをご覧ください。高度なルールは、すでに使える接続を要件に合わせて振り分けるためのものです。基本ネットワーク、正しい認証、有効なサブスクリプションの代わりにはなりません。

設定のトラブル対処：症状から原因を絞る

状況を記録してから、手前の要因から順に確認する

問題が起きたら、発生させた操作、現在のネットワーク、使用中の設定、最初に見つかった明確なエラーを記録してください。手がかりを失うため、すぐにサブスクリプションを消去したり、クライアントを再インストールしたりしないでください。確認は、基本のネットワーク、システム時刻、ローカルのカーネル、待ち受け入口、使用中のサーバー、リモートのパラメーター、複雑なルーティングやDNSの順に進めます。一度に変更する項目は1つにし、前の手順の結果も残しましょう。どの変更が実際に効いたか判断できます。

クライアントの画面が開いてもカーネルが正常に起動していなければ、どのサーバーもローカルの入口から利用できません。この場合は、設定項目が受け付けられない、ファイルへのアクセスが制限されている、待ち受けポートが使用中などの起動エラーを確認します。ブラウザーにローカルプロキシへの接続失敗が表示される問題と、ログに記録されたリモートとのハンドシェイクタイムアウトは別の層の問題です。まずローカルサービスが正常に待ち受けていることを確認してから、リモートをテストしてください。すべてを「ノードに接続できない」と一括りにしないようにしましょう。

ハンドシェイク失敗とタイムアウトの確認方法

ログに認証またはハンドシェイクの問題が示されている場合は、サーバーの要件と照合してください。プロトコルの種類、サーバーアドレス、ポート、ユーザーID、TLS、通信方式、必要なパスやサービス名を確認します。アドレスは接続先、TLSのサーバー名は検証とハンドシェイクに使う名前であり、異なる場合があります。推測で入れ替えないでください。WebSocket のパスと gRPC のサービス名も混同しないようにします。大文字・小文字や先頭のスラッシュなどの細部は、元の設定に従ってください。

接続がタイムアウトする場合は、現在のネットワークから接続先の経路に到達できるか、特定の設定だけで失敗するか、ネットワークを切り替えると症状が変わるかを確認します。同じサブスクリプション内の設定がすべて失敗する場合は、まずローカルの入口と共通パラメーターを調べてください。1つだけ失敗する場合は、その設定のサーバー状態と通信要件を確認します。TLSエラーを隠すために証明書検証を無効にしないでください。システム時刻、ドメイン名、設定の入手元を確認しましょう。詳しい手順はノードのタイムアウトを順に確認する方法をご覧ください。

接続済みなのにアプリを使えない場合

「接続済み」は通常、何らかのサービスやインターフェースが起動したことを示すだけで、すべてのアプリのリクエストが成功するとは限りません。ブラウザーは使えるのに別のアプリで失敗する場合は、そのアプリのプロキシ入口と対象範囲を確認します。ドメイン名だけが失敗し、IPアドレスへの直接アクセスができる場合はDNSを調べます。TUNを有効にして通常のネットワークにも影響が出たら、いったんTUNを停止し、システムプロキシのモードで復旧するか確認してください。この比較で、仮想インターフェースとリモート接続のどちらに問題があるかを切り分けられます。最初から設定をすべて作り直す必要はありません。

Webページの一部が読み込めない場合は、複数のドメイン、既存の接続キャッシュ、異なるアウトバウンドルールが関係していることがあります。まず新しいテストウィンドウで再現し、ログで失敗したリクエストの接続先を確認してください。アドレスバーに表示されたメインドメインだけを対象にルールを変更しないでください。アプリが独自のプロキシ設定や長時間の接続を保持している場合は、クライアント設定を変更したあとにアプリの再起動が必要です。アプリごとのプロキシ設定を有効にしている場合は、対象アプリが除外されていないか、除外モードが想定と逆になっていないかも確認しましょう。

復旧、問い合わせ、今後のメンテナンス

設定を戻す必要がある場合は、追加したルールとTUNを停止し、システムプロキシとDNSを元に戻して、基本のネットワークが正常か確認します。その後、保存しておいた安定版の設定で接続し、カスタム機能を1つずつ戻してください。クライアントをアップデートする前に、動作している状態を記録して設定をバックアップします。アップデート後は基本接続を確認してください。1回のメンテナンスで、カーネル、サブスクリプション、ルーティング方式を同時に移行しないでください。手順は増えても、変更を分ければ明確なロールバック経路を保てます。

問い合わせるときは、OS、クライアント名、実際に使っているカーネル、エラーが発生する手順、個人情報を伏せたログを伝えれば十分です。サブスクリプション URL、ユーザーID、認証パラメーター、個人のネットワーク情報は隠し、エラーの種類と関連する設定名は残してください。メニューの場所を確認したい場合は該当プラットフォームの項目に戻り、形式についてはサブスクリプション管理、通信経路についてはプロキシとルーティングを参照してください。まず問題を1つの段階に絞ってから再インストールを検討するほうが、すべてを最初からやり直すより確実です。