v2rayN完全ガイド
設定とメンテナンス

基本概念：接続経路を理解する

クライアント、コア、リモートサーバーの違い

接続を4つの段階に分けて考えましょう。アプリがリクエストを送信し、ローカルのプロキシ入口が受け取り、コアが設定に従って処理・転送し、リモートサーバーが接続先のWebサイトにアクセスします。v2rayNは設定や動作状況を管理するGUIクライアントであり、リモートサーバーそのものではありません。インストールしただけで接続先が使えるようになるわけでもありません。クライアントはサブスクリプションの管理、サーバーの選択、システムプロキシ、コアの起動を担います。プロトコルやトランスポート、ルーティングを実際に処理するのはコアです。この関係を理解すれば、「ソフトが起動すること」と「接続が確立すること」を区別できます。

Project Vは関連するプロキシ技術のエコシステムを支えるプロジェクトで、V2FlyとXrayはそれぞれ異なるコアプロジェクトです。一部の概念は共通していますが、機能、設定項目、対応範囲は常に一致するわけではありません。共有リンクをインポートできても接続できない場合は、クライアント名だけで判断せず、現在のコアがその組み合わせに対応しているか確認してください。GUIに項目が表示されていても、すべてのコアで実行できるとは限りません。コアを切り替えたら、生成された設定と起動ログを確認し、変更が反映されているか確かめましょう。

プロトコル、トランスポート、セキュリティ層の違い

VMess、VLESS、Trojanはそれぞれ異なるプロキシプロトコルです。TCP、WebSocket、gRPCなどはデータを運ぶトランスポート方式、TLSとREALITYは接続のセキュリティに関わる仕組みです。これらは異なる階層の要素で、互いに置き換えられるものではありません。たとえばVLESSを選んでも、適切なトランスポートとセキュリティの設定が必要です。REALITYも、選択するだけで接続できる汎用スイッチではありません。サーバー側に対応する公開鍵、サーバー名などのパラメーターが必要です。サービス提供元から受け取った設定一式を基準にしてください。

一般にノードとは、リモート接続に必要なアドレス、ポート、ユーザーID、パスワード、トランスポート設定などを含む接続設定のことです。サブスクリプションURLは、複数の設定を取得するための入口で、更新によって登録内容が追加、削除、変更される場合があります。サブスクリプションを取得できても、個々の設定が使えるとは限りません。反対に、既存の設定で接続できても、サブスクリプションを更新できるとは限りません。設定の取得とプロキシ接続を分けてテストすると、問題を切り分けやすくなります。

ローカルポートとリモートポートの違い

ローカルの待受ポートは、ブラウザーやターミナルなどのアプリがクライアントに接続するためのものです。一方、リモートポートはサーバー側のサービスが使用するポートで、両者を同じ番号にする必要はありません。一般的なローカルSOCKSポートは10808ですが、実際の値は現在のクライアント設定で確認してください。127.0.0.1は自分の端末を指すループバックアドレスで、サーバーのアドレスではありません。リモートアドレスをブラウザーのローカルプロキシ設定に入力したり、ローカルポートをサーバー設定に入力したりすると、どちらもタイムアウトすることがあります。

DNSはドメイン名をIPアドレスに変換し、ルーティングはリクエストを直接接続、プロキシ、遮断のどれにするか決めます。システムプロキシの設定が適用されるのは、その設定を参照するアプリだけです。TUNは仮想ネットワークインターフェースを経由して、より多くの通信を取り込みます。そのため「システムプロキシを有効にする」だけで全アプリが接続されるわけではなく、「グローバルルーティング」を選んでもOS全体の通信がすべて取り込まれるわけではありません。設定を変更するたびに、リクエストがクライアントに届いているか、届いた後にどのルールに一致したかを確認しましょう。

設定を始める前に、OSの種類とプロセッサーのアーキテクチャを確認し、使用可能なサブスクリプションまたは完全な共有設定を用意してください。また、システム時刻が自動同期されていることも確認しましょう。サブスクリプションURLや共有リンクにはアクセス認証情報が含まれる場合があるため、公開の掲示板に貼らず、個人用のパスワード管理ツールなどに保管してください。サポートを求める際はプロトコル、トランスポート方式、エラーが起きた段階を伝え、URL内の認証情報は伏せましょう。この習慣は初回インポート時から身につけてください。

クライアントの選び方：プラットフォームとコア

デスクトップではv2rayNを優先

Windows、macOS、Linuxのデスクトップでは、v2rayNを主なクライアントとして利用できます。インストーラーを選ぶときは、まずOS、次にプロセッサーのアーキテクチャを確認し、その後にUIの種類やパッケージ形式を選びます。ファイルサイズや名前の長さだけで新旧を判断したり、別のOS用パッケージを何度も解凍したりしないでください。ダウンロードセンターでプラットフォームごとの説明を確認してください。OSから非対応形式だと表示された場合は、保護機能をすぐに無効化せず、まずプラットフォームとアーキテクチャを見直しましょう。

Windows版には、デスクトップ版と従来のWPF版があります。デスクトップ版はクロスプラットフォームのUIを採用し、WPF版は従来のUIを引き継いでいます。メニューの配置や設定の保存方法は異なる場合があります。初めて使う場合はデスクトップ版から始め、従来のUIに慣れている場合は環境に合わせてWPF版を選んでください。設定の問題を調べるためだけに両方のUIを何度も切り替えるのは避けましょう。画面上の項目の位置だけでなく、作業ディレクトリや実行条件も変わる可能性があり、原因の判断が難しくなります。

端末情報に合わせてインストーラーを選ぶ

