ルーターと旁路ルーターへのV2Rayコア導入ガイド：構成の選び方と注意点

ルーターに V2Ray または Xray コアを配置する目的は、手動設定する SOCKS プロキシを増やすことではありません。LAN 内の通信を共通ゲートウェイで識別し、ルーティングと DNS 処理を一元化することです。安定性を左右するのは、ゲートウェイの位置、Linux のネットワーク機能、コア設定、ルールデータ、ハードウェア性能であり、設定ファイルが起動するかどうかだけでは判断できません。

まずゲートウェイの位置を決める：メインルーターで直接実行するか、旁路ルーターにするか

メインルーターでの直接実行とは、PPPoE 接続、NAT、DHCP、ファイアウォールを担う機器で同時にコアを動かす構成です。通信経路が短く、クライアントのデフォルトゲートウェイを変更する必要もありません。新しく接続した LAN 機器もルール体系に入りやすい一方、すべてのネットワーク機能が一台に集中するため、コアの異常、ルールミス、メモリ不足が LAN 全体に影響します。

旁路ルーターゲートウェイは通常、メインルーターと同じサブネットに置きます。外部ネットワークへの接続はメインルーターが担当し、旁路ルーターが指定した機器の転送と透過プロキシを処理します。個別に再起動や切り戻しができ、まず PC や Android 機器一台で試してから対象を広げる運用にも適しています。ただし、接続するだけで通信を自動的に引き継ぐわけではありません。クライアントのデフォルトゲートウェイ、DHCP 配布、静的ルートを明確に設定する必要があります。

選択する前に、実際の通信経路を図にして確認しましょう。例えば、旁路ルーターのアドレスが 192.168.1.2、メインルーターが 192.168.1.1 の場合、対象機器のデフォルトゲートウェイは 192.168.1.2 に設定し、旁路ルーターのデフォルトルートは 192.168.1.1 に向けます。クライアントがメインルーターをデフォルトゲートウェイにしたままだと、旁路ルーターの透過プロキシルールには通信が届きません。

コア、ファームウェア、プロセッサ性能の評価方法

ルーターの「V2Ray 対応」は、単に特定のバイナリを実行できるという意味に過ぎず、透過プロキシに必要な機能がすべてそろっているとは限りません。少なくとも、プロセッサのアーキテクチャ、対象コアの実行可否、空きストレージ、サービスマネージャーによるプロセス起動、ポリシールーティングと透過転送を支えるネットワークモジュールを確認してください。

V2Ray コアは、既存の VMess、VLESS、一般的なトランスポート設定に適しています。Xray コアは、VLESS、透過プロキシ、新しいトランスポート機能で広く使われています。設定構造は似ていますが、すべての項目をそのまま相互利用できるわけではありません。サブスクリプション URL も、通常はルーターのコアが設定ファイルとして直接読み込むものではなく、管理層で解析してからコア形式の outbound 設定を生成します。

プロセッサ性能はコア数だけで判断できません。同じクアッドコアでも、クロック周波数、キャッシュ、暗号化命令、冷却設計によって大きな差が出ます。メモリはコア本体、ルールデータ、DNS キャッシュ、ログ、ファームウェアのバックグラウンドサービスが共同で消費します。メモリ 128 MB の古い機器では、大きな GeoSite データを読み込むとメモリ回収やプロセス終了が起きやすくなります。

設定ファイルの主要項目と透過プロキシの入口

ゲートウェイ設定には、少なくとも inbound、outbound、routing、log の四つが必要です。透過プロキシの inbound には dokodemo-door がよく使われ、followRedirect によりファイアウォールでリダイレクトされた元の宛先アドレスを受け取ります。outbound には proxy、direct、block など分かりやすいタグを設定し、ルーティングルールから参照します。

