接続経路 / ログで原因を特定 / 変更は一度に一つ

V2Ray トラブル対処ガイド

まず問題の発生箇所を切り分け、該当する設定を変更します。サブスクリプションの更新、サーバーへの接続、アプリの通信を同じテストとして扱わないでください。

初めて使う場合は、まず設定ガイドに沿ってインポート、サーバーの選択、接続確認を行ってください。このページでは接続後のトラブルを扱います。症状に合う章を開き、変更前の状態を記録してから、一度に一つだけ設定を変更し、最後に同じ経路で再テストしましょう。

デスクトップではv2rayN、Androidではv2rayNGを中心に解説します。V2Flyカーネルが必要な場合はv2flyNGを使用します。画面の項目名はクライアントのバージョンによって異なることがあります。見つからない場合は、まずクライアントと対応プラットフォームを確認し、別のクライアントの設定手順を流用しないでください。

01 / アプリ → ローカル接続口 → カーネル → 外部接続

インターネットに接続できない：通信経路を切り分ける

「クライアントが接続済み」と表示されても、通常はローカルサービスが起動したことを示すだけです。サーバー側の認証に成功したことや、ブラウザーの通信がプロキシを通ったことまでは確認できません。まず、クライアント名、OS、選択中のサーバー名、システムプロキシのモード、ルーティングモード、Tunの状態を記録し、接続できなかったサイトと発生時刻も控えてください。いきなり設定を削除したりネットワークをリセットしたりするのは避けましょう。元のログと設定が、原因の切り分けや変更前後の比較に役立ちます。

ネットワークの基本状態を確認してから、ローカル接続口を調べる

クライアントを終了してシステムのネットワーク設定を元に戻し、普段プロキシなしでアクセスできるサイトを開いてみてください。直接接続もできない場合は、Wi-Fiのログイン認証が必要か、LANケーブルが抜けていないか、ネットワークアダプターにIPアドレスが割り当てられているか、手動プロキシの設定が残っていないかを確認します。公共Wi-Fiの認証ページはプロキシ有効時に表示されないことがあります。先に認証を済ませてからクライアントを起動してください。特定のサイトだけ直接接続できない場合は、ネットワーク全体の異常とは限りません。別のサイトでも確認しましょう。

ネットワークに問題がなければv2rayNを起動し、インポート済みで設定がそろったサーバーを一つ選びます。まずTunをオフにし、システムプロキシだけでテストしてください。クライアント設定でローカルの待ち受けアドレスとポートを確認し、カーネルの起動ログにエラーがないことも確かめます。以下のコマンドは、ローカルポートが実際に10808で、その接続口がHTTPプロキシを受け付ける場合に限り使用できます。ポートが異なる場合は置き換えてください。この方法ならブラウザーがシステムプロキシを参照しているかどうかを切り分けられますが、カーネルのルーティング規則は迂回しません。

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

コマンドでサイトのレスポンスヘッダーが返れば、アクセス制限の応答であっても、通常は何らかのHTTPサーバーまでリクエストが届いています。証明書とレスポンス内容も確認してください。ローカルポートへの接続に失敗する場合は、カーネルの起動状態とポート番号を確認します。プロキシトンネルの確立やリモートハンドシェイクに失敗する場合は、サーバーへの接続を調べてください。HTTP用の接続口をSOCKS用として使わないでください。プロトコルを間違えると、ポートに接続できてもリクエストを正しく処理できません。

ログからローカル接続口・外部接続・アクセス先を切り分ける

v2rayNのログ画面を開き、現在時刻を確認してから対象サイトへ一度だけアクセスし、該当する新しいログを調べます。関連するログが見つからなくても、アプリがプロキシを使っていないとは限りません。通常のリクエストを記録しないログレベルの場合もあります。「ログがない」だけで通信が入っていないと判断しないでください。一時的にログの詳細度を上げ、プロキシを明示するコマンドでも比較できます。「接続拒否」は接続先まで到達したものの、サービスに拒否された状態です。タイムアウトが続く場合は、アドレス、ネットワーク経路、サーバーの状態も確認します。

プロキシを明示したアクセスは成功し、ブラウザーだけ失敗する場合は、ブラウザーの拡張機能、独自プロキシ設定、安全なDNSを確認し、システムプロキシの章に沿ってアプリへの適用状態を調べてください。プロキシ経由のリクエストがすべて失敗し、直接接続は正常なら、別の設定元から入手した利用可能なサーバーで試します。特定のドメインだけ失敗する場合は、そのドメインに対するルーティング規則と名前解決を先に確認してください。すべてのサブスクリプションをすぐに更新する必要はありません。サーバー、アクセス先、クライアントは別々に確認しましょう。

