トラブル診断 / 症状から探す

V2Rayトラブル対処ガイド

接続、サブスクリプション、DNS、プロキシの設定を確認し、まず問題の箇所を特定してから該当する項目を変更しましょう。

このページは必要な箇所を参照するためのトラブル対処ガイドです。最初から最後まで読む必要はありません。初回インストールやインポートの手順は、まず入門ガイドをご覧ください。設定済みなのに期待どおり動作しない場合は、以下から該当する症状の章に進んでください。デスクトップでは主にv2rayNを、Androidではv2rayNGとv2flyNGをそれぞれ説明します。画面やメニューの名称はバージョンによって異なる場合があるため、機能の内容と実際の待ち受け値を確認してください。

診断メモ · 一度に変更する条件は1つ

記録しておく項目：発生日時、ネットワークの種類、使用中のクライアント、プロキシモード、対象アプリ、同じ時刻のエラーログ。変更前の設定画面を保存し、再現可能なリクエストを実行してください。

ログは、問題が発生した前後の関連行だけを抜き出してください。共有前にサブスクリプションURL、サーバーアドレス、ユーザーID、パスワード、接続用リンクを削除してください。設定ファイル全体を公開しないでください。

インターネットに接続できない：ローカルの入口とリモート接続を切り分ける

「起動しました」という表示は、クライアントが動作を開始したことを示すだけです。ブラウザーの通信がプロキシに届いていることや、リモートサーバーへの接続が確立したことまでは保証しません。まず、すべてのアプリで失敗するのか、特定のブラウザーだけなのか、すべてのサイトが開けないのか、特定の接続先だけ失敗するのかを確認してください。また、プロキシをオフにすると通常の接続に戻るかも調べます。問題を基本ネットワーク、ローカルの待ち受け、アプリからの接続、リモートへの通信に分ければ、最初からすべてのノードを変更せずに済みます。

プロキシを使わない接続と比較する

v2rayNでシステムプロキシを解除し、TUNがオフになっていることを確認してから、普段直接接続できるサイトをブラウザーで開いてください。それでも接続できない場合は、Wi-Fiのログイン認証が必要か、システム時刻が正しいか、ネットワークアダプターがIPアドレスを取得しているかを確認します。公衆Wi-Fiでは、まず認証ページを直接開いてログインする必要があります。認証前にノードをテストしても、原因を絞り込めないタイムアウトが返るだけです。基本ネットワークの問題をサブスクリプションの問題として扱わないでください。

直接接続が正常なら、動作確認済みの設定を1つ読み込み、接続方式も1つだけに絞ります。デスクトップでは、まずシステムプロキシを使い、TUNやほかのプロキシソフトは同時に有効にしないでください。「パラメーター設定」でローカルの待ち受けポートを確認し、実行ログでコアが起動していることを確かめます。画面表示とログのポートが異なる場合は、今回の起動で実際に待ち受けている値を基準にしてください。ポートは固定値ではありません。変更した場合は、プロキシを手動設定しているアプリの値も更新してください。

プロキシを明示したリクエストで通信経路を切り分ける

次のWindowsコマンドではHTTPプロキシの入口を明示します。「アプリがシステムプロキシを使っていない」可能性を確認するのに便利です。例ではHTTPまたは混合プロキシの待ち受けポートが10808であることを想定しています。設定が異なる場合は、先にポート番号を置き換えてください。SOCKS専用の入口には使えません。また、接続先には、現在のネットワークからアクセスでき、安定して応答するHTTPSサイトを選んでください。

curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

ローカルプロキシに接続できない場合は、コアが起動していない、ポート番号が違う、ポートが使用中といった問題を先に解決してください。ローカルプロキシへの接続後にリモート接続やTLSのエラーが発生する場合は、次の章に進みます。明示的なプロキシ接続は成功するのにブラウザーだけ失敗する場合は、ブラウザー独自のプロキシ設定、拡張機能、アプリのキャッシュを確認してください。すぐにサーバー設定を変更する必要はありません。実際にローカルの入口を経由するため、タスクトレイのアイコンを見るだけの場合より確実な確認方法です。

ルーティングで通信の出口が誤っていないか確認する

「ルーティング設定」を開き、選択中のルールセットが想定どおりか確認します。ルールによって接続先が直接接続に振り分けられていると、サーバーに問題がなくてもプロキシの不具合と同じような症状が出ることがあります。一時的にルールの少ないテスト設定を使い、対象にプロキシ経由でアクセスできるか確認したら、元の振り分け設定に戻してください。ルールの誤りを隠すためにプロキシ対象を広げたままにすると、どのルールが影響したのか分かりにくくなります。

特定のアプリだけ失敗する場合は、そのアプリがHTTP、SOCKS、または独自の接続方式のどれを使っているか確認してください。システムプロキシはすべてのアプリやUDP通信を自動的に経由させるものではありません。まずアプリがプロキシの手動設定に対応しているか確認し、その後でTUNが必要か判断します。TUNを有効にしたときだけ失敗する場合は、仮想ネットワークアダプター、権限、ルーティングの変更を記録し、TUNモードの説明に沿って確認してください。DNSとノードを同時に変更するのは避けましょう。

