V2Ray トラブルシューティングガイド

まず現象を特定し、次に原因の層を絞り込み、最後に設定を変更します。本章は以降すべての章の共通の出発点です。

トラブルシューティングの第一歩は設定変更ではなく、現象の特定です。同じ「接続できない」でも、システムプロキシが適用されていない、ノードが失効している、DNS 解決に失敗している、ルーティングルールにブロックされている、など原因はさまざまで、対処法もまったく異なります。本マニュアルのすべての章は「現象の確認 → 原因の層の特定 → 設定変更」の順で構成されており、原因不明のままクライアントを何度も再起動する事態を避けられます。クイックスタートガイドは「使い方」、本マニュアルは「トラブル発生時の対処法」を扱います。2 つをあわせてご活用ください。

確認を始める前に、クライアントのバージョン・コアのバージョン・システム時刻の 3 つを確認してください。これらはログ画面と設定画面ですぐに確認できます。メモしてから作業を始めると、無駄な試行錯誤を大幅に減らせます。

ログ:接続問題の第一級の資料

ログは問題を特定するための第一級の資料です。v2rayN のログはメニューの「ログを表示」から開け、接続とルーティングのイベントが既定で記録されます。ハンドシェイク失敗や TLS エラーを調べるときは、ログレベルを「デバッグ」に上げてから再現すると、接続の一連の流れを完全に取得できます。v2rayNG のログは「設定 → ログ記録」にあり、こちらもレベル別の出力に対応しています。ログのキーワードと調査の方向性の対応は次のとおりです。

バージョンとコア:独立した 2 つの変数

クライアントのバージョンとコアのバージョンは独立した 2 つの変数です。v2rayN は「設定 → パラメータ設定 → コア」でコア(Xray-core または V2Fly-core)を確認・切り替えできます。v2rayNG は既定で Xray コアを内蔵し、v2flyNG は v2fly コアに対応しています。バージョンの確認方法:v2rayN のメイン画面にクライアントのバージョンが表示され、「設定 → パラメータ設定 → コア」の上部にコアのバージョンが表示されます。v2rayNG は「情報」ページでバージョン番号とコア情報を確認できます。クライアントをアップグレードした後に問題が発生した場合は、同時にコアのバージョンも変わっていないか確認してください。両者は厳密に対応している必要はありませんが、差が大きすぎると設定項目の非互換が生じることがあり、起動直後にエラーになる、一部のノードに接続できない、といった症状が出ます。

システム時刻:TLS エラーの頻出原因

端末の時刻が実際の時刻と数分以上ずれていると、証明書の検証が即座に失敗します。症状は、ノード一覧は正常・遅延テストも正常なのに、接続した瞬間にエラーになり、ログに証明書関連のエラーが記録される、というものです。「システム時刻を合わせる」を調査順の最初に置くのが、最もコストが低く、最も効果的です。Windows・macOS・Android は自動時刻同期に対応しているので、有効にしてからクライアントを再起動してください。

最小構成での検証:2 つの方法でクロスチェック

接続性を検証するときは、2 つの方法を併用することをおすすめします。1 つ目はブラウザのシークレットウィンドウで目的のサイトにアクセスする方法で、拡張機能とキャッシュの影響を排除できます。2 つ目はターミナルで curl コマンドを実行する方法で、ブラウザより実際の経路の状態に近い結果が得られます。

# ローカル SOCKS プロキシ経由で目的のサイトにアクセス
curl -x socks5h://127.0.0.1:10808 -I https://www.google.com

# ローカル HTTP プロキシ経由で目的のサイトにアクセス
curl -x http://127.0.0.1:10809 -I https://www.google.com

# 現在有効なプロキシ環境変数を確認する(Linux / macOS)
env | grep -i proxy

2 つのコマンドのポート番号は、クライアントが実際に待ち受けているポートに合わせてください。v2rayN の既定の SOCKS ポートは 10808、HTTP ポートは 10809 で、「設定 → パラメータ設定 → ローカル待ち受け」で確認・変更できます。

「接続済みなのにインターネットに接続できない」の調査の流れ:プロキシが適用されているか、経路が使えるか、トラフィックがルールにブロックされていないか。

「接続済みなのにインターネットに接続できない」は最もよくある障害です。クライアントはプロキシ経路を確保できているものの、トラフィックが正しくその経路に入っていないか、入った後にどこかのルールでブロックされていることを意味します。次の順番で 1 つずつ確認してください。各ステップに明確な合格基準があります。

