V2Rayをゼロから使いこなす：v2rayN完全設定

基本概念と通信経路

まずクライアント、コア、サーバーを区別する

V2Rayを使う際に混同しやすいのは、グラフィカルクライアント、プロキシコア、リモートサーバーの3つです。v2rayN、v2rayNG、v2flyNGはグラフィカルクライアントに分類され、サブスクリプションの保存、サーバー一覧の表示、実行用設定の生成、プロキシモードの切り替えを行い、ユーザーの操作をコアが理解できるパラメーターに変換します。XrayとV2Flyはコアの系統に属し、主にローカルポートの待ち受け、アウトバウンド接続の確立、ルーティングの照合、さまざまな転送方式の処理を担当します。サブスクリプション提供元が用意するリモートサーバーは通信経路の反対側にあり、クライアントから送られたプロトコル接続を受け取ります。画面に「起動済み」と表示されても、ローカルのコアプロセスが動作していることを示すだけで、リモートサーバーに必ず到達できるとは限りません。サブスクリプションの更新に成功しても、アドレスから解析可能な内容が返ったことを示すだけで、すべてのノードが接続できるとは限りません。

この3層を理解すれば、トラブルシューティングを境界ごとに進められます。プログラムが開かない場合はクライアントのインストールとシステム依存関係を、コアの起動に失敗する場合はローカルログとポート使用状況を、サーバーテストに失敗する場合はノードパラメーター、ネットワーク到達性、システム時刻を確認します。ブラウザーが従来のネットワークを使い続ける場合は、システムプロキシまたはTUNが対象アプリを実際に引き受けているかを確認してください。すべてを「ノードが使えない」と一括りにすると重要な手掛かりを見失い、再インストールを繰り返すことになります。

リクエストがアプリから外へ出るまで

v2rayNのシステムプロキシモードを例にすると、ブラウザーはまずOSのプロキシ設定を読み取り、v2rayNがローカルで待ち受けるHTTPまたはSOCKSのインバウンドポートへリクエストを渡します。コアはリクエストを受け取ると、routingに上から順に並ぶルールに従って、ドメイン、IP、ポート、プロトコル、インバウンドタグを確認します。ルールに一致すると、現在選択中のプロキシサーバー、directの直接接続、blockの遮断など、指定されたアウトバウンドへ送られます。どのルールにも一致しなければ、設定されたデフォルトのアウトバウンドに進みます。DNS問い合わせはアプリ、システム、コアのいずれかで行われる可能性があるため、「ドメインが直接接続ルールに一致したのに最終的にはプロキシを通る」といった現象は、名前解決の結果や照合段階に関係していることがよくあります。

プロトコル、転送層、セキュリティ層は別のパラメーター

VMess、VLESS、Trojanなどは通常、ノードが使用するプロキシプロトコルを示します。TCP、WebSocket、gRPCなどは転送方式を、TLS、REALITYなどは接続認証またはセキュリティ層を示します。ノードをインポートした後は、これらの項目をサーバー側の設定と一つずつ対応させる必要があり、アドレスとポートだけ残して自由に組み合わせることはできません。たとえばVLESS、TCP、REALITYを使うノードでは、flow、serverName、publicKey、shortIdなどの項目が接続成立を左右します。いずれかを変更すると、実際のリクエストに到達する前にハンドシェイクが終了することがあります。初心者には、共有リンクまたはサブスクリプションを完全な形でインポートし、項目の意味を理解するまでは転送パラメーターを手動で変更しない方法が最も安全です。

遅延、接続性、実際の速度

クライアントの遅延テストは通常、対象へ接続できるか、ハンドシェイクにおよそどれほど時間がかかるかを判断するためのもので、継続的な転送速度を示すものではありません。テスト方式によってTCPハンドシェイク、実際のプロトコルリクエスト、指定URLなど経路が異なるため、同じノードの結果がクライアントごとに異なっても不思議ではありません。遅延が小さいノードでも長時間接続が不安定な場合があり、遅延がやや大きくても十分な帯域を持つノードがあります。ノード選択では単発の数値だけでなく、連続接続の成否、Webページの初回応答の安定性、長時間利用時の切断頻度も確認してください。このような層別の理解が、サブスクリプション管理、ルーティング、TUN設定の基礎になります。

クライアントの選択とインストール

OSに合わせてクライアントを選ぶ

