v2rayNのトラブル対処ガイド：サブスクリプション・DNS・システムプロキシ・接続診断

インターネットに接続できない：通信が止まっている箇所を特定する

「インターネットに接続できない」原因は、ローカルネットワークの切断、アプリがプロキシを経由していない、コアの起動失敗、リモート接続の不具合などさまざまです。まず、すべてのアプリで失敗するのか、ブラウザーだけなのか、すべてのサイトか特定のドメインだけなのか、影響範囲を確認します。範囲によって確認箇所は異なります。サブスクリプションの更新、コアの切り替え、TUNの有効化を同時に行うと、復旧しても原因を特定できません。

プロキシを使わない状態に戻して基準を確認する

v2rayNで「システムプロキシをクリア」を選び、「Tunモードを有効にする」をオフにします。OSのネットワーク設定に手動プロキシが残っていないことも確認してください。他のプロキシツールを終了し、ブラウザーを開き直して、通常はプロキシなしでアクセスできるサイトを表示します。それでも開けない場合は、まずWi-Fiや有線接続、ゲートウェイ、ネットワークのログインページを確認しましょう。この段階ではクライアントが原因とは限りません。公衆ネットワークではWeb認証が必要な場合があり、プロキシ設定が認証ページへのアクセスを妨げることもあります。

プロキシなしで接続できたら、クライアントを起動し、TUNはオフのままシステムプロキシだけを使ってテストします。クライアント終了後に全アプリがインターネットへ接続できなくなる場合は、停止済みのローカル待ち受けポートを指すプロキシ設定が残っていないか確認してください。プロキシをクリアしたらアプリを開き直し、古い接続が再利用されないようにします。ブラウザーにキャッシュ済みページが表示されても、接続が復旧した証拠にはなりません。実際にネットワーク通信が必要なページを再読み込みしてください。

有効な設定とローカル待ち受けを確認する

設定一覧に利用可能な項目があり、テストする設定が選択されていることを確認します。サブスクリプショングループがあっても、ノードが含まれているとは限りません。アドレスを追加しただけでは更新も完了していません。次にログを確認し、コアが起動直後に終了していないか確認します。設定の解析エラー、ポートのバインド失敗、リソースファイルの読み込み失敗がある場合は、まずローカルの起動問題を解決してください。リモートノードを繰り返し切り替えても、これらのエラーは解消しません。

クライアントの基本設定を開き、実際の待ち受けアドレス、ポート、プロトコルを控えます。アプリ側のプロキシポートはここに表示される値と一致させてください。チュートリアルの例から推測して設定しないでください。ループバックアドレスでの待ち受けは自分の端末だけで利用する設定で、正常な動作です。ログにアドレスの使用中と表示されたら、競合するプログラムを特定するか、待ち受けポートを変更してアプリ側の設定も合わせます。片方だけを変更しないでください。

最小限の経路で入口と出口を切り分ける

まずブラウザー1つ、テスト先1つ、有効な設定1つに絞ります。システムプロキシを「システムプロキシを自動設定」にし、ブラウザーのプロキシを切り替える拡張機能は一時的に無効にします。クライアントのログにテスト先へのリクエストが記録されていれば、少なくとも通信はローカルの入口まで届いています。次にルーティングの適用先とリモート側のエラーを確認しましょう。リクエストがまったく記録されない場合は、ブラウザー独自の設定、システムプロキシの反映、アプリがプロキシを迂回していないかを優先して調べます。

失敗したリクエストが最終的に直結とプロキシのどちらへ向かったかも確認します。テスト対象のドメインがルールによって直結に振り分けられている場合、その失敗だけではプロキシノードが使えないとは判断できません。クライアントに明確なプロキシ経由のテスト方法があれば、一時的に利用し、完了後は元のルーティングに戻してください。テストのために全通信を恒久的にプロキシ経由にしたり、既存ルールを削除したりしないでください。元に戻せる状態にしておけば、LANや社内リソース、他のアプリへの影響を防げます。

結果に応じて次の章へ進む

ローカルの入口は正常でもリモートとのハンドシェイクに失敗する場合は、ノードがタイムアウトするの章へ進みます。ドメインだけ失敗し、ほかの接続先が正常な場合は、DNSの問題の章を確認してください。ブラウザーは正常でターミナルだけ失敗する場合は、システムプロキシの章へ進みます。変更のたびに同じ接続先で再テストし、エラー表示に変化があったか記録しましょう。「接続拒否」から「ハンドシェイク失敗」に変わったなら、問題の発生箇所が移っています。単に「まだ使えない」とまとめないでください。

ノードがタイムアウトする：接続・ハンドシェイク・応答を切り分ける

