基本知識と選び方
基礎知識
クライアント、リモートサービス、通信の取り込み方を整理してから、インストーラーを選びましょう。
v2rayN・v2rayNG・v2flyNGはどれを選べばよい？
Windows、macOS、Linuxのデスクトップではv2rayNを選びます。Androidでは通常、Xrayコアを採用したv2rayNGが第一候補です。V2Flyコアが必要な場合はv2flyNGを検討してください。クライアントはサブスクリプション管理、ノード選択、プロキシ設定を担い、コアは実際の接続とルーティングを処理します。選ぶ前に、サブスクリプションのプロトコルとトランスポートの組み合わせが、クライアントとコアの両方でサポートされているか確認しましょう。名前が似ていても設定をそのまま使えるとは限りません。移行時はサブスクリプションを再読み込みし、プロキシのポートとルーティングモードを一つずつ確認してください。
クライアントをインストールしたのに、サブスクリプションやノード設定が必要なのはなぜ？
クライアントは端末上で接続を管理するツールであり、インストーラーに利用可能なリモートサービスは含まれていません。接続には、有効なサーバーアドレス、ポート、認証情報、対応するトランスポート設定が必要です。サブスクリプションを使うと、これらの設定をまとめて読み込み、更新できます。利用権限のあるサービスから設定を入手し、サブスクリプションが有効か確認してから接続テストを行いましょう。ソフトのインストール、サブスクリプションの読み込み、リモートサービスの利用可否は別々に確認してください。サブスクリプションURLに認証情報が含まれる場合があるため、画面の共有や問い合わせの際はURL全体を隠してください。
システムプロキシ、ルーティング、TUNモードの役割の違いは？
システムプロキシは、システム設定に従うアプリの通信をローカルのプロキシポートへ送ります。ルーティングは、コアに届いた通信をプロキシ経由にするか、直接接続するか、遮断するかを決めます。TUNモードは仮想ネットワークインターフェースで通信を受け取り、システムプロキシに従わない一部のアプリで利用できます。それぞれ動作する段階が異なります。システムプロキシを有効にしても、すべてのアプリの通信がコアに届くわけではありません。また、ルーティングを切り替えても、コアに届いていない通信は自動的に取り込まれません。初回はシステムプロキシで通常のWeb閲覧を確認し、必要に応じてTUNを有効にしましょう。複数の設定を同時に変えると、原因を特定しにくくなります。
Android版のarm64とuniversal、どちらを選ぶ？
まず端末情報でプロセッサのアーキテクチャを確認してください。比較的新しいAndroidスマートフォンの多くはarm64のため、該当するインストーラーを選ぶとよいでしょう。universalは通常、複数のアーキテクチャに対応しており、端末のアーキテクチャが分からない場合や、ほかの対応アーキテクチャでも使いたい場合に適していますが、ファイルサイズは大きくなる傾向があります。製造年はあくまで目安で、アーキテクチャの確認にはなりません。インストールできない場合は、Androidのバージョン要件、プロセッサのアーキテクチャ、インストーラーのダウンロード完了を確認してください。失敗しただけで既存アプリを削除しないでください。上書きインストールの前に、サブスクリプションやカスタム設定を引き継ぐ必要があるか確認しましょう。
読み込みと権限
導入と設定
サブスクリプションURLの保存、内容の更新、システム権限の許可は、それぞれ別の手順です。
v2rayN・v2rayNGでサブスクリプションを読み込み、グループを確認する方法は？
v2rayNではサブスクリプショングループの設定を開き、新しいグループを作成して、分かりやすい名前とサブスクリプションURL全体を入力します。保存後、そのグループのサブスクリプションを更新してください。v2rayNGではサブスクリプショングループの設定画面で名前とURLを追加し、メイン画面に戻って更新します。メニュー名はバージョンによって多少異なる場合があります。更新後は、別のグループで一覧が絞り込まれていないことを確認し、ノードを一つ選んで有効にします。URLを保存しただけでは、通常、内容は自動取得されません。画面操作を確認する際はチュートリアルを参照できますが、例示ドメインは実際のサブスクリプションサービスを提供していないため、接続テストには使えません。
サブスクリプションの読み込みに失敗する、または形式に対応していないと表示される場合は？
まず、コピーしたものがサブスクリプションURL、個別の共有リンク、サービス管理ページのURLのどれかを確認します。サブスクリプションURLはグループに登録し、個別の共有リンクはクリップボードからの読み込みなど、対応する方法で追加してください。URLの前後にある空白や改行、途中で切れたパラメーターを確認し、全体をコピーできているか確かめます。取得結果がログイン画面、期限切れの通知、Web認証画面の場合、クライアントはノード形式として解析できません。サービス提供元にサブスクリプションの状態を確認してください。それでも失敗する場合は、クライアントに表示された形式やプロトコル名を記録し、コアの対応状況を確認します。出所の分からないオンライン変換ツールにサブスクリプション全体を渡さないでください。
サブスクリプションの更新に失敗しても、既存のノードで接続できる場合は？
既存のノードは端末に保存された設定を使うことが多い一方、サブスクリプションの更新ではサーバーへの再アクセスが必要です。そのため、結果が異なる場合があります。現在のグループは残したまま、更新エラーが解析失敗、接続タイムアウト、アクセス拒否のどれか確認し、サブスクリプションの期限やURLが変わっていないか調べます。クライアントにプロキシ経由で更新する設定がある場合は、既存ノードが正常に動作していることを確認したうえで試してください。プロキシ自体が使えない場合は、サブスクリプションにアクセスできるネットワーク経路を利用します。メモや選択状態が失われるおそれがあるため、グループを何度も削除して作り直すのは避けましょう。更新後はノードの追加・削除を確認し、現在のノードが残っているか確かめてください。
TUNを有効にすると権限不足や仮想インターフェースの作成失敗が表示される場合は？
まずTUNを無効にして、通常のプロキシモードが動作するか確認します。Windowsではクライアントの案内に従って管理者権限で実行するか、現在のバージョンで利用できるサービスモードを使ってください。macOSとLinuxでは、アプリの案内に沿って必要な権限を許可し、コンポーネントを設定します。Androidでは初回起動時に、システムのVPN接続要求を許可する必要があります。別のアプリが仮想ネットワークインターフェースやVPNセッションを使用している場合は、一時停止してから試してください。それでも失敗する場合はログの詳細を確認し、権限、インターフェース作成、ルート設定のどこで失敗したか切り分けます。案内を回避するためにシステムのセキュリティ機能を恒常的に無効化しないでください。変更前に元の設定を記録し、テスト後は不要な権限を元に戻しましょう。
モードとメンテナンス
使い方
アプリに合わせて通信の入口を選び、目的に応じて振り分け、更新前に復元可能な設定を保存しましょう。
普段のWeb閲覧には、グローバルルーティングと中国本土の通信を除外する設定のどちらがよい？
利用目的に応じて選びましょう。一般的な「中国本土を除外」するルールでは、中国本土のアドレスや一部のローカル通信を直接接続し、それ以外をプロキシ経由にします。ただし、実際の動作は選択したルールの内容や順序、ルールデータによって異なります。グローバルルーティングは、通信の振り分けが問題に関係しているかを確認するための短時間の比較テストに向いています。通常は、コアに届いた通信をプロキシ経由で送る設定であり、すべてのアプリの通信が取り込まれるという意味ではありません。切り替え後は新しい接続で確認してください。既存の接続は以前の経路を使い続ける場合があります。特定のサイトだけに問題がある場合は、そのサイトに適用されるルールを優先して確認し、端末全体の接続方法を長期間変更する必要はありません。
ブラウザーはプロキシ経由なのに、ターミナルのコマンドは直接接続になるのはなぜ？
多くのコマンドラインツールはデスクトップのシステムプロキシを参照せず、独自のオプションやhttp_proxy、https_proxyなどの環境変数を使います。まずクライアント画面で、実際に待ち受けているローカルアドレス、ポート、プロトコルを確認し、ツールのドキュメントに従って現在のターミナルセッションにプロキシを設定してください。HTTPプロキシとSOCKSは、ポート番号だけを置き換えて共用できません。また、変数名にhttpsが含まれていても、プロキシサーバー自体がHTTPSを使うとは限りません。テストはまず現在のセッションに限定し、無効なアドレスをシステム全体の環境変数に登録しないようにします。クライアントを終了したら一時変数を削除してください。TUNで通信を取り込む場合は、ターミナルの通信が除外ルールで迂回されていないかも確認します。
カスタムルーティングルールが想定どおりに動作しないのはなぜ？
まず対象アプリの通信が現在のコアに届いているか確認し、カスタムルールが有効で、再読み込み済みかを調べます。V2Rayのルーティングルールは通常、上から順に照合されます。先に広範囲のルールが一致すると、後続の詳細なルールは適用されません。domainやipなどの照合項目、アウトバウンドのタグ、geositeやgeoipのデータが利用できるかも確認してください。domainStrategyはドメインをさらにIPアドレスへ解決するかどうかに影響するため、IPルールだけを変更してもドメインへの接続結果が変わらない場合があります。一度に一組の条件だけを変更し、対象の接続を作り直してログを確認すると、複数のルールを同時に変えるより原因を特定しやすくなります。
クライアントの更新やコアの切り替え前に、どの設定を保存すべき？
まずクライアントのバックアップまたはエクスポート機能を使い、サブスクリプショングループ、手動追加したノード、カスタムルーティング、DNS設定、ローカルの待ち受けポートを保存します。エクスポートできる範囲はバージョンによって異なります。バックアップにサービスの認証情報が含まれる場合があるため、安全な場所に保管してください。更新前に実行中のコアを終了し、新旧のプロセスが同じポートを使用しないようにします。設定を復元したら、まずシステムプロキシで基本的な接続を確認し、その後TUNとカスタムルールを確認します。コアの切り替えは単に名前を置き換えるだけではありません。対応する設定項目やプロトコルの組み合わせが異なる場合があります。起動に失敗したらログから非対応の項目を特定し、異なるコア間で設定全体をそのまま上書きしないでください。
接続とログ
トラブル対処
エラー表示を手がかりに、ローカルの待ち受け、ネットワーク経路、リモート接続、DNSの名前解決を切り分けましょう。
ノードのテストがタイムアウトしたら、そのノードは必ず使えない？
必ずしもそうとは限りません。テスト結果は、テスト方法、接続先、現在のネットワーク、ノード設定によって変わります。特定の確認方法で失敗しても、実際のアプリでの接続は異なる結果になる場合があります。まず端末の時刻が正確か、現在のネットワークで直接接続できるかを確認し、別の既存ノードでも比較します。ログでサーバーへの接続タイムアウト、ドメインの名前解決失敗、TLSハンドシェイク異常のどれが発生しているか確認し、サーバーアドレス、ポート、トランスポート設定を照合してください。同じノードでもネットワークによって結果が異なる場合は、通信経路をさらに確認します。サブスクリプション内のノードが全般的に使えない場合は、サービスの状態や設定が更新されていないか確認し、速度テストを何度も実行するだけで済ませないでください。
クライアントは実行中なのにWebページが開かない場合、どの順番で確認すればよい？
実行中の表示は通常、ローカルサービスが起動したことを示すだけで、リモート接続やDNS名前解決の成功を意味しません。まず有効なノードが正しく選択されているか確認し、起動ログに設定エラーがないか調べます。次に、ブラウザーがクライアントの実際の待ち受けポートを使用しているか確認してください。異なるドメインにアクセスし、一つのサイトだけの問題か、すべて接続できないのかを切り分けたうえで、ログの名前解決、ハンドシェイク、アウトバウンドに関するエラーを確認します。比較のためにルーティングモードを一時的に切り替える場合も、一度に変更する設定は一つにしてください。TUNを有効にしている場合は、まず通常のプロキシに戻してテストします。通常のプロキシでは動作し、TUNでだけ問題が起きる場合は、仮想インターフェース、DNS、ルートの競合を確認してください。接続が復旧したら、テストのために変更した設定を元に戻します。
システムプロキシの自動設定を有効にしているのに、ブラウザーがプロキシを経由しないのはなぜ？
まずクライアントのシステムプロキシの状態と、システム設定にあるプロキシのアドレス、ポートが一致しているか確認します。次にブラウザー拡張機能、独自のプロキシ設定、除外リストを調べてください。ブラウザーによっては独自のプロキシ設定を使い、拡張機能や組織のポリシーがシステム設定を上書きする場合があります。競合するプロキシ拡張機能を無効にして新しい接続でテストし、クライアントのアクセスログでリクエストがコアに届いているか確認します。ローカルドメインや特定のサイトだけが直接接続になる場合は、除外ルールの想定どおりの動作かもしれません。ブラウザーのセキュアDNS設定も名前解決の経路を変える場合がありますが、プロキシの入口とは別の問題なので分けて確認してください。テスト後は、引き続き使うブラウザー設定を元に戻します。
ログにDNSの名前解決失敗やポートの使用中と表示された場合の対処法は？
DNSの名前解決に失敗した場合、まずサブスクリプションのドメイン、ノードサーバーのドメイン、接続先サイトのドメインのどれで失敗したか確認します。次に、選択したDNSサーバーへ現在の経路からアクセスできるか、リモートDNSが未確立のプロキシ接続に依存していないかを調べてください。ポートの使用中はローカルの待ち受けに関する問題です。複数のクライアントを同時に起動していないか、コアのプロセスが残っていないか確認し、競合するプログラムを通常の方法で終了します。空いているポートに変更する場合は、アプリ側のプロキシ設定も合わせて変更してください。発生する段階が異なるエラーなので、ノードを何度も切り替えて解決しようとしないでください。問い合わせる際は、発生時刻、操作手順、機密情報を伏せたログを添え、サブスクリプション、認証情報、個人のアドレスを隠しましょう。