ステップ 1:システムプロキシの状態を確認

v2rayN のトレイメニューには「システムプロキシ」サブメニューがあり、「システムプロキシを自動構成」「システムプロキシを変更しない」「システムプロキシをクリア」の 3 つの状態があります。「システムプロキシを自動構成」を選ぶと、Windows と macOS ではローカルポートを指すシステムレベルのプロキシが書き込まれます。この項目が「システムプロキシをクリア」になっていると、ブラウザのトラフィックはクライアントを通りません。確認方法:システムのネットワーク設定を開き、プロキシサーバーのアドレスが 127.0.0.1 と対応するポートになっているか確認します。v2rayNG は Android ではシステムプロキシを使わず、VPN 経由でトラフィックを引き受けるため、確認項目はシステムの「VPN 設定」にあります。

ステップ 2:直接接続での比較テスト

クライアントのプロキシをオフにして、中国国内のサイトに直接アクセスしてみてください。直接接続でもつながらない場合は、ローカルネットワーク自体の問題で、プロキシとは無関係です。先に Wi-Fi またはブロードバンドを復旧してください。直接接続は正常なのに、プロキシを有効にすると全サイトにつながらない場合は、次のステップに進みます。このステップで「ローカルネットワークの障害」と「プロキシ経路の障害」を素早く切り分けられるので、省略しないでください。

ステップ 3:ノードの接続性を検証

v2rayN のメイン画面で現在のノードを選択し、「サーバーの実接続遅延をテスト」をクリックします。ここでは 2 種類の結果を区別してください。TCP 遅延だけの表示はポートに到達できることを示すだけで、プロキシのハンドシェイク成功を意味しません。「実接続遅延」は実際にプロトコルのハンドシェイクを行うため、より信頼できる結果です。実接続テストに失敗したら、別のノードで再テストしてください。すべてのノードで失敗する場合はローカルの経路またはクライアント設定の問題、一部のノードだけ失敗する場合はそのノードのサーバーの問題なので、第 3 章の手順に従ってください。

ステップ 4:ルーティングモードを確認

ルーティングモードは、どのトラフィックをプロキシ経由にするかを決めます。v2rayN でよく使われるのは次の 3 つです。「中国本土を迂回」— 中国国内のアドレスは直接接続し、それ以外はプロキシ経由。日常利用に向いています。「グローバル」— すべてのトラフィックをプロキシ経由。「直接接続」— すべてプロキシを通さない。現在「中国本土を迂回」で、目的のサイトが中国国内と判定されている場合、トラフィックは直接接続され、「プロキシは有効なのにサイトが開かない」という症状になります。ルーティングモードを一時的に「グローバル」に切り替えて試し、つながるようであれば振り分けルールの判定が原因です。「中国本土を迂回」に戻したあと、第 6 章に従って DNS とルールを調整してください。

ステップ 5:DNS とブラウザのキャッシュ

ルーティングモードが正常なのに一部のドメインの名前解決に失敗する場合は、DNS を確認します。v2rayN の「DNS 設定」でリモート解決が有効になっていると、ローカルシステム DNS の汚染を回避できます。名前解決のリクエストがローカル DNS を通っていると、汚染によって誤った IP に解決されることがあり、ドメインでは開けないのに IP 直接接続では通る、という症状になります。ブラウザ側はまずシークレットウィンドウで再テストし、キャッシュと拡張機能の影響を排除してください。

• システムプロキシが「システムプロキシを自動構成」になっている
• 直接接続の比較プロキシをオフにするとローカルネットワークで正常にアクセスできる
• ノードテスト「実接続遅延」テストに合格
• ルーティングモードと目的のサイトの判定が一致している
• ブラウザ側シークレットウィンドウではアクセスでき、通常ウィンドウではできない場合はキャッシュと拡張機能をクリア
• 最終確認ノードを変更しても失敗する場合は、ローカルのファイアウォールとウイルス対策ソフトを確認

より詳しいプラットフォーム別の手順は、技術ノート『v2rayNG 接続済みなのにインターネットに接続できない:システムプロキシからルーティングルールまでの確認チェックリスト』を参照してください。

まずログのタイムアウトの形態を確認し、それから調査の方向(ポート・プロトコル・回線・証明書)を決めます。