デスクトップ環境ではv2rayNを第一候補にします。Windows、macOS、Linuxに対応し、サブスクリプション管理、システムプロキシの切り替え、ルーティング設定、TUNの有効化ができるため、複数のデスクトップ端末で操作方法を統一するのに適しています。Androidではv2rayNGを第一候補にします。Xrayコアを使用し、モバイル端末での接続手順に合わせた画面構成になっています。V2Flyコアを使う必要がある場合はv2flyNGを選べます。3つのクライアントは役割が異なるため、同じ端末で同時に動かす必要はありません。複数のクライアントが同じローカルポートを同時に待ち受けたり、システムプロキシを同時に引き受けたりすると、原因を特定しにくいポート競合や状態の上書きが発生します。

アーキテクチャ、インストール形式、ディレクトリ権限

インストール前にOSのアーキテクチャを確認します。Windowsの一般的なデスクトップ端末はx64です。macOSでは「このMacについて」でチップの種類を確認してください。近年のAndroid端末は通常arm64ですが、判断できない場合は汎用版を選べます。Linuxではuname -mを実行して確認でき、x86_64はx64、aarch64はarm64に対応します。アーキテクチャが合わないと、インストーラーが実行を拒否する、形式エラーが表示される、起動直後に終了するといった現象が起きます。

Windowsのv2rayNデスクトップ版とクラシックWPF版は、日常利用の入口としてどちらか一方を選びます。圧縮アーカイブ版を使う場合は、書き込み権限のある固定ディレクトリへ完全に解凍してからメインプログラムを起動してください。圧縮ソフトの一時プレビュー画面から直接実行すると、設定ファイル、ログ、コアファイルを安定して保存できない場合があります。macOSではインストール後にアプリケーションフォルダーから起動します。Linuxでdebまたはrpmを使う場合、パッケージマネージャーがシステムの規則に従ってファイルを配置します。依存関係の警告が出たら、ライブラリを手動でコピーせず、対象ディストリビューションのパッケージマネージャーに処理させてください。

初回起動時に確認すること

初回起動後、すぐにTUNを有効にしないでください。メイン画面が正常に表示されるか、設定画面がコアを認識しているか、ログ画面に継続的なエラーが出ていないかを確認し、ローカルの待ち受けポートが他のプロキシクライアントに使われていないことも確認します。その後、設定を1つインポートし、サーバーを選択してクライアントの接続テストを実行します。通常のシステムプロキシ経路が安定して動作してから、ルーティングとTUNの章へ進んでください。これにより、インストールの問題と高度な通信の引き受けに関する問題を切り分けられます。

システム権限とセキュリティ警告への対処方針

TUNドライバーのインストール、システムプロキシの変更、ファイアウォールルールの書き込みでは、システム権限の確認が表示される場合があります。実行中のプログラム名と操作の出所を確認してから許可してください。通常のシステムプロキシで管理者権限を長期間使う必要はありませんが、TUNは仮想ネットワークインターフェースを作成するため、より高い権限が必要です。企業管理端末で統一ネットワークポリシーがある場合は、プロキシやネットワークアダプターを変更できるか事前に確認します。起動後、特定のアカウントだけ設定を保存できない場合は、プロトコルパラメーターを変更する前に、プログラムディレクトリの書き込み権限とアカウントの設定ディレクトリを確認してください。

インストール後はクライアントのダウンロードページで、使用中のプラットフォームに対応するクライアントの種類とインストール形式を確認できます。インストール段階の目標は、すべての機能を一度に設定することではなく、安定して起動し、設定を保存し、ログを読める基礎環境を作ることです。機能を追加するたびに、この基礎状態へ戻れる手順を残してください。

サブスクリプションのインポートとノード管理

サブスクリプションURLと単一ノードの共有リンク

サブスクリプションURLは通常、更新可能なサーバー一覧を指します。クライアントがURLへアクセスすると複数のノードを解析し、対応するサブスクリプショングループへ登録します。vmess、vlessなどの共有リンクは、単一ノードの完全なパラメーターを記述したもので、一時的なインポートや個別保存に適しています。見た目だけで両者を判別できるとは限りません。サブスクリプションURLは通常のHTTPSリンクの場合もアクセスパラメーターを含む場合もあり、単一ノードのリンクは一般にプロトコル名で始まります。共有リンクをサブスクリプションURL欄へ貼り付けたり、サブスクリプションURLを単一ノードのスキャン対象として扱ったりしないでください。