タイムアウトは、処理が制限時間内に完了しなかったことを示すだけで、サーバーの停止を直接意味するものではありません。接続の確立、プロトコルのハンドシェイク、名前解決、対象ページの応答のいずれでも発生します。まずログを開き、テスト時刻に近い最初のエラーを探してください。最後の行だけを見るのではなく、先に記録された名前解決の失敗や接続拒否を確認します。後続のタイムアウトが連続するより、最初のエラーのほうが原因特定に役立つことがあります。テスト中はほかのネットワーク操作を控え、対象のリクエストをログで判別しやすくしましょう。

何を測定しているテストか確認する

TCP接続テストで分かるのは、指定したアドレスとポートに接続できるかどうかです。認証情報、通信経路、接続先サイトまでは検証できません。実際のリクエストを使うテストは利用状況に近い一方、テスト先、DNS、ルーティングの影響も受けます。テストで結果が返らなくても、すぐに設定を削除しないでください。まずブラウザーで既知の接続先を開き、同じリクエストがクライアントのログに記録されているか確認します。

一覧にあるすべての設定で同時に失敗する場合は、ローカルネットワーク、システム時刻、サブスクリプションの設定、テスト先など、共通する要因を調べます。1つだけ失敗する場合は、同じサブスクリプション内のほかの設定と比較してください。比較時はネットワークとテスト方法をそろえ、異なる時刻や接続先で得た結果を混ぜないようにします。大量の同時テストは接続制限にかかることもあるため、診断では1つずつ試すほうが結果を解釈しやすくなります。

ログに記録された段階ごとに対処する

「接続が拒否されました」は、接続先のアドレスには到達できるものの、対象ポートが接続を受け付けていない、または途中の機器が明示的に拒否している状態を示すことが多いです。まずアドレスとポートを確認し、サービス提供元に稼働状況を問い合わせてください。「ネットワークに到達できません」は、ローカルルーティング、アドレスファミリー、ネットワーク出口が原因の可能性があります。「タイムアウト」の場合は、接続確立前かハンドシェイク後かをさらに切り分けます。エラーメッセージはコアによって異なるため、前後のログと合わせて判断してください。

証明書、サーバー名、ハンドシェイクに関するエラーが出た場合は、トランスポートのセキュリティ設定、サーバー名、トランスポート種別、パスを確認します。設定によっては接続先アドレスとサーバー名が異なるため、一致させようとして書き換えないでください。REALITYを使う設定では、公開鍵、ショートID、フィンガープリントが正しくすべて入力されているかも確認します。項目を一つずつ推測して変更するより、サービス提供元から受け取った元のリンクを再インポートするほうが安全です。

時刻・アドレスファミリー・ネットワークの違いを確認する

OSの日付と時刻を自動設定にし、実際の時刻が正しいことを確認します。時刻のずれは、証明書の有効期間判定や一部プロトコルの認証に影響します。時刻を直さずタイムゾーンだけ変更しても解決しません。スリープから復帰した直後なら、ネットワークと時刻の同期を待ってからクライアントを再起動してテストしてください。時刻や名前の誤りを隠すために証明書検証を無効にしないでください。接続のセキュリティが低下します。

ノードのドメインからIPv4とIPv6の両方のアドレスが返されることがあります。端末にIPv6アドレスがあるからといって、リモートまでのIPv6経路が使えるとは限りません。逆に、IPv6が必ず原因だと決めつけることもできません。クライアントが対応しているアドレス選択設定で一方のアドレスファミリーを一時的に制限し、ほかの条件を変えずに比較します。テスト後は元に戻してください。利用が許可されている別のネットワークで試す方法も有効です。ネットワークによって結果が変わるなら、設定をすべて作り直すのではなく、出口ルートを調べましょう。

設定を保持し、提供元に状況を伝える

サブスクリプションを更新して再テストし、サービス提供元がアドレス、ポート、トランスポート設定を変更していないか確認します。同じ設定が別のネットワークでも失敗し続ける場合は、ノード名、テスト時刻、エラーの発生段階、個人情報を伏せたログを添えて、サーバーの稼働状況を問い合わせてください。認証情報を公開したり、別の設定のパスワードや識別情報を組み合わせて試したりしないでください。クライアントでコアを選択できても、どのコアでも同じ拡張設定を解釈できるとは限りません。

ノードが復旧したら、接続テストだけでなく、もともと失敗していた実際の通信も確認します。ハンドシェイクは成功しても特定のサイトだけタイムアウトする場合は、そのサイトのルーティング、名前解決、接続先側の制限を調べてください。プロトコル項目の意味は用語集で確認できます。VMessとVLESSの違いはプロトコルの違いをご覧ください。各項目の役割を理解してから変更すると、選択肢を何度も切り替えるより安定した結果につながります。

サブスクリプションの更新に失敗する：URL・取得・解析を切り分ける

