路由器直跑 V2Ray 核心可行嗎：旁路由部署思路與流程總覽

先選拓撲：主路由直跑還是獨立旁路由

所謂「路由器直跑核心」，就是讓 V2Ray 或 Xray 程序執行在閘道裝置上，再由防火牆將區域網路流量送入核心。電腦與 Android 裝置不必各自啟用 v2rayN 或 v2rayNG，也能依照閘道規則分流。它解決的是多裝置統一管理問題，不會自動改善節點線路、頻寬或延遲。

主路由方案的路徑最短。撥號、DHCP、DNS、NAT、透明代理都集中在同一台裝置上，資料少經過一次轉送，網路結構也更容易釐清。不過，設定錯誤會直接影響整個家庭網路。核心異常、DNS 迴圈或防火牆規則寫錯，都可能讓一般直連流量一併中斷。

旁路由方案將代理工作拆分到第二台裝置。主路由繼續負責撥號與基礎網路，旁路由只處理指定終端。除錯期間可以先讓一台測試電腦將閘道改為旁路由位址，確認穩定後再透過 DHCP 發布給更多裝置。即使旁路由停止服務，主路由本身仍能恢復一般網路。

硬體門檻：記憶體夠用不等於轉送夠快

核心執行所需的儲存空間與記憶體並不高，真正影響體驗的是單核心效能、加密運算、連線數量與散熱。路由器標示千兆網路埠，只代表實體介面的能力，不代表經過透明代理後仍能跑滿千兆。VMess、VLESS 以及不同傳輸層組合都會消耗 CPU，啟用詳細記錄與複雜規則後也會增加額外負載。

以下以 OpenWrt 24.10.2、Xray 25.6.8 作為一組部署紀錄範例，在四核心 ARM 裝置上進行單一連線下載測試：直連約 936 Mbps，VLESS over TCP 約 612 Mbps，VMess over WebSocket 約 438 Mbps。換成雙核心低頻裝置後，同一條線路分別約為 917 Mbps、214 Mbps 與 156 Mbps。這些數字不能視為所有硬體的跑分，但足以說明網路埠規格與代理吞吐量之間不能直接畫上等號。

• 確認架構是否與核心檔案相符，常見類型包括 aarch64、armv7 與 x86_64，檔案不能混用。
• 確認快閃儲存空間仍然充足。除了核心本體，還要為 Geo 資料、設定備份與記錄輪替預留空間。
• 壓力測試至少持續 15 分鐘，不要只看測速頁面的瞬間峰值。溫度升高後的降頻狀況，才更接近真實家庭負載。
• 同時測試 TCP 與 UDP。網頁能開不代表視訊通話、遊戲或基於 UDP 的網域名稱解析也正常。

設定部署：訂閱連結不能直接交給核心

v2rayN、v2rayNG 與 v2flyNG 是具備圖形介面的客戶端，可以管理訂閱、節點與執行參數。V2Ray 或 Xray 核心本身讀取的是結構化設定檔，不會將常見訂閱連結自動轉換成完整的透明代理方案。訂閱只包含節點資訊時，仍缺少入站連接埠、DNS、路由規則、記錄層級與防火牆配合。

穩妥的流程是先在客戶端驗證節點參數，再將伺服器位址、連接埠、使用者識別碼、傳輸方式與 TLS 相關欄位寫入路由器設定。桌面端可在 v2rayN 的「設定」→「參數設定」→「Core 類型」確認目前使用的核心家族，接著使用同一節點進行連線測試。Android 端可用 v2rayNG 驗證 Xray 節點，用 v2flyNG 驗證 V2Fly 設定，但不要將客戶端匯出的局部資訊直接當成路由器透明代理設定。

1. 確認架構

   在路由器系統資訊中確認 aarch64、armv7 或 x86_64，並核對可用快閃儲存空間與記憶體。建議至少預留 80 MB 磁碟空間與 256 MB 可用記憶體。

2. 驗證節點

   先在 v2rayN、v2rayNG 或 v2flyNG 中連線至同一節點，記錄位址、連接埠、使用者識別碼、傳輸層、TLS 與伺服器名稱，排除節點本身無法使用的情況。

3. 確認核心

   進行桌面驗證時，進入 v2rayN「設定」→「參數設定」→「Core 類型」，確認測試使用的是 Xray 還是 V2Fly；路由器端採用對應欄位，不要混用專屬功能。

4. 產生設定

   將入站監聽設定為本機位址與固定連接埠，例如透明入站使用 12345，管理用 SOCKS 入站使用 10808，再補齊直連、代理與阻斷出站。

5. 小範圍上線

   先讓一台測試裝置使用旁路由閘道，依序驗證網頁、DNS、影片與 UDP 應用程式。確認記錄沒有迴圈連線後，再修改 DHCP 閘道發布範圍。