最後に、一時的に有効にした詳細ログをオフにし、必要なシステムプロキシまたはTunの設定を戻して、最初に失敗したアプリをもう一度開きます。ブラウザーが古い接続を再利用することがあるため、必要に応じて完全に終了してから再起動してください。「どの設定を変えたら結果が変わったか」を記録しておくと、再発時に原因を特定しやすくなります。「再起動したら直った」だけでは、ネットワークの一時的な復旧と設定変更の効果を区別できません。

02 / アドレス → ポート → トランスポート → TLS → 認証

サーバーがタイムアウトする：ハンドシェイクの段階を特定する

サーバーのテストがタイムアウトしても、サーバーが停止しているとは限りません。テストでは、サーバーのドメイン名を解決し、トランスポート接続を確立し、安全なハンドシェイクとプロトコル認証を完了してから、テスト用サイトへアクセスする場合があります。どの段階で失敗しても結果に影響します。TCP接続テスト、実際の接続テスト、Web速度テストのどれを使ったか確認してください。それぞれ確認する経路が異なります。TCP以外のトランスポートを使う設定では、通常のTCP接続確認だけで実際のプロトコルが使えるかどうかは判断できません。

サーバーの接続先を確認し、すぐにプロトコルを変更しない

サーバーの編集画面でアドレスとポートを確認します。アドレス欄にhttps://やパス、末尾の空白が入っていないか、ポートがサーバー側の実際の待ち受けポートと一致しているかも確認してください。ドメイン名を使っている場合は、名前解決できることを先に確かめます。IPアドレスの場合は、接続先が現在も有効か確認してください。Windowsでは次のコマンドでTCP接続の可否を調べられます。例のドメイン名は自分のサーバーアドレスに置き換えてください。成功しても確認できるのはTCP接続までで、プロトコル認証、TLS、接続先へのリクエスト成功を保証するものではありません。

Test-NetConnection -ComputerName example.net -Port 443

テストに失敗したら、設定を変えずにスマートフォンのテザリングなど別のネットワークでも試します。別のネットワークでは成功する場合、元のネットワークの出口、ファイアウォール、ルーティング制限を優先して調べます。どちらでも失敗する場合は、サーバーの待ち受け状態、受信側ファイアウォール、アドレスの有効性を確認してください。サーバーの管理権限がない場合は、失敗した時刻、接続先、エラーが発生した段階を設定の提供元に伝えます。手当たり次第にポートを変えないでください。サーバー側と異なるポートを指定すると、新たな問題が発生するだけです。

TLS・トランスポート設定・プロトコル認証を切り分ける

ポートに接続できても失敗する場合は、証明書検証、ハンドシェイク、認証、トランスポート経路に関するエラーがログにないか確認してください。TLS設定では、サーバー名、一般にSNIと呼ばれる項目と、システム時刻が正確かどうかを確認します。証明書の名前は接続に使うIPアドレスと一致する必要はありませんが、サーバー証明書と設定の要件には一致している必要があります。WebSocketではパスとHost、gRPCではサービス名も確認します。これらすべてにアドレス欄のドメイン名を入力すればよいわけではありません。

REALITYではサーバーアドレスに加えて、公開鍵、短いID、サーバー名などを設定の提供元に照らして確認します。通常のTLS証明書設定とは異なるため、同じパラメーターを流用しないでください。VLESS、VMess、Trojanの認証情報も相互に置き換えられません。サブスクリプションを更新しても、以前のサーバー設定が別のグループに残っている場合があります。選択中の項目が新しい設定か、別名だけで判断せずに確認してください。証明書エラーの詳しい対処手順はシステム時刻とSNIのトラブル対処メモをご覧ください。

症状まず確認する項目症状だけでは判断できないこと
ドメイン名を解決できないサーバーのドメイン名、名前解決の初期設定、ネットワークのDNSリモート側のプロセスが停止している
接続を拒否されたアドレス、待ち受けポート、接続拒否のポリシープロトコルの認証情報に必ず誤りがある
証明書の検証に失敗したシステム時刻、サーバー名、証明書チェーン検証を無効にすれば長期的に使用できる
認証に失敗した認証情報、プロトコルの種類、サーバー側の設定システムプロキシが有効になっていない

証明書検証を長期間無効にしてハンドシェイクエラーを隠したり、タイムアウトを避けるために待ち時間を延ばし続けたりしないでください。タイムアウトのしきい値を変えても、誤ったアドレスや認証設定は直りません。項目を一つ修正するごとに実際にアクセスし、ログが次の段階へ進むか確認します。ポートに接続できてハンドシェイクも成功するのにテスト用サイトへアクセスできない場合は、サーバー側の外部接続、DNS、テスト対象に原因が移っている可能性があります。別のサイトでも試し、クライアントの認証情報をむやみに変更しないでください。

03 / サブスクリプションの取得とサーバーへの接続は別の処理

