V2Rayトラブル対処完全ガイド

インターネットに接続できない：アプリから出口まで順に確認

クライアントに「実行中」と表示されても、画面やコアが何らかの動作状態にあることを示すだけで、接続先のWebサイトにアクセスできるとは限りません。まず、すべてのアプリで失敗するのか、ブラウザーだけなのか、一部のWebサイトだけなのかを切り分けます。発生時刻、直前に変更した設定、ネットワークを切り替えた場合も同じ症状かを記録してください。接続ボタンを何度も押すより、この情報のほうが役立ちます。Webサイト側の障害をクライアント設定の問題と誤認することも防げます。

比較の基準となる接続を用意する

まずクライアントの通信制御を停止し、システムプロキシが元の状態に戻っていることを確認してから、普段そのままアクセスできるWebサイトを開きます。それでも失敗する場合は、Wi-Fi、LANケーブル、ゲートウェイ、ネットワークのログイン画面を確認してください。認証が必要な公共ネットワークでは、先に認証を完了させます。基本のネットワーク接続が正常になったら、クライアントを起動して有効な設定を1つ選びます。テスト中はプロキシクライアントを1つだけ使い、通信経路を変更するほかのツールは停止してください。

次に、ローカルのプロキシ入口が利用できるか確認します。v2rayNで実際のHTTPまたはSOCKSの待ち受けアドレスとポートを確認し、ほかの解説記事にある数字をそのまま入力しないでください。ブラウザーに手動でプロキシを設定している場合、プロトコルを待ち受け入口に合わせ、アドレスには通常ローカルホストを指定します。SOCKSの入口をHTTP欄に入力したり、リモートサーバーのポートをローカルプロキシのポート欄に入力したりすると、ノード設定に問題がなくてもWebページをまったく開けないことがあります。

ログで「接続が届いていない」場合と「接続後に失敗した」場合を見分ける

クライアントのログを開き、対象がはっきりしたWebサイトに再度アクセスします。対応する接続記録がまったくない場合は、ブラウザーがシステムプロキシを迂回していないか、拡張機能が設定を上書きしていないか、対象アプリがシステムプロキシを参照するかを確認します。ログに対象ドメインが記録されている場合は、名前解決、接続、ハンドシェイクのどの段階で失敗したかを調べます。ログでは重複メッセージがまとめられることがあり、新しい行がないだけで通信が届いていないとは断定できません。必要に応じて一時的にログの詳細度を上げて再テストしてください。

「特定のWebサイトだけ開けず、ほかは正常」な場合は、ルーティングでそのドメインが不適切な出口に送られていないか確認します。クライアントのグローバルプロキシルーティングを一時的に使って比較すると、問題の範囲を絞り込めます。テスト後は元の設定に戻してください。グローバルルーティングで開けるのに元のルールでは開けない場合は、ルールの順序、ドメインの照合、直接接続時のDNSを確認します。どちらでも失敗する場合は、ノード接続と接続先サービスの状態を調べます。

認証、証明書、既存の接続による影響を確認する

証明書エラーが表示されたら、まずシステムの日付、タイムゾーン、自動時刻同期を確認し、次にノードのサーバー名設定を確認します。証明書検証を無効にして問題を隠さないでください。ブラウザーではWebページを開けるのに特定のアプリが接続できない場合は、そのアプリ独自のプロキシ、固定接続プール、バックグラウンドサービスも確認します。システムプロキシを変更しても、確立済みの接続はすぐに再接続されないことがあります。現在のページを更新するだけでなく、アプリを完全に終了して再起動すると、新しい設定を反映した状態を確認しやすくなります。

TUNを有効にするとすべての通信が止まり、無効にするとブラウザーが復旧する場合は、権限、仮想ネットワークアダプター、ルーティング、DNSの制御を確認してください。クライアント全体をすぐに再インストールする必要はありません。まず現在の設定を保存し、「クライアント1つ、ノード1つ、システムプロキシ」の最小構成に戻してから、ルールを1つずつ追加します。毎回同じページを使ってテストし、エラーの文言を記録してください。「開けない」という状態を、タイムアウト、接続拒否、名前解決失敗、証明書検証失敗などに切り分けることが大切です。

復旧後は、少なくとも次の3点を確認してください。通常のWebページが最後まで読み込めること、プロキシが必要なアプリで新しい接続を確立できること、クライアントを終了しても基本のネットワークが利用できることです。一部のリソースだけ読み込めない場合は、設定一式を切り替え続けるのではなく、ブラウザーの開発者ツールで失敗したドメインを確認します。より詳しい手順は接続済みなのにインターネットに接続できない場合の確認リストを参照してください。初期設定がまだの場合は、チュートリアルに戻るのがおすすめです。

ノードがタイムアウトする：ポート、通信方式、ハンドシェイクを切り分ける

