INSTALL / SUBSCRIPTION / ROUTING

V2Ray クライアントの全プラットフォーム導入・設定ガイド

デスクトップはv2rayN、Androidはv2rayNGの導入と設定を解説。プラットフォーム別の手順と通信経路から問題を確認できます。

このページは必要な箇所を調べるためのガイドです。最初から最後まで読む必要はありません。初回接続はクイックスタートガイドに沿って進め、インストール、権限、ルーティング、DNSで問題が起きたら該当する章を確認してください。クイックスタートでは接続までの手順を、本ページでは各設定がどの階層に作用するかを説明します。

共通の準備：インストールパッケージ、設定、通信の取り込み範囲

クライアントとデバイスのアーキテクチャを確認

デスクトップではv2rayN、AndroidではXrayコアを使用するv2rayNGがおすすめです。V2Flyコアが必要な場合はv2flyNGを検討してください。クライアントは設定の編集、サブスクリプションの管理、コアの起動を担当し、実際の接続はコアが処理します。両者は異なる階層の機能です。クライアントを変えると画面や通信の取り込み方法は変わりますが、サーバー設定の誤りが自動で直るわけではありません。インストール前にOS、プロセッサのアーキテクチャ、プロキシを使うアプリを確認しておくと、適切なパッケージを選べます。

Windowsではx64のデスクトップパッケージが一般的です。macOSではApple SiliconとIntelを、Linuxではプロセッサのアーキテクチャとパッケージ形式の両方を確認してください。Androidの多くの端末ではarm64を選び、アーキテクチャが不明な場合は汎用版を検討します。OSが64ビットでも、プロセッサのアーキテクチャが特定の種類とは限りません。システム情報に表示されるプロセッサの種類を確認し、ダウンロードページから該当するパッケージを選んでください。別のプラットフォーム向けパッケージを、ファイル名だけ変えて使うことはできません。

接続情報を準備する。サンプルのアドレスは接続に使えません

クライアントをインストールしただけでは接続できません。有効なサブスクリプションURL、共有リンク、または手動設定用の接続情報が必要です。サブスクリプションは通常、ノード一覧を返すWeb形式のURLです。共有リンクは一般にプロトコル名で始まり、単一の設定を表します。本サイトではクライアントの操作方法を紹介します。接続情報は、利用権限のあるサービスから入手してください。サーバーアドレス、ポート、ユーザーID、通信方式、安全設定はいずれも接続に必要な情報です。一つでも欠けると、インポートできてもハンドシェイクに失敗することがあります。

サブスクリプションを保存する際は、「仕事用」「テスト用」など用途がわかるグループ名を付けてください。名前は端末内のメモであり、接続動作には影響しません。共有するスクリーンショットには、サブスクリプションURL、ユーザーID、QRコードを表示しないでください。これらの情報から接続権限を取得されるおそれがあります。本文中のドメインや設定項目は構造を説明するための例であり、接続可能なサービスではありません。サンプルをクライアントに入力して接続を待つのは、役に立たない作業を増やすだけです。

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

システムプロキシは、OSにローカルプロキシのアドレスを登録する設定です。設定を参照するアプリはリクエストをクライアントに送りますが、すべてのアプリに強制できるわけではありません。独自のネットワークスタックを使うアプリ、一部のコマンドラインツール、個別にプロキシを設定したアプリなどは対象外になることがあります。TUNは仮想ネットワークインターフェースで通信を受け取るため、通常はより広い範囲を取り込めますが、権限が必要で、ほかの仮想ネットワークアダプターと競合することもあります。ルーティングは、コアに入った通信をプロキシ経由、直接接続、または遮断のいずれにするか決めます。

初回の設定では、まずシステムプロキシでブラウザーの接続を確認し、その後必要に応じてTUNを有効にしてください。同じローカルポートを複数のクライアントで取り合ったり、複数の通信制御ツールでデフォルトルートを同時に変更したりしないでください。AndroidのVPNによる通信制御とデスクトップのシステムプロキシは仕組みが異なりますが、確認手順は同じです。まず通信がクライアントに届いているかを確認し、次にどの出口から送信されるかを調べます。ルーティングをグローバルに設定しても、コアに届いていない通信がログに現れることはありません。

元に戻せるテストの基準を作る

最初のテストでは、動作確認済みのノードを一つ選び、転送パラメーターは初期設定のまま、Muxは無効にします。その時点のルーティングモード、ローカルの待ち受けポート、通信の取り込み方法を記録し、一度に変更する設定は一つだけにしてください。証明書の有効期間を正しく判定するため、端末の時刻も合わせておきます。接続前に通常のネットワークが使えることを確認してください。Web認証が必要なネットワークでは、先に認証を済ませます。基礎となるネットワークに接続できていないと、サブスクリプションもノードもタイムアウトすることがあります。最初にルーティングを疑う必要はありません。

インストールやアップデートの前に、クライアントの設定とサブスクリプショングループをバックアップし、自分だけがアクセスできる場所に保存してください。バックアップにも機密性の高い接続情報が含まれるため、公開ドキュメントには置かないでください。問題が起きた場合は、エラーの種類、発生時刻、操作手順を記録しましょう。赤い文字だけの画面を撮影するより、原因の特定に役立ちます。以降のプラットフォーム別の章では、パッケージ選択、インストール、インポート、通信の取り込み、終了後の復旧という共通の流れで説明します。すでに利用環境がある場合は、違いを確認するだけでよく、初期設定をやり直す必要はありません。

Windows：v2rayNの導入とシステムプロキシ

デスクトップ版と従来のWPF版の選び方

ダウンロードページには、v2rayNのデスクトップ版と従来のWPF版があります。デスクトップ版は新世代のクロスプラットフォームUIを採用し、WPF版は従来のデスクトップ操作を引き継いでいます。初めて導入する場合はデスクトップ版を、WPF版に慣れている場合は引き続き該当するパッケージを選ぶとよいでしょう。メニューの位置はバージョンによって異なるため、この章では機能名を使って説明します。特定のボタン位置をすべての環境に共通する手順とはみなしません。一方の版のプログラムファイルを、もう一方の版のフォルダーに上書きしないでください。設定や依存ファイルが混在するおそれがあります。

