V2Rayのトラブルシューティング：接続・サブスクリプション・DNS・システムプロキシ

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

クライアントが起動していても、アプリの通信がプロキシを経由しているとは限りません。通常、通信はアプリ、ローカル待ち受け、コアのルーティング、リモート接続、接続先サービスの順に進みます。途中で通信が引き継がれなければ、設定が正しくても後続の段階にはリクエストが届きません。まず、すべてのアプリで失敗するのか、ブラウザーだけなのか、一部のサイトだけなのかを記録します。接続前後の変化も書き留め、もともとのネットワーク障害をクライアントの問題と混同しないようにしましょう。

直接接続とプロキシ接続を比較する

まずクライアントでシステムプロキシを解除するか、Androidの接続を停止してから、普段直接アクセスできるページを開きます。直接接続も失敗する場合は、Wi-Fiの認証、ルーターへの接続、システム時刻など、ネットワーク自体の問題を先に解決してください。すでに開いているタブだけで判断しないでください。キャッシュが表示されている可能性があります。新しいページを開いて再読み込みし、実際に通信が発生したことを確認してから、クライアントを起動して同じページにアクセスします。

デスクトップでは、まずv2rayNで切り分けるのがおすすめです。設定を開き、実際のローカル待ち受けアドレス、ポート、プロトコルを確認して、システムプロキシのアドレスと照合します。当サイトの図にある10808や10809が、すべてのバージョンで共通するとは限りません。画面によっては混合待ち受けを使い、SOCKSとHTTPを別々に設定する場合もあります。現在のクライアント設定と起動ログを基準にし、古い画面キャプチャを参考にシステム設定を変更しないでください。

次にクライアントのログを開き、古い内容を消すか現在時刻を記録してから、失敗するアクセスを1回だけ行います。新しい接続記録がまったく出ない場合は、アプリがシステムプロキシを参照しているか、ブラウザー独自のプロキシ設定が上書きしていないかを確認します。ローカルのインバウンド記録の後にエラーが出る場合、リクエストはコアに届いています。ノード、ルーティング、DNSを確認してください。ログレベルが低く個別の接続が見えない場合は、一時的に1段階上げ、テスト後に元へ戻します。

明示的なプロキシでシステム設定を切り分ける

次のコマンドは、127.0.0.1:10808でSOCKSサービスが動作していると確認済みの場合に限り使用できます。ポートが異なる場合は置き換えてください。WindowsではPowerShellでcurl.exeを使い、macOSとLinuxではcurlを使えます。例のドメインは通信経路の確認用で、速度比較には使いません。ツールがインストールされていない場合は、アプリ内のプロキシ設定で確認できるため、診断のためだけに別のネットワークツールをインストールする必要はありません。

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

明示的なプロキシで応答があり、通常のブラウザーでは失敗する場合、まずノードを疑う必要はありません。システムプロキシの章を確認してください。ローカルアドレスに接続できないというエラーが出る場合は、コアのプロセス、待ち受けポート、ポートの競合を確認します。ローカル接続後にハンドシェイクエラーやタイムアウトが発生する場合は、ノードのタイムアウトの章を参照してください。HTTPエラーが返っても通信経路が確立している可能性があります。成功以外のステータスをすべてプロキシ切断と判断しないでください。

症状	優先して確認する項目	次の手順
直接接続も失敗する	基本ネットワーク、認証、システム時刻	プロキシを停止し、まず基本接続を復旧する
明示的なプロキシは使える	アプリのプロキシ、システムプロキシのアドレス	アプリがローカル待ち受けに接続しているか確認する
ローカル待ち受けへの接続が拒否される	コアの起動状態、ポートの競合	起動ログとポートを使用中のプロセスを確認する
一部のドメインだけ失敗する	ルールの適用、名前解決、接続先サービス	同じドメインで項目ごとに比較する

接続ボタンだけでなく、実際に復旧したか確認する

復旧時は逆の順に確認します。コアがエラーなく起動していること、ローカル待ち受けがあること、アプリのリクエストがログに記録されること、接続先ページから応答があることを確認してください。一度に変更するのは1項目だけにし、最初に失敗したアクセスを再試行します。ノードを切り替えると同時にDNS、ルーティング、ブラウザー設定も変えると、原因を特定できず、元の設定にも戻しにくくなります。解決したら対応内容を記録し、必要なログだけを保管してください。

ノードのタイムアウト：ポートから通信設定まで確認

タイムアウトは、ある処理が制限時間内に完了しなかったことを示すだけで、障害箇所を直接示すものではありません。ノード一覧の遅延テスト、通信接続の確立、Webページの読み込みでは、テスト対象や経路が異なる場合があります。まず、どの操作でエラーが出たのかを確認し、同じ時刻のコアログを調べてください。テストが1回失敗しただけでノードが恒久的に使えないとは限りません。連続して失敗する場合も、まずローカルネットワークの変化や設定の未反映を除外します。