サブスクリプションの更新は、クライアントからURLへのリクエスト、サーバーからの本文の返却、本文から設定一覧への変換という3段階で行われます。どの段階で失敗しても「更新に失敗しました」と表示されることがありますが、対処方法は異なります。まずリクエストが完了していないのか、取得には成功したものの設定として認識されなかったのかを確認してください。グループ名だけで更新の成否を判断せず、現在利用できる設定を消してから再インポートすることも避けましょう。

URLを保存してから更新する

「サブスクリプショングループ設定」でURLがすべて保存されていることを確認し、「すべてのサブスクリプションを更新」を実行します。グループを追加しただけではノードは取得されません。コピー時に前後の空白、改行、チャットアプリが付けた句読点が混ざっていないか確認してください。クエリパラメーターを含むURLは途中で切らないよう注意が必要です。例のURL https://example.com/sub?token=xxxx は書式を示すものです。実際にはサービス提供元から発行された専用URLを使用してください。

サブスクリプションURLと個別ノードの共有リンクは別のものです。通常のWebページのURLや、ログイン後の管理画面のURLがサブスクリプション用とは限りません。ページの見た目から判断せず、サービス提供元がサブスクリプション用として案内する入口からコピーしてください。URLがリセットされている場合、古いリンクはアクセス拒否や空の内容を返すことがあります。その場合はクライアントの解析設定を繰り返し変えるのではなく、新しいURLに差し替えてください。

リクエストの失敗と取得内容の異常を見分ける

更新ログに記録されたステータスとエラーを確認します。名前解決に失敗する場合はDNS、接続タイムアウトの場合は現在のネットワークからサブスクリプションサービスまでの経路を調べます。証明書エラーが出たら、システム時刻とサービスのドメインを確認してください。アクセス拒否の場合は、サブスクリプションの利用資格、URLの期限、アクセス制限を確認します。サーバーが混雑しているときに更新を連打すると、レート制限が強まる可能性があります。時間を置いて再試行し、最初に表示されたエラーも記録しておきましょう。

リクエストに成功しても、設定が返ってくるとは限りません。APIがログインページ、メンテナンスのお知らせ、ネットワーク認証ページを返すと、クライアントは設定として解析できません。応答内容を確認する場合は、自分の管理下にある端末で操作し、URL全体を公開記録に残さないでください。ブラウザーでページが開けても、確認できるのはブラウザーがコンテンツを取得したことだけです。プロキシ、ログイン状態、DNSがクライアントと異なる場合があるため、クライアントの通信経路も同じとは限りません。

更新に使う通信経路を選ぶ

プロキシなしでサブスクリプションサービスへアクセスできる場合は、まず直接接続で更新して、依存関係を減らします。直接接続できず、クライアントに利用可能な設定が残っている場合は、画面にあるプロキシ経由の更新機能を使えます。メニューはバージョンによって異なるため、実際の設定を確認してください。既存の設定がすべて使えないと、プロキシ経由の更新は「更新するには接続が必要だが、接続には更新が必要」という依存関係になります。その場合は、新しく有効なURLか個別ノードの設定を入手してください。

更新前に使用する経路を記録し、更新後にログを確認します。システムプロキシを有効にすれば、クライアント自身のサブスクリプション取得も必ずプロキシ経由になるとは限りません。更新モジュールが独自の通信経路を使うことがあります。アクセスできないURLを、身元不明のオンライン変換サービスに渡すのも避けてください。サブスクリプションにはアクセス用の認証情報が含まれることがあり、変換サービスから内容を見られる可能性があります。形式を変換する必要がある場合は、送信先、処理方法、認証情報が露出する範囲を確認しましょう。

形式の互換性と更新後の一覧の変化を確認する

本文が空ではないのに有効な設定が見つからないと表示される場合は、サービス提供元が現在のクライアントに対応した形式を提供しているか確認します。クライアントとコアの役割は異なります。クライアントがサブスクリプションを解析し、コアが生成された設定を実行します。コアを切り替えても、通常はサブスクリプション形式の認識問題は解決しません。ダウンロードページからOSに合ったクライアントを選び、現在の利用環境を上書きせず、バックアップした設定で別途テストできます。

更新後に項目が減った場合は、提供元が設定を削除したか、グループのフィルターで一部が非表示になっている可能性があります。まず一覧のフィルターを解除し、そのサブスクリプショングループの更新結果を確認してください。新しい項目が使えることを確認してから、古い項目を整理します。原因調査のために記録を残す場合も、プロトコル種別や個人情報を伏せたエラーなど必要最小限にしてください。認証情報を含む項目を保存・転送しないでください。

速度が遅い：転送速度・応答時間・アプリごとの差を分けて測る

Webページの表示、動画のバッファリング、大容量ファイルのダウンロードが遅いからといって、すべて同じ原因とは限りません。Webページは名前解決やハンドシェイク、複数リソースの取得に左右されます。連続ダウンロードはスループットや輻輳の影響が大きく、リアルタイム通信ではジッターやパケットロスも重要です。まず「何が遅いのか」を具体的にしてから、適切な方法でテストします。一覧に表示される応答時間は特定の条件で測定した結果にすぎず、すべての用途での速度順位やサービス品質全体を示すものではありません。

