v2rayNの全プラットフォーム設定
と Androidのサブスクリプション設定

事前準備と設定範囲の確認

クライアント・コア・サブスクリプションの違い

まず、設定する対象がどの層なのかを確認しましょう。v2rayNはデスクトップ向けのGUIクライアントで、サーバー情報の保存、サブスクリプショングループの管理、実行設定の生成、コアの制御を行います。実際の接続処理は選択したコアが担当します。AndroidではXrayコアを使用するv2rayNGが基本です。V2Flyコアが必要な場合に限り、v2flyNGを検討してください。サブスクリプションはサービス提供元が発行するURLまたは設定データであり、クライアントのアカウントとは異なります。アプリをインストールしても利用可能なサーバーが自動で用意されるわけではなく、任意のWebページのURLをサブスクリプションとして使うこともできません。有効なサブスクリプションを用意してから、各プラットフォームの項目に進んでください。

サービス提供元の案内で、形式、プロトコル、利用条件を確認してください。サブスクリプションには、共有リンク、エンコードされたリンクの一覧、特定クライアント向けの設定データなどがあります。読み込めるかどうかは、クライアントが実際に対応している形式によって異なります。ファイルの拡張子だけで互換性を判断したり、実行設定全体を「可选地址 Url」に貼り付けたりしないでください。サーバー単体の共有リンクを受け取った場合は、クリップボードからサーバーをインポートする機能を使います。サブスクリプションURLの場合は、サブスクリプショングループを作成してください。取り込み方法によってデータの取得元と、その後の更新方法が異なります。

アーキテクチャ・時刻・ネットワーク環境を確認

ダウンロードセンターを開く前に、システム情報でプロセッサのアーキテクチャとOSの種類を確認してください。デスクトップ版はプロセッサとディストリビューションに合ったものを選び、PCのメーカー名だけで判断しないでください。Windowsのシステムの種類、macOSのチップ情報、Linuxのマシンアーキテクチャ、Android端末のプロセッサ性能によって、適切なインストール方法が異なります。インストーラーの形式が合っていても、OSのバージョンが要件を満たすとは限りません。ランタイム、システムAPI、インストーラーの制限が表示された場合は、案内に従って対処してください。アプリが正常に起動していない状態で、サブスクリプションを何度も読み込み直しても解決にはなりません。

時刻の自動設定を有効にし、タイムゾーンと現在時刻が正しいことを確認してください。TLS証明書の検証にはシステム時刻が使われるため、大きくずれていると、すべてのサーバーでハンドシェイクエラーが発生することがあります。次に、通常のドメイン名を解決できるネットワークか確認し、必要ならネットワークのログインページで認証を済ませます。公衆Wi-Fiの未認証状態、ポータルページによる通信の遮断、ローカルDNSの障害は、サブスクリプション取得時のタイムアウトとして現れることがあります。準備段階では基本的なネットワークだけを確認し、TUNや複雑なルーティングを急いで有効にしないでください。まず最小限の設定で再現可能な接続を確立し、その後で機能を追加します。

設定を記録し、確認する順序を決める

変更前に、現在のシステムプロキシの状態、ローカルの待受ポート、サブスクリプショングループ名を記録してください。旧クライアントから移行する場合は、まず旧アプリを終了します。旧アプリがポートを占有したまま、システムプロキシを書き換え続ける状態を避けてください。設定をバックアップするときは、サブスクリプションURLを機密情報として扱います。URLに含まれるtokenがアクセス権を持つ場合があります。スクリーンショットを公開するときは、URL全体、ユーザー識別情報、サーバーの認証情報を隠してください。本文中の例示URLは入力欄の説明用であり、実際のサブスクリプション更新には使用できません。確認済みの有効なURLを置き換えないでください。

「アプリの起動、サブスクリプションの更新、サーバーテスト、通信のプロキシ経由化、出口の確認」の順に進めます。各段階の結果を記録してから次へ進んでください。コア、DNS、ルーティング、プロキシモードを一度に変更すると、問題の原因を特定しにくくなります。初めて使う場合は、クイックスタートの手順で接続を確認してから、このページに戻ってプラットフォームごとの設定を進めてください。インストールが終わっていない場合は、まずインストールの問題を解決します。クライアントのテストは成功するのにブラウザーだけ接続できない場合は、アプリがプロキシを使っているかを確認してください。すぐにすべてのサーバーを切り替える必要はありません。

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

