v2rayN が接続できないとき：ポート・DNS・TLS の切り分け

一度に 1 つの質問に答えてください

コアが起動し、ローカルポートがリッスンしていることを確認し、明示的なプロキシリクエストと失敗したアプリケーションを比較します。 DNS、ノード、ポート、および TUN を一緒に変更する前に、障害のあるレイヤーを特定します。

1. 障害時の記録を残す

クライアントのバージョン、コアの名前とバージョン、OS、キャプチャ方法、ルーティングプロファイル、時間、再現性のある失敗したターゲットを記録します。全サイトの障害を 1 つのアプリケーションまたは 1 つのドメインから区別します。問題が更新、ネットワーク変更、または TUN アクティベーションの後に発生したかどうかに注意してください。

公式 FAQ はクライアントのログとコアのログを区別しています。画面操作や更新の問題では主に guiLogs を確認し、接続や設定の問題ではメイン画面に表示されるコア出力も確認します。^[1] 古いログを消去・分離する前に必要な記録を保存し、一度だけ再現してください。過去の無関係なエラーが混ざるのを防げます。

2. コアの起動と待受ポートを確認する

コア自体が起動できない場合、DNS の変更だけで解決することは通常ありません。まず設定解析エラー、実行ファイルの不足、権限、ポート競合を確認します。Windows PowerShell で待受状態を調べるときは、例の 10808 をクライアントに表示される実際のポートへ置き換えてください。

Get-NetTCPConnection -State Listen -LocalPort 10808 |
  Select-Object LocalAddress, LocalPort, OwningProcess

一致するオブジェクトがない場合は、このチェックでリスナーが見つからなかったことを意味します。リスナーが存在する場合は、そのプロセスが目的のコアに属していることを確認します。不慣れなプロセス、特にマネージドアプリケーション、VM コンポーネント、システムサービスをやみくもに終了しないでください。

lsof がインストールされている macOS または Linux では、以下を使用できます。Linux では ss -ltnp でも待受状態を確認できます。プロセスの詳細表示には追加の権限が必要な場合があります。

lsof -nP -iTCP:10808 -sTCP:LISTEN

3. 条件をそろえてプロキシ接続を比較する

比較の意味が変わらないよう、先に TUN を無効にします。ノードと宛先は固定してください。macOS または Linux では、以下の Windows 向け例の curl.exe を curl に置き換えます。

curl.exe --noproxy "*" --connect-timeout 10 --max-time 20 -I https://example.com/
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

最初のコマンドは curl のアプリケーション層でのプロキシ使用を無効にします。動作中の TUN、VPN、ネットワークゲートウェイを回避するものではありません。二つ目はローカル SOCKS プロキシを明示的に使い、宛先の名前解決を委ねます。^[2] 実際に接続できないホスト名でも両方を試してください。例示用のサイトで成功しても、業務サイトでの成功は保証されません。

宛先が HEAD リクエストを拒否する場合は -I を外します。403 や 429 が返る場合は、その応答が宛先、プロキシ、中間ゲートウェイのどこから来たかを確認してください。HTTP エラー応答と接続自体の失敗は別の問題であり、一律にノードの故障とは判断できません。

4. 観察した症状から調べる

観察する項目	最初に調べる項目	次に確認する情報
ローカルプロキシポートで接続が拒否されました	コアが実行されていません。ポートが間違っているか、バインドアドレスが異なります。	起動ログと待受プロセス
複数のプロファイルでコアの起動が失敗する	構成の互換性、バイナリまたはポートの競合	最初の明示的なエラーとコアバージョン
明示的プロキシは機能しますが、ブラウザは失敗します	システムプロキシ、拡張機能、またはアプリケーションのオーバーライド	新しいリクエストがコアに到達したかどうか
1 つのドメインのみが失敗します	そのルーティング、DNS、TLS、またはサーバー応答	ドメイン固有の接続ログと応答
TUN 有効時だけ失敗する	インターフェイス、DNS、権限またはルートの競合	TUN-off ベースラインと変更された動作
アップデート後に障害が発生する	クライアント/コアの互換性または移行された設定	リリースノートと古いセットアップの個別の比較

