v2rayN 初回インストール設定チェックリスト：Windows・macOS共通の要点とよくある落とし穴

インストール前にシステム・アーキテクチャ・実行環境を確認

初回設定はサブスクリプションの貼り付けから始めないでください。まずダウンロードしたパッケージと端末のアーキテクチャが一致しているか、自包含パッケージかランタイム依存パッケージかを確認します。アーキテクチャを間違えると起動できず、ランタイムが不足している場合はノード設定ではなく、必要な .NET コンポーネントがないという警告が表示されます。

v2rayN 7.xのデスクトップ版はWindows、macOS、Linuxに対応しています。一般的なWindows端末ではx64版を使い、ARMプロセッサ搭載端末ではarm64版を選びます。macOSもarm64とx64を区別してください。ファイル名の「デスクトップ版」だけで判断せず、ダウンロード前にシステム情報でプロセッサのアーキテクチャを確認しましょう。

• 解凍が完了してからメインプログラムを実行し、設定ファイル、ログ、コアファイルが正常に書き込まれるようにします。
• バージョンを更新する前に、実行中のv2rayNを終了し、メニューバーやトレイにあるプロセスが終了していることを確認します。
• サブスクリプションのURLと必要なカスタムルーティングルールをバックアップし、移行時に実行ファイルだけをコピーしないでください。
• プログラムは開くのにコアの起動に失敗する場合は、まずログにあるファイルパス、権限、ランタイムのメッセージを確認し、その後でノードのパラメーターを調べます。

初回起動後は決められた順番で基本設定を完了する

正しい順番は、まずコアを確認し、次にサブスクリプションを追加、その後サーバーを選び、最後にシステムプロキシを有効にすることです。最初からシステムプロキシを何度も切り替えると、コアが起動していない、サブスクリプションが更新されていない、ブラウザが新しいプロキシ設定を読み込んでいない、といった問題が混在します。

1. コアを確認

   「設定」→「パラメーター設定」→「Core タイプ」を開き、通常のVLESS・VMessノードではまずXrayを選択します。保存してメイン画面に戻り、下部のログにコアの起動成功メッセージが表示されているか確認します。

2. グループを追加

   「サブスクリプショングループ」→「サブスクリプショングループ設定」→「追加」を開き、識別しやすい名前を入力して完全なサブスクリプションURLを貼り付けます。URLの前後に空白や改行を残さないでください。

3. サブスクリプションを更新

   グループを保存したら「サブスクリプショングループ」→「すべてのサブスクリプションを更新」を実行します。ノード一覧が更新され、結果がタイムアウト、空の内容、形式の解析失敗になっていないことを確認します。

4. ノードを選択

   サーバー一覧からノードを1つ選び、アクティブサーバーに設定します。選択行は現在の接続先を示すだけなので、コアが動作していることも確認してください。

5. ルーティングを設定

   初回の確認では、ルールが明確な基本ルーティングモードを選びます。接続が正常だと確認できたら、LAN、日本国内の直結サイト、プロキシ経由サイトの要件に合わせてカスタムルールを調整します。

6. プロキシを有効化

   トレイまたはメニューバーから「システムプロキシ」を開き、自動構成を選択します。テスト終了時やプログラムを終了する前に「システムプロキシをクリア」に切り替え、無効なポートがシステムに残らないようにします。

各手順を終えるたびに、メイン画面の状態とログを確認すると、原因を直接切り分けられます。サブスクリプションの更新でエラーが出ているならルーティングを変更する必要はなく、コアのポートが待ち受けていないならブラウザのキャッシュを先に疑う必要もありません。

システムプロキシ・コアのポート・ルーティングモードを分けて理解する

「ノードが接続済み」でも、「すべてのアプリがプロキシを経由している」とは限りません。コアはローカルポートを待ち受けてリモートと通信し、システムプロキシはOSのプロキシ設定に従うアプリをローカルポートへ導き、ルーティングルールが各リクエストをプロキシ経由または直接接続のどちらで送るかを決めます。3つの層のどれか1つが欠けるだけでも、一部のプログラムだけ使える状態になることがあります。

ポート番号を機械的にそのまま使わないでください。10808と10809は初期値としてよく使われますが、ユーザーによる変更、旧バージョンからの移行、ほかのローカルサービスによって変わることがあります。最も確実なのは、「設定」→「パラメーター設定」のローカル待ち受け設定と、コア起動ログに実際に表示される待ち受けアドレスです。

サブスクリプション読み込み後にプロトコル項目と更新結果を確認

サブスクリプションは単なるノード名の一覧ではありません。各レコードにはサーバーアドレス、ポート、ユーザー識別子、トランスポート方式、TLSパラメーター、パス、Server Name、Realityの公開鍵やフィンガープリントなども含まれます。v2rayNは更新後にこれらをローカル設定へ変換するため、重要な項目が1つでも欠けるとハンドシェイクに失敗することがあります。