macOSでは「このMacについて」でチップ情報を確認できます。Appleのチップと表示される場合はApple Silicon向け、Intelプロセッサーと表示される場合はIntel向けのものを選んでください。外観や購入年だけで判断しないようにしましょう。Linuxでは、まずディストリビューションのパッケージ管理方式を確認し、debまたはrpmを選びます。同じパッケージ形式でも、一般的なデスクトップ向けのx64と、ほかの端末で使われるarm64が分かれている場合があります。パッケージ形式とアーキテクチャの両方が一致している必要があります。

Androidでは、Xrayコアを使用するv2rayNGが第一候補です。V2Flyコアを使うv2flyNGは、そのコアが必要な場合の選択肢です。比較的新しいスマートフォンの多くはarm64を選べますが、端末の発売年だけでは判断できません。システム環境とチップの仕様が一致しない場合もあります。不明な場合はシステム情報を確認するか、汎用版を選んでください。2つのクライアントは名前だけが異なる同じアプリではありません。対応する設定項目やメニューの詳細をそれぞれ確認し、新しいセキュリティ機能がどちらでも使えると決めつけないようにしましょう。

プロトコル名で優劣をつけず、設定要件で選ぶ

クライアントは、手元の設定に必要な機能を基準に選びましょう。サービス設定で特定のトランスポートやセキュリティ項目を使う場合は、まずクライアントに含まれるコアが対応しているか確認し、その後でUIの使いやすさを検討します。「新しいプロトコルほど優れている」と考えて、すでに使えている設定を書き換える必要はありません。接続結果はプロトコル、トランスポート、証明書、ネットワーク環境に左右され、名称を変えるだけで改善するわけではありません。サブスクリプションを使う場合は、自分でパラメーターを推測するより、提供元の設定項目を維持するほうが確実です。互換性の問題がある場合は、エラーを記録し、対応範囲を確認してください。

設定を移行するときは、共有形式とクライアントの設定を分けて考えましょう。単一の共有リンクに含まれるのは通常、リモート接続に必要な項目だけです。ルーティング、DNS、ローカルポート、UIの設定までは含まれない場合があります。同じリンクを読み込めるからといって、環境全体を移行できたとは限りません。移行後は、ローカルの待受アドレス、システムプロキシ、現在の有効な設定、デフォルトルートを確認してください。端末を替える場合は、まず新しい端末で最小限の接続を確立し、成功を確認してからカスタムルールを一つずつ移すとよいでしょう。

同じ端末では、ネットワークを制御するクライアントを最初は1つだけ起動してください。複数のプログラムがローカルポート、システムプロキシ、仮想インターフェースを取り合うと、画面上は正常でもリクエストの経路が分からなくなることがあります。切り替えてテストする場合は、先に元のプログラムのプロキシ制御を解除し、次にプログラムを終了してから、新しいクライアントを起動してください。複数のクライアントをインストールして次々に試すより、正常に使える設定を1つ残して比較するほうが、問題の切り分けに役立ちます。クライアントのダウンロード元と接続設定の入手元も分けて管理しましょう。インストールできたことは、接続設定を持っていることを意味しません。

インストールと初回起動

書き込み可能なフォルダーと実行環境を用意

インストール前に、起動中の旧クライアントを終了し、現在のローカルポートとシステムプロキシの状態を記録してください。インストーラーを使う場合はOSの案内に従います。圧縮ファイルを使う場合はすべて展開してから、展開先のフォルダーから起動してください。圧縮ソフトの一時プレビューから直接実行するのは避けましょう。クライアントはコアのファイルを読み込み、設定を保存します。読み取り専用の場所、一時フォルダー、アクセス制限の厳しい共有フォルダーに置くと、設定が保存できない、コンポーネントが見つからないといった問題が起きることがあります。デスクトップのショートカットは起動用の入口にすぎず、実際のファイルがすべてデスクトップにあるわけではありません。

Windowsで起動できない場合は、まずシステムのダイアログに実行環境の不足が明示されているか確認します。配布パッケージによって必要なコンポーネントが含まれている場合と、対応するデスクトップランタイムが必要な場合があります。インストール手順に従って判断し、複数のランタイムを手当たり次第に入れないでください。従来のWPF版とクロスプラットフォーム版では、実行要件が異なる場合があります。アクセス権限のエラーが出たら、フォルダーに書き込めるか、セキュリティソフトによってファイルが隔離されていないか、警告の発信元はどこかを確認します。常に管理者として実行する方法を、一般的な解決策として使うのは避けてください。

プラットフォーム別の初回起動

macOSでは、インストール後にアプリを適切なアプリケーションフォルダーへ移してから起動してください。システムが起動をブロックした場合は、ダウンロード元と警告の内容を確認し、OSが案内する許可手順に従います。アプリを起動するためにセキュリティ機能全体を無効にしないでください。アーキテクチャの互換性に関する警告が出た場合は、端末情報に戻ってチップの種類を確認します。更新前にはアプリを終了してください。旧プロセスが動作中にファイルを置き換えると、画面と実際に動作するコンポーネントが異なるインストール状態になり、原因の判断が難しくなります。

Linuxでは、ディストリビューションに合ったパッケージ管理方法でインストールし、完了後にアプリメニューまたはインストール済みの起動項目から実行します。依存関係やGUIのエラーが起きたら、パッケージ管理によるインストールが失敗したのか、インストール後の起動に失敗したのかを分けて確認してください。前者はパッケージ形式と依存関係の表示、後者はグラフィカル環境、権限、起動時の出力を調べます。別のディストリビューション向けのコマンドをそのままコピーしないでください。ネットワーク制御に必要な権限は、該当機能を有効にするときに付与しましょう。通常の設定管理の段階で、あらかじめ権限を広げる必要はありません。