条件をそろえて比較する

安定した接続先を1つ選び、同じ端末・同じネットワーク・近い時刻で、プロキシなしとプロキシ経由を比較します。OSの更新、クラウド同期、ほかの大容量通信を一時停止し、バックグラウンド通信で上り帯域を使い切らないようにします。Wi-Fiでは電波強度、周波数帯、ルーターの負荷も確認してください。ルーターの近くにいても、無線環境に干渉がないとは限りません。可能であれば有線接続とも比較し、まず端末からネットワークまでの変動を切り分けます。

一度に比較する設定は2つまでにし、ルーティングとDNSの条件をそろえます。複数の速度測定ツールを同時に動かしたり、1回の極端な結果だけで結論を出したりしないでください。測定では実際に通信量が発生するため、従量制のサービスではテスト量を抑えましょう。特定の時間帯だけ全体的に遅く、別の時間には回復する場合、繰り返し再インストールするより時間帯ごとの記録が役立ちます。ネットワークの混雑やサーバー側の負荷をさらに調べる手がかりになります。

実際の出口と接続先の状態を確認する

遅いリクエストが想定したプロキシを通っているか、まず確認します。ルーティングルールによって、ページ本体とリソースのドメインが別の出口に振り分けられ、本文は表示されても画像の読み込みが止まることがあります。ログから失敗したドメインを特定し、同じリクエストが繰り返されていないか、特定のリソースだけが常に直接接続になっていないか確認します。ページが最終的に表示されてもタイムアウトを無視しないでください。ブラウザーは複数のリソースを待ってから読み込みを完了することがあります。

特定のサイトだけ遅い場合は、サイト側、コンテンツ配信サーバー、アカウントの制限も考えられます。プロキシの出口を変えると接続先サーバーが変わることがありますが、必ず改善するとは限りません。通常のページは速く、特定のダウンロード元だけ遅い場合は、まず別の正規ダウンロード元や同じサイトの別ファイルと比較します。接続先で速度制限されている問題は、ローカルの待ち受けポートを変えても解決しません。クライアントの設定で実際の回線帯域を超えることもできません。

接続の多重化・UDP・通信経路の問題を見分ける

多重化は接続の構成方法を変える機能であり、数を増やせば必ず速くなるわけではありません。サーバーとの互換性、パケットロス、アプリの種類によって結果は異なります。診断時は既定値またはサービス提供元の推奨設定を使い、多重化が原因と考えられる場合にだけ、一度無効にして比較してください。別のコアのパラメーターをそのまま流用しないでください。同じ名称でも実装や対応フィールドが異なり、誤った設定でコアが起動しなくなることがあります。

ブラウザーがUDPベースの通信を試みる一方、現在の経路ではUDPとTCPで扱いが異なる場合があります。特定のアプリだけに問題があるなら、アプリが対応する範囲で一時的に通信方式を切り替えて確認してください。システム全体のUDPをすぐに無効にしないでください。TUNを有効にすると大容量ファイルのダウンロードが止まり、通常のページは表示される場合、経路上のMTUが関係することもあります。ネットワーク環境を踏まえてテストし、どの端末にも同じ固定値を適用しないでください。

再現できる結果をもとに調整する

同時接続数を減らすと安定する場合は、接続制限や輻輳を調べます。最初のリクエストだけ遅く、次から速い場合はDNSや初回ハンドシェイクを確認してください。ロック画面やスリープからの復帰後に遅くなる場合は、ネットワークアダプターの状態やクライアントの再接続を確認します。現象ごとに調べる方向は異なります。接続先、時刻、出口、通信方式、結果を簡単に記録しておくと、速度測定のスクリーンショット1枚を保存するより役立ちます。

症状	優先して確認する項目	比較方法
最初の表示が遅い	名前解決とハンドシェイク	同じ接続先への連続リクエスト
ダウンロード中に速度が変動する	輻輳とバックグラウンド通信	ほかの通信を停止して再テスト
特定のアプリだけ遅い	アプリ独自のプロキシ設定と通信方式	アプリの設定とリクエストログを確認

効果を確認できた変更だけ残し、それ以外は元に戻してください。ネットワーク最適化に万能な設定一式はありません。一度に多くの項目を変えると、比較の基準が失われます。名前解決の経路を詳しく調べる場合は、次の章をご覧ください。

DNSの問題：どこで名前解決し、どの経路を通るか確認する

DNSはドメイン名をIPアドレスに変換しますが、プロキシ利用時に名前解決の入口が1つとは限りません。OS、ブラウザー、クライアントのコア、リモートプロキシがそれぞれ関与することがあります。ページに「ドメインが見つかりません」と表示されても、どこかの段階で利用可能な結果を得られなかったことしか分かりません。まずノードサーバーのドメインを解決できないのか、接続先サイトのドメインを解決できないのかを切り分けます。前者はプロキシの確立を妨げますが、後者は通常プロキシの動作開始後に発生します。対処方法は異なります。