デスクトップ版または従来のWPF版を選ぶ

Windowsのダウンロードページを開き、v2rayNのデスクトップ版と従来のWPF版から選択します。デスクトップ版はクロスプラットフォームのUIを採用し、従来のWPF版はWindows向けのデスクトップUIを使用します。メニューの配置が異なる場合があるため、別バージョンのスクリーンショットを見て座標だけを頼りに操作しないでください。現在の配布一覧から、システムの種類に合ったインストール方法を選び、インストール時の環境要件を確認します。ここでは設定名に沿って手順を説明します。すべての配布パッケージで同じインストール方法が使えるとは限らず、特定のOSバージョンで必ず動作するとも限りません。

インストール後は通常ユーザーとして起動し、メインウィンドウ、サーバー一覧、ログ欄が正常に表示されることを確認してください。解凍して使う配布形式の場合は、書き込み可能なフォルダーに完全に解凍します。圧縮ファイルのプレビュー画面から直接起動しないでください。メインプログラムだけを移動して、同じフォルダーに必要なコンポーネントを残し忘れることも避けましょう。アプリのインストール先と実際の設定保存先は異なる場合があります。移行前に、クライアントのバックアップ機能や設定管理機能でデータの場所を確認してください。ファイルの書き込みに失敗した場合は、サブスクリプションの問題と決めつけず、まずフォルダーのアクセス権とセキュリティソフトの記録を確認します。

サブスクリプションを取り込み、サーバーをテストする

「订阅分组设置」を開いてグループを追加し、見分けやすい別名を付けて、完全なURLを「可选地址 Url」に貼り付けます。有効になっていることを確認して保存し、「订阅分组」メニューから「更新全部订阅(不通过代理)」を実行します。更新後に該当グループを選び、サーバーが表示されるか確認してください。一覧が空の場合は、まず検索とフィルターを解除してから、ログで更新結果を確認します。グループの更新成功とサーバーへの接続成功は別です。メニューにエラーが表示されなかっただけで、実際に接続できたと判断しないでください。

サーバーを一つ選び、「真连接延迟」テストを実行して、成功したサーバーを使用中のサーバーに設定します。TCPingは主に相手側ポートへ到達できるかを確認するもので、プロトコルのハンドシェイク、認証、宛先へのリクエストがすべて成功することまでは証明しません。真の接続遅延もテスト先の影響を受けるため、後でブラウザーからも確認してください。大量のサーバーを一度にテストし、単発の結果だけで判断しないようにします。まずサーバーとテスト先を一つずつ固定し、ログで外向き接続が確立するかを確認してから、他のサーバーと比較してください。

システムプロキシを設定し、終了時の状態を確認

コアが起動していることを確認してから、v2rayNのシステムプロキシメニューで「自动配置系统代理」を選択します。次にWindowsの設定でプロキシの状態を確認し、アドレスがローカルを指していること、ポートがクライアントの待受設定と一致していることを確かめてください。システムプロキシを使うのは、その設定を参照するアプリだけです。一部のコマンドラインツール、ゲーム、独自のネットワーク設定を持つアプリは自動では従いません。ブラウザーにプロキシ拡張機能や独自設定がある場合は、拡張機能の直接接続ルールがシステム設定を上書きしないよう、プロキシの設定元を統一してください。ブラウザーで一般的なWebページが開けても、現在のサーバー経由で通信しているとは限りません。

出口の接続を確認してから、TUNを使うか判断します。TUNが必要な場合は、クライアントの案内に従って必要な権限を付与してください。通常のシステムプロキシ接続のトラブル対処で、管理者権限のまま使い続ける必要はありません。起動時にポート使用中と表示された場合は、古いインスタンスを終了して、ほかの待受プログラムがないか確認します。ポートを変更した場合は、手動で設定したアプリ側のポートも合わせて変更してください。終了前にシステムプロキシを解除してからクライアントを閉じます。そうしないと、アプリが停止済みのローカルポートへ接続し続けることがあります。スリープ復帰後、ネットワーク切り替え後、または更新後に通信できなくなった場合は、サブスクリプションをすべて削除するのではなく、まずシステムプロキシとコアの状態を確認してください。