最後に、結果を「直接接続は正常、明示的なHTTPプロキシ接続も成功、ブラウザーだけ失敗」のように再現できる一文にまとめます。これだけで、問題をアプリの接続部分に絞れます。「直接接続は正常、ローカルポートにも接続できるが、すべてのリモートリクエストが失敗する」場合に、ノードや通信パラメーターを確認してください。復旧後は有効な設定を保存し、一時的なテストルールを削除します。次回起動時に問題のある設定へ戻らないようにしましょう。

ノードがタイムアウトする：ポート、ハンドシェイク、接続先の失敗を切り分ける

タイムアウトは、制限時間内に期待した応答がなかったことを示しますが、どの段階で止まったかは分かりません。サーバーのポートへの接続、暗号化通信の確立、認証、サーバーから接続先への通信など、さまざまな段階でタイムアウトが起こります。実行ログから今回のリクエストに関係する最初のエラーを探し、最後の「失敗」という行だけを見ないでください。エラー発生前に接続が確立していたか、特定の接続先やネットワークでのみ発生するかも記録します。

まずサーバーの接続先に到達できるか確認する

使用中のサーバーの編集画面を開き、提供元が案内したアドレスとポートを照合します。アドレスの前後に空白がないか確認し、ウェブページのURL全体をサーバーアドレス欄に入れたり、サブスクリプションURLをノードのアドレスとして入力したりしないでください。ホスト名とポートは別々に入力します。最近サブスクリプションの内容が変更された場合は、該当するグループを更新してから有効な項目を選び直してください。古い項目を手動で編集しても、次回の更新後に設定が残るとは限りません。

Windowsでは次のコマンドを使って、サーバーのTCPポートに接続できるか確認できます。例のドメイン名はコマンドの書式を示すためのものです。実行時は使用中のノードの正しいアドレスとポートに置き換え、置き換え後のコマンドを公開しないでください。テストに失敗した場合は、PCからそのTCPポートへの接続が確立していません。成功しても、ポートに接続できることが分かるだけで、プロトコル、ユーザーID、通信パラメーターが正しいことは証明できません。別の通信方式を使う設定では、このテストだけで全体を検証することもできません。

Test-NetConnection -ComputerName server.example.com -Port 443

同じネットワークで複数のノードが失敗する場合は、信頼できる別のネットワークに切り替え、同じ設定で再確認します。ネットワークとノードを同時に変えると、原因を特定できません。特定のサーバーだけがすべてのネットワークで失敗し、ほかのサーバーは正常なら、設定の提供元にサーバーの稼働状況を確認してください。短い間隔で何度もテストしてもタイムアウトの原因は分かりやすくなりません。接続制限につながる場合もあるため、少し時間を置いて再試行してください。

ポートに接続できたら、通信方式とセキュリティ設定を確認する

TCPポートに接続できるのにログにハンドシェイクエラーがある場合は、プロトコル、通信方式、TLS設定、サーバー名を1つずつ照合します。WebSocketのパスとHost、gRPCのサービス名、REALITYの公開鍵とshort IDは、サーバー側の設定と一致している必要があります。ポート番号が同じでも、パラメーターを使い回せるとは限りません。パスの大文字・小文字や先頭のスラッシュも一致に影響する場合があります。推測で項目を埋めるより、接続情報をまとめて再インポートしてください。

端末の時刻がずれていると、証明書の有効期間の判定や一部の認証処理に影響することがあります。まずシステムの時刻を自動設定にし、ログに証明書名、有効期間、信頼チェーンに関するメッセージがないか確認します。「証明書の検証をスキップ」は日常的な対処として使わないでください。本来検出されるべき問題を無視するだけで、サーバー名の設定ミスは解決しません。サーバー証明書に問題がある場合は、サーバーの管理者が修正し、クライアントには正しい接続パラメーターを設定します。

エラーの種類から確認すべき箇所を見分ける

ログの手がかり	よくある意味	優先して確認する項目
`connection refused`	接続が明示的に拒否された	接続先のポート、待ち受けサービス、ファイアウォールの拒否ルール
`i/o timeout`	読み書きの待機中にタイムアウトした	エラーに関連するアドレス、発生した段階、使用中のネットワーク
`certificate`	証明書の検証に失敗した	システム時刻、サーバー名、証明書チェーン
`EOF`	相手側が接続を途中で終了した	通信方式、認証、サーバー側のログ

これらのキーワードだけで原因を断定することはできません。読み書きのタイムアウトは接続先のサイト側で発生している場合があり、相手側による接続終了も途中のネットワーク機器が原因かもしれません。前後のログと比較テストを合わせて判断してください。サーバーへの接続が確立した後に特定のサイトだけ失敗する場合は、そのサイトのルーティングとサーバー側からのアクセス条件を確認します。接続先の一時的な問題だけでノード全体が使えないと判断しないでください。

クライアント一覧の遅延テストでは、実際の接続と異なる接続先や方式が使われる場合があります。ポートテストは成功するのに実際の接続テストが失敗する場合は、プロトコル以降の通信経路を引き続き確認してください。詳しくはノードの遅延とダウンロード速度測定の違いをご覧ください。管理者に問い合わせる際は、発生時刻、プロトコルの種類、エラーが発生した段階、試したネットワークを伝えてください。認証情報全体は送らないでください。具体的な回答を得やすくなります。

サブスクリプションの更新に失敗する：取得、解析、グループ表示を個別に確認する