以下は構造を示す例で、実際のサーバーアドレス、認証情報、完全な DNS 設定は省略しています。例では 12345 で待ち受け、TCP と UDP の両方を受け付け、宛先のスニッフィングを有効にします。実際に使用する際は、outbound のプロトコルとトランスポート項目をノードのパラメーターに合わせてください。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "transparent-in",
      "port": 12345,
      "protocol": "dokodemo-door",
      "settings": {
        "network": "tcp,udp",
        "followRedirect": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls"]
      },
      "streamSettings": {
        "sockopt": {
          "tproxy": "tproxy"
        }
      }
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": []
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

geoip:private は前方に配置し、LAN、ループバック、予約済みアドレスがプロキシ outbound に入らないようにします。ドメインルールは通常、スニッフィング結果や DNS 結果を先に照合し、該当しなければ宛先 IP で判定します。ルールは上から順に適用されるため、範囲の広いルールを先に置くと、後続のより精密な直接接続やブロックルールが隠れてしまいます。

• inbounds：透過プロキシの待ち受けアドレス、ポート、ネットワーク種別、リダイレクト動作を決めます。
• outbounds：プロキシ、直接接続、ブロックの出口を定義します。タグはルーティングルールと完全に一致させてください。
• routing：ドメイン、IP、ポート、inbound タグなどの条件で通信の出口を決めます。
• dns：ドメインをどのサーバーで検索するか、検索通信をプロキシ経由にするかを決めます。
• log：初回導入では warning を使うか、一時的に info へ切り替えます。安定後は過剰なログを長期間出し続けないようにします。

透過プロキシ、ポリシールーティング、DNS ループ

透過プロキシはコアだけで完結する機能ではありません。ファイアウォールが対象通信を選び、マークを付けます。ポリシールーティングがマーク付きパケットをローカルの透過入口へ送り、コアが元の宛先を読み取って outbound を選択します。TCP ではリダイレクトまたは TPROXY、UDP では通常、宛先情報を保持できる TPROXY が必要です。具体的なコマンドは、ファームウェアが採用するファイアウォールのバックエンドによって異なります。

以下のコマンドは、Linux のポリシールーティングと TPROXY の関係を示す要点のみで、すべてのファームウェアにそのまま適用できる完全なスクリプトではありません。実行前に必要なモジュールが含まれていることを確認し、ゲートウェイ自身、LAN アドレス、コアの outbound 接続、管理ポートを除外してください。除外しないと通信ループが発生しやすくなります。

ip rule add fwmark 1 table 100
ip route add local 0.0.0.0/0 dev lo table 100

iptables -t mangle -N V2RAY
iptables -t mangle -A V2RAY -d 0.0.0.0/8 -j RETURN
iptables -t mangle -A V2RAY -d 10.0.0.0/8 -j RETURN
iptables -t mangle -A V2RAY -d 127.0.0.0/8 -j RETURN
iptables -t mangle -A V2RAY -d 172.16.0.0/12 -j RETURN
iptables -t mangle -A V2RAY -d 192.168.0.0/16 -j RETURN
iptables -t mangle -A V2RAY -p tcp -j TPROXY --on-port 12345 --tproxy-mark 1
iptables -t mangle -A V2RAY -p udp -j TPROXY --on-port 12345 --tproxy-mark 1

旁路ルーターでは IPv4 転送も有効にする必要があります。sysctl net.ipv4.ip_forward で確認でき、1 が返れば有効です。IPv6 を使う場合は、IPv6 のルートとファイアウォールルールを別途設計してください。IPv4 だけを処理する場合は、クライアントが未管理の IPv6 デフォルトルートで旁路ルーターを迂回しないことも確認します。

1. まず ip route で、旁路ルーターのデフォルト出口がメインルーターを向いていることを確認します。
2. ip rule で、マーク 1 がルーティングテーブル 100 を参照することを確認します。
3. ファイアウォールのカウンターで、テスト通信が実際にカスタムチェーンへ入っていることを確認します。
4. 12345 が対象コアによって待ち受けられ、待ち受けプロトコルに TCP と UDP の両方が含まれることを確認します。
5. 最後にコアのログを確認し、「通信が入っていない」のか「outbound 接続に失敗している」のかを切り分けます。