macOSのインストールと権限の設定

チップに合ったインストーラーを選ぶ

「このMacについて」でチップまたはプロセッサ情報を確認してから、macOSのダウンロードページに進みます。Apple Silicon搭載機では対応するarm64版、Intel搭載機ではx64版を選んでください。互換実行を標準のインストール方法と考えず、まずはMacに合ったネイティブ版を使います。ダウンロードしたディスクイメージを開き、同梱の説明に従ってv2rayNをアプリケーションフォルダーに移動してから起動してください。マウントしたディスクイメージから長期間直接起動するのは避けましょう。更新やパスへのアクセス、終了後の再起動で混乱が生じやすくなります。

初回起動時は、まずシステムの警告を確認してください。ダウンロード元の制限によって起動できない場合は、ファイルの入手元を確認したうえで、システムの「プライバシーとセキュリティ」画面から該当する警告に対処します。アプリを起動するために、システム全体のセキュリティ機能を無効にしないでください。ファイルの破損、アーキテクチャの不一致、コンポーネントの読み込み失敗が明示された場合は、ダウンロード元、システム要件、インストール手順を見直します。任意のターミナルコマンドで無理に回避しないでください。クライアントのウィンドウが開いた後は、コアも正常に起動するか確認します。画面が表示されただけでは、コアの動作確認にはなりません。

グループを作成し、現在のネットワークを確認する

「订阅分组设置」に別名と「可选地址 Url」を入力して保存し、サブスクリプションを更新します。初回の更新は、まずプロキシを経由しない方法で試してください。URLへのアクセスに既存の接続が必要な場合は、その接続が使えることを先に確認してから、プロキシ経由で更新します。認証ページが表示されても、そのWebページの内容をサブスクリプションファイルとして保存しないでください。更新後に使用するサーバーを選び、真の接続遅延をテストして、ログに認証エラーやハンドシェイクエラーが連続していないことを確認します。UIの言語やメニューの位置はバージョンによって異なる場合がありますが、サブスクリプションURL、グループ、更新方法の関係は変わりません。

システムプロキシが必要な場合は、クライアントに自動設定させてから、システム設定で現在使用中のネットワークサービスを確認します。Wi-Fi、有線LAN、その他のネットワークサービスは、それぞれ別のプロキシ設定を持つ場合があります。ネットワークを切り替えた後は、実際に使っているサービスが正しいローカル待受ポートを参照しているか確認してください。クライアントが自動設定できない場合は、案内に従って権限を付与するか、ポートの種類を把握したうえで手動設定します。HTTPプロキシとSOCKSのポートは、名前だけで置き換えられるものではありません。まずクライアントの設定で待受プロトコルを確認し、システム側の対応する項目に入力してください。

アプリのプロキシ設定・権限・ネットワーク復旧を切り分ける

特定のアプリがシステムプロキシに従わない場合は、独自のネットワーク設定を使っていないか確認してください。コマンドラインアプリは、システムのGUI設定ではなく環境変数を参照する場合もあります。ターミナルとブラウザーで結果が異なっても、必ずしもサーバーの障害とは限りません。ブラウザー拡張機能で別のポートを指定しながら、システムプロキシでも同じ接続を確認するのは避けてください。まずテスト対象のアプリでプロキシ設定元を一つにして、直接接続とプロキシ経由の結果を比べます。出口を確認するときは、同じ宛先に同じ方法でリクエストしてください。キャッシュやアドレスファミリーの違いによる誤判定を防げます。

TUNを有効にする前に、ほかの通信制御アプリを終了し、使用中のクライアントの案内に従って権限やコンポーネントの要件を満たしてください。デスクトップUIにスイッチが表示されていても、実行に必要な条件がすべて整っているとは限りません。スリープから復帰して接続に問題が起きた場合は、いったん接続を停止して再開し、デフォルトルートとDNSが復旧しているか確認します。ネットワークを切り替えた後は、使用中のサーバーを再テストしてください。アプリをアンインストールまたは移動する前に、TUNを無効にし、システムプロキシを解除して、正常に終了します。アプリを削除した後もネットワークに問題が残る場合は、システム設定で残ったプロキシ項目を削除し、ほかのネットワークサービスも確認してください。システム全体のネットワークをむやみにリセットしないでください。