システムの名前解決とプロキシ側の名前解決を比較する

Windowsのターミナルでは、次のシステムコマンドで対象ドメインが応答するか確認できます。例のドメインは操作方法を示すものです。実際にエラーが出ているドメインに置き換えてください。応答したサーバー、アドレスファミリー、エラーメッセージを記録します。アドレスが1行表示されただけで、名前解決の経路が正しいと判断しないでください。リゾルバーによって異なるコンテンツ配信先のアドレスが返ることがあります。

nslookup example.com

システムの問い合わせが成功しても、コアのリモートDNSが正常とは限りません。システム側で失敗しても、プロキシが必ず使えないわけではありません。リクエストによってはドメイン名をリモート側に渡して処理します。次にクライアントログのDNSリクエストと、最終的に接続したアドレスを確認してください。ブラウザーで独自のセキュアDNSを有効にしている場合は、その状態も記録します。切り分けの間は、どの経路で名前解決するかを明確にして比較し、完了後にブラウザーの元の設定に戻すか判断しましょう。

名前解決の依存関係が循環しないようにする

暗号化DNSを使う場合、リゾルバー自身のドメインを解決して接続を確立してから、問い合わせを送信することがあります。このリゾルバーへの接続にプロキシが必要で、プロキシサーバーのドメイン解決も同じリゾルバーに依存すると、起動時に依存関係の循環が発生します。プロキシ接続の確立前に必要な問い合わせを完了できるよう、ノードのドメインを解決するための初期経路を明確にしてください。コアによって設定名や構造は異なるため、フィールドを混在させないでください。

クライアントのローカルDNS、リモートDNS、ルーティング設定の組み合わせを確認します。直接接続する接続先を到達できないリゾルバーに問い合わせたり、プロキシ経由の接続先に現在のネットワークと合わないシステム応答を使ったりすると、問題が発生することがあります。変更後は接続を確立し直してテストし、古いキャッシュに判断を左右されないようにします。ブラウザーのキャッシュを消しても、すべての層のDNS結果が消えるわけではありません。必要に応じてクライアントと関連アプリを再起動してください。

TUNの通信取り込みとLAN内の名前解決を理解する

TUNはより多くの通信を取り込めますが、すべての名前解決リクエストが自動的に同じポリシーに従うわけではありません。DNSハイジャック、仮想ネットワークアダプター、アプリの除外設定、ルーティングルールが有効か確認します。アプリが独自の暗号化DNSを使う場合、通常のDNSハイジャックでは処理できないことがあります。TUNのスイッチがオンかどうかだけでなく、リクエストがコアに届いているか、どのリゾルバーが使われたかをログで確認してください。

プリンター、ファイルサーバー、社内LANでは、ローカルDNSや特定の検索ドメインが必要な場合があります。すべての問い合わせを外部リゾルバーへ強制的に送ると、これらの名前を解決できなくなることがあります。LANや組織内部のドメインには必要な名前解決経路を残し、ネットワーク管理者の設定に従ってください。プライベートアドレスへの直接接続ルールを設定するだけでは不十分です。内部ドメインがDNSの段階で解決できなければ、その後のIPアドレスに基づくルーティングまでリクエストが進みません。

名前解決の正確さとプライバシーの境界を別々に確認する

Webページを正常に開けることと、名前解決が想定どおり行われることは別の確認項目です。オンライン検査ページに表示されるのは、そのページが発生させた一部の問い合わせだけで、端末上のすべてのアプリを反映するわけではありません。リゾルバー運営者の所在地も、実際のネットワーク出口と同じとは限りません。ブラウザー設定、コアのログ、アプリの動作を合わせて判断し、検査ページに表示された地域ラベルだけで情報漏えいや修復の成否を決めつけないでください。

修復後は、通常のドメイン、問題が起きていたドメイン、維持する必要があるLAN内の名前をテストし、IPv4とIPv6で結果が異ならないか確認します。変更前後のリゾルバーと出口を記録し、次回ネットワークを切り替えても再現できるようにしてください。詳しい手順はDNSリークの検査と設定方法をご覧ください。掲載されている設定項目は、使用中のコアや画面に合わせて選んでください。

システムプロキシが効かない：ブラウザーとターミナルを分けて調べる

システムプロキシは、アプリが参照するネットワーク設定の一つであり、すべての通信を強制的に転送するものではありません。アプリによって設定に従うもの、独自のプロキシを使うもの、直接接続するものがあります。そのため、ブラウザーでは使えてターミナルでは使えない場合も起こり得ます。まず問題が起きているアプリがどのプロキシ方式を使うか確認し、入口のアドレスとポートを調べてください。アプリのリクエストがクライアントに届いてから、ルーティングやノードの設定が影響します。

