路由器部署的难点不是启动内核,而是让流量经过正确的网关、解析器与防火墙规则。本文面向已有可用节点、准备接管部分局域网设备的用户,对比主路由与旁路由,给出地址规划、透明代理与 DNS 验收顺序。先用一台设备完成闭环,再决定是否扩大接管范围。
一、架构选择:主路由部署还是旁路由部署
Xray 与 V2Ray 是代理内核,不是完整的路由器系统。内核运行后,还需要操作系统完成转发、防火墙接管与服务管理。固件中的管理界面可以生成配置,但界面选项、规则文件和实际运行的内核版本必须相互匹配,不能只看页面上是否显示“已启动”。
旁路由:先接管单台测试设备
推荐保留现有主路由的拨号、无线和 DHCP。另用 Linux 设备承担代理与 DNS,通过手动设置测试设备网关逐步验证。优势是回退范围清楚;代价是必须处理同网段转发、返回路径与 IPv6 绕行。
适合:已有稳定主路由、希望分批接入设备的家庭或小型局域网。
主路由:统一接管出口
在承担互联网出口的路由器上运行内核,网关与防火墙集中管理,流量路径较直接。代理服务、规则更新或资源不足也更容易影响全网,需要准备本地管理入口和可恢复的配置备份。
适合:熟悉路由系统、需要统一策略且设备资源充足的环境。
判断:先确认回退方式,再改全网网关
首次部署只修改一台测试设备。确认将网关和 DNS 改回主路由后可以恢复原有联网,再继续配置透明代理;不要一开始就向整个 DHCP 地址池下发旁路由地址。
内核按节点要求选择。Xray 与 V2Fly 维护的 V2Ray 在协议、传输和配置字段上存在差异,尤其不能把包含 REALITY 等特定功能的配置直接交给不支持它的内核。v2rayN 是桌面客户端,v2rayNG 与 v2flyNG 是 Android 客户端;它们能帮助验证节点,但不是路由器上的转发服务。
二、地址规划:网关、DNS 与返回路径分别确认
下面是一组用于说明的静态地址,不是所有网络通用的默认值。部署前先核对实际网段、DHCP 地址池和已有设备,避免地址冲突。旁路由地址应固定,并排除在动态分配范围之外,或在主路由中为它设置静态租约。
两种架构的网关分工
主路由运行内核
- 终端默认网关保持为 192.168.10.1。
- 终端 DNS 指向主路由提供的解析服务。
- 在主路由检查转发链与本机输出链,区分两类流量。
旁路由运行内核
- 测试设备网关设为 192.168.10.2。
- 测试设备 DNS 设为 192.168.10.2。
- 旁路由自身默认路由指向 192.168.10.1,并开启必要的 IP 转发。
网关决定数据包的下一跳;DNS 决定域名向谁解析。只改其中一项,不能视为完成接管。
单网口、同网段旁路由的直连流量可能从旁路由转发到主路由,再由主路由直接返回终端,形成非对称路径。应结合防火墙状态跟踪决定采用受控源地址转换,还是调整拓扑以保持路径对称;同时检查 ICMP 重定向是否使终端绕过旁路由。不要把“开启 NAT”当作所有故障的统一答案。
三、透明代理:内核监听不等于流量已接管
显式代理要求应用主动连接 HTTP 或 SOCKS 代理端口。透明代理则由网关截获符合条件的流量,将其交给内核,并保留目标地址供路由判断。只配置一个 SOCKS 入站,即使设备网关已经指向旁路由,也不会自动让普通应用流量进入这个入站。
| 接管方式 | 配套条件 | 检查重点 |
|---|---|---|
| TCP 重定向 | 内核透明入站与防火墙重定向规则配套 | 常用于 TCP;不能顺带认为 UDP 已被接管 |
| TPROXY | 系统支持、透明监听、流量标记与策略路由配套 | 分别验证 TCP 和 UDP,并检查标记是否冲突 |
| 显式代理测试 | 应用指定内核已配置的 HTTP 或 SOCKS 监听 | 可隔离节点与出站问题,但不能证明透明转发正常 |
- 先验证出站:用同一节点在客户端确认基本可用,再检查路由器上的时间、证书验证、服务器域名解析与连接日志。桌面可用不代表路由器网络条件完全相同。
- 再验证入站:核对监听地址、协议和端口,确认防火墙把流量交给正确的透明入站,而不是误送到显式代理端口。
- 最后加拦截:先限定测试设备源地址,再逐步增加目标范围。TPROXY 需要相应策略路由,只有防火墙规则而没有路由配套时仍可能断流。
- 排除代理环路:内核自身建立的出站连接不能再次被接管。通常通过专用标记、进程身份或目的地址排除实现,具体方式需与部署方案一致。
局域网管理地址、广播、多播及其他应直连的网段,应在防火墙接管层和内核路由层分别考虑。节点服务器 IP 的排除规则还要考虑域名解析结果变化。使用基于 nftables 的防火墙环境时,不要把旧的 iptables 脚本直接叠加运行;重复接管与规则顺序错误会让故障变得难以复现。
四、DNS 接管:端口、分流与启动解析要闭环
DNS 接管包含终端查询、路由器本地转发、上游解析三个环节。终端把 DNS 指向旁路由,只能约束遵循该设置的请求。应用内置的加密 DNS 不会因为拦截普通 53 端口就自动改用你的解析器,应单独核对浏览器与应用设置。
- 监听端口:常规 DNS 服务使用 UDP/TCP 53。如果系统解析服务已经监听 53,可让另一解析组件使用本机 5353 端口,再由前者转发;这些端口是规划示例,须以实际监听配置为准。
- 域名分流:为需要直连与需要代理的域名安排合适的上游,并确认发往上游的流量走预期出站。仅把上游地址改成公共解析器,不能证明请求经过代理。
- 启动解析:如果节点服务器地址是域名,必须先有可用的解析路径。不要让节点域名只能依赖一条尚未建立的代理连接解析。
- 防止循环:本地 DNS 转发给内核后,内核不能又把同一查询送回本地原入口。检查每一跳的地址、端口和出站标签。
- 域名与 IP 匹配:
domainStrategy影响路由判断时是否以及何时解析域名,不等于系统全部 DNS 请求都会被接管。其取值和行为应按所用内核版本核对。
如果使用 geosite、geoip 等规则资源,还需保证资源文件与配置引用一致,并检查更新是否成功。嗅探可以在部分连接中辅助恢复域名信息,但不能保证识别所有流量,也不能替代 DNS 路径设计。测试分流时,应同时看域名命中记录和实际出站标签。
# 在安装了 dig 的测试设备执行;域名仅用于连通性测试
dig @192.168.10.2 example.com A
dig @192.168.10.2 example.com AAAA
dig @192.168.10.2 example.com A +tcp
这三条查询分别检查 IPv4 记录、IPv6 记录和 TCP DNS。能收到答案只说明解析服务有响应;要确认查询发往哪个上游、走哪条出口,仍需结合路由器日志或受限抓包观察。修改解析设置后应清理终端与路由器缓存,避免旧答案掩盖配置变化。
五、部署顺序:先单设备验证,再下发 DHCP
路由器上的配置不是把桌面导出文件原样复制过去。监听地址、文件路径、用户权限、资源文件位置和透明入站都会变化。订阅地址也不等于可以直接启动的内核配置;是否能导入、如何生成出站,取决于管理层的实现。
- 记录基线:备份网络、DHCP 与防火墙设置,记录主路由管理地址。确认测试设备在原网关下可以正常解析域名、访问网页和访问局域网设备。
- 确认运行环境:选择与处理器架构匹配的内核程序,检查系统时间、可写存储和服务权限。规则资源占用与连接数会影响内存,不以安装包大小推断运行需求。
- 独立启动内核:先检查配置语法与启动日志,再验证节点连接。内核配置验证命令在不同发行版本间可能有差异,应先查看随程序提供的帮助。
- 限定测试范围:仅为 192.168.10.100 设置网关与 DNS,并只接管该源地址。分别测试直连站点、代理站点和局域网服务。
- 补齐异常策略:明确节点不可用时是阻断还是允许特定流量直连;DNS 故障、内核停止和设备重启都要测试,不能只测正常状态。
- 最后扩展设备:确认稳定后再调整 DHCP。OpenWrt 的 LuCI 界面通常可在「网络」→「接口」→「LAN」→「DHCP 服务器」中检查分配设置,具体字段随版本变化;已有终端需要重新获取租约才会采用新值。
六、验收与排障:按路径定位,不只看出口地址
出口地址变化只能证明某一次请求走过某条路径,不能证明 DNS、UDP、IPv6 和全部应用都被正确接管。验收应保留正常与故障两组结果,并把终端、网关、DNS、内核出站分开检查。
# 在 Linux 路由设备执行;需具有相应查看权限
ip -4 route
ip -6 route
ip rule show
ss -lntup
上述命令用于查看 IPv4 路由、IPv6 路由、策略路由规则和监听端口;精简系统可能需要另装对应工具。检查时对照自己的地址规划,不要仅凭输出里出现一个端口就判断部署完成。若日志包含订阅地址、访问凭据或设备标识,分享前应先删除敏感内容。
旁路由能联网,为什么其他设备一改网关就断网?
先将测试设备网关恢复为 192.168.10.1 确认基线,再检查旁路由的 IP 转发、转发链放行和返回路径。旁路由自身访问互联网走本机输出路径,并不能证明它可以转发终端数据。
网页能打开,语音或游戏却连接失败?
查看对应应用是否依赖 UDP,核对透明入站、防火墙与节点出站是否支持并实际接管 UDP。仅使用 TCP 重定向时,网页测试可能成功;不要据此判断 UDP 已通过。
改了 DNS,检测结果为什么还是原来的解析器?
重新获取 DHCP 租约并清理缓存,检查浏览器安全 DNS、应用内置解析和 IPv6 下发的 DNS。随后使用指定服务器的 dig 查询,再从网关观察上游请求,区分终端绕行与解析器转发行为。
停止代理以后,全家设备都无法联网怎么办?
先把测试设备或 DHCP 下发的网关、DNS 恢复到原方案,再解除对应接管规则。检查是否仍把流量送入已关闭的监听端口,以及 DNS 是否仍依赖已停止的内核;恢复后重新获取租约。
验收结论:一项通过,不替代整条链路通过
至少分别记录直连、代理、DNS、UDP、IPv6 和停止内核后的行为。只有这些结果都符合事先定义的策略,才适合把单设备测试扩展为整个局域网的默认出口。