Windowsのダウンロードページからパッケージを入手したら、実際の形式に応じてインストールまたは展開します。展開が必要なパッケージは、専用フォルダーにすべて展開してください。圧縮ファイル内のメインプログラムを直接起動する方法は避けます。パスが短く、現在のユーザーが書き込める場所を選ぶのがおすすめです。設定、ログ、コアの実行ではファイルへの書き込みが発生する場合があります。保護されたフォルダー、オンデマンド同期のフォルダー、一時フォルダーでは、起動後にリソースが見つからなくなったり、終了時に設定を保存できなくなったりすることがあります。

初回起動とランタイムの確認

起動したら、まずメインウィンドウが正常に表示されるか確認し、次にログにコアの起動エラーがないか確認してください。ウィンドウが開いたからといって、コアも正常に動作しているとは限りません。.NETランタイムが不足しているとシステムに明示された場合は、パッケージの説明に従って必要なランタイムを追加します。名前が似ているというだけで、手当たり次第にコンポーネントをインストールしないでください。ランタイムを同梱するパッケージと、システムのランタイムに依存するパッケージでは要件が異なります。何度も再インストールするより、エラーメッセージを確認してから対処するほうが効率的です。

セキュリティソフトがコアをブロックした場合は、対象ファイルがインストールしたクライアントのパッケージに含まれていることを確認し、システムの保護履歴を確認してください。保護機能を一括で無効にして試すのは避けましょう。起動直後に終了する場合は、展開が完了しているか、フォルダーに書き込みできるか、別のプロセスが起動していないかを確認してから、アプリのエラーログを調べます。起動時の問題については、v2rayNの起動直後の終了・クラッシュへの対処も参照してください。この段階では接続パラメーターを変更する必要はありません。

サブスクリプションの追加と接続するノードの選択

「サブスクリプショングループ設定」でグループを追加し、名前とサブスクリプションURLを入力して保存します。メイン画面に戻り、「サブスクリプショングループ」メニューから「プロキシを使わずに更新」を実行してください。使用できるノードがまだない初回は、プロキシを使わない更新のほうが基準を作りやすいでしょう。サブスクリプションサイトへのアクセスに既存の接続が必要な場合は、「プロキシ経由で更新」を選びます。ただし、使用可能なノードがすでにあることが前提です。空のリストに、最初の設定をダウンロードさせることはできません。

更新後はノード一覧と所属グループを確認し、ノードを一つ選んでアクティブサーバーに設定します。行にフォーカスが当たっただけでは、接続先が切り替わっていない場合があります。クライアントに表示されるアクティブ状態を確認してください。共有リンクは「クリップボードから共有リンクをインポート」で追加し、サブスクリプションURL欄には入力しないでください。インポート後に項目が空になる場合は、元のリンクがチャットアプリで途中までしかコピーされていない可能性があります。特に末尾のパラメーターやパーセントエンコードを確認し、複雑に見える部分を安易に削除しないでください。

まずシステムプロキシを使い、必要に応じてTUNを有効にする

コアが正常に動作したら、「システムプロキシ」で「システムプロキシを自動設定」を選びます。現在の接続でアクセスする必要があるURLをブラウザーで開き、該当するリクエストがクライアントのログに記録されるか確認してください。ブラウザーでは使えるのに別のアプリで使えない場合は、そのアプリがシステムプロキシを参照しているか確認します。アプリによっては独自のプロキシ設定があり、ローカルのHTTPまたはSOCKSアドレスを指定する必要があります。ポート番号はクライアントの実際の設定を確認し、別のガイドにある初期値をそのまま使わないでください。

端末全体の通信を取り込む必要がある場合に限り、TUNを有効にしてください。通常は管理者権限または関連コンポーネントの初期化が必要です。詳細はクライアントの案内に従います。ほかのプロキシツールを終了し、仮想ネットワークアダプターによる通信制御が残っていないことを確認してから起動してください。TUNでエラーが起きてもシステムプロキシが使える場合は、問題が権限、ネットワークアダプター、システムルートにある可能性が高く、サーバーをすぐに変える必要はありません。テスト中にDNS、ルーティング、転送パラメーターを同時に変更すると、どの操作で復旧したのか判断できなくなります。

終了時の復旧とWindowsでよくある注意点

メインウィンドウを閉じても、タスクトレイに最小化されるだけの場合があります。通信の取り込みを停止するには、「システムプロキシ」で「システムプロキシを解除」を選び、TUNを無効にしてから、タスクトレイのメニューで終了してください。異常終了すると、停止したローカルポートをシステムプロキシが参照し続ける場合があります。その場合はWindowsのプロキシ設定を開き、手動プロキシのアドレスが残っていないか確認して削除します。まず通常の直接接続が復旧したことを確認してからクライアントを再起動してください。ブラウザー独自のプロキシ拡張機能も確認しましょう。システム設定を変更しても連動しないことがあります。

自動起動には、まずクライアントの設定を使い、現在のユーザーがログインした後に実際に起動することを確認してください。自動起動の設定が成功していてもTUNが起動しない場合、権限が異なることがあります。複数の起動項目を作って対処しないでください。アップデート前に旧プロセスを終了し、設定をバックアップします。アップデート後はシステムプロキシ、アクティブサーバー、ローカルポートを再確認してください。ポートが使用中の場合は、使用しているプロセスを特定するか、空きポートに変更し、アプリ側の設定も合わせて更新します。片方だけを変更しないでください。

macOS：チップに合ったパッケージ、ネットワーク権限、通信の取り込み

チップに合わせてv2rayNをインストール

「このMacについて」を開き、チップ名とIntelプロセッサのどちらが表示されるか確認してください。Apple Siliconではarm64、Intelではx64のパッケージを選びます。パッケージはチップのアーキテクチャで選ぶもので、システムの表示言語や画面サイズは関係ありません。macOSのダウンロードページから該当するディスクイメージを入手し、開いたウィンドウの案内に従ってアプリを「アプリケーション」フォルダーに移動します。ディスクイメージやダウンロードフォルダーから長期間実行すると、アップデート、自動起動、パスの権限に問題が生じることがあります。