Androidではインストール後、まずアプリを開いて基本画面を確認し、すぐに接続する必要はありません。アプリのインストール許可を求められた場合は、信頼できる現在のインストール元だけに必要な許可を与えます。インストール後は、そのインストール元への許可を取り消してもかまいません。プロキシ接続の初回起動時に求められるVPN権限は、ローカルの通信制御インターフェースを作成するためのもので、インストール権限とは別です。ほかのVPNがすでに動作している場合は、先に元の接続を終了してください。許可を繰り返し確認しても、2つの通信制御サービスの競合は解決しません。

コアとローカル待受を確認

初回起動後、設定画面でローカルの待受アドレスとポートを確認し、ログにコアファイルの不足、設定の解析失敗、ポートの競合が表示されていないか確認してください。リモート設定をまだインポートしていない場合、一部の接続テストが完了しないのは正常です。必要な前提がそろっていないだけで、インストールの破損とは限りません。インストール先のコンポーネントが隔離された場合は、まずセキュリティソフトの処理履歴を確認してください。原因を特定してから、信頼できる配布元の説明に従って修復し、出所不明の同名コアファイルを適当に配置しないでください。

プロキシの入口は、まずローカルのループバックアドレスに限定してください。すべてのネットワークインターフェースで待ち受けると、同じネットワーク上のほかの端末からも接続できる可能性があり、ファイアウォールやアクセス制御も必要です。学習段階でほかの端末から使う必要がなければ、LAN接続を許可しないでください。ポートが使用中の場合は、そのポートを使っている古いクライアントを終了するか、用途を確認したうえで待受ポートを変更します。変更後はアプリ側のプロキシアドレスも更新してください。クライアントの入口だけを変更し、ブラウザーが古いポートに接続し続けると、エラーが解消しません。

最後に、初期状態を記録してください。インストール先、クライアントの種類、待受ポート、自動起動の有無、現在のシステムプロキシの状態を記録します。認証情報は含めず、後から環境を復元するのに必要な項目だけ残しましょう。自動起動、自動サブスクリプション更新、TUNを一度に設定するのは避けてください。まず手動起動の最小構成を動作させ、その後で自動化を追加します。問題が発生しても、インストール自体に問題があったのか、新たに追加した設定で通信経路が変わったのかを判断できます。

サブスクリプションの追加：グループと更新

まずURLの種類を見分ける

インポート前に、手元にあるものがサブスクリプションURL、単一の共有リンク、完全な設定ファイルのどれなのか確認します。サブスクリプションURLは、複数の設定を取得するためのネットワークアドレスです。共有リンクはプロトコル名で始まることが多く、1件分のリモート設定を記述します。QRコードはテキストを格納する手段で、中身は共有リンクの場合もサブスクリプションURLの場合もあります。すべての内容をサブスクリプション欄に貼り付けたり、サブスクリプションのWebページのログインURLを入力したりすると、形式エラーになります。内容を確認してから適切な入口を選びましょう。

v2rayNでサブスクリプショングループの設定を開き、用途が分かるグループ名を付け、サブスクリプションURL全体を入力欄に貼り付けて保存します。コピー時に含まれた前後の空白や改行は取り除きますが、URL内のクエリパラメーターは勝手に削除しないでください。認証に必要な場合があります。グループ名はローカルで管理するためのラベルにすぎず、リモートの設定を変更したり、更新を完了したりするものではありません。グループを保存した後に更新操作を行うと、サーバー設定が取得されます。

正しい更新方法を選ぶ

初めて設定し、まだプロキシを使えない場合は、「現在のサブスクリプションを更新（プロキシを使用しない）」などの項目を試してください。まだ接続できていない通信にサブスクリプションの取得を依存させずに済みます。サブスクリプションの提供元がプロキシ経由のアクセスを指定している場合は、まず利用可能な設定を確認してから、プロキシ経由で更新してください。どちらが常に優れているというわけではなく、現在のネットワークからサブスクリプションサーバーに到達できるかどうかが重要です。更新に失敗した場合は、エラーを確認し、名前解決の失敗、接続タイムアウト、認証失敗、応答内容の解析エラーを区別しましょう。

更新後は、一覧に現在のグループの設定が追加されたか、検索条件やグループの絞り込みで非表示になっていないか確認します。一覧が空の場合は、まず更新ログを確認し、URLからサブスクリプションの内容が返されているか調べてください。ブラウザーで開くとログイン画面、サブスクリプションの期限切れ通知、その他のWebページが表示されるURLもあります。ダウンロードに成功しても、有効な設定とは限りません。認証情報を含むサブスクリプションの内容を公開の変換サイトにアップロードしないでください。形式が分からない場合は、提供元に対応クライアントとエクスポート方法を確認しましょう。

クリップボード、QRコード、エンコードされたデータを使い分ける

v2rayNGでは、操作メニューからクリップボードの共有データをインポートしたり、QRコードをスキャンしたりできます。スキャン前に画像の入手元を確認し、インポート後はプロトコルとセキュリティの項目が揃っているか確認してください。サブスクリプションURLを受け取った場合は、サブスクリプショングループの設定で保存・更新します。サーバー設定1件としてインポートする方法は使いません。カメラ権限はスキャンが必要なときだけ許可してください。テキストが手元にある場合は、通常クリップボードからのインポートが簡単です。インポート後は有効な設定を選び、接続に必要なVPN権限を許可してください。設定が一覧に表示されただけでは接続確認は完了していません。