サブスクリプションの更新は、クライアントがアドレスから内容を取得する、取得した内容をサーバー項目として解析する、該当するサブスクリプショングループに保存する、という3つの段階に分かれます。画面に「失敗」と表示されたら、まずどの段階の問題かを確認してください。取得に失敗する場合は、ネットワーク、アドレス、証明書が原因かもしれません。解析に失敗する場合は、ウェブページが返された、または対応していない形式の可能性があります。更新が成功しても項目が表示されない場合は、別のグループを選択しているだけかもしれません。更新ボタンを繰り返し押しても、これらの条件は変わりません。

アドレスと更新時に使うネットワークを確認する

v2rayNで「サブスクリプショングループ設定」を開き、対象グループを編集して、アドレスが正しく保存されているか確認します。サブスクリプションURLにはアクセス認証情報が含まれる場合があるため、信頼できる提供元から全体をコピーしてください。手作業でつなぎ合わせたり、公開するスクリーンショットに表示したりしないでください。チャットアプリによる改行、末尾にコピーされた句読点、期限切れのアクセスパラメーターがあると、見た目が似ていても別のアドレスへリクエストされます。先に保存してから、そのグループを更新してください。

プロキシ経由で更新する設定と、直接接続で更新する設定を確認してください。現在のノードが使えないのに、サブスクリプションの更新にもそのノードが必須だと、自力で復旧できない状態になります。まずサブスクリプションURLに直接接続できるか確認します。提供元が利用可能なプロキシ経由でのアクセスを求めている場合は、更新用に動作確認済みの接続を1つ残してください。リストを空にして解決しようとしないでください。

ブラウザーでサブスクリプションURLを開けても、クライアントが内容を取得できるとは限りません。ブラウザーが別のプロキシを使っている、ログイン状態を保持している、ウェブページの認証を通過している場合があります。クライアントのログに記録された応答ステータスを確認してください。認証失敗やアクセス拒否の場合はアカウントとリンクの権限、リソースが見つからない場合はアドレス、サーバーエラーの場合は時間を置いてから再試行し、提供元に問い合わせます。すべての応答をクライアントコアの問題と決めつけないでください。

リクエストに成功したら、内容を認識できるか確認する

ネットワークへのリクエストが成功しても、返された内容がノード情報ではなく、ログインページ、案内ページ、ネットワーク認証ページの場合があります。ログに有効なサーバーがない、解析に失敗した、形式に対応していないといったメッセージがある場合は、まずそのURLがどの種類のGUIクライアント向けか、サブスクリプションの提供元に確認してください。ウェブ上のサブスクリプション案内と、実際のサブスクリプションデータのURLは別物です。また、専用形式の設定は汎用的な接続リストとしてインポートできない場合があります。

サブスクリプション全体をオンライン変換サイトに貼り付けてトラブルシューティングすることはおすすめしません。アクセス認証情報がすべて含まれている可能性があります。まずローカルで返された内容の種類を確認し、必要であれば提供元には「ウェブページが返される」「設定形式を認識できない」とだけ伝えてください。単体の接続リンクもある場合は、クライアントのクリップボードから1つインポートして動作を確認します。単体では使えるのにサブスクリプションの更新だけ失敗するなら、取得方法と形式に絞って確認でき、ネットワーク設定全体を調べ直す必要はありません。

更新に成功したのに一覧が空、または項目が重複している

サーバー一覧に戻り、選択中のサブスクリプショングループ、検索ボックス、フィルター条件を確認します。別のグループを更新しても、現在の画面にその内容が自動で表示されるとは限りません。古い検索キーワードが適用されたままの場合もあります。グループに今回編集したアドレスが保存されているか、名前が似た別の項目ではないか確認してください。同じアドレスのグループが複数ある場合は、内容を照合してから重複分を削除します。有効な参照元まで削除しないよう注意してください。

サブスクリプションの更新後にサーバー名や順序が変わると、以前選択していた項目が置き換わっていることがあります。有効な項目を選び直してから接続を確認してください。サーバーのパラメーターを手動で変更していた場合、更新で上書きされる可能性もあります。個別の調整は、出所を明記した別のグループに保存しましょう。自動更新後に問題が起きた場合は、更新前後の時刻と項目の変化を記録すると、「更新後に使えなくなった」という説明だけより原因を絞り込みやすくなります。

自動更新だけが失敗し、手動更新は正常な場合は、PCのスリープ状態、起動順序、更新時のネットワーク状態を確認してください。クライアントの起動時には、ネットワークがまだ使えないことや、プロキシコアの起動前に更新リクエストが送信されることがあります。まず手動更新で通信経路を確認してから、更新のタイミングを調整します。Androidではバックグラウンド制限も確認してください。手順はこのページの最後の章にあります。

初回設定はサブスクリプションのインポート手順に沿って、操作順を確認してください。基本的な疑問はFAQをご覧ください。問題を報告する際は、ステータスコード、エラーの種類、グループの操作手順だけを伝え、URL全体とアクセスパラメーターは伏せてください。修正後は、更新、サーバーの選択、実際のリクエストをそれぞれ1回確認します。3つすべてが正常になって初めて復旧完了です。

速度が遅い：遅延、通信速度、アプリの待ち時間を分けて確認する