3種類のシステムプロキシモードを確認する

「システムプロキシを自動設定」は、クライアントの設定に従ってシステムプロキシを構成します。「システムプロキシをクリア」は、該当するプロキシ設定を削除します。「システムプロキシを変更しない」は、現在の状態をクライアントから変更しないという意味で、クリアとは異なります。別のプログラムが設定したプロキシが残っている場合、「変更しない」を選ぶとその設定が維持されることがあります。クライアントのメニューだけで判断せず、OSのネットワーク設定を開いて実際の値を確認してください。

設定後、テストするアプリを開き直してください。起動時にしかプロキシ設定を読み込まないアプリもあります。画面上では切り替わっているのにシステム側の値が変わらない場合は、権限、組織のポリシー、他のプロキシプログラムによる上書きを確認します。管理対象の端末では組織のルールに従い、ポリシーを無理に変更しないでください。複数のクライアントにシステムプロキシを常時変更させると、設定が不規則に切り替わり、接続に失敗することがあります。

ブラウザー独自の設定と拡張機能を調べる

ブラウザーのプロキシを切り替える拡張機能を無効にし、ブラウザー独自のネットワーク設定も確認します。ブラウザーによってはシステムプロキシを使うほか、別のプロキシを手動で指定できます。古いPAC URL、手動プロキシ、迂回リストが通信経路を変えていることもあります。プライベートブラウジングだけで確認するより、新しいブラウザープロファイルで試すほうが確実です。プライベートウィンドウでも一部の拡張機能やポリシーが有効な場合があります。

「ローカルアドレスにはプロキシを使用しない」などの迂回ルールがあると、一部の接続先は直接接続されます。LAN内のリソースへのアクセスでは正常な動作の場合があり、ログに記録されないからといってシステムプロキシの故障とは限りません。プロキシの入口をテストする際は、迂回リストに含まれない接続先を選んでください。ブラウザー独自のDNS設定も記録します。同じプロキシ設定でも名前解決の結果が変わることがあります。

ターミナルで正しいプロキシプロトコルを明示する

コマンドラインツールによって、システムプロキシへの対応は異なります。プロキシを明示するパラメーターを使って一度だけテストできます。以下はローカルのHTTP待ち受けが実際に 127.0.0.1:10809 に設定されている場合の例です。実行前に、クライアントに表示されるHTTPまたは混合待ち受けの実際のポートに変更してください。このポートはテスト例であり、既定値を示すものではありません。Windows PowerShellでは curl.exe を使うと、対象のプログラムを明示して実行できます。

curl --proxy http://127.0.0.1:10809 --head https://example.com

SOCKSの入口を使う場合は、ツールが対応するSOCKSプロキシ用のパラメーターを選んでください。通常、socks5h はドメイン名の解決をプロキシ側に任せますが、socks5 のローカル名前解決の挙動はツールのドキュメントで確認してください。HTTPプロキシのアドレスを、SOCKS専用の項目に入力してはいけません。また、http_proxy、https_proxy、ALL_PROXY、NO_PROXY に古い値が残っていないか確認します。

TUNとLAN共有の適用範囲を明確にする

プロキシ設定を参照しないアプリでTUNを試す場合は、影響を理解したうえで行ってください。デスクトップでは通常、管理者権限などの許可が必要です。仮想ネットワークアダプターとデフォルトルートも確認します。ルートの競合を避けるため、ほかのVPNや通信を取り込む機能は一時的に停止してください。ただし、組織で維持が必要な接続は勝手に切断しないでください。TUNでは誤ったノード設定を修正できません。また、システムプロキシが効かない場合に必ず有効な代替手段でもありません。

スマートフォンからPC経由でプロキシを共有する場合、スマートフォン自身のループバックアドレスは指定できません。PC側でLANからの接続を許可し、スマートフォンにはPCのプライベートIPアドレスと正しいポートを入力します。ファイアウォールでは、必要な信頼できるネットワークだけに接続を許可してください。詳しい手順はLANでプロキシを共有する方法をご覧ください。ブラウザーとターミナルの比較手順はシステムプロキシが効かない場合のトラブル対処で説明しています。修復後は、テスト用に追加した永続環境変数を削除してください。

クライアントがクラッシュする：画面の終了とコアの停止を区別する

ウィンドウが消えた、プロセスが終了した、コアが停止したという状態はそれぞれ異なります。まずタスクトレイとOSのプロセス一覧を確認してください。ウィンドウを閉じてもタスクトレイに最小化されただけの場合があります。画面は開いたままプロキシが停止しているなら、コアの起動に失敗している可能性があります。起動時、設定のインポート時、ノード切り替え時、スリープ復帰後など、発生した操作を記録しましょう。「突然終了した」というだけの説明よりも、きっかけのほうが有用です。実行環境、設定内容、権限のどれを調べるべきか判断する手がかりになります。