タイムアウトの原因は1つではなく、接続経路のどこかで処理が制限時間内に完了しなかった状態です。クライアントのテスト機能は、TCP接続、プロキシ経由のHTTPリクエストなど、異なる方法で接続を確認することがあります。テストの種類を確認してから、実際にアクセスしてみてください。1つのノードのテストに失敗しても、サブスクリプション全体が無効とは限りません。ポートに接続できても、認証や通信パラメーターが正しいとは限りません。

1つのノードだけか、環境全体かを確認する

同じネットワークとクライアント設定で、異なる提供元または経路の有効なノードを2つテストします。1つだけ失敗する場合は、そのノードとサーバーの状態を重点的に確認します。すべて同時に失敗する場合は、端末の時刻、ネットワーク出口、ファイアウォール、コアの起動状態を確認してください。その後、利用可能な別のネットワークに一時的に切り替えて比較します。ネットワークを切り替えると名前解決と出口の両方が変わるため、問題が環境に関係していることは示せても、特定の設定ミスを直接特定することはできません。

サーバーアドレスとポートは、サブスクリプションまたはサービス提供元の完全な情報を基準に確認します。ドメイン名の前にプロトコルのスキームを重ねて付けず、ポート欄にパスを入力しないでください。手動設定では、前後の空白、全角記号、コピー漏れにも注意します。ドメイン名を使う場合は、端末で名前解決できることを確認してください。アドレスが更新されるサービスでは、一度調べたアドレスを固定して使い続けず、設定を再取得します。

エラーが発生した段階から原因を絞り込む

これらの語句は原因の確定ではなく、調査の手がかりです。たとえば「接続が拒否されました」は明示的な拒否を受けたことを示しますが、拒否元はリモートサーバーの場合も、経路上の機器の場合もあります。「タイムアウト」だけでは、ログの1行からパケットの損失とサーバーの無応答を区別できません。エラーの前後の行、特に接続先と使用した出力先を記録してください。接続先Webサイトによる拒否と、プロキシサーバーによる拒否を混同しないでください。発生する層が異なります。

通信設定は一式で整合させる

TLSを使うノードでは、サーバー名、通信プロトコル、サーバー側の要件を確認します。WebSocketのパスとHost、gRPCのサービス名などは、サーバー設定に合わせる必要があり、プロトコル名だけを変更しても解決しません。VLESSとREALITYを組み合わせる場合は、公開鍵、Short ID、サーバー名、フロー制御など、構成に応じたパラメーターも確認します。必須項目は組み合わせによって異なるため、異なる解説記事の項目を継ぎ合わせるのではなく、リンク全体を再インポートするのが確実です。

システム時刻のずれは、証明書の有効期間の判定や一部プロトコルの認証に影響することがあります。まずシステム設定で時刻を同期し、コアを再起動して新しい接続を確立してください。証明書チェーンに問題がある場合は、システムの信頼ストアが正常か、ログインが必要なネットワークではないかを確認します。検証をスキップした状態を常用しないでください。サーバー名と時刻に関する詳しい手順は、TLSハンドシェイクと証明書エラーの対処法を参照してください。

最後に、クライアントまたはコアの更新が必要か判断します。ログに未対応フィールド、認識できないプロトコル、設定の解析失敗が明記されている場合は、更新が直接的な対処になります。更新前に設定を保存し、クライアントのダウンロードページから対象プラットフォームのものを選んでください。更新後も同じノードで再テストし、経路を同時に変更しないようにします。ノード自体が無効な場合は、サービス提供元に設定とメンテナンス状況を確認してください。テスト間隔を過度に短くして接続要求を増やさないでください。

復旧を確認する際は、1回テストに成功しただけでなく、実際にWebページへ接続し、その状態が継続するか確認します。有効なノード設定とテスト環境を保存し、一時的に追加したファイアウォールの例外やデバッグ設定は元に戻してください。タイムアウトが再発した場合、この基準を使えばノード、ネットワーク、端末設定のどれが変わったか判断しやすくなります。

サブスクリプション更新に失敗する：URL、取得経路、形式を確認

サブスクリプションの更新は、コンテンツの取得、解析、グループへの反映という3段階に分かれます。更新ボタンでエラーが表示されたら、どの段階で失敗したかを確認してください。接続タイムアウトは通常取得時、内容を認識できないエラーは解析時、更新が完了したのにノードが表示されない場合は、グループの絞り込みやコンテンツの変更を確認します。最初から元のサブスクリプションを削除しないでください。利用可能な古いノードを残しておけば、接続の維持や問題の比較に使えます。

URL全体を確認し、サブスクリプションの認証情報を保護する