サブスクリプションの更新に失敗する：取得と読み込みを確認する

サブスクリプションの更新は独立したWebリクエストで、現在のサーバー接続と同じ経路を使うとは限りません。「内容をダウンロードできない」場合と、「ダウンロードはできたがクライアントにインポートできない」場合を分けて考えてください。前者はアドレス、ネットワーク、アカウントの状態、証明書が原因になりやすく、後者は応答内容、形式の不一致、未対応の項目が原因の可能性があります。更新に失敗しても、既存のサーバー設定は削除しないでください。古い設定で接続できれば、サブスクリプション取得用の経路を復旧する手掛かりになります。

アドレスとサブスクリプショングループを確認する

v2rayNの「サブスクリプショングループ」で対象のグループ設定を開き、URLが最後まで正しくコピーされているか確認します。特に疑問符以降のクエリパラメーター、末尾の文字、誤って含まれた改行に注意してください。サブスクリプションURLのトークンはアクセス情報です。公開ログ、スクリーンショット、オンラインのデコードツールに貼り付けないでください。チャットからコピーすると句読点が混ざることがあります。また、リッチテキストのリンクに表示された文字列が実際のURLとは限りません。設定の提供元にあるコピー機能から取得し直してください。

更新対象のグループが、設定を編集したグループと同じか確認してから、「サブスクリプションを更新（プロキシを使用しない）」を試します。ローカルネットワークからサブスクリプションサービスにアクセスできる場合、停止中のサーバーに依存せず更新できます。直接接続でタイムアウトし、現在のプロキシ経由の実アクセスが成功する場合は、プロキシ経由での更新も試してください。どちらも失敗した場合は、それぞれのエラーを記録します。ボタンの名前だけで、クライアントが意図した経路を使うと決めつけないでください。ログとプロキシの状態も確認しましょう。

応答内容に応じて対処を分ける

「認証されていません」や「アクセス禁止」と表示される場合は、アカウントの状態、サブスクリプショントークン、サーバー側の権限を確認します。更新ボタンを繰り返し押しても権限は変わりません。リクエスト頻度が高すぎるというエラーが出たら、連続して再試行せず、サーバーで許可された間隔を待ってから試してください。証明書エラーの場合は、端末の時刻と証明書チェーンを確認します。リクエストが成功しているのに利用可能なサーバーがないと表示される場合は、ログイン画面、メンテナンス画面、認証ページ、別クライアント用の形式が返っている可能性があります。HTTPリクエストの成功は、サブスクリプション内容が正しいことを意味しません。

サブスクリプションには、クライアントが対応する共有リンクの一覧やエンコードされたデータが含まれます。文字列として表示されていても、どのクライアントにもそのままインポートできるとは限りません。別形式の設定ファイルを独自にリネームして読み込ませたり、サブスクリプションURLを「クリップボードから共有リンクをインポート」に貼り付けてすべてのクライアントで認識されると期待したりしないでください。提供元が指定するクライアントに合った方法を選びます。新しい項目が読み込めない場合は、ダウンロードページでクライアントを確認し、設定をバックアップしてからクライアントを更新してください。サブスクリプション全体を直接編集するのは避けましょう。

更新後に現在の設定を確認する

更新が終わったら、グループ内のサーバー設定が想定どおりか確認し、テストに使う設定を選び直します。グループ設定によっては古いサーバーが残ったり、現在の選択が維持されたりします。「更新完了」と表示されただけで、すべての設定が置き換わったとは判断できません。同じ別名でもアドレス、ポート、安全設定が同じとは限りません。更新直後に接続できなくなった場合は、新旧のプロトコル、トランスポート、安全設定を比較し、サーバーの移行や設定変更がなかったか提供元に確認してください。

定期更新だけ失敗し、手動更新は成功する場合は、定期実行時にクライアントが起動していたか、端末がまだネットワークに接続していなかったか、プロキシに利用可能なサーバーがあったかを確認します。起動順序による失敗なら、サブスクリプション形式を変更する必要はありません。復旧後は、手動更新の成功、グループ内容の表示、新しい設定の選択、実際のWebアクセス成功まで一通り確認しましょう。サブスクリプショングループの初期設定はクイックスタートガイドを参照してください。この章では、更新経路が途切れた箇所を扱います。

04 / スループット・応答時間・安定性を分けて測る

速度が遅い：条件をそろえて比較する

「速度が遅い」には、Webページの初回表示が遅い、ダウンロードが遅い、動画が頻繁に止まる、接続が途中で切れるなど、複数の症状があります。初回表示の遅さはDNSやハンドシェイク、接続確立が原因になりやすく、ダウンロードの遅さは帯域幅、混雑、接続先の速度制限が関係します。途中で切れる場合は、Wi-Fi、端末のスリープ、サーバー側の接続ポリシーも確認してください。まず、どの段階で問題が起きるかを記録し、それに合う方法でテストします。レイテンシが低くてもスループットが高いとは限らず、1回の速度テストであらゆるサイトの速度は判断できません。