データを保存してから独立したテスト環境を作る

画面を開ける場合は、クライアントのエクスポートまたはバックアップ機能を使い、サブスクリプショングループや必要な設定を安全に保存します。画面を開けない場合は、作業を続ける前に既存のユーザーデータをコピーしてください。ディレクトリ全体をすぐに削除しないでください。設定には認証情報が含まれる場合があるため、バックアップは管理された場所に保存します。移行やテストの際、書き込み中の同じデータディレクトリを複数のインスタンスで同時に使用すると、ロックやデータの競合が発生することがあります。

ダウンロードページから、OSとプロセッサーのアーキテクチャに合ったパッケージを選びます。Windowsデスクトップ版にはクロスプラットフォームのUI版と、従来の画面を維持するWPF版があります。両者は画面の互換性を比較するために利用できますが、それだけでノード設定も変更されたとは判断できません。独立したテスト環境を作る際は、最初に過去の設定をすべてインポートせず、有効性が分かっている設定を1つだけ追加します。基本的な起動を確認してから、ほかの設定を段階的に戻してください。

システムの実行条件とファイル権限を確認する

起動前に空き容量が十分にあり、ユーザーディレクトリに書き込めること、OSが求める実行環境がインストールされていることを確認します。インストール先を読み取れても、ログ、キャッシュ、ユーザー設定の各ディレクトリに書き込めるとは限りません。ログにアクセス拒否が記録されていたら、対象のパスを特定して対処してください。ディスク全体の権限を緩めないでください。セキュリティソフトがファイルを隔離した場合は、警告内容と入手元を確認します。すべての保護機能を無効にする方法を恒久的な解決策にしないでください。

Linuxデスクトップで起動しない場合は、インストール後の起動コマンドをターミナルから実行し、不足ライブラリ、グラフィカルセッション、権限に関するメッセージを確認します。コマンドは実際にインストールされた起動方法に従い、バイナリの場所を推測しないでください。macOSでは通常のアプリ許可手順に従って起動を許可します。システム保護を全体的に無効にしないでください。プラットフォーム導入の詳細はLinuxのインストールと自動起動の設定をご覧ください。まず手動起動を解決してから自動起動を設定します。

最初のエラーからコアの問題を特定する

画面は開くのにコアがすぐ終了する場合は、まず設定の解析エラーを調べます。エラーにフィールド名や発生箇所が記載されている場合があり、非対応パラメーター、途中で欠けたインポート内容、誤ったカスタム設定が原因のことがあります。直近で変更した項目を一つだけ元に戻し、コアを再起動してください。Project V、V2Fly、Xrayは関連するエコシステムですが、設定の構造や拡張機能は完全には一致しません。どの設定断片もコアを問わず使えると考えないでください。

ポートの競合、リソースファイルの読み込み失敗、権限不足もコアの終了原因になります。ポートが競合する場合は、重複して起動したインスタンスを終了するか、待ち受けポートを変更してください。リソースファイルのエラーがある場合は、アプリのインストールが完了しているか、ファイルのパスを読み取れるか、内蔵の更新が正常に完了したか確認します。出所不明のコアファイルを組み合わせて使わないでください。TUN関連のエラーなら、まずTUNをオフにして通常のプロキシが動作するか確認し、その後で権限と仮想ネットワークアダプターを調べます。

異常を再発させないよう段階的に設定を戻す

独立した環境で正常に動作したら、サブスクリプション、ルーティング、カスタムDNS、TUNの順に設定を戻し、各段階で再起動してテストします。特定の設定をインポートした後に問題が再現する場合は、その設定と基本環境の違いを比較してください。上書きインストールを続けないでください。データベースの使用中や設定破損のエラーが出たら、元のバックアップを保存し、まずアプリが対応する復元方法を使います。構造を理解せずにデータファイルを直接編集しないでください。

起動時の自動起動でのみ問題が起きる場合は、ネットワーク接続前に起動していないか、作業ディレクトリが異ならないか、実行時の権限が異ならないか確認します。スリープ復帰後だけ起きる場合は、ネットワークが回復してからコアを再起動してください。問い合わせの際は、OSのアーキテクチャ、パッケージの種類、再現手順、個人情報を伏せたエラーの一部を共有します。設定全体を公開する必要はありません。復旧後はシステムプロキシが有効な待ち受け先を指しているか確認し、画面終了後もアプリが存在しないローカル入口に接続し続ける状態を防いでください。

Androidのトラブル：権限・アプリごとの振り分け・バックグラウンド切断

Androidでは、Xrayコアを使うv2rayNGを主な選択肢とし、V2Flyコアを採用するv2flyNGを代替クライアントとして利用できます。画面や対応パラメーターはアプリによって異なります。アプリを切り替えても設定の問題が自動的に解決するわけではありません。まずOS、クライアント名、接続方式、問題が起きる状況を記録し、初回から接続できないのか、特定のアプリだけ失敗するのか、画面消灯後に切断されるのかを判断します。症状によって確認する手順は異なります。