v2rayNでは、まずサブスクリプショングループ管理を開き、新しいグループを作成してサブスクリプションURLを入力し、「現在のサブスクリプションを更新」または同等の更新メニューを実行します。グループ名は用途や出典を表すものにし、後から判別できない「サブスクリプション1」「サブスクリプション2」のような名前は避けます。v2rayNGとv2flyNGでは入口の名称が多少異なる場合がありますが、URLを保存し、更新し、設定一覧へ戻り、対象ノードを選ぶという関係は同じです。更新前後のノードはサブスクリプション内容に従ってクライアントが管理するため、ノードの項目を手動で変更しても次回更新時に上書きされる可能性があります。

サブスクリプション更新に失敗したときの段階的な確認

更新後に一覧が空になった場合、まずログで「リクエスト失敗」か「解析失敗」かを確認します。リクエスト失敗はクライアントがサブスクリプション内容を取得できなかったことを示すため、URLが完全か、システム時刻が正確か、現在のネットワークからURLへアクセスできるか、更新が利用できないプロキシ出口経由に設定されていないかを確認します。解析失敗はサーバーが内容を返したものの、クライアントが想定する形式ではなかったことを示します。URLの期限切れ、ログインページの返却、アクセスパラメーターの欠落、クライアントのバージョンが新しい項目を認識できないケースなどが考えられます。元のグループを変更せずにテスト用グループを作り、完全なURLを貼り直して、古い項目の残りを切り分けることもできます。

古いノードが残っているのに更新が続けて失敗する場合、設定全体をすぐ削除しないでください。まず現在使えるノードを残し、ログにある最初の明確なエラーをコピーしてから、サブスクリプションリンクを確認します。確認順序はURL、ネットワークリクエスト、返却内容、解析処理、ノード接続です。更新失敗から直接クライアントの再インストールへ進まないでください。詳しい確認手順はサブスクリプション解析失敗の主な原因とセルフチェックリストも参照してください。

ノードテストの使い方

一括テストは明らかに接続できない項目を整理するのに適していますが、1回の結果を恒久的な順位として扱うべきではありません。まずサブスクリプションを更新し、同じテスト方式を選んでから、失敗が同じプロトコル、同じドメイン群、同じサーバー地域に集中していないかを確認します。同じサブスクリプション内の全ノードが同時に失敗する場合は、ローカルネットワーク、システム時刻、コアの状態、サブスクリプションパラメーターを優先して確認します。一部のノードだけが失敗する場合は、ノード自体の状態を検討します。短時間に何度もテストすると接続が混雑し、ログに並列エラーが大量に混ざるため、原因を特定しにくくなります。

グループ、備考、更新方針

サブスクリプションが増えたら、グループで管理範囲を分けます。異なる出典は別グループに入れ、手動ノードは独立したグループにまとめ、テスト用の一時ノードには分かりやすい備考を付けます。自動更新の間隔は、通常利用を頻繁に中断するほど短くせず、実際の変化頻度に合わせて設定し、手動更新の入口も残します。更新にプロキシが必要な場合は、依存する現在のノードが使えることを確認してください。そうしないと、「復旧には更新が必要なのに、更新には使えないノードが必要」という循環に陥ります。

サブスクリプションURL自体にアクセス認証情報が含まれている可能性があるため、公開スクリーンショット、ログ共有、公開文書へ貼り付けないでください。トラブルシューティングではドメインとエラー種別だけを残し、クエリパラメーターやパス中の識別情報は隠します。ノードの共有リンクにも完全な接続パラメーターが含まれるため、管理下の端末間だけで伝えてください。適切なノード管理の目標は項目数を増やすことではなく、出典、更新日時、よく使うノード、失敗理由をすぐ判別できる状態にすることです。

システムプロキシとプロキシモード

システムプロキシで解決できること

システムプロキシは、デスクトップで最初に身につける接続方法として適しています。v2rayNで有効にすると、OSのプロキシアドレスがローカルの待ち受けポートを指すようになります。システムプロキシ設定に従うブラウザーやデスクトップアプリは、その後リクエストをコアへ渡します。範囲が明確で、切り替えが簡単、トラブルシューティングの負担が小さい点が利点です。一方、システムプロキシを読み取らないプログラムや、ゲーム、コマンドラインツール、独自のネットワークスタックを持つアプリは直接接続することがあります。特定のプログラムだけ引き受けられない場合は、まずそのプログラムがシステムプロキシに対応しているかを確認し、すぐにノードのプロトコルを変更するのではなく、TUNが必要か判断してください。