接続拒否、ハンドシェイク失敗、タイムアウトを見分ける

ログにconnection refusedと表示される場合、通常は該当アドレスが接続を受け付けていません。ポートの誤り、サービスが待ち受けていない、中継機器による拒否などが考えられます。i/o timeoutは待ち時間が上限に達したことを示します。名前解決、接続の試行、応答の読み取りのどこで待っていたかを確認してください。EOFは接続が途中で終了したことを示すだけです。この1行だけで認証情報の誤りと判断せず、前後のプロトコルやハンドシェイクの記録も確認します。

まずシステムの日付、時刻、タイムゾーンを確認し、自動時刻同期を有効にします。証明書の有効期間確認や一部の認証方式は時刻に依存します。スリープ後、オフライン後、または手動で時刻を変更した後に、突然接続できなくなることがあります。次に、確認対象のノードが現在のアクティブノードかを確かめ、古い接続を停止して再接続します。リストで行を選択しただけでは、そのノードがアクティブになったとは限りません。

次に、サービス提供元の設定情報と照合し、サーバーアドレス、サーバーポート、ユーザーIDまたはパスワード、通信方式、セキュリティ設定を1項目ずつ確認します。サーバーポートはリモートサービスへの接続口で、ローカル待ち受けポートはアプリがクライアントへ接続する場所です。両者を取り違えないでください。サブスクリプションからインポートした項目も、古いキャッシュ、グループ更新の失敗、手動編集などにより、現在のサーバー設定と異なる場合があります。

現在のノードで使われている項目だけを確認する

WebSocketを使う設定では、パスとHostを確認してください。パスの大文字・小文字、先頭のスラッシュ、余分な空白が一致に影響することがあります。gRPCではサービス名を確認します。TLSを使う場合は、サーバー名と証明書の対応を確認してください。接続先アドレスと証明書名は一致しない場合があります。エラーを消すために証明書検証を無効にしないでください。設定の問題を隠し、接続のセキュリティを損なう可能性があります。

VLESSはプロキシプロトコル、REALITYは特定の実装に関連するセキュリティ機構であり、同じ設定項目ではありません。REALITYの設定を確認する際は、サーバーが指定するサーバー名、公開鍵、Short ID、フィンガープリントなどを照合し、使用中のコアがその組み合わせに対応しているか確認します。v2rayNGとv2flyNGではコアの系統が異なります。共有リンクをインポートできても、すべての項目がそのまま動作するとは限りません。

通信設定が複雑な場合は、既存の項目で選択肢を次々に試すのではなく、元の設定を再インポートして比較してください。元の項目は残し、テスト用の項目には識別しやすいメモを付けて、誤って上書きしないようにします。他のノードのパス、サーバー名、セキュリティ設定を流用しないでください。これらは通常、ひとまとまりの設定です。一部だけ置き換えると別のエラーが発生しやすくなります。

条件を一つずつ変えてリモート側の問題を確認する

クライアント設定は変えずに、動作確認済みの別ノードへ切り替えます。新しいノードで接続できる場合、元の項目の設定やリモート側の状態に問題がある可能性が高まります。すべてのノードが同じネットワークで失敗する場合は、別の正常なネットワークでも試し、他のプロキシやトンネルアプリは一時的に停止してください。ネットワークを切り替えたら接続を確立し直します。古い接続は、ネットワークの出口が変わっても有効な比較対象にはなりません。

アドレスとポートが正しく、クライアントの互換性も確認済みで、複数のネットワークでも失敗する場合に限り、サービス提供元へサーバーの待ち受け状態、ファイアウォール、アカウント状態を問い合わせます。失敗時刻、使用中のコア、機密情報を伏せたエラー行、すべてのノードで失敗するかを伝えれば十分です。サブスクリプションの完全なURL、ユーザーID、パスワード、共有リンクは公開しないでください。アクセス認証情報が含まれている場合があります。

サブスクリプションの更新失敗：取得と解析を分けて確認

サブスクリプションの更新には、内容の取得、形式の判別、ノードの解析、グループへの反映という段階があります。更新失敗の表示は、URLの期限切れとは限りません。ネットワークに接続できない、ログインページが返された、形式に対応していない、誤ったグループを選択したなどの原因も考えられます。まずエラー全文を記録し、「リクエスト失敗」か「解析失敗」かを見分けてから、ネットワークと取得内容のどちらを確認するか決めてください。比較対象となる設定を失わないよう、最初にすべてのノードを削除しないでください。

既存のグループと有効なノードを保護する

v2rayNでサブスクリプショングループを開き、更新対象のグループ名とURLが一致しているか確認します。重複したグループや似た名前のメモがないかも調べてください。クライアントに設定のエクスポート機能がある場合は、ローカルにバックアップを保存して安全に保管します。バックアップにアカウント情報が含まれることがあります。新しいURLを試す場合は別のグループを作成すると、既存のグループを上書きするより元に戻しやすく、更新前後のノードも比較できます。

