高防+anycast服务器的udp限制和解决

使用 udp2raw 来搭配 WireGuard,确实是对抗高防网关无脑丢弃 UDP 包的“杀手锏”。它的核心逻辑是:把 WireGuard 的 UDP 流量伪装成正常的 TCP 握手和数据传输,从而无视网关对 UDP 的限速策略。

既然你是在两台内网节点(假设都是 Linux 系统)之间建立隧道,以下是详细的安装与配置手册。


:round_pushpin: 核心拓扑理解

在开始之前,我们需要明确两端的数据流向:

  • 服务端 (高防 VPS): 运行 WireGuard 服务端(假设监听 UDP 51820)。运行 udp2raw 服务端(监听 TCP 4000),将收到的伪装 TCP 流量还原为 UDP,并转发给本机的 51820 端口。
  • 客户端 (另一台机器): 运行 udp2raw 客户端(监听本地 UDP 3333),将流量伪装成 TCP 发往高防 VPS 的 TCP 4000。运行 WireGuard 客户端,连接到本地的 UDP 3333

第一步:下载与安装 (两端均需执行)

udp2raw 是单一的可执行文件,无需复杂的编译,直接下载预编译版本即可。

# 1. 下载最新版发布包 (目前最新通常为 20230206 版本左右,请按需调整)
wget https://github.com/wangyu-/udp2raw/releases/download/20230206.0/udp2raw_binaries.tar.gz

# 2. 解压文件
tar -xzvf udp2raw_binaries.tar.gz

# 3. 将对应架构的二进制文件移动到系统环境变量目录 (以 amd64 为例)
sudo mv udp2raw_amd64 /usr/local/bin/udp2raw

# 4. 赋予执行权限
sudo chmod +x /usr/local/bin/udp2raw

# 5. 验证安装
udp2raw -h


第二步:服务端配置 (高防 VPS)

假设你的 WireGuard 服务端已经配置好,并且正在监听 51820 端口。

1. 临时测试运行命令:

sudo udp2raw -s -l 0.0.0.0:4000 -r 127.0.0.1:51820 -k "你的自定义密码" --raw-mode faketcp -a

参数解释:

  • -s: 以 Server 模式运行。
  • -l 0.0.0.0:4000: 监听本机的 4000 端口(向外暴露的伪装 TCP 端口,请确保云服务商的安全组放行了此 TCP 端口)。
  • -r 127.0.0.1:51820: 将还原后的 UDP 流量转发到本机的 WireGuard 端口。
  • -k: 加密密码,两端必须一致。
  • --raw-mode faketcp: 使用 TCP 伪装模式。
  • -a: 自动添加 iptables 规则(拦截内核对该伪装 TCP 端口发出的 RST 包,这是 udp2raw 正常工作必须的)。

第三步:客户端配置 (你的另一台机器)

1. 临时测试运行命令:

sudo udp2raw -c -l 0.0.0.0:3333 -r <高防VPS的公网IP>:4000 -k "你的自定义密码" --raw-mode faketcp -a

参数解释:

  • -c: 以 Client 模式运行。
  • -l 0.0.0.0:3333: 在本地监听一个未被占用的 UDP 端口(例如 3333)。
  • -r: 指向高防 VPS 的 IP 和刚才设置的 TCP 4000 端口。

2. 修改客户端的 WireGuard 配置文件 (wg0.conf)
你需要让本地的 WireGuard 连向本地的 udp2raw 端口,而不是直接连向远端。

打开你的客户端 wg 配置文件,修改 [Peer] 部分:

[Peer]
PublicKey = <服务端的公钥>
# 将原本的高防 IP 替换为本地 127.0.0.1 和本地 udp2raw 监听的端口
Endpoint = 127.0.0.1:3333
# ... 其他配置保持不变 ...


第四步:极其关键的 MTU 调整 :warning:

因为 udp2raw 把 UDP 打包进 TCP,增加了额外的包头,会导致网络报文的有效载荷变小。如果 WireGuard 依然使用默认的 1420 MTU,会导致握手成功但无法打开网页、内网 SSH 卡死等现象。

必须在服务端和客户端的 WireGuard 配置文件中,双向降低 MTU。

在两端的 [Interface] 部分添加或修改 MTU:

[Interface]
# 建议降低到 1280 到 1300 之间,以避免分片丢包
MTU = 1280
...

修改完成后,两端重启 WireGuard 服务:systemctl restart wg-quick@wg0


第五步:持久化运行 (配置 Systemd 守护进程)

测试命令运行无误、WireGuard 可以跑满 1Gbps 后,需要将 udp2raw 设置为开机自启的后台服务。

在服务端 (高防 VPS) 创建服务:

sudo nano /etc/systemd/system/udp2raw.service

写入以下内容(注意替换你的密码):

[Unit]
Description=udp2raw server
After=network.target

[Service]
Type=simple
User=root
ExecStart=/usr/local/bin/udp2raw -s -l 0.0.0.0:4000 -r 127.0.0.1:51820 -k "你的自定义密码" --raw-mode faketcp -a
Restart=on-failure

[Install]
WantedBy=multi-user.target

在客户端创建服务:
路径同上,只是 ExecStart 替换为客户端的命令:

ExecStart=/usr/local/bin/udp2raw -c -l 0.0.0.0:3333 -r <高防VPS的公网IP>:4000 -k "你的自定义密码" --raw-mode faketcp -a

启动并设置开机自启 (两端执行):

sudo systemctl daemon-reload
sudo systemctl enable udp2raw
sudo systemctl start udp2raw

如果使用tailscale,如何使用udp over tcp?

这是一个非常好的思路转变!相比于原生 WireGuard 需要折腾 udp2rawTailscale 原生就自带了极其强大的 UDP 失败回退到 TCP 的机制

Tailscale 底层依然是 WireGuard(UDP),但当它发现两端无法建立直连(比如你的高防 VPS 把 UDP 丢包丢到完全无法握手时),它会自动且无缝地切换到 TCP 模式

以下是 Tailscale 实现 “UDP over TCP” 的核心逻辑以及你的最佳实践方案:

1. Tailscale 是如何实现 TCP 传输的?(DERP 中继)

Tailscale 引入了一个叫做 DERP (Designated Encrypted Relay for Packets) 的组件。

  • 当你的本地机器和高防 VPS 尝试通过 UDP 直连失败(或丢包率极高导致无法维持连接)时。
  • 两端会立刻寻找最近的 Tailscale DERP 中继服务器。
  • 它们会与 DERP 服务器建立 标准且伪装性极好的 HTTPS (TCP 443) 连接
  • 你的 WireGuard UDP 流量会被包裹在这个 HTTPS 隧道中,通过中继服务器进行转发。高防网关只会看到你在进行正常的网页浏览通信,从而放行。

2. 如何确认或强制使用 TCP (DERP)?

通常情况下,在高防 UDP 被严重 QoS 的网络环境里,你不需要做任何事情,Tailscale 会自动 fallback 到 DERP 模式。

如何验证当前走的是不是 TCP:
在任意一端(比如本地电脑)运行:

tailscale ping <对端高防VPS的Tailscale IP>

如果你看到结果显示:
pong from [名称] (IP) via DERP(syd) in 45ms
只要带有 via DERP 字样,就说明 UDP 直连失败了,现在正在通过 TCP 协议进行中继

如何强制只走 TCP?
如果你发现 Tailscale 还在不死心地尝试 UDP(表现为偶尔卡顿),你可以通过系统的防火墙直接把 Tailscale 的默认 UDP 端口(41641)墙掉,逼迫它瞬间走 TCP:

  • 在高防 VPS 上执行:sudo iptables -A INPUT -p udp --dport 41641 -j DROP
  • 或利用环境变量启动(Linux):TS_DEBUG_ALWAYS_USE_DERP=true tailscale up

:police_car_light: 致命缺陷与终极解决方案 (必读)

虽然 Tailscale 自动走 TCP 解决了连通性问题,但如果你直接使用官方默认的配置,会遇到一个致命问题:速度极慢。

Tailscale 官方的公共 DERP 服务器是免费提供给全球用户的,为了防止滥用,官方对单用户的带宽限制通常在 2Mbps - 5Mbps 左右。这会彻底浪费掉你那 1Gbps 的 TCP 带宽。

:light_bulb: 解决方案:自建私有 DERP 服务器 (跑满 1Gbps 的关键)

既然你的高防 VPS TCP 可以跑到 1Gbps,你必须在这台 VPS 上自己搭建一个 DERP 服务器 (derper)

架构逻辑:

  1. 在你的高防 VPS 上安装并运行官方的 derper 程序,监听 TCP 443 端口。
  2. 在 Tailscale 网页控制台的 Access Controls (ACL) 中,添加你自建的 DERP 节点配置。
  3. 你的本地电脑会通过 TCP 443 连接到你 VPS 上的 DERP 服务。
  4. 此时,你的 VPS 既是目标机器,又是中继服务器。数据通过 TCP 到达 VPS 后,内部解包交给本地的 Tailscale。

自建 DERP 的简要前置要求:

  • 一个域名(可以托管在 Cloudflare),解析到你 VPS 的公网 IP。
  • 申请一个该域名的 SSL 证书(Let’s Encrypt 即可,也可以用 Caddy 反代)。
  • 放行该 VPS 的 TCP 443 和 80 端口。

总结与路线建议

如果你追求极致的内网大带宽,你有两条路:

  1. 坚持纯 WireGuard + udp2raw(上一条回复的方案):
  • 优点: 性能损耗最小,真正的点对点伪装,适合两台 Linux 之间的纯粹打洞,占用资源极低。
  • 缺点: 配置相对繁琐,需要在两端维护进程,如果是手机、Windows 加入网络,配置 udp2raw 会非常痛苦。
  1. 转向 Tailscale + 自建 DERP:
  • 优点: 体验无敌好,全平台通吃(手机、电脑、NAS 随时随地接入),打通所有设备的内网,自动处理 TCP 握手。
  • 缺点: 需要配置域名和证书来搭建 derper 服务端,有一点点封装损耗。

如果你只是两台 Linux 服务器之间需要大带宽传数据,方案 1 (udp2raw) 效率最高。如果你想构建一个包含你所有个人设备的虚拟局域网,且都要通过这个 1Gbps 的节点,那么方案 2 (Tailscale + 自建 DERP) 是绝对的首选。