初回起動時にセキュリティ確認が表示されたら、アプリの提供元と、ダウンロードしたクライアントのファイルであることを確認し、システムの「プライバシーとセキュリティ」の案内に従ってください。アプリを起動するためにシステム全体のセキュリティ機能を無効にしたり、出所不明の制限解除スクリプトを実行したりしないでください。アーキテクチャの不一致がエラーに示された場合は、ダウンロードページで適切なパッケージを選び直します。変換実行が可能かどうかはビルドによって異なるため、誤ったパッケージを選んだときの確実な解決策とは限りません。

サブスクリプションを追加してコアの動作を確認

「サブスクリプショングループ設定」を開き、名前とURLを追加して保存したら、サブスクリプションを更新します。アクティブノードがない場合は、まずプロキシを使わずに更新してください。既存のノードがあり、サブスクリプションへのアクセスにプロキシが必要な場合は、プロキシ経由で更新します。リストが表示されたらアクティブサーバーを選び、コアの起動情報がログに記録されているか確認してください。GUIの表示、サブスクリプションの取得、ノードへの接続はそれぞれ別の動作です。前の2つが成功しても、接続できたとは限りません。

共有リンクを手動で追加する場合は、「クリップボードから共有リンクをインポート」を使います。クリップボードには完全なリンクだけを入れ、説明文やチャットの引用記号を混ぜないでください。インポート後はアドレス、ポート、通信方式、TLS関連の項目を確認します。パスワード管理ツールや別のアプリがクリップボードを自動消去することがあります。リンクを認識できない場合は、コピーし直してからインポートしてください。同じアドレスをサブスクリプショングループに何度も登録しても、インポートエラーは解消しません。重複グループは後の更新をわかりにくくします。

システムプロキシと使用中のネットワークサービス

まずv2rayNの「システムプロキシ」で自動設定を有効にし、ブラウザーで接続を確認します。macOSのプロキシ設定はネットワークサービスに関連付けられています。Wi-Fi、有線、別のネットワークインターフェースに切り替えると、使用中のサービスが変わる場合があります。ネットワークを切り替えた後に接続できなくなったら、システムの「ネットワーク」設定で現在のサービスのプロキシ項目を確認し、クライアントから設定を再適用してください。確認するのは現在使用中のサービスです。一覧にある過去の接続先を適当に選ぶのではありません。

アプリが独自のプロキシ設定を使っている場合もあります。片方のブラウザーは使えるのに別のアプリで失敗する場合は、後者がシステムプロキシを参照しているか確認し、必要に応じてローカルのHTTPまたはSOCKSの受け口を設定してください。手動で入力する場合は、クライアントが実際に待ち受けているアドレスとポートを使います。通常、ローカルアドレスにはループバックアドレスを指定します。リモートサーバーのアドレスではありません。リモートノードのポートをアプリのローカルプロキシ欄に入力すると、クライアントのプロトコル処理を経由せず、接続待ちが続くことがあります。

TUNの権限とネットワーク切り替え

TUNはシステムプロキシを参照しない通信を取り込むために使います。有効にする前に、使用中のビルドがこの機能に対応していることを確認し、クライアントが求める権限の設定を済ませてください。権限昇格の確認が表示された場合は、適用範囲を読んでください。システムパスワードを設定ファイルやスクリプトに書き込んではいけません。初回の有効化では、動作確認済みのアクティブノードと初期ルールを維持し、通信の取り込み方法だけを変更します。TUNが使えずシステムプロキシが動作する場合は、システムプロキシに戻して作業を続け、仮想インターフェースの初期化と権限の記録を確認してください。

ほかのVPN、ネットワークフィルタリングソフト、仮想マシンのネットワーク機能がルーティングに影響する場合があります。調査中は通信を制御するツールを一つだけ一時終了し、問題が解消するか確認してください。すべてを同時に再起動するのは避けます。スリープからの復帰やネットワークの切り替えで、古い接続やインターフェースの状態が無効になることもあります。まずクライアントの接続を停止して再起動し、セッションを再作成します。まだ問題があればTUNを再度有効にしてください。復帰直後に設定全体を削除する必要はありません。

終了、アップデート、システム設定の復旧

終了前にシステムプロキシを解除し、TUNを無効にして、直接接続が復旧したことを確認してからアプリを終了してください。異常終了後にネットワークへ接続できない場合は、現在のネットワークサービスが、待ち受けを停止したローカルプロキシを参照していないか確認します。プロキシアドレスが残っていると、ほかのアプリは停止済みのローカルポートへ接続し続けます。これはネットワーク自体が突然故障したわけではありません。残留プロキシを解除してもアクセスできない場合は、ほかの通信制御ツールとシステムDNS設定を階層ごとに確認します。問題をまとめて解決しようと、複数の設定を一度にリセットしないでください。

アップデート前にグループと設定をバックアップし、実行中のアプリを終了してからプログラムを置き換えます。ログイン後の自動起動に失敗する場合は、システムの「ログイン項目」とクライアントの自動起動設定が競合していないか確認し、明確な起動方法を一つだけ残してください。アプリを削除する場合は、先に通信の取り込みを解除します。アプリをゴミ箱に移動しただけでネットワーク設定がすべて復旧するとは限りません。設定フォルダーを削除する前にデータをエクスポートしてください。特に手動で作成したノードは、サブスクリプション更新では復元できません。

Linux：パッケージの導入、デスクトッププロキシ、自動起動

パッケージ形式とアーキテクチャを個別に確認

Linuxのデスクトップではv2rayNがおすすめです。UbuntuやDebianでは通常deb、FedoraやopenSUSEでは通常rpmを選びます。x64とarm64のどちらに該当するかも確認してください。パッケージ形式が合っていても、アーキテクチャが違えば実行できません。Linuxのダウンロードページから該当するパッケージを選び、debの拡張子だけ変えてrpmとして使うことは避けてください。ディストリビューション名、パッケージ形式、プロセッサのアーキテクチャは別々に確認する必要があります。デスクトップのテーマだけを見てディストリビューションを判断しないでください。

