Linux 路由器与旁路由部署概览：内核直跑的接管边界

先分清“内核直跑”接管了什么

这里的“内核”指运行在用户空间中的 V2Ray 或 Xray 代理核心，不是把代理功能编译进 Linux 内核。代理核心负责接收被送入入站端口的连接，按照路由规则选择直连、阻断或远端出站；Linux 本身仍负责网卡、地址、路由表、连接跟踪、转发和防火墙。

因此，程序显示“运行中”只说明进程已经启动，不代表局域网流量必然经过它。要完成网关接管，数据包必须先到达这台 Linux 主机，再由 nftables 或 iptables 将目标流量送入透明代理入口。返回流量也要沿着可预期的路径回到原设备，否则会出现连接建立后立即中断、部分网站能开而其他应用超时等现象。

网关、DNS、转发与代理核心的职责

默认网关回答的是“数据包下一跳去哪里”。DNS 回答的是“域名解析成什么地址”。Linux 转发负责让从一个接口进入的数据包能够从另一个接口离开，而代理核心只处理真正送到其入站的连接。这四部分相互配合，但任何一部分正常都不能替另外三部分证明部署成功。

例如，终端可以通过 Linux 上的 DNS 服务得到正确地址，却仍然把数据包发往原路由；也可能默认网关已经改成 Linux，但系统未启用 IPv4 转发，导致终端连局域网外地址都失败。另一个常见情况是转发正常、透明入口也在监听，但防火墙没有排除网关自身、局域网网段或远端服务器地址，最终形成循环。

主路由与旁路由的流量路径差异

主路由模式下，Linux 通常同时持有局域网接口和上游接口，终端通过 DHCP 自动取得它作为默认网关。数据包从局域网接口进入，经过路由判断、防火墙和代理规则后，再从上游接口发出。路径统一，分流规则容易集中维护，但 DHCP、NAT 或转发中的一次错误就可能让整个网络失去外部连接。

旁路由模式下，原路由仍负责上网与地址分配，Linux 主机位于同一局域网。只有把默认网关明确指向旁路由的终端才会经过它。若终端网关仍是原路由，仅把 DNS 改成旁路由，那么旁路由通常只能看到 DNS 查询，看不到后续连接，透明代理规则自然不会命中。

还要检查回程。旁路由将数据包转发给原路由后，原路由需要知道响应如何返回终端。常见做法是在旁路由出口进行源地址转换，或者在原路由上添加指向测试网段的静态路由。前者部署简单，但原路由看到的是旁路由地址；后者保留源地址，要求网络设备具备明确的路由配置能力。

• 主路由路径：终端 → Linux 默认网关 → 透明代理或直连规则 → 上游网络。
• 旁路由路径：测试终端 → Linux 旁路由 → 原路由 → 上游网络。
• 仅改 DNS：终端 → Linux 查询域名，实际连接仍可能直接发往原路由。
• 显式代理路径：终端应用 → Linux HTTP/SOCKS 入口 → 代理核心出站，不依赖透明规则。

按可回退顺序完成部署

部署时应把“节点是否可用”和“网关是否接管”拆成两次测试。先用显式代理验证核心配置和远端连接，再启用 Linux 转发与透明规则。这样一旦出错，可以快速判断问题在代理出站还是本地网络路径。

1. 记录原网络

   保存测试终端原来的 IP、子网掩码、默认网关与 DNS。旁路由也要固定局域网地址，避免 DHCP 租约变化后失去管理入口。

2. 验证核心出站

   先让 V2Ray 或 Xray 监听仅供测试的 HTTP/SOCKS 端口，例如 10808，并在单个应用中显式填写该地址。此时不启用透明转发。

3. 确认核心类型

   如使用 Windows 测试终端交叉验证同一份节点参数，可在 v2rayN 打开「设置」→「参数设置」→「Core 类型」，确认所选核心与协议配置匹配。

4. 打开系统转发

   检查 net.ipv4.ip_forward 是否为 1，再确认 FORWARD 链允许测试网段通过。先保持普通路由可用，不急于加入透明规则。

5. 接入透明入口

   为 TProxy 设置数据包标记、策略路由和本地路由表，将选定 TCP/UDP 流量送入 12345，并排除局域网、组播、广播、网关自身和远端服务器地址。

6. 逐项扩大范围

   先测试一个固定 IP，再按设备组扩大。每次只改变网关、DNS或规则中的一项，并保留停用透明规则后恢复普通转发的操作入口。

下面的命令用于查看状态，不会替你生成防火墙规则。输出中应重点确认转发值、策略规则、路由表和监听端口是否与自己的配置一致。若系统使用 nftables，就应直接查看实际规则集，而不是只检查兼容层显示的内容。