「遅い」と感じる状況には、クリックしてから読み込みが始まるまで時間がかかる、転送開始後も速度が低い、再生や通話が断続的に途切れる、という少なくとも3つのパターンがあります。1つ目は名前解決や接続確立、2つ目は利用可能な帯域や混雑、3つ目はジッター、パケットロス、アプリの通信が正しくプロキシを経由していないことが関係する場合があります。まずどの症状か記録し、それに合った方法でテストしてください。一覧に表示された遅延の数値だけで並べ替えると、用途に合わないサーバーを選ぶおそれがあります。

比較できる条件をそろえて2回テストする

同じ端末、同じ接続先、同じプロキシモードを使い、ほかの大容量通信を一時的に止めてください。ノードを1つテストした後、ノードだけを切り替えて再テストします。ルーティングやDNSも同時に変えないでください。大容量ファイルのダウンロードは通信量を消費し、ほかの利用者にも影響することがあります。比較のために長時間繰り返す必要はありません。接続確立にかかる時間と、安定して転送している間の状態を確認してください。ブラウザーのキャッシュにより瞬時に表示されても、リモートへの通信が速いとは限りません。

まずWi-Fiの接続品質と端末の負荷を確認します。アクセスポイントから離れている、Wi-Fiの周波数帯が混雑している、システムがファイルを同期しているといった原因で、すべての通信が遅くなることがあります。同じネットワークから直接アクセスできるサービスを基準にし、直接接続も遅い場合は基本ネットワークを先に確認してください。可能なら有線接続でも比較します。これは常時有線接続を求めるものではなく、Wi-Fiの通信経路を原因から除外するためのテストです。

遅延が小さくても大容量通信が速いとは限らない

ポート接続テストで分かるのは、主に接続確立までの待ち時間です。実際の接続テストはプロキシのハンドシェイクや接続先の影響を受け、ダウンロード速度測定では帯域や混雑がより表れます。3つは別の指標であり、数値が完全に一致するものではありません。リモート回線の往復時間が長くても転送が安定している場合もあれば、接続が速くても混雑する時間帯に通信速度が落ちる場合もあります。会議や対話型アプリでは安定性を、継続的なダウンロードでは転送中の速度も確認してください。

同じノードで特定のサイトだけ遅い場合は、サイト自体、コンテンツ配信経路、適用されているルールを確認します。サーバーから接続先までの経路と、PCからサーバーまでの経路は別です。別の安定した接続先で試すか、同じ接続先に別のノードからアクセスしてください。1つのサイトの応答だけを根拠に、すべての設定をリセットしないでください。テスト方法の違いはTCPing、実際の接続テスト、ダウンロード速度測定の違いをご覧ください。

接続方式、ルーティング、端末の負荷を確認する

実行ログを開き、遅いリクエストが想定した出力先に送られているか確認してください。範囲の広いルールで不適切な経路に送られている場合や、ウェブページはプロキシ経由でもダウンロード機能が独自に接続している場合があります。アプリ内のアップデーター、メディア機能、コマンドラインツールは、同じシステムプロキシ設定に従うとは限りません。まずアプリで対応しているプロキシを明示的に設定します。通信をすべて取り込む必要がある場合に限りTUNをテストしてください。対象範囲を広げることは、一般的な高速化の方法ではありません。

デスクトップで複数のプロキシ、仮想ネットワーク、セキュリティソフトのスキャンを同時に使うと、処理が増える場合があります。重複している機能を1つずつ一時的にオフにして比較しますが、システムの保護機能をすべて無効にしないでください。クライアントとコアのCPUやメモリの使用量も確認します。リクエスト中にCPU使用率が高い状態が続く場合は、接続の繰り返しや大量のログ出力がないか調べてください。デバッグが終わったら通常のログレベルに戻します。詳細ログを長時間記録すると、ディスク容量とプライバシーに影響します。

特定のネットワークでのみ「大きなリクエストが止まる一方、小さなリクエストは正常」という症状がある場合に限り、パスMTUやフラグメントの問題を検討します。まずシステムプロキシとTUNの動作を比較し、症状を再現できることを確認してから、クライアントが対応する設定を小さく調整してください。MTUに極端に小さい値を設定すると通信効率が下がり、別の問題を隠すこともあります。根拠のない「汎用設定」をそのまま使わないでください。変更前の値を記録し、改善しなければ元に戻します。

DNSの待ち時間を通信速度の低下と取り違えていないか、最後に確認します。初回のアクセスだけ遅く、その後のリクエストが正常なら、名前解決と接続確立の段階を重点的に記録してください。ダウンロード全体が遅い場合は、混雑や通信の安定性を確認します。同じ条件での比較結果を残し、具体的なサーバー情報は公開しないでください。復旧したら一時的な変更を1つずつ元に戻し、再テストで効果を確認できた設定だけを残しましょう。説明できない「最適化設定」を増やさないでください。

DNSの問題：名前解決を行う場所と問い合わせ経路を確認する

DNSの問題では、ドメイン名でサイトを開けない、初回の読み込みに時間がかかる、同じ接続先でもアプリによって結果が異なるといった症状が起きます。ブラウザーに名前解決エラーが表示されただけで、すべてのDNSアドレスをすぐに変更しないでください。アクセスは、OSのキャッシュ、ブラウザーのセキュアDNS、プロキシコアの名前解決、リモートサーバーでの名前解決を経由することがあります。まず今回のリクエストがどの段階で名前解決されているかを確認し、変更する箇所を判断してください。新しい設定を追加しても、そのアプリが使うとは限りません。

システムの名前解決結果だけではプロキシ経由の結果は分からない