サービス提供元のページからサブスクリプションURLをコピーし直し、先頭、末尾、クエリパラメーターがすべて含まれているか確認します。チャットアプリによる改行、ブラウザーで表示された文字列だけのコピー、疑問符以降のパラメーターの削除などでURLが無効になることがあります。サブスクリプションURLにはアクセス用の認証情報が含まれることが多いため、公開の掲示板に貼ったり、不明な変換サービスにアップロードしたりしないでください。サポートを求める場合はエラーの種類だけを伝え、スクリーンショットではURL、アカウント情報、ノードの認証項目を隠してください。

アカウントページに期限切れ、停止、通信量の上限到達、サブスクリプションURLのリセットが表示されていないか確認します。サービスページにログインできても、以前のURLが有効とは限りません。同様に、Webページを開けてもサブスクリプションのAPIが利用できるとは限りません。サービス提供元から新しいURLが案内されている場合は、既存のグループを編集して更新し、似た名前のグループを複数作らないようにします。どのノードが同じ提供元のものか分かるよう、元のグループメモは残してください。

サブスクリプションの取得とノード接続を分けて考える

ノードに接続できても、同じ経路でサブスクリプションのAPIにアクセスできるとは限りません。すべてのノードが無効な状態で、既存のプロキシを使ってサブスクリプションを取得しようとすると、処理が循環することもあります。クライアントにプロキシ経由、直接接続などの更新オプションがあるか確認し、現在のネットワークに合う方法を選んで個別に比較します。クライアントや画面によって項目名は異なり、サブスクリプションの更新が常にシステムプロキシを使うとは限りません。

直接更新がタイムアウトする一方で、既存ノードからサブスクリプションのサーバーにアクセスできる場合は、現在のプロキシ経由で更新を試します。現在のプロキシが利用できず、サブスクリプションのAPIに直接アクセスできる場合は、直接取得に切り替えます。毎回取得方法だけを変更し、DNSやグループURLを同時に変更しないでください。連続して失敗した場合は時間を置いて再試行し、サーバー側の頻度制限を避けます。ネットワークへのログインが必要な場合は、先に認証を済ませてください。認証前はログインページが取得されることがあります。

形式の互換性とノードの不足を確認する

サブスクリプションの内容には、エンコードされた共有リンクの一覧や、特定クライアント専用の形式が使われる場合があります。ファイル名やURL末尾の拡張子だけでは、現在のクライアントに対応しているか判断できません。サービス提供元がv2rayN、v2rayNG、v2flyNG向けと明示している入口を優先してください。ログに未対応のプロトコル項目が表示された場合は、ソフトウェアを更新する前にクライアントとコアの対応状況を確認します。項目を適当に削除すると、ノードの保存には成功しても接続時に失敗することがあります。

更新時にエラーが出なかったのにノードが一部しか表示されない場合は、キーワード、プロトコル、グループによる絞り込みを確認してください。サービス提供元が経路一覧を変更したか、クライアントが重複項目を統合したかも確認します。まずすべてのグループを表示し、既知のノード名を検索してください。「昨日と件数が違う」という理由だけで解析エラーと判断しないでください。サーバー側の内容変更でも同じことが起きます。

更新後に接続パラメーターが変わった場合は、別の問題として切り分けます。元のノードが置き換わったり、選択中の項目が削除済みの記録を指していたりすることがあります。更新後のノードを選び直し、コアを起動してください。新しいサブスクリプションをインポートできても、すべて接続に失敗する場合は、取得処理ではなくノードのタイムアウトに関する章を確認します。復旧後は必要なグループ設定のバックアップを保管し、ログと一緒に公開しないよう管理してください。

次の3点を確認できれば、更新から接続までの一連の動作を確認できます。更新が正常に完了すること、対象グループに新しい内容が表示されること、その中の有効なノードを選んで実際に接続できることです。グループを初めて追加する手順はサブスクリプションのインポートガイド、URL管理や一般的な使い方はよくある質問を参照してください。同じURLで複数の端末から更新できず、アカウント状態に問題がない場合は、無関係な再インストールを繰り返さず、時間を置くかサービス提供元にAPIの状態を確認してください。

速度が遅い：遅延、通信速度、アプリの使用感を分けて測る

ページの表示、動画の読み込み、大容量ファイルのダウンロードが遅くても、原因が同じとは限りません。遅延は通信の往復にかかる時間、スループットは継続的にデータを転送する能力を表します。パケットロスやジッターは接続の安定性に影響します。ノード一覧の一度のテスト結果が良好でも、すべてのアプリで速いとは限りません。最初の表示までの待ち時間、継続速度の不足、断続的な切断のどれが問題かを確認し、それに合った比較方法を選んでください。

テスト条件をそろえる

普段安定している接続先を1つ選び、近い時間帯に同じネットワーク、クライアント、操作でテストします。OSの更新、クラウド同期、ほかの大容量通信を一時停止し、同じネットワーク内の別の端末がアップロード帯域を使い切っていないか確認してください。アップロードの混雑もWebページの応答を遅くするため、ダウンロードの使用量だけでは判断できません。Wi-Fiの電波が弱い場合は、アクセスポイントに近づくか有線接続に切り替え、ローカルの再送をリモート経路の問題と誤認しないようにします。

