v2rayNのよくある質問

Windows、macOS、Linuxのデスクトップではv2rayNを選びます。AndroidではXrayコアを採用したv2rayNGが第一候補で、V2Flyコアを採用したv2flyNGも選択肢になります。クライアントは設定を管理し、コアを起動してプロキシ接続を提供するソフトウェアです。利用可能なサブスクリプションを自動で作成するものではありません。選ぶ前に端末のOSを確認し、サブスクリプションのプロトコルや通信方式に対応しているかも確かめてください。3つのソフトは設定フォルダーや画面構成が異なるため、移行時はサブスクリプションを再度取り込み、別のクライアントのデータを上書きしないようにしましょう。

信頼でき、現在も有効なサブスクリプションURL、またはサーバー設定一式が必要です。サブスクリプションには通常、サーバーアドレス、ポート、プロトコル、認証情報が含まれます。クライアントはそれらを読み込んで利用します。インストール後、設定を取り込み、サーバーを選択してから、システムプロキシまたはAndroidのVPN接続を設定し、通信できるか確認してください。ソフトのインストールが完了しても、サーバーが使えるとは限りません。設定をまだ入手していない場合は、提供元に取得方法を確認しましょう。出所の分からない設定をテストに使ったり、サブスクリプションURLが写った画面を公開したりしないでください。

サブスクリプションURLは、複数の設定を取得するための入口です。更新すると、サーバーが追加・削除・変更されることがあります。個別サーバーの共有リンクには通常、1台分の設定だけが含まれ、サブスクリプションのように自動更新されません。取り込む前に、受け取ったものがWebページのURL、サブスクリプションURL、プロトコルの共有リンクのどれかを確認してください。サブスクリプションURLはサブスクリプショングループの入力欄に、共有リンクはクライアントのクリップボード取り込み機能に入力します。アカウント管理ページはサブスクリプションURLの代わりにはなりません。コピー時は前後の空白や改行にも注意してください。URLに含まれる認証情報は機密情報として扱い、アカウント情報と同様に保管しましょう。

システムプロキシはOSの設定にプロキシの接続先を登録し、その設定を参照するブラウザーやアプリで利用されます。独自に接続するソフトや、個別にプロキシを設定したソフトには適用されないことがあります。TUNモードは仮想ネットワークインターフェース経由で通信を取り込むため、より多くのアプリを対象にできますが、ルーティング、DNS、システム権限にも関わります。どちらの方式でも、すべての通信が必ずプロキシを通るわけではありません。最終的な接続先はルーティングルールにも左右されます。設定を始めるときは、まずシステムプロキシで接続を確認し、必要に応じてTUNを有効にしましょう。複数のネットワーク設定を同時に変更すると、原因を特定しにくくなります。

コピーしたものがアカウントのログインページや決済ページではなく、サブスクリプションURL全体であることを確認し、前後の空白を削除します。サブスクリプショングループを開いてURLを追加・保存した後、「サブスクリプションをすべて更新」を実行してください。保存するだけではサーバー一覧は作成されません。形式を認識できないと表示された場合は、取得した内容がログインページやエラーページではないか、クライアントがその形式に対応しているかを確認します。同じURLを何度も貼り付けるだけでは解決しません。一部の設定が表示されない場合は、ログの解析メッセージを確認し、対応形式を提供元に問い合わせてください。調査の際はエラーの種類だけを伝え、認証情報を含むURL全体は公開しないでください。

2015年以降の一般的なAndroidスマートフォンではarm64を選べることが多いものの、実際に対応するアプリのアーキテクチャを確認してください。universal版は複数のアーキテクチャに対応するため、ファイルサイズは大きめです。端末のアーキテクチャが分からない場合や、複数の端末で使いたい場合に適しています。arm64版が非対応と表示されたら、まずOSとプロセッサーの情報を確認し、universal版を試してください。プロセッサーが64ビット対応でも、システム環境に制約がある場合があります。インストールパッケージを解析できない場合は、OSのバージョンが動作要件を満たしているかも確認しましょう。インストール失敗の原因をすべてアーキテクチャの選択に結びつけないでください。

デスクトップ版はクロスプラットフォームの画面を採用し、従来のWPF版はWindows向けです。画面構成や依存関係、一部設定の場所が異なる場合があります。切り替える前に、クライアントのエクスポートまたはバックアップ機能で設定を保存し、サブスクリプショングループ、ルーティング、ローカルポートを記録してください。旧クライアントを終了してから別のバージョンを起動し、同じプロキシポートの競合を防ぎます。新旧バージョンのファイルを混在させて上書きしたり、移行結果を確認する前に元のデータを削除したりしないでください。初回起動後にシステムプロキシの接続先と選択中のサーバーを確認し、正常に接続できてから旧フォルダーを整理しましょう。

Windowsではクライアントを終了し、管理者として起動してからTUNを再度有効にします。macOSとLinuxでは、必要な権限がクライアントのバージョンやシステム環境によって異なります。画面の案内に従って許可し、設定フォルダー全体のアクセス権をむやみに緩めないでください。許可後も失敗する場合は、仮想インターフェースの作成失敗、ドライバーの問題、ポート競合がログに記録されていないか確認し、別のVPNやTUNソフトが動作していないかも調べます。テスト中はネットワークを制御するツールを1つだけ使ってください。失敗したらTUNを無効にして通常のネットワーク接続に戻し、原因を個別に確認しましょう。