DNS で最も多い問題は、検索経路とプロキシ経路が相互に入れ子になることです。例えば LAN 機器が旁路ルーターを DNS に指定し、旁路ルーターが透過ルールで再び捕捉されるアドレスへ検索を送ると、タイムアウトや接続の繰り返しが発生します。DNS outbound に明確なタグを設定するか、ファイアウォールでローカル DNS プロセスと上流アドレスを除外してください。

性能ボトルネックは継続負荷で判断する

ルーターのスループットは、プロトコル、トランスポート層、暗号化処理、接続数、冷却性能によって決まります。ウェブページが時々開くだけでは性能が十分とはいえず、短時間の速度測定では CPU の一時的なブーストに隠れることもあります。固定ノードと固定ネットワーク条件で 10 分間連続転送し、スループット、CPU、メモリ、温度、パケットロスを同時に記録する方法が有効です。

実験室での参考条件は、クアッドコア ARM Cortex-A53 1.5 GHz、メモリ 1 GB、ギガビットポート、外部回線 300 Mbps です。直接接続の実測値は約 286 Mbps。単一の VLESS over TCP with TLS outbound を有効にすると、継続スループットは約 126 Mbps、CPU 使用率のピークは 91%、温度は 54°C から 72°C に上昇しました。この結果は、このハードウェア構成に計算処理のボトルネックがあることを示すだけで、個別機器のテストに代わるものではありません。

CPU の単一コアが長時間ほぼ最大負荷なのにポート使用率が低い場合、ボトルネックはプロトコル処理または暗号化計算にある可能性が高いです。CPU 使用率が低いのにパケットロスが増える場合は、NIC ドライバー、ソフト割り込み、キューを確認します。数分後から速度が徐々に低下する場合は、温度と周波数低下を確認してください。短時間接続が大量に発生すると、コネクショントラッキングテーブルとメモリへの負荷も高まり、単一接続の速度測定とは結果が異なります。

家庭用のギガビット回線だからといって、ゲートウェイがギガビット級のプロキシスループットを処理する必要はありません。ただし、実際の外部回線速度をカバーし、計算性能に約 20% の余裕を残すべきです。外部回線が 300 Mbps なのにテストで安定して 126 Mbps しか処理できないなら、ルールを増やしてもハードウェアの制約は解決しません。対象範囲を狭める、高性能な旁路ルーターに変更する、または高負荷の端末でクライアントを個別実行してください。

稼働前の確認とよくある障害への対処

導入後は、コアの状態が「実行中」と表示されるかだけで判断しないでください。直接接続ドメイン、プロキシドメイン、LAN アドレス、DNS 検索、TCP、UDP、ゲートウェイ再起動後の復旧まで確認します。設定ファイルの権限、システム時刻、ルールデータの保存場所も確認してください。証明書検証には正確な時刻が必要で、GeoIP や GeoSite ファイルが欠けると該当ルールを期待どおり読み込めません。

• クライアントからメインルーターと旁路ルーターの管理アドレスにアクセスでき、プライベートネットワークの通信がプロキシへ入っていない。
• 中国本土向けの直接接続ルールとプロキシルールが、それぞれ想定した outbound タグに一致する。
• 53 番ポートを待ち受ける DNS サービスが計画どおり一つだけで、重複使用がない。
• 透過入口のポート 12345 が外部ネットワークインターフェースに公開されていない。
• 再起動後、コア、ポリシールーティング、ファイアウォールルールが正しい順序で復旧する。
• コア停止時に明確なフォールバックがあり、すべての通信が停止したポートへ送り続けられない。

最終的な設定には、起動可能な最小構成と現在稼働中の構成をそれぞれ保存してください。コアの変更、ルールデータの更新、DNS 上流の変更など、一度に一つの変数だけを調整し、変更後は同じ検証手順を完了します。ルーター導入の信頼性は、大量のルールを一度に投入して放置することではなく、観測可能で、切り戻せて、再現できることから生まれます。