URLを貼り付けるときは、先頭や末尾に空白、改行、引用符、チャットアプリが追加した説明文が含まれていないか確認します。疑問符以降のクエリパラメーターを勝手に削除しないでください。認証情報や形式の指定が含まれている場合があります。有効期限付きのURLは再取得が必要なことがありますが、長いURLだからといって問題があるとは限りません。サービス提供元がURLを再発行した場合、古いURLが引き続き使えるかどうかは提供元の案内に従ってください。

次に、今回の更新が直接接続とプロキシ接続のどちらで行われるか確認します。更新メニューの名称はクライアントや画面のバージョンによって異なるため、操作の説明を確認してください。現在のプロキシノードが使えない場合、それを使ってサブスクリプションを更新しようとすると堂々巡りになることがあります。直接接続が許可されているネットワークなら、通常の更新を試してください。逆に、利用可能なプロキシ経由でしかアクセスできないURLの場合は、動作確認済みの接続を選んでから更新します。

更新を繰り返す前に、取得した内容を確認する

ログにHTTPステータスが記録されている場合、認証関連のエラーではURLとアカウント権限を優先して確認します。リクエスト回数が多すぎる場合は、再試行を中断してサーバー側の案内に従ってください。成功ステータスが返っても、ノード情報が取得できたとは限りません。ネットワーク認証ページ、ログイン画面、リバースプロキシのエラーページが通常のWebページとして返されることがあります。クライアントがWebページをサブスクリプションとして解析すると、空の一覧や形式エラーだけが表示され、ページの内容までは説明されない場合があります。

応答内容を確認する必要がある場合は、信頼できるローカル環境でのみ操作し、サブスクリプションURLをオンラインデコードツールやオンラインテストツールに貼り付けないでください。返された内容が、クライアント対応の共有リンク一覧またはサブスクリプション形式であり、説明ページではないことを確認します。ブラウザーに長いテキストが表示されても、取得できたことを示すだけです。すべてのノードのプロトコル、項目、文字コードが現在のクライアントに対応しているとは限りません。

同じサブスクリプションから一部のノードしかインポートされない場合は、取り込まれなかった項目のプロトコルと通信方式を確認します。必要な項目が欠けている、形式の拡張に対応していない、別の設定体系向けの内容がサーバーから返されたなどの可能性があります。サービス提供元に、現在のクライアント向けの出力形式を選んでもらってください。別用途の設定一式を、単一ノードのインポート欄に貼り付けないでください。コアを切り替える場合も、対応プロトコルを確認します。

フィルター、グループ、更新結果を確認する

更新成功と表示されても一覧が空の場合は、まず検索キーワードを消し、すべてのグループに切り替え、ノード名のフィルターや非表示条件が有効になっていないか確認します。次に、ステータス表示だけでなく、ログに記録されたインポート数と現在の一覧を比較してください。クライアントによっては新しいサブスクリプションの内容でグループ内の古い項目が置き換えられます。サーバーから空の内容が返された状態で更新を繰り返すと、既存のノードが消えることがあります。バックアップがあれば復元しやすくなります。

更新成功は接続確認の成功を意味しません。新しくインポートしたノードをアクティブにして再接続し、サブスクリプションのインポート手順に沿ってアクセスを確認してください。新しいノードがすべて失敗し、古いノードは使える場合は、設定と出力形式の違いを重点的に比較します。更新だけが失敗し、既存ノードは使える場合は、ノードのルーティング、DNS、通信設定を同時に変更しないでください。

形式の互換性に問題がある場合は、クライアントのダウンロードページでOSとアーキテクチャに合ったクライアントを選び、設定を引き継ぐ方法で更新してください。クライアントを更新しても、すべてのサブスクリプションの問題が解決するわけではありません。URLの無効化、アカウント権限、サーバーから返されるエラーは個別に対処が必要です。取得経路、エラーが発生した段階、最終的なインポート結果を記録しておけば、次回は確認済みの段階から調査を続けられます。

速度が遅い：遅延、通信速度、途切れを切り分ける

「速度が遅い」には、ページの初回表示に時間がかかる、継続的なダウンロード速度が低い、接続後しばらくすると頻繁に止まる、という少なくとも3種類の問題があります。遅延テストは特定のリクエストへの応答時間を主に示すもので、大容量データの通信速度やすべてのサイトでの性能を直接示すものではありません。まず「同じページの初回表示は遅いが、再読み込みすると正常」のように、症状を具体的に記録し、その現象を確認できるテストを選びます。

テスト条件を固定して正しく比較する

テストでは端末、ネットワーク、クライアントのルーティング、接続先サービスを固定し、切り替えるのはノード1つだけにします。システム更新、クラウド同期、その他の大容量通信を一時停止し、ローカル回線が使い切られていないことを確認してください。Wi-Fiの電波が弱い、ルーターの負荷が高い、同時接続端末が多いといった状況も、プロキシの速度低下に見えることがあります。直接接続できるサービスも遅い場合は、コアを何度も切り替える前にローカルネットワークを確認します。