システムの権限と通信を管理するアプリを確認する

初回接続時は、システムの案内に従ってVPN接続を確立する権限を許可します。許可画面が表示されない、または拒否した場合は、関連するシステム設定を確認してから接続を再試行してください。Androidでは通常、同じユーザー環境で複数の一般アプリが同時にこの種の接続を使用することはできません。ほかの通信管理ツールが動作していないか確認します。仕事用プロファイルやデバイス管理ポリシーによって利用範囲が変わることもあるため、管理上の要件に従ってください。

システムに接続中の表示があっても、ネットワークサービスが確立したことを示すだけで、リモートノードが利用できる証拠にはなりません。クライアントのログを開き、明確な接続先にアクセスして、リクエストが届いているか、リモートとのハンドシェイクに成功したか確認します。すべてのアプリで失敗するなら、まずローカルネットワークと有効な設定をテストしてください。1つのアプリだけが失敗する場合は、アプリごとの振り分け、独自のDNS、アプリ独自のプロキシ設定を優先して確認します。すぐにすべてのデータをリセットする必要はありません。

画面消灯・バックグラウンド・ネットワーク切り替えに対処する

前面では接続できるのに画面消灯後に切断される場合は、バッテリー最適化、バックグラウンド動作の制限、端末メーカー独自のアプリ管理ルールを確認します。常時接続が必要なクライアントについては、システムの機能を使って必要なバックグラウンド動作を許可し、通知やプロセスが終了されていないか確認してください。設定メニューの名称は端末によって異なるため、特定の端末の手順をそのまま当てはめないでください。バックグラウンド制限の緩和はバッテリー消費を増やすため、常時接続が必要なアプリだけに適用します。

Wi-Fiからモバイルネットワークへ切り替えると、既存の接続を再確立する必要がある場合があります。まずネットワークにIPアドレスが割り当てられるまで待ち、クライアントの接続を停止してから再開します。特定のネットワークだけで失敗する場合は、DNS、アドレスファミリー、ネットワーク認証の違いを比較し、すぐにプロトコルを変更しないでください。「常時接続」や接続できない通信を遮断する設定を有効にすると、ノードが使えないとき端末全体がオフラインに見える場合があります。診断中に設定を変更する際は、まずその動作を理解してください。

アプリごとの振り分けと名前解決の範囲を確認する

アプリごとの振り分けには、「選択したアプリだけをプロキシ経由にする」「選択したアプリを迂回させる」など、方向の異なるモードがあります。同じアプリ一覧でもモードが逆なら、結果はまったく異なります。まず現在のモードを確認し、対象アプリが選択されているか調べてから保存し、必要に応じて再接続してください。アプリの更新、仕事用プロファイル内の複製、異なる入手元からのインストールでは、アプリ識別子が異なる場合があります。アイコンが同じでもルールが適用済みとは限りません。

Webページは開けるのに特定のアプリだけ失敗する場合は、アプリがUDPに依存していないか、独自の暗号化DNSを使用していないか、接続先サービスに制限されていないか確認します。AndroidのプライベートDNSとクライアントのDNS設定が、どちらも名前解決に影響する場合があります。一度に一つだけ変更して比較してください。LAN内の機器を検出できない場合は、プライベートネットワークへの直接接続設定とローカル名の解決も確認します。通信をプロキシから迂回させても、ブロードキャストによる機器検出まで自動的に復旧するわけではありません。

インストールパッケージ・サブスクリプション・復旧後の確認

Android用インストールパッケージから、端末に適したアーキテクチャを選びます。比較的新しい一般的な端末ではarm64が使われますが、端末の実際のアーキテクチャを確認してください。判断できない場合は、システム情報を確認するか、ページにある汎用版を利用します。インストール失敗の原因は、OSの互換性、空き容量、アプリの署名の違い、ダウングレード制限などの場合もあります。同じファイルを繰り返しダウンロードするだけで解決するとは限りません。既存アプリを置き換える前に設定をバックアップし、アンインストール後にサブスクリプションや振り分けルールを失わないようにしてください。

サブスクリプションの更新に失敗した場合は、このページのURL・リクエスト・解析の3段階に沿って確認します。クリップボードへのアクセス権の問題と、サーバーから返されたエラーを混同しないでください。復旧後は、前面でのアクセス、画面消灯からの復帰、Wi-Fiとモバイルネットワークの切り替えをそれぞれテストし、プロキシが必要なアプリと直接接続が必要なアプリの動作も確認します。有効だった設定だけを記録し、テスト用の一時ルールは削除してください。日常的な使い方はクイックスタートガイド、用語に関する疑問はよくある質問をご覧ください。