ネットワーク・接続先・テスト時間をそろえる

同じ端末、同じネットワーク、同じファイルまたはWebページを使ってテストし、OSの更新、クラウド同期など大容量通信は一時停止します。可能なら有線LANか電波の安定したWi-Fiで比較し、無線の干渉をサーバーの問題と混同しないようにしてください。時間を記録して複数回テストし、多数のサーバーを同時に測定するのは避けます。同時テストはローカル帯域を消費し、サーバー側の接続数制限にかかることもあります。測定後は接続が終了してから、次の比較を行ってください。

まず、直接接続できる接続先で基本的な速度を確認し、次にプロキシ経由で比較します。異なる接続先同士の結果からは、ローカルネットワーク全体の異常を見つけられる場合がありますが、プロキシによる速度低下を直接計算することはできません。サーバー同士を公平に比べるには、接続先とリクエスト方法をそろえてください。ダウンロード元が接続元アドレスで速度制限している場合や、接続先までの経路が遅い場合もあります。「サーバーを変えたら速くなった」としても、その組み合わせが適していたというだけで、元のサーバー全体の性能が低いとは限りません。

名前解決の待ち時間とデータ転送の待ち時間を分ける

Webページを初めて開くたびに時間がかかる一方、その後のダウンロードは正常なら、DNSのタイムアウト、IPv6からのフォールバック、TLSハンドシェイクを優先して確認します。ブラウザーの開発者ツールにあるネットワークタイムラインでは、名前解決、接続、応答待ち、コンテンツのダウンロードを区別できます。ただしプロキシ利用時は一部の処理をプロキシが行う場合があるため、実際の経路を踏まえて数値を見てください。プロキシを明示したコマンドでブラウザー拡張の影響を除外し、DNSの章に沿って名前解決の経路を比較できます。初回表示が遅いだけで、バッファーやスレッド数を変更しないでください。

Webの応答は正常なのに転送速度が遅い場合は、別のダウンロード元でも試して、特定の接続先だけが遅いか確認します。さらに別のローカルネットワークでも試し、ボトルネックがローカル側か接続先までの経路にあるかを切り分けます。ルーティング規則も結果に影響します。本来直接接続する大きなファイルがプロキシへ送られると遠回りになり、本来プロキシを使う接続先が誤って直接接続されると、再試行が続く場合があります。テスト中はルーティングモードを一時的に切り替えて比較し、成功したら該当する規則を修正してください。分割ルーティングを無視したまま使い続けないでください。

症状に関係する場合だけ詳細設定を変更する

多重化を必ず有効にする必要はありません。実際の効果はカーネル、プロトコル、サーバーの対応状況によって異なり、一部の接続処理を減らせる場合もあれば、パケットロス時に複数のリクエストへ影響する場合もあります。UDP転送も、クライアント、外部接続プロトコル、サーバー、ネットワークの条件に左右されます。一つのスイッチで利用を保証できるものではありません。音声通話やゲームに問題がある場合は、アプリの通信が実際にプロキシを通っているか、UDP経路が確立しているかを先に確認してください。Webページが開くかどうかだけで判断しないでください。

Tun利用時に、小さなWebページは開くのに大きなリクエストが止まる場合は、パスMTUが原因の可能性として考えられます。ただし、それだけで原因と決めつけないでください。まずTunをオフにし、プロキシを明示した方法で比較します。同じ差が繰り返し確認できた場合に限り、クライアントにあるMTU設定を参考に少しずつ調整し、元の値も記録しておきます。社内ネットワーク、仮想マシン、多段トンネルでは適切なパケットサイズが変わるため、他の設定値をそのまま使えるとは限りません。変更後は同じ大きなリクエストで再テストしてください。

決まった時間帯だけ問題が起きる場合は、時間を変えて比較した結果を記録し、サービス提供元に連絡してください。上流ネットワークの混雑や接続先の外部接続容量不足は、クライアントでは解決できません。テスト後はログレベルとルーティングを元に戻し、一時停止したアプリも再開してください。調査時と普段の環境が大きく異なると、テストでは正常でも実際の利用では遅いままになることがあります。

05 / サーバーの名前解決と接続先ドメインの名前解決は別の経路

DNSの問題：どこで名前解決しているか確認する