ノード接続タイムアウトと「インターネットに接続できない」の違いは、前者がプロキシ経路の確立に失敗しているのに対し、後者は経路は確立できたもののトラフィックの流れが正しくないことです。タイムアウト問題の調査では、ローカルからサーバーまで、サーバーから目的のサイトまで、プロトコルハンドシェイク自体、のどこで障害が起きているかを切り分けることが重要です。

3 種類のタイムアウトを区別する

接続タイムアウト(ログでは dial tcp や connect: connection refused がよく見られます)は、ローカルからサーバーのポートに到達できないことを示し、ポートが塞がれている、サーバーがダウンしている、ローカルのファイアウォールが遮断している、などの原因が考えられます。ハンドシェイクタイムアウトは TCP は通っているのにプロトコル層が応答しない状態で、プロトコル種別の誤り、TLS 設定の不一致、サーバー負荷の過大がよくある原因です。読み取りタイムアウトはハンドシェイクは成功したもののデータの流れが途切れる状態で、回線品質やサーバーの出口制限が関係することが多いです。3 つの形態で調査の方向が異なります。

サーバー側の要因

ポートが開放されていない、またはプロトコル設定の誤りが最も一般的な原因です。ノード情報のポートがサーバーの実際の待ち受けポートと一致しているか確認してください。プロトコル(VMess/VLESS/Trojan)、転送方式(ws/grpc/tcp)、TLS のオン・オフはサーバー設定と厳密に対応している必要があります。たとえばサーバーが VLESS + Reality なのに、クライアントが VLESS + TLS になっていると、ハンドシェイクは必ず失敗します。この種のエラーはログではハンドシェイク段階のタイムアウトや EOF として現れることが多いです。また、サーバー側でファイアウォールやクラウド事業者のセキュリティグループが 443 ポートだけを許可していて、ノード設定が別のポートになっている場合も、接続タイムアウトになります。

ローカル側の要因

ローカルのファイアウォール・ウイルス対策ソフト・プロキシソフトの競合が、外向きの接続を遮断することがあります。Windows では一時的にファイアウォールを無効にするか、クライアントに許可ルールを追加してください。macOS は「システム設定 → ネットワーク → ファイアウォール」の受信遮断を確認します。Linux は ufw または firewalld の状態を確認します。システムで IPv6 が有効でノードが対応していない場合、IPv6 優先の接続が発生してタイムアウトすることがあるので、クライアントで「IPv6 を優先」をオフにするか、システムの IPv6 を一時的に無効にして検証してください。社内ネットワークや学内ネットワークでは非標準ポートの制限もよくあります。こうした環境では 443 ポートのノードを優先的に使うことをおすすめします。

診断コマンドとログ

ログレベルを「デバッグ」にして再現し、接続確立に失敗する直前の最後の 2 件の記録に注目してください。コマンドラインでは nc や curl で対象を絞ってテストできます。

# TCP ポートに到達できるかテストする(タイムアウト 5 秒)
nc -vz -w 5 <サーバーアドレス> <ポート>

# ローカル SOCKS プロキシ経由で目的のサイトにアクセス
curl -x socks5h://127.0.0.1:10808 -v https://www.google.com

nc が succeeded を返せばポートには到達できており、問題はプロトコル層にあります。timeout または connection refused を返す場合は、ポートまたはネットワーク層に問題があります。ログに certificate 関連の記述がある場合は、まずシステム時刻を合わせ、次にノードの SNI とサーバーのドメインが一致しているか確認してください。この 2 つが TLS 系タイムアウトの最も一般的な原因です。TLS 証明書エラーの原因の完全な分析は、技術ノート『V2Ray TLS ハンドシェイク失敗と証明書エラー:システム時刻・SNI・allowInsecure の解説』を参照してください。

購読の失敗は、購読 URL 自体、購読サーバーへの到達性、返される内容の形式の 3 つに関係します。

購読の失敗は、購読 URL 自体、購読サーバーへの到達性、返される内容の形式の 3 つに関係します。v2rayN と v2rayNG はどちらも購読からの一括ノード取り込みに対応しています。失敗したときは次の順序で確認してください。多くの問題は最初の 3 ステップで解決します。

購読 URL を確認