次にノードだけを切り替え、同じ接続先の状態を確認します。複数のノードで同じWebサイトが遅く、ほかのサイトは正常な場合は、接続先による速度制限、コンテンツ配信経路、アカウント制限を考慮します。同じノードがモバイルネットワークでは正常で、固定回線では遅い場合は、アクセス経路の違いが考えられます。複数の速度測定を同時に実行しないでください。帯域を奪い合うため、日常の使用感を反映せず、比較にも適しません。

ログとシステム負荷からボトルネックを探す

転送中に再接続、タイムアウト、接続リセットが頻発する場合は、まず安定性の問題に対処します。むやみに同時接続数を増やすと、状況が悪化することがあります。タスクマネージャーやシステムモニターで、クライアント、コア、接続先アプリのCPU使用率が高い状態で続いていないか確認します。省電力モード、過熱、頻繁なバックグラウンドスキャンは、暗号化やネットワーク処理に影響することがあります。まず電源と冷却の状態を通常に戻してから、ソフトウェアの調整が必要か判断してください。

ブラウザーのダウンロードは正常なのに特定のアプリだけ遅い場合は、そのアプリが別の出口や独自プロキシを使っていないか、異なるサービス地域を選んでいないか確認します。ルーティングルールによって、Webページはプロキシ経由でもダウンロード用ドメインは直接接続になっている場合や、その逆もあります。対象ドメインの接続記録から、実際の出力先を確認してください。アプリ名だけで経路を推測しないでください。同じアプリでも、ログイン、メディア、更新などで複数のドメインを使うことがあります。

通信設定とTUNパラメーターは慎重に扱う

多重化がすべてのプロトコルやネットワーク環境で速くなるとは限りません。特定の高度な通信オプションを有効にした後だけ問題が起きる場合は、その項目を既定値に戻して比較してください。異なる情報源から汎用の高速化設定を寄せ集めないでください。プロトコルとコアの組み合わせには対応範囲があります。サーバー側で有効になっていない機能は、クライアントだけで変更しても性能は向上しません。通信方式をむやみに変更するより、サービス提供元の設定をそのまま保つことが重要です。

TUNモードで「小さなページは開けるが、大きなファイルの転送が止まる」場合は、MTU、パスMTUディスカバリー、UDPの処理を原因候補にできますが、これらだけが原因とは限りません。まずTUNを無効にし、システムプロキシで同じファイルをダウンロードして比較します。TUN使用時だけ問題が起きる場合は、仮想ネットワークアダプターとコアのログを確認してください。MTUの調整が必要な場合は、元の値を記録して小さく試します。変化がなければ元に戻し、説明できないネットワーク設定を長期間残さないでください。

DNSも「遅い」と感じる原因になることがあります。ドメインの名前解決が再試行されると、初回表示まで時間がかかる一方、ファイル転送が始まった後は正常な速度が出る場合があります。そのときは高帯域のノードに切り替えるのではなく、DNSの章を確認してください。ブラウザーのキャッシュにも注意が必要です。2回目のアクセスが速いのは、リソースがすでに端末内に保存されているためかもしれません。初回読み込みを比較する場合は、新しいセッションを使うか、キャッシュ条件をそろえてください。

最終的に採用するのは、一時的な最高速度ではなく、再現性のある改善です。実際の用途で連続して確認し、頻繁な切断と引き換えに一時的な速度を得ていないか確認してください。サービス提供元が示す通信量倍率は課金ルールであり、速度の保証ではありません。地域、プロトコル、倍率の選び方はノード選びの比較ガイドを参照してください。基本のネットワークが混雑している場合、クライアント設定で回線速度を補うことはできないため、ローカルと上流のネットワーク環境から確認します。

DNSの問題：どこで名前解決し、その結果をどこで使うか確認

DNSはドメイン名をアドレスに変換しますが、プロキシを使う場合は、システム、ブラウザー、クライアントのコア、リモート側のいずれで名前解決するかが異なります。ある場所で名前解決に成功しても、実際のアクセスに同じ結果が使われるとは限りません。最初からDNSサーバーを切り替えるのではなく、失敗したリクエストをどのプログラムが送信したのか、どの経路で名前解決したのか、そのアドレスがルーティングの選択に影響したかを確認します。名前解決と接続出口をあわせて調べてください。

名前解決の失敗と接続の失敗を切り分ける

