troubleshooting manual

V2Rayトラブルシューティングガイド

ローカルネットワークから始め、クライアント、サブスクリプション、ノード、ルーティング、DNSの順に確認します。一度に一つの条件だけを変え、再現可能な結果で障害の範囲を絞り込みます。

トラブルシューティングを開始 クイックチュートリアルを見る トラブルシューティングを開く

how to use

クライアントを初めて設定する場合は、まずクイックスタートガイドに沿ってサブスクリプションのインポート、ノード選択、システムプロキシの設定を完了してください。このガイドではインストール手順を繰り返さず、「設定済みなのに期待どおり動作しない」場合を扱います。v2rayN、v2rayNG、v2flyNGを再入手する場合は、ダウンロードセンターでプラットフォームに合ったクライアントを選択してください。

トラブルが発生したら、まず三つの事実を記録します。いつから発生したか、すべてのノードで失敗するか、クライアントを終了すると通常のネットワークは正常か。その後は現在の症状に対応する章だけを実行してください。クライアントの再インストール、DNS変更、サブスクリプション更新、ネットワーク変更を同時に行わないでください。複数の変数を同時に変えると、復旧しても本当の原因を特定できません。

chapter one

インターネットに接続できない：ローカルネットワークとプロキシ障害を切り分ける

「プロキシを有効にするとすべてのウェブページにアクセスできない」からといって、ノードが使えないとは限りません。ブラウザーのリクエストは、アプリから対象サイトまで、システムプロキシ、ローカル待受ポート、クライアントのルーティング、プロトコル接続、DNS名前解決などを通ります。どこか一つが途切れるだけでも、見た目の症状は同じになります。最も効果的なのは再インストールではなく、まずクライアントを終了した状態でネットワークが復旧するか確認し、問題がプロキシ経路にあるのか基礎ネットワークにあるのかを判断することです。

プロキシを経由しない基準結果を確認する

まずクライアントでシステムプロキシを無効にするか接続を停止し、個別プロキシを設定したブラウザーを完全に終了してから、通常のウェブページを開き直します。それでもアクセスできない場合は、Wi-Fi、有線ネットワーク、ルーターのログイン、ネットワーク認証、上流接続を優先して確認します。既知の正常な別ネットワークへ一時的に切り替えて比較することはできますが、すぐにクライアント設定を変更しないでください。プロキシを無効にすると正常で、有効にすると直ちに失敗する場合に限り、クライアント経路の障害と判断できます。

デスクトップでは「クライアントのウィンドウを閉じる」ことと「バックグラウンドプロセスを終了する」ことも区別してください。v2rayNはメインウィンドウを閉じても通常はタスクトレイで動作し続け、システムプロキシがローカルポートを指し続けることがあります。タスクトレイのメニューから終了し、その後システムプロキシが無効になったことを確認します。ブラウザーに個別のHTTPまたはSOCKSプロキシを設定している場合も、一時的に「システム設定を使用」に戻すか手動プロキシを無効にし、古いポートがリクエストを引き続き受けないようにします。

ローカル待受ポートの存在を確認する

システムプロキシは、127.0.0.1と待受ポートなどのローカルアドレスへリクエストを送るだけです。実際にリクエストを受け取るのはクライアントのコアです。コアが起動していない場合や、ポートが別のプログラムに使用されている場合、システムプロキシが有効でも動作しません。v2rayNではまず実行ログを確認し、設定が読み込まれ、「address already in use」のようなポート競合メッセージがないことを確認します。Windowsではターミナルから一般的なローカルポートが待ち受け状態か確認できます：

netstat -ano | findstr LISTENING
netstat -ano | findstr 10808

2つ目のコマンドのポートは、クライアントの設定画面に表示される実際のポートへ置き換えてください。何も出力されない場合、現在のポートを待ち受けるプロセスはありません。出力されたプロセスIDが実行中のクライアントと一致しない場合は、ポート競合の可能性があります。占有しているプログラムを終了するか、v2rayNでローカル待受ポートを変更し、ブラウザーの手動プロキシ、コマンドラインの環境変数、古いポートに依存する他のソフトウェアも同時に更新します。詳しい確認方法はローカルポート競合の確認方法を参照してください。

最小構成でルーティングルールの影響を切り分ける

待受が正常であることを確認したら、ルーティングモードを一時的にグローバルへ切り替え、正常に使えることを確認済みのノードを選択します。グローバルモードでは、カスタムルール、ドメイン分類、直結出口の設定を迂回できるため、問題が振り分けによるものか判断しやすくなります。グローバルモードで使えて元のモードで使えない場合は、元のモードに戻してルールの順序を一つずつ確認します。特に先頭付近のdomain、geosite、geoip、フォールバックルールを確認してください。ルールは通常上から順に照合されるため、広すぎる直結ルールが、プロキシ出口へ送るべきリクエストを先に処理してしまいます。

グローバルモードでも使えない場合は、同じサブスクリプション内の別ノードへ切り替えます。一つのノードだけ失敗して他が正常なら、ローカルのプロキシ経路はおおむね正常で、問題はノードのパラメーターまたはサーバー側の状態にあります。すべてのノードで失敗する場合は、システム時刻、ファイアウォール、プロトコルパラメーター、DNSを続けて確認します。「遅延テストに数値が出る」ことを、ウェブページに必ずアクセスできることと同一視しないでください。テストによってはTCP接続だけを確認し、完全なプロトコルハンドシェイク、トランスポート層、対象リクエストまでは検証しません。