この章ではGUIインストーラーを使って説明します。ダウンロードしたパッケージを開き、アプリ名、依存関係の案内、インストール先を確認してから、システムの指示に従って権限を許可してください。依存関係が不足している場合は、ディストリビューション標準のパッケージ管理ツールで追加します。別のディストリビューションの共有ライブラリをシステムフォルダーにコピーしないでください。旧バージョンがある場合は、プロセスを終了してからアップデートします。メニューにアプリのアイコンが表示されても、起動できるかどうかは別途確認が必要です。

初回起動とフォルダーの権限

アプリメニューからv2rayNを起動し、メイン画面とコアのログを確認してください。GUIアプリは通常のユーザーで実行します。権限エラーを避けるために、クライアント全体を管理者権限で常時実行しないでください。設定、キャッシュ、ログは現在のユーザーのデータです。実行ユーザーを変えると別のフォルダーが使われ、「ノードがすべて消えた」「設定を保存できない」と誤解することがあります。まずユーザーフォルダーに書き込みできるか確認し、次にアプリ自体の問題かどうかを調べます。

アイコンをクリックしてもウィンドウが開かない場合は、デスクトップランチャーが正しいプログラムを指しているか、インストール時に依存関係が不足していないかを確認し、システムのアプリケーションエラー情報も調べてください。GUIコンポーネント、動的ライブラリ、ディスプレイ環境が不足している場合、プロキシ設定はまだ関係ありません。デスクトップセッションのないサーバーは、この章で説明するLinuxデスクトップ環境とは異なります。GUIクライアントにはデスクトップ環境が必要です。端末しか使えないマシンにデスクトップ向けの手順をそのまま適用することはできません。

設定の追加とシステムプロキシの適用範囲

正常に起動したら、「サブスクリプショングループ設定」にURLを保存し、プロキシを使わずに更新してアクティブサーバーを選びます。サブスクリプションの更新と接続テストは分けて確認してください。リストが表示されたのは設定を取得できたというだけで、実際の接続には通信方式と安全設定の確認が必要です。単一の共有リンクはクリップボードからインポートし、元のリンクも確認用に残しておきます。更新後に同じ名前のノードが複数ある場合は、グループとサーバーの項目で判別し、表示名だけで重複を判断しないでください。

「システムプロキシを自動設定」を有効にしたら、まずデスクトップブラウザーでテストします。デスクトップ環境によってシステムプロキシの参照方法は異なります。デスクトップの設定を使うアプリもあれば、環境変数や独自のプロキシ欄を使うアプリもあります。ブラウザーでは使えるのにターミナルのプログラムで使えない場合、通信の入口が異なるだけかもしれません。すぐにTUNを有効にする必要はありません。ルーティングを「グローバル」にしても、すべてのアプリを自動で取り込めるわけではありません。まず対象アプリがどのプロキシ設定を参照するか確認してください。

プロキシを手動で設定する場合は、アプリにクライアントのローカル待ち受けアドレスとポートを入力し、HTTPとSOCKSの種類も確認します。クライアントのポートを変更したら、アプリ側も合わせて変更してください。複数の設定ファイルに古いポートを残さないようにします。環境変数はシステムまたはアプリの環境設定で確認できます。クライアントを終了してもローカルプロキシを参照する環境設定は残るため、別途復旧が必要です。デスクトップの「システムプロキシを解除」では、独自の設定まで変更できないことがあります。

TUN、権限、ディストリビューションによる違い

TUNは仮想インターフェースとシステムルートを使うため、通常は追加の権限またはクライアント提供の補助機能が必要です。現在のビルドの案内に従って初期化してください。内容がわからない権限コマンドを必須手順とみなして実行しないでください。有効化時に権限エラーが出た場合は、まず許可手順が完了しているか確認し、次にディストリビューションのセキュリティポリシーとログを調べます。セキュリティモジュールが特定の操作を拒否している場合もあります。セキュリティ機能全体を無効にするのではなく、拒否された操作を特定してください。

ファイアウォール、ほかのVPN、仮想マシンのネットワーク機能はTUNに影響することがあります。テスト前にほかの通信制御ツールを終了し、ローカルの待ち受けポートが別のプロセスに使われていないことを確認します。ネットワークを切り替えた後、直接接続はできるのにTUNだけが動かない場合は、通信の取り込みを再起動してルートを更新してください。ノードがシステムプロキシ経由で使える場合は、サブスクリプションを再インポートするのではなく、仮想インターフェースとルーティングを優先して確認します。一度に変更するのは一つだけにしてください。Linuxのエラーメッセージは具体的なことが多いため、最後まで確認する価値があります。

ログイン時の自動起動とアンインストール

デスクトップの自動起動とは、現在のユーザーがGUIセッションにログインした後にアプリを起動する設定です。PCの電源を入れただけで接続できるという意味ではありません。クライアントの自動起動設定か、デスクトップ環境の「自動起動するアプリ」の設定のどちらかを使います。両方は設定しないでください。アプリは自動起動してもTUNが起動しない場合は、二つ目の起動項目を追加するのではなく、権限の初期化とセッション環境を確認します。複数のプロセスがポートを取り合うと、安定していた設定が断続的に失敗するようになります。

アンインストールやアップデートの前にTUNを無効にし、システムプロキシを解除してプロセスを終了します。その後、ディストリビューションのパッケージ管理ツールでパッケージを操作してください。設定フォルダーはプログラムとは別に残ることがあるため、アンインストールしても接続情報が削除されるとは限りません。移行する場合は先に設定をエクスポートし、データを削除する場合は対象範囲を確認します。アンインストール後もネットワークに問題がある場合は、アプリ独自のプロキシ設定、環境設定、ほかの通信制御ツールを確認してください。削除済みのプログラムファイルだけを調べても解決しません。

Android：v2rayNGへの設定追加とVPNによる通信の取り込み

v2rayNGを選び、アーキテクチャに合ったものをインストール