ログにドメイン名の解決失敗が明記されている場合は、対象ドメインを記録し、同じ時間帯のほかのドメインと結果を比較します。すべてのドメインで失敗する場合は、DNSサービス自体とアクセス経路を確認してください。特定のドメインだけ異常な場合は、権威DNSレコード、キャッシュ、接続先ドメインの状態を検討します。IPアドレスでWebサイトにアクセスしても、確実な代替テストにはなりません。多くのサイトはサーバー名、証明書、バーチャルホストに依存しており、IPアドレスに接続できてもドメイン名を使った経路が正常とは限りません。

システム標準のツールで、OS側の名前解決を確認できます。Windowsでは nslookup example.com を実行します。これはシステムの問い合わせに応答があるか確認するもので、ブラウザーの暗号化DNSやクライアント内蔵の名前解決も同じとは限りません。比較時は問い合わせ時刻とネットワークを記録し、アドレスの結果だけを残さないでください。システムで名前解決できるのにクライアントでエラーが出る場合は、システムキャッシュを何度も消すのではなく、コアのDNS設定を確認します。

ドメインポリシーとルールの順序を理解する

ルーティングルールはドメイン名またはアドレスを条件にできます。ドメイン名のルールに一致しない場合、アドレスのルールを続けて確認するために名前解決を行うポリシーもあります。以下はV2Ray/Xrayのルーティング設定の一部を示した例で、項目の位置を理解するためのものです。単独で動作する完全な設定ではありません。また、DNSサーバーアドレスの設定とは別のため、この行だけを変更してすべての名前解決の問題を解決することはできません。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch"
  }
}

IPIfNonMatchは、ドメイン名が既存のルールに一致しなかった場合に名前解決を試み、関連するアドレスルールを照合する設定です。実際の結果は、ルールの順序、名前解決の結果、既定の出力先にも左右されます。別の設定に変更すると判定のタイミングは変わりますが、ルーティングの精度が上がるとは限りません。まず対象ドメインをどの出口に送るべきか確認し、該当ルールに一致しなかった理由を調べてください。詳しくはルーティングと通信の振り分けに関する用語を参照してください。

名前解決とプロキシの依存ループを避ける

プロキシサーバーのアドレスがドメイン名で、その名前を解決するDNSリクエストも、まだ確立していないプロキシ経由でしか送れない場合、起動時に処理が循環することがあります。暗号化DNSを使う場合も、DNSサービスのアドレス自体を先に解決する必要があることがあります。クライアントが対応する範囲で、サーバーのドメイン名に利用可能なブートストラップ用の名前解決経路を確保し、プロキシが起動する前にその経路へアクセスできることを確認してください。検証せずに複雑なリモート名前解決の経路を追加しないでください。

TUNで通信を制御する場合は、システムのDNSリクエストが受信、転送され、適切にルーティングされるかも確認します。ブラウザーの暗号化DNS、システムの暗号化DNS、コアのDNSを同時に有効にすると、アプリごとに異なる結果になることがあります。まず経路を1つに絞ってテストし、ほかの階層のカスタム設定を一時的に無効にしてから、1つずつ戻します。FakeDNSのようなマッピング機能を使っている場合は、制御を無効にした後、関連アプリの接続を再確立してください。この機能でのみ意味を持つマッピングアドレスが使われ続けることがあります。

デュアルスタックネットワークも確認が必要です。ドメインが2種類のアドレスを返しても、一方の経路が利用できず、断続的な待ち時間や一部のアプリの接続失敗につながることがあります。まず実際の接続でどちらの種類のアドレスが使われているかを確認し、クライアントのアドレス選択設定を使って一時的に比較します。最初からシステム全体で一方のアドレスを無効にするのは避けてください。ルーティング、ゲートウェイ、上流ネットワークの問題を隠し、ほかのアプリにも影響することがあります。

復旧確認では、システムの名前解決、クライアントログ、実際のWebアクセスをそれぞれ確認し、結果に矛盾がないか調べます。次にネットワークを一度切り替え、新しいネットワークによってDNSの配布条件やブートストラップの条件が変わるか確認してください。DNSアドレスの変更後に一時的に復旧しても、しばらくすると再び失敗する場合は、キャッシュの有効期限が切れた後の状態も観察します。「名前解決は正常だが接続に失敗する」という切り分けができたら、次は出力先と接続先サービスを確認し、DNSを際限なく入れ替えないでください。

システムプロキシが効かない：入口、権限、TUNを確認

システムプロキシは、アプリが参照するためのプロキシ設定であり、すべてのプログラムの通信を強制的に制御するスイッチではありません。システム設定を参照するアプリもあれば、独自のプロキシ設定を使うアプリや、直接接続するプログラムもあります。そのため、ブラウザーでアクセスできても別のプログラムで接続できないからといって、v2rayNが起動していないとは限りません。まず対象アプリがどの接続方式に対応しているかを確認し、システムプロキシ、アプリ内プロキシ、TUNのどれを使うか判断してください。

システム設定が実際に反映されているか確認する

