- 场景说明：为什么要把两套代理/隧道放在一台服务器上
- 关键冲突点：端口、协议与路由表三大维度
- 可行的几种架构思路
- 1. 端口/协议隔离（最简单）
- 2. 同机多 IP（最稳妥但成本高）
- 3. 透明代理 + 政策路由（细粒度）
- 流量分流的核心技术点（不用代码也要理解）
- 实战案例：按目标域名走 Trojan，其他走 WireGuard（思路说明）
- 常见问题与排查建议
- 优劣权衡与调优建议
- 未来趋势与演进方向
场景说明：为什么要把两套代理/隧道放在一台服务器上
很多折腾翻墙的同学会把 WireGuard（轻量、UDP 内核隧道）和 Trojan（伪装成 HTTPS 的 TCP 隧道）同时部署在同一台 VPS 上。这样做的常见动机包括：
- 利用 WireGuard 处理大流量、实时性要求高的应用（比如视频、游戏）；
- 利用 Trojan 的 TLS 伪装和域名伪装优势，用于浏览器与少量敏感流量；
- 节约 VPS 资源与公网 IP 成本；
- 实现按应用/目标域名的流量分流（split tunneling）。
关键冲突点：端口、协议与路由表三大维度
要在一台机器上让两者和谐共存，主要要解决三类冲突：
- 端口与协议冲突：WireGuard 要绑定 UDP 端口（默认 51820），Trojan 常常监听 TCP 443（或其它端口）。若两者不慎使用相同端口或协议层次冲突，会导致服务冲突或 TLS 握手被拦截。
- 路由与出接口选择：WireGuard 建立的是虚拟网卡（如 wg0），会创建一条或多条路由；Trojan 则是基于 TCP，通常走主机的默认路由。如何让不同流量走不同出口，是关键。
- 流量分类与转发：精确分流需要按目标 IP/域名、进程、端口或 TPROXY/透明代理规则分类并重路由，否则无法实现细粒度策略。
可行的几种架构思路
下面给出几种常见且实用的共存架构思想，每种都有权衡点。
1. 端口/协议隔离（最简单）
直接为两种服务指定不同端口和协议：WireGuard 使用 UDP 专属端口，Trojan 使用 TCP 443（或别的 TCP 端口）。这种方法最低侵入性，适合仅需要两条独立通道的场景。但缺点是不能按应用自动分流，客户端需要手动选择连接方式。
2. 同机多 IP（最稳妥但成本高）
给 VPS 额外绑定一到多个公网 IP，将 WireGuard 与 Trojan 分别绑定到不同 IP。优点是根本避免端口与证书层面的相互干扰；同时可以在服务器端用路由规则把不同来源的流量分别处理。缺点是需要额外公网 IP，部分 VPS 提供商限制多 IP。
3. 透明代理 + 政策路由（细粒度）
在服务器上部署透明代理/TPROXY 或者使用 iptables/nftables 的 mangle 表打 mark，再配合 ip rule + ip route 将标记流量路由到 WireGuard 虚拟接口或本地出口。客户端可只运行一个代理，服务器端基于目标域名/IP 做流量调度。此方法可实现按域名分流且对客户端透明，但配置复杂，需注意 MTU、连接跟踪和 HTTPS 伪装的差异。
流量分流的核心技术点（不用代码也要理解）
无论采用哪种架构，下面几项技术概念不可回避：
- 策略路由（Policy-based routing）：通过 ip rule 指定源地址、fwmark 或其他条件，选择不同的路由表，从而把流量送入 WireGuard 或直接走公网。
- 连接跟踪与 NAT：iptables/nftables 的 NAT/POSTROUTING 需要与策略路由配合，避免把已经走 WireGuard 的流量再次被 NAT 到错误出口。
- 透明代理与 TPROXY：要把服务器当做网关强制重定向 TCP/UDP 流量到 Trojan 或其它代理，需用 TPROXY + iptables 覆盖，注意防止 loop（回环）。
- DNS 处理：域名分流依赖准确的 DNS 解析；本地 DNS 池化、DNS over HTTPS/DoT、并根据策略决定解析结果是常见做法。
- MTU 与分片：WireGuard 默认 MTU 较小或不同于主链路，混合使用时可能出现网页加载慢或连接失败，需针对隧道特性调整或开启 Path MTU Discovery。
实战案例：按目标域名走 Trojan，其他走 WireGuard（思路说明）
场景：你希望浏览器访问特定被封锁域名时走 Trojan（借助其 TLS 伪装与 SNI），而大流量下载/游戏走 WireGuard。
- 客户端层面：配置系统或应用分流策略，优先把某些域名的请求发给系统默认网络（或直接到远端 Trojan），其余流量经 WireGuard 隧道。
- 服务器层面：Trojan 监听 TCP 443，WireGuard 监听 UDP 专属端口。服务器上建立两套路由策略：一套是 WireGuard 的 peer 路由表，另一套是本地出站表用于 Trojan。若使用透明代理，还需在防火墙上把来自于被标记流量转到 Trojan 的监听端口。
- DNS：确保被迫走 Trojan 的域名解析结果指向 VPS，或在客户端使用满足分流策略的 DNS 解析器。
- 监控与回滚：用 netstat/ss 查看端口占用，tcpdump 或 tshark 验证流量是否按预期走到目标端口/接口，发现问题先回退路由或防火墙规则逐项排查。
常见问题与排查建议
- 服务无法启动：先排查端口占用与协议冲突，确认没有两个进程同时绑定同一 IP:端口。
- 分流失败：用抓包确认 TCP/UDP 哪个接口在发送；检查 ip rule 与路由表的优先级；若依赖 fwmark，确认 mangle 表是否生效。
- 证书/伪装被识别：Trojan 的伪装依赖真实证书与合理的域名流量模式，确保 SNI 与域名匹配，避免异常频繁的非 TLS 流量暴露特征。
- 性能瓶颈：WireGuard 在 UDP 层面延迟低，但 CPU 加密开销与 MTU 设置会影响吞吐；Trojan 的 TLS 握手和单 TCP 连接吞吐也有上限。
优劣权衡与调优建议
综合来看，同机部署两者的主要优势是灵活性与成本节约；主要挑战是配置复杂度与潜在的路由/防火墙陷阱。实用的调优方向包括：
- 尽量避免端口复用；若必须使用 443 并同时有其它服务，优先考虑多 IP 或端口映射方案；
- 把路由与防火墙规则模块化、分阶段部署并保持一套回滚脚本，便于排错；
- 监控连接数、CPU、带宽与 MTU，针对高并发优化 TLS 会话复用与 WireGuard 的 keepalive 与窗口参数；
- 使用可信的 DNS 与证书管理，减少伪装异常导致的流量被识别风险。
未来趋势与演进方向
随着加密流量识别技术进步，与此同时也有越来越多轻量级隧道与多路复用方案出现（如 QUIC-based 隧道、基于 SOCKS/HTTP 多路径的智能路由）。在可预见的未来，混合使用多种传输层协议、结合应用层智能判断的方案会越来越普及。不过在实际部署时，清晰的路由边界、稳健的监控与可回滚的配置仍然是最可靠的实践。
暂无评论内容