完全な購読アドレスは https:// で始まり、末尾に余分な空白や改行が含まれていない必要があります。購読リンクをコピーするとき、チャットアプリが空白を追加したり改行で切ったりすることがあり、貼り付け後は肉眼では気づきにくいです。v2rayN では「購読グループ → 購読グループ設定」を開き、URL を入力欄に貼り付けて 1 文字ずつ照合してください。v2rayNG も「購読設定」で同様に操作します。URL に & パラメータが含まれる場合は、コピーでパラメータ部分が欠けていないか確認してください。一部のサービス事業者は複数の購読アドレス(base64 版と Clash 版など)を提供しているので、クライアントが対応している形式を使っているか確認してください。

ネットワークへの到達性を確認

購読サーバーはローカルネットワークから直接アクセスできる必要があり、プロキシ経由でアクセスするサイトとは異なります。ローカルネットワークが購読ドメインを名前解決できない場合、購読の更新は失敗します。判定方法:ブラウザで購読 URL を直接開き、テキストがダウンロードできればネットワーク到達性は問題ありません。開けない場合は、まず購読ドメインの名前解決の問題を解決してください。購読ドメインを一時的にプロキシルールに追加するか、アクセスできるミラーアドレスに切り替える方法があります。v2rayN の「購読を更新(プロキシ不使用)」は現在のプロキシ経由で購読を取得するため、購読ドメインに直接到達できない場合に適しています。

内容の形式を確認

購読が返す内容は、base64 エンコードされた v2ray リンクの一覧の場合もあれば、Clash や sing-box などの形式の場合もあります。v2rayN は一般的な形式の識別に対応しています。v2rayNG は主に v2ray 標準形式と base64 を識別します。返される内容が HTML のエラーページや空ファイルの場合は、購読インターフェース自体の異常で、クライアントとは無関係です。手動での検証方法:ダウンロードしたテキストをデコード対応のオンラインツールに貼り付けるか、先頭を直接確認します。vmess://・vless://・trojan:// で始まるものは標準リンク、長い base64 文字列で始まるものはエンコードされた一覧です。

更新タイミングとキャッシュ

購読の更新頻度はグループ設定で制御されます。追加したばかりの新しいノードはすぐには表示されず、「購読を更新」を手動でクリックする必要があります。更新した直後にすぐもう一度クリックすると、一部の購読サーバーには頻度制限があり、429 や空の内容が返されます。v2rayN の「購読グループ」の右クリックメニューには「購読を更新」と「購読を更新(プロキシ不使用)」の 2 つの項目があり、ネットワーク状況に応じて使い分けてください。

手動インポートによる代替手段

購読サーバーが利用できないときは、ノードを手動で 1 つずつインポートできます。v2rayN はクリップボードからのインポートに対応しています。vmess:// または vless:// で始まる完全なリンクをコピーし、トレイメニューの「クリップボードからインポート」を選ぶだけです。v2rayNG も「クリップボードからインポート」に対応しています。ノードの単体インポートは購読インターフェースに依存しないため、緊急時の調査に有効です。インポート後は遅延をテストしてから使用してください。

まずボトルネックがどの層にあるかを特定し、その層に合わせて調整します。ノードをむやみに変えないようにします。

速度低下は一度で特定するのが最も難しい問題です。サーバー・回線・ローカルの 3 層にまたがって要因が存在するためです。本稿では層ごとに調査します。まずボトルネックがどの層にあるかを特定し、その層に合わせて調整します。ノードをむやみに変えないようにします。速度問題の層別の考え方の詳細は、技術ノート『v2rayN の速度が遅い場合:ノード・回線・ローカル設定の 3 層調査法』も参照してください。

まず信頼できる速度測定を 1 回行う

遅延の数値で速度を判断しないでください。遅延はハンドシェイクの往復時間を反映するだけで、ダウンロードのスループットとは線形の関係がありません。測定方法:まず v2rayN でノードに対して「実接続遅延」テストを行い、経路が利用可能なことを確認します。その後、コマンドラインで実際にファイルをダウンロードします。

curl -o /dev/null -w "%{speed_download}\n" \
  -x socks5h://127.0.0.1:10808 \
  https://speed.cloudflare.com/__down?bytes=10000000

3 回繰り返して中央値を採用し、瞬間的な変動を除外します。朝のピーク時と深夜で速度の差が大きい場合、ボトルネックは基本的にサーバーと回線の層にあり、ローカル設定をどう調整しても上限は変わりません。

ノードと回線の層