AndroidではXrayコアを使用するv2rayNGがおすすめです。V2Flyコアを使うv2flyNGは代替候補です。どちらを選ぶかはアイコンや似た名前ではなく、設定で必要なコア機能を基準に判断してください。多くのAndroid端末ではarm64を選び、アーキテクチャが不明な場合は汎用版を検討します。Androidのダウンロードページから該当するパッケージを入手し、システムの案内に従ってインストールしてください。インストールを許可する場合は、ダウンロードやファイル管理に使うアプリだけを対象にします。インストール後、不要になった権限は取り消せます。

アップデート時に署名が一致しないと表示された場合は、すぐにアンインストールせず、旧パッケージと新しいパッケージが同じクライアント、同じ配布元のものか確認してください。アンインストールすると端末内のノードや設定も消えることがあるため、先にバックアップします。インストールに失敗する原因には、アーキテクチャの不一致、ストレージ不足、OSの互換要件などがあります。原因に応じて対処してください。v2rayNGとv2flyNGのアプリデータは別々です。もう一方をインストールしても、以前のサブスクリプションが自動で引き継がれることはありません。

サブスクリプションと共有リンクは別々に追加する

v2rayNGの「サブスクリプショングループ設定」でグループ名とサブスクリプションURLを追加して保存します。メイン画面に戻り、メニューから「サブスクリプションを更新」を実行してください。更新後、グループ内の設定を確認し、使用するノードをタップします。メニュー名や位置はビルドによって異なる場合がありますが、機能は同じです。グループには更新可能なURLを保存し、ノード一覧から接続に使う設定を選びます。グループを作成してもノードがすぐ表示されない場合は、まだ更新していないことがよくあります。保存に失敗したとは限りません。

単一の共有リンクは「クリップボードからインポート」で追加します。チャットアプリでは表示部分だけがコピーされて途中で切れることがあるため、リンク全体をコピーしてください。QRコードも設定のインポートに使えます。スキャン結果に完全な読み取り可能な情報が含まれているか確認します。QRコードやリンクに機密パラメーターが含まれている場合は、公開の問い合わせ用スクリーンショットに載せないでください。インポート後は通信方式、TLS、サーバー名を中心に設定項目を確認します。画面に設定が一件表示されても、項目がサーバー側の情報と一致するとは限りません。

VPNモードを許可してルーティングを選ぶ

VPNモードで初めて接続すると、システムの許可確認が表示されます。アプリが端末内にVPNインターフェースを作り、通信を受け取るための許可です。リモートサーバーへの接続成功を意味するものではありません。許可後にクライアントへ戻り、接続ボタンの状態とログを確認してから、実際にアクセスできるかテストします。AndroidではVPNによる通信制御を行うアプリを2つ同時に有効にできない場合がほとんどです。別のアプリに接続が切り替わったと表示されたら、使用するアプリを決めてください。複数のツールに通信制御を交互に奪い合わせないようにします。

「設定」でVPNモードとルーティングを確認します。通常の振り分けでは、まず「LAN内および中国本土のアドレスを除外」を使い、比較テストが必要なときだけ一時的にグローバルに切り替えてください。ルーティングが決めるのは、クライアントに入った通信の経路です。誤ったサーバーアドレスが直るわけではありません。通信の取り込み対象から除外されたアプリは、ルーティングをグローバルにしても自動でコアに入ることはありません。特定のアプリだけ接続できない場合は、まずアプリ別の振り分け設定を確認し、その後ルーティングを調べます。

デスクトップの「システムプロキシを設定」という手順を、AndroidのVPNモードにそのまま当てはめることはできません。Androidでは通常、システムのVPNインターフェースを通じてコアに通信を渡します。一方、デスクトップのシステムプロキシはアプリ側の設定参照に依存します。同じサービスに接続する場合は接続情報を移行できますが、通信の取り込み設定はプラットフォームごとに行う必要があります。ネットワークによっては、Webページを開いて認証を済ませる必要があります。クライアントを起動する前に認証しておかないと、VPNやサブスクリプションの更新がタイムアウトすることがあります。

バックグラウンド動作、バッテリー管理、ネットワーク切り替え

一定時間後に接続が切れる場合は、システムがバックグラウンドのプロセスを終了していないか確認してください。バッテリー最適化、バックグラウンド動作、自動起動の制限は端末によって名称が異なります。アプリ情報から確認し、このクライアントに必要な権限だけを変更してください。すべてのアプリに権限を広げる必要はありません。通知やフォアグラウンドサービスは接続の維持に役立ちますが、通知が表示されていてもリモートセッションが有効とは限りません。ネットワーク切り替え後は実際のアクセスで確認してください。

Wi-Fiからモバイルネットワークに切り替えると、接続を再確立する必要がある場合があります。まず接続を停止して再起動し、復旧するか確認してください。特定のネットワークだけで失敗する場合は、DNS、サーバーへの到達性、ネットワーク認証の条件を比較します。ネットワーク切り替えによる一度の切断を直すために、高度な設定をすべて有効にしないでください。基準を作りやすくするため、Muxは初期状態のまま無効にします。スニッフィングもルーティングの要件に応じて設定してください。高度な機能を増やせば安定するとは限りません。追加機能が増えるほど、確認する要因も増えます。

ローカルDNSと終了時の確認

ドメイン名へのアクセスで問題が起きたら、「ローカルDNS」などの設定を確認し、現在のルーティングとコアの動作を踏まえて名前解決の経路を調べます。設定項目はコアやクライアントのビルドによって異なるため、古いスクリーンショットにある値をすべてコピーしないでください。DNSサーバーには、現在のネットワークまたはプロキシ経路から到達できる必要があります。IPアドレスではアクセスできるのにドメイン名では失敗する場合、DNSを重点的に確認します。ただし、正しいホスト名やTLSを必要とするサービスもあるため、IPアドレスへの置き換えだけでは根本的な解決になりません。