サブスクリプションの中には、複数の共有リンクをBase64でエンコードして格納するものがあります。エンコードは暗号化ではなく、内容を公開してよいという意味でもありません。通常、クライアントはサブスクリプションの更新時に対応形式を処理するため、事前に手動でデコードする必要はありません。応答が別形式の設定であれば、Base64に変換するだけでは互換性は得られません。各インポート方法の違いは、サブスクリプショングループ、クリップボード、QRコードからのインポート手順を参照し、内容の種類ごとに確認してください。

手動の変更が更新で上書きされないようにする

サブスクリプションの設定は次回更新時に再生成される場合があります。長期的に残したいカスタマイズを、サブスクリプションの項目だけに保存しないでください。個別の設定を変更する場合は、独立した設定として複製できるか、別のグループで管理できるか確認し、変更の目的と元の項目も記録します。更新が頻繁な場合、表示名だけで同じ設定かどうか判断するのは避けましょう。プロトコル、アドレス、主要なパラメーターを合わせて確認してください。名前が変わっても接続先が変わったとは限らず、名前が同じでも内部の項目が維持されているとは限りません。

手動での更新が安定してから自動更新を有効にし、実際の使い方に合った間隔を選びましょう。更新に失敗しても、利用可能な既存設定を残し、すぐにグループ全体を削除して作り直すのは避けてください。リモート側で認証が無効化された場合やサービスの利用期限が切れた場合、ローカルの更新方法を何度変えてもアクセスは回復しません。サブスクリプションの状態を確認してください。端末を移行する場合は、グループと必要な設定を移してから手動で更新します。出所が不明な古い一覧をそのままコピーすると、無効になった設定まで新しい環境に持ち込む可能性があります。

システムプロキシ：接続と動作確認

コアを起動してから、アプリを接続する

サブスクリプションを追加したら、使う設定を選んで有効にし、コアが起動していることを確認します。続いてシステムプロキシの自動設定を選ぶと、システムプロキシを参照するアプリからのリクエストがローカルの入口へ送られます。メニューの「システムプロキシをクリア」は、通常、OSのプロキシ設定を削除するもので、コアの停止まで行うとは限りません。「システムプロキシを変更しない」は、通常、OSの現在の設定を維持するという意味で、プロキシを無効にすることではありません。具体的な動作は現在のクライアントの説明で確認し、項目名に「プロキシ」とあるだけで判断しないでください。

WindowsとmacOSでは、多くのブラウザーがシステムプロキシを参照しますが、ブラウザー拡張、独自の起動オプション、企業ポリシーが設定を上書きする場合があります。Linuxでは、デスクトップ環境やアプリによってシステムプロキシの参照方法が異なるため、アプリ側でローカルの入口を明示する必要があることもあります。ターミナルのプログラムは、デスクトップのプロキシ設定を参照しない場合がよくあります。そのため、ブラウザーでアクセスできてもコマンドラインの通信が同じ経路を通るとは限りません。ターミナルで接続できないからといって、すぐにシステムプロキシの不具合だと判断することもできません。

接続方式とルーティング方式を分けて考える

システムプロキシは「リクエストをどうクライアントに渡すか」を決め、ルーティングは「受け取った後、どこへ送るか」を決めます。一般的なグローバルプロキシのルーティングは、コアに届いたリクエストを優先的にプロキシ経由で送る設定であり、端末内のすべてのアプリを強制的に制御するものではありません。ダイレクトルートの場合も、ローカルのコアを経由した後、出口として直接接続を選ぶことがあります。PACではルールスクリプトがアプリにプロキシを使わせるかを決めます。これは接続段階のルールであり、コア内部のルーティングと混同しないでください。トラブル対処では、明確な接続方法を1つだけ使って確認しましょう。

Androidでは、v2rayNGが通常、ローカルのVPNインターフェース経由でアプリの通信を取り込み、アプリごとのプロキシ設定を利用できる場合もあります。アプリを対象にするか除外するかは、現在のモードによって異なります。リストにあるアプリだけがプロキシを使う場合もあれば、リストのアプリが対象外になる場合もあります。アプリ名が一覧に表示されているだけで、接続対象だと判断しないでください。まず追加のプロキシ設定をしていない通常のアプリで確認し、問題がなければ対象を広げます。ブラウザーをテストするときは、設定の重複を避けるため、プロキシ拡張を一時的に無効にしてください。

1つのWebサイトだけで判断せず、段階ごとに確認する

まずコアのログに起動エラーがないことを確認します。次にローカルポートが実際に待ち受けていることを確かめ、プロキシに対応したアプリからリクエストを送ります。最後に、そのアプリがシステムプロキシを利用しているか確認してください。次のコマンドではSOCKS入口を明示できます。ポートは設定画面に表示された実際の値に置き換えてください。ここでのsocks5hは、接続先ドメインの名前解決をプロキシ側で行う指定です。ローカルの名前解決とプロキシ経路の問題を切り分けるのに役立ちますが、システムプロキシの設定自体が正しいことを証明するものではありません。

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --head https://example.com/

コマンドから妥当なHTTP応答が返れば、そのリクエストは少なくとも対応する接続処理を完了しています。接続先がリダイレクトやアクセス拒否を返すこともあり、成功ステータス以外にも診断に役立つ応答があります。ローカルポートへの接続にすぐ失敗した場合は、コアと待受アドレスを確認してください。ローカルの入口に接続した後でハンドシェイクエラーが出た場合は、リモート設定と時刻を調べます。テスト先のWebサイト自体に問題がある場合もあるため、必要に応じて正常だと分かっている別の接続先でも確認し、サイトの障害をプロキシ全体の問題と混同しないようにしましょう。