v2rayNでシステムプロキシの自動設定を選んだ後、OSのネットワークプロキシ設定を開き、アドレスとポートが現在の待ち受け入口を指しているか確認します。以前のポートや別のプログラムのアドレスが残っている場合は、別のクライアント、管理ツール、自動スクリプトが設定を上書きしていないか調べます。ほかの通信制御ツールを停止し、設定を再度反映させてください。組織管理の端末ではポリシーによる制限がある場合があります。管理上の要件を回避せず、許可されたネットワーク設定の方法を確認してください。

アプリに手動でプロキシを設定する場合は、プロトコル、ホスト、ポートを確認し、認証欄に誤った情報を入力していないか確認します。通常のローカル待ち受け入口では認証が有効とは限らないため、ノードのユーザーIDやパスワードをブラウザーのプロキシ認証欄に入力しないでください。トラブルシューティングのためだけに待ち受けアドレスをすべてのネットワークインターフェースに変更するのも避けましょう。ローカルでのみ使う場合は、ローカルの範囲に限定したほうがアクセスを管理しやすくなります。LANで共有する場合は、アクセス権限を別途検討してください。

自動設定、独自プロキシ、環境変数を確認する

システムには、手動プロキシ、自動設定スクリプト、アプリ内プロキシが同時に設定されている場合があり、優先順位はアプリによって異なります。ブラウザー拡張機能がブラウザーだけの出力先を変更することもあります。まず関連する拡張機能を無効にしてブラウザーのプロキシ設定を確認し、セッションを再確立してください。コマンドラインツールやバックグラウンドサービスは、環境変数や独自設定を参照する場合があります。ブラウザーで成功したからといって同じ経路を使うとは限りません。このガイドでは、まずグラフィカルな設定画面で実際の入口を確認します。

TUNの問題を起動と転送に分けて確認する

TUNは仮想ネットワークアダプターを使って、そこにルーティングされた通信を処理します。ただし、実際に制御する範囲はシステムのルーティングとクライアント設定によって異なります。起動に失敗する場合は、権限、仮想ネットワークアダプターの作成、ドライバー関連のログを確認します。起動できてもインターネットに接続できない場合は、ルーティング、DNS、出力先の選択、サーバーアドレスが正しく除外されているかを確認してください。スイッチがオンだからといって、すべての通信が制御されているとは限りません。また、すべてのクライアントに同じ設定項目があるとも限りません。

デスクトップで権限の昇格が必要な操作は、OSが用意した正規の認証手順を使ってください。認証後も失敗する場合は、以前の仮想ネットワークアダプターが残っていないか、ほかのネットワークツールがルーティングを占有していないか、セキュリティソフトに明確なブロック記録がないか確認します。保護機能全体を無効にしないでください。記録に基づいて必要なコンポーネントだけを許可してからテストします。明確な根拠が見つからない場合は、トラブルシューティングによる新たなリスクを避けるため、保護状態を維持してください。

通信のループが発生したり、有効化直後にネットワークが切れたりした場合は、TUNを無効に戻し、システムプロキシが正常に動作する基準状態を確認します。その後、通信制御とDNSの設定を1つずつ有効にし、問題が発生する段階を調べてください。TUNは通信を制御する仕組みであり、どのノードから出力するかはルーティングルールで決まります。TUNを有効にしても、すべての宛先が同じノードを使うとは限りません。設定手順と利用場面はTUN設定ガイドと仮想ネットワークアダプターの仕組みを参照してください。

クライアントを終了した後にネットワークが切れた場合は、まずシステムのプロキシ設定が終了済みのローカルプロキシを指したままになっていないか確認し、仮想ネットワークアダプターとルーティングが正常に解放されたか調べます。まずクライアントを再起動し、通信制御の停止やシステムプロキシの解除など、通常の操作で復旧してください。すべてのプロセスを強制終了するのは避けます。復旧後は利用可能な通信制御方式を把握し、日常使用では必要な方式だけを使って、二重プロキシや設定の競合を減らします。

クライアントがクラッシュする：画面、コア、設定を分けて確認

ウィンドウが突然閉じる、起動ボタンを押しても反応しない、画面は正常でもコアが終了するのは、それぞれ異なる問題です。まずタスクトレイにアイコンが残っているか、ログの更新が続いているか、タスク管理ツールに関連プロセスが残っているかを確認します。起動直後、特定のノードをインポートした後、TUNを有効にしたときだけなど、発生する操作を記録してください。再現可能な条件が分かれば、単発のクラッシュメッセージより原因を特定しやすくなります。

設定を保護してから実行環境を確認する

フォルダーの削除、設定のリセット、再インストールを行う前に、クライアントのエクスポート機能で必要な設定を保存してください。サブスクリプションURLやノードの認証情報は機密情報です。バックアップは自分で管理できる場所に保管してください。画面を開けない場合は、復元用に既存のデータフォルダーをコピーできますが、フォルダー全体を公開しないでください。次に、その設定が現在のインストール先に属するか確認します。別のポータブル版のデータを現在のインスタンスのものと誤認しないようにしてください。

