路由器與旁路由部署 V2Ray 核心：硬體選擇、透明代理與 DNS 分流

1. 硬體選擇：先確認架構，再估算可用記憶體

V2Ray 是專案與工具體系中常用的名稱。部署時應確認實際執行的是 V2Fly 的 v2ray-core，還是 Xray-core。v2rayN 是桌面圖形介面用戶端；v2rayNG 和 v2flyNG 是 Android 用戶端。路由器直接執行核心，不需要安裝這些圖形介面用戶端，也不能把用戶端安裝套件當成路由器的執行檔使用。

處理器架構決定程式能否執行。常見裝置包括 x86_64、aarch64、32 位元 ARM 與 MIPS；MIPS 還需要確認大小端序。處理器支援 64 位元，不代表韌體使用 64 位元使用者空間。選擇安裝套件時，應以韌體套件來源的架構資訊與核心發布說明為準。請先在裝置終端機查看以下資訊，再決定是否部署：

uname -m
cat /etc/openwrt_release
free -m
df -h

/etc/openwrt_release 僅適用於 OpenWrt；一般 Linux 可查看 /etc/os-release。應留意可用記憶體與可寫入的儲存空間，而不只是包裝標示的總記憶體。規則資料、DNS 快取、連線數量與記錄檔都會增加資源用量；核心能啟動，不代表高併發時仍穩定。

• CPU：核心數相同，不代表代理傳輸效能相同。請留意單核心負載是否接近滿載，並區分代理流量與一般轉發流量。
• 儲存空間：確認能容納核心、geosite/geoip 資料與更新暫存檔。不要長期將高頻除錯記錄寫入容量有限的快閃記憶體。
• 網卡：單網卡也能建置旁路由，但更仰賴路由設計；雙網卡有助於區分入口與出口，卻無法自動修正錯誤的政策路由。
• 系統：確認韌體提供所需的核心模組與套件。存在使用者空間程式，不代表系統支援 TPROXY 或 TUN。

2. 選擇核心：依節點設定與韌體整合情況決定

先確認節點需求，再看韌體能穩定維護哪些功能。協定、安全層與傳輸方式是不同面向：VLESS 本身不提供內容加密，REALITY 是相關安全機制，WebSocket 則是傳輸方式。不能只因訂閱中出現「V2Ray」，就認定兩種核心的所有設定欄位都能互換。

訂閱通常是節點來源，不等於可直接啟動的完整閘道設定。分享連結或 Base64 節點清單需要由相容的管理工具解析，再產生入站、出站、路由與 DNS 設定；若直接執行核心，則須準備相應格式的設定檔。服務名稱、檔案目錄與更新方式會隨韌體套件而異，請勿自行臆測。

3. 主路由器與旁路由：閘道路徑比裝置名稱重要

主路由器通常負責撥接、DHCP、NAT 與防火牆；在其上執行代理核心後，可以從統一的轉發入口處理流量。旁路由通常不負責連線撥接，必須確保目標裝置的流量確實經過旁路由。只把一台裝置接入同一個區域網路，不會自動接管其他終端。

例如，主路由器為 192.168.10.1，旁路由為 192.168.10.2，測試終端為 192.168.10.100。測試終端的預設閘道指向 192.168.10.2，旁路由的預設出口則指向 192.168.10.1。這只是 IPv4 網路拓撲範例，位址必須符合實際網段；旁路由位址也不能落在可能重複配發的 DHCP 位址池中。

1. 為旁路由設定靜態位址或 DHCP 靜態租約，確保重新啟動後位址不變。
2. 在測試終端手動設定閘道，並將 DNS 指向預計處理查詢的本機解析器。
3. 確認旁路由已啟用 IP 轉送、防火牆允許所需流量轉發，且回程流量處理正確。
4. 確認直連與代理都正常後，再修改 DHCP 配發的閘道選項；不要同時啟用兩個會互相爭用位址配發的 DHCP 服務。

4. 透明代理模式：REDIRECT、TPROXY 與 TUN 的取捨

透明代理是閘道接管連線的方式，不是節點協定。明確指定的 SOCKS 代理由應用程式主動連至代理連接埠；透明代理則透過防火牆、政策路由或虛擬網卡，將流量導入核心。建議先確認明確代理可正常連線，再處理透明接管，避免同時排查兩層問題。

以 TPROXY 為例，防火牆先為選定流量加上標記，再將連線交給透明入站；政策路由則負責把帶有標記的封包送入本機處理路徑。少了任何一個環節，都可能出現「規則計數增加，卻沒有連線記錄」的情況。透明入口可使用 12345 作為範例；它與應用程式測試用的 10808 是不同用途的連接埠，不能只改連接埠號碼就完成接管。