終了方法と元に戻す手順を明確にする

クライアントを終了する前に、システムプロキシを解除するか、元のシステム設定に戻してからプログラムを終了してください。そうしないと、待受を停止したローカルポートをシステムが参照し続け、ブラウザー全体が接続できなくなる場合があります。システムのスリープ復帰後、異常終了後、プロセスを強制終了した後も確認しましょう。元のシステムプロキシが職場のネットワークや別の管理プログラムによるものなら、まず元の値を記録し、区別せずに削除しないでください。新しい設定を重ねるより、まずネットワーク接続を復旧することが重要です。必要であれば直結環境に戻し、最小の接続経路から段階的に構築し直しましょう。

プロキシを明示したコマンドは使えるのにブラウザーで使えない場合は、ブラウザー拡張、独立したプロキシ設定、古い接続キャッシュを確認します。ブラウザーは使えるのにターミナルで使えない場合は、ターミナルの環境変数やプログラム固有のプロキシ設定を調べてください。両者は別々に確認し、すぐにクライアントを再インストールする必要はありません。詳しくはブラウザーとターミナルでシステムプロキシが機能しない場合の対処法を参照してください。検証中はテスト先、使用した入口、エラーが起きた段階を記録し、「使える」「使えない」だけで済ませないようにしましょう。

ルーティング：ルールとDNS

デフォルトの出口とルールの順序を決める

ルーティングでは、リクエストがコアに届いた後、ドメイン、アドレス、ポート、プロトコルなどの条件に応じて出口を選びます。設定を始める前に、どのルールにも一致しないリクエストがどの出口を使うかを決め、必要最小限のルールを追加してください。たとえば、LAN内のアドレスは直接接続し、指定ドメインはプロキシ経由、その他はデフォルトの方針に従う構成です。ルールは多いほど正確とは限りません。重複したルール、条件の範囲が広すぎるルール、出所不明のルールセットは、動作を理解しにくくします。ルールを追加するたびに、何に一致し、なぜその順序に置くのか説明できるようにしましょう。

多くのコアはルールを上から順に確認し、最初に一致したルールで出口を決めます。そのため、対象が明確で範囲の狭い例外を、広いルールより前に置いてください。たとえば、あるドメインはプロキシ経由にしたい一方で、より広いドメイン集合を直接接続にしている場合は、両者の順番を確認します。プライベートアドレスを直接接続にすると、ルーター、プリンター、ファイルサーバーへのアクセスがリモートサーバー経由になるのを防げます。ただし、内部の名前がすべて正しく解決されるとは限りません。名前解決とアドレスのルーティングをそれぞれ確認してください。ルールを1つ追加しただけで両方が解決したと思い込まないようにしましょう。

設定例を読み、設定全体の置き換えを避ける

以下はXrayのルーティングオブジェクトの構造例です。最初にプライベートアドレスを直接接続し、次に例示したドメインとそのサブドメインをプロキシ経由にします。完全な設定ではありません。directとproxyは現在の設定に実在するアウトバウンドのタグに対応させる必要があります。また、geoip:privateを使うには、対応するアドレスデータが利用できなければなりません。GUIクライアントは通常、完全な設定を生成します。この断片を設定ファイル全体に上書きしないでください。GUIのルールエディターを使う場合は、同じ意図を対応するルール項目に置き換えてください。

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

この例のアドレスルールが機能するのは、照合できるアドレス条件がある場合だけです。リクエストにドメイン名しか含まれず、現在のドメインポリシーが照合のために名前解決を行わない場合、「プライベートアドレスに解決されるドメインをすべてこのルールで処理できる」とは限りません。同様に、ドメインルールの適用にはコアがドメイン名を把握している必要があります。アプリがアドレスしか送らない場合、元のドメイン名をコアが取得できないことがあります。スニッフィングで一部の通信から名前を補える場合もありますが、暗号化された通信をすべて識別できるわけではありません。必ずルールに一致させる万能機能だと考えないでください。

DNSは独立した経路として考える

DNSを設定するときは、アプリがどこで名前解決するのか、クライアントがどのリゾルバーを使うのか、DNSリクエスト自体がどの経路を通るのかを個別に確認してください。アプリが独自の暗号化DNSを使う場合、システムのリゾルバーを経由しないことがあります。SOCKSを明示したリクエストも、ローカルとプロキシ側のどちらで名前解決するかを選べる場合があります。コアのDNS設定がOS内のすべてのアプリの問い合わせを制御するとは限りません。ドメイン名では開けずIPアドレスでアクセスできる場合は、リモートポートをすぐに変更せず、まず名前解決の結果と問い合わせ経路を確認してください。経路によって異なるIPアドレスが返ると、その後に適用されるルーティングルールも変わる場合があります。

リゾルバーとプロキシ接続の間で循環依存が起きないようにしてください。たとえば、リモートサーバーに接続するためにドメインの名前解決が必要なのに、その問い合わせをまだ確立していない同じ接続経由で送ろうとすると、開始地点で止まる可能性があります。初期の名前解決に使える経路を確保し、サーバー名の解決方法を確認してください。名前解決の方針を変更した後も、アプリ、OS、コアにそれぞれキャッシュが残る場合があります。元の設定を記録し、関連する部分ごとにキャッシュを消すか再起動してから新しい接続をテストしましょう。古いキャッシュによって新しいルールが効いていないように見えるのを防げます。

ルーティング結果を1つずつ確認する