基準結果 優先して確認する範囲 次の手順
プロキシを無効にしても接続できない ローカルネットワーク、ルーター、ネットワーク認証 まず基礎ネットワークを復旧する
プロキシを有効にするとすべて失敗する 待受ポート、コアの起動、システムプロキシ ログとポートを確認する
一部のノードだけ失敗する ノードの状態、プロトコル、トランスポートパラメーター ノードのタイムアウトの章へ進む
グローバルでは使えるが振り分けで失敗する ルーティングルールの順序と出口 カスタムルールを減らす

chapter two

ノードのタイムアウト：接続層ごとにパラメーターを確認する

ノードのタイムアウトは、クライアントが規定時間内に期待する応答を受け取れなかったことを示します。ただし、タイムアウトが発生する場所はさまざまです。ドメインを名前解決できない、対象ポートへのTCP接続を確立できない、TLSハンドシェイクに失敗する、プロトコルの認証パラメーターが一致しない、といった問題はいずれも似たエラーとして表示されます。切り分けでは、ノード設定に依存しない条件から始め、徐々にプロトコルの詳細へ進みます。ローカルネットワークを確認できていない段階で、UUID、パス、トランスポート方式を何度も編集しないでください。

まずシステム時刻と対象アドレスを確認する

システム時刻のずれはTLS証明書の有効期間判定に影響し、時間枠に依存する認証処理を壊すこともあります。Windows、macOS、Android、Linuxでは、自動的な日付・時刻・タイムゾーン設定を有効にして、もう一度同期してください。長時間のスリープ、デュアルブート、マザーボードの電池異常がある端末では、時刻のずれが発生しやすくなります。時刻を修正したら、コアを完全に停止して再接続します。既存の接続はハンドシェイク全体を自動的にやり直しません。

続いてノードアドレスを確認します。アドレスがドメインの場合は、端末で名前解決できることを確認します。IPアドレスの場合は、コピー時に混入した空白、ポート区切り文字、プロトコル接頭辞を取り除きます。通常、ノードアドレス欄にはホスト名またはIPアドレスだけを入力し、完全なサブスクリプションURL、ウェブページのパス、https://まで含めてはいけません。ポートにはサブスクリプションが指定する対象ポートを入力します。ローカルのSOCKSまたはHTTP待受ポートをサーバーポート欄に入力しないでください。

ネットワーク不通とプロトコルハンドシェイク失敗を区別する

デスクトップでは、システムツールで対象ホストへのTCP接続を確立できるか確認できます。Windows PowerShellでは、ホストとポートをノード設定の値に置き換えて次のコマンドを実行します：

Test-NetConnection example.com -Port 443

LinuxまたはmacOSでは次を使用できます：

nc -vz example.com 443

このコマンドが確認するのは対象ポートだけで、VMess、VLESS、Trojan、トランスポート層の設定は検証しません。ポートテストに失敗した場合は、まずローカルネットワーク、対象アドレス、ポート、サーバーへの到達性を確認します。ポートテストは成功するのにクライアントのハンドシェイクが失敗する場合は、プロトコルパラメーターに注目します。ネットワーク環境によっては診断コマンドが制限されるため、1回の失敗だけで結論を出さず、別のネットワークでも再テストしてください。

ログでは、エラーが発生した段階に注目します。ドメイン名前解決のエラーには通常、lookup、resolve、DNSに関する記述が含まれます。connection refusedは対象が明確に接続を拒否したことを示し、timeoutは制限時間内に応答が返らなかったことを示します。certificate、handshake、TLSに関するエラーは、ドメイン、証明書名、システム時刻、TLSパラメーターに関係することが多いです。最後の1行だけを確認せず、その前後10行ほども見てください。実際に失敗を引き起こしたアドレスや出口名が含まれていることがあります。

プロトコルとトランスポートの項目を一つずつ照合する

ノードを手動入力する場合は、プロトコル層とトランスポート層を分けて確認します。VMessでは、アドレス、ポート、ユーザー識別子、暗号化またはセキュリティ設定が主な確認項目です。VLESSでは、ユーザー識別子、フロー制御、暗号化項目、対応するトランスポート設定を確認します。Trojanでは、パスワード、TLSのサービス名、トランスポートパラメーターが重要です。WebSocketではパスとHost、gRPCではサービス名を確認します。REALITYでは、サブスクリプションに記載されたサービス名、公開鍵、短い識別子、フィンガープリントを照合してください。どの項目も、似ているだけで完全に一致していなければハンドシェイク失敗の原因になります。

ノードがサブスクリプション由来の場合は、項目を手動で修正するより先にサブスクリプションを再更新してください。提供元がトランスポートパラメーターを変更すると、古いノード名が同じでも内部設定が変わっていることがあります。更新前にサブスクリプションURL自体が有効か確認し、更新後は新しく生成されたノードを選んでコアを再起動します。すべてのノードが同時にタイムアウトする場合は、ノードのタイムアウト確認手順に沿ってローカルネットワークとシステム時刻を確認します。一つのノードだけ失敗する場合は、他のノードを比較対象として残し、サブスクリプショングループ全体を削除しないでください。