終了するときは、まず接続を停止し、システムのVPNが解除されたことを確認します。v2flyNGに切り替える場合は、先にv2rayNGを停止し、対応する設定を再インポートしてから許可してください。以前の設定が同期されているとは限りません。アンインストール前にサブスクリプションと手動ノードをバックアップし、移行後はルーティングとアプリ別の振り分けを再確認します。インストールや接続に関する疑問はよくある質問も参照してください。問い合わせの際はOSのバージョン、クライアント名、機密情報を伏せたエラー情報を添えます。サブスクリプションURL全体を公開する必要はありません。

サブスクリプションと移行：URL、ノード一覧、端末内の編集

サブスクリプションURLとノードの接続先は別

サブスクリプションは設定一覧を取得するための入口で、ノードは一覧に含まれる実際の接続先です。サブスクリプションは通常のWeb形式のURLの場合がありますが、ノードにはプロトコル、サーバー、ポート、認証パラメーターが含まれます。サブスクリプションの更新では一覧を取得して解析するだけで、各サーバーへの接続テストは行いません。そのため「更新成功」と「ノードが使えるか」は別々に確認してください。共有リンクは通常、単一ノードの設定を表します。一時的な追加には向いていますが、サブスクリプションのように継続的に更新されるものではありません。サーバー側の情報が変わった場合は、新しいリンクが必要になることがあります。

サブスクリプションURLのクエリパラメーターは、アクセス認証に使われることがあります。ドメイン名とパスだけを残さないでください。末尾のパラメーターが欠けると、サーバーからエラーページ、ログインページ、空の内容が返される場合があります。ブラウザーでURLを開けても、クライアントが解析できるとは限りません。Webページとサブスクリプションデータは異なる形式です。アカウントページのURLではなく、サービス提供元が案内するクライアント用のサブスクリプションURLを使ってください。URLの見分け方は、共有リンクとサブスクリプションの違いも参考になります。

プロキシを使わない更新とプロキシ経由の更新

プロキシを使わない更新では、通常、現在のネットワークを使ってサブスクリプションを取得します。プロキシ経由の更新では、確立済みのローカルプロキシ接続を使います。最初のノードがない場合は、まずプロキシを使わない方法を試してください。失敗しても使用可能な接続がある場合は、次にプロキシ経由を試します。どちらも同じ設定一覧を取得する方法です。選ぶ基準はサブスクリプションサイトへの到達性で、どちらが必ず速いということではありません。既存の接続が不安定だと、プロキシ経由での更新によって問題が二つに増えることもあります。

更新に失敗したら、DNS名前解決、接続確立、TLSハンドシェイク、サーバー応答、内容の解析のうち、どの段階でエラーが起きたかを確認します。解析エラーはサブスクリプション形式でない内容が返される場合に、接続エラーはURLやアクセス経路に問題がある場合によく起きます。システム時刻のずれが安全な接続を妨げることもあります。同じグループを何度も新規作成しても、これらの条件は変わらず、重複記録が増えるだけです。既存のグループは残し、エラーの全体を一度記録してから、ネットワーク経路と応答内容を分けて確認してください。

グループ名と更新後の変化

提供元や用途ごとにグループを作り、見分けやすい名前を付けてください。更新後はノード数、名前、並び順が変わり、アクティブなノードを選び直す必要が生じることもあります。表示名は識別用のメモで、安定した識別子ではありません。同じ表示名でもアドレスやポートが異なることがあり、名前が違っても同じサービスを指すことがあります。選択時はプロトコルとサーバーの項目を確認し、一覧の順番を固定のものとみなさないでください。自動テストの結果は現在の環境での参考にとどめ、最終的には実際のアプリで接続を確認します。

サブスクリプションのノードをクライアント上で編集しても、次回の更新で変更が上書きされる場合があります。特殊な設定を長期的に維持したい場合は、別の手動設定欄にコピーして、変更理由を記録してください。サブスクリプション由来のノードを直接編集し、由来がわからなくなることは避けましょう。サーバーアドレスや認証情報が変わっても、コピーした設定には自動反映されないため、自分で管理する必要があります。サブスクリプションは手作業での更新を減らし、手動設定は個別の調整を維持します。自動更新と変更の完全な保持を同時に期待することはできません。

プラットフォーム間の移行で引き継ぐ設定

デスクトップからAndroidに移行する場合は、まずサブスクリプションURLを再登録し、移行先のクライアントに対応する形式で設定を生成させてください。単一ノードは共有リンクでも移行できます。あるプラットフォームの設定をすべてエクスポートして、別のプラットフォームにそのまま読み込むのは避けてください。ローカルポート、パス、システムプロキシ、通信の取り込み方法は共通ではありません。共通するのはプロトコルのパラメーターとサービス情報です。権限、インターフェース、バックグラウンド動作、アプリ別の振り分けはプラットフォームごとに再確認してください。

設定ファイルの移行は、コアの形式を理解している場合に適しています。XrayとV2Flyには共通する設定概念がある一方、対応するフィールドや機能には違いがあります。クライアントにプロトコル名が表示されていても、関連するすべての通信方式に対応しているとは限りません。移行後に未知のフィールドや非対応のセキュリティ方式が表示されたら、移行先のコアが対応しているか確認してください。エラーになった項目をむやみに削除しないでください。項目を削除すれば起動できても、接続の意味が変わり、起動時ではなくハンドシェイク時に問題が移ることがあります。

バックアップと機密情報を隠す方法

バックアップには、サブスクリプショングループ、手動ノード、重要なルーティング設定を含めます。自分で管理できる場所に保存し、元のクライアントとバックアップ日時を記録してください。異なるプラットフォームのファイルを同じフォルダーに混在させないようにします。復元前に移行先のクライアントがその形式に対応していることを確認してください。トラブルシューティング用にはバックアップの複製を作って機密情報を隠し、唯一のバックアップを直接編集しないでください。サブスクリプションは再登録できますが、手動設定したパラメーターはバックアップがないと画面の履歴から復元できないことがあります。

サブスクリプションの定期更新の前後に、アクティブノードを確認してください。特にサービス提供元が名前や一覧の構造を変更した後は注意が必要です。自動更新は接続を修復する機能ではなく、更新時刻もノードが正常である証明にはなりません。サブスクリプションが長期間読み取れない内容を返す場合は、提供元に対応するクライアント形式を確認してから、別のインポート方法が必要か判断してください。問題の解決後は、テスト用の重複グループを削除し、由来と用途が明確な設定を一つ残します。アップデート時に問題の発生箇所を特定しやすくなります。

