在路由器部署的關鍵,不是把桌面用戶端搬進設備,而是讓核心、系統路由、防火牆與 DNS 協同運作。本文適合已有可用連線設定、想讓區域網路裝置統一分流的使用者:先分清主路由與旁路由,再確認處理器架構和資源餘裕,最後用一台測試裝置驗證轉送路徑,避免一次更動全網閘道後失去排錯管道。
路由器執行的是核心,不是桌面用戶端
v2rayN 是桌面端的設定與連線管理用戶端,v2rayNG 是使用 Xray 核心的 Android 用戶端,v2flyNG 則使用 V2Fly 核心。這些用戶端提供訂閱管理、設定檔產生與操作介面;路由器通常直接執行 Xray 或 V2Fly 命令列程式,並由韌體的服務管理機制負責啟動。用戶端介面中的「系統代理」開關,無法直接轉換成路由器的全網代理功能。
核心負責接收入站連線、套用路由規則並建立出站連線。至於哪些終端流量會進入核心,仍由系統的轉送、防火牆與策略路由決定。只啟動程序,即使日誌顯示監聽成功,也不代表同網段的電視、電腦或其他裝置已經經過代理。
- 應用程式明確設定代理:在支援代理的應用程式中填入路由器位址與 SOCKS 或 HTTP 連接埠,先測試單一應用程式,影響範圍較小。
- 透明代理接管:透過重新導向、TPROXY 等機制,將指定流量交由核心處理;需要搭配系統模組、防火牆規則與入站設定。
- 依裝置分流:依終端位址或網段決定是否接管,再由核心的網域、IP 等規則決定實際出站路徑。
主路由與旁路由:先確認故障影響範圍
主路由通常負責撥號、位址分配、預設閘道與防火牆,部署集中,流量路徑也較直接。但升級核心、修改轉送規則或記憶體耗盡,都可能影響整個區域網路。旁路由將代理功能移至另一台設備,方便保留主路由原有的基本上網能力;代價是必須更仔細規劃回程路徑、位址分配與 DNS。
旁路由:先連接一台測試裝置
建議保留現有主路由的撥號與 DHCP 功能,只修改測試裝置的閘道或應用程式代理設定。發生問題時,將這台裝置切回主路由即可逐項驗證,也不會直接影響其他裝置。
適用情況:已有穩定的主路由、初次嘗試閘道分流,或需要明確的復原方式
在主路由直接執行核心
流量接管點與出口集中在同一台設備,方便統一管理轉送;但必須預留管理管道,並確認 CPU、記憶體、儲存空間與韌體模組足以負擔額外工作。
適用情況:熟悉韌體防火牆、能還原設定,且可安排維護時段
範例架構:保留主路由,單獨測試旁路由
主路由:192.168.10.1
- 繼續負責網際網路出口與 DHCP。
- 為旁路由保留 192.168.10.2,避免位址衝突。
- 暫不變更其他終端的預設閘道。
旁路由:192.168.10.2
- 預設路由指向 192.168.10.1。
- 需要轉送流量時,啟用 IP 轉送並設定防火牆。
- 測試裝置依照方案使用指定的閘道與 DNS 服務。
以上位址僅為同一子網路的範例;套用前請檢查現有網段、DHCP 位址池與已設定的靜態位址。
單網路埠的旁路由也能運作,但不能忽略回程路徑:直連流量可能由主路由直接返回終端,繞過旁路由。是否需要來源位址轉換,應依連線追蹤、防火牆與回程路由判斷,不宜照抄通用規則。多網路埠設備也不會自動解決設定問題,關鍵仍是清楚掌握每一跳的入口、出口與返回路徑。
硬體選擇:確認架構、記憶體餘裕與儲存寫入
先查詢設備資訊,再選擇可執行檔。處理器商品名稱不足以判斷相容性:必須分辨 ARM 的位元數與指令集,以及 MIPS 的位元組序與建置需求。硬體支援 64 位元,不代表韌體使用者空間也是 64 位元;動態連結程式還會受到執行階段函式庫與載入器影響。遇到「無法執行」時,不應先懷疑節點或訂閱。
# 在設備終端查看系統與資源;不同韌體的命令選項可能有所差異
uname -m
uname -a
free -m
df -h
ip route show
ip -6 route show
| 檢查項目 | 實際確認內容 | 對選擇的影響 |
|---|---|---|
| 處理器與系統 | 例如 aarch64、armv7l、x86_64;同時確認韌體套件架構 | 決定可執行的核心版本,不能只依設備型號判斷 |
| 記憶體餘裕 | 分別觀察啟動前、載入規則後及連線增加時的 available 等指標 | 規則集、連線數量、DNS 快取及其他服務都會占用記憶體 |
| 可寫入空間 | 核心、規則檔、暫存更新檔與日誌所在分割區 | 下載新檔案及替換舊檔案可能需要額外空間 |
| 系統功能 | 防火牆後端、策略路由及所需的透明代理模組 | 決定實際的流量接管方式,不能只確認程式能啟動 |
| 網路與散熱 | 網路埠速率、驅動程式穩定性,以及持續負載下的溫度與 CPU 使用率 | 影響長期穩定性,不能只憑核心數量推估傳輸效能 |
採購新設備時,可先以 512 MB 或以上記憶體作為輕量閘道的初步篩選條件;多項服務同時執行時,則可考慮 1 GB 或以上。這是資源規劃建議,不代表核心的最低需求或效能保證。現有的小記憶體設備也可能執行精簡設定,但應減少不必要的規則與背景服務,並留意是否因記憶體不足而終止程序。不要把啟用交換空間當成長期容量不足的替代方案。
硬體選擇建議:先用目標規則集試跑,再決定是否更換設備
在同一台設備上記錄閒置時、載入規則後,以及日常多台裝置使用時的資源變化。若核心沒有錯誤但 CPU 持續忙碌,請檢查加密與轉送負載;若程序遭系統終止,先查看記憶體日誌。僅憑「節點連線很慢」不足以判斷路由器效能不足。
連接埠、DNS 與透明代理:分段驗證流量路徑
明確設定代理後能連線,是很有用的起點,但不能證明透明代理接管設定正確。建議先設定僅供測試的 SOCKS 入站,用單一應用程式驗證出站,再加入閘道轉送。以下三個連接埠僅為用途範例,並非任何用戶端或韌體的通用預設值;實際監聽設定應以設定檔與系統輸出為準。
- 檢查監聽範圍:若只監聽
127.0.0.1,其他區域網路裝置便無法直接連線。若確實需要提供區域網路代理,請綁定合適的位址並以防火牆限制來源,切勿將代理連接埠開放至網際網路。 - 排除代理本身的流量:接管規則須避免再次攔截核心建立的出站連線。依部署方式使用程序、使用者、流量標記或目標位址來排除,並確保可正常連線至伺服器位址。
- 分別處理 TCP 與 UDP:某種重新導向方式支援 TCP,不代表也會處理 UDP。TPROXY 還需要策略路由與相應模組,不能只新增一條連接埠轉送規則。
- 規劃 DNS 引導路徑:先確認由誰解析伺服器網域名稱,再決定應用程式網域查詢的路徑。若建立代理前必須先解析網域,而解析又只能透過尚未建立的代理,就會形成啟動相依循環。
- 單獨驗證 IPv6:若只設定 IPv4 規則,IPv6 連線可能走另一條路徑。請確認是否提供 IPv6 分流,並檢查終端收到的路由公告與 DNS 資訊。
遷移設定:複製連線參數,重新建立路由器本機設定
桌面端已可使用的節點可作為遷移參考,但不應直接完整覆蓋路由器設定。v2rayN 產生的執行設定可能包含本機連接埠、檔案路徑或用戶端管理欄位;訂閱內容也不一定是可直接執行的核心 JSON。請先拆分伺服器連線參數與本機執行參數,再依目標核心的設定規範重新建立設定。
- 記錄連線參數:位址、連接埠、協定、身分參數、傳輸方式與安全層。TLS 的 serverName、WebSocket 的 path 和 Host、REALITY 的伺服器公鑰與 shortId 等欄位,都應依實際方案逐一確認,不能互相替代。
- 確認目標核心:確認協定、傳輸方式與安全層的組合受到支援。訂閱能匯入某個用戶端,只能表示該用戶端能處理,不能保證另一個核心接受相同設定。
- 重新建立本機設定:設定監聽位址、入站連接埠、路由規則與 DNS;將規則檔路徑改為設備上有效的位置。確認執行使用者具有讀取檔案及執行必要操作的權限。
- 先檢查再啟用:使用核心的設定測試命令檢查欄位與參照檔案,再於前景檢視啟動日誌。測試通過只代表設定可載入,仍須驗證實際連線。
- 最後交由服務管理器啟動:使用韌體內建的服務管理器負責啟動與重新啟動,避免同時設定多個啟動入口。記錄備份檔位置、復原步驟與停止服務的方法。
# 假設可執行檔名稱為 xray,設定檔儲存在此路徑
# 先查看說明,確認目前建置版本支援的命令參數
xray help run
xray run -test -config /etc/xray/config.json
# 設定檢查通過後,在前景啟動並查看日誌
xray run -config /etc/xray/config.json
使用 V2Fly 時,應查閱該建置版本的說明,不要預設 Xray 的命令與欄位也適用於 V2Fly。訂閱自動更新也不是核心啟動後自然具備的功能,還需要受控的取得、轉換、設定檢查與替換流程。更新失敗時應保留上一份可用設定,不能用空白結果覆蓋正在使用的檔案。
常見故障:先找出問題所在,再修改設定
每次只變更一個項目。先確認設備本身能正常解析網域並建立出站連線,再測試核心連線,最後檢查終端到閘道的轉送路徑。若同時更換 DNS、路由規則與協定,即使連線恢復,也很難找出真正原因,更難確保重新啟動後仍能正常運作。
程式顯示無法執行,是不是下載錯了?
先執行 uname -m 並確認韌體套件架構,再檢查檔案執行權限、動態載入器與執行階段函式庫需求。「Exec format error」通常表示架構或檔案格式有誤,此時尚未進入連線階段,不必先修改伺服器端參數。
旁路由本身能連線,電腦設定為閘道後卻無法開啟網頁?
檢查 IP 轉送、防火牆轉送策略、預設路由與回程路徑。接著在電腦上明確連線至範例 SOCKS 連接埠 1080:若能正常使用,應優先檢查透明代理接管路徑,而非重新匯入節點。之後分別測試 DNS、TCP 與 UDP。
只有部分網站異常,需要更換協定嗎?
先確認規則是否命中、DNS 回傳結果與 IPv6 路徑。檢查是否有目標被錯誤地設為直連、UDP 未被接管,或發生路徑 MTU 問題。比較同一台終端使用明確代理與透明代理接管時的結果,比直接切換協定更有助於找出問題。
重新啟動後就失效,需要再加一個啟動指令碼嗎?
先查看服務狀態、啟動日誌與設定檔權限,再確認啟動時網路、時間同步及規則檔是否已就緒。避免重複啟動造成連接埠衝突;應修正現有服務的相依條件與設定路徑,而不是再啟動第二個程序。
正式上線前:確認連線可用,也能復原
擴大至更多終端前,先完成一次設備重新啟動、一次核心停止測試與一次設定復原測試。確認測試裝置能切回原本的主路由,管理頁面也始終可連線,再逐步調整 DHCP 配發策略;不要在同一次操作中首次接管全網並首次升級。