まずログに記録されたドメイン名を確認してください。接続先のウェブサイト、サーバーアドレス、DNSサービス自体のいずれかかもしれません。サーバーにドメイン名を設定している場合、プロキシに接続する前にコアがその名前を解決する必要があります。この段階で失敗すると、すべてのプロキシ通信に影響することがあります。一方、接続先のドメインの名前解決に失敗した場合は、一部のサイトだけに影響する可能性があります。ログ中のドメインが何を指すか記録し、実際のアドレスを公開する必要はありません。

Windowsでは次のコマンドで、システムが現在取得する名前解決結果を確認できます。システムDNSが応答するか、想定したサーバーから応答が返るかを確かめる方法です。ただし、ブラウザーやプロキシコアが同じ結果を使っていることまでは証明できません。IPアドレスを取得できても接続に失敗する場合は、ルーティング、接続先のポート、通信のハンドシェイクが原因かもしれません。すべてのエラーをDNSの問題と決めつけないでください。

Resolve-DnsName example.com

リモート側の名前解決を確認するには、SOCKSのドメイン名転送を使い、ローカルでIPアドレスに変換せずにドメイン名をプロキシ経由で送信できます。次の例ではSOCKSまたは混合プロキシの入口が10808であることを想定しています。入口がHTTP専用の場合は、その方式に合ったテストを使ってください。プロトコルが合わないことによるエラーを、名前解決の失敗と解釈しないでください。

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

暗号化DNSも、まず通信経路を確保する必要がある

HTTPSを使うDNSでは、DNSサービス自体への接続が必要で、そのドメイン名を先に解決しなければならない場合があります。まだ確立していないプロキシ経由でDNSサービスに接続しようとすると、プロキシ接続にサーバーの名前解決が必要なのに、その名前解決にもプロキシが必要という循環依存が起こることがあります。まずサーバーアドレスの基本的な名前解決とDNSサービスへの経路を確保してから、ルーティングのルールを追加してください。互いに依存する複数の名前解決方法を一度に組み合わせないでください。

v2rayNで、使用中のコアに対応するDNS設定を確認し、通常のプロキシとTUNの環境を分けて考えてください。コアによって設定項目に互換性があるとは限らないため、ある設定のDNS部分を別のコアにそのまま貼り付けないでください。まず画面に用意された設定方法を使い、保存後にコアが再読み込みされたことを確認します。選択されていない設定ファイルを変更した場合、画面上では変更されているように見えても、実際の動作は以前の設定のままです。

名前解決とルーティングルールを合わせて確認する

ドメイン名ルールはリクエストにドメイン名が含まれること、IPルールは接続先のIPアドレスとデータファイルに依存します。ブラウザーが先に名前解決する、アプリがIPアドレスだけを渡す、通信の判定でドメイン名を取得できないといった場合、ドメイン名ルールに一致しないことがあります。Sniffingは一部の接続で判別可能な接続先情報を補えますが、すべてのプロトコルに対応するわけではなく、DNSの代わりにもなりません。リクエストにどの情報が含まれるかを確認してから、該当ルールを調べてください。「ドメイン名を取得できない」ことを、ルールの構文エラーと誤解しないようにしましょう。

次はXray形式のルールの例です。ドメイン名とIPの条件の書き方を示すもので、クライアント設定全体ではありません。利用可能なgeosite、geoipデータと、定義済みのdirect出力先が必要です。2つの条件を別々のルールにすることで、適用状況を確認しやすくなります。この部分だけで設定ファイル全体を上書きしないでください。GUIではルーティング編集機能を使って同じルールを作成します。

{
  "rules": [
    {
      "type": "field",
      "domain": ["geosite:cn"],
      "outboundTag": "direct"
    },
    {
      "type": "field",
      "ip": ["geoip:private"],
      "outboundTag": "direct"
    }
  ]
}

データファイルの欠落、タグのスペルミス、ルールの順序によって、想定外の出力先に振り分けられることがあります。ルールの順序はgeositeとgeoipによる振り分けの解説をご覧ください。トラブル対処中は接続先に関係するルールだけを一時的に変更し、名前解決の問題を理由にルールセット全体を削除しないでください。元の設定を保存し、確認後に復元できるようにします。

変更後はブラウザーの古いタブを閉じるか、関連アプリを再起動します。必要に応じてシステムのDNSキャッシュを消去してください。キャッシュを消すと次のリクエストで再度問い合わせが行われますが、サーバーアドレスの誤りや循環依存は解決しません。ブラウザーだけに問題がある場合は、セキュアDNSがシステム設定を迂回していないか確認します。TUNだけで問題が起きる場合は、仮想ネットワークでのDNSルーティングを確認してください。最後に、一般的なドメイン名と現在のサーバーのドメイン名の両方で、基本接続と接続先へのアクセスが復旧したか確認します。

システムプロキシが効かない：アプリがローカルの入口を使っているか確認する

システムプロキシはアプリが参照するネットワーク設定の一種で、システム内のすべての通信を強制的に取り込む仕組みではありません。v2rayNでシステムプロキシを設定しても特定のアプリが直接接続する場合、アプリがシステム設定を参照しない、独自のプロキシ設定や環境変数、別のソフトが入口を上書きしているといった原因が考えられます。まず明示的なプロキシ設定でコアを確認し、次にシステム設定が反映されているか、最後に対象アプリを確認してください。この順序で調べれば、接続設定の問題をノードの故障と誤認しにくくなります。

