V2Ray クライアントのトラブルシューティング 症状別に切り分け

01 / 切り分けの基本変数を固定してから層ごとに切り分ける

トラブルシューティングで最もありがちな失敗は、複数の設定項目を同時に変更してしまうことです。ノード、プロトコル、ルーティング、DNS をまとめて変えると、たとえ接続が回復しても、どの変更が効いたのか分からなくなります。このページのすべての章は同じ手順に従います。まず現在の環境を固定し、経路をいくつかの区間に分け、クライアントに最も近い区間から検証を始め、1 つの区間が通ることを確認してから次へ進みます。

プロキシの経路は 6 つの区間に分けられます。アプリのリクエスト送信、ローカルのインバウンドポート、ローカルのコアプロセス、アウトバウンド接続(プロトコルと転送方式)、リモートサーバー、目的のサイトです。各区間には個別に検証できるチェックポイントがあり、下の表にまとめています。以降の章の切り分け作業は、この区間を単位に進めます。

始める前に 4 つの情報を固定する

1. クライアントとコアのバージョン — v2rayN のログ先頭行にはコア名とバージョンが出力されます。コア(V2Fly と Xray)によって同じ設定の対応範囲が異なるため、フィールドのエラーが出たらまずコアを確認します。
2. ローカルのインバウンドポート — 設定で SOCKS と HTTP のポート番号をそれぞれ控えておきます。以降のコマンドライン検証では必ずこの 2 つのポートを使います。
3. 現在のアウトバウンドパラメータ — プロトコル(VLESS、VMess、Trojan など)、転送方式(tcp、ws、grpc)、TLS の有無、SNI または Host の値。
4. システムプロキシと TUN の状態 — クライアントがプロキシを OS に書き込んでいるか、TUN モードで全トラフィックを引き受けているかを確認します。この 2 つのモードでは対処の方向がまったく異なります。

あわせて切り分けメモを用意し、再現した時刻、そのときのネットワーク環境(Wi-Fi か有線か、ネットワークを切り替えたか)、変更した設定項目を記録します。「調子が良いときと悪いときがある」問題の多くは、このメモで規則性が見つかります。たとえば特定のネットワークでのみ発生する、スリープ復帰後にだけ発生する、といった具合です。

ログレベルを上げて、もう一度再現させる

デフォルトのログレベルでは警告しか出力されず、情報量が足りません。不具合を再現させる前にレベルを info か debug に上げ、再現が終わったらすぐ戻してログファイルが肥大化しないようにします。ログの各行にはタイムスタンプが付くので、システムのイベントと秒単位で突き合わせられます。ログの構造とよくあるエラーの読み方は「v2rayN の動作ログの読み方」で詳しく解説しています。

コマンドラインでコアを単独実行する

クライアントのログパネルは、実質的にはコアプロセスの標準出力です。設定を config.json としてエクスポートしたら、コマンドラインで手動実行し、GUI 層の影響を排除して確認できます。

# Xray コア:設定の検証のみ、サービスは起動しない
xray run -test -config config.json

# Xray コア:フォアグラウンドで起動し、ログを端末に直接出力
xray run -config config.json

V2Fly コアの場合は、コマンドを v2ray test -config config.json と v2ray run -config config.json に置き換えます。引数の意味は同じです。

最後に 1 つの判断原則です。同じサブスクリプション内の複数ノードが同時にタイムアウトする場合は、ローカルネットワーク、サブスクリプション自体、クライアント設定を優先的に疑います。特定のノードだけがタイムアウトする場合は、そのノードのサーバーと回線を優先的に疑います。この原則が、第 03 章と第 04 章のどちらへ進むかの判断基準になります。

02 / 症状 1接続済み表示なのにページが開かない

クライアントの「接続済み」は、ローカルのコアプロセスが起動し、インバウンドポートがリッスンを開始したことしか示していません。データがアウトバウンドを通って目的のサイトまで届くことを意味するものではありません。この症状は範囲が最も広く、以下の 4 つの手順で問題の区間を特定できます。

ステップ 1:ローカルポートがリッスンしているか確認する

# macOS / Linux
lsof -nP -iTCP:10808 -sTCP:LISTEN

# Windows
netstat -ano | findstr "10808"