chapter three

サブスクリプション取得失敗：ダウンロード・解析・上書きのどこかを判断する

サブスクリプションの更新は、クライアントがURLへリクエストを送る、レスポンスを取得する、その内容をノードとして解析してグループへ書き込む、という3つの連続した手順で行われます。画面に「更新失敗」としか表示されない場合は、ログと更新結果からどの段階で失敗したかを判断します。URLへアクセスできない、ログインページが返る、対応していない形式が返る、グループのフィルターでノードが隠れる、といった問題は、最終的にリストが空になる症状として現れます。

サブスクリプションURLが完全で、種類も正しいことを確認する

サブスクリプションリンクをコピーするときは、提供元の管理ページから完全なURLをコピーし、クエリパラメーターを手動で省略しないでください。URL末尾のtoken、パラメーター、パスはサブスクリプションの識別に使われることが多く、1文字欠けただけでもエラーページが返ります。v2rayN、v2rayNG、v2flyNGへ貼り付けた後、先頭や末尾に日本語の引用符、改行、空白、チャットアプリが付けた句読点が混入していないか確認します。QRコードでインポートした場合も、読み取り完了だけでなくサブスクリプション項目を確認してください。

サブスクリプションリンクと単一ノードの共有リンクは用途が異なります。サブスクリプションリンクは定期的に複数の設定を取得するためのもので、単一ノードリンクは通常プロトコル名で始まり、一つの設定だけを表します。単一ノードリンクをサブスクリプション管理へ登録すると形式エラーになることがあり、逆にサブスクリプションURLを単一ノードとしてインポートしても期待どおりにはなりません。複数端末へ移行する場合は、サブスクリプションリンク・設定エクスポート・QRコード移行の比較を参考に、更新の必要性に応じて方法を選んでください。

レスポンスの状態からリクエスト段階を特定する

更新中は、ログに表示されるHTTPステータス、リダイレクト、タイムアウト、解析メッセージを確認します。接続タイムアウトは、クライアントがまだレスポンスを取得できていないことを示します。現在のネットワーク、サブスクリプションドメインの名前解決、システムプロキシ経路を確認してください。未認証やアクセス禁止が返る場合は、有効なサブスクリプションURLを再取得する必要があります。成功と表示されても解析数が0なら、レスポンスがクライアント対応形式ではない、またはウェブページの本文が返っている可能性があります。サブスクリプションURLには有効期限や端末制限が設定されることがあり、無効になった場合は元のサービス画面で再生成します。ローカルのノードパラメーターを変更しても直りません。

通常のネットワークからサブスクリプションへ直接アクセスできる場合は、まず「プロキシ経由でサブスクリプションを更新」を無効にしてテストします。サブスクリプションの取得にプロキシ接続が必要な場合は、すでに使える古いノードを選んでから、プロキシ経由の更新を有効にします。重要なのは循環依存を避けることです。使えるノードがない状態で、サブスクリプション更新にもプロキシを要求すると、更新は開始できません。この項目の名称はクライアントによって多少異なるため、サブスクリプション設定と更新ログを基準にしてください。

更新は成功したのにノードが見えない

ログでサブスクリプションの取得成功を確認したら、グループ、フィルター、上書きの動作を続けて確認します。まず更新直後のサブスクリプショングループへ切り替え、名前フィルターを解除し、キーワードによるノードの包含・除外ルールが有効になっていないか確認します。フィルター語の空白、正規表現、大文字と小文字の違いによって、すべてのノードが隠れることがあります。クライアントが更新時に古い設定を削除する仕様なら、更新結果が空のとき元のリストまで消える可能性があります。サブスクリプション設定を変更する前に、現在使える設定をエクスポートしてください。

同じサブスクリプションを重複登録すると、名前は同じでも出所の異なるグループが作成され、新しいノードを古いグループで探してしまいがちです。有効な項目を一つだけ残し、出所が分かる名前をグループに付けてから、完全な更新を一度実行することをおすすめします。サブスクリプション内容が変わると、現在選択中のノードがすでに存在しないことがあります。その場合は新しいリストから選び直して接続を開始してください。リストが更新されたことは、実行中のコアが新しい設定へ切り替わったことを意味しません。

インポート後にノードは存在するもののすべてタイムアウトする場合は、サブスクリプションの確認をやめ、前章へ戻ってネットワークとノードパラメーターを確認します。一部のノードだけ不足している場合は、クライアントが対応するプロトコルとトランスポートの種類を照合してください。デスクトップではv2rayN、Androidではv2rayNGを優先して使用できます。v2flyコアのエコシステムが必要な場合にv2flyNGを選択してください。クライアントの入手先と対応プラットフォームはダウンロードセンターを基準にしてください。

更新結果 考えられる段階 確認するポイント
リクエストタイムアウト サブスクリプションのダウンロード ネットワーク、DNS、プロキシ更新設定
未認証が返る サブスクリプションへのアクセス リンクの有効性と完全なパラメーター
解析数が0 レスポンスの解析 レスポンス形式、ウェブページへのリダイレクト、クライアントの対応状況
成功したがリストが空 書き込みと表示 グループ、フィルター、上書き設定