ルーティングとDNS：通信の入口から出口まで確認

まず通信がコアに入っているかを確認

ルーティングが処理するのは、コアに入ったリクエストだけです。デスクトップアプリがシステムプロキシを参照していない、Androidアプリが通信の取り込み対象から除外されている、TUNが起動していない、といった場合は、ルールが正確でも実行されません。調査を始める前にリクエストログを確認し、対象アプリのアクセスが記録されているか見てください。記録がなければ、システムプロキシまたは通信の取り込み設定に戻ります。記録はあるのに出口が想定と異なる場合は、ルーティングを確認します。この順に調べると、入口の問題を振り分けルールの問題と誤認しにくくなります。

グローバルモードでは通常、受け取った通信をプロキシ経由の出口に送ります。バイパスモードではルールに従って一部の宛先を直接接続します。システムプロキシの切り替えとルーティングモードは別の設定です。前者は通信をクライアントに入れ、後者はどの経路に送るかを決めます。クライアント画面のモード名は具体的なルールに対応するため、仕組みを理解した後も実際に生成された設定を確認してください。階層ごとの違いはシステムプロキシとルーティングモードの解説も参照してください。

ルールの順序と出口のタグ

一般的なルーティングルールは上から順に照合され、最初に一致したルールが処理を決めます。特定のドメイン向けの詳細なルールは、広範囲に適用するルールより前に配置してください。そうしないと、後にある例外ルールが使われないことがあります。出口のタグは設定内で参照する名前で、プロトコル名ではありません。outboundTagを指定した場合、同じ名前の出口が必要です。タグの誤記は起動エラーや想定外の動作につながります。ドメイン一覧だけでなく出口の定義も確認してください。

以下は、XrayまたはV2Flyクライアントの設定に組み込めるルーティングの例です。完全な設定にdirectという名前の直接接続用出口があることを前提とします。ループバックアドレスとプライベートアドレスを直接接続に送り、それ以外は完全な設定のデフォルト出口で処理します。この例にはリモートサービスの情報は含まれておらず、単独で接続できる設定ではありません。プライベートアドレス向けのルールはローカルネットワークへの接続を維持するのに便利ですが、実際の環境で別の特殊なアドレス範囲が使われていないか確認してください。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "127.0.0.0/8",
          "10.0.0.0/8",
          "172.16.0.0/12",
          "192.168.0.0/16",
          "::1/128",
          "fc00::/7",
          "fe80::/10"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

domainStrategyとドメインの照合

AsIsは主に既存のドメイン情報を使って照合します。IPIfNonMatchはドメインルールに一致しなかった場合に名前解決を試み、IPルールを確認します。IPOnDemandは照合にIP情報が必要になった時点で名前解決します。これらはルーティングの照合段階での動作を表し、システムDNSの設定とは異なります。似た名前の項目でも、出口での名前解決とルーティング段階での名前解決を混同しないでください。変更後はドメインにアクセスできるかだけでなく、どのルールに一致したかも確認します。

ドメインルールのfull:は完全一致に、domain:は指定したドメインとそのサブドメインの照合に使います。通常の文字列とは動作が異なるため、すべて同じ書き方として扱わないでください。ルールデータファイルを使う場合は、コアがファイルを参照できることと、指定したカテゴリを認識できることも確認します。初回の導入では、手作業でルール一式を作るよりクライアント内蔵のルーティングを使うほうが簡単です。まず基準を作り、必要な例外だけを一つずつ追加してください。

DNSの名前解決場所と失敗時の切り分け

DNSはドメイン名をIPアドレスに変換します。名前解決のリクエストはアプリ、OS、コア、通信の取り込み機能のいずれから送信される場合もあり、具体的な場所は設定によって異なります。アプリがドメイン名をIPアドレスに変換してからプロキシに渡すと、コア側に元のドメイン名が残らないことがあります。その場合、IPルールは機能してもドメインルールには一致しないことがあります。スニッフィングで一部のプロトコルからドメイン名を補える場合もありますが、すべての通信から取得できるわけではありません。万能なドメイン復元機能として扱わないでください。

DNSサーバーには、選択した経路から到達できる必要があります。直接接続できないDNSサーバーを直接接続の経路に設定すると、「ノードは正常なのにドメインがタイムアウトする」ことがあります。まだ確立されていないプロキシにDNSを依存させると、起動時の依存関係が問題になる場合もあります。サーバーアドレス自体の名前解決と、接続先サイトの名前解決を区別し、循環依存がないか確認してください。DNSをテストする際は、使用中のネットワーク、通信の取り込み方法、キャッシュの状態を記録します。ネットワーク切り替え後に古いキャッシュが結果を隠すことがあるため、必要に応じて関連アプリを再起動してから再確認します。

スニッフィング、Mux、動作確認の方法

スニッフィングは主にドメインルーティングを補助し、Muxは接続を多重化します。両者は異なる問題に対処する機能です。Muxを有効にしても認証エラーは解決せず、すべての通信方式で安定性が向上するとも限りません。初回の導入では初期設定を維持し、多重化を無効にした状態で基準を作ってください。接続が安定してから必要に応じて試します。特定の機能を有効にしたときだけ切断される場合は、その設定を元に戻して再テストしてください。高度な機能は実際の用途に応じて使うもので、すべてのスイッチを有効にすることが完了条件ではありません。

JSONを編集するときは、カンマ、引用符、配列の構造に注意し、設定にコメントを追加しないでください。元のファイルを残して複製上で編集し、起動に失敗したらすぐに戻せるようにします。ノード切り替え時にクライアントが生成済みの設定を書き換える場合もあります。長期的に使うルールはクライアントのルーティング設定に保存し、一時的な出力を何度も編集しないでください。各項目の役割は設定ファイルの構造解説も参考にし、受け口、出口、ルーティングを分けて理解してください。

設定時によくある問題：発生段階から原因を特定