何も出力されない場合は、インバウンドが起動していません。クライアントのプロセスが実際に動作しているか、設定のインバウンドポートが他のプログラムに占有されていないかを確認します。対処法は第 07 章を参照してください。

ステップ 2:curl でブラウザを介さずプロキシを直接テストする

curl -x socks5h://127.0.0.1:10808 -I https://www.example.com
curl -x http://127.0.0.1:10809 -I https://www.example.com

2 つのコマンドで SOCKS と HTTP のインバウンドをそれぞれテストします。結果の見分け方は次のとおりです。

• 両方ともレスポンスヘッダーが返る:プロキシ経路は正常で、問題はブラウザまたはシステムプロキシ層にあります。第 07 章へ進んでください。
• 両方とも通らない:アウトバウンドまたはリモート側に問題があります。第 03 章へ進んでください。
• 片方だけ通る:該当ポートのインバウンド設定またはプロトコル種別に問題があります。設定で両方のインバウンドが有効になっているか確認してください。

socks5h の h は、ドメインの名前解決をプロキシ側に任せることを意味します。h を付けない場合は、本機が先に IP へ解決してからプロキシに渡します。テスト時に socks5h を使うと、本機の DNS の影響を排除できます。両者の違いは第 06 章で詳しく扱います。

ステップ 3:ルーティングルールで目的の通信が直接接続になっていないか確認する

クライアントの一般的な分流プリセットには、「ドメインの地域別に振り分ける」ルールが含まれていることがあります。目的のドメインが直接接続と判定され、その直接接続の回線自体が通らない場合、ブラウザ上の挙動は「プロキシが効いていない」ときとまったく同じになります。特定するには、ログレベルを info に上げて目的のサイトへアクセスし、該当リクエストのアウトバウンドタグが直接接続かプロキシかを確認します。

誤判定だと確認できた場合、対処は 2 つあります。ルーティング設定でそのドメインをプロキシのルールに追加するか、一時的にデフォルトのアウトバウンドをプロキシに変えて、ルールが原因かどうかを検証します。参考になるルールの骨組みは次のとおりです。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      { "type": "field", "domain": ["geosite:cn"], "outboundTag": "direct" },
      { "type": "field", "domain": ["geosite:geolocation-!cn"], "outboundTag": "proxy" }
    ]
  }
}

ルールは上から下へ照合され、先に一致したものが適用されるため、より具体的な項目を前に書きます。この話題は「ルーティングルール設定の実践」でより詳しく解説しています。

ステップ 4:直接接続と比較し、目的のサイト側の問題を除外する

プロキシを経由しないネットワークで同じサイトにアクセスします。直接接続でも開けないなら、問題はクライアント側ではないので、設定を変更し続ける必要はありません。単純に見えるこの手順が、「半日調べた末に相手サイトの障害だった」というケースのかなりの部分を防いでくれます。

03 / 症状 2ノードのタイムアウトとハンドシェイク失敗

この種の問題に共通するのは、ローカルのコアは動作しているのにデータが出ていかない点です。ログには明確なエラー行が残るので、まずキーワードで分類し、それから調査の方向を決めると、設定を 1 項目ずつ変更するよりはるかに速く解決できます。

ログキーワード早見表

まず接続性をテストし、それから設定を疑う

# Linux / macOS:TCP ポートに接続できるかテスト
nc -vz 203.0.113.10 443

# Windows PowerShell
Test-NetConnection -ComputerName 203.0.113.10 -Port 443

例のアドレスはドキュメント用のアドレス帯から取っています。実際に使うときは自分のノードのサーバーアドレスとポートに置き換えてください。結果の判断は次のとおりです。

• ポートが通らない:サーバーがリッスンしていない、サーバー側のファイアウォールで遮断されている、あるいは回線レベルで到達できない状態です。まずサーバー側の状態を確認し、それからポートや回線の変更を検討します。
• ポートは通るのにクライアントがタイムアウトを報告する:クライアントに入力したアドレスがドメインか IP かを確認します。ドメインの場合、名前解決の段階に問題がある可能性があるので第 06 章へ進んでください。
• ICMP ping が通らないからといってポートが通らないわけではありません。多くのサーバーはデフォルトで ping に応答しないため、TCP テストの結果を基準にしてください。