各ノードを数回テストし、たまに起こる失敗と継続的な異常を分けて記録してください。接続先サービスが単一接続の速度を制限したり、出口アドレスに応じて異なるコンテンツ配信経路を選んだりすることがあります。同じノードでも、アクセス先によって速度が異なるのは珍しくありません。1つのサイトで1回測定した結果から、すべての通信の性能を推測しないでください。テストするページ、ファイル、動画は、内容や画質をできるだけそろえます。

ノードのテストで遅延が低いのにWebページの読み込みが遅い場合は、ログで名前解決に時間がかかっていないか、同じ接続が大量に繰り返されていないか確認します。ページでは複数のドメインに同時にアクセスすることが多く、メイン文書への応答が速くても、画像、スクリプト、APIが正しい経路を通るとは限りません。ブラウザーの開発者ツールを使えば、名前解決、接続確立、応答待ちの段階を切り分けられます。ただし、リクエストURLに個人情報が含まれる場合があります。

実際の出力経路と端末のリソースを確認する

一時的にプロキシ経由になることが明確なルールを選び、遅いリクエストが不適切な直接接続経路に送られていないか確認します。ルーティングを一時変更して大きく改善した場合は、元のモードに戻して該当ルールを特定してください。プロキシ対象を広げたままにして、問題を覆い隠さないでください。ログインが必要なサービスでは、出口の変更によって追加認証が発生することがあります。結果を比較する際は、認証にかかった時間と通常の通信時間を分けてください。

ダウンロードが継続的に遅い場合は、システムのタスク管理ツールでネットワーク、プロセッサ、メモリの使用率を確認します。省電力端末では、大容量通信、複雑な暗号化、多数の接続によってリソースがボトルネックになることがあります。プロセッサの使用率が高い状態では、遅延の低いノードに切り替えても速度が改善しない場合があります。ログレベルを非常に詳細にすると、ディスク書き込みや画面更新の負荷も増えます。診断後は通常のログ設定に戻してください。

多重化は、どのノードにも使える高速化スイッチではありません。接続の構成方法が変わり、実際の効果はプロトコル、通信方式、サーバーの対応状況、経路の品質によって異なります。サービス提供元が明確に対応を案内している場合に限り、他の設定を変えずに比較テストし、結果を記録してください。多重化、輻輳関連の設定、DNSを同時に変更すると、速度が変わっても原因を特定できません。

断続的な停止はネットワークの変化を確認する

大容量通信を開始してから止まる一方で、小さなページは開ける場合は、パケットロス、接続リセット、経路の違い、サーバー側の制限を確認します。接続できていても、長時間の接続が安定するとは限りません。まず同じノードを別の正常なネットワークでテストし、その後にパスMTUを確認する必要があるか判断します。小さいMTU値をそのまま適用しないでください。一部の接続が復旧する一方で、効率が下がったり別の互換性問題が起きたりする場合があります。

接続してしばらくすると遅くなる場合は、端末の温度、電源モード、Androidのバックグラウンド制限、ネットワーク切り替えの記録も確認します。スリープからの復帰やWi-Fiの再接続後、古い接続が終了を待つ間に新しい接続が正常に動作している場合があります。まずクライアントを再接続して比較してください。長時間接続だけが失敗する場合は、発生時刻とネットワーク切り替えの状況を記録して、さらに原因を絞り込みます。ノード全体を使えないと判断する必要はありません。

複数の端末が同じ時間帯に同じノードを使い、すべて通信速度が低下する一方、別のノードで復旧する場合は、リモート側の負荷や出口経路の問題が考えられます。条件を固定して再現手順をサービス提供元に伝えてください。「速度テストが遅い」だけでは原因を特定しにくいため、接続先サービス、継続時間、直接接続が正常か、低遅延なのに通信速度が低いかを説明すると役立ちます。

DNSの問題：どこで名前解決されるか確認する

DNSの異常は、一部のドメインだけ開けない、初回アクセスに時間がかかる、ルーティングを切り替えると結果が変わる、といった症状として現れます。リクエストによっては、システムのDNS、ブラウザーの暗号化DNS、コア内蔵のDNSを使うか、ドメイン名をリモート側へ渡して処理します。まず、アプリからクライアントへ渡されるのがドメイン名か、すでに解決済みのアドレスかを確認し、該当する名前解決経路を調べます。システムのDNSだけを変えても、ブラウザーやコアが独自に送る問い合わせには反映されない場合があります。

同じドメインで名前解決の段階を確認する