実際のポート番号と待ち受けアドレスを確認する

「パラメーター設定」でローカルの待ち受けアドレスとHTTPまたは混合プロキシのポートを確認し、実行ログに起動エラーがないか調べてください。システムプロキシの接続先は、この入口と一致している必要があります。通常、同じ端末内から使う場合はループバックアドレスを指定します。「LANからの接続を許可」はほかの端末がPCの入口に接続するための設定であり、このPCのプロキシを直すために必要なものではありません。特に公衆ネットワークでは、ブラウザーを動かすためだけに待ち受け範囲を広げないでください。

ポートを変更した場合は、まず古いシステムプロキシ設定を解除してから現在の設定を適用し、対象アプリを終了して再起動してください。アプリによっては起動時にだけプロキシ設定を読み込み、古い接続を使い続けることもあります。ウィンドウを閉じただけでなく、タスクマネージャーでプロセスが終了したことを確認してください。新しいポートを明示すれば接続できるのにシステムプロキシでは失敗する場合は、残存設定やアプリ独自のポリシーを優先して調べます。サーバーを再変更する必要はありません。

OSごとに設定が反映されている場所を確認する

OS	確認する場所	見落としやすいポイント
Windows	設定 → ネットワークとインターネット → プロキシ	アプリ独自の設定や別のネットワークインターフェースを使う場合があります
macOS	システム設定 → ネットワーク → 使用中のネットワークサービス → 詳細 → プロキシ	使用中のネットワークサービスに関連する設定を確認します
Linux	使用中のデスクトップ環境のネットワークプロキシ設定	デスクトップの設定とターミナルの環境変数は別々の場合があります

Windowsのユーザープロキシ設定と、一部のシステムサービスが使うネットワーク設定は異なる場合があります。そのため、ブラウザーは接続できるのにバックグラウンドサービスが失敗しても、必ずしもクライアントの不具合とは限りません。特定のサービスのために全体のネットワーク設定を変更せず、まずアプリに独自のプロキシ設定があるか確認してください。macOSでネットワークサービスを切り替えた場合は、以前の接続だけでなく、現在使用中のサービスの設定を確認します。

Linuxでは、GUIアプリ、デスクトップセッション、ターミナルのプロセスがそれぞれ異なる設定を読み込む場合があります。ターミナルのHTTP_PROXY、HTTPS_PROXY、ALL_PROXYに古いアドレスが残っていることもあり、環境変数の大文字・小文字の扱いはアプリによって異なります。まずプロキシを明示するオプションでテストし、次に現在のプロセスが引き継いでいる環境変数を確認します。変更後はターミナルを再起動してください。すべての変数に異なるプロトコルのポートを設定すると、実際にどれが使われているか判断しにくくなります。

上書き設定とプロキシのループを確認する

ブラウザーのプロキシ拡張機能、別のプロキシクライアント、ネットワーク管理ツールがシステムプロキシを繰り返し書き換える場合があります。重複するツールを終了し、アドレスが自動的に変わり続けないか確認してください。システムプロキシを管理するプログラムは1つだけにします。クライアントを終了してもネットワークに問題が残る場合は、コアがバックグラウンドで動作していないか確認してから「システムプロキシを解除」を実行します。プログラムを起動できない場合は、システム設定から無効なローカルポートを指す設定を手動で削除できます。

プロキシループは別の問題です。アプリのリクエストがプロキシに入った後、コア自身の通信も再び同じ入口に送られ、接続が繰り返されたりリソース使用量が増え続けたりします。TUNとシステム全体に適用するプロキシ機能を併用する場合は、除外する通信経路に注意してください。まずシステムプロキシだけの最小構成に戻し、正常に動作することを確認してから、通信を取り込む機能を1つずつ再度有効にします。ポートを繰り返し変更してもルーティングのループ自体は解消しません。

アプリが独自のネットワーク処理を使う場合は、そのアプリの説明に沿ってHTTPまたはSOCKSの入口を設定します。SOCKSとHTTPでアドレスの形式を使い回すことはできません。リアルタイム通信ではUDPも使われることがあり、ウェブページを開けても音声通話がプロキシ経由とは限りません。再確認時は、アプリの動作とクライアントログに該当するリクエストが記録されているかを合わせて見てください。ログにリクエストがない場合は、重要な手がかりです。サーバーではなく、まずアプリからの接続を確認します。

復旧後は「どの設定がどのアプリを担当するか」を記録し、使わなくなった古い設定を削除してください。初めてモードを選ぶ場合は入門ガイドに戻り、振り分けの確認はルーティングの設定手順をご覧ください。明示的なプロキシを使ったテストコマンドを基準として残しておくと、OSの更新後やネットワークを切り替えた後に、問題がアプリ側か接続側かをすばやく切り分けられます。

クライアントがクラッシュする：GUIの終了とコアの起動失敗を分けて確認する

「起動できない」場合は、まず2つのプロセスを切り分けます。GUI自体が動作しないのか、画面は開くもののプロキシコアが起動直後に終了するのかを確認してください。前者はプログラムファイル、実行環境、ユーザーデータ、権限の問題が考えられます。後者はコアのエラーログから設定、ポート、ファイルパスの手がかりを見つけられる場合があります。起動に失敗しただけでユーザーフォルダー全体を削除しないでください。サブスクリプション、ルーティング、ローカル設定が含まれていることがあります。まずバックアップを取り、原因を切り分けます。