システムプロキシの状態とコアの実行状態は別のものです。コアは起動しているのにシステムプロキシが無効、あるいはシステムプロキシが古いポートを指したままコアが終了していることもあります。クライアントを正常終了するときは、システムプロキシを元に戻す必要があります。異常終了後にブラウザーがネットワークへ接続できない場合は、OSのプロキシ設定を開き、ローカルアドレスが残っていないか確認してください。v2rayNを再起動してシステムプロキシを無効にするだけで復旧できる場合もあります。

グローバル、ルール、直接接続の違い

「グローバル」は通常、クライアントが引き受けた通信をすべてプロキシのアウトバウンドへ送ることを意味します。「ルール」は通信をルーティングで照合し、ルールに従ってプロキシ、直接接続、遮断のいずれかへ送ります。「直接接続」は引き受けた通信をローカルネットワークから直接送信します。ここで重要なのは「引き受けた通信」という条件です。アプリがシステムプロキシに入っていなければ、グローバルとルールを切り替えても影響はありません。逆に、グローバルモードも端末上のすべてのデータを自動的にクライアントへ入れるものではなく、コア内部のアウトバウンド選択を変えるだけです。

比較テストで通信の引き受け経路を確認する

プロキシモードを検証するときは、トレイアイコンの色だけを見ないでください。まず接続できることを確認したノードを選び、システムプロキシを有効にして、システムプロキシに従うブラウザーでテストページへアクセスします。次に直接接続モードへ切り替えて同じページを開き、最後にシステムプロキシを無効にします。3つの状態で何も変わらない場合は、ブラウザーが独自のプロキシ設定を使っていないか、システムプロキシのアドレスが現在のポートを指しているか、クライアントログに対応するリクエストがあるかを確認します。ログにリクエストがあるのに接続できない場合はルーティングまたはノード側の問題です。ログにリクエストがまったくない場合は、アプリからローカルインバウンドまでの経路に問題があります。

コマンドラインツールの動作は個別に確認する必要があります。一部のツールはデスクトップのシステムプロキシではなく、HTTP_PROXY、HTTPS_PROXY、ALL_PROXY環境変数を読み取ります。一時的なテストではツールのドキュメントに従ってプロキシアドレスを設定できますが、ポート番号を別の端末からそのまま流用せず、現在のクライアントのローカル待ち受け設定を基準にしてください。待ち受けポートを変更した場合は、手動で設定した環境変数とアプリ内プロキシも合わせて更新します。

LANアクセスとローカル待ち受け

LAN接続を許可すると、クライアントの待ち受け先がローカル端末だけでなくLANインターフェースにも広がります。同じネットワーク上の他の端末からこのPCをプロキシ入口として使う必要がある場合だけ有効にし、ファイアウォールの範囲、待ち受けアドレス、アクセス制御も同時に確認してください。通常の単独利用ではローカルのみの待ち受けにします。有効にしても他の端末から接続できない場合は、待ち受けアドレス、OSのファイアウォール、ルーターの端末分離、ポート入力の順に確認します。問題の切り分けを理由にすべてのインターフェースを長期間開放しないでください。本来明確だったローカルの境界が変わってしまいます。

ルーティングルール

ルールは順番に照合される

ルーティングの要点はルールの数ではなく照合順序です。コアは通常、ルールを上から下へ確認し、通信が1つに一致すると、そのルールが指定するアウトバウンドへ送り、後続のルールは処理しません。そのため、より具体的な例外ルールは、より広いルールより前に置く必要があります。たとえば特定のドメインはプロキシを通し、そのドメインが属する集合はデフォルトで直接接続する場合、単一ドメインのプロキシルールを集合の直接接続ルールより前に置きます。先に広いルールを置くと、後の例外は一度も適用されません。