chapter four

速度が遅い：ローカル帯域・ノード・ルーティングの影響を分けて確認する

速度の遅さは、1回ウェブページを開くまでの時間だけでは判断できません。初回アクセスにはDNS、TCP、TLS、コンテンツ読み込みが含まれ、ブラウザーキャッシュ、対象サイトの負荷、無線信号によって結果も変わります。同じ端末、同じネットワーク、近い時間帯で比較条件を作り、プロキシを無効にして基礎ネットワークを測定し、有効にして複数のノードを測定します。さらにグローバルモードと振り分けモードを比較します。条件を揃えてこそ、ボトルネックがローカル、ノード、ルールのどこにあるか判断できます。

再現可能な比較テストを作る

まず大容量ファイルの同期、システム更新、クラウドストレージへのアップロード、他の端末での高トラフィック処理を停止します。プロキシを無効にし、固定したテスト対象でダウンロード、アップロード、応答の状態を記録します。その後プロキシを有効にして、同じ対象でテストを繰り返します。それぞれの状態で少なくとも2回実行し、明らかに異常な1回は除外します。テスト中にWi-Fi帯域、ブラウザー、ノード、DNSを同時に切り替えないでください。そうすると結果を比較できません。

無線ネットワークでは、信号品質と干渉に特に注意します。ルーターに近づけて速度が明らかに回復するなら、主なボトルネックはプロキシではありません。パソコンでは有線ネットワークに切り替えて比較し、AndroidではWi-Fiとモバイルネットワークを一度切り替えてみます。モバイルネットワークへ切り替えるとアドレスとルーティングも変わるため、現在のWi-Fiに異常があるかを判断するためだけに使います。2種類のネットワークの絶対速度を、そのままノード品質の差と見なさないでください。

遅延テストと実際のスループットを正しく理解する

遅延テストが示すのは、接続の確立や特定のリクエストの完了に必要な時間であり、継続的なダウンロード速度ではありません。低遅延のノードでも帯域が限られることがあり、高遅延のノードでも大容量ファイルの転送を安定して行える場合があります。実接続テストは完全に使えないノードを除外するのに役立ちますが、ノード選択では対象へのアクセス、継続転送、安定性も考慮してください。1回の順位だけで頻繁に切り替えないでください。接続を何度も再確立すると、それ自体が待ち時間を増やします。

同じサブスクリプション内の2～3個のノードを選んでテストします。すべてのノードが基礎ネットワークより大幅に遅い場合は、追加の多段プロキシ、複雑すぎるルーティング、不適切なトランスポート設定が有効になっていないか確認します。特定のノードだけ遅い場合は、まずノードを変更します。ピーク時だけ遅く、それ以外は正常なら、経路やサーバー側の負荷変動が原因であることが多く、ローカルでクライアントを再インストールしても上流の容量は変わりません。

振り分け、同時実行数、アプリのプロキシ方式を確認する

グローバルモードでは、本来直接接続できる大容量ファイル、システム更新、LANサービスを含むすべてのリクエストがプロキシを通ります。これによりノードの負荷が増え、LANアクセスが遠回りになることもあります。LANをバイパスする設定や適切な振り分けモードへ戻し、ローカルアドレス、プリンター、ストレージ機器、よく使う直接接続ドメインが正しい出口へ送られることを確認します。カスタムルールは具体的なものから広いものの順に並べ、広すぎるプロキシルールが全トラフィックを先に捕捉しないようにします。ルールの構文と優先順位はdomain・ip・geositeルーティングルールの解説を参照してください。

ブラウザー拡張、ダウンロードツール、開発環境はシステムプロキシを使わず、独自のSOCKSまたはHTTPポートを設定していることがあります。ポートの種類を間違えると、一部のリクエストが失敗して再試行され、速度低下として現れます。アプリの設定で、プロトコルの種類がクライアントのインバウンドと一致しているか確認します。SOCKSプロキシをHTTPプロキシ欄に入力しないでください。コマンドラインツールはHTTP_PROXY、HTTPS_PROXY、ALL_PROXYを読み取ることもあり、古い環境変数が現在のシステム設定を上書きする場合があります。

DNSの特定モードを有効にしたときだけ遅くなる場合は、名前解決サーバーの応答遅延、誤ったフォールバック、ドメインに対する不適切な出口が原因かもしれません。まずクライアントのDNS設定を初期状態に戻してコアを再起動し、最初のリクエストと後続リクエストの違いを確認します。最初だけ遅く、更新後は正常ならDNSまたは接続確立の問題に近く、転送中も速度が低いなら回線帯域、ノード負荷、ローカルネットワーク品質の問題に近いと考えられます。

chapter five

DNSの問題：名前解決の結果からルーティング出口まで段階的に確認する

DNSはドメインを接続可能なアドレスへ変換します。「IPアドレスではアクセスできるがドメインでは開けない」「一部のドメインが断続的に失敗する」「接続ログにlookup errorが出る」といった場合は、DNSを独立した要素として確認します。V2Rayクライアントはシステムの名前解決を使うこともあれば、コアの設定でサーバー、問い合わせ方式、出口を指定することもあります。システムDNSとクライアントDNSを同時に変更すると、問題が重なって原因を特定しにくくなります。