起動時の状況を記録し、失敗する範囲を特定する

まず、アイコンをダブルクリックした後の状態を記録します。ウィンドウがまったく表示されない、表示後すぐ閉じる、バックグラウンドに残る、メイン画面にコアの起動失敗が表示される、のどれでしょうか。タスクマネージャーやシステムのアクティビティモニターで、別のプロセスがすでに起動していないか確認してください。古いプロセスがファイルやポートを使用中だと、起動を繰り返すたびに別のエラーが発生することがあります。古いプロセスを正常に終了してから再試行してください。用途を確認せずに、名前が似ているシステムサービスを終了しないでください。

GUIが開かない場合は、プログラムのログフォルダーやシステムのアプリケーションエラー記録を確認し、ファイルの読み込み失敗、依存コンポーネントの不足、アクセス拒否を探してください。アクセス制限のあるフォルダーに配置している、圧縮ファイル内から一時的に起動している、ファイルが完全に展開されていない、といった原因で動作しない場合があります。ダウンロードセンターから、使用するOSとプロセッサーのアーキテクチャに合うパッケージを選び、案内どおりにインストールまたは展開してから、固定したフォルダーより起動してください。異なる配布形式のプログラムファイルを混在させないでください。

コアの起動に失敗したら、まず最初のエラーを確認する

GUIは正常に動くのにコアが終了する場合は、実行ログを開き、起動時点から追って、項目名やアドレスが明記された最初のエラーを探します。後に続く「プロセス終了」や「接続失敗」は、単に結果を示している場合があります。ポートの競合は待ち受けアドレスとポート、設定エラーは該当する階層、データファイルのエラーはパスを確認してください。詳しくはXrayコアの起動失敗への対処をご覧ください。最後の一文だけを見て、何度も再インストールしないでください。

Windowsでは次のコマンドで、例のポートが使用中か確認できます。ポート番号をログに表示された値に置き換え、結果に表示されたプロセスIDをタスクマネージャーで確認してください。ポートが使用中の場合は、重複して起動したクライアントを終了するか、現在のクライアントに未使用のポートを設定し、システムプロキシと手動設定しているアプリの値も合わせて変更します。用途不明のプロセスを終了しないでください。ポート変更後にアプリが接続できなくなった場合も、新しいサーバーの問題と決めつけないでください。

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

JSONを手動編集した後に起動できなくなった場合は、余分なカンマ、引用符の不足、括弧の階層、値の型を確認してください。構文が正しくても、設定が使えるとは限りません。項目が現在のコアに対応していない、出力先のタグが定義されていない、ルールが参照するデータがないといった可能性があります。できるだけGUIから変更し、クライアントに用意された検証機能を使ってください。ネット上にある単独の設定例をそのまま全体設定に置き換えないでください。特に異なるコアの設定形式を混在させないようにしましょう。

独立したデータフォルダーでユーザー設定を切り分ける

プログラム本体は動くのに、既存のユーザーデータを読み込むとクラッシュする場合は、バックアップを取った上で、クライアントが対応する独立フォルダーや設定の分離機能を使って、初期状態のテスト環境を作成します。元のフォルダーは削除せず、名前を変更して残してください。初期状態で正常に動く場合は、サブスクリプション、サーバー、ルーティングを一種類ずつ戻し、そのたびに起動を確認します。古い問題をそのまま一式コピーせずに、破損したデータや互換性のない設定を特定できます。

更新後に問題が起きた場合は、新旧のプログラムが同じフォルダーに混在していないか、実際に起動するショートカットがどこを指しているか確認します。デスクトップ版とWPF版では画面や実行環境が異なるため、実行ファイルを入れ替えて切り替えないでください。プロセッサーのアーキテクチャも端末に合わせる必要があります。実行環境の不足がログに明記されている場合に限り、配布元の説明に沿って依存コンポーネントを追加してください。出所不明の「修復ツール」をインストールしないでください。

セキュリティソフトがプログラムファイルを隔離した場合は、ファイルの入手元と検出履歴を確認し、OSに用意された復元や例外設定を使ってください。すべての保護機能を無効にしないでください。サポートに問い合わせる際は、OS、プロセッサーのアーキテクチャ、使用している配布形式、最初に表示されたエラーを伝え、ユーザーフォルダー全体はアップロードしないでください。用語の詳しい説明は実行ログの読み方をご覧ください。最後にGUIの起動、コアの動作、実際のプロキシリクエストをそれぞれ確認し、画面だけ直って接続の問題が残らないようにします。

Androidのトラブル：VPN権限、アプリごとの振り分け、バックグラウンド動作

Androidではv2rayNGを優先して使用し、V2Flyコア向けの設定ではv2flyNGを選択できます。両者では画面やコアの設定項目が完全には一致しないため、トラブル対処では実際に使用しているアプリを確認し、別のクライアントのメニューをそのまま探さないでください。ダウンロード先はAndroidクライアントのダウンロードをご覧ください。作業前にサブスクリプション情報を保存し、接続ボタンを押した直後に問題が起きるのか、画面ロック、ネットワークの切り替え、特定のアプリの起動後に起きるのかを記録してください。

VPNの許可と通信が実際に取り込まれているか確認する