よく使われる照合条件には、ドメイン、IP、ポート、ネットワーク種別、プロトコル、インバウンドタグがあります。domain条件は完全なドメイン名、サフィックス、ルールセットによる照合に適しています。ip条件は名前解決後の対象アドレスを扱い、portはサービスのポートを限定し、inboundTagは異なるローカル入口から来た通信を区別します。outboundTagは一致後に使う出口を決めます。ルール内のタグはoutboundsで実際に定義されているタグと一致しなければなりません。綴りの違いは設定チェックの失敗や、想定外のルーティング結果につながります。

簡潔なroutingの例

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:example.com",
          "geosite:category-ads-all"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

この例では、まずプライベートアドレスをdirectへ送り、ルーター、プリンター、LANサービスへのアクセスがリモート側へ回り込むのを防ぎます。2番目のルールでは、例示ドメインと指定された集合をblockへ送ります。最後のルールはフォールバックとして、残りのTCPとUDP通信をproxyへ送ります。実際のクライアントはグラフィカルインターフェースから同等の設定を生成する場合があり、アウトバウンドのタグ名も異なる可能性があります。ルールをコピーする前に、現在の設定にあるタグを確認してください。最後のルールは非常に広範囲なので、1番目に置くとLANの直接接続ルールが照合される機会を失います。

domainStrategyが判断に与える影響

domainStrategyは、ルーティング段階でどのような場合にドメインをIPへ解決するかを決めます。AsIsでは元のドメイン名を優先して保持し、IPルールのために自動で解決しません。IPIfNonMatchではドメインルールに一致しなかった場合にIPへ解決し、続けてIPルールを確認します。IPOnDemandはルールでIPが必要になったとき、より積極的に解決します。積極的であればよいとは限りません。追加の名前解決によって、DNS経路、キャッシュ、解決結果の違いが生じるためです。日常のルーティングではまずIPIfNonMatchから始め、ログを見て必要に応じて調整するとよいでしょう。

最小限のルールセットから始める

ルーティングを組むときは、まずLANの直接接続、明確にプロキシが必要な対象、残りの通信のデフォルト処理という3種類の基本動作を残します。安定してから、広告ブロック、アプリ専用ポート、複雑なドメイン集合を追加してください。追加は毎回1グループだけにし、ルール一覧のどこに置いたかを記録します。異常が出たら、まずモードをグローバルに切り替えて比較します。グローバルでは正常でルールモードだけ失敗するなら、ノード自体は使える可能性が高く、ルーティング条件、DNS、アウトバウンドタグを重点的に確認します。

複雑な設定はV2Ray設定ファイルの構造をセクションごとに解説も参考にし、inbounds、outbounds、routingの関係を理解してください。ルーティングを調べるときは、Webページが開いたかだけでなく、「元のドメイン名、解決されたアドレス、一致したルール、対象アウトバウンド」の4項目を記録します。この4項目が対応していれば、通常はルーティングの動作を説明して再現できます。

TUNモードの設定

TUNとシステムプロキシの通信引き受け範囲の違い

TUNモードは仮想ネットワークインターフェースでシステム通信を受け取り、システムプロキシを読み取らないアプリも広く対象にできます。OSはルーティング条件に合うパケットを仮想インターフェースへ渡し、クライアントがそれを変換してコアへ送ります。アプリプロキシより低いネットワーク層で動作するため、DNS、UDP、LANアクセス、デフォルトルート、ファイアウォールが結果に関係します。TUNは「より強力なグローバルスイッチ」ではなく、引き受ける範囲が広い一方で設定変数も多い動作方式です。

有効にする前に3つ確認します。現在のノードで通常のシステムプロキシが安定して接続できること、システムプロキシモードでルーティングルールが正しく動くこと、クライアントが必要な権限で仮想インターフェースを作成できることです。基礎経路を確認しないままTUNの起動に失敗すると、ノード、ルール、ドライバー、システムネットワークのどこが原因か区別できません。TUNを無効にした状態で使える設定を保存し、異常時にはまずその状態へ戻すことをおすすめします。

有効化の手順と必要な確認

v2rayNの設定でTUNを有効にすると、システムが権限昇格を求め、仮想ネットワークアダプターを作成する場合があります。許可した後、ログでアダプターの作成、アドレスの割り当て、ルートの書き込み、コアの起動にエラーがないことを確認します。続いて通常のWebページ、UDPを使うアプリ、最後にLAN機器を順にテストしてください。最初からカスタムDNS、厳格なルーティング、複雑なルールセット、複数のネットワークフィルターツールを同時に有効にすると、どの段階が原因か分からなくなります。