まず、失敗するドメイン名とエラーメッセージを記録します。システムがホスト名を解決できない場合と、名前解決後に接続がタイムアウトする場合では、問題の段階が異なります。次のシステムコマンドで、システムのリゾルバーが応答を返すか確認できます。ただし、プロキシコアが同じ結果を使うことや、接続先サービスに到達できることを証明するものではありません。キャッシュの影響を除くため、設定を変更した後に接続を確立し直し、別のサイトではなく同じドメインで再テストしてください。

nslookup example.com

システムで名前解決に失敗しても、明示的なSOCKSプロキシ経由ならアクセスできる場合、プロキシが別の名前解決経路を使っている可能性があります。前述のコマンドにあるsocks5hでは、curlがドメイン名をSOCKS側へ渡します。socks5では通常、curlがローカルで先に名前解決します。両者を比較に使えますが、ローカルプロキシがドメイン名を受け取った後にどこで名前解決するかは、コアのルーティングとDNS設定によります。

特定のブラウザーだけで問題が起きる場合は、ブラウザー独自のセキュアDNS設定を確認します。ブラウザーがシステムのリゾルバーを使わなかったり、独自の名前解決に失敗してローカルプロキシへリクエストを送らなかったりすることがあります。一時的にシステムの名前解決を使う設定に戻すと切り分けに役立ちますが、テスト後は必要に応じて設定を選び直してください。ブラウザー設定とコアのDNSを同時に変更すると、問題の層を切り分けられなくなります。

コアのDNSとルーティングの関係を確認する

コアのDNS設定には、サーバーアドレスだけでなく、クエリの種類、どの出力経路を使うか、ルーティングの照合時にドメイン名をIPアドレスへ解決するかどうかも関係します。次は項目の階層を示す部分的なJSONです。初期のルーティング判定ではドメイン名を保持し、アドレスルールとの照合を目的とした名前解決は行いません。完全な動作設定ではないため、クライアントが生成した設定ファイル全体と置き換えないでください。

{
  "routing": {
    "domainStrategy": "AsIs"
  }
}

この項目に対応するXrayおよびV2Flyの設定で、AsIsは、すべてのドメイン名が一切解決されないという意味ではありません。実際の接続や他のコンポーネントでアドレスが必要になる場合があります。ドメイン名が一致しなかった後に名前解決する方式を選べば、後続の判定でアドレスルールを利用できる可能性がありますが、DNSへの依存も増えます。まずルーティングの目的を明確にしてから方式を選んでください。DNSエラーを見て、すべての選択肢をむやみに切り替えないでください。

暗号化DNSを使う場合は、DNSサーバー自体のドメイン名をどう解決するか、そのサーバーへの接続を直接接続とプロキシ接続のどちらで行うかも考慮します。プロキシを確立するためにノードのアドレスを先に解決する必要があり、そのDNS問い合わせも未確立のプロキシに依存すると、起動時に循環が発生する可能性があります。起動段階で到達できる名前解決経路を確保し、クライアントの該当設定の説明に従ってください。DNSサーバーをむやみに追加するだけでは解決しません。

IPv6、キャッシュ、FakeDNSを個別に確認する

ネットワークによってはIPv6アドレスが返されても、接続先へのIPv6経路が不完全で、待ち時間の後にフォールバックしたり、断続的にタイムアウトしたりすることがあります。まず端末が安定したIPv6接続を実際に利用できるか確認し、対応する設定でアドレスファミリーの方式を比較します。一時的にIPv4を使う方法は検証に使えますが、すべての問題をIPv6無効化で解決すべきとは限りません。ネットワークが異なれば結果も変わります。

DNS設定を変更した後も、既存の接続、アプリのキャッシュ、システムキャッシュが古いアドレスを使い続ける場合があります。関連するページと接続を閉じ、システムの手順に従ってキャッシュを更新してください。再現条件を見失わないよう、端末全体を何度も再起動しないでください。FakeDNSを使う場合、アプリが受け取る仮想アドレスは対応するコアがドメイン名に戻す必要があります。処理方法を切り替えた後に仮想アドレスが残っているとルーティングできないことがあるため、アプリに再度名前解決させてください。

トラブルシューティングでは、まず単純で動作を説明しやすい名前解決経路に戻し、接続を確認してから複雑な機能を1つずつ追加します。ログではDNSのエラーと最終的な出力経路の両方を確認し、名前解決の成功だけを見て、その後の接続失敗を見落とさないようにしてください。仮想アドレスの仕組みと適用範囲はFakeDNSの仕組みを詳しく解説を、関連用語は用語集を参照してください。

システムプロキシが効かない：プロキシ適用と振り分けを確認

システムプロキシ、コアのルーティング、透過プロキシはそれぞれ異なる層の機能です。システムプロキシは、対応するアプリにリクエストの転送先を伝えます。ルーティングは、コアが受け取ったリクエストの出力先を決めます。透過プロキシは、別の層で通信を取り込みます。そのため、ルーティングをグローバルにしても、システムプロキシを無視するアプリが自動的にクライアントへ接続されるわけではありません。まずリクエストがコアに届いていることを確認してから、適用するルールを調べます。