ルールをテストする際は、対象を1つ決め、アプリがドメイン名を送っているか、適用される条件は何か、最終的な出口はどこかを記録します。ログで一致したルールを表示できる場合は、テスト中だけログレベルを上げ、終わったら元に戻してください。アクセスできるかどうかだけを唯一の判断材料にしないでください。直接接続でもプロキシ経由でもアクセスできる場合があります。反対に、プロキシの出口が接続先サービスに制限されていても、ルールが一致している可能性はあります。まず通信がコアに届いていることを確認し、次に予想した出口が選択されたこと、最後に接続先からの応答を確認しましょう。この順序なら、ルーティングの問題とサービス側の問題を分けて調べられます。

TUNモード：通信の取り込みと元に戻す方法

より広い範囲の通信を取り込む必要があるか確認

TUNは仮想ネットワークインターフェースでシステムの通信を受け取り、対応する処理コンポーネントへ転送します。システムプロキシを参照せず、独自のプロキシ入口も持たないアプリには便利ですが、すべてのタイムアウトを解消するためのスイッチではありません。ローカルプロキシを明示したテストでもリモートに接続できない場合、TUNを有効にすると同じエラーがより多くのアプリに広がるだけです。まず通常のプロキシモードでリモート設定、DNS、ルーティングを確認してから、この章に進みましょう。新たな問題が起きたときに、既存の問題ではなく通信の取り込み層に原因を絞れるようになります。

TUNの実装は、プラットフォーム、クライアントのビルド、選択したコンポーネントによって異なります。メニュー名、ネットワークスタックの項目、必要な権限が一致するとは限りません。画面のスクリーンショットと同じスイッチを探したり、特定のプロキシコアを選ぶだけで必要な機能がすべて使えると思い込んだりしないでください。現在の画面にある機能説明、起動ログ、必要なコンポーネントの案内を確認します。AndroidのローカルVPNインターフェースとデスクトップのTUNは使い方が似ていますが、権限の仕組みや選択可能な設定をそのまま流用することはできません。

ネットワークの初期状態を記録してから、1つずつ有効にする

有効化する前に、現在のネットワークアダプター、システムDNS、ほかのVPNの有無、クライアントの接続方式を記録してください。ルーティングを変更するほかのプログラムを終了して通信の二重制御を一時的に止めてから、TUNを有効にし、システムの案内に従って必要な権限を与えます。起動失敗をすべて権限不足のせいにしないでください。ログに出るインターフェース作成失敗、ルート追加失敗、ポート競合、設定の非対応はそれぞれ別の問題です。エラーが明確に権限を示す場合に限り、現在のプラットフォームの要件に合わせて許可範囲を調整してください。

最初はデフォルトのネットワークスタックと基本設定を保ち、MTU、厳格なルーティング、DNSハイジャックなどの詳細項目を同時に変えないでください。まず一般的なWebページ、次にシステムプロキシを参照しないアプリ、最後にLAN内の端末やスリープ復帰後の通信を確認します。Webページは使えても特定のリアルタイムアプリが動かない場合は、UDP経路やアプリ側の制限を調べる前に、リモートプロトコルと出口が該当する通信に対応しているか確認してください。TUNがデータを受け取れることと、リモートサービスがあらゆるトランスポートを転送できることは別です。

ループ、DNS、LANアクセスを確認

すべてのルートを取り込む場合、クライアント自身がリモートサーバーに接続する通信を同じ仮想インターフェースへ送り返さないようにする必要があります。通常の実装では適切に迂回されますが、カスタムルート、複数の通信制御プログラム、手動のネットワークアダプター設定によって動作が変わる場合があります。コアは正常に起動するのに、通信の取り込みを有効にするとすぐに接続できなくなる場合は、まずTUNを無効にして基本のプロキシが復旧するか確認し、リモート通信が誤って取り込まれていないか調べてください。システムのルーティングテーブルから項目を一括削除しないでください。

DNSの取り込みとFakeDNSも、別の仕組みとして理解しましょう。DNSの取り込みは問い合わせを指定された経路へ送り、FakeDNSは仮想アドレスを返してドメイン名との対応関係を管理します。組み合わせて使うことはできますが、同じスイッチではありません。仮想アドレスを使うと、対応する処理経路を通らないアプリが直接アクセスできないアドレスを受け取る場合があります。社内ネットワークの名前、LAN内の機器検出、独自の名前解決機能を持つアプリは特に個別に確認してください。明確な目的がなければ通常の名前解決を維持し、説明のしやすさを損なってまで機能を増やすのは避けましょう。

終了時のテストも有効化手順に含める

有効化できたら、機能を無効にする、クライアントを終了する、ネットワークを切り替える、スリープから復帰するテストも行います。終了後に仮想インターフェースに関連するルートと名前解決の設定が元に戻り、通常のネットワークが使えることを確認してください。終了後も接続できない場合は、システムにローカルプロキシへの指定が残っていないかを調べ、次に使用中のインターフェースとリゾルバーを確認します。問題の状態に関する基本情報を保存した後、OSの通常のネットワーク再接続手順で復旧してください。用途が分からないままネットワークアダプターをまとめて削除したり、ファイアウォール設定をすべて消去したりしないでください。

通信の取り込み、ルーティング、LAN、終了後の復旧をすべて確認してから、自動起動を検討してください。ネットワークの準備ができる前や、必要な権限が許可される前に起動する可能性も考慮します。ログイン後に手動で起動できることだけをテストしても不十分です。設定に問題が起きたときは、TUNを無効にし、元のシステムプロキシとDNSに戻し、動作確認済みの通常のプロキシ設定で調べるのが確実な復旧手順です。応用機能は明確な目的を満たすためのもので、すべてのスイッチを有効にすることが目的ではありません。