本当にドメイン名前解決の失敗か確認する

プロキシを無効にした状態と有効にした状態で、同じ問題のドメインを問い合わせ、アドレスが返るか確認します。Windowsでは次を使用できます：

nslookup example.com

LinuxまたはmacOSでは次を使用できます：

dig example.com
# dig がシステムにない場合
nslookup example.com

問い合わせ結果が返っても最終的な接続成功を保証するものではありません。ただし、結果がまったく返らない、サーバーエラーが返る、長時間待たされる場合は、名前解決経路をさらに確認する必要があります。ブラウザーが独自の暗号化DNSを有効にしていると、システムコマンドとは別の名前解決経路を使います。ブラウザー設定を一時的にシステムの既定値へ戻し、もう一度比較してください。コマンドは正常なのに特定のブラウザーだけ失敗する場合は、ブラウザーのキャッシュ、拡張、独自DNS設定を優先して確認します。

キャッシュを消去し、制御点を一つに戻す

ドメインレコードの変更後、システム、ブラウザー、クライアントのそれぞれに古いキャッシュが残ることがあります。Windowsでは管理者ターミナルで次を実行できます：

ipconfig /flushdns

消去後はブラウザーを完全に終了し、クライアントのコアを再起動します。Linuxのキャッシュ方法はシステムサービスによって異なるため、まずsystemd-resolvedを使用しているか確認し、その後次を実行します：

resolvectl status
sudo resolvectl flush-caches

同じ切り分け中に、ルーターのDNS、システムDNS、ブラウザーDNS、クライアントDNSを同時に変更しないでください。まずブラウザーをシステム設定に従う状態へ戻し、クライアントDNSも初期状態に戻して、観察できる設定をシステム側の1か所に限定します。基礎的な名前解決が正常だと確認してから、クライアントのリモート名前解決、ドメインポリシー、振り分けDNSを一つずつ有効にします。これにより、どの層で異常が発生したか特定できます。

問い合わせ方式と出口の関係を確認する

設定のdomainStrategyは、ルーティングルールがいつ名前解決結果を使うかを決めます。AsIsはドメインを保持したまま照合する傾向があります。その他の方式では、必要に応じてIPへ解決してからIPルールを適用することがあります。これは単純な「DNSのオン・オフ」ではなく、変更するとルールの適用結果にも影響します。geoipに依存するルールで、ドメインがIPへ解決されなければ、該当ルールが期待どおり機能しない可能性があります。逆に早すぎる名前解決は、ドメインルールが先に適用される機会を失わせることがあります。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

上の例はドメインを保持し、プライベートアドレスを直接接続の出口へ送る設定です。実際のクライアントではグラフィカルインターフェースが完全な設定を生成することがあり、クライアントが管理する設定ファイルを直接上書きしないでください。カスタマイズが必要な場合は、まず現在の設定を参考用にエクスポートし、関係する項目だけを変更して、コアの再起動後に生成ログを確認します。JSONのカンマ、引用符、階層を誤ると、DNS部分だけでなく設定全体の読み込みに失敗します。

DNS問い合わせ自体がどの出口を通るかにも注意します。指定した名前解決サーバーへ特定の経路でしかアクセスできないのに、DNSリクエストが別の出口へ誤送信されると、「ノードには接続できるがドメインを解決できない」状態になります。まずクライアントの初期設定で検証し、必要に応じてDNSの出口を指定します。LAN内のドメイン、端末名、内部サービスは通常ローカル名前解決に依存します。すべてをリモートDNSへ送るとローカル機器を見つけられなくなるため、プライベートドメインとプライベートアドレスには直接接続経路を残してください。

症状 よくある原因 確認方法
すべてのドメインで失敗する システムDNSが使えない、またはDNSの出口が誤っている システムとクライアントを個別にテストする
ブラウザーだけ失敗する ブラウザー独自のDNS、キャッシュ、拡張 システムDNSに戻し、拡張を無効にする
LAN内の名前が使えない ローカルの問い合わせがリモート名前解決へ送られている プライベートドメインにローカル経路を残す
初回アクセスが非常に遅い 問い合わせのタイムアウト後にフォールバックしている ログで名前解決の所要時間とエラーを確認する

chapter six

システムプロキシが機能しない：接管範囲とポートの一致を確認する

クライアントに「システムプロキシが有効」と表示されても、OSのプロキシ項目が書き込まれたことを示すだけで、すべてのアプリがその項目に従うとは限りません。ブラウザーは通常システムプロキシに従いますが、一部のコマンドラインツール、ストアアプリ、ゲーム、独自のネットワークプログラムはシステム設定を無視することがあります。切り分けでは、まずローカルプロキシサービスが正常か確認し、次に対象アプリがどのプロキシ方式を使うかを確認し、最後にシステムプロキシのアドレスとクライアントの待受ポートが一致しているか確認します。

プロキシアドレスと待受ポートを確認する