Linuxのインストールとデスクトップ環境の違い

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

使用しているディストリビューションのパッケージ形式を確認してから、Linuxのダウンロードページでv2rayNを選びます。debとrpmは異なるパッケージ管理方式に対応し、x64とarm64はプロセッサのアーキテクチャを示します。両方を一致させてください。ダウンロードできたからといってインストールできるとは限りません。また、ある形式のファイル名を別の形式に変えただけでは使えません。ディストリビューションのGUIソフトウェアインストーラーでファイルを開き、依存関係と権限の案内を確認してください。依存関係が不足していると表示された場合は、ディストリビューションの公式リポジトリから追加します。不明な配布元のコンポーネントを寄せ集めないでください。

次の読み取り専用コマンドをターミナルで実行すると、マシンのアーキテクチャとシステム情報を確認できます。一般にx86_64はx64、aarch64はarm64に対応しますが、最終的にはパッケージの説明とディストリビューションの対応状況を確認してください。インストール後はアプリメニューから起動し、ディスプレイ環境、ランタイム、実行権限に関するエラーがないか確認します。リモートターミナル、GUIのないサーバー、通常のデスクトップセッションは、それぞれ実行環境が異なります。このページではデスクトップ向けGUIクライアントを扱い、GUIアプリをヘッドレス環境のサービスとして使う方法は説明しません。

uname -m
cat /etc/os-release

サブスクリプションを取り込み、デスクトップのプロキシを確認する

「订阅分组设置」を開いてグループを追加し、サブスクリプションURLを保存します。更新後に使用するサーバーを選び、まず真の接続遅延をテストしてください。コアが実際のリクエストを処理できると確認してから、デスクトップのプロキシを設定します。更新に失敗した場合は、アプリ自体がネットワークに接続できないのか、サブスクリプションURLに到達できないのか、取得した内容を解釈できないのかを切り分けてください。システムのソフトウェアインストーラーがネットワークに接続できても、クライアントが同じ経路で通信するとは限りません。環境変数やネットワーク設定が異なる場合があります。根拠となるエラーがないまま、パッケージ形式を何度も切り替えないでください。

Linuxでは、システムプロキシがすべてのアプリに共通する設定とは限りません。デスクトップ環境やアプリによって、プロキシ設定の読み取り方が異なります。クライアントでシステムプロキシを自動設定した後、現在のデスクトップ環境のネットワーク設定で状態を確認してください。デスクトップのプロキシを参照しないアプリでは、アプリ独自の設定または一時的なプロキシ環境変数を使います。先にクライアントの待受ポートとプロトコルを確認してください。以下ではローカルの例示ポートを使い、HTTPプロキシを明示したリクエストを試します。実行前に、クライアントに表示されているポートへ置き換えてください。このテストはアプリの設定を切り分けるもので、システムプロキシを恒久的に変更するものではありません。

curl --proxy http://127.0.0.1:10809 --head https://example.com/

権限・コンテナ・終了後の復旧に対応する

通常のデスクトップ接続では、一般ユーザーのセッションを使ってください。TUNは仮想ネットワークデバイスへのアクセスとルートの変更を必要とします。具体的な権限付与の方法はクライアントやシステムによって異なるため、画面の案内に従ってください。手間を省くために、GUIアプリ全体を常に高い権限で起動するのは避けましょう。コアのログにデバイスがない、権限が不足している、ルートの追加に失敗したといった内容があれば、該当するシステム条件を解決してからサーバーをテストします。ポートが使用中の場合は、使用元を特定するか、待受ポートを変更してアプリ側の設定も合わせます。コアを何度も再起動するだけでは解決しません。

コンテナ、サンドボックス化されたアプリ、リモートセッションでは、127.0.0.1がデスクトップクライアントのネットワーク環境を指すとは限りません。プロキシを明示したリクエストに失敗した場合は、まずアプリとクライアントが同じネットワーク名前空間を共有しているか確認してください。すぐに待受アドレスを全ネットワークインターフェースに公開しないでください。LANからのアクセスが必要な場合は、ファイアウォール、認証、アクセス範囲も検討します。ログアウト、スリープ、デスクトップ切り替え後にプロキシ設定が残っていないか確認してください。正常に終了する前にデスクトッププロキシを解除し、TUNを停止します。アプリを更新するときは設定をバックアップし、インストール後に権限を再確認してください。以前の許可がそのまま有効とは限りません。