認証パラメータと時刻のずれ

VMess プロトコルは認証にタイムスタンプを使うため、クライアントとサーバーの時刻のずれが許容範囲を超えると即座に拒否されます。システム時刻の自動同期が有効か確認してください。仮想マシンやデュアルブート環境では、長時間のスリープ後に時刻がずれるのがよくある原因です。UUID やパスワードなどの認証情報は大文字と小文字を区別するため、コピーの際に末尾の文字を落としやすいので注意してください。

TLS と転送パラメータ

• TLS を有効にしたノードでは、SNI がサーバー側の証明書と一致している必要があります。間違っているとハンドシェイク失敗になります。
• REALITY ノードには正しい serverName と公開鍵(publicKey)が必要で、どちらも欠かせません。この 2 つのパラメータの仕組みは「REALITY と XTLS Vision の解説」で説明しています。
• 転送方式が ws または grpc の場合、path と host はサーバー側と一致させる必要があり、大文字と小文字も区別されます。
• 転送層の host フィールドと TLS の SNI は別のパラメータです。互いに混同して入力しないでください。

複数のノードが同時にタイムアウトし、接続性テストもすべて失敗する場合は、疑う対象を個々のノードからローカルネットワークの出口やサブスクリプション自体に移します。特定のノードだけが決まった時間帯にタイムアウトする場合は、時間の傾向を記録してサービス提供元に確認してください。

04 / 症状 3サブスクリプション更新失敗とノードリストの異常

サブスクリプションはノードリストの供給元です。更新に失敗すると、ノードがすべて消える、リストが古い内容のままになる、更新ボタンが回転した後にエラーが表示される、といった形で現れます。まずサブスクリプションの内容自体を取得できるかを確認し、その後にクライアント側を見ます。順序を逆にしないでください。

ステップ 1:コマンドラインでサブスクリプションを直接取得する

curl -L -A "v2rayN" -o sub.txt "https://example.com/api/v1/client/subscribe?token=xxxx"
head -c 300 sub.txt

1 つ目のコマンドでサブスクリプションの内容をファイルに保存し、2 つ目で先頭 300 文字を表示して戻り方の形式を判断します。

• base64 文字列が返る:これは正常なノードリストのエンコード形式で、問題はクライアント側にあります。
• HTML ページが返る:サブスクリプションのアドレスが無効になっているか、リクエストが中間層で遮断されてエラーページに転送されています。
• 404 または 403 が返る:アドレスの期限切れ、token の誤り、あるいはサーバー側が User-Agent を制限している可能性があります。例の -A "v2rayN" は User-Agent を指定するもので、一部のサーバーはこれでリクエスト元を判別しています。

サブスクリプションを更新するには、まずノードが必要

サブスクリプションのサーバーがプロキシ経由でしか到達できないネットワークにあり、その時点でクライアントに使えるノードが 1 つもない場合、「ノードがない → サブスクリプションを更新できない → さらにノードがない」という循環に陥ります。対処は 2 つあります。サブスクリプション設定で「プロキシ経由で更新」を有効にし、先に使えるノードを 1 つ手動でインポートするか、サブスクリプションサーバーへ直接接続できるネットワークで一度更新を完了させ、ノードをインポートしてからネットワークを切り替えます。

更新後にノードが減る、または消える

• グループフィルタ:名前や地域で絞り込むグループを設定していないか確認します。フィルタで除外されたノードは表示されません。
• 上書き:一部のクライアントでは、サブスクリプションの更新がそのグループの内容を丸ごと置き換えます。手動で追加したノードは別のグループに入れ、上書きされないようにします。
• 重複の統合:同じサーバーの複数の回線がインポート後に 1 つに統合されることがあり、数が減るのは正常な動作です。
• サーバー側の変更:サブスクリプションの内容自体が変わっています。最新の取得結果を基準にしてください。

自動更新と手動更新の違い

設定の更新間隔が自動更新の頻度を決めます。手動更新には通常 2 つの入口があります。完全更新はノードリストを再取得して上書きします。サブスクリプションの内容だけを更新する方法は現在選択中のノードを変更しないため、接続が安定しているときに現状を維持したい場合に向いています。切り分け中は、バックグラウンドの処理が判断を妨げないよう、自動更新を先にオフにすることをおすすめします。