ノードの負荷・帯域上限・回線品質が速度の上限を決めます。同じサービス事業者の複数のノードなら、負荷の低い方を選んでください。事業者が異なる場合、回線の差で数倍の開きが出ることがあります。転送方式も影響します。電波が弱い環境では、grpc と reality は素の tcp よりパケットロスに強い傾向があります。通信事業者が UDP を速度制限している環境では、UDP ベースの転送は TCP より遅くなることがあります。ノードのプロトコルと転送方式を記録しておき、ノードを変えるときは同じ組み合わせを保つと、比較に意味が出ます。

ローカル設定の層

クライアントのローカル設定が速度に与える影響は、主に 3 か所です。1 つ目はログレベルで、「デバッグ」はオーバーヘッドを大幅に増やすため、調査が終わったら「情報」または「警告」に戻してください。2 つ目はルーティングルールの数で、ルールが多いほど接続ごとの振り分け判定に時間がかかるため、不要なルールを整理できます。3 つ目は mux(多重化)のオン・オフで、パケットロスの多い回線では mux が再送のオーバーヘッドを拡大することがあり、オフにしたほうが速くなる場合もあります。v2rayN の「設定 → パラメータ設定 → ルーティング」と「設定 → パラメータ設定 → コア」でこれらの項目を調整できます。

システムレベル

DNS 解決の所要時間は、新しいドメインに初めてアクセスするたびに影響します。ローカル DNS が汚染されていると、名前解決がタイムアウトして再試行され、「ページが数秒止まってから読み込まれる」という症状になります。クライアントのリモート DNS または FakeDNS を有効にすると、この待ち時間を短縮できます。MTU の不一致は大きなパケットが断片化されて破棄される原因になり、ページは開けるのに大きなファイルのダウンロードが極端に遅い、という症状になります。システムのネットワーク設定で MTU を 1500 から 1400 前後に下げて検証してください。ウイルス対策ソフトのリアルタイムスキャンもダウンロードを遅くするため、クライアントのディレクトリを除外項目に追加してください。

3 つの症状:名前解決の失敗、プロキシ経由にすべきドメインが直接接続される、解決結果が誤った IP を指す。

DNS の問題は、通常 3 つの症状で現れます。一部のドメインの名前解決に失敗する、プロキシ経由にすべきドメインが直接接続される、解決結果が誤った IP を指す、の 3 つです。DNS 設定は Xray コアの高度な機能です。設定構造を理解すれば、ほとんどの問題は dns セクション内で解決できます。

DNS の症状を識別する

ドメインでは開けないのに IP 直接接続では通る場合、DNS 汚染の典型的な特徴です。プロキシ経由にすべきサイトが直接接続される場合は、通常、名前解決の結果が「中国本土を迂回」の IP 帯判定に該当したことを示します。もう 1 つのよくある状況は、ノード一覧も接続も正常なのに、一部のサイトでログインがおかしい、または CAPTCHA が読み込めない、というものです。こうした問題は、DNS が汚染された中間結果を返していることが関係していることが多いです。なお、DNS 関連のエラーがノードの問題と誤判定されることがあります。ログに resolution failed や no such host が現れたら、ノードより先に DNS を確認してください。

Xray DNS 設定の構造

Xray の DNS 設定は dns セクションにあり、中心となるのは servers リストと queryStrategy です。servers にはローカル DNS(例:223.5.5.5)とリモート DNS(例:1.1.1.1 や DoH アドレス)を同時に設定でき、ドメインルールでどのドメインがどのサーバーを使うかを決めます。

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

この例の構造は、中国以外のドメインはリモート DNS、中国のドメインはローカル DNS を使い、返された IP が中国の IP 帯に属するか検証するものです。実際に使うときは、例の中のアドレスを自分の DNS サーバーに置き換えてください。servers の順序には優先順位があり、ドメインルールが重複する場合は先にマッチした方が優先される点に注意してください。

FakeDNS を有効にする場面

FakeDNS は予約済みネットワークの仮想 IP で実際の名前解決を置き換え、透過プロキシや TUN モードでもドメインルールを有効にし、さらに DNS の往復を 1 回減らします。有効化の場所は v2rayN の「設定 → パラメータ設定 → コア → FakeDNS を有効にする」です。適している場面:TUN モードを使用している、ドメインレベルの振り分けが必要、ローカル DNS が汚染されている。適さない場面:システムプロキシのみを使用している、IP 直接接続の強いニーズがある、一部のアプリが仮想 IP に敏感。有効化後にログイン異常や証明書エラーが出た場合は、まず FakeDNS をオフにして比較してください。FakeDNS とリモート DNS は同時に有効にできます。前者はドメインルールのマッチングを解決し、後者は名前解決結果の信頼性を解決します。原理と限界は、技術ノート『FakeDNS とは:Xray コアの仮想 IP 名前解決の原理と有効化の場面』を参照してください。