まず、サーバーのドメイン名と接続先サイトのドメイン名を分けて考えます。リモートサーバーに接続するには、クライアントが先にサーバーのアドレスを知る必要があります。一方、接続先サイトの名前解決は、アプリ、OS、カーネル、リモート側のいずれかが行う場合があります。ブラウザーでセキュアDNSを有効にしていると、独自の経路を使うこともあります。そのため、システムのコマンドで名前解決できても、プロキシカーネルが同じ結果を使うとは限りません。プロキシ経由でサイトを開けても、システムのDNSが復旧したとは限りません。まず実際の経路を確認し、すぐにDNSサーバーのアドレスを変更しないでください。

システムとカーネルの名前解決を別々に確認する

Windowsでは次のコマンドを使い、システムの名前解決結果を確認できます。応答に含まれるアドレスの種類、タイムアウトの有無、ネットワークを変えたときの違いを記録してください。ドメイン名に複数の有効なアドレスが返っても、異常とは限りません。コンテンツ配信サービスは地域やネットワークに応じて異なる結果を返します。IPアドレスを指定したHTTPS接続も、信頼できる代替テストではありません。サーバーが証明書の検証や仮想ホストの選択にドメイン名を使っていることがあります。証明書エラーだけで元の名前解決に問題があるとは判断できません。

Resolve-DnsName example.com

次に、カーネルのログに名前解決のタイムアウト、DNSサーバーへ接続できないエラー、利用可能なアドレスがないというエラーがないか確認します。サーバーのアドレス自体がドメイン名で、リモートDNSも未接続のプロキシ経由で使う設定では、起動時に依存関係が循環することがあります。接続には名前解決が必要なのに、名前解決には先に接続が必要になるためです。クライアントの初期名前解決やサーバードメイン解決の設定を使ってこの依存関係を解消し、起動時に必要なアドレスを現在のネットワーク経由で取得できるようにしてください。確立前のトンネルにすべての名前解決を強制的に送らないでください。

ドメインの処理方針がルーティングに与える影響を理解する

ルーティングのAsIs、IPIfNonMatch、IPOnDemandは、ルールの照合でドメイン名の名前解決をどう使うかを指定するもので、「DNS速度の3段階」と単純に捉えることはできません。AsIsは、この照合のためにドメイン名を積極的にIPアドレスへ変換しません。IPIfNonMatchはドメイン名のルールに一致しない場合に名前解決し、IPルールとの照合を試みます。IPOnDemandはIPアドレスが必要なルールの照合時に名前解決します。外部接続で別途名前解決が必要な場合もあるため、ルーティングポリシーとDNSのすべての動作を同じものと考えないでください。

以下はカーネルのルーティング項目の一部を示す例です。完全な設定ではなく、クライアントが生成した設定ファイルをそのまま置き換えるためのものでもありません。ドメイン分類の後にアドレス分類を照合する考え方を示しています。対応する地域データファイルと、directという名前の外部接続が必要です。v2rayNのルーティング設定から編集する場合は、対象のルールが実際に使用中のルーティング設定に書き込まれているか確認してください。ルールの順番や、それより前に適用されるルールも最終結果に影響します。

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

ブラウザーのキャッシュ、IPv6、Tunの通信制御を確認する

ブラウザーだけに問題がある場合は、セキュアDNS、拡張機能、キャッシュを確認します。すべてのアプリで問題が起きる場合は、システムとカーネルを調べてください。IPv6で名前解決できても、現在のネットワークに利用可能なIPv6経路があるとは限りません。反対に、IPv6を無効にすれば直るとも限りません。まずアドレスの種類と接続ログを比較し、特定のアドレスだけ失敗し続けるか確認してから、クライアントの名前解決や外部接続の設定を変更します。変更後はキャッシュの期限切れを待つか、アプリを再起動し、古い結果が再利用されないようにしてください。

TunによるDNSの制御が有効かどうかは、クライアントの実装、システムルート、アプリの動作に左右されます。Tunを有効にすればすべてのDNS通信が同じ経路になるとは限りません。ログに見慣れない仮想アドレスが表示された場合は、FakeDNS系の機能が有効か確認してください。アドレスをそのままシステムのhostsファイルに書き込まないでください。キャッシュを消す前に現在の結果を記録し、名前解決の設定を変えた後で比較します。プレフィックスと照合順序の詳しい説明はカスタムルーティング規則のメモ、具体的なルーティング例は直接接続・プロキシ・ブロックの設定をご覧ください。

06 / システム設定・アプリ設定・仮想ネットワークインターフェースを分けて確認

プロキシが効かない：通信を取り込む方法を確認する

システムプロキシは、アプリが参照できる設定の一つで、すべての通信を必ず通すためのスイッチではありません。Tunは仮想ネットワークインターフェースとルーティングを使って通信を取り込みます。両者は異なる層で動作します。切り分けでは、まず片方だけを有効にしてください。デスクトップのブラウザーでは「システムプロキシを自動設定」から始め、ローカル接続口とサーバー接続が正常だと確認してからTunを試します。両方を有効にしてDNSも同時に変更すると、どの層で結果が変わったのか判断しにくくなります。