初めて接続を開始すると、通常はシステムからVPN接続の許可を求められます。許可を与え、ローカルのVPNインターフェースが正常に作成されると、クライアントが対象アプリの通信を取り込めるようになります。ステータスバーのアイコンはインターフェースが存在することを示すだけで、リモートサーバーが使えることまでは示しません。接続後は実際に接続先を開いて確認してください。許可画面が表示されない、またはすぐに消える場合は、システムのVPN設定で既存の設定や管理ポリシーを確認します。

通常、同じユーザー環境では、VPNインターフェースを使うネットワークツールを複数同時に動作させることはできません。別のVPN、LANツール、ローカルVPNを使うフィルターアプリが、現在の接続を置き換える場合があります。いったんすべて切断し、クライアントを1つだけ起動して再確認してください。システムでVPNの常時接続が設定されている、またはVPNを経由しない接続をブロックしている場合は、対象アプリが現在使用しているクライアントか確認します。設定の組み合わせが誤っていると、切断後にすべての通信がシステムに遮断されることがあります。

アプリごとの振り分けが想定と逆になっていないか確認する

クライアントのアプリごとの振り分け設定、またはアプリプロキシ設定を開き、現在のリストが「選択したアプリだけをプロキシ経由にする」のか、「選択したアプリを除外する」のか確認してください。意味が逆になるため、チェックの数だけで判断できません。ブラウザーは正常でも別のアプリが失敗する場合は、そのアプリが実際に通信を取り込む対象か確認します。インストール直後のアプリはリストに追加されていないことがあります。変更後は切断して再接続し、VPNルートとアプリの対象範囲を反映させてください。

クライアントのローカル待ち受けとシステムのVPNモードは別の機能です。ローカルプロキシサービスだけを有効にしても、通常のAndroidアプリが自動的にそれを使うとは限りません。VPNで正常に通信を取り込めている場合、各アプリにローカルプロキシを設定する必要もありません。Wi-Fiの手動プロキシも同時に設定すると、通信経路が重複することがあります。まずクライアントの標準VPNモードに戻し、余分な手動プロキシを解除してから、ノードの接続を確認してください。

画面ロック後の切断とネットワーク切り替え後の失敗を順に確認する

画面を開いている間は接続できるのに、しばらくロックすると切断される場合は、システムのバッテリー管理がクライアントを制限していないか確認してください。端末の設定で必要なバックグラウンド動作を許可し、そのアプリに対する過度な省電力制限を解除して、接続通知を残します。メニュー名は端末によって異なるため、アプリ情報のバッテリー、バックグラウンド動作、ネットワーク権限を確認してください。最初からすべてのアプリのバックグラウンド制限を解除せず、接続に使うクライアントだけを調整します。

Wi-Fiとモバイルネットワークを切り替えた後は、古い接続が以前のネットワーク状態を参照し続ける場合があります。まず切断してから再接続し、復旧するか確認してください。切り替えのたびに再現する場合は、変更前後のネットワークの種類とログを記録します。公衆Wi-Fiでは、先にウェブページで認証が必要な場合もあります。データセーバー、ローミング制限、特定のネットワークだけを許可するアプリの権限も、「自宅では正常なのに外出先では失敗する」原因になるため、サーバーの問題と分けて確認してください。

特定のネットワークでだけドメイン名の問題が起きる場合は、システムのプライベートDNSとクライアント内部のDNS設定を確認します。両者が同じ経路を使うとは限らず、一方をオフにすれば他方が自動的に使われるわけでもありません。まず現在の設定を記録し、一時的にシステムの自動設定に戻して比較してから、このページのDNSの章を参考に、サーバーのドメイン名と接続先のドメイン名を確認します。原因を把握しないままDNSアドレスを次々に追加すると、失敗の経路を再現しにくくなります。

ウェブ閲覧、リアルタイム通信、サブスクリプションのバックグラウンド更新を切り分ける

ウェブページは開けるのに音声通話、ゲーム、その他のリアルタイム機能が失敗する場合は、UDP、アプリごとの対象範囲、サーバー側の対応状況が関係している可能性があります。まず該当アプリの通信が取り込まれているか確認し、ノードのプロトコルと提供元の対応情報を照合してください。ウェブページを開けるだけで、すべての通信方式が使えると判断しないでください。1つのアプリだけに問題がある場合は、アプリ内のネットワーク診断を試します。1つの機能のためにルーティングとDNSを同時にリセットしないでください。

サブスクリプションを前面で手動更新すると成功するのに、バックグラウンドの自動更新が失敗する場合は、バックグラウンド通信の制限と更新のタイミングを優先して確認してください。すぐにサブスクリプションを削除する必要はありません。インストール時にパッケージが対応していないと表示された場合は、端末のアーキテクチャを確認し、ダウンロードページからarm64または汎用版を選択します。インストールの互換性問題を接続エラーと混同しないでください。クライアントを変更する前に、設定中のプロトコルが変更先のコアに対応しているか確認します。3種類のクライアントの比較はクライアントの比較をご覧ください。

原因を特定できない場合は、「いつ正常か」「いつ失敗するか」「再接続で復旧するか」の3点を比較し、機密情報を隠したエラーログを添えてください。用語は用語集で、基本的な操作は入門ガイドで確認できます。何度も再インストールするより、再現条件を明確にするほうが役立ちます。同じ問題が再発した際も、確認済みの手順からすぐに調べ始められます。