透明代理核心：入站連接埠、策略路由與 DNS

透明代理不是簡單開啟一個 SOCKS 連接埠。SOCKS 連接埠需要應用程式主動連線，而路由器接管的是原本要前往任意目標位址的流量。防火牆必須先標記並轉送連線，策略路由再將已標記的資料送回本機透明入站，核心透過原始目標位址決定代理或直連。

TCP 可以採用重新導向或 TPROXY，UDP 通常需要 TPROXY 才能保留目標資訊。若只處理 TCP，網頁可能正常，但遊戲、即時通話與部分 DNS 請求會繞過代理或失敗。OpenWrt 新版本通常以 firewall4 與 nftables 為基礎，舊教學中的 iptables 指令不能原樣照搬；規則概念相同，但語法與掛載位置不同。

{
  "inbounds": [
    {
      "tag": "transparent-in",
      "listen": "0.0.0.0",
      "port": 12345,
      "protocol": "dokodemo-door",
      "settings": {
        "network": "tcp,udp",
        "followRedirect": true
      },
      "streamSettings": {
        "sockopt": {
          "tproxy": "tproxy"
        }
      }
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

上方設定只展示核心側的關鍵結構，不包含節點出站，也不能取代防火牆規則。連接埠 12345 必須與 nftables 的轉送目標一致。區域網路位址、群播、路由器管理位址與 DHCP 流量應先排除，否則存取閘道管理頁面時可能再次被送入代理。

DNS 要單獨畫出資料路徑

• 區域網路裝置通常會將查詢送往閘道的 53 連接埠，再由閘道本地解析服務決定使用哪個上游。
• 若核心 DNS 入站監聽 1053，可讓本地解析服務將指定網域轉送至 127.0.0.1:1053，不要讓 1053 再回到 53，形成迴圈。
• 中國大陸網域與區域網路網域可使用本地解析，需要代理的網域則交給遠端解析，並讓對應連線使用代理出站。
• 排除故障時，分別記錄查詢網域、回傳位址與實際出站。只看「DNS 有結果」無法判斷分流是否正確。

路由分流：先排除內網，再決定代理範圍

路由器上的分流需要同時考慮核心規則與防火牆規則。防火牆負責決定哪些資料進入核心，核心負責決定進入後使用哪個出站。只修改其中一層，容易出現兩類問題：原本應直連的區域網路流量被接管，或核心雖已設定代理規則，資料卻根本沒有進入透明入站。

最小規則集應先確保基礎網路可用，再加入網域分類。私有位址、迴環位址、鏈路本地位址、群播位址與路由器自身發起的必要連線，都應繞過透明入口。代理出站連線也必須排除，否則核心連往節點伺服器的連線會再次被自己捕獲，形成流量迴圈並迅速佔滿 CPU。

1. 先排除區域網路網段，例如 192.168.1.0/24，以及主路由、旁路由與網路儲存裝置的固定位址。
2. 排除節點伺服器位址，避免代理出站重新進入連接埠 12345。節點位址變更時，需要同步更新規則。
3. 保留 DHCP 使用的 UDP 67 與 68 連接埠，以及區域網路探索與管理所需的流量。
4. 再加入需要代理的網域或位址規則，未匹配的流量依預定策略直連，而不是預設全部阻斷。
5. 最後測試路由器自身更新、區域網路裝置互訪、一般網頁、影片與 UDP 應用程式。

上線前檢查：記錄、回復與故障定位

正式接管整個網路前，應準備一個不依賴代理的管理入口。最簡單的方法是保留主路由的固定管理位址，並準備一台可以手動填寫 IP、閘道與 DNS 的電腦。即使 DHCP 或旁路由失效，也能直接進入主路由還原設定。

記錄層級建議在除錯時使用 info，上線穩定後降至 warning。長期使用 debug 會產生大量寫入，對小容量快閃儲存空間不利。觀察重點不是每一筆連線記錄，而是連接埠占用、DNS 逾時、路由迴圈、出站握手失敗與程序反覆重新啟動。

是否值得部署，取決於裝置數量與維護意願。只有一兩台電腦與 Android 裝置時，分別使用 v2rayN、v2rayNG 或 v2flyNG 更直觀，故障範圍也較小。需要統一管理電視、遊戲裝置或其他無法個別設定代理的終端時，旁路由的價值才會明顯。

實際部署應以可回復為首要原則：先驗證節點，再執行核心；先開放本地 SOCKS 測試，再接入透明流量；先接管一台裝置，再修改 DHCP。只要將拓撲、DNS 與策略路由分開驗證，路由器直跑核心並不神秘，但確實比一般客戶端多出一整層網路維護工作。