路由器与旁路由部署 V2Ray 内核概览:硬件选择、透明代理与 DNS 分流

1. 硬件选择：先确认架构，再估算可用内存

V2Ray 是项目与工具体系中的常用名称。部署时应明确实际运行的是 V2Fly 的 v2ray-core，还是 Xray-core。v2rayN 是桌面图形客户端；v2rayNG 和 v2flyNG 是安卓客户端。路由器直接运行内核，不需要安装这些图形客户端，也不能把客户端安装包当作路由器二进制文件使用。

处理器架构决定程序能否执行。常见设备有 x86_64、aarch64、ARM 32 位及 MIPS；MIPS 还需确认大小端。处理器支持 64 位不等于固件运行在 64 位用户空间，选择安装包时应以固件软件源的架构和内核发布说明为准。在设备终端先查看以下信息，再决定是否部署：

uname -m
cat /etc/openwrt_release
free -m
df -h

/etc/openwrt_release 仅适用于 OpenWrt；普通 Linux 可查看 /etc/os-release。重点看可用内存与可写存储空间，而不是只看包装上的总内存。规则数据、DNS 缓存、连接数量和日志都会增加资源占用，内核启动成功也不代表高并发时仍然稳定。

• CPU：同样的核心数量并不代表相同代理吞吐。看单核负载是否接近满载，并区分代理流量与普通转发流量。
• 存储：确认内核、geosite/geoip 数据和更新临时文件都能放下。不要将高频调试日志长期写入小容量闪存。
• 网卡：单网口可以构建旁路由，但更依赖路由设计；双网口便于划分入口与出口，不会自动解决错误的策略路由。
• 系统：确认固件提供所需内核模块和软件包。用户态程序存在，不代表系统支持 TPROXY 或 TUN。

2. 内核选择：以节点配置与固件集成为准

先看节点需要什么，再看固件能稳定维护什么。协议、安全层与传输方式是不同维度：VLESS 不自带内容加密，REALITY 是相关安全机制，WebSocket 是传输方式。不能仅凭订阅里出现“V2Ray”就推断两个内核可以互换所有配置字段。

订阅通常是节点来源，不等于可直接启动的完整网关配置。分享链接或 Base64 节点列表需要由兼容的管理工具解析，再生成入站、出站、路由和 DNS 设置；直接运行内核则需要准备对应格式的配置文件。服务名称、文件目录与更新方式随固件软件包变化，不应猜测。

3. 主路由与旁路由：网关路径比设备名称重要

主路由通常负责拨号、DHCP、NAT 和防火墙，同时运行代理内核后，可以在统一的转发入口处理流量。旁路由通常不负责互联网拨号，需要让目标设备的流量确实经过它。仅把一台设备接入同一个局域网，不会自动接管其他终端。

例如，主路由为 192.168.10.1，旁路由为 192.168.10.2，测试终端为 192.168.10.100。测试终端默认网关指向 192.168.10.2，旁路由的默认出口指向 192.168.10.1。这只是 IPv4 拓扑示例，地址必须与实际网段一致，且旁路由地址不能落入可能重复分配的 DHCP 地址池。

1. 为旁路由设静态地址或 DHCP 静态租约，确保重启后地址不变。
2. 在测试终端手动设置网关，DNS 指向计划承接查询的本地解析器。
3. 确认旁路由启用 IP 转发，防火墙允许所需转发，并正确处理返回流量。
4. 验证直连与代理后，再修改 DHCP 下发的网关选项；不要同时启用两个争抢地址分配的 DHCP 服务。

4. 透明代理模式：REDIRECT、TPROXY 与 TUN 的取舍

透明代理是网关接管连接的方式，不是某种节点协议。显式 SOCKS 代理由应用主动连接代理端口；透明代理则通过防火墙、策略路由或虚拟网卡让流量进入内核。建议先让显式代理连通，再处理透明接管，避免同时排查两层问题。

以 TPROXY 为例，防火墙先给选定流量打标，再将连接交给透明入站；策略路由负责把带标记的包送入本地处理路径。缺少任意一环，都可能出现“规则计数增长但没有连接日志”。透明入口示例可用 12345，它与用于应用测试的 10808 是两个不同角色的端口，不能仅修改端口号就完成接管。

• 先排除：路由器管理地址、必要的局域网目标、节点服务器地址和内核自身发出的连接，防止自代理循环。
• 区分链：转发终端流量与路由器自身流量入口不同。前者接管成功，不代表后者的订阅更新也走同一路径。
• 核对后端：OpenWrt 22.03 起常见默认组合是 firewall4 与 nftables；旧固件可能使用 firewall3 与 iptables，规则不能机械混写。
• 保留管理：规则应能重复加载且不会重复叠加，并有明确的卸载路径。远程修改前保留另一条管理连接。

UDP 接管成功也不保证所有 UDP 应用可用。节点出站、服务端和中间网络仍需支持相应流量；网页可用但语音或游戏失败时，应单独检查 UDP 日志与规则。硬件流量卸载也可能改变软件规则的可见路径，诊断时可先关闭卸载，再比较规则计数与连接行为。

5. DNS 分流：解析出口与连接出口需要配合

DNS 分流至少涉及三个环节：终端把查询交给谁、本地解析器选哪一个上游、解析器访问上游时走哪个出口。把 DNS 地址填到旁路由上，只解决第一步；如果上游查询仍经不合适的路径发送，可能得到异常结果或持续超时。

常见方案是在路由器上保留 dnsmasq，负责 DHCP、局域网名称和缓存；按规则将部分查询转给独立解析入口或内核 DNS。内核中的 dns 配置不等于自动对局域网开放一个 DNS 服务端口，还要配置实际入口或 DNS 转发机制。

1. 画出唯一上游方向：终端 → dnsmasq → 指定解析入口 → 上游。不要让 dnsmasq 与内核 DNS 互相转发同一类查询。
2. 保留本地解析：局域网主机名和内部域名应交给知道这些记录的解析器，不能一律发送给公共上游。
3. 安排节点域名引导：建立代理连接前就可能需要解析节点服务器域名，这条解析路径不能依赖尚未建立的代理连接。
4. 处理 IPv6：检查 DHCPv6、路由通告及 AAAA 查询的去向，使 IPv6 连接策略与解析结果相匹配。

假设 dnsmasq 已监听 LAN 的 53 端口，另一个解析入口可以按实际支持情况绑定 127.0.0.1:5353，再由 dnsmasq 转发指定查询。5353 也常用于 mDNS，使用前应检查占用；不能让两个服务绑定相同地址和端口。对外提供服务的入口还必须由防火墙限制来源，避免 WAN 侧成为开放解析器。

域名路由与 IP 路由也需要区分。透明连接进入内核时可能只有目标 IP；嗅探可在支持的协议中提供域名线索，但不能保证覆盖所有流量。geosite 用于域名分类，geoip 用于 IP 分类，二者依赖匹配的数据文件。路由规则通常按顺序匹配，domainStrategy 则影响路由阶段是否为 IP 规则解析域名，不会替代终端 DNS 设置。

6. 上线验证：先单设备，再逐步扩大接管范围

配置验收应把“内核可运行”“节点可连接”“终端流量被接管”“DNS 结果符合预期”拆成独立检查。不要在一轮操作中同时升级固件、替换内核、改网关并导入新规则，否则日志很难指向唯一原因。

1. 备份：保存网络、防火墙、DHCP 和内核配置，记录主路由管理地址以及恢复直连的方法。
2. 测试配置：Xray 可用下方命令检查配置。V2Fly 的命令行参数应以当前版本帮助输出为准，不直接套用 Xray 命令。
3. 显式测试：只让测试应用访问 SOCKS 入口，确认节点连接、时间与证书设置正确。
4. 透明测试：仅接管测试终端，观察防火墙计数、内核访问日志及真实出口，分别测试 TCP 与所需 UDP 应用。
5. 持续观察：检查空闲、下载和多设备访问时的可用内存、CPU、温度及错误日志，再扩大到更多终端。

# 配置路径为本文示例，按实际安装位置调整
xray run -test -config /etc/xray/config.json

# 以下命令用于具备相应工具的 Linux 环境
ip route
ip -6 route
ip rule
ss -lnptu
nft list ruleset

# 查询示例：将地址改为实际承接 DNS 的设备
nslookup example.com 192.168.10.2

部分精简固件需要另外安装 ss 等诊断工具；命令不存在不等于服务故障。分享日志前应隐藏订阅地址、认证信息及完整节点凭据。临时打开详细日志用于定位问题后，恢复较低日志级别，避免持续写盘和暴露访问记录。