サブスクリプション内のサーバー情報は提供元が管理しており、更新時に再生成されることがあります。手動で変更した内容がサブスクリプションの項目に長期間保持されるとは限りません。設定を試す場合は、対象を独立した手動項目としてコピーし、サブスクリプションの元設定と区別できる名前を付けましょう。誤操作に備えて、更新前に現在の設定をバックアップする方法もあります。同じ項目を何度も変更する必要がある場合は、更新のたびに修正するのではなく、元の設定に誤りがないか提供元に確認してください。グループ設定とサーバー項目では保持の動作が異なる場合があるため、実際の結果は利用中のバージョンで確認しましょう。

ブラウザーなどのアプリでクライアントのプロキシを使う場合は、システムプロキシを自動設定します。一時的に利用を停止するときやクライアントを終了するときは、システムプロキシを解除します。別のツールでシステムプロキシを管理している場合に限り、「変更しない」を検討してください。「変更しない」は直接接続を意味せず、OSに設定済みの内容を維持するため、古いプロキシアドレスが引き続き使われることもあります。切り替え後はOSのプロキシ設定で、実際の接続先を確認しましょう。クライアントを終了した後もブラウザーが接続できない場合は、ローカルポートを指すプロキシ設定が残っていないか確認し、不要な設定を解除してください。

ブラウザーとターミナルのツールでは、参照するプロキシ設定が異なる場合があります。ブラウザーが動作していても、使えることが確認できたのはブラウザー側の接続経路だけです。まずターミナルのツールがシステムプロキシに対応しているか確認します。対応していない場合は、ツールのドキュメントに従ってプロキシ設定やhttp_proxy、https_proxyなどの環境変数を設定してください。接続先にはクライアントが実際に待ち受けているローカルアドレスとポートを入力し、HTTPまたはSOCKSの種類も合わせます。他の端末の値をそのまま流用しないでください。環境変数は現在のセッションや、新たに起動したプロセスにだけ適用されることがあります。テスト後は一時設定を削除し、クライアント終了後も古いポートへの接続を試みないようにしましょう。

ルーティングルールに、geoip:privateをdirectに向ける項目があるか確認し、先に一致する可能性のある広範なルールより前に配置されているかも確認してください。このルールの主な対象はプライベートIPアドレスです。すべての内部ドメインが対象になるとは限らないため、内部ドメインを使う場合はDNSが正しいLAN内アドレスを返すことも確認しましょう。ルールを保存したら、ルーターの管理画面、プリンター、内部サービスへの接続を再テストします。それでもアクセスできない場合は、一時的にプロキシを無効にして基本のネットワーク接続を確認し、アプリが独自のプロキシを指定していないか調べてください。LAN内のサービス1つのために、ルーティングルール全体を削除しないでください。

まず、リクエストのタイムアウト、認証失敗、内容の解析失敗のどれに当たるかを確認します。タイムアウトの場合は、ローカルネットワークとサブスクリプションのドメイン名解決を調べ、更新時に直接接続しているか、既存のプロキシを使っているか確認してください。接続中のサーバーが使えなくなっていれば、そのサーバー経由の更新も失敗することがあります。認証に失敗した場合は、サブスクリプションの期限切れやURLのリセットを確認します。解析に失敗した場合は、提供元が形式を変更していないか確認してください。短時間に何度も再試行すると、サーバー側でリクエストが制限されることがあります。サブスクリプションURLを再取得した場合は、保存してから更新し、認証情報を取り除いたエラー情報だけを提供元に送ってください。

1回のテストがタイムアウトしただけでは、所定時間内にそのリクエストが完了しなかったことしか分からず、設定全体が使えないとは判断できません。まず端末の時刻が正確か確認し、同じグループ内の別サーバーで実際のアクセスを試してください。1つの項目だけ失敗する場合は、アドレス、ポート、通信パラメーターを確認します。すべて失敗する場合は、ローカルネットワーク、サブスクリプションの有効期限、コアの起動ログ、ファイアウォールの警告を優先して確認してください。テスト先にアクセスできず、タイムアウトになる場合もあります。クライアントが対応する別のテスト方法でも確認しましょう。接続の調査を理由に、システムの保護機能を長時間無効にしないでください。

接続済みという表示は通常、ローカルサービスまたはAndroidのVPNインターフェースが起動したことを示すだけで、接続先サーバーへの通信を保証しません。まずTUNを無効にして接続方法を1つに絞り、選択中のサーバーとローカルの待ち受けポートを確認します。次に、システムプロキシがそのポートを指定しているか確認してください。ブラウザーに独自のプロキシ拡張機能がある場合は一時的に無効にして、ページを開き直します。ドメイン名だけが開けずネットワーク接続は維持されている場合は、DNSを確認してください。すべてのリクエストが失敗する場合は、コアのログで認証、ハンドシェイク、接続に関するエラーを確認します。Androidではアプリごとのプロキシ設定も確認し、ブラウザーが対象外になっていないか調べましょう。

まず、画面ロック後やアプリ切り替え後にだけ切断されるか確認します。前面では正常に接続できるのにバックグラウンドで頻繁に停止する場合は、システムがクライアントのバックグラウンド動作やバッテリー使用を制限していないか調べ、端末の設定で必要なバックグラウンド実行を許可してください。VPNの許可が有効で、別のVPNアプリが接続を置き換えていないことも確認します。Wi-Fiとモバイルデータの切り替え時だけ失敗する場合は、クライアントで再接続してログを確認し、別のサーバーも試してください。バックグラウンド制限とサーバーの問題が同時に起きることもあります。バッテリー、DNS、ルーティング、サーバーの設定を一度に変えず、個別に確認しましょう。