TUNが起動済みと表示されるのにネットワーク全体が切断された場合は、まずTUNを無効にして基礎ネットワークが復旧するか確認します。次にデフォルトルートが正しく書き込まれているか、DNSに利用可能な出口があるか、仮想アダプターがアドレスを取得しているか、他のセキュリティソフトが新しいインターフェースを阻止していないかを調べます。ブラウザーだけ正常で特定のアプリが失敗する場合は、そのアプリがTCPとUDPのどちらを使うか、ルーティングルールが該当プロトコルを遮断していないかを確認します。ドメインだけ失敗し、テスト用アドレスへ直接アクセスすると応答がある場合は、通常DNSが原因です。

DNSとループバックの問題

TUN環境では、クライアント自身が発行した接続をTUNが再び捕捉してクライアントへ戻し、ルーティングループを形成しないようにする必要があります。成熟したクライアントは、コアプロセス、サーバーアドレス、特定のアウトバウンドを迂回させますが、カスタムルールによってこの関係が崩れることがあります。同じサーバーアドレスへの接続がログに繰り返し現れる、CPU使用率が上がる、接続がすぐ失敗するといった場合が典型です。そのときはデフォルトのTUNルールへ戻し、プロキシサーバーのアドレスが実際のネットワークインターフェースから直接接続され、コアのアウトバウンドが仮想インターフェースへ再び入っていないことを確認します。

DNSの処理は、単一で説明可能な主要経路に保ちます。システムDNS、クライアント内蔵DNS、ブラウザー独自の名前解決、他のネットワークツールが同時に動作すると、ドメインが場所ごとに異なる結果を得ることがあります。トラブルシューティングでは追加のアプリレベルDNS機能を一時的に無効にし、クライアント推奨のデフォルト設定を使って、ログでドメイン問い合わせがどのインバウンドから入り、どのアウトバウンドを経由して返ったかを確認します。安定したら、カスタムポリシーを1つずつ戻します。

スリープ、ネットワーク切り替え、終了後の復旧

ノートPCがスリープから復帰したとき、有線と無線を切り替えたとき、または別のネットワークへ移動したとき、仮想インターフェースとデフォルトルートが古い状態を参照し続けることがあります。接続が切れたら、まずTUNを停止し、実ネットワークが有効なアドレスを取得するまで待ってから再度有効にします。クライアントの異常終了後にネットワークが戻らない場合は、システムプロキシ、仮想アダプター、デフォルトルートを確認し、すぐに設定全体を削除する必要はありません。Windowsでは残ったシステムプロキシを無効にしてクライアントを再起動し、Linuxではip routeでデフォルトルートを確認します。macOSではネットワーク設定で現在のサービス順序を確認できます。

TUN設定の完了基準は、アイコンに「準備完了」と表示されることではありません。通常のWebページ、UDPアプリ、LANリソース、スリープ復帰、クライアント終了という5つの場面で、予測どおりの結果が得られることです。テスト後は、DNS方式、プライベートネットワーク範囲のルール、権限設定を記録しておくと、アップグレードやネットワーク変更時にすぐ比較できます。

トラブルシューティングと日常のメンテナンス

最初の有効なエラーを読む

コアの起動に失敗した場合、ログの後半に大量に並ぶエラーは、最初の問題から連鎖した結果にすぎないことがあります。今回の起動時刻から下へ読み進め、項目名、ポート、ファイルパス、設定セクションを含む明確な最初のエラーを見つけてください。よくある種類は、ローカルポートの使用中、JSON項目の形式エラー、アウトバウンドタグの不存在、転送パラメーターの不足、コアファイルを実行できない、設定ディレクトリへの書き込み権限がない、といったものです。元のエラーを記録してから設定を変更し、1回につき1つの原因だけを処理して再起動します。ノード、ポート、コア、ルーティングルールを同時に変えないでください。

ポートが使用中の場合、まず別のクライアントがバックグラウンドで動作していないか確認します。Windowsでは次のコマンドでローカルポートを使用しているプロセスIDを確認し、タスクマネージャーでプログラムを照合できます。Linuxではssで待ち受けプロセスを確認できます。ポート番号はクライアント設定に表示された実際のローカル待ち受けポートへ置き換えてください。

netstat -ano | findstr LISTENING
ss -lntup