アドレス、ポート、アプリの動作を確認する

v2rayNでシステムプロキシの自動設定を選んだ後、システムのネットワーク設定を開き、プロキシのアドレスとクライアントの実際の待ち受け先が一致しているか確認します。端末内で使う場合は通常ループバックアドレスを指定しますが、ポートは現在の設定に合わせてください。リモートノードのアドレスをシステムプロキシ欄に入力しないでください。SOCKS専用ポートをHTTPプロキシとして使うこともできません。混合待ち受けを使う場合は、アプリが必要とするプロトコルに対応しているか確認します。

Windowsでは、アプリによって異なるプロキシ設定を参照する場合があり、コマンドラインツールがブラウザーの設定を引き継ぐとも限りません。macOSのプロキシ設定は現在のネットワークサービスに関連付けられるため、有線と無線を切り替えた後は再確認してください。Linuxでは、デスクトップ環境、アプリ独自の設定、端末の環境変数がそれぞれ独立している場合があります。そのため、ブラウザーが使えても、他のプログラムの動作まで保証されるわけではありません。

アプリ独自のHTTPまたはSOCKS設定がある場合は、システムプロキシを上書きしていないか確認します。ブラウザー拡張、開発ツール、ダウンロードツールに古いアドレスが保存されている場合もあります。端末のツールはプロキシ環境変数や除外リストを参照することがあり、除外ルールに一致すると指定したプロキシを通りません。システム設定画面のスイッチだけでなく、該当プロセスがどの設定を参照しているか確認してください。

個別のルールで照合順序と出力先を確認する

リクエストがコアに届いていることを確認したら、適用されたルールを調べます。多くのルールは上から順に照合されるため、前方にある範囲の広いルールが、後方の詳細なルールより先に適用される場合があります。次はルールの一部を示す例です。例のドメインとサブドメインをdirectという出力先へ送ります。完全な設定にその出力先タグが定義されている場合にのみ使用してください。この断片を単独で設定としてインポートしないでください。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      }
    ]
  }
}

ルールの表示名と実際の出力先タグが一致するとは限りません。カスタムルールを変更する前に、生成された設定を確認してください。アプリが先にドメイン名をIPアドレスへ解決すると、インバウンドにはアドレスだけが含まれ、ドメイン名のルールが一致しない場合があります。一部の状況ではトラフィック検出でドメイン名を補えますが、プロトコルや設定の制限があり、すべてのリクエストで元のドメイン名を復元できるとは限りません。ログを見て、ルールの照合に必要な情報が含まれているか確認します。

ルーティングを一時的にグローバルへ切り替えて復旧する場合、元のルール、名前解決結果、デフォルトの出力先に違いがある可能性があります。次に元のモードへ戻し、失敗するドメインだけに限定したルールで比較し、適用後に復旧するか確認してください。すべてのルールを消したり、照合範囲を広げたままにしたりしないでください。本来は直接接続すべきLANサービス、社内ネットワーク、ローカル端末にも影響する可能性があります。

複数のプロキシが設定を上書きしていないか確認する

複数のプロキシアプリを同時に実行すると、システムプロキシ設定やローカルポートを奪い合うことがあります。一方を終了しても、もう一方が自動でプロキシの適用を再開するとは限りません。テストではクライアントを1つだけ起動し、システムプロキシを再適用してから実際のアドレスを確認してください。透過プロキシや仮想ネットワークアダプターを有効にしている場合は、どの層が通信を受け持つか明確にし、リクエストの循環や二重取り込みを避けます。

アプリがシステムプロキシを参照せず、別の方式で通信を取り込む必要があると確認できた場合に限り、クライアントが対応する他のモードを検討してください。権限が必要なモードは、プラットフォームの説明に従って許可します。原因の切り分けをせず、管理者権限で常時実行する方法で代用しないでください。管理対象端末では組織のポリシーがシステムプロキシを設定している場合があります。端末の管理ルールに従い、設定を何度も強制変更しないでください。

復旧確認では、最初に失敗したアプリと、正常に直接接続できるサービスの両方をテストし、クライアント終了後もネットワークが使えることを確認します。LANへのアクセスだけが異常な場合は、除外リスト、待ち受け範囲、ルールの順序を確認してください。すべてのインバウンドインターフェースを開放しないでください。用語が混同しやすい場合は、まずルーティングとDNSの用語を確認し、各設定がどの層に属するかをこの章で照合します。

起動失敗・クラッシュ：画面とコアを切り分ける

起動時の問題は、画面が開かない、画面は正常だがコアが終了する、しばらく動作した後にプログラム全体が終了する、の3つに分けて確認します。それぞれ、実行環境、設定やポート、リソースやシステムイベントに関係する可能性があります。最後に表示された画面とエラー全文を記録し、設定フォルダーをすぐに削除しないでください。画面が動作していても、タスクトレイのアイコンがあるだけではコアの起動成功を示しません。