Androidのインストールとバックグラウンド接続

v2rayNGまたはv2flyNGを選ぶ

Androidのダウンロードページを開き、通常はXrayコアを使用するv2rayNGを選びます。V2Flyコアが明確に必要で、プロトコルの互換性も確認できている場合に限り、v2flyNGを選んでください。2つは同じアプリのテーマ違いではなく、インポート結果や対応プロトコルが完全に同じとは限りません。一般的なarm64端末では、対応するインストーラーを選びます。アーキテクチャが分からない場合はユニバーサル版を検討し、システム要件も確認してください。ユニバーサル版のファイルサイズが大きくても、プロキシ機能が多いとは限りません。アーキテクチャへの対応とプロトコルの機能は別の要素です。

インストール時はシステムの案内に従って、現在の入手元からのアプリインストールを許可します。インストール後に、その入手元への許可を取り消すこともできます。更新前にサブスクリプションURLと必要な設定を控えてください。署名の不一致などのインストール競合が起きた場合は、案内を確認し、ローカルデータを失う可能性のあるアンインストールをすぐに行わないでください。インストール後にクライアントを開き、先にデータを取り込んでから接続します。サーバー一覧が表示されても、通信を制御する権限が取得できたとは限りません。初回接続時はシステムのVPN権限確認に応答してください。許可しなかった場合は、再度接続をタップして案内に従って許可します。

グループを取り込み、VPN接続を確立する

v2rayNGでサブスクリプショングループの設定を開き、別名とサブスクリプションURLを追加して保存した後、更新を実行します。UIのバージョンによっては、更新メニューが別の場所にある場合があります。「订阅分组」と「更新订阅」の項目を探してください。共有リンクが1件だけの場合は、クリップボードから設定を取り込む機能を使い、サブスクリプションURLの欄には入力しないでください。v2flyNGではメニュー名や配置が異なる場合があります。実際のサブスクリプション管理画面から操作し、別のクライアントのスクリーンショットと同じ位置にあるとは限らないことに注意してください。

使用するサーバーを選んで接続し、システムのVPN権限を許可します。VPNの状態表示は、アプリが提供する通信経路をシステムが確立したことを示すだけで、リモート側の認証成功までは保証しません。接続後にクライアントの真の接続テストを実行するか、ブラウザーで決めたテスト先にアクセスし、ログも確認してください。AndroidのVPNによる通信制御は、デスクトップのシステムプロキシとは異なります。通常、Wi-Fiの手動プロキシを別途設定する必要はありません。以前のWi-Fiプロキシ設定が残っている場合は、存在しないローカルポートを参照していないか確認してください。設定が重なると原因を特定しにくくなります。

アプリ別の通信・バックグラウンド動作・ネットワーク切り替え

アプリ別プロキシを有効にする前に、一覧の設定が「選択したアプリのみをプロキシ経由にする」のか、「選択したアプリを除外する」のかを確認してください。意味が逆のため、選択を誤るとブラウザーだけ、または特定のアプリだけが接続できなくなることがあります。一覧を変更した後は、クライアントの指示に従って再接続し、新しい設定をVPNに反映します。トラブル対処中は複雑なアプリ別ルールをいったん無効にし、全体の通信経路を確認してから、一つずつ戻してください。仕事用プロファイルとメインのユーザー領域には個別の制限がある場合があります。メイン領域で接続中と表示されていても、別領域のアプリが同じ経路を使うとは限りません。

画面ロック後に接続が切れる場合は、アプリのバッテリー設定、バックグラウンド動作の制限、システムのバックグラウンド終了設定を確認し、必要なバックグラウンド動作を許可してください。すべての省電力機能を一律に無効にするのではなく、切断時刻が画面ロックやプロセス終了と一致するかを確認します。Wi-Fiとモバイルネットワークを切り替えた後は、接続を再確立する必要がある場合があります。まず再接続し、サーバーアドレスの名前解決とハンドシェイクの結果を確認してください。システムVPNを使う別のアプリが現在の接続と競合する場合があるため、通信制御の経路は一つにしてください。クライアントを切り替えるときは、旧クライアントの接続を停止してから、新しいクライアントでグループを作成します。複数のアプリがVPN経路を取り合わないようにしてください。

