本文适合准备把代理能力从单台设备迁移到家庭网关的用户。重点不是某个管理界面的安装步骤，而是厘清流量经过哪台设备、TCP 与 UDP 如何进入内核、DNS 查询由谁处理，以及故障时怎样保留直连回退路径。
先确定网关角色，再选择部署位置
路由器直跑 V2Ray 内核，通常是指在 Linux 网关上运行 Xray 或 V2Fly，并通过路由规则把指定终端的流量送入内核。Xray 与 V2Fly 是实际处理连接、协议和路由的核心程序；v2rayN、v2rayNG、v2flyNG 则是面向终端设备的客户端，不能直接等同于路由器网关方案。
主路由部署中，运行内核的设备同时承担拨号、DHCP、NAT、防火墙和默认网关职责。全部终端天然经过这台设备，策略覆盖完整，但配置错误也可能同时影响整个局域网。修改防火墙、DNS 或内核服务前，应先导出配置，并准备一台能够通过网线登录管理地址的设备。
旁路由部署会保留现有主路由，把另一台设备放在同一局域网内。终端可通过手动设置网关、DHCP 下发策略或主路由策略路由进入旁路由。它的优势是迁移范围可控，电视、办公电脑或测试设备可以分批切换；代价是链路更长，错误的网关与回程设置容易形成环路。
主路由直接部署
默认网关、DHCP、DNS 与透明代理集中在一台设备，策略入口统一，局域网终端不需要逐台修改。
适合:网络结构简单、能够维护防火墙与启动服务
旁路由分批接入
推荐保留原主路由，仅把测试终端或指定设备导向旁路由，出现故障时可快速恢复原网关。
适合:首次部署、需要低风险迁移与按设备控制
终端客户端并行
路由器维持普通网络，电脑使用 v2rayN，安卓设备使用 v2rayNG 或 v2flyNG，各自管理代理状态。
适合:设备数量少、需要每台设备独立切换节点
结论:首次部署先用旁路由验证链路
先只调整一台测试终端的默认网关和 DNS，确认 TCP、UDP、域名解析与回程都正常，再扩大接入范围，比直接改动全网默认网关更容易定位问题。
部署前检查架构、内存与系统能力
先核对架构与透明代理能力
安装包必须匹配处理器架构。常见软路由是 x86_64，小型 ARM 设备则可能是 aarch64；名称相近不代表二进制可以混用。执行 uname -m 确认架构，再检查系统是否提供 nftables、策略路由和 TPROXY 支持。只配置一个 SOCKS 入站端口并不能自动接管局域网流量。
以下基线适合用于理解资源需求：OpenWrt 23.05.5、Linux 5.15.167、4 核 x86_64 处理器和 512 MB 可用内存，可以承担普通家庭网络的规则匹配与数百兆转发。大型 geosite、geoip 数据和详细访问日志会增加内存与存储写入，低容量闪存设备应降低日志级别，并把轮转策略设为保留少量文件。
推荐方案:管理面与转发面分开验证
网关侧
- Xray 或 V2Fly 作为系统服务启动
- 透明入站监听 12345 端口
- 本地 DNS 入站监听 127.0.0.1:1053
- 保留管理地址和局域网网段直连
终端侧
- 先固定一台设备的网关地址
- DNS 指向承担分流的网关
- 分别测试网页、下载与 UDP 应用
- 记录切换前后的出口和延迟
内核能启动只说明配置语法通过，终端流量实际进入透明入站并完成回程，才算网关链路可用。
透明代理需要同时处理流量入口与回程
透明代理的核心任务是让原本不知道代理存在的终端，把连接交给 Xray 或 V2Fly。Linux 上常见入口是 TPROXY 或重定向。重定向更容易处理 TCP，TPROXY 可以保留原目标信息并覆盖 UDP，但需要额外的 fwmark、策略路由和本地路由表。具体能力取决于内核模块与防火墙框架。
一组完整规则至少要先排除路由器自身管理地址、局域网网段、组播地址、节点服务器地址和内核进程产生的连接，再捕获需要代理的 TCP 与 UDP。如果忘记排除节点服务器，内核发往节点的连接可能再次进入透明入口，表现为连接超时、CPU 占用升高或日志不断重复同一目标。
- 创建透明入站并固定监听端口，例如
12345，按实际需求启用 TCP 与 UDP。 - 建立策略路由表，把带有
0x1标记的数据包送到本机回环接口。 - 在防火墙链中先写直连排除项，再对目标流量设置 TPROXY 与标记。
- 配置内核路由规则，确保局域网、管理地址和节点地址走 direct 出站。
- 重启服务后检查监听端口、规则计数器和内核日志，而不是只看进程状态。
ip rule add fwmark 0x1 table 100
ip route add local 0.0.0.0/0 dev lo table 100
nft add rule inet proxy prerouting \
meta l4proto { tcp, udp } \
tproxy to :12345 meta mark set 0x1DNS 分流决定域名规则是否稳定生效
DNS 必须纳入网关规划
只有流量分流而没有 DNS 规划，常见结果是域名规则没有命中、解析结果与出口不一致，或者终端绕过网关直接查询外部 DNS。建议让受管终端统一把 DNS 指向网关的 53 端口，再由本地 DNS 服务按域名类别选择直连解析或转发到内核的本地 DNS 入站。
一种清晰的结构是：局域网终端查询网关 53 端口，dnsmasq 负责本地域名与 DHCP 主机名；需要经内核处理的查询转发到 127.0.0.1:1053；Xray 或 V2Fly 再按 DNS 规则选择出站。必须避免把 1053 的上游重新指回 53，否则会形成递归循环。
| 检查项 | 建议设置 | 异常表现 |
|---|---|---|
| 终端 DNS | 指向网关 LAN 地址的 53 端口 | 域名规则偶发失效或出口不一致 |
| 内核 DNS 入站 | 仅监听 127.0.0.1:1053 | 端口暴露到局域网或被其他设备直接调用 |
| 缓存位置 | 明确由 dnsmasq 或内核承担主要缓存 | 修改规则后仍返回旧地址 |
| IPv6 查询 | 与 IPv6 路由和代理策略同时启停 | 终端优先使用未纳入策略的 IPv6 出口 |
在常见 OpenWrt 管理界面中，可从「网络」→「接口」→「LAN」→「DHCP 服务器」→「高级设置」检查下发给终端的 DHCP 与 DNS 参数。不同系统版本的项目名称可能略有差异，修改后应让测试终端重新获取租约，并用系统解析命令确认实际 DNS 服务器，而不是根据界面配置推断。
结论:DNS 与透明代理必须成对验收
测试时同时记录域名解析结果、命中的路由规则和实际出口。只验证网页能否打开，无法发现 DNS 绕行、缓存未刷新或 IPv6 未被接管的问题。
性能测试要区分内核负载与网络质量
性能评估要覆盖完整转发链路
网关性能不能只看处理器核心数。加密算法、连接数量、规则集大小、日志级别、网卡驱动和硬件中断分配都会影响吞吐。开启透明代理后，部分硬件加速或流量卸载可能绕过防火墙规则；如果出现部分连接不受策略控制，应先关闭相关卸载功能再复测。
一组参考测试使用 4 核 N5105、8 GB 内存、千兆有线局域网和 500 Mbps 下行线路，测试终端与网关均使用有线连接。相同节点、相同时间段下，主路由直接转发测得 438 Mbps，经过同网段旁路由测得 421 Mbps；持续传输时内核进程占用约 118% 单核计量，网关总 CPU 占用约 34%。这些数字只用于说明测量方法，不能替代本地线路实测。
- 先测不经过代理的局域网吞吐，排除网卡协商和线材问题。
- 再测直连外网速度，记录延迟、丢包、下载和上传基线。
- 启用透明代理后使用同一终端、同一节点和同一测试目标复测。
- 持续测试至少 5 分钟，同时观察 CPU、内存、温度和连接数。
- 分别测试 TCP 下载、网页短连接和需要 UDP 的应用，避免单项结果代替整体判断。
如果速度下降但 CPU 占用不高，应优先检查节点质量、MTU、DNS 和回程路径；如果单个核心持续接近满载而其他核心较空，则瓶颈可能来自单连接处理或中断分配。旁路由比主路由多出的一个转发环节通常不会自动造成显著降速，错误的双重 NAT、百兆端口或无线回程更值得先排查。