ブラウザの DoH とシステム DNS の競合

ブラウザ内蔵の「セキュア DNS」(DoH)は、システムとクライアントの DNS 設定を迂回し、ブラウザに設定された DoH サーバーへ直接問い合わせるため、振り分けが機能しなくなります。調査方法:ブラウザのセキュア DNS を一時的にオフにして、ドメインの名前解決が正常に戻るか観察します。ドメインレベルの振り分けが必要な場合は、ブラウザの DoH をオフにして、名前解決をクライアントに一元化することをおすすめします。システムレベルの「プライベート DNS」(Android)も同様で、「自動」にするかオフにしてください。

調査のポイントは、プロキシのポートと適用範囲です。ポートが使用されていないか、システムプロキシが正しいポートを指しているか、アプリがシステム設定を読んでいるか。

「クライアントは接続済みと表示されるのに、ブラウザがプロキシを通らない」と「インターネットに接続できない」の違いは、前者がプロキシをシステムやアプリが使っていないのに対し、後者はプロキシ経路自体が通っていないことです。この種の問題の調査ポイントは、プロキシのポートと適用範囲です。

ローカルの待ち受けポートを確認

v2rayN は既定でローカルに 2 つのポートを待ち受けます。SOCKS 10808、HTTP 10809 です。システムプロキシはこの 2 つのいずれかを指している必要があります。ポートが使用されている場合、クライアントが自動的にポートを変更することがあり、システムプロキシが無効なポートを指してしまうことがあります。確認方法:「設定 → パラメータ設定 → ローカル待ち受け」で実際のポートを確認し、システムプロキシ設定のアドレスと照合してください。コマンドラインでは次のコマンドで待ち受け状態を確認できます。

# Windows:10808 ポートの待ち受け状態を確認
netstat -ano | findstr 10808

# Linux / macOS:10808 ポートの待ち受け状態を確認
lsof -i :10808

ポートが他のプログラムに使用されている場合は、そのプロセスを終了するか、クライアント設定でローカルポートを変更してください。ポートを変更したら、システムプロキシのアドレスも同時に変更する必要がある点に注意してください。

自動構成の仕組みとプラットフォームによる違い

「システムプロキシを自動構成」はプラットフォームによって実装が異なります。Windows はシステムプロキシのレジストリに書き込み、macOS はネットワークサービスの設定を変更し、Linux のデスクトップ環境は通常、環境変数またはデスクトップ設定に依存します。Linux の多くのディストリビューションはシステムプロキシを自動設定しないため、環境変数を手動でエクスポートする必要があります。

export http_proxy=http://127.0.0.1:10809
export https_proxy=http://127.0.0.1:10809
export socks5_proxy=socks5h://127.0.0.1:10808

これらの変数は現在のターミナルでのみ有効です。GUI アプリはデスクトップ設定または起動スクリプトから読み取る必要があります。macOS では Wi-Fi を切り替えたあと、古いプロキシ設定が残ることがあり、「システムプロキシは設定済みと表示されるのに実際には効いていない」という症状になります。「システムプロキシを自動構成」をもう一度切り替えると更新されます。

ブラウザ拡張機能による接管の競合

SwitchyOmega のようなプロキシ拡張機能は、ブラウザレベルでトラフィックを引き受け、システムプロキシを迂回します。拡張機能の設定が指すポートとクライアントの実際のポートが一致しない場合、ブラウザは直接接続に失敗します。調査:プロキシ拡張機能を一時的に無効にするか、拡張機能のポートをクライアントが実際に待ち受けているポートに変更してください。ブラウザ自体の「セキュア DNS」もプロキシ設定を迂回するので、あわせて確認してください。

アプリがプロキシを通らないよくある原因

一部のアプリはシステムプロキシを読み取らないため、個別に設定が必要です。Windows の UWP アプリはネットワーク分離の影響を受けるため、「ネットワーク分離」関連の設定をオフにしてみてください。macOS のネイティブアプリの多くはシステムプロキシを通りますが、コマンドラインツールは環境変数が必要です。v2rayN は「TUN モード」を提供しており、仮想ネットワークカードで全トラフィックを引き受けるため、システムプロキシを読み取らないアプリに最も効果的です。TUN を有効にするとシステムプロキシ設定は必須ではなくなりますが、管理者権限が必要で、一部の VPN ソフトと競合します。