05 / 症状 4接続できるのに遅い・頻繁に切断される

「遅い」には少なくとも 4 つの異なる現れ方があります。ハンドシェイクが遅い(ページが開くまでの待ち時間が長い)、帯域が低い(ダウンロード速度が上がらない)、変動が大きい(速くなったり遅くなったりする)、切断される(接続が途切れる)の 4 つです。それぞれ対処の方向が異なるので、まずどれに当てはまるかを見極めてから作業に入ります。

また、よく使われる 3 つの遅延の数値も区別してください。ping は ICMP の往復、実接続遅延はプロキシ経路の確立時間、ダウンロード速度テストは実際のスループットを測るものです。3 つは測定対象が異なるため、互いに代用できません。「遅延テスト 3 つの数値の比較」では、それぞれの数値の使いどころとよくある誤解を解説しています。

まず直接接続と比較する

同じ端末、同じ時間帯に、プロキシを経由せず同じ地域の大きなファイルのダウンロード先へアクセスし、速度を記録します。直接接続自体が不安定なら、問題はローカルネットワークか回線事業者の出口にあるため、クライアントを調整し続けても意味がありません。

トラフィックが実際にプロキシを通っているか確認する

ログで目的のドメインのアウトバウンドタグを確認します。遅い原因が、ルールによって直接接続に振り分けられ、その回線がたまたま混雑していただけという場合もあり、「プロキシが遅い」ように見えることがあります。

転送方式と多重化

• 多重化(mux):複数の接続を 1 本の TCP にまとめるもので、パケット損失が少ない回線ではハンドシェイクの負荷を減らせます。一方、損失が多い回線では 1 本の接続に問題が起きると、そこに多重化されたすべてのリクエストが遅くなります。オンとオフを切り替えて比較テストするとよいでしょう。
• 転送方式:tcp が最も直接的です。ws と grpc は特定のネットワーク環境ではより安定しますが、カプセル化が 1 層増える分のオーバーヘッドがあります。
• 暗号化アルゴリズム:性能の低い端末ではアルゴリズムによるスループットの差がはっきり出ます。変更して比較してみてください。

MTU とフラグメンテーション

大きなパケットが経路上で破棄されると、「ページは開くがダウンロードが止まる」「動画のバッファリングが長い」といった症状が典型的に現れます。クライアントまたはシステム側で MTU を段階的に小さくし、1 回につき 8〜16 バイト減らして改善するか観察します。変更後は一度再接続しないと反映されません。

切断のよくある原因

• サーバーの負荷変動や回線の切り替え。
• ローカルネットワークの切り替え:Wi-Fi と有線の切り替え、モバイルネットワークの基地局切り替え。
• システムのスリープ復帰後にプロキシプロセスの状態がおかしくなり、再接続が必要になる。
• 長時間アイドル状態の接続が中間機器に削除され、再接続で復旧する。

06 / 症状 5一部ドメインの名前解決異常

この種の問題の典型的な現れ方は、ほとんどのサイトは正常に開けるのに一部のドメインだけ開けない、名前解決された IP が実際と異なる、特定の地域のサイトへアクセスすると遅延が明らかに大きい、といったものです。共通しているのは、「ドメインが IP に変わる」段階で問題が起きている点です。

ドメインはどこで名前解決されるか

SOCKS プロキシを使う場合、名前解決を行う場所はクライアントの設定によって変わります。

• socks5h(h 付き)またはドメインスニッフィングを有効にした場合:ドメインはコアが DNS 設定に従って解決します。
• socks5(h なし)の場合:本機が先に IP へ解決してからプロキシに渡すため、本機の DNS の問題がそのままプロキシ経路に持ち込まれます。

切り分けでは、まず socks5h で一度テストすると、「本機の DNS の問題」と「プロキシ経路の問題」をすばやく切り分けられます。

クライアントの DNS 設定を調整する

{
  "dns": {
    "servers": [
      { "address": "1.1.1.1", "domains": ["geosite:geolocation-!cn"] },
      { "address": "223.5.5.5", "domains": ["geosite:cn"] }
    ]
  }
}