インストール元とシステムアーキテクチャを確認する

まずクライアントのダウンロードページに戻り、プラットフォームとプロセッサアーキテクチャに合ったものを選んだか確認します。Windowsのデスクトップ版と従来のWPF版では、画面や実行環境が異なる場合があります。必要条件は該当するダウンロード項目の説明に従ってください。macOSではApple SiliconとIntelを区別します。Linuxではプロセッサアーキテクチャとディストリビューションのパッケージ形式の両方を確認してください。拡張子が似ているだけでインストールを試さないでください。

システムがランタイムコンポーネントの不足を報告した場合は、エラーが指すコンポーネントと使用中のクライアント系列を特定します。不明な配布元から動的リンクライブラリをコピーしないでください。LinuxのGUIアプリはデスクトップセッションと対応するグラフィック環境にも依存します。コマンドラインだけの環境で画面が表示されなくても、コアのネットワーク機能の障害とは限りません。インストーラーの権限やシステムのセキュリティ警告は、システムが案内する手順で対処し、保護機能全体を無効にしないでください。

アップグレード後に問題が発生した場合は、まず古いインスタンスを完全に終了し、バックグラウンドにプロセスが残っていないことを確認してから新しいプログラムを起動します。複数のインスタンスが設定ファイルや待ち受けポートを奪い合う場合があります。元の設定をバックアップし、独立したテスト用ディレクトリか、クライアントが対応する新しい設定方法で動作を確認してください。旧プログラムのディレクトリにあるコアを新しい画面とむやみに組み合わせると、原因を特定しにくい互換性問題が発生します。

待ち受けポートが使用中か確認する

ログにアドレスが使用中、またはバインドできないと表示された場合は、まずそのポートを使用しているプロセスを調べます。次は10808を使った確認例ですが、すべてのバージョンの標準ポートという意味ではありません。WindowsではPowerShellでコマンドを実行します。macOSとLinuxでは、ツールがインストールされているかどうかによって利用できる方法が異なります。検索結果がない場合も、その時点で該当する待ち受けが見つからなかったことを示すだけです。コアを再起動してログを確認してください。

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

# macOS
lsof -nP -iTCP:10808 -sTCP:LISTEN

# Linux
ss -ltnp 'sport = :10808'

プロセスIDを取得したら、まずシステムのプロセス管理ツールでプログラム名とパスを確認してください。見覚えのないプロセスをすぐに終了しないでください。古いクライアントのプロセスなら正常に終了してから再試行します。引き続き必要な別のサービスがポートを使用している場合は、クライアントの設定で未使用のポートに変更します。変更後はシステムプロキシとアプリ独自のプロキシ設定も更新してください。コアが起動しても、リクエストが古いアドレスへ送られる場合があります。

ログに設定の解析失敗が表示された場合は、最初に出た構文または項目のエラーから確認します。カスタムJSONでは、余分なカンマ、引用符の誤り、項目の階層の不整合、存在しない出力先タグなどがよくある原因です。まず直前に加えた変更を取り消し、設定を再生成してください。複数箇所を推測で一度に修正しないでください。また、ログ末尾の終了メッセージを根本原因と判断しないでください。本当のエラーは、その前に出ていることがよくあります。

動作中の終了やリソースの問題を調べる

しばらく動作してからクラッシュする場合は、発生前にサブスクリプションを更新したか、ネットワークを切り替えたか、システムをスリープから復帰させたか、詳細ログを有効にしたかを記録します。ディスクの空き容量、メモリ負荷、設定フォルダーへの書き込み権限も確認してください。同期ソフトによる設定ファイルの同時書き換え、フォルダー権限の変更、ディスク書き込みの失敗なども異常の原因になります。複数のプログラムが同時に変更する場所に、使用中の設定を置かないでください。

画面が終了してもコアが残っている場合は、まず関連するインスタンスを正常に終了し、古い待ち受け先を参照しているシステムプロキシ設定を解除します。デスクトップのショートカットを削除しただけでは、バックグラウンドのプロセスは終了しません。システムにクラッシュイベントの記録機能がある場合は、障害時刻から該当するイベントを検索し、異常モジュールとエラーの種類を記録します。記録を共有する前に、ユーザー名、個人用パス、ノード設定が含まれる可能性のあるコマンドラインを隠してください。

クリーンなテスト設定では正常に起動し、古い設定に戻すと必ず問題が起きる場合は、サブスクリプショングループ、カスタムルーティング、DNS、その他の追加設定を分けて復元します。これにより、古い設定をすべて戻すのではなく、問題を引き起こす条件を特定できます。ポート競合の具体的な対処は、競合プロセスを特定して待ち受けポートを変更するを参照してください。

Androidのトラブル：権限、バックグラウンド、アプリ別設定