サブスクリプショングループと更新方法

取得元ごとに情報と更新方法を管理する

異なる取得元は別々のサブスクリプショングループに登録します。別名は識別用なので、リモートサーバー名と一致させる必要はありません。「可选地址 Url」には完全なサブスクリプションURLを保存し、クエリパラメーターや大文字・小文字を変えず、末尾に説明文を加えないでください。コピーの際、チャットアプリが改行、空白、省略記号を挿入することがあります。tokenの途中を書き換えるのではなく、取り込み前にURLの先頭と末尾を確認します。サブスクリプションURLにはアクセス権情報が含まれる場合があるため、バックアップ、スクリーンショット、問い合わせの投稿では機密部分を隠してください。クライアント内のグループ名はリモートアカウントの権限を代替せず、サービスの有効期限も変更しません。

「更新全部订阅(不通过代理)」は、現在のネットワークからサブスクリプションURLへ直接アクセスできる場合に使います。「更新全部订阅(通过代理)」は、すでに使えるプロキシ経路が必要です。利用可能なサーバーがすべて使えない場合、後者では更新に必要な接続も確立できず、循環依存になることがあります。どちらか一方を常に正しい方法とせず、サブスクリプションURLに実際に到達できるかで選んでください。更新に失敗しても古い一覧は残し、まずエラーを確認してから接続経路を切り替えます。復旧に使える接続を失うおそれがあるため、最初からすべてのサーバーを削除しないでください。

自動更新・フィルター・リクエスト識別子を理解する

「自动更新间隔(分钟)」は更新チェックの間隔を指定しますが、実際の実行タイミングはクライアントの起動状態、タイマー、ネットワーク環境にも左右されます。サーバー側が設定どおりの時刻に更新を配信する保証ではありません。まず手動更新の成功を確認してから、提供元の制限に合った間隔を設定してください。極端に短い間隔で繰り返しリクエストしないでください。スリープ中やオフライン中に更新されなくても、必ずしも故障ではありません。ネットワーク復旧後に一度手動で更新できます。グループを無効にすると、そのグループが更新対象から外れることがあります。既存サーバーが残るかどうかはクライアントの動作によって異なるため、変更前にバックアップしてください。

「过滤(正则)」は、サブスクリプション内のサーバー名を絞り込む機能です。フィルター式でサーバーの実在性が変わることはなく、不足しているプロトコルパラメーターを補うこともできません。条件が厳しすぎると、更新に成功しても一覧が空になる場合があります。トラブル対処では、まずフィルターを解除して、元のサブスクリプションに認識可能なデータがあるか確認し、その後で簡単な条件を一つずつ追加します。「User-Agent」は、提供元から指定された場合や、応答形式との互換性が必要な場合にのみ変更してください。任意のクライアントを装うと、解析できないデータが返ることがあります。変更値の根拠を記録し、元に戻すときは既定のリクエスト動作に戻してください。

サブスクリプションデータと実行設定を区別する

サブスクリプションを更新するとサーバー情報が再生成されることがあり、生成されたサーバーを手動で変更しても、次回の更新で上書きされる場合があります。例外的な設定を残す必要がある場合は、クライアントに独立して保存する機能やカスタム設定があるか確認してください。上書きされる可能性のあるデータに変更を積み重ねないでください。グループを削除する前に確認メッセージを読み、関連サーバーも削除されるか確認します。移行時は、まずクライアントが対応する形式でバックアップを取り、その後にサブスクリプションURLを保存してください。一時的な実行設定をコピーしても、サブスクリプションとの関連付け、フィルター、アプリの設定まで完全に復元できるとは限りません。

以下は単体で解析できるXray JSONの例です。ローカルのSOCKSインバウンドと直接接続のアウトバウンドだけを設定しており、リモートプロキシへの接続は行わず、サブスクリプションデータでもありません。ノードを「修復」するために、クライアントが自動生成した設定と置き換えないでください。実際に使用するプロトコル、トランスポート、セキュリティレイヤー、サーバーパラメーターは一式で一致させる必要があります。設定の構造をさらに確認したい場合は、XrayとV2Flyコアの違いを読み、クライアントとプロトコルの互換性を確認してください。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct"
    }
  ]
}