1. クライアントの実際の待ち受けポートを確認—「ローカル待ち受け」で確認し、システムプロキシのアドレスと照合します。
2. システムプロキシの指す先を確認—Windows と macOS はシステムのネットワーク設定でプロキシサーバーのアドレスを確認します。
3. ブラウザのプロキシ拡張機能をオフにして再テスト—拡張機能レベルの接管を排除します。
4. ターミナルで環境変数をエクスポートして再テスト—コマンドラインツールがプロキシを通るか確認します。
5. それでも無効なら TUN モードを有効化—仮想ネットワークカードで全トラフィックを引き受けます。

修復の順序は「バックアップ → リセット → 復元」の順に従い、設定が壊れた状態で何度も再起動することを避けます。

クライアントのクラッシュは 3 種類に分けられます。起動時にクラッシュ、接続中にクラッシュ、購読更新時にクラッシュです。クラッシュの多くは設定の破損・コアファイルの欠落・ポート競合が原因で、次の手順で素早くリセットできます。修復の順序は「バックアップ → リセット → 復元」の順に従い、設定が壊れた状態で何度も再起動することを避けます。

起動時にクラッシュ

起動時にクラッシュする場合は、まず設定の破損を疑ってください。v2rayN の設定はユーザーディレクトリの guiConfig 関連ファイルに保存され、破損しているとクライアントは起動段階で読み込みに失敗します。対処:クライアントを終了し、設定ディレクトリ全体の名前を変更してバックアップし(たとえば .bak を付ける)、再起動します。クライアントは既定の設定で再構築されます。バックアップディレクトリはクライアントのデータディレクトリの外に置き、再読み込みされないように注意してください。名前を変更してもまだクラッシュする場合は、他のセキュリティソフトがクライアントのプロセスをブロックしていないか確認してください。再構築後、購読を再インポートするとノード一覧が復元されます。

接続中にクラッシュ

接続中のクラッシュは、コアと設定の不一致がよくある原因です。v2rayN でコア(Xray-core / V2Fly-core)を切り替えたあと、古い設定の一部の項目が新しいコアに認識されないことがあります。対処:「設定 → パラメータ設定 → コア」で元のコアに戻すか、ノードを削除して購読から再インポートしてください。また、ログレベルを「デバッグ」にしたまま長時間実行すると、巨大なログファイルが生成され、ディスクを満たして異常の原因になることがあります。調査が終わったら早めに「情報」に戻してください。

コアファイルの欠落とウイルス対策ソフトによる誤削除

コアファイルが欠落していると、クライアントの起動時にコアが見つからないというメッセージが表示されます。よくある原因は、ウイルス対策ソフトがコアの実行ファイルを脅威として隔離することです。対処:ウイルス対策ソフトの隔離領域からファイルを復元し、クライアントのディレクトリを信頼領域に追加してください。v2rayN の「設定 → パラメータ設定 → コア」でコアを再ダウンロードできます。ダウンロードに失敗する場合は、ローカルネットワークがコアのダウンロードアドレスにアクセスできるか確認し、必要に応じてプロキシ経由でダウンロードしてください。v2rayNG のコアはインストールパッケージに内蔵されているため、欠落のメッセージが出た場合は再インストールを優先してください。インストールパッケージはダウンロードセンターから取得できます。

ポートの使用

ローカルポートが他のプログラムに使用されていると、クライアントの待ち受けが失敗し、起動直後に終了する、またはプロキシが効かないという症状になります。netstat または lsof で使用中のプロセスを見つけ、そのプロセスを終了するか、クライアント設定でローカルポートを変更してください。ポート競合は複数のプロキシクライアントを同時に実行している場合にもよく発生します。これらは既定で同じポートの組み合わせを使用するためです。

v2rayNG のクラッシュ処理

v2rayNG がクラッシュした場合は、アプリのデータを消去してから購読を再インポートできます。Android でバックグラウンド中にクラッシュが発生した場合は、バッテリー最適化がアプリを凍結していないか確認し、アプリを「制限なし」のバッテリーポリシーに追加してください。v2flyNG の対処も同じです。2 つのクライアントの設定は互換性がないため、データディレクトリを直接コピーしないでください。データの消去は購読と設定も同時に削除するので、操作前に購読アドレスを控えてください。