v2rayNの設定でローカルHTTP、SOCKS、混合インバウンドのポートを確認し、OSのプロキシ設定を開いて、アドレスがローカルのループバックアドレスであり、ポートがクライアント表示と一致することを確認します。ポートを変更しても、古いシステムプロキシの値が常に自動同期されるとは限りません。システムが古いポートを指している場合は、まずシステムプロキシを無効にし、クライアントのメニューから再度有効にします。サーバーポートをシステムプロキシに入力しないでください。システムプロキシが接続するのは遠隔ノードではなく、ローカルのクライアントです。

WindowsではPowerShellで現在のユーザーのプロキシ設定を確認できます：

Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" |
  Select-Object ProxyEnable, ProxyServer, AutoConfigURL

ProxyEnable、ProxyServer、自動構成URLが同時に存在することがあります。以前プロキシスクリプトを使っていた場合、AutoConfigURLがアプリの動作に影響し続ける可能性もあります。まず元の値を記録し、システム設定で不要になった自動構成を無効にします。企業や組織のポリシーなど、内容を理解していない設定を直接削除しないでください。管理対象端末では、先にネットワークポリシーの要件を確認します。

システムプロキシ、TUN、アプリ独自のプロキシを区別する

システムプロキシが主に影響するのは、OSのプロキシ設定を読み取るアプリです。TUNモードは仮想ネットワークインターフェースを通じて、より広い範囲のトラフィックを接管します。両者は同じスイッチではなく、障害の原因が不明な状態で同時に何度も切り替えるべきではありません。ブラウザーは使えるのに特定のアプリが使えない場合は、そのアプリがシステムプロキシに対応しているかを確認します。アプリにHTTPまたはSOCKS設定がある場合は、クライアントのインバウンド種類に合わせてローカルアドレスとポートを手動入力します。アプリがプロキシにまったく対応していない場合にTUNの利用を検討し、システムプロキシの問題をいきなり全体構成の変更へ広げないでください。

コマンドラインツールには独自設定があることが多いです。一時的な環境変数を例にすると、HTTPプロキシとSOCKSプロキシでは形式が異なります：

# HTTP プロキシの例
set HTTPS_PROXY=http://127.0.0.1:10809

# PowerShell の現在のセッション
$env:HTTPS_PROXY="http://127.0.0.1:10809"

ポートは書式を示す例にすぎないため、クライアントの実際のHTTPインバウンドポートへ置き換えてください。環境変数は現在のセッションまたは子プロセスにだけ適用されますが、永続変数はクライアント終了後も残ることがあります。切り分けが終わったら不要な変数を削除し、「システムプロキシを無効にしたのにコマンドラインだけ古いポートを使う」状態を避けます。

プロキシの残留設定とLANの例外を処理する

クライアントの異常終了、システム更新、アカウント切り替えの後にプロキシ項目が残ることがあります。典型的には、タスクトレイにクライアントが表示されていないのに、ブラウザーがプロキシサーバーによる接続拒否を表示します。この場合はシステム設定でプロキシを手動で無効にし、クライアントを再起動して、コアが待ち受けていることを確認してから再度有効にします。クライアントを再起動しても誤ったポートが自動的に設定される場合は、ローカルポートの重複や、複数のv2rayNインスタンスが同時に動作していないか確認します。

LANアクセスに異常がある場合は、プロキシの例外設定とルーティングルールを確認します。ループバックアドレス、プライベートネットワーク、本地域名は通常直接接続にします。プロキシのバイパスリストはシステム設定に従うアプリだけに影響します。一方、V2Rayコアのルーティングルールは、コアに入ったリクエストがどの出口から出るかを決めます。両者は階層が異なるため、一方だけを変更してもすべてのアプリは直りません。まずIPアドレスでLAN機器へアクセスし、次に機器名でアクセスします。IPでは正常で名前だけ失敗する場合は、DNSの章に戻ってローカル名前解決を確認します。

一方のブラウザーは正常で、もう一方だけ失敗する場合は、両方がシステムプロキシを使用しているか比較します。拡張機能がプロキシを固定したり、自動構成スクリプトや直接接続モードを強制したりすることがあります。拡張を読み込まない一時的なブラウザープロファイルを作ってテストすると、拡張を一つずつ推測するより早く確認できます。システムプロキシに従うすべてのアプリが失敗する場合は、待受ポートとコアのログに戻ります。特定のアプリだけ失敗する場合は、通常そのアプリ自身の設定に問題があります。

chapter seven

クライアントがクラッシュする：ログを保存し、実行条件を減らす

クライアントが起動しない、開くとすぐ終了する、設定のインポート中に固まる、しばらく動作した後にクラッシュする場合は、まずグラフィカルインターフェースとコアプロセスを区別します。画面が終了してもコアが同時に停止したとは限らず、コアのエラーが画面のクラッシュを引き起こすとも限りません。対応前に、操作内容、ログの場所、システム環境を記録し、最小構成で起動してからサブスクリプション、ルーティング、追加機能を段階的に戻します。

画面の終了かコアの失敗かを確認する