日常のメンテナンス：バックアップとトラブル対処

復元できる設定状態を保存する

日常のメンテナンスは、更新よりもバックアップから始めましょう。まずクライアントのエクスポートまたはバックアップ機能を使い、サーバー設定、サブスクリプショングループ、ルーティングルール、DNS、UIの設定がそれぞれ含まれるか確認します。設定フォルダーをコピーする場合は、書き込み途中のデータが含まれないよう先にクライアントを終了してください。保存場所は現在のインストール方法によって異なります。すべてのプラットフォームで同じ場所にあると思い込まないでください。バックアップには簡単な説明を添え、対象プラットフォーム、UIの種類、その時点で使えていた機能を記録しておきます。

バックアップにはサブスクリプションの認証情報、サーバーのパスワード、プライベートなドメイン名が含まれる場合があります。アクセス制御されたローカル環境、または信頼できる暗号化ストレージに保存してください。サポート用に共有する設定と、復元用の完全なバックアップは分けて管理します。前者から機密情報を取り除き、後者には復元に必要な項目を残します。画面のスクリーンショットだけでは、非表示の項目やルールの順序を復元できないことが多いため、それだけをバックアップにしないでください。更新前には、利用可能だと確認済みの設定を最低1つ保存し、問題が起きてから探すのではなく、復元方法も確認しておきましょう。

クライアント、コア、ルールデータを分けて更新する

クライアントの更新ではGUIや管理方法が変わり、コアの更新ではプロトコル処理の対応範囲が変わり、ルーティングデータの更新ではルールセットの照合対象が変わります。これらを同じ更新として扱わないでください。一度に1種類だけ更新し、起動、サブスクリプションの更新、通常の接続、終了後の復旧を確認してから次に進みます。安定していた接続が突然失敗した場合は、直近で変更した層を振り返りましょう。頻繁な再インストールより、設定変更を記録しておくほうが役立ちます。再インストールしても古い設定が残ったり、問題発生時の状態が失われたりする場合があり、原因の説明につながらないこともあります。

バージョンの変更により、項目が廃止されたりデフォルトの動作が変わったりする場合があります。更新後はログに設定の互換性に関する警告がないか確認してください。完全なカスタム設定は特に注意が必要です。GUIで生成される設定を経由しないため、新しい画面項目が自動的に反映されるとは限りません。戻す必要がある場合は、古い設定と互換性のある方法で復元し、複数のプログラムから同じデータフォルダーへ同時に書き込まないようにしてください。設定データベースの移行後は、旧プログラムで直接読み込めない場合もあります。変更前のバックアップを残しておきましょう。

エラーが起きた段階に応じてログを読む

トラブル対処では、まずどの操作の後にエラーが起きたかを記録します。プログラムを開けない、コアが起動しない、サブスクリプションを取得できない、アプリのリクエストが失敗する、といった段階を区別しましょう。プログラムの起動問題では実行環境とフォルダーの権限を確認します。コアの起動問題では設定項目、コンポーネント、ポートを調べます。サブスクリプションの問題ではURLと取得経路を確認し、リクエストの問題では名前解決、リモートのハンドシェイク、ルーティングを調べます。「接続に失敗した」とだけ伝えるより、エラーの原文を残すほうが有効です。ログにはアドレスやユーザー情報が含まれる場合があります。共有する前に確認し、伏せてください。作業フォルダー全体をそのままアップロードしないでください。

ノードのタイムアウトは、システム時刻、ローカル待受、ネットワーク到達性、トランスポート設定の順に確認できます。システム時刻のずれは証明書やハンドシェイクに影響し、ポート競合があるとアプリは想定したプロセスに接続できません。サーバーのポートに到達できない場合は、さらに別の層の問題です。TLS関連のエラーでは、サーバー名、証明書の状態、セキュリティ設定を確認してください。検証機能を無効にしたまま使い続けるのは避けましょう。詳しい手順はシステム時刻、ポート、TLSハンドシェイクのトラブル対処を参照し、変更のたびに新しいリクエストを送ってください。

テスト条件を揃える

変更前後を比較する際は、同じアプリ、同じ接続先、同じネットワーク入口を使ってください。設定を切り替えた後も古い接続が再利用される場合があります。必要に応じてテスト用のアプリを終了するか接続を切断してから、新しいリクエストを送ります。システムのスリープ、Wi-Fiと有線の切り替え、ログインが必要なネットワークへの接続は、通信の前提を変える場合があります。ネットワークにログインできていない場合は、プロキシ設定を元に戻してから通常の接続手続きを完了してください。ネットワークの認証ページをサブスクリプションの応答や接続先の応答と誤認しないようにしましょう。

通常はデフォルトまたは適切な量のログを維持し、問題を再現するときだけ一時的に詳細度を上げます。ログが多すぎると保存領域を消費し、アクセスに関する情報も多く記録されます。問題が解決したらログレベルを元に戻し、必要に応じて古い記録を削除してください。定期的にサブスクリプションの有効性、バックアップの読み込み可否、システムプロキシを正常に解除できるか確認すれば十分です。安定して動作している設定を毎日変更する必要はありません。メンテナンスの目的は予期しない変更を減らし、次の問題に備えて比較の基準と実行可能な復旧手順を用意することです。

応用への道筋：動作確認からカスタマイズまで

まず設定項目の相互関係を理解する

