本文適合準備將 Xray 從單一裝置移至家用網路閘道的使用者。先了解主路由與獨立旁路由的差異，再透過固定網段說明閘道、DNS、透明代理入口及回程路徑。讀完即可規劃單一裝置的試行方式、找出需額外設定的轉送規則，並保留恢復主路由直連的操作途徑。
一、Xray 核心與路由器各自負責什麼
Xray 是處理代理協定、入站、出站與路由規則的核心，並非完整的路由器系統。將執行檔放進裝置，只解決「程式能否啟動」；裝置轉送、DNS 服務、防火牆接管及開機啟動，仍由作業系統與部署方案負責。v2rayN 是桌面用戶端，v2rayNG 是使用 Xray 核心的 Android 用戶端，不能把它們的安裝檔直接當成路由器服務安裝。
部署前先記錄 CPU 架構、系統版本、可用記憶體與剩餘儲存空間。韌體套件管理工具提供的軟體套件也可能依賴特定系統函式庫；不能只因檔名出現 ARM 就判定相容。以下以 OpenWrt 的網路管理邏輯為例，實際功能是否支援，請以裝置韌體和安裝套件為準。
- 系統層：網卡位址、預設路由、IP 轉送、IPv6 路由與防火牆。
- 接管層：將需要處理的 TCP 或 UDP 流量導入透明代理監聽連接埠。
- 核心層：
inbounds接收連線，routing.rules設定比對條件，outbounds定義代理或直連出口。 - 解析層：用戶端使用哪個 DNS、查詢如何分流，以及解析上游是否會再次被自身接管。
二、主路由直跑與旁路由的部署差異
主路由通常已負責撥號、DHCP、NAT 與防火牆。在這台裝置上執行 Xray，流量入口較集中，但規則設定錯誤可能影響整個區域網路。獨立旁路由方便只接管一台測試裝置，不過會多出一段轉送路徑，也增加回程路徑不對稱、重複 DHCP 和閘道設定錯誤的風險。
兩種部署方式：先確認裝置的預設閘道由誰提供
主路由執行 Xray
- 終端的預設閘道仍是主路由位址。
- 在轉送入口接管指定裝置或特定流量。
- 需評估撥號、無線網路與代理共同占用的資源。
- 修改防火牆前，先保留本機管理連線。
獨立旁路由執行 Xray
- 先將一台終端的閘道改為旁路由位址。
- 旁路由的預設路由指向主路由。
- 單網卡、同網段的方案需另外檢查回程路徑。
- 未經規劃，不要啟用第二個 DHCP 服務。
初次部署時先維持主路由服務不變，只讓一台裝置經由旁路由；驗證完成後再擴大接管範圍。
旁路由不一定要有兩個網路埠。單網路埠可在同一區域網路中收發流量，但不代表可以省略轉送規則。雙網路埠也不代表一定能正確隔離：若兩個介面都接在同一個橋接介面，實際上仍可能屬於同一個第二層網路。
三、以固定位址說明閘道與回程路徑
下表是用來說明的 IPv4 拓樸，不代表裝置預設值，也不是效能測試結果。請先確認這些位址未被占用，並將固定位址排除在 DHCP 動態分配範圍之外。測試終端只需修改自身設定，其他裝置仍沿用主路由。
| 裝置 | IPv4 位址 | 預設閘道 | DNS |
|---|---|---|---|
| 主路由 | 192.168.10.1/24 | 電信業者上游 | 依現有網路設定 |
| 旁路由 | 192.168.10.2/24 | 192.168.10.1 | 明確設定的 DNS 服務 |
| 測試終端 | 192.168.10.100/24 | 192.168.10.2 | 192.168.10.2 |
將終端的 DNS 設為 192.168.10.2，前提是旁路由確實在該位址的 53 埠提供 DNS 解析服務，並允許來自區域網路的查詢。只安裝 Xray 不代表自動具備這項服務。主路由與旁路由位於同一網段時，直接連線至主路由管理位址，通常會透過第二層網路傳輸，不會經過預設閘道。
單臂旁路由的直連轉送可能出現「終端經由旁路由送出流量，主路由卻直接回覆終端」的情況，進而影響具狀態防火牆或連線追蹤。來源位址轉換可讓回應封包返回旁路由，但會改變上游看到的來源位址，不能當成適用所有拓樸的通用開關。也要檢查 ICMP 重新導向是否讓終端改走主路由，以及防火牆是否允許流量從同一介面轉送。
- 在旁路由確認預設路由是否指向
192.168.10.1。 - 檢查是否已啟用 IPv4 轉送，以及轉送鏈是否允許測試終端的流量。
- 分別檢查代理流量與直連流量，不要以單次網頁連線代表所有路徑。
- 若 IPv6 仍使用主路由發布的預設路由，變更 IPv4 閘道不會自動接管 IPv6 流量。
四、透明代理入口與 Xray 路由分屬不同層
顯式代理需要應用程式主動連線至 SOCKS 或 HTTP 入口；透明代理則由網路規則將連線導入核心。只在 Xray 新增監聽埠，不會讓區域網路裝置自動使用。本文範例的 12345 只是選定的埠號，必須與實際透明代理入口及防火牆轉送目的地一致。
先在單一裝置測試顯式代理
建議先透過區域網路可連線的 SOCKS 或 HTTP 入站，測試節點、憑證與出站參數。限制來源位址，測試完成後關閉不再需要的入口。通過這一層測試，不代表透明代理已可正常運作。
適用情境：初次部署時，先排除節點與核心設定問題。
使用 REDIRECT 接管
常見方案用於 TCP 流量，且要求相應入站能取得原始目的位址。不能將 TCP 重新導向規則直接套用於所有 UDP 流量，也不能只設定 NAT 鏈就認定已涵蓋所有協定。
適用情境：已確認只接管 TCP，且韌體提供相應設定的環境。
使用 TPROXY 接管
可用於 TCP 與 UDP，但須仰賴核心支援、策略路由、流量標記及相應的透明通訊端設定。標記值、路由表與入站設定需要一起檢查。
適用情境：需要接管 UDP，且能維護策略路由的環境。
OpenWrt 22.03 起預設採用 firewall4 與 nftables。維護舊方案時，請先確認實際使用的規則後端；不要將舊版 iptables 指令碼直接加入新版韌體，再以命令結束碼判斷部署成功與否。透明代理入口也應排除核心自身發出的代理連線、管理位址及必要的本機服務，以免流量再次進入自身。
五、DNS 分流須配合連線路徑
終端查詢 DNS 的路徑，與終端連線至目的位址的路徑是兩回事。將閘道改為旁路由，不會自動接管瀏覽器內建的加密 DNS；將 DNS 指向旁路由，也不會自動變更預設閘道。試行期間須確認哪些裝置使用系統 DNS，哪些應用程式會自行解析。
- 入口：確認
192.168.10.2:53有服務監聽，且 TCP、UDP 查詢都能抵達。 - 上游：確認本機解析器會將查詢轉交給哪個服務；若上游透過代理存取，須避免代理連線本身依賴尚未就緒的同一條 DNS 路徑。
- 規則：
domainStrategy會影響路由比對時如何使用解析結果，並非區域網路 DNS 接管的總開關。 - 網域資訊：透明流量不一定帶有可供比對的網域名稱；嗅探也無法保證還原所有加密連線的網域。
- 快取：變更解析路徑後，先重新建立連線，再視需要清除終端與本機解析器的快取，避免舊記錄影響判斷。
若系統已安裝相應工具，可在測試終端執行下列兩個命令，分別測試一般 UDP 與 TCP 查詢。收到回覆只能確認這個 DNS 入口可用，無法證明查詢經過預期的上游；仍須查看解析服務記錄確認上游路徑。
dig @192.168.10.2 example.com A
dig +tcp @192.168.10.2 example.com AIPv6 也需要一併規劃。終端可能透過路由通告取得 IPv6 預設閘道與 DNS，應用程式也可能優先使用 AAAA 記錄。在完成 IPv6 接管前，應明確控制測試裝置的 IPv6 路徑並記錄設定；不要只因 IPv4 能連線，就宣稱整個網路已生效。
六、從一台終端開始部署
以下介面操作路徑以 OpenWrt 23.05 系列的標準 LuCI 繁體中文介面為例，自訂韌體的選單名稱可能不同。變更網路位址會中斷管理連線，操作前請準備有線連線，並記下主路由位址、原有 DHCP 設定與目前的設定備份。
-
記錄原有設定
進入「系統」→「備份／升級」，建立目前設定的備份。記下測試終端原本的閘道與 DNS，並確認仍可直接連線至主路由
192.168.10.1。 -
設定旁路由固定位址
進入「網路」→「介面」→「LAN」→「編輯」→「基本設定」，依範例設定靜態位址
192.168.10.2/24，並將 IPv4 閘道設為192.168.10.1。套用設定後，使用新位址重新登入。 -
避免重複分配位址
在旁路由進入「網路」→「介面」→「LAN」→「編輯」→「DHCP 伺服器」→「一般設定」，確認已勾選「忽略此介面」。同網段測試期間，保留主路由作為唯一的 DHCP 位址分配來源。
-
確認核心入口設定
先驗證 Xray 設定與節點連線，再啟用已規劃的透明接管規則。確認監聽埠、轉送策略、DNS 服務及排除程序自身流量的設定，不要直接複製其他裝置的整套防火牆指令。
-
只修改測試終端
將測試終端的閘道改為
192.168.10.2；確認 DNS 服務可用後，再將 DNS 指向該位址。分別測試網頁、UDP 應用程式、區域網路分享與路由器管理頁面。 -
確認無誤後再擴大範圍
重新啟動旁路由並再次測試。確認服務啟動順序、規則還原與 DNS 就緒後，再考慮透過 DHCP 選項 3 下發閘道、選項 6 下發 DNS；已取得租約的裝置須更新租約，並檢查實際取得的設定。
七、依症狀排除問題，避免同時變更多層設定
建議依序檢查：終端位址與路由、旁路由轉送、DNS、核心入口、代理出站。每次只變更一項，並記錄變更前後的記錄。以下命令用於 Linux 閘道唯讀檢查；部分精簡韌體可能需要安裝相應工具。
ip -4 route
ip -6 route
ip rule show
sysctl net.ipv4.ip_forward
ss -lntup
nft list ruleset變更閘道後，所有網頁都無法開啟？
先將測試終端的閘道改回 192.168.10.1，確認原本的網路正常。接著檢查旁路由的預設路由、IP 轉送及防火牆轉送計數；不要先更換節點。若 DNS 指向旁路由，也須確認 53 埠有服務在執行。
網頁能開，語音或遊戲卻無法連線？
確認實際部署的是否只有 TCP 接管，再檢查 UDP 入站、策略路由與出站支援狀況。透過應用程式記錄確認失敗的協定；TCP 網頁能正常使用，不代表 UDP 和 DNS 轉送也正常。
為什麼只有部分裝置經由旁路由？
逐一查看裝置實際使用的閘道與 DNS，不要只看 DHCP 管理頁面。靜態位址、舊租約、應用程式內建解析，以及 IPv6 預設路由都可能造成差異。先在同一台裝置上分別確認 IPv4 與 IPv6 路徑。
重新啟動後失效，手動啟動卻正常？
檢查服務啟動記錄，確認網路、時間同步與 DNS 是否先於代理連線就緒。確認防火牆重新載入後，接管鏈仍然存在；先處理相依順序，再設定有限次數的重試，避免以持續重啟掩蓋設定問題。
上線前，最後確認三項復原方式：終端可改回原本的閘道、仍可連線至主路由管理介面，以及旁路由停止服務後不會留下指向空埠的接管規則。CPU 架構、節點協定與線路條件差異很大，不能根據裝置標示的頻寬推估代理吞吐量；擴大接管範圍前，應以實際使用情境測試、資源使用量與連線記錄作為依據。