まずタスクトレイとタスクマネージャーを確認します。v2rayNはメインウィンドウを閉じてもタスクトレイに残ることがあります。本当にクラッシュした場合は画面のプロセスが消え、システムイベントにアプリケーションエラーが残ることがあります。画面は残っているのにノードへ接続できない場合は、クライアントの実行ログを確認します。これはコアの起動または設定読み込みの失敗に近い症状です。画面自体が表示されない場合は、アプリケーションログ、システムイベント、実行ディレクトリの権限、依存環境を確認します。

Windowsでは「イベント ビューアー」を開き、Windowsログのアプリケーション欄から障害時刻に該当する記録を探します。Linuxのデスクトップ版ではターミナルからアプリを起動して標準出力を確認し、現在のユーザーサービスのログも確認します。ユーザー単位の自動起動を設定している場合は、次を実行できます：

systemctl --user status v2rayn
journalctl --user -u v2rayn --since today

サービス名は実際に作成されたユニットに合わせてください。Linuxのインストールとユーザー単位の自動起動についてはv2rayN Linuxデスクトップ版インストールガイドを参照できます。macOSで起動できない場合は、アプリが安定したディレクトリにあること、現在のアカウントが設定ディレクトリを読み取れることを確認し、システムログから起動時刻に該当するエラーを探します。

空の設定で基本起動を検証する

設定ファイルを操作する前に、クライアントと関連するコアプロセスを終了し、設定ディレクトリをバックアップします。唯一の設定を直接削除しないでください。現在の設定ディレクトリ名を変更して、クライアントに新しい初期設定を生成させます。空の設定で起動できるなら、プログラム本体は動作しており、問題は古い設定、サブスクリプションデータ、ルーティングルール、画面状態にある可能性が高いです。その後、古いディレクトリ全体を一度に戻さず、サブスクリプション、ルーティング、カスタムDNS、画面設定の順に一つずつ復元します。

特定の設定をインポートした直後にクラッシュする場合は、バックアップから最近変更したサブスクリプションまたはノードを特定します。異常に長いノード名、壊れたJSON、誤ったエンコード、不完全なインポート内容が解析問題を引き起こすことがあります。JSONを手動編集する場合は、UTF-8に対応したテキストエディターを使用し、まず基本構文を確認します。次のコマンドは、PythonがインストールされたデスクトップシステムでJSONを解析できるか検証できます：

python -m json.tool config.json

このコマンドが確認するのはJSONの構文だけで、V2Rayのフィールドがクライアントの要件を満たすかどうかは検証しません。構文が通った後も、ログを基にアウトバウンドのタグ、ルーティング参照、DNSサーバー、プロトコル項目を確認します。クライアントが自動生成するファイルは終了時に上書きされる可能性があるため、クライアントの実行中に直接編集しないでください。

権限、占有、リソース負荷を確認する

アプリケーションディレクトリまたは設定ディレクトリに書き込めない場合、クライアントは設定の保存、サブスクリプションの更新、実行ファイルの展開に失敗することがあります。アプリは、現在のユーザーが正常に読み書きできる場所へ置き、圧縮ファイルのプレビューから直接実行しないでください。企業端末、管理対象ディレクトリ、同期ドライブには追加の権限やファイルロックがある場合があります。テストでは通常のユーザーディレクトリへ移してください。ディレクトリの問題を隠すために、管理者権限を常用しないでください。まず実際にどのファイルへの書き込みが必要かを確認します。

セキュリティソフトが新しいプロセスの起動を阻止したり、ローカル待受を制限したり、実行ファイルを隔離したりすることがあります。システムの記録に明確なブロックイベントがあるか確認し、組織のポリシーに従って対応してください。すべての保護機能を無闇に無効にしても安定した結論は得られず、ポートや権限の本当の問題を隠す可能性もあります。ブロック記録がない場合は、ポート占有、設定解析、依存関係のエラーを続けて確認します。

ノードやサブスクリプションが大量にあると、起動時の解析、画面描画、遅延テストによってリソース使用量が増えます。まず自動テストを停止し、重複したサブスクリプションを整理して、フィルター範囲を狭めます。大量テスト時だけクラッシュするなら、同時実行タスクを減らしてください。一定時間後もメモリ使用量が増え続ける場合は、操作とリソース変化を記録し、現在のプラットフォーム向けクライアントを再取得して上書きインストールします。上書き前に設定をバックアップし、インストール後はまず初期設定で起動してから必要な内容だけをインポートします。

chapter eight

モバイル端末の問題：Androidのバックグラウンド、VPN、ネットワーク切り替え

Androidのv2rayNGとv2flyNGは通常、システムVPNインターフェースを通じてアプリのトラフィックを接管します。モバイル端末の障害には、ノードやサブスクリプションだけでなく、省電力設定、バックグラウンド制限、常時接続VPN、プライベートDNS、Wi-Fiとモバイルネットワークの切り替えも影響します。切り分けの順序は基礎ネットワークから始めますが、クライアントがバックグラウンドで継続動作できるか、現在のVPNインターフェースが他のアプリに使用されていないかも確認してください。

システムVPNインターフェースと基礎ネットワークを確認する

まずクライアントの接続を停止し、現在のWi-Fiまたはモバイルネットワークでブラウザーから通常のウェブページを開けることを確認します。次にv2rayNGまたはv2flyNGを起動し、システムのVPN接続要求を許可して、ステータスバーにVPNアイコンが表示されるか確認します。システムにすでにVPNが実行中と表示される場合は、VPNインターフェースを使う他のアプリを先に終了します。Androidでは同じユーザー領域で通常、一つの主要なVPNインターフェースしか維持できず、複数のアプリが同時に接管することはできません。