この設定は、地域ごとに異なる DNS サーバーへ問い合わせるようにして、地域をまたぐ名前解決による余分な遅延を減らします。変更後はコアプロセスを再起動しないと反映されません。

ルーティングルールの照合にはドメイン情報が必要

ドメイン単位のルーティングルールは、まずドメインを取得する必要があります。トラフィックが IP の形でコアに入るとドメインルールは照合できず、リクエストはデフォルトのアウトバウンドに流れます。ドメインスニッフィング(sniffing)を有効にすると、コアは HTTP リクエストや TLS ハンドシェイクの情報からドメインを復元できます。

{
  "inbounds": [
    {
      "tag": "socks-in",
      "port": 10808,
      "listen": "127.0.0.1",
      "protocol": "socks",
      "sniffing": { "enabled": true, "destOverride": ["http", "tls"] },
      "settings": { "udp": true }
    }
  ]
}

スニッフィングを有効にして初めて、ドメインルールとドメイン単位の分流が期待どおりに動作します。「ルールを書いたのに効かない」と感じたら、まずスニッフィングが有効か確認してください。

特定ドメインだけを個別に修正する

一部のドメインだけ名前解決がおかしい場合は、hosts 設定に正しいアドレスを固定で書くか、DNS 設定でそのドメイン専用のサーバーを指定します。変更範囲が小さいほど効果を確認しやすく、新たな問題も持ち込みにくくなります。

システムの DNS キャッシュを更新する

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux(systemd-resolved)
sudo resolvectl flush-caches

07 / 症状 6システムプロキシが効かない・ポート占有

典型的な現れ方は、クライアントは接続済みと表示され、ブラウザではページが開けないのに、コマンドラインの curl はローカルプロキシ経由で通るというものです。これはプロキシ経路自体に問題がなく、システムプロキシが書き込まれていない、書き込み先が違う、ポートが一致していないのいずれかであることを示しています。

各プラットフォームでシステムプロキシを確認する場所

システムプロキシが書き込まれないよくある原因

• クライアントの権限が足りず、システムプロキシの設定を変更できない。
• 他のプロキシ系ソフトが動作していて、同じ設定を取り合っている。
• ブラウザが独自のプロキシ設定や拡張機能を使っていて、システム設定を参照していない。
• システムプロキシは OS の設定を参照するアプリにしか効きません。一部のアプリは TUN モードでないと引き受けられません。

TUN モードとシステムプロキシの違い

ポートの占有

# Windows:ポートを占有しているプロセス ID を調べる
netstat -ano | findstr ":10808"
tasklist | findstr "<PID>"

# macOS / Linux
lsof -nP -iTCP:10808 -sTCP:LISTEN

占有しているプロセスが見つかったら、それを終了するか、クライアントのインバウンドポートを使用されていない別のポートに変更します。

ポート変更後に必要な一連の操作

1. クライアントの設定でインバウンドポートを変更して保存する。
2. 「システムプロキシ」のスイッチをいったんオフにしてからオンに戻し、新しいポートを OS に書き込む。
3. OS の設定でプロキシのアドレスとポートが一致しているか確認する。
4. curl で新しいポートを経由して検証し、経路が通ることを確認する。

08 / 症状 7クライアントの起動失敗と設定の破損

症状としては、ダブルクリックしても無反応、起動直後に終了する、画面は正常なのにコアが繰り返し再起動する、などが現れます。まず「クライアントの画面が起動しない」のか「コアプロセスが起動しない」のかを切り分けます。両者では調査の方向が異なります。

まず設定の構文を検証する

# Xray コア:設定の検証のみ、サービスは起動しない
xray run -test -config config.json

# V2Fly コア
v2ray test -config config.json

よくあるエラーとその意味:

• invalid character:JSON に不正な文字があります。余分なカンマ、コメント、全角の引用符がよくある原因です。
• unexpected of JSON input:括弧または引用符が閉じられていません。
• unknown field:フィールド名の綴りが間違っているか、現在のコアがそのフィールドに対応していません。

設定にコメントや末尾の余分なカンマがあると解析に失敗します。他の場所から設定の断片をコピーするときに、こうした問題が最も紛れ込みやすくなります。