画面が開かない場合はノード接続の問題ではない

起動直後に終了する、ウィンドウが表示されない、システムにランタイム不足を指摘される場合は、アプリの起動段階での問題です。インストールパッケージのアーキテクチャ、インストールの状態、フォルダーの権限、実行環境を確認してください。この時点ではコアが接続設定を読み込んでいないこともあり、サブスクリプションを変更しても改善しません。Windowsではランタイムと展開先、macOSではアーキテクチャとシステムのセキュリティ通知、LinuxではGUIの依存関係とユーザーセッション、Androidではインストール要件とアプリデータの状態を確認します。

画面は開くのにコアが起動しない場合は、ローカルポートの競合、設定形式、コアの対応範囲を確認します。複数のクライアントを同時に起動するとポートを取り合うことがあり、終了していない旧プロセスが新しいインスタンスの待ち受けを妨げる場合もあります。不要なプロセスを停止し、待ち受けアドレスとポートを確認してから再試行してください。非対応のフィールドがエラーに示された場合は、現在のコアの対応状況とインポート形式を確認します。高度な項目をすべて削除して解決したと判断しないでください。接続動作が大きく変わることがあります。

サブスクリプションにノードはあるが接続がタイムアウトする

タイムアウトは、ある段階が想定時間内に完了しなかったことを示します。認証パラメーターの誤りとは限りません。まず通常のネットワークが使えることと、サーバーのドメイン名を解決できることを確認し、次にリモートアドレスとポートが現在も有効か調べてください。一つのノードだけタイムアウトし、ほかのノードは正常な場合は、そのサービスまたは設定を優先して確認します。同じネットワークで全ノードが失敗し、別のネットワークで復旧する場合は、ネットワーク環境と名前解決の経路を比較してください。サービスの稼働状況は提供元への確認が必要です。クライアントはタイムアウトの表示だけから具体的な原因を判断できません。

TLSエラーが出る場合は、端末の時刻、サーバー名、証明書の要件を確認してください。接続先のアドレスとTLSのサーバー名は異なる場合があり、それぞれ役割があります。接続先がIPアドレスだからといって、サーバー名までIPアドレスに変更しないでください。WebSocketのパス、Host、gRPCのサービス名など、通信方式に関するパラメーターはサーバー側の設定と一致させる必要があります。手動で項目を補うより、共有リンクをインポートするほうが確実です。手動設定が必要な場合は、元の情報を一つずつ確認し、画面の初期値を根拠なく使わないでください。

ブラウザーは使えるが、ほかのアプリでは失敗する

この場合は、まず通信の入口を確認してください。アプリがシステムプロキシを無視している、独自設定を使っている、Androidのアプリ別振り分けで除外されている、または現在の受け口に適さない通信を送っている可能性があります。クライアントのログに対象アプリのリクエストがあるか確認します。記録がなければアプリのプロキシ設定または通信の取り込み範囲を調整し、記録があればルーティングと出口を確認してください。TUNを使うと取り込み範囲を広げられますが、権限やルーティングの確認項目も増えます。システムプロキシで動作確認してから試してください。あらゆるアプリの問題に対する最初の対応として使うものではありません。

Webページのトップは開くのに一部のリソースが読み込めない場合、ドメインごとの違い、キャッシュされた接続、プロトコルの動作が関係していることがあります。失敗した宛先を記録し、別のルールで振り分けられていないか比較してください。ブラウザーのセキュアDNSや独自のプロキシ拡張機能が通信経路を変えていることもあります。テストでは、動作が明確な設定を一つだけ使います。長時間更新していないWebページだけで接続を判断しないでください。古いページやキャッシュ済みリソースが表示されても、新しいリクエストが成功した証拠にはなりません。再読み込みするか、新しいセッションでアクセスしてください。

クライアントを停止すると通常のネットワークも使えなくなる

まず、システムプロキシが残っていないか確認してください。OSがリクエストをローカルアドレスへ送っているのに、クライアントが待ち受けを停止していると、システムプロキシに従うアプリはすべて失敗します。先にシステムプロキシを解除し、次にTUNが停止しているか、ほかのVPNが通信を取り込んでいないか確認します。AndroidではシステムVPNの通信遮断設定も確認してください。直接接続が復旧してからクライアントを再起動します。終了時だけ問題が起きる場合は終了後の復旧手順を見直し、ノードの変更で対処しないでください。

ログに残す情報とテストで変更する設定

ログには発生時刻、操作手順、エラーの種類、関連する項目名を残します。最後の一行だけでは原因が抜けることがあるため、前後の数行も適切に含めると判断しやすくなります。ただし、サーバーの認証パラメーター、ユーザーID、サブスクリプションURL全体は必ず伏せてください。原因を調べる間だけログの詳細度を上げ、テスト後は通常のレベルに戻します。詳細ログを長期間記録するとデータ量が増えるおそれがあります。ログにアクセス先が含まれる場合もあるため、バックアップや共有の際はプライバシーに配慮してください。

簡単な比較表を作りましょう。同じノードがシステムプロキシとTUNの両方で使えるか、ネットワークを変えても同じ設定で使えるか、同じネットワークでノードを変えるとどうなるかを確認します。一度に変えるのは一つだけにし、結果を記録してください。ノード変更、DNS変更、スニッフィングの有効化を同時に行うと、成功してもどの操作が必要だったのかわかりません。有効な修正を確認したら、ほかのテスト用変更を元に戻し、動作に必要な最小限の設定だけを残します。安定性につながるのは、仕組みを説明できる設定です。考えられる項目をすべて順番に試すことではありません。

原因を特定できない場合は、クライアント名、OSとアーキテクチャ、通信の取り込み方法、問題が起きた段階、機密情報を隠したログを整理して、よくある質問の該当項目を確認してください。接続を最初から確認する場合は、クイックスタートガイドに沿って基本手順を試します。アップデートやパッケージの変更が必要な場合は、ダウンロードページで正しいプラットフォームを選んでください。再インストールは最後に検討する環境対処であり、設定パラメーターやサービスの状態を確認する代わりにはなりません。