本文適合已能維護 OpenWrt,並希望讓電視、遊戲機及其他區域網路裝置統一套用代理規則的使用者。內容涵蓋主路由與旁路由的選擇、V2Ray 程序部署、REDIRECT 與 TPROXY 接管、DNS 轉送、迴圈規避及故障定位;讀完即可判斷現有硬體是否適合,並取得一套可分階段驗證的實施順序。
先判斷使用主路由還是旁路由
在路由器上執行 V2Ray,重點不只是複製一個可執行檔,而是決定由誰負責區域網路裝置的預設閘道、DNS 與防火牆。主路由方案由一台 OpenWrt 同時負責撥號、NAT、DHCP、DNS 與透明代理,路徑最短,但設定錯誤會直接影響全家的網路。旁路由方案則保留現有主路由,只讓指定裝置將閘道與 DNS 指向 OpenWrt,變更範圍較小,也更適合首次測試。
旁路由並不等同於「旁路監聽」。如果終端的預設閘道仍是原本的主路由,而 OpenWrt 又不在實際轉送路徑上,它就看不到需要接管的封包。最明確的做法是手動為測試終端設定旁路由位址,例如主路由為 192.168.1.1、旁路由為 192.168.1.2,再將測試終端的閘道與 DNS 都設為 192.168.1.2。驗證完成後,再透過主路由 DHCP 依裝置下發。
OpenWrt 主路由
所有轉送流量都會自然經過本機,DHCP、DNS 與防火牆規則集中管理。更新設定前,應保留可直接進入管理頁面或主控台的復原途徑。
適合:熟悉防火牆,需要全網統一策略
OpenWrt 旁路由
推薦先讓一台電腦或一組裝置改用旁路由閘道,問題不會立即擴散到所有終端,適合逐步驗證 TCP、UDP 與 DNS。
適合:首次部署,需要依裝置遷移
終端獨立用戶端
Windows 可使用 v2rayN,Android 可依核心需求選擇 v2rayNG 或 v2flyNG,不必變更家庭網路的閘道架構。
適合:裝置數量少,不需要代理電視等終端
硬體、系統與目錄準備方式
核心必須與路由器的 CPU 架構一致。常見架構包括 arm64、armv7、mips 與 x86_64,不能只根據裝置品牌判斷。可透過 ubus call system board 查看系統資訊,再用 uname -m 確認核心回報的架構。若檔案上傳後執行時顯示 not found,即使檔案確實存在,也應優先檢查架構與動態連結相依性。
建議將程式、設定與執行資料分開:可執行檔放在 /usr/bin/v2ray,主要設定放在 /etc/v2ray/config.json,日誌則依需求寫入系統日誌或容量充足的持久化目錄。不要持續把詳細存取日誌寫入空間有限的快閃記憶體;排錯時暫時提高日誌層級,確認穩定後恢復為 warning 或 error。
| 檢查項目 | 最低檢查方式 | 未達要求時的表現 |
|---|---|---|
| CPU 架構 | uname -m |
程式無法啟動或回報格式錯誤 |
| 可用記憶體 | free -m |
規則載入失敗、程序遭系統終止 |
| 系統時間 | date |
TLS 連線因憑證有效期間不符而失敗 |
| 連接埠遭佔用 | ss -lntup |
入站監聽失敗、DNS 無法繫結 |
| 持久化儲存空間 | df -h |
升級或寫入日誌後剩餘空間不足 |
結論:先保留資源餘裕,再考慮全面接管
只啟動一個核心,不代表硬體足以承擔全網轉送。若裝置長期只剩十幾 MB 可用記憶體,或 CPU 在一般下載時持續滿載,應保留原本的主路由,先從單一終端進行旁路測試,而不是直接遷移所有 DHCP 用戶端。
設定檔、服務與啟動順序
設定應先透過核心內建的測試命令檢查,再交由服務管理器啟動。不同 V2Ray 5 系列建置版本的命令參數可能略有差異,常見檢查形式是 v2ray test -c /etc/v2ray/config.json。如果目前的建置版本不識別該參數,應先執行 v2ray help 查看實際命令,不要在語法錯誤的狀態下反覆重新啟動服務。
透明代理入站通常使用 dokodemo-door,監聽從區域網路轉送過來的 TCP 與 UDP。以下只展示入站的關鍵段落,出站的伺服器位址、使用者識別碼、傳輸層與 TLS 參數必須依實際節點填寫。範例連接埠 12345 也必須與防火牆規則一致。
{
"log": {
"loglevel": "warning"
},
"inbounds": [
{
"tag": "transparent-in",
"listen": "0.0.0.0",
"port": 12345,
"protocol": "dokodemo-door",
"settings": {
"network": "tcp,udp",
"followRedirect": true
},
"sniffing": {
"enabled": true,
"destOverride": ["http", "tls"]
},
"streamSettings": {
"sockopt": {
"tproxy": "tproxy"
}
}
}
]
}
確認架構
透過終端機執行
uname -m,下載與架構一致的 V2Ray 核心,並確認 OpenWrt 具備足夠的持久化儲存空間與可用記憶體。放置檔案
將程式放到
/usr/bin/v2ray,設定放到/etc/v2ray/config.json,再執行chmod 755 /usr/bin/v2ray。檢查設定
先執行設定測試命令,再以前景模式啟動一次並觀察日誌。確認節點出站成功後,才建立開機服務並設定異常重新啟動策略。
開放轉送
進入 OpenWrt「網路」→「防火牆」,檢查 LAN 區域的轉送設定;旁路由還需確認核心轉送參數已啟用。
單機試用
只將一台測試電腦的閘道與 DNS 改為旁路由位址,分別驗證網頁、影片、軟體下載及需要 UDP 的應用程式。
逐步遷移
穩定執行後,再從「網路」→「介面」→「LAN」→「DHCP 伺服器」調整閘道與 DNS 下發設定,避免一次影響所有裝置。
REDIRECT 與 TPROXY 兩種接管方式
REDIRECT 的做法是將經過路由器的 TCP 連線重新導向至本機監聽連接埠。它容易理解,適合先驗證網頁與一般 TCP 應用程式,但無法完整支援 UDP 透明代理。若家庭裝置涉及即時通訊、部分 DNS 流量或依賴 UDP 的應用程式,最終通常需要 TPROXY。
TPROXY 不會直接改寫原始目標位址,而是為封包設定標記,再由策略路由將已標記的流量送往本機透明代理連接埠。典型組合是防火牆標記 0x1、策略路由表 100、監聽連接埠 12345。V2Ray 出站通訊端也應設定獨立標記,並在接管鏈中排除,否則核心發出的連線會再次進入自身,形成迴圈。
| 方式 | TCP | UDP | 部署複雜度 | 建議用途 |
|---|---|---|---|---|
| REDIRECT | 支援 | 不適合作為完整方案 | 較低 | 先驗證 TCP 連線與分流規則 |
| TPROXY | 支援 | 支援 | 較高 | 長期接管區域網路 TCP 與 UDP |
OpenWrt 23.05 及後續系列預設使用 fw4 與 nftables。舊教學中的 iptables 命令不能直接與 nftables 規則混用,否則可能出現命令執行成功,封包卻未進入預期鏈的情況。部署時應在「網路」→「防火牆」確認目前的後端,並使用 nft list ruleset 查看實際載入結果。
策略路由的核心關係如下,命令用於說明標記與路由表的對應方式。正式使用時,應將其放入可隨介面重新連線而恢復的腳本,並檢查目前系統是否已存在同名規則。
ip rule add fwmark 0x1 table 100
ip route add local 0.0.0.0/0 dev lo table 100
ip rule show
ip route show table 100
- 排除路由器自身的 LAN 位址、迴環位址、群播位址與保留位址,避免管理頁面及區域網路服務被送入代理。
- 排除代理伺服器的實際 IP,否則建立代理通道的連線會再次命中透明代理規則。
- 先在 prerouting 路徑接管 LAN 轉送流量,不要一開始就接管路由器所有 output 流量。
- IPv4 與 IPv6 是兩套路徑;尚未設定 IPv6 分流時,應明確決定保留直連,或暫時不要向 LAN 下發相關路由。
結論:先用 REDIRECT 驗證,再切換至 TPROXY
第一階段只接管一台測試終端的 TCP,可快速確認節點、路由與迴圈排除是否正確;第二階段再加入 UDP、策略路由與 DNS,排錯範圍會明顯小於一次載入所有規則。
DNS 必須與流量路徑一併設計
透明代理成功,不代表 DNS 已正確運作。若終端仍直接詢問主路由或網路業者提供的解析伺服器,網域分流與實際連線路徑可能不一致。旁路由測試時,閘道改為 192.168.1.2,但 DNS 仍是 192.168.1.1,就是最常見的半接管狀態。
V2Ray 設定中的 dns 物件用於核心解析與相關路由邏輯,但它不會因為存在於設定中,就自動成為 LAN 的 DNS 服務。若要讓區域網路裝置使用它,需要安排 DNS 入站,或讓 dnsmasq 依規則轉送到本機連接埠。本文範例可讓 dnsmasq 監聽 LAN 的 53 連接埠,再將需要交由核心處理的請求轉送到 127.0.0.1:1053。
統一入口
保留 dnsmasq 監聽 LAN 的 UDP/TCP
53連接埠,讓終端的 DNS 統一填寫 OpenWrt 的 LAN 位址,避免裝置繞過旁路由查詢。建立轉送
為 V2Ray 設定本機 DNS 入站,例如監聽
127.0.0.1:1053,並確保該連接埠未被其他解析服務佔用。區分路徑
本地域名與區域網路主機名稱繼續由 dnsmasq 處理,需要代理解析的請求再轉交核心,避免家庭裝置名稱失效。
阻斷迴圈
防火牆規則排除路由器發往上游 DNS 的連線,避免
53連接埠請求被透明代理規則重複攔截。逐項驗證
先在路由器上執行解析查詢,再從測試終端查詢同一網域,最後檢查核心日誌與 nftables 計數器是否同時變化。
依連線路徑逐段排查常見故障
路由器透明代理包含終端、閘道、防火牆、策略路由、V2Ray 入站、V2Ray 出站與 DNS 等多個環節。最有效的排錯方式不是頻繁更換節點,而是從終端一路逐段確認到出站。先檢查終端能否存取 OpenWrt 管理位址,再檢查預設閘道與 DNS,接著觀察 12345 是否正在監聽、規則計數器是否增加,以及核心日誌是否產生對應連線。
如果規則計數器始終為零,問題通常出在終端閘道或防火牆接管範圍;如果計數器增加但核心沒有日誌,請檢查策略路由與監聽位址;如果核心收到請求卻無法出站,再檢查系統時間、節點參數、路由規則及代理伺服器 IP 排除設定。先將故障定位到某一段路徑後再修改,可避免多個變數同時改變。
旁路由可以上網,卻完全沒有代理效果?
先在終端查看預設閘道,確認確實是旁路由位址;再執行 nft list ruleset 查看接管鏈計數器。計數為零時,不要先修改 V2Ray 設定,應檢查 DHCP 下發、靜態閘道與 LAN 轉送。
網頁可以開啟,部分應用程式卻一直連線失敗?
先判斷發生問題的應用程式是否依賴 UDP。只設定 REDIRECT 時,TCP 網頁正常並不能代表 UDP 已被接管。切換至 TPROXY 前,請檢查 fwmark 0x1、路由表 100 及 12345 的 UDP 監聽狀態。
啟用規則後,路由器自身無法連上網路?
暫停透明代理鏈,確認網路恢復後檢查迴圈排除設定。代理伺服器實際 IP、路由器 LAN 位址、迴環網段及核心出站標記,都不應再次進入透明代理。
網域無法開啟,直接存取 IP 卻正常?
檢查終端 DNS 是否仍指向原本的主路由,並使用 ss -lntup 確認 53 與 1053 的監聽程序。接著核對 dnsmasq 的轉送目標,不要讓同一請求在兩個服務之間循環轉送。
重新啟動後又失效,該檢查哪些地方?
分別確認 V2Ray 服務、nftables 接管規則、ip rule 與路由表 100 是否已恢復。網路介面重新連線也可能清除暫時的策略路由,因此規則應由系統服務或熱插拔流程重建。
上線前的最小驗收清單
家庭網路的驗收重點是可復原、可定位及可逐步擴大範圍。修改設定前,應備份 OpenWrt 設定與 V2Ray 設定,保留一台不經過旁路由的管理裝置,並記錄停用透明代理規則的命令。即使分流或 DNS 設定有誤,也能進入管理介面復原。
長期執行時只保留必要日誌。每次升級核心前,先在獨立連接埠測試新程式與現有設定是否相容,再替換服務檔案。設定檔、地理規則資料與程式版本應作為一組管理,避免程式更新後仍載入不相容的舊欄位。
- 測試終端的預設閘道與 DNS 都指向預期的 OpenWrt 位址。
- 路由器本機管理頁面、印表機、儲存裝置及其他區域網路位址維持直連。
- 分別測試 TCP 與 UDP,不要以網頁能開啟取代 UDP 驗收。
- 重新啟動路由器後,V2Ray 程序、監聽連接埠、防火牆鏈與策略路由都會自動恢復。
- 停用透明代理後,區域網路能回到一般直連狀態。
- 將日誌層級恢復為日常設定,並維持快閃記憶體空間與可用記憶體穩定。
最終判斷:是否值得部署取決於裝置涵蓋範圍
需要統一接管電視、遊戲機與多台家庭裝置時,OpenWrt 透明代理能減少逐台設定;若只有少量 Windows 或 Android 裝置,使用 v2rayN、v2rayNG 或 v2flyNG 通常更直接,也更容易個別排錯。