システムプロキシ・TUN・ルーティング

通信の入口を選び、その後にアウトバウンドルールを設定する

システムプロキシ、TUN、ルーティングは別々の機能として理解してください。システムプロキシは、設定を参照するアプリにローカルポートへリクエストを渡すよう指示します。TUNは仮想ネットワークデバイスを使って、条件に合う通信を取り込みます。ルーティングルールは、コアに届いたリクエストをどのアウトバウンドへ送るかを決めます。それぞれが働く層は異なります。「全局」は通常、コアに入った後の既定のアウトバウンド方針を指し、すべてのアプリの通信がすでに取り込まれたという意味ではありません。そのため、システムプロキシで全局を選んでも、独自にネットワークへ接続する一部のアプリは直接接続することがあります。これはルーティング設定と矛盾しません。

ブラウザーとシステムプロキシに従うデスクトップアプリだけを使う場合は、まずシステムプロキシを使うと、通信の確認や復旧が容易です。システムプロキシを参照しないアプリも扱う場合は、TUNを検討してください。有効にする前に元のプロキシ設定を記録し、ほかの通信制御アプリを終了して、権限、仮想デバイス、関連コンポーネントが要件を満たしているか確認します。複数のクライアントで同時にTUNを有効にし、ルーティング変更で競合を解決しようとしないでください。有効化後に端末全体がネットワークへ接続できなくなった場合は、まずTUNを無効にしてネットワークを復旧し、ログを確認します。基本的な接続を失った状態でDNS設定を次々に変更しないでください。

DNS・ドメイン判定・ルールの順序を確認する

ルーティングの判定には、クライアントが実際に取得した宛先情報が使われます。HTTP、SOCKS、TUN、アプリの種類によって、ドメイン名が渡される場合もIPアドレスだけが渡される場合もあります。すべてのリクエストがドメインルールに一致するとは限りません。ドメイン判定のAsIsは、ルーティング判定のためにドメインを追加で解決しません。IPIfNonMatchは、ドメインルールに一致しない場合に名前解決を試み、IPルールの判定を続けます。IPOnDemandは、IPが必要なルールを判定するときに名前解決を行います。判定方式を変えると名前解決のタイミングは変わりますが、利用できないDNSサーバーが自動的に直るわけではありません。

ルールの順序は通常、判定結果に影響します。最初に一致したルールが処理方法を決めます。プライベートアドレスの直接接続ルールを適切な位置に設定すると、LAN上のリソースがリモート経由になるのを防げます。ただし、アクセス範囲はアプリの用途に合わせて確認してください。geosite:cnやgeoip:privateなどの記述は、対応するルールデータとコアのサポートが必要です。アウトバウンドのタグも、設定内に存在するタグと一致させてください。対応するアウトバウンドがない状態で「proxy」という文字列だけをコピーしても、接続は作成されません。変更後は生成された設定またはログを確認し、画面に保存されただけでなくルールが読み込まれていることを確かめてください。

通信の取り込みを確認し、復旧手段を残す

確認するときは、使用中のサーバーとテスト先を固定します。クライアントで真の接続遅延をテストし、次にブラウザーから同種の宛先へアクセスして出口を確認してください。コマンドラインアプリは、プロキシを明示したリクエストを比較用に使えます。明示プロキシでは成功し、通常のリクエストでは失敗する場合は、まずアプリがどのプロキシ設定を参照しているか確認します。どちらも失敗する場合は、コア、サーバー、ルーティングを調べてください。IPv4とIPv6で異なる経路が使われることがあります。出口の結果が一致しない場合は、すべての通信がプロキシを迂回していると決めつけず、アドレスファミリーを切り分けてください。詳しい確認方法は、システムプロキシの設定と真の接続遅延テストをご覧ください。

復旧時は有効にした順序と逆に操作します。TUNを停止し、システムプロキシを解除してから、クライアントを正常に終了してください。プロキシ環境変数やアプリ独自のプロキシ設定を手動で変更した場合は、それぞれ元に戻します。クライアントを終了しても、各アプリに保存された設定までは自動で変更されません。LAN上の機器、リモートデスクトップ、職場のネットワークはルーティング変更の影響を受けやすいため、変更前にローカルへアクセスする経路を確保してください。特定のアプリを接続させるために、待受アドレスをすべてのネットワークインターフェースへ公開しないでください。プロキシを共有する必要がある場合は、ローカルネットワーク向けの設定をそのまま流用せず、アクセス制御とファイアウォールを別途検討します。