これらは調査の優先順位であり、1 対 1 の診断ではありません。タイムアウトはいくつかの段階で発生する可能性があり、ログと制御された比較の両方が必要です。

5. システムとプロキシの名前解決を区別する

Windows では、A レコードと AAAA レコードを個別にクエリして、システムリゾルバーパスの違いを探します。

Resolve-DnsName example.com -Type A
Resolve-DnsName example.com -Type AAAA

この結果は実行したシステム側の問い合わせを示すもので、プロキシで使われるすべての名前解決を示すものではありません。ブラウザーは暗号化 DNS、SOCKS は遠隔での名前解決、コアは独自の方針で選んだ DNS を使う場合があります。各テストがどの経路を確認しているか記録します。

IPv6 に関係する経路だけで失敗する場合は、限定的な比較を始める前に DNS 応答、コアのログ、出口の対応状況を保存します。根拠なく端末全体の IPv6 を恒久的に無効にしないでください。カスタム DNS を変更した場合は設定を保存し、現在のバージョンの初期設定と比較します。Xray と sing-box の DNS 設定は同じ意味ではありません。^[3]

6. TLS エラーの原因を調べる

証明書の期限切れ、ホスト名の不一致、システム時刻の誤り、信頼チェーンの不足、プロトコル設定の誤りは、いずれもハンドシェイクに影響します。TLS handshake timeout は、その段階を時間内に完了できなかったことを示す場合もあります。この文字列だけで原因やサーバーの遮断を断定することはできません。

システム時刻、サーバー名、設定の提供元が指定したパラメーターを確認します。新しい Xray では旧来の allowInsecure の扱いが変わっており、プロジェクトのメンテナーが説明しています。^[4] 検証を省略することは一般的な修復方法ではありません。失敗した接続から取得したフィンガープリントを、そのまま信用しないでください。証明書の固定には、信頼できる経路で得た期待値と、証明書更新時の運用が必要です。

7. 再現可能な報告をまとめる

正確なエラーテキストを保持しますが、プライベートにしておく必要があるサブスクリプショントークン、UUID、パスワード、秘密キー、アドレスは削除してください。完全な構成には認証情報が含まれている可能性があるため、診断に便利だからという理由だけで公開ディスカッションに貼り付けるべきではありません。

Client / core versions:
OS and package:
Capture mode and routing profile:
Change immediately before failure:
Target and reproduction steps:
Expected / actual behavior:
Explicit-proxy test result:
TUN-off comparison:
Relevant sanitized log excerpt:

別のノードが動作している場合、問題は解決していますか? これは便利なコントロールですが、違いが元のサーバー、プロトコル、またはルーティング動作であるかどうかを識別することはできます。違いを記録すると、次のインシデントの診断が容易になります。

すべてリセットしたほうがいいでしょうか？ バックアップをとり、コストを理解した後でのみ検討してください。証拠を保存し、結果が説明可能な状態を維持できるように、最初に最小限の作業構成を確立します。

参考にした YouTube 動画

公開されている動画タイトル・説明・チャプター索引を、テーマ選びと画面操作の参考にしました。本文は独自に作成したガイドで、動画の書き起こしではありません。技術的な内容は以下の公式資料で確認しています。

科技分享 · v2rayN チュートリアル 2026-04-1601:58 · 21:16
科技分享 · v2rayN チュートリアル 2025-09-2804:31 · 07:50

公式資料と適用範囲

資料確認日：2026-10-26。メニュー名や機能はクライアント、コア、OS のバージョンによって異なります。本文のチェックリストは推奨する検証手順であり、実測済みの性能データではありません。