クライアント、サブスクリプションURL、システム時刻を確認
設定を始める前に、インストール済みのクライアントと正常に使えるサブスクリプションURLを用意します。デスクトップでは v2rayN、Android では v2rayNG を使用します。クライアントをまだインストールしていない場合は、まずダウンロードページでOSに対応するバージョンを選んでください。インストール後は一度クライアントを起動し、既定の設定フォルダーと基本設定を作成してから、以下のサブスクリプション操作に進みます。
サブスクリプションURLは通常、ネットワークプロトコルで始まる完全なリンクです。コピーするときは最初の文字から最後の文字まで選択し、チャットアプリが付けた引用符、空白、改行を含めないでください。サブスクリプションURLは設定への入口なので、使用中のクライアント以外には保存しないようにします。URLが無効になっている、リセットされている、またはアクセスに必要なパラメーターが不足している場合、正しく操作してもサーバー一覧を取得できません。その場合はサブスクリプション提供元に戻り、URLの状態を確認してください。
端末の日付、時刻、タイムゾーンも確認してください。一部のプロトコルでは接続時に時刻情報を使うため、システム時刻のずれが大きいとハンドシェイクに失敗することがあります。まずシステムの時刻自動設定を有効にしてから操作を続けるのがおすすめです。パソコンでほかのプロキシクライアントも動作している場合は、システムプロキシ設定やローカル待ち受けポートの競合を避けるため、先に終了してください。一般的なローカル SOCKS ポートは10808ですが、実際の値は使用中のクライアント設定に従います。
サブスクリプションをインポートしてサーバー一覧を更新
v2rayN デスクトップクライアントにサブスクリプションを追加
v2rayN を開き、まず上部メニューにある「サブスクリプショングループ」などの項目から、サブスクリプショングループ設定に進みます。新しいサブスクリプションを登録するときは、見分けやすい名前を付け、完全なサブスクリプションURLをURL欄に貼り付けます。名前はローカルで識別するためだけのもので、接続には影響しません。一方、URLは変更せずそのまま入力する必要があります。保存してメイン画面に戻ったら、もう一度サブスクリプション関連のメニューを開き、「現在のサブスクリプションを更新」または「すべてのサブスクリプションを更新」を実行します。
更新が終わると、メイン画面のサーバー一覧に1件以上の設定が表示されます。一覧には通常、プロトコルの種類、アドレス、ポート、通信方式などの基本項目が表示されます。ここで設定を1項目ずつ書き換える必要はありません。用途が分からないままポート、ユーザー識別子、トランスポート層、セキュリティ設定を変更するのも避けてください。サブスクリプションはこれらのパラメーターを完全な設定としてクライアントに渡すためのものです。項目を手動で変更すると接続できなくなる場合があります。
更新後も一覧が空の場合は、まずサブスクリプショングループ設定に戻り、URLが途中で切れていないか確認します。そのうえで、実行したのが更新操作であり、サブスクリプション名の保存だけではないことを確認してください。ネットワーク環境によっては、「プロキシ経由で更新」と「直接更新」を選べる場合があります。初回設定で現在使える接続がない場合は、まず直接更新を試します。すでに使える接続があるものの新しいサブスクリプションへ直接アクセスできない場合は、状況に応じて現在のプロキシ経由で更新してください。
v2rayNG Android クライアントにサブスクリプションを追加
v2rayNG を開き、右上のメニューから「サブスクリプショングループ設定」または「サブスクリプション設定」に進みます。追加ボタンをタップし、名前とサブスクリプションURLを入力して保存したら、設定一覧に戻ります。続いて更新画面を開き、サブスクリプションを更新します。更新が完了すると、メイン画面に選択可能な設定が表示されます。空の一覧が表示されたままの場合は、選択中のサブスクリプショングループと、更新処理が完了していることを確認してください。
Android では、アプリのバックグラウンド通信が制限される場合があります。インポート中に長時間結果が表示されないときは、v2rayNG を前面に表示したまま、もう一度更新を実行してください。省電力設定が厳しい場合は、一時的にクライアントの通常のネットワーク通信を許可することもできます。重要なのは待ち時間ではなく、最終的に設定一覧を取得できたかどうかです。プロトコルとサーバーの項目が一覧に表示されれば、次の手順に進めます。
プロキシモードとルーティングルールを選択
クライアントがサーバー設定を取得したら、どの通信をプロキシ経由にし、どの通信を直接接続にするかを決めます。この判断は通常、2つの設定で行います。システムプロキシはアプリからクライアントへリクエストを送らせ、ルーティングルールはクライアント内部で direct または proxy の出口を選びます。名前は似ていますが役割は異なるため、まず判断しやすい基本構成を使い、接続成功後に細かく調整してください。
デスクトップではシステムプロキシを自動設定
v2rayN のメイン画面またはトレイメニューから「システムプロキシ」を開き、「システムプロキシを自動設定」を選びます。有効にすると、システムプロキシ設定を読み取るブラウザーやデスクトップアプリが v2rayN にリクエストを渡すようになります。ローカル SOCKS と HTTP の待ち受けポートはクライアントが管理するため、通常はブラウザーに同じ設定を入力する必要はありません。ブラウザーのプロキシを手動設定していた場合は、まずシステム設定に従う状態へ戻し、古いポートを参照し続けないようにしてください。
続いて「ルーティング設定」を開き、初回はクライアントが用意している一般的な振り分けプリセットを選びます。この種のプリセットでは、LANアドレスや一般的な中国本土向けリソースを直接接続にし、それ以外をルールに従ってプロキシへ振り分けることが多いです。ルーティングルールは順序とマッチ条件に依存するため、初回接続で多数のカスタムドメインを追加するのはおすすめしません。まず既定のプリセットが正常に動作することを確認し、その後必要に応じてrouting ルーティングルールリファレンスを参照してください。
Android でルーティングと対象アプリを確認
v2rayNG の設定から「定義済みルール」またはルーティング関連の項目を開き、普段使いに適した振り分けルールを選びます。特別な要件がなければ、まず一般的なプリセットを使用してください。次に「アプリごとのプロキシ」が有効か確認します。無効の場合は、接続確立後にシステムがその接続へ渡すアプリの通信が共通ルールで処理されます。有効の場合は、選択したアプリ、または除外リストに含まれないアプリだけがクライアントを経由します。初回の確認ではシンプルな設定を使い、テスト対象アプリの選択漏れによる誤判定を避けてください。
プロキシモードは接続品質を選ぶ設定ではありません。グローバル、振り分け、カスタムルーティングを切り替えても、誤ったサブスクリプションパラメーターが修正されたり、使えないサーバーが使えるようになったりするわけではありません。変わるのは通信の出口の選び方だけです。特定のアプリだけ正常で、別のアプリがクライアントをまったく経由しない場合は、サブスクリプションを何度も更新するのではなく、アプリごとの対象範囲、システムプロキシの読み取り方法、ルーティングの適用状況を先に確認してください。
アクティブサーバーを選んで接続を開始
プロキシモードの設定が終わったら、サーバー一覧に戻り、設定を1つ選んで現在のアクティブサーバーにします。サブスクリプションに複数の設定がある場合も、まずは1つだけで基本テストを行えば十分です。デスクトップでは通常、一覧項目をダブルクリックするか、右クリックメニューから「アクティブサーバーに設定」を実行します。選択すると、該当行の色、マーク、ステータス表示などが変わります。Android では設定項目をタップし、左側または右側に選択マークが表示されることを確認します。
v2rayN では、アクティブサーバーを確認してからコアを起動します。「システムプロキシを自動設定」が有効なら、起動後にシステムプロキシはクライアントのローカル待ち受けポートを指します。ウィンドウ下部のステータス欄またはログ欄に、Xray などのコアの起動とローカルインバウンドの確立に関する情報が表示されるはずです。正常に起動しても対象サーバーが必ず使えるとは限りませんが、少なくともクライアントが設定を読み込み、ローカル待ち受けを確立できたことを示します。
v2rayNG では、設定を選んでメイン画面の接続ボタンをタップします。この種の接続を初めて確立するときは、システムにネットワーク接続の許可を求める通知が表示されます。許可すると、クライアントの状態が接続済みに変わり、ステータスバーに接続マークが表示されます。タップ直後に未接続へ戻る場合は、ボタンを連打せず、クライアントのログで最初に表示された明確なエラーを確認してください。主な原因は、設定項目の不足、サーバーへの到達不能、システム時刻の誤り、現在のネットワークの一時的な不調です。
起動直後に複数の設定を切り替えないでください。数秒待ち、名前解決、プロトコルのハンドシェイク、トランスポート層の確立が終わってからアクセスをテストします。現在の設定に失敗した場合は接続を停止し、サブスクリプション内の別の設定を選んで再起動します。一度に変更する要素を1つにすると、問題がアクティブサーバー、ルーティングルール、システムプロキシのどこにあるか判断しやすくなります。
プロキシが有効か確認
確認では、「アプリからアクセスできるか」と「クライアントが通信を受信しているか」の2つを同時に見ます。まずシステムプロキシを読み取るブラウザーを開き、普段安定して開けるウェブページへアクセスします。次に、現在のプロキシルールで処理される対象へアクセスしてください。ページが正常に読み込まれ、クライアントのログまたは通信カウンターに新しい接続記録が現れれば、アプリのリクエストがクライアントに入っています。クライアントが接続済みと表示されるだけでは、ブラウザーがその接続を使っているとは限りません。
デスクトップでは、v2rayN のログに表示される対象ドメイン、インバウンドの種類、ルーティング先を重点的に確認します。新しいアクセス記録があれば、システムプロキシ経路は基本的に正しく動作しています。最終的に direct または proxy のどちらへ送られるかは、現在のルーティングルールによって決まります。ブラウザーに新しい記録がまったくない場合は、システムプロキシが「システムプロキシを自動設定」になっているか確認し、ブラウザー独自のプロキシ設定が有効になっていないかも確認してください。待ち受けポートを変更した場合は、システムプロキシが指すポートと v2rayN の現在のポートが一致していることも確認します。
Android では、接続を維持したままテスト対象アプリを開き、その後 v2rayNG に戻ってログまたは接続情報を確認します。クライアントに新しい接続がまったくない場合は、アプリごとのプロキシ設定で対象アプリが除外されていないか確認します。接続は表示されるのにアクセスできない場合は、アクティブサーバーとルーティング結果を確認してください。一部のアプリは古い接続をキャッシュするため、設定を切り替えた後はアプリを完全に終了して再起動すると、古いセッションの影響を避けられます。
停止して比較する方法もあります。現在正常にアクセスできている結果を覚えておき、クライアントの接続を意図的に停止して同じ対象を再読み込みします。その後、再接続してもう一度読み込みます。2回の結果にプロキシルールと一致する変化があれば、通信経路の確認に役立ちます。テスト後は必要な接続状態に戻せばよく、ログ画面を常に開いておく必要はありません。
サブスクリプションの更新、設定の切り替え、クライアントの終了
サブスクリプションの内容が変わっても、既存のグループを削除して追加し直す必要はありません。「現在のサブスクリプションを更新」または「すべてのサブスクリプションを更新」を実行すると、クライアントが内容を再取得して設定一覧を更新します。更新後は、現在のアクティブサーバーが残っているか確認してください。元の設定が置き換えられていた場合は、新しい設定を選んで接続を開始します。同じURLを何度も追加するとグループが重複し、どの設定を使っているか分かりにくくなります。
アクティブサーバーを切り替えるときは、まず一覧で新しい設定を選び、接続状態とログを確認します。バージョンによってはコアが自動的に再起動しますが、手動で停止してから再起動が必要な場合もあります。切り替え後は短時間のアクセス確認を行い、新しい設定が使えることを確認してください。ルーティングプリセットだけを変更した場合も、新しいルールを後続のリクエストへ確実に適用するため、再接続することをおすすめします。すでに確立された古い接続は、すぐに新しい出口へ切り替わらない場合があります。
デスクトップでは、メインウィンドウを閉じても v2rayN がトレイで動作し続ける場合があります。完全に終了するには、トレイメニューから終了を選び、必要に応じて先にシステムプロキシを解除してください。そうしないと、アプリ終了後も他のアプリがローカル待ち受けのなくなったプロキシアドレスを参照し、ウェブページにアクセスできなくなることがあります。Android では接続を停止すると、システムの接続状態も終了します。ホーム画面に戻るだけで停止しなかった場合、クライアントがシステム設定に従って動作し続けることがあります。
基本設定が安定してから、DNS、sniffing、Mux、LAN接続、カスタムルーティングなどの設定を確認できます。これらは明確な目的がある場合に使うもので、問題がない状態ですべてを一度に変更するのは避けてください。項目の意味と JSON 構造は設定リファレンスを、サブスクリプション更新、ポート競合、接続失敗についてはトラブルシューティングを参照してください。
決まった順番で確認する
1番目はサブスクリプションを確認します。URLが完全な状態で、手動更新後に一覧から設定を取得できることを確認してください。更新処理自体に失敗している場合は、ルーティングを調整する前に、サブスクリプションへのアクセスまたは形式の問題を解決します。2番目はアクティブサーバーを確認します。一覧で設定が確実に選択されていることを確認し、同じサブスクリプション内の別の設定も試して、特定の設定だけが一時的に使えない可能性を切り分けます。
3番目はクライアントの状態とローカルポートを確認します。ログにポート競合、設定の解析失敗、コア未起動などの明確なメッセージがないか確認してください。ポートが使用中の場合は、まず同種のクライアントを終了してから現在のクライアントを再起動します。複数のポートをむやみに変更するのは避けてください。ブラウザー、システムプロキシ、ほかの呼び出し元が古い値を保持している場合があるためです。4番目は通信の入口を確認します。デスクトップではシステムプロキシモード、Android では接続許可とアプリごとの対象範囲を確認します。
5番目にルーティングと DNS を確認します。クライアントがリクエストを受信しているのに、対象が想定外の出口へ送られる場合は、現在のルーティングプリセットとカスタムルールの順序を確認してください。ログに名前解決失敗が表示される場合は、DNS 設定と現在のネットワークが利用可能かを確認します。確認中は一度に1か所だけ変更し、変更後に再接続して再テストします。サーバー、ポート、ルーティング、DNSを同時に変更するより、原因を見つけやすくなります。
4ステップ完了後のチェックリスト
- サブスクリプショングループを更新でき、サーバー一覧が空ではない。
- アクティブサーバーが選択され、クライアントのコアが動作している。
- デスクトップのシステムプロキシ、または Android のアプリ対象範囲が正しく設定されている。
- テストアクセスに対応する接続記録がクライアントに残る。
- ルーティング結果が選択したプリセットと一致し、接続停止後も状態を正常に復元できる。
原因がまだ分からなくても、クライアントを何度も再インストールする必要はありません。問題が起きたときの操作手順、クライアントログに出た最初のエラー、現在のプロキシモードを記録し、トラブルシューティングと照らし合わせて確認してください。基本接続は成功しており、ドメインの振り分けやインバウンド・アウトバウンド設定を細かく調整したい場合は、設定リファレンスを参照してください。