ポートが使用中だからといって、任意の数字へ適当に変更しないでください。ブラウザー、環境変数、他のアプリが古いポートを手動で設定している場合は、変更後にすべて更新する必要があります。ログを読む詳しい方法はログ画面からコアの起動エラーを特定するトラブルシューティング手順も参照してください。

通信経路に沿ってトラブルシューティング項目を作る

プログラムは起動するのに対象へアクセスできない場合は、サブスクリプションが更新できるか、対象ノードの接続テストが完了するか、コアが実行中か、アプリのリクエストがローカルインバウンドへ入っているか、ルーティングが正しいアウトバウンドを選んでいるか、DNSが利用可能な結果を返すかを順に確認します。各段階に、サブスクリプションログ、コアの起動ログ、リクエスト記録、モード比較の結果など、観察可能な証拠が必要です。グローバルモードでは使えるのにルールモードでは使えない場合はルーティングを、システムプロキシでは使えるのにTUNでは使えない場合は仮想インターフェース、DNS、システムルートを重点的に確認します。すべてのモードで接続できない場合は、ノードパラメーター、システム時刻、基礎ネットワークへ戻ります。

日常の更新とロールバック

クライアント、コア、サブスクリプション、ルールセットは4種類の異なる更新対象であり、同じメンテナンスで一度にすべて交換すべきではありません。安全な順序は、現在使える状態を記録し、そのうち1つを更新して再起動し、よく使う場面を検証してから次へ進むことです。クライアントのアップグレード後は設定移行とメニュー変更を、コア更新後はプロトコルパラメーターと起動ログを、サブスクリプション更新後はノードの増減と名称変更を、ルールセット更新後はよく使うWebサイトとLANアクセスを重点的に確認します。各段階に検証点を設ければ、異常を直近の変更に限定できます。

ロールバックには、識別可能な基準状態を残す必要があります。少なくとも現在のクライアント種類、サブスクリプショングループ、よく使うノード、システムプロキシモード、TUNの状態、カスタムルーティングルールを記録します。設定のエクスポートファイルは管理下の場所に保存し、サブスクリプションURLやノード情報を公開同期ディレクトリへ置かないでください。アップグレード後に問題が出たら、まず直近の変更項目だけを戻します。設定をすべて削除して環境を作り直すと一時的に復旧する場合もありますが、原因を説明できるログや差分も同時に失われます。

ログを共有する前の処理

ログにはエラー発生時刻、エラー種別、項目名、対象ポート、クライアントで行った操作手順を残すと役立ちますが、サブスクリプションのパス、サーバーアドレス、ユーザー識別子、ローカルディレクトリが含まれることがあります。他者へ渡す前に、サブスクリプションのクエリパラメーター、ノード識別情報、個人ディレクトリ名を削除し、エラーの前後関係は残してください。最後の1行だけでは起動時の情報が不足し、設定全体を公開すると不要なデータまで露出します。「発生前に何をしたか、期待した結果、実際の結果、最初のエラーとその前後数行」を提供するのがおすすめです。

安定したメンテナンスには、設定を頻繁に初期化するのではなく、再現可能な手順が必要です。基準状態を残し、一度に1つの変数だけを変更し、最初のエラーから読み進めれば、多くの問題を明確な層まで絞り込めます。メイン画面の各領域の役割はv2rayNメイン画面の機能エリア詳解も参照してください。

設定ファイルと上級設定への道筋

グラフィカル設定を設定構造へ対応付ける

上級設定で重要なのは、グラフィカルクライアントを離れてすべての設定を手書きすることではなく、画面上の操作が最終的にどの構造を変更するか理解することです。V2Ray系の設定は通常、log、dns、inbounds、outbounds、routingなどで構成されます。inboundsはローカルのSOCKS、HTTP、TUN入口など、通信がコアへ入る方法を定義します。outboundsはプロキシ、直接接続、遮断の出口を定義します。routingはインバウンド通信をどのアウトバウンドへ送るかを決めます。dnsはドメインの解決方法と、解決リクエストをどの経路で送るかに影響し、logは記録レベルと出力先を決めます。