クライアントのダウンロードページで、プラットフォームとプロセッサーアーキテクチャを確認してください。デスクトップOSである種類のアプリが動作しても、別のアーキテクチャ向けパッケージが使えるとは限りません。特に異なるプロセッサーの端末に移行する場合は、対応するパッケージを選び直してください。Windowsのデスクトップ版と従来のWPF版では画面の技術が異なります。選択したパッケージの実行環境を確認し、一方の画面に必要な依存関係の説明を、もう一方にそのまま当てはめないでください。

画面が開かない場合とコアが起動しない場合を分けて対処する

画面の起動直後に終了する場合は、システムイベント、アプリのログ、ディスクの空き容量を確認します。インストール先に書き込めない、ユーザーデータフォルダーの権限に問題がある、同期ソフトがファイルをロックしているなどの原因で起動できないことがあります。まずプログラムを通常アクセスできる場所に置き、現在のユーザーに必要な権限があることを確認してください。通常のファイルアクセスの問題を隠すために、常に最高権限で実行するのは避けます。TUN操作で必要な権限昇格は、通常の画面起動とは分けて判断してください。

画面は表示されるのにコアがすぐ停止する場合は、設定の生成と待ち受けポートのエラーを重点的に確認します。アドレスが使用中とログに表示される場合、別のインスタンスが動作しているか、ほかのプログラムが同じポートを使用している可能性があります。重複したインスタンスを終了し、ポートの用途を確認してからローカルの待ち受け設定を変更してください。変更後はシステムとアプリのプロキシ設定も更新します。クライアントのポートだけ変更してブラウザーが古い値を参照したままだと、「起動は成功するがアクセスできない」という別の問題が発生します。

設定の解析エラー、未対応の項目、ルールファイルの読み込み失敗が表示された場合は、直前の変更を特定します。手動編集したJSONは、引用符、カンマ、項目の型を確認してください。ただし、起動時にクライアントが毎回生成するファイルを直接変更しないでください。まず設定画面で該当項目を元に戻すか、保存済みの設定を復元します。インポートしたパラメーターが現在のコアに対応していない場合は、エラー行を無作為に削除せず、プロトコルの対応状況を確認してください。

更新後に問題が起きたら、前後の状態を比較する

更新直後に問題が起きた場合は、更新前後のパッケージの種類、システム環境、発生した操作を記録します。バージョン情報を推測で作ったり、記憶だけを頼りに入力したりしないでください。以前のプロセスが終了したか、新しいプログラムが元のデータの場所を読み込んでいるか確認します。複数のインスタンスで同じデータフォルダーを共有すると、状態が不安定になることがあります。再インストール前に、どの実行ファイルを使っているか確認してください。デスクトップのショートカットが古いフォルダーを参照している場合もあります。

セキュリティソフトがコンポーネントを隔離またはブロックした場合は、まず明確なイベント記録とファイルの入手元を確認してから、復元や例外設定を判断してください。すべての保護機能を一度に無効にしないでください。ディスク容量不足、突然の電源断、データ書き込みの中断によって、不完全な設定が残ることもあります。画面を開ける場合は、読み取れる内容を先にエクスポートしてから、新しい作業用データを作成します。復元時はグループとルールを1つずつインポートすると、問題を引き起こす内容を特定しやすくなります。

問い合わせには、システムの種類、アーキテクチャ、クライアント画面の種類、再現手順、個人情報を隠したエラーの前後の情報を含めてください。サブスクリプションの認証情報、サーバーの認証項目、不要な個人用パスを隠します。復旧後は、通常の接続を確認してから複雑なルーティングとTUNを戻してください。実際の使用状態でしばらく確認し、画面が開くだけでなく通信も復旧したことを確かめます。コアとGUIクライアントの関係はProject Vのエコシステム解説を参照してください。画面の問題とコアの問題を混同しないために役立ちます。

モバイル端末のトラブル：VPN権限、バックグラウンド動作、アプリごとのルール

Androidでは主にv2rayNGを使った手順を説明し、V2Flyコアを使う代替クライアントとしてv2flyNGも取り上げます。両者で利用できる設定や画面の細部は異なる場合があり、同じ高度なパラメーターが両方に対応するとは限りません。まず実際に動作しているクライアントを確認し、「基本ネットワーク、VPN権限、ノード接続、アプリごとのルール」の順に調べます。デスクトップのシステムプロキシに関する知識だけでは、AndroidのVPNによる通信制御を判断できません。

起動後にネットワークへ接続できない場合は、権限と競合を確認する