• 先排除：路由器管理位址、必要的區域網路目標、節點伺服器位址與核心自行發出的連線，避免形成代理迴圈。
• 區分流量鏈：終端轉發流量與路由器本機流量會經過不同入口。前者成功接管，不代表訂閱更新也會走相同路徑。
• 確認防火牆後端：OpenWrt 22.03 起常見的預設組合為 firewall4 與 nftables；較舊韌體可能使用 firewall3 與 iptables，規則不可直接混用。
• 保留管理方式：規則應可重複載入而不會重複堆疊，並提供明確的移除方式。遠端修改前，請保留另一條管理連線。

成功接管 UDP，不代表所有 UDP 應用程式都能正常使用。節點出站、伺服器與中間網路都必須支援相應流量；如果網頁可用，但語音或遊戲無法使用，應分別檢查 UDP 記錄與規則。硬體流量卸載也可能改變軟體規則可觀察到的路徑；診斷時可先停用卸載，再比較規則計數與連線行為。

5. DNS 分流：解析出口與連線出口需相互配合

DNS 分流至少涉及三個環節：終端將查詢交給哪個服務、本機解析器選擇哪個上游，以及解析器連線至上游時使用哪個出口。只在旁路由填入 DNS 位址，只完成第一步；若上游查詢仍經由不合適的路徑送出，可能會得到異常結果或持續逾時。

常見做法是在路由器保留 dnsmasq，負責 DHCP、區域網路名稱與快取；再依規則將部分查詢轉送至獨立解析入口或核心 DNS。核心中的 dns 設定不代表會自動對區域網路開放 DNS 服務連接埠，還須設定實際入口或 DNS 轉送機制。

1. 規劃單一上游方向：終端 → dnsmasq → 指定解析入口 → 上游。不要讓 dnsmasq 與核心 DNS 互相轉送相同類型的查詢。
2. 保留本機解析：區域網路主機名稱與內部網域應交由掌握這些記錄的解析器處理，不要一律轉送至公共上游。
3. 安排節點網域名稱解析：建立代理連線前，可能就需要解析節點伺服器的網域名稱；這條解析路徑不能依賴尚未建立的代理連線。
4. 處理 IPv6：檢查 DHCPv6、路由器公告與 AAAA 查詢的流向，讓 IPv6 連線策略符合解析結果。

假設 dnsmasq 已在 LAN 的 53 連接埠監聽，另一個解析入口可依實際支援情況綁定至 127.0.0.1:5353，再由 dnsmasq 轉送指定查詢。5353 也常用於 mDNS，使用前請檢查是否已被占用；兩個服務不能綁定相同的位址與連接埠。對外提供服務的入口也必須由防火牆限制來源，避免 WAN 端成為開放式解析器。

網域路由與 IP 路由也需要分開理解。透明連線進入核心時，可能只有目標 IP；嗅探功能可在支援的協定中提供網域線索，但無法涵蓋所有流量。geosite 用於網域分類，geoip 用於 IP 分類，兩者都需要相符的資料檔。路由規則通常依序比對；domainStrategy 會影響路由階段是否為 IP 規則解析網域，並不能取代終端的 DNS 設定。

6. 上線驗證：先測試單一裝置，再逐步擴大接管範圍

設定驗收時，應分別確認「核心可執行」、「節點可連線」、「終端流量已接管」與「DNS 結果符合預期」。不要在同一輪操作中同時升級韌體、更換核心、修改閘道並匯入新規則，否則記錄很難指出真正原因。

1. 備份：保存網路、防火牆、DHCP 與核心設定，記下主路由器管理位址及恢復直連的方法。
2. 測試設定：Xray 可使用下方指令檢查設定。V2Fly 的命令列參數應以目前版本的說明輸出為準，不要直接套用 Xray 指令。
3. 明確代理測試：只讓測試應用程式連線至 SOCKS 入口，確認節點連線、時間與憑證設定正確。
4. 透明代理測試：只接管測試終端，觀察防火牆計數、核心存取記錄與實際出口，並分別測試 TCP 及所需的 UDP 應用程式。
5. 持續觀察：檢查閒置、下載與多裝置存取時的可用記憶體、CPU、溫度及錯誤記錄，再擴大至更多終端。

# 設定檔路徑為本文範例，請依實際安裝位置調整
xray run -test -config /etc/xray/config.json

# 以下指令適用於具備相關工具的 Linux 環境
ip route
ip -6 route
ip rule
ss -lnptu
nft list ruleset

# 查詢範例：將位址改為實際處理 DNS 的裝置
nslookup example.com 192.168.10.2

部分精簡韌體需要另外安裝 ss 等診斷工具；找不到指令不代表服務故障。分享記錄前，請隱藏訂閱網址、驗證資訊與完整節點憑證。為了找出問題而暫時啟用詳細記錄後，請恢復較低的記錄層級，避免持續寫入儲存裝置或暴露存取記錄。