v2rayNでサーバーを切り替えると、通常はメインプロキシのアウトバウンドパラメーターが変わります。グローバルとルールモードの切り替えはルーティングの選択を変え、ローカルポートの変更はインバウンドの待ち受けに影響し、TUNを有効にすると対応するインバウンドとシステムネットワーク設定が追加または変更されます。この対応関係を理解すれば、ログに出るinboundTag、outboundTag、ドメイン戦略などの語が孤立した項目ではなくなります。設定を読むときは、まず「入口—ルール—出口」の3段階を図にし、その後でプロトコルの詳細を確認します。

設定変更は最小限の差分で行う

設定を手動で調整する前に、現在使えるバージョンをコピーし、複製側に用途を記載します。1回につき1つの論理的な目的だけを変更してください。たとえば直接接続するドメインを1つ追加する、DNSアウトバウンドを変更する、テスト用インバウンドを1つ追加する、といった具合です。保存後はまずクライアントまたはコアの設定チェックを実行し、起動して冒頭のログを確認し、最後に変更対象に直接関係するリクエストを検証します。同じ編集でルーティングを全面的に並べ替え、DNS、待ち受けポート、ノードを同時に変更すると、接続できてもどの変更が作用したのか判断できません。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ]
}

この例は、ローカルのSOCKSインバウンドと、直接接続・遮断という2つの基本アウトバウンドを示します。待ち受けアドレスに127.0.0.1を使うため、アクセスできるのはこの端末だけです。UDPを有効にすると、このインバウンドで対応するリクエストを受け取れます。プロキシのアウトバウンドにはサブスクリプションまたはサーバーが提供する実際のプロトコルパラメーターが必要なため、これは完全なリモートプロキシ設定ではありません。学習時はこのような簡略化した断片で構造を理解し、日常の接続ではクライアントにサブスクリプションと一致する完全な設定を生成させてください。

ログレベルと観察範囲

日常の実行ではwarningなど控えめなログレベルで十分です。複雑なルーティングや接続過程を調べるときだけ一時的に詳細度を上げ、原因を確認したら戻します。詳細ログは内容量が急増し、より多くの対象情報を記録する可能性もあるため、長期間の有効化には向きません。ログを見るときは、1つのテストリクエストの時刻を記録し、その時刻の前後からインバウンド、対象ドメイン、ルーティングの判断、アウトバウンドエラーを探します。明確なテスト操作を伴わない長大なログでは、バックグラウンドのリクエストと対象リクエストを区別しにくくなります。

おすすめの上級学習順序

第1段階ではシステムプロキシ、ノード選択、ログの入口を身につけます。第2段階でドメイン、IP、ポート、ルールの順序を理解します。第3段階でDNSリクエストが発生する場所とdomainStrategyの影響を学びます。第4段階でTUNの仮想インターフェース、デフォルトルート、UDPを扱い、第5段階でプロトコル項目と転送パラメーターに進みます。ローカルで観察できる動作からプロトコルの詳細へ段階的に進むため、問題が起きても確認済みの基礎層へ戻れます。

プロトコル学習は項目同士の関係を軸に進めます。VLESSなどのプロトコル項目は認証情報とフロー制御を、TCP、WebSocket、gRPCなどの転送方式は通信の運搬を、TLSまたはREALITYは対応するセキュリティと認証パラメーターを担います。共有リンクは常に完全なパラメーターの組として扱い、名前が似ているからといって項目を入れ替えないでください。単一ノードのリンクとサブスクリプションの構造を比較する場合は、vmessとvlessの共有リンクの使い方を参照してください。

自分の実行基準を作る

このガイドを終えたら、端末ごとの基準状態を作ることをおすすめします。クライアント名、OS、待ち受けポート、システムプロキシモード、TUNの状態、DNS経路、ルーティングルールの出典、よく使うサブスクリプショングループを記録します。基準にはノードの機密パラメーターを保存せず、設定の関係だけを記述します。アップグレードや変更のたびに、クライアント起動、サブスクリプション更新、通常のWebページ、ルール振り分け、LANアクセス、UDPアプリ、スリープ復帰を同じ条件で検証します。結果が基準状態と一致して初めて、変更完了と判断できます。

ゼロから使いこなすとは、すべての項目を暗記することではありません。問題の層を特定し、ログの証拠を集め、最小限の変更を行い、比較テストで確認するという安定した分析順序を身につけることです。最短の設定手順をもう一度行う場合はクイックスタートへ戻り、別のプラットフォーム用インストーラーが必要な場合はクライアントのダウンロードページへ進んでください。前者は操作の入口、後者は設定同士の因果関係を説明します。