v2rayNG よくある質問

3つの手順で確認します。第一に、取得したのが Web ページの URL ではなくサブスクリプション URL であることを確認します。サブスクリプション URL を開くと、紹介ページではなくエンコードされたテキストかノード一覧が返ります。第二に、URL が途中で切れていないか確認します。チャットや Web ページからコピーすると末尾のパスパラメータを落としやすいので、最後までコピーし直します。第三に、別の取り込み方法で検証します。v2rayNG で「クリップボードからサブスクリプションをインポート」に URL を貼り付け、それでもエラーになる場合はブラウザでその URL を直接開き、返ってくる内容がエラーページやログインページでないかを見ます。

URL 自体が失効している場合、クライアント側でどう操作してもノードは取得できません。サービス提供元に新しいサブスクリプション URL を依頼するしかありません。インポートに成功するとノードはグループごとに一覧に表示されるので、まずリアル遅延テストを1回行ってからノードを選びましょう。

プロセッサのアーキテクチャで判断します。2015年以降の主要なスマートフォンはほぼ 64 ビット ARM チップなので、arm64 版で問題ありません。パッケージが小さく、動作効率も良くなります。universal 版は複数のアーキテクチャのライブラリを同時に含むため、古い機種やエミュレーターにも対応しますが、インストールパッケージは大きくなります。

迷ったらまず arm64 版を入れ、アプリがインストールされない、またはパッケージの解析に失敗したという表示が出たら universal 版に切り替えます。2つのバージョン間でアプリデータは共有されないため、切り替える前にサブスクリプション URL を控えておき、インストール後に改めてインポートしてください。

「プロキシのみ」はルーティングルールに一致した通信だけをプロキシに渡し、それ以外は直接接続するため、ルールを細かく書いている場面に向いています。「LAN をバイパス」はすべての通信をプロキシしつつ、プライベートネットワークのアドレス帯(192.168.x.x、10.x.x.x など)を除外するもので、家庭やオフィスのネットワークでよく使われる設定です。「グローバル」はすべての通信をプロキシに送るため、ノードが使えるか一時的に確認したいときに適しています。

切り替えた後は一度切断して再接続しないと反映されません。日常使いは「LAN をバイパス」のままにしておき、特定のアプリの挙動がおかしいときに一時的に「グローバル」へ切り替えて比べると、問題が振り分けルールにあるのかノード自体にあるのかを判断できます。

v2rayNG の「アプリごとのプロキシ」には2つのモードがあります。ホワイトリストはチェックしたアプリだけをプロキシし、ブラックリストはチェックしていないアプリだけを通します。既定ではすべてのアプリがプロキシ経由になります。

よくある使い方としては、ブラウザ、メールクライアント、開発ツールをホワイトリストに入れ、銀行、決済、フードデリバリーなどネットワーク環境に敏感なアプリを除外し、ログイン時のリスク判定や地域チェックによる支障を減らします。変更後は同じく一度切断して再接続し、新しい振り分けルールを反映させましょう。一覧のアプリは名前順に並んでいるので、用途が分からないものはチェックしないでおくのが無難です。

まず「サブスクリプションを更新」を手動で1回実行し、返ってくるメッセージを確認します。よくある原因は3つです。1つ目は、サービス提供元がサブスクリプション URL の token やパスを変更し、古い URL が 404 を返すようになったケース。2つ目は、現在のネットワークでサブスクリプションのドメインが名前解決できていないケースで、別のネットワーク(Wi-Fi からモバイルデータなど)に切り替えて試します。3つ目は、クライアントの自動更新間隔が長く、起動のたびに更新されるわけではないという点です。

URL が有効だと確認できたら、サブスクリプション設定で自動更新をオンにできます。あわせてノードの共有リンクを1つ保存しておくのがおすすめです。サブスクリプションが一時的に取得できないときは、重要なノードを手動で先にインポートできます。

外側から内側へ順に確認し、各手順で変える要素は1つだけにします。ステップ1では、プロキシを切って直接接続し、端末のネットワーク自体が通じているか確認します。ステップ2では、別のノードに切り替えて再接続し、単一ノードの不具合を除外します。ステップ3では、ルーティングモードとアプリごとのプロキシを確認し、現在のアプリがプロキシの対象に入っているかを見ます。ステップ4では、DNS 設定を確認します。ローカルでの名前解決に失敗すると、プロキシに接続できてもページが開けません。ステップ5では、特定のサイトだけおかしい場合を確認します。その場合はそのサイトのアクセス方針によるものが多く、ノードとは関係ありません。

作業の間は各ステップの結果をメモしておくのがおすすめです。原因の箇所を特定してからピンポイントで調整するほうが、クライアントを何度も入れ直すよりはるかに効果的です。

すべてのノードが同時に失敗する場合、原因はクライアントの外にあることがほとんどです。まずサブスクリプションを手動で1回更新し、ノード情報が古くなっていないか確認します。次にネットワークを切り替えて試し、現在の Wi-Fi や回線の問題かどうかを見ます。その後、システム時刻を確認します。VMess のように時刻検証を行うプロトコルは時刻のずれに敏感で、システム時刻が正確でないとハンドシェイクが失敗します。

ネットワークを変えて一部のノードが復活したなら、特定の回線の問題です。モバイルデータに切り替えてもすべて失敗するなら、原因はサブスクリプション側とほぼ判断できるので、サービス提供元に確認しましょう。

TUN モードは仮想ネットワークカードで通信を引き受けるため、システムから VPN 権限を付与される必要があります。初めてオンにすると承認ダイアログが表示されるので、必ず許可を押してください。許可しないと接続はすぐに切れます。以前に拒否した場合は、システム設定の VPN またはアプリの権限から再承認すれば問題ありません。

ほかによくある原因は2つです。VPN チャンネルを同時に占有できるアプリは1つだけなので、まず他のプロキシ系アプリが動いていないか確認します。一部のカスタム OS ではバックグラウンド起動が制限されるため、バッテリーとパフォーマンスの設定でクライアントをバックグラウンド実行の許可リストに追加する必要があります。TUN モードはシステムプロキシより引き受ける範囲が広いので、オンにしたらまずテストページで出口アドレスが変わったか確認しましょう。

まず「システムプロキシ」のスイッチがオンで、モードが「システムプロキシを自動設定」または「グローバル」になっているか確認します。ブラウザにプロキシ管理の拡張機能が入っている場合、その拡張がシステムプロキシ設定を上書きします。いったんシステムに従う設定に切り替えるか、一時的に無効化してください。

もう1つあるのは、管理者権限で動作するプログラムは現在のユーザーのプロキシ設定を読まないことがあるケースです。その場合は TUN モードで通信を引き受ける必要があります。設定を変えたらブラウザを一度再起動して新しいプロキシ設定を反映させ、テストページを開いて出口アドレスを確認しましょう。

DNS リークとは、ドメインの名前解決リクエストがプロキシ経由にならず、ローカルネットワークや ISP の DNS で解決されてしまうことを指します。検出の考え方は、接続後に DNS リーク検出系のテストページを開き、返ってくるリゾルバの所属を見るというものです。ローカルの ISP やルーターのアドレスが表示されたら、リークしています。

防ぐにはリモート DNS を有効にし、解決リクエストをノード側に任せ、ルーティング設定で DNS クエリの経路を個別に指定します。デスクトップ版では DNS 設定でローカルネットワークを経由しないリゾルバのアドレスを指定する方法もあります。変更したら再接続し、もう一度テストして確認しましょう。DNS 設定とルーティングルールは互いに影響するので、一度に1項目だけ変更するのがおすすめです。