VMessとVLESSでは、サーバーアドレスだけを比較しないでください。同じアドレスでも、異なるポート、トランスポート、セキュリティ層を利用できます。ノードを手動編集する際は、別のプロトコルの項目を混在させないように注意します。

• 更新後にノード数が0になった場合：まずサブスクリプションの応答が空でないか確認し、URLが改行で途中分割されていないか調べます。
• 古いノードが残っている場合：別のサブスクリプショングループを更新していないか、古いレコードを削除する設定が有効かを確認します。
• ノード名は正常なのにすべて失敗する場合：サブスクリプションの有効性、システム時刻、コアの種類、ログにあるハンドシェイクエラーを優先的に確認します。
• 一部のノードだけ失敗する場合：同じグループのほかのノードと比較し、単一ノードのパラメーターの問題か、ローカル共通設定の問題かを判断します。

自動起動・サブスクリプション更新・設定保存を行う

基本接続を確認してから自動化設定を有効にします。そうすれば、システムへのログイン直後に未検証の設定が読み込まれるのを防げます。WindowsとmacOSではログイン時の起動方法が異なりますが、確認の考え方は同じです。アプリの場所が固定され、ログイン項目が存在し、起動後にコアとローカル待ち受けポートが正常に動作している必要があります。

1. 自動起動を有効にする：「設定」→「パラメーター設定」でログイン時の自動起動オプションを探します。Windowsではシステムのスタートアップアプリ一覧も確認し、macOSではログイン項目が現在のアプリの場所を参照しているかも確認します。
2. アプリの場所を固定する：ログイン時の起動を有効にした後は、アプリのディレクトリを不用意に移動しないでください。すでに移動した場合は、古いログイン項目を削除してから新しい場所で再度有効にします。
3. 更新間隔を設定する：サブスクリプショングループの設定で、実際の用途に合った自動更新間隔を入力します。個人用端末ならまず1440分、つまり1日1回から始めれば十分で、数分おきにリクエストを繰り返す必要はありません。
4. 起動ログを残す：システムを再起動した後、まずコアが自動起動したか確認し、次にサブスクリプションの更新が成功したかを確認します。自動起動の成功と自動更新の成功は別の結果です。
5. 終了時の動作を確認する：メインウィンドウを閉じても、トレイやメニューバーに最小化されるだけの場合があります。プロキシを完全に停止するには、プログラムのメニューから終了し、システムプロキシが解除されたことを確認します。

自動更新は頻繁なほどよいとは限りません。間隔が短すぎるとエラーログが急速に増え、ネットワークが復旧した直後にリクエストを繰り返すこともあります。端末が常時オンラインでないなら、通常は1日1回で十分です。すぐに変更を取得したい場合は、「すべてのサブスクリプションを更新」を手動で実行するほうが明確です。

再現可能なテストで設定の有効性を確認する

初回接続では、サーバー一覧の色や遅延値だけを見ないでください。少なくとも、コアの起動、ローカルポートの待ち受け、システムプロキシの有効化、対象ページへのアクセス、ノード切り替え後の再テストまで確認します。一度に変更する項目を1つに絞ることで、結果がノード、ルーティング、ローカル設定のどれに起因するか判断できます。

表の186 msと241 msは、あるトラブル対応記録の例であり、速度の基準ではありません。遅延はノードの場所、回線、時間帯、ハンドシェイク方式に左右されます。ここで記録すべきなのは、同じネットワーク、同じ対象、同じルーティングモード、そして切り替え前後で唯一変えたノードというテスト条件です。

• まず1つのノードをテストし、成功してから一覧をまとめてテストします。大量の失敗ログで最初のエラーが埋もれるのを防げます。
• ノードを切り替えた後はテストページを開き直し、古い接続の再利用による誤判定を減らします。
• ルールモードでは失敗するのに一時的なグローバル確認では成功する場合、ドメイン、IP、アウトバウンドタグのルーティング一致を重点的に確認します。
• 同じ時間帯に2つのノードがともに失敗する場合は、まずローカルネットワーク、サブスクリプションの状態、コアのログを確認し、プロトコル項目を次々に変更しないでください。

初回利用でよくある問題と対処の順番

トラブル対応の基本は、端末からリモート側へ段階的に確認することです。まずプログラムとコア、次にポートとシステムプロキシ、その後にサブスクリプションとノード、最後にルーティングとトランスポートのパラメーターを確認します。前段の基本層を飛ばすと、ポート競合をノード障害と誤認しがちです。

これらの確認を終えれば、5つの質問に明確に答えられるはずです。プログラムは安定したディレクトリから動作しているか、コアは正常に起動したか、サブスクリプションは更新できたか、システムプロキシは正しいポートを指しているか、ルーティングは想定どおりアウトバウンドを選んでいるか。今後接続状況が変わっても、同じ順番で素早く原因を特定できます。