Androidのv2rayNGとv2flyNGは通常、VpnServiceを使ってアプリの通信を取り込みます。システムの接続許可、バックグラウンドの制限、アプリ別ルールによって実際の動作が変わります。接続ボタンが実行中に変わっても、起動処理が該当段階まで進んだことを示すだけです。システムの接続表示、通知、クライアントログも確認してください。起動直後に失敗するのか、画面ロック後に切断されるのか、一部のアプリだけ使えないのかを切り分けます。

VpnServiceの許可と接続中のアプリを確認する

初回接続時、システムからVPN接続の許可を求められたら、現在使用しているクライアントが許可対象であることを確認します。ダイアログが表示されない、またはすぐに戻る場合は、他のシステム画面に隠れていないか、端末管理ポリシーで接続が制限されていないか確認してください。起動ボタンを何度もすばやく押さないでください。許可、停止、再起動の処理が交錯し、ログと動作を対応付けにくくなります。

通常、同じシステムユーザーでVPN接続を担当できるアプリは1つだけです。同じAPIを使う他のネットワークツールが、現在の接続を置き換えることがあります。反対に、v2rayNGを起動すると別の接続が停止する場合もあります。確認時は他の同種ツールを停止してから対象のクライアントを起動し、システムに表示される接続元を確認してください。ノードの比較テストのためにv2rayNGとv2flyNGを同時に実行しないでください。個別にテストします。

「常時接続VPN」や「VPNを経由しない接続をブロック」が有効な場合、クライアントを停止しても直接接続できないことがあります。これはサブスクリプションの破損ではなく、システムのポリシーが通信を制限している状態です。システムのVPN設定で現在のアプリと関連オプションを確認し、必要に応じて変更してください。仕事用プロファイルと個人用プロファイルで管理ルールが異なる場合があります。問題が発生しているプロファイル内で確認します。

画面ロック後の切断は電源とデータの制限を確認する

画面を表示している間は使えても、しばらくロックすると失敗する場合は、クライアントのプロセスが残っているか、通知が消えていないか、ログが途切れていないか確認します。システムの省電力機能がバックグラウンド通信を制限したり、プロセスを終了したりすることがあります。クライアントのバックグラウンド動作を許可するか、適切なバッテリー設定を選び、端末メーカー独自の自動起動やバックグラウンド管理項目も確認してください。設定画面の名称はシステムごとに異なるため、現在の端末の表示に従います。

バックグラウンド動作を許可しても、すべてのネットワーク条件で通信できるとは限りません。バックグラウンドデータとデータセーバーの設定も確認してください。Wi-Fiでは正常でモバイルネットワークでは失敗する場合、クライアントと対象アプリの両方で該当ネットワークの利用が許可されているか確認します。変更後に再接続し、同じ時間だけ画面をロックして、同じアプリで再テストします。ロック解除後に復旧しても、バックグラウンドの問題が解決したとは限りません。アプリが前面に戻ったときに初めて接続し直す場合があります。

通知が残っているのにネットワークが切り替わった場合、古い接続が適切に復旧していない可能性があります。Wi-Fiとモバイルネットワークを切り替えた時刻を記録し、接続を停止して再起動し、結果を比較します。再接続ですぐに復旧する場合は、DNSを何度も変更するのではなく、ネットワーク切り替え後の復旧処理を確認してください。深い省電力状態、電波の一時的な途切れ、アクセスポイントの切り替えは、既存の長時間接続に影響することがあります。

アプリ別リストの設定内容を確認する

アプリ別プロキシを有効にしたら、現在のモードが「選択したアプリだけをプロキシ経由にする」のか、「選択したアプリをプロキシから除外する」のかを確認します。同じチェックリストでもモードが逆なら結果も反対になるため、チェックの有無だけでは判断できません。設定後はクライアントを再接続し、対象アプリを完全に終了してから開き直します。新しくインストールしたアプリが対象に自動追加されるかどうかも、選択したモードによって異なります。

アプリによっては、システムコンポーネント、ダウンロードサービス、独立したログインプロセスを呼び出します。実際の通信が、表示中のアプリだけから行われるとは限りません。確認のためにアプリ別の制限を一時的に無効にし、通信全体を取り込む設定で正常に動作するか試します。復旧した場合は対象を少しずつ絞ってください。メイン画面が開くだけで、すべての機能が正常だと判断しないでください。ログイン、添付ファイルのダウンロード、メディア再生では通信経路が異なる場合があります。

v2rayNGからv2flyNGへ切り替える場合は、システムの許可、アプリ別設定、プロトコルの互換性を改めて確認します。両者はXrayとV2Flyという異なるコア系列を使用するため、すべての拡張設定が共通とは限りません。ノードの要件に合ったクライアントを選び、対応が明確な項目を1つ使って接続を確認してから、カスタム設定を戻してください。インストール元とアーキテクチャの選択についてはAndroidクライアントのダウンロードを参照してください。