コアが繰り返し再起動する

画面には実行中と表示されるのに、ログではコアプロセスが起動と終了を繰り返している場合、通常は設定の検証失敗かポートの占有が原因です。まずログレベルを debug に上げ、終了する直前の最後の行を確認してから、第 03 章と第 07 章の手順に沿って対処します。

権限とパス

• インストール先がシステムの保護されたディレクトリにある場合、設定の書き込みに管理者権限が必要になるため、データディレクトリをユーザーディレクトリへ移せます。
• パスに特殊文字が含まれる場合や階層が深すぎる場合、一部のシステムコンポーネントが読み込みに失敗することがあります。
• 設定ファイルの場所を移動した後は、クライアントが記録している古いパスが無効になります。

セキュリティソフトによるブロック

一部のセキュリティソフトはプロキシのコアをリスクのあるプログラムと判定し、通知なしにブロックします。典型的な現れ方は、プロセスが起動して数秒後に消えるのに、コマンドラインで同じ設定を手動実行すると正常に動くというものです。対処としては、セキュリティソフトでそのディレクトリを例外に追加するか、別のインストール先で試します。Windows での初回インストールの流れとつまずきやすい点は、「Windows に v2rayN をインストールする手順」で順を追って説明しています。

設定のバックアップと復元

設定を変更する前に一度エクスポートしておきます。起動の問題が出たらリセット機能で既定の設定に戻し、そこから 1 項目ずつ復元していくと、どの設定項目が原因かを特定できます。設定ディレクトリ全体を戻すより、ノードを手動でインポートするほうが安全で、元に戻すのも簡単です。

09 / 症状 8Android 特有の切り分け

Android で動作するのは v2rayNG(Xray コア)と v2flyNG(v2fly コア)です。どちらもデスクトップ版とは仕組みが異なり、スマートフォンでは VPN モードでトラフィックを引き受けるため「システムプロキシ」の層が存在しません。そのためデスクトップ版の切り分け項目の一部はスマートフォンには当てはまらず、逆もまた同様です。

2 つのクライアントの違い

同じ共有リンクはどちらにもインポートできますが、一部の新しいプロトコルのパラメータは Xray コアでのみ有効です。「インポートはできるのに接続できない」場合は、もう一方のクライアントで試して比較すると、パラメータの問題かクライアントの問題かをすばやく判断できます。両クライアントのインストールパッケージの入口はダウンロードページの Android セクションにあります。

接続できないよくある原因

• VPN の許可ダイアログを確認していない:初回接続時にシステムが許可のダイアログを表示するので、VPN 接続の確立を許可する必要があります。
• システム上で他の VPN 系アプリが動作している:同時に使用できる VPN チャネルは 1 つだけです。
• 省電力設定:アプリがバックグラウンドでシステムに終了され、通知バーのアイコンが消えて接続が切れます。
• アプリ別プロキシ:一部のアプリだけを選択している場合、選択していないアプリはプロキシを通りません。

サブスクリプションとノードの管理

スマートフォンでサブスクリプションの更新に失敗したら、まずネットワークを切り替えて試します。モバイルデータと Wi-Fi を入れ替えてみてください。更新後にノードの順序が変わるのは正常で、サブスクリプションの内容が基準です。サブスクリプションのアドレスには token が含まれるため、スクリーンショットを公開の場に投稿しないでください。ノードリストの整理方法はデスクトップ版と同じで、サブスクリプション更新失敗の判断手順は第 04 章をそのまま利用できます。

ログとセルフチェック

v2rayNG のログページではコアの出力を確認できます。切り分け方法はデスクトップ版と同じで、まずタイムスタンプに対応するエラー行を見て、タイムアウト、認証、DNS のどれなのかを切り分けます。スマートフォンにはコマンドライン環境がないため、検証はノードを変えての比較やネットワークを切り替えての比較が中心になります。

上記の 9 章で当てはまらない場合は、症状を 1 つの文に整理してみてください。どの操作を、いつ行い、ログの最後の行が何だったか、という形です。よくある質問ページにはテーマ別のより細かい Q&A を掲載しており、用語解説ページはログに出てくる用語の意味を確認するのに使えます。