各章の内容を確認した後は、設定を増やすのではなく、項目どうしの制約を理解しましょう。まず利用できることが確認済みの設定を用意し、プロトコル、トランスポート、セキュリティ、ルーティングの各項目がコアの設定にどう反映されるかを確認します。説明できる範囲から読み進め、ユーザーID、パスワード、公開鍵など、リモートサービス側で決まる項目を安易に変更しないでください。設定構文を学ぶことと、実際の認証情報を書き換えることは別です。前者は機密情報を伏せた設定例を使って練習できますが、後者には対応するサービス情報が必要です。

プロトコルを学ぶときは、必要な認証項目、データの運び方、組み合わせ可能なセキュリティ機構、現在のコアの対応状況を確認してください。名称の新旧で互換性を判断しないようにしましょう。たとえばREALITYでは、サーバー名、公開鍵、ショートIDをサーバー側の要件に合わせる必要があります。クライアント側でフィールドをランダムに生成しても、既存のサービスが自動的に受け入れるわけではありません。複数の値を指定できる項目でも、どのような組み合わせでも正しいとは限りません。提供元の説明と一つずつ照らし合わせ、利用可能な元の設定も比較用に残してください。

具体的な疑問を解決できる小規模な実験を行う

実験を始める前に、「このターミナルはシステムプロキシを参照していない」などの仮説を書き出し、変更する条件を1つに絞ってテストを設計します。まず直接接続でリクエストを送り、次にローカルの入口を明示し、最後に環境変数を試します。入口を明示すると成功し、通常のリクエストでは失敗する場合は、ルーティングやDNSを同時に変えず、まずアプリの接続方法を確認しましょう。実験結果には、リクエストの入口、エラーが起きた段階、予想した出口を記録します。Webページが開いたかどうかだけを残すより、この積み重ねが別の環境にも活用できる判断力につながります。

ルーティングの実験では、まず例示用のドメイン1つだけにルールを設定し、ルールへの一致と出口を確認してから、ドメインやアドレスの集合へ広げます。DNSの実験では、アプリによるローカルの名前解決とプロキシ側の名前解決を比較し、キャッシュの影響に注意してください。TUNの実験では、LAN、ネットワークの切り替え、終了後の復旧も確認します。各実験には個別の復旧手順を用意し、前の実験を理解しないまま次に進まないようにしましょう。結果が仮説と異なる場合は、その現象を記録して変数を絞ります。表面的にアクセスできるようにするための修正を重ねないでください。

設定構文と生成の仕組みを正しく理解する

JSONの例では、二重引用符、カンマ、括弧は構文の一部です。文字列内の項目名は、各コンポーネントの設定仕様に従います。標準のJSONではコメントと末尾の余分なカンマを使用できません。Web上で読めるコメント付きの断片が、そのままコアに読み込めるとは限りません。設定を解析できたことは、構文が正しいことを示すだけです。項目の組み合わせが意味的に正しいことや、リモートサービスが利用できることを保証するものではありません。エラーが起きた場合は、構文エラー、未知の項目、出口タグの不足、接続エラーを分けてから、変更する箇所を決めましょう。

GUIクライアントは通常、画面の設定から実行用の設定を生成します。生成されたファイルを直接編集すると、次回の起動や設定の切り替えで上書きされる場合があります。継続的にカスタマイズする場合は、クライアントに用意されているルール、カスタム設定の断片、完全な設定ファイルの各入口が、どの段階で適用されるか確認してください。必要最小限の方法を優先し、生成された設定全体を長期保守するファイルとしてコピーしないようにしましょう。完全なカスタム設定を使うと、項目の互換性、出口の参照、後続アップデートへの対応を自分で担う必要があります。これらの責任を理解してから利用し、設定の参照元が二重になるのを防いでください。

セキュリティ境界を設定設計に含める

プロキシは特定の経路上の通信を保護するものであり、すべてのアクセスが自動的に匿名になるわけではありません。接続先のWebサイトのアカウント、ブラウザーの保存データ、アプリのテレメトリー、リモートサービスの運用ログには、それぞれ別の境界があります。サブスクリプションや共有リンク自体も機密性の高い入口です。不要になったコピーは定期的に削除し、漏えいが疑われる場合はサービス提供元が案内する方法で認証情報を変更してください。LAN向けの待受やリモート管理を有効にする前に、誰がアクセスできるのか、どう制限するのか、無効化後に入口が停止したことをどう確認するかを明確にしましょう。

証明書エラーを回避するためにセキュリティ検証を長期的に無効化することや、出所不明の設定一式から説明できないリゾルバー、ルール、管理インターフェースを引き継ぐことは推奨されません。接続できることは最低限の確認にすぎません。保守しやすい設定には、出所が明確であること、動作を説明できること、権限が適切であること、終了後に元の状態へ戻せることも必要です。業務用端末や管理対象ネットワークでは、端末とネットワークの管理要件に従ってください。グローバルルート、システムサービス、ファイアウォールを変更する場合は、特に元の状態を記録し、許可範囲を確認しましょう。

理解度は、次の内容を一通り説明できるかで確認できます。あるアプリがどの入口を使い、ローカルでどのコンポーネントが処理し、ドメイン名をどこで解決し、どのルールが出口を選び、リモート側でどのパラメーターが必要か、そして失敗時にどう復旧するか。各項目を説明できるようになってから、複雑なルーティング、仮想アドレスのマッピング、より細かいアプリの通信制御を学ぶと、基礎を固められます。シンプルで検証可能、かつ元に戻せる設定を常に残してください。応用設定は必要に応じて選べる手段であり、仕組みの分からないまま依存するものではありません。