接続ボタンは起動済みなのにステータスバーにVPNアイコンがない場合は、システムが権限を取り消していないか、インターフェース作成時にクライアントが直ちにエラーを出していないか確認します。システムのVPN設定を開き、「常時接続VPN」と「VPNなしの接続をブロック」などの項目を確認します。これらが別のアプリに紐付いていると、現在のクライアントが正常に動作しない可能性があります。現在のクライアントに紐付いていてもノードが使えない場合、直接接続のブロックによってすべてのネットワークが切断されたように見えます。切り分け中は強制項目を一時的に無効にし、基本接続を確認してから必要に応じて戻してください。

バックグラウンド停止と画面ロック後の切断に対処する

前面では正常に使えるのに、数分ロックすると切断される場合は、バッテリー最適化とバックグラウンド動作制限を重点的に確認します。現在のクライアントを制限なし、またはバックグラウンド実行を許可する対象に追加し、必要なフォアグラウンドサービス通知も許可します。端末によって設定名は異なりますが、判断方法は同じです。画面点灯中は安定し、ロック後にプロセスやVPNアイコンが消えるなら、ノード障害よりもシステムによるプロセス回収が疑われます。

システムによってはアプリごとにバックグラウンドデータも制限します。クライアントがWi-Fi、モバイルデータ、バックグラウンドデータを使用できることを確認します。モバイルネットワークでだけ失敗する場合は、そのアプリのモバイルデータ権限が無効になっていないか確認してください。データセーバーはバックグラウンド接続を制限することがあるため、テスト中はクライアントを制限なしに設定します。変更後は最近使ったアプリ一覧からクライアントを閉じ、再度開いて新しいシステムポリシーを新しいプロセスへ適用させます。

複数の「自動起動」「バックグラウンド保護」ツールを同時に有効にし、システム状態を何度も変更することはおすすめしません。まずシステムのバッテリーとデータ権限だけを調整し、しばらく様子を見ます。問題が解消したら、他の制限を一つずつ戻します。接続ログのEOF、network changed、インターフェース終了のメッセージを、VPNアイコンが消えた時刻と照らし合わせると、ネットワーク切り替え、システムによる回収、遠隔側からの切断を判断しやすくなります。

プライベートDNS、アプリごとのプロキシ、ネットワーク切り替えを確認する

AndroidのプライベートDNSはシステムのネットワーク設定にあり、クライアント内部のDNSとは別の層です。ドメインを解決できない場合は、プライベートDNSを一時的に自動へ戻し、クライアントDNSも初期状態にしてから再接続します。正常に戻ったら、どちらか一方だけを個別に有効にします。プライベートDNSのホスト名自体を解決できない、または接続できない場合、クライアントがVPNを確立する前にシステム側でドメイン問題が発生することがあります。

アプリごとのプロキシでは、どのアプリをVPNへ入れるか指定できます。ブラウザーは正常なのに対象アプリが通信できない場合は、そのアプリが包含リストにあるか、除外されていないか確認します。モードを切り替えた後も、一部の確立済み接続が古いネットワークを使い続けることがあります。対象アプリを完全に終了してから再度開いてください。システムコンポーネント、ダウンロードサービス、アプリのメインプロセスが別々のプロセスでリクエストを行うこともあるため、表示上のアプリだけを選択しても全トラフィックをカバーできない場合があります。切り分けでは一時的にすべてのアプリをVPNへ入れ、確認後に範囲を絞ります。

Wi-Fiとモバイルネットワークの切り替えは、基礎となる接続を変えます。切り替え後は通常、クライアントがセッションを再構築するため、短時間の中断は接続再構築の過程です。長時間復旧しない場合は、接続を手動で停止して再起動します。特定のWi-Fiだけで失敗する場合は、そのネットワークの認証ページ、DNS、ルーティングを確認します。モバイルネットワークだけで失敗する場合は、クライアントのデータ権限、ネットワーク種別、対象アドレスへの到達性を確認してください。ネットワーク切り替え前後のテスト結果を混ぜて比較しないでください。

モバイル端末の症状 優先して確認する項目 対処の方向性
画面ロック後に切断する バッテリー最適化、バックグラウンド制限 バックグラウンドとフォアグラウンドサービスの実行を許可する
VPNを作成できない 他のVPNアプリ、システム権限 インターフェースを解放して再認証する
一部のアプリだけ失敗する アプリごとのプロキシリスト 一時的にすべてのアプリでテストする
ネットワーク切り替え後に復旧しない 古いセッションと基礎ネットワークの変化 停止して接続を再確立する
ドメインは失敗するが接続は存在する プライベートDNSとクライアントDNS DNSの制御点を一つに戻す

この章を終えても判断できない場合は、トラブルシューティングで問題の分類から短い回答を探してください。再設定が必要な場合は、クイックスタートガイドに戻り、サブスクリプションのインポート、ノード選択、接続確認を最初から行います。検証していない変更を古い設定へ続けて重ねないでください。