初回接続時は、システムのVPN接続許可を求められます。許可を完了していない場合は、ノードをインポートしていてもアプリの通信を制御できません。システムのVPN設定とクライアントの通知を確認し、意図したクライアントが接続中か確認してください。Androidでは通常、同じユーザー環境で同時に有効にできるVPNサービスは1つです。VPNの仕組みを使うほかのネットワークツールと競合する場合があるため、競合するサービスを停止してから対象のクライアントだけを起動します。

システムでVPNの常時接続や、VPN未使用時の接続ブロックを設定していると、クライアントの切断中に基本のネットワークも使えなくなることがあります。これはシステムポリシーの動作であり、ネットワーク自体が壊れたとは限りません。トラブルシューティングの前に各設定の役割を確認し、許可された端末管理の範囲内で必要に応じてテスト条件を変更します。終了後は元に戻してください。仕事用プロファイルやデバイスポリシーで管理された端末では、管理者が指定したネットワーク設定に従ってください。

画面消灯後の切断とバックグラウンド制限を分けて確認する

画面を表示している間は正常でも、ロック後に切断される場合は、バッテリー最適化、バックグラウンド動作の制限、データセーバーを確認します。設定画面は端末メーカーによって異なるため、アプリ情報からバッテリー、バックグラウンドデータ、自動起動などの項目を探してください。使用中のクライアントに必要な権限だけを調整し、すべてのアプリの電源設定を変更する必要はありません。通知権限やバックグラウンドサービスの制限も確認しますが、通知が表示されているだけではノード接続が継続している証拠にはなりません。

テストではノードを1つに固定し、まず画面を表示した状態でアクセスします。その後、画面をロックして待ち、ロック解除後すぐにログの再接続とネットワーク変更の記録を確認してください。Wi-Fiからモバイルネットワークに切り替えたときだけ切断される場合は、既存の接続が切れた後に復旧できていない可能性があります。まず接続を停止して再確立し、新しいネットワークで利用できるか確認します。接続が復旧していない間にプロトコルの設定を何度も切り替えると、ネットワーク切り替えの問題と設定の問題が重なってしまいます。

一部のアプリだけ失敗する場合は、アプリごとの設定とDNSを確認する

アプリごとのプロキシ設定には、選択したアプリだけをプロキシ経由にするモードと、選択したアプリを除外するモードがあります。モードを逆に選ぶと、「チェックしたのにプロキシを使わない」状態になります。まずモードを確認し、対象アプリとその依存サービスが正しい一覧に含まれているか調べてください。変更後はVPNを再接続し、対象アプリを完全に終了してから再起動します。ブラウザーと特定のアプリで結果が異なる場合は、DNSや接続プロトコルの違いも考えられます。一度Webページを開いただけで、通信制御の範囲を判断しないでください。

システムのプライベートDNS、クライアントのDNS、アプリ内の暗号化DNSが同時に有効になっている場合があります。ログに名前解決の失敗が表示されたら、まずDNSのトラブルシューティングに戻り、どこで名前解決されているか確認してください。すべてのDNS設定を同時に別々のサービスへ変更しないでください。モバイルネットワークとWi-Fiで結果が異なる場合は、新しいネットワークで認証が必要か、特定の接続が制限されていないか、クライアントが元の出力先に復帰しているかも確認します。必要に応じて別の有効なノードを使い、1項目ずつ比較してください。

インストール、移行、最終確認

インストールパッケージのアーキテクチャが合わないと、インストールや実行ができない場合があります。端末のプロセッサーとシステムの対応状況に合わせて選択してください。一般的な端末では通常arm64を選びます。分からない場合は端末情報を確認し、ダウンロードページの汎用パッケージの説明を参照してください。既存アプリを上書きインストールできない場合は、システムが表示する理由を確認し、署名の違いや別のユーザー環境でのインストール記録を調べます。上書きのためにデータをすぐ消去せず、先にバックアップしてください。

設定を移行する場合は、システム関連の項目をすべて無条件にコピーするのではなく、自分のサブスクリプションを再登録して更新する方法を優先します。アプリごとの一覧、バックグラウンド権限、VPNの許可は端末環境に依存するため、新しい端末で確認し直してください。手動設定したノードが1つだけ接続できない場合は、共有パラメーター全体とコアの対応状況を確認します。すべてのノードが2種類のネットワークで失敗する場合は、端末の設定だけを何度も探るのではなく、アカウントとサービスの状態を確認してください。

最後に実際の使用環境で、画面表示中のアクセス、ロック解除後の復旧、ネットワーク切り替え、対象アプリの接続、正常な切断後の基本ネットワークを確認します。有効な設定を保存し、一時的なデバッグ設定や不要な権限変更は元に戻してください。インストールパッケージを選び直す場合は、Androidクライアントのダウンロードへ進んでください。一般的な操作の違いを確認するだけなら、よくある質問を参照してください。一連の確認が終わってから普段の複雑なルールを戻すと、次回のトラブル時にも比較の基準を保てます。