設定のよくある質問とログの確認方法

起動・サブスクリプション・接続の順に切り分ける

最初に失敗した層から確認します。画面が開かない場合は、インストール、アーキテクチャ、実行環境を調べます。画面は正常でもコアが起動しない場合は、ログでポートの競合、設定の解析エラー、権限を確認してください。コア起動後にサブスクリプションの取得に失敗する場合は、URL、リクエスト経路、応答内容を確認します。サブスクリプションを取得できても接続できない場合に、プロトコル設定とサーバーへの到達性を調べます。すべての判断を再インストールに置き換えないでください。再インストール後も元の設定が残る場合があり、調査に役立つエラー情報を失うこともあります。エラーの原文と発生時の操作を保存してから、必要最小限の変更を行ってください。

ログのエラーは前後の記録と合わせて確認します。address already in useは通常、ローカルの待受ポートが使用中であることを示し、リモートサーバーが接続を拒否したという意味ではありません。JSONの解析に失敗した場合は、該当フィールド、カンマ、データ型を確認します。不明なプロトコルや未対応フィールドが表示された場合は、使用中のコアがその設定をサポートしているか確認してください。クライアントが自動生成するファイルは、再起動時に上書きされる場合があります。まず画面上の元設定を修正してください。コアの起動失敗と設定エラーの対処方法も参考にして、設定生成の問題と実行環境の問題を切り分けましょう。

証明書・認証・ネットワークのタイムアウトを切り分ける

TLSエラーが発生した場合は、まずシステム時刻を確認し、サーバーアドレス、SNI、証明書のドメイン名の関係を調べてください。接続先アドレスと証明書の検証名が異なる構成もありますが、サービス提供元の設定に合っている必要があります。よく使われるWebサイトのドメイン名に任意で変更しないでください。証明書検証のスキップを日常的な対処法にすると、名前の不一致や信頼チェーンの問題を隠してしまいます。REALITYなどの設定では、公開鍵、short ID、サーバー名、その他のパラメーターを提供元の案内どおり一式で取り込んでください。別のサーバー設定から項目を寄せ集めないでください。詳しくは時刻同期とSNIエラーの解説をご覧ください。

タイムアウトは、ある待機処理が時間内に完了しなかったことを示します。ドメイン名の解決、接続の確立、ハンドシェイク、宛先へのリクエストのどの段階で発生したかをログで確認してください。接続拒否とタイムアウトも別の状態です。前者は宛先ポートでサービスが動作していない可能性があり、後者はネットワーク経路やリモートからの応答が関係している場合があります。まず、既知の別サーバーと比較してから、ネットワークを変えて試します。すべてのプロトコル設定を一度に変更しないでください。同じ時間にすべてのサーバーで失敗する場合は、サブスクリプション全体の無効化と決めつける前に、ローカルに残ったプロキシ設定、DNS、公衆ネットワークのログイン状態、コアの動作を確認してください。

再現に必要な情報を残し、段階的に設定を戻す

問い合わせる際は、OS、プロセッサのアーキテクチャ、クライアント名、通信の取り込み方法、失敗した操作、機密情報を隠したログの抜粋を記録してください。サブスクリプションURL全体、認証情報、機密パラメーターを含む設定ファイルを公開しないでください。「サブスクリプションの更新に失敗する」のか「ブラウザーでページを開けない」のかを明記すると、「使えない」とだけ書くより原因を絞り込みやすくなります。画面ロック後、ネットワーク切り替え後、特定のアプリだけで起きる場合は、その条件も記載してください。復旧後にフィルター、アプリ別設定、DNS、カスタムルーティングを一つずつ戻し、その都度確認します。問題を再発させないよう、一度に複数の設定を追加しないでください。

問題の種類に応じた情報はFAQをご覧ください。最小構成から設定し直す場合は、サブスクリプションの取り込み手順に戻ってください。復旧後は、動作する設定とテスト記録を保存します。次回のトラブルでは、すべてを最初から設定し直すのではなく、変更点を比較してください。