1. 設定ディレクトリをバックアップ—名前を変更して、障害発生時の状態を保持します。
2. 既定の設定に戻して起動—クライアントが正常に開けることを確認します。
3. 購読を再インポート—ノード一覧を復元します。
4. コアの完全性を確認—コアファイルが隔離または削除されていないか確認します。
5. ポートの使用状況を確認—ローカルポートが他のプログラムに使用されていないか確認します。

モバイル端末の調査の違いは、主に 3 つです。バックグラウンドでの常駐、システムレベルのプロキシ接管方式、バッテリーとネットワークのポリシー。

モバイル端末とデスクトップ端末の調査の違いは、主に 3 つです。バックグラウンドでの常駐、システムレベルのプロキシ接管方式、バッテリーとネットワークのポリシー。本節では v2rayNG と v2flyNG のよくある問題に沿って説明します。Android はシステムバージョンによる違いが大きいため、以下の手順は一般的な設定を基準にしています。

接続は成功するがアプリがプロキシを通らない

Android では v2rayNG は既定で VPN 経由でトラフィックを引き受けるため、システムの「VPN 設定」でアプリが VPN 接続を確立することを許可する必要があります。接続アイコンは正常に表示されるのに目的のアプリが直接接続される場合は、ルーティングモードを確認してください。既定の「中国本土を迂回」では、中国国内のアプリは直接接続されます。プロキシが必要なアプリが中国国内と判定されると、直接接続に失敗します。ルーティングを一時的に「グローバル」に切り替えて検証するか、「アプリごとのプロキシ」を使用している場合は目的のアプリがチェックされているか確認してください。一部の機種では VPN に追加の省電力制限があり、「アプリ情報」で「省電力ポリシー」の VPN への制限をオフにする必要があります。

バックグラウンドで終了され切断される

Android は省電力のためバックグラウンドアプリを凍結することがあり、v2rayNG が凍結されると VPN 経路も切断されます。対処:システム設定で v2rayNG を「バッテリー最適化のホワイトリスト」に追加してください。一部の機種では「自動起動管理」で自動起動を許可する必要もあります。v2rayNG の「接続時に自動再接続」を有効にすると短時間の切断を緩和できますが、根本原因は依然としてバックグラウンド制限です。メーカーごとの ROM でバックグラウンドポリシーの実装は大きく異なります。切断が発生したら、まず「バッテリー」ページにアプリの凍結の通知がないか確認してください。

購読の更新失敗

モバイル端末での購読更新の失敗は、システム時刻または証明書に関係することが多いです。Android の自動時刻同期がオフになっていると、時刻のずれで HTTPS 証明書の検証に失敗し、購読リクエストが拒否されます。対処:「自動的に時刻を設定」を有効にし、タイムゾーンも合わせてください。また、一部の購読ドメインはモバイルネットワークから直接到達できないことがあります。v2rayNG の購読設定で「プロキシ経由で更新」を有効にしてください。ただし、その時点で利用可能なノードが必要です。Wi-Fi とモバイルネットワークを切り替えた後は、ネットワーク状態が更新されずに購読更新が失敗することもあります。機内モードをオン・オフしてから再試行してください。

プライベート DNS とプロキシの競合

Android の「プライベート DNS」機能はアプリ層の DNS 設定を迂回し、クライアントのドメイン振り分けと競合します。症状:クライアントは接続済みと表示されるのに、一部のドメインの名前解決が異常になります。対処:プライベート DNS を「自動」にするかオフにして、名前解決をクライアント設定に一元化してください。プライベート DNS をどうしても使う場合は、DoH に対応し汚染された結果を返さないサーバーを選んでください。ただし、ドメインレベルの振り分けは機能しなくなる可能性があります。

v2flyNG の違い

v2flyNG は v2fly コアを使用しており、v2rayNG の Xray コアとは設定項目に違いがあります。同じ購読は通常 2 つのクライアントの両方にインポートできますが、一部の高度なパラメータ(一部の転送方式の拡張項目など)は互換性が異なります。調査するときは、まずノードのプロトコルと転送方式が現在のコアでサポートされているか確認し、それからコアまたはクライアントの切り替えを検討してください。2 つのクライアントの設定データは互いに独立しているため、再インストールやもう 1 つへの切り替え時には購読を再インポートする必要があります。