本文面向已经能维护 OpenWrt、希望让电视、游戏机和其他局域网设备统一执行代理规则的用户。内容覆盖主路由与旁路由选择、V2Ray 进程部署、REDIRECT 与 TPROXY 接管、DNS 转发、回环规避及故障定位；读完可判断现有硬件是否适合，并得到一套可分阶段验证的实施顺序。
先判断主路由还是旁路由
先确认 OpenWrt 位于转发路径
在路由器上运行 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 通常更直接，也更容易单独排错。