システム設定とアプリが実際に参照する設定を確認する

v2rayNの下部ステータスバーで「システムプロキシを自動設定」を選び、OSのプロキシ設定にローカルのアドレスとポートが反映されているか確認します。ポートがクライアントの待ち受けポートと一致していることも必要です。アドレスがループバックアドレスかどうかだけでは不十分です。システム設定が元に戻る場合は、別のプロキシソフト、ブラウザー拡張機能、デバイス管理ポリシー、セキュリティソフトが書き換えていないか確認してください。複数のクライアントにシステムプロキシを同時管理させたり、同じ設定を取り合ったりしないでください。

Windowsでは、一部のコマンドラインプログラムやバックグラウンドサービスがデスクトップのシステムプロキシを使いません。環境変数を参照するものや、独自のプロキシ設定を使うものもあります。ブラウザーは接続できるのにコマンドラインでは失敗しても、クライアントの異常とは限りません。まずアプリのドキュメントに沿ってプロキシを設定するか、プロキシを明示できるリクエストで比較してください。macOSのプロキシ設定は、現在使っているネットワークサービスに関連付けられます。Wi-Fi、Ethernet、別のネットワークサービスに切り替えた場合は、以前設定したサービスではなく、現在有効なサービスを確認してください。

接続口を一つにしてポートと除外リストを確認する

システムプロキシの除外リストと、ブラウザーで対象ドメインが直接接続に設定されていないか確認します。LAN内アドレスを直接接続するのは一般的な設定です。ログに記録を残すためだけに、すべてのLAN通信をリモートサーバーへ送らないでください。対象が除外されている場合は、用途に応じて該当するルールを変更します。ほかの端末からローカルプロキシに接続する場合は、待ち受けアドレス、ファイアウォール、アクセス制御を別途設定する必要があります。自分のブラウザーを直すために、安易にLAN接続用の待ち受けを有効にしないでください。

方式まず確認する項目よくある制限
システムプロキシシステムのアドレスとポート、アプリが使うプロキシの設定元システム設定を参照しないアプリもある
アプリ内プロキシプロトコルの種類、アドレス、ポートそのアプリだけに適用され、システム設定を上書きする場合がある
Tun権限、仮想インターフェース、ルート、DNSほかのトンネルや仮想ネットワークインターフェースと競合する場合がある

Tunが動作しない場合は、権限とルートを確認する

ほかのVPNやトンネルソフトを終了してから、クライアントの案内に従い、仮想ネットワークインターフェースの作成やルート変更に必要な権限を許可します。Windowsでは管理者権限が必要になることがあります。他のデスクトップOSでは、使用中のクライアントが示す権限の案内に従ってください。Tunを有効にした後は、スイッチがオンになっているかだけでなく、ログにインターフェースの作成完了が記録されているか確認します。権限の確認画面を閉じた場合、画面の状態が実際の動作をすぐに反映しないことがあります。ログと実際のインターフェース状態を確認してください。

Tunを有効にするとすぐネットワークが切れる場合は、いったんオフにして接続が復旧することを確認し、複数のネットワークアダプター、仮想マシンのネットワーク、企業向け接続ソフト、残っているルートを調べます。リモートサーバーへの通信が誤ってトンネル自身に取り込まれると、ループが発生することがあります。DNSの制御が競合すると、すべてのドメインが同時に使えないように見える場合もあります。ルートの役割が分からないまま、システムのルートをまとめて削除しないでください。まずクライアントの通常の終了操作で設定を解除し、競合するソフトを一つずつ停止して比較します。復旧手段は残しておきましょう。

修正後は、プロキシが必要なアプリ、LAN内のサービス、OSのネットワーク確認をそれぞれテストします。システムのネットワークアイコンに異常が表示されても、確認用の接続先にアクセスできないだけの場合があります。実際のリクエスト結果も確認してください。メイン画面のステータスバー、ログ、設定項目の場所はv2rayNのメイン画面ガイドをご覧ください。最終的に、どのアプリがシステムプロキシを使い、どのアプリに個別設定が必要か、どの状況でTunを使うかを整理しておきましょう。

07 / GUIの起動とカーネルの起動を分けて対処

起動しない：現在の状態を記録してから復旧する

ダブルクリックしてもウィンドウが表示されない、ウィンドウが開いてすぐ終了する、画面は正常でもカーネルが停止する、といった症状はそれぞれ別の問題です。まずタスクマネージャーでクライアントのプロセスがすでに動いていないか確認し、ウィンドウがタスクトレイに隠れていないか、接続を切ったディスプレイ側に移動していないかも調べます。何度も連続して起動しないでください。複数のプロセスがローカルポートや設定ファイルを取り合い、単一の問題が多重起動の競合へ発展することがあります。プロセスを終了する必要がある場合は、まずログを記録してから通常の方法で終了します。応答がないときだけ強制終了を検討してください。

インストール形式・アーキテクチャ・書き込み可能な保存先を確認する

クライアントのダウンロードページで、OSとプロセッサアーキテクチャを確認してください。Windows版にはデスクトップ版と従来のWPF版があり、画面の仕組みや必要なランタイムが異なる場合があります。インストーラーの説明と起動時の案内を確認し、別のバージョンの要件をすべての版に当てはめないでください。Linuxではdebとrpmのパッケージ形式、macOSではApple SiliconとIntelを区別します。アーキテクチャの不一致、OSのバージョン要件、依存関係の不足は、サーバー設定を変えても解決できません。

展開して使う場合は、必要なファイルをすべて現在のユーザーが書き込めるフォルダーに展開してください。圧縮ファイルのプレビュー画面から直接実行したり、付属ファイルを残して実行ファイルだけをコピーしたりしないでください。設定の保存に失敗する場合は、フォルダーのアクセス権、ディスクの空き容量、同期ソフトによるファイルの使用状況を確認します。セキュリティソフトがブロックした場合は、ログで対象ファイルを確認してください。起動のために端末の保護機能を一括で無効にしたり、不明な配布元から「不足コンポーネント」を入手したりしないでください。

カーネルの起動失敗は最初のエラーから確認する

GUIは正常に動作するのにカーネルが起動しない場合は、ログの最後にある「停止」ではなく、最初に出たエラーを確認します。ポートの競合、設定の構文エラー、未対応の項目、地域データファイルの不足、権限不足では対処方法が異なります。ローカルの待ち受けポートが競合している場合は、まず使用中のプロセスを特定してください。見慣れないシステムサービスをいきなり終了しないでください。Windowsでは次のコマンドでポートとプロセスを確認できます。例のポートは、クライアントの実際の設定に合わせてください。

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

Get-Process -Id 1234

2つ目のコマンドにあるプロセスIDは例です。1つ目のコマンドで確認した値に置き換えてください。別のクライアントインスタンスが使用している場合は、重複したインスタンスを終了します。終了できないアプリが使用している場合は、ローカルの待ち受けポートを変更し、システムプロキシとアプリ内プロキシの設定も合わせて変更してください。一か所だけ変更すると、起動の問題が接続口への接続失敗に変わるだけです。検索結果がない場合も、エラーが別の待ち受けポートを示していないか確認しましょう。すべての競合が同じポートで起きるとは限りません。

設定エラーは、ログに記載された対象と項目をもとに特定します。JSONの余分なカンマ、型の誤り、閉じていない引用符は解析エラーの原因です。JSONとして解析できても、カーネルが要求する項目に合っているとは限りません。カスタム設定は、使用中のカーネルに対応させる必要があります。XrayとV2Flyで対応する項目を機械的に置き換えないでください。クライアントが生成する実行時の設定ファイルは、再起動時に上書きされることがあります。クライアントの設定画面やカスタム設定用の入力欄を使って修正し、一時的な出力ファイルだけを編集しないでください。

最小限の設定でユーザーデータが原因か確認する

復旧前にサブスクリプショングループ、ルーティング、カスタムDNS、必要なユーザー設定をバックアップし、サブスクリプションの認証情報も保護してください。クライアントを終了してから、対応している方法で別の設定フォルダーを使うか、元の設定フォルダー名を変更して最小限の設定で起動します。プログラムが動作中にデータベースを移動しないでください。新しい設定で起動できたら、設定を一つずつ戻します。まずサーバーを一つだけ追加して接続を確認し、その後ルーティングや詳細設定を戻してください。古いデータをまとめて戻すと、原因まで再び取り込んでしまいます。

最小限の設定でもクラッシュする場合は、OSのアプリケーションエラーログ、権限に関するメッセージ、実行環境の情報を確認してから再インストールを検討します。問題を報告する際は再現手順とエラー内容を記載し、認証情報、サブスクリプションURL、個人フォルダー内の機密情報を隠してください。詳しい設定エラーの例はカーネル起動失敗ログの診断ガイドをご覧ください。ウィンドウが開くだけでは復旧完了ではありません。カーネルが動作し続け、ローカル接続口に接続でき、再起動後も設定が正しいことを確認してください。

08 / VPNの許可 → アプリの対象範囲 → バックグラウンド → ネットワーク切り替え

Androidのトラブル：接続とバックグラウンドでの切断

Androidでは通常v2rayNGを使用し、V2Flyカーネルが必要な場合にv2flyNGを検討してください。両者で設定できる内容や対応項目が異なることがあるため、トラブル対処のために複雑な設定をそのまま相互にコピーしないでください。インストーラーが端末のアーキテクチャに合っているか確認します。最近の一般的な端末はarm64ですが、実際の対応状況は端末のOSによります。判断できない場合は、ダウンロードページにある汎用パッケージの説明を確認してください。インストールに失敗したら、まずOSに表示された理由を調べます。インストーラーを改変したり、OSの署名チェックを回避したりしないでください。

VPNの許可後もサーバー接続を確認する

初回接続時はOSのVPN接続を許可し、対応する接続がシステムに表示されるか確認します。別のVPNアプリが動作中なら、先に切断してからv2rayNGを試してください。Androidでは通常、同じユーザーやプロファイル内で一般的なVPNサービスを同時に一つしか利用できません。複数のアプリが接続を交互に切り替えると、ランダムに切断されるように見えることがあります。OSに鍵のアイコンが表示されても、確認できるのはローカルのVPNサービスが起動したことまでです。サーバー認証の成功や、サブスクリプション内のすべての設定が使えることを示すものではありません。

v2rayNGで対象の設定を選んで接続し、アプリのログを開いてから、実際のWebページに一度だけアクセスします。サーバーの名前解決エラーが出る場合はDNSの章を、ハンドシェイクエラーが出る場合はサーバーのタイムアウトの章を参照し、トランスポートと安全設定を確認してください。比較する際は同じ設定を使い、Wi-Fiとモバイルデータで別々に試します。ネットワークを切り替えるときにサーバーも変えないでください。モバイルデータの通信制限、ローミングの許可、OSのデータ通信制御も影響する場合があります。システム設定で一つずつ確認しましょう。

アプリごとのプロキシ設定とOSのプライベートDNSを確認する

特定のアプリだけ接続できない場合は、アプリごとのプロキシ設定を開き、「選択したアプリのみをプロキシする」のか「選択したアプリを除外する」のかを確認します。同じアプリを選んでも、両者では結果が逆になります。対象アプリが仕事用プロファイル、アプリの複製、別ユーザー環境にないかも確認してください。これらの環境は、現在のVPNによる制御対象外の場合があります。アプリ一覧を変更したら、クライアントの手順に従って接続を再確立し、対象アプリも完全に終了してから起動します。古い接続が以前の経路を使い続けないようにしてください。

OSの「プライベートDNS」や「専用DNS」は、端末によって名称が異なります。クライアント内蔵DNSやブラウザーのセキュアDNSとともに名前解決に使われることがあります。特定のネットワークだけで問題が起きる場合は、元の設定を記録してから、一時的にOSの自動設定に切り替えて比較します。その後、クライアントのドメイン処理方針とDNSサーバーへの接続性を確認してください。複数の場所を同時に変更すると、ネットワークが復旧しても原因を特定できません。Webページは開くのに特定のアプリだけ失敗する場合は、アプリ独自のプロキシ設定や通信制限も確認します。

画面ロック後の切断はバックグラウンド設定を確認する

画面を表示している間は正常でも、ロック後しばらくして接続できなくなる場合は、バッテリー最適化、バックグラウンド動作の許可、自動起動の制限、データセーバーを優先して確認します。クライアントのバックグラウンド動作を許可し、バックグラウンドでのモバイルデータ通信が禁止されていないことも確かめてください。メーカーによって設定画面の場所や項目名は異なります。端末に表示されるメニューに従えばよく、まったく同じ名称を探す必要はありません。最近使ったアプリ一覧に残しても、すべてのバックグラウンド権限が許可されるとは限りません。ロック前後のログと接続状態を確認し、サービスが停止していないか判断してください。

OSが常時接続VPNに対応している場合は、通常の接続が安定してから有効にするか検討してください。「VPN未接続時に通信をブロック」を有効にすると、切断後のネットワーク動作が変わります。クライアントが停止すると、通常の通信もOSにブロックされる場合があります。トラブル対処中はこの設定状態を記録し、OSによる通信遮断をサーバーの問題と取り違えないようにしてください。一時的に直接接続へ戻す必要がある場合は、接続ボタンをオフにするだけでなく、該当するOSのポリシーも確認・変更します。組織の管理ポリシーが適用された端末では、その指示に従ってください。

ネットワーク切り替え後に少し待つ必要がある、または再接続が必要な場合は、古い接続、アドレスの変更、OSによるネットワーク復旧が関係していることがあります。切り替えるたびに接続できなくなる場合は、VPNが自動で再接続するか、サーバーのドメイン名が再解決されるか、新しいネットワークからリモートポートへ接続できるか確認してください。最後に普段使うアプリで実際に通信し、アプリ内のレイテンシテストだけに頼らないでください。初回のインポートと接続手順は設定ガイドをご覧ください。インストール形式を変更する場合はAndroidクライアントのダウンロードに戻り、既存の設定をバックアップしてから操作してください。