sysctl net.ipv4.ip_forward
ip rule show
ip route show table 100
nft list ruleset
ss -lntup | grep -E '(:53|:10808|:12345)'

TProxy、重定向与 TUN 应怎样选择

透明接管并不只有一种实现。TCP 重定向规则容易理解，但原始目标和 UDP 处理能力受实现方式限制。TProxy 可以在保留目标信息的同时接收 TCP 与 UDP，更适合需要域名、IP 和传输层联合分流的网关，不过它依赖防火墙标记、策略路由和代理核心透明入站配置，排错步骤更多。

TUN 则让代理核心创建虚拟网络接口，从路由层接收流量。它能减少部分防火墙重定向逻辑，但仍需正确设置路由、DNS、接口权限和回避规则。若默认路由错误地再次指向 TUN，远端服务器连接也可能被送回代理自身，形成循环。

部署初期不建议同时叠加 TProxy 与 TUN。两条接管链并存时，同一连接可能被重复处理，日志中只看到不断重连，却很难从表面判断流量在哪一步回环。先选一种方式跑通 TCP、UDP 和 DNS，再决定是否有切换方案的必要。

DNS 与路由分流要分别验证

基于域名的分流需要可靠的域名信息来源。代理核心可能从入站协议、DNS 结果或流量探测中获得域名，但这些来源并不总是等价。若终端已经把域名解析成 IP，再以透明流量进入网关，核心看到的可能只有目标 IP，此时仅配置域名规则不一定命中。

DNS 还要避免自我循环。例如，Linux 上的本地 DNS 把查询转给代理核心，而核心配置的上游域名又需要调用同一个本地 DNS，查询就会反复回到原入口。较稳妥的做法是明确区分局域网监听地址、核心内部查询和上游解析路径，并在日志中确认一次查询只有可解释的请求与响应。

• 在测试终端查询一个预期直连域名，记录返回地址和查询耗时。
• 查询一个预期代理处理的域名，确认请求到达指定 DNS 入口。
• 使用目标 IP 发起连接，检查 IP 规则是否与域名规则产生不同结果。
• 分别测试 TCP 与 UDP，避免只凭浏览器打开网页判断全部协议正常。
• 检查 IPv4 与 IPv6 路径；若只部署了 IPv4 接管，不能默认 IPv6 会走同一套规则。

资源占用、验收指标与回退准备

网关负载不能只看空闲时的内存。加密连接数量、UDP 会话、日志级别、DNS 缓存和规则规模都会影响资源使用。还要观察软中断、单核占用与网卡吞吐，因为低功耗设备可能在总 CPU 看似不高时，已经有一个核心达到瓶颈。

一组用于建立基线的实测环境为：四核 N5105、4 GB 内存、Linux 6.1、千兆有线接口，单台终端持续传输 500 Mbps，并维持约 800 条连接。运行透明代理后，代理核心常驻内存约 118 MB，整机 CPU 在 18% 至 27% 间变化。这个结果只用于说明记录方法，协议、加密方式、规则数量和硬件不同都会改变数值。

验收时至少记录直连基线、显式代理、透明接管三组结果，并分别测试首次解析耗时、持续吞吐、连接建立、UDP 和规则命中。若透明接管比显式代理明显更慢，应优先检查 MTU、重复接管、DNS 等待和单核瓶颈，而不是直接更换协议名称。

1. 备份启用前的路由表、防火墙规则、DNS 配置和系统转发值。
2. 准备一条命令或服务操作，同时撤销透明规则与策略路由。
3. 保留原主路由的 DHCP 配置，旁路由试运行期间不要立即删除。
4. 设置日志轮转，避免调试日志长期写入占满磁盘。
5. 重启 Linux 主机后重新验收，确认规则加载顺序不会早于网络接口就绪。

部署前的最终判断

如果目标只是让少量应用使用代理，显式代理通常更容易观察，也不需要改变整个局域网路径。如果目标是接管电视、终端工具或不便逐个设置代理的设备，网关模式才有明显价值，但代价是需要同时维护路由、DNS、防火墙与代理核心。

首次部署更适合从旁路由和单台测试终端开始：先验证 10808 显式代理，再打开系统转发，最后把透明入口接到 12345。确认规则命中、DNS 路径、TCP、UDP、IPv4 与回退操作后，才考虑迁移 DHCP 或让 Linux 成为主路由。

• 能明确画出终端、Linux、原路由和上游之间的去程与回程。
• 能解释端口 53、10808 与 12345 分别由哪个进程监听。
• 能在停止代理核心前先撤销流量导向规则。
• 能从日志、端口、路由表和规则计数交叉判断故障位置。
• 能在不依赖代理链路的情况下进入 Linux 管理界面。