Akvicor
Akvicor
发布于 2026-08-29 / 0 阅读
0
0

Surge 旁路由下直播引发网络高延迟的排查与解决

网络环境

设备

地址

作用

爱快主路由

172.16.0.1

网络出口与 NAT

Mac mini

172.16.0.2

Surge Gateway VM

172.16.0.3

Surge 虚拟网关

终端将 IPv4 网关指向 172.16.0.2172.16.0.3 后,流量进入 Surge 转发路径。

问题现象

打开直播后,整个局域网出现周期性高延迟,包括未经过 Surge 的设备,网卡没有错误,链路带宽也未耗尽。问题表现为高延迟和丢包,而不是吞吐量不足。

问题原因

Surge 是四层代理。每个源地址、源端口、目标地址和目标端口组合不同的 UDP 流,都会作为独立连接管理。直播客户端在短时间内创建数百条 STUN 流,显著增加协议识别、规则匹配、日志和连接状态管理开销。

这些流量随后进入主路由的连接跟踪、NAT 和转发队列。第一跳延迟同步升高,说明主路由处理路径也受到压力。由于没有取得主路由内部队列和连接跟踪指标,也没有抓取 Mac 物理网卡出站流量,Surge 与主路由各自承担的开销比例尚未量化。

解决方案

保留游戏机 STUN

always-real-ip 只控制 DNS 返回真实 IP,不会绕过 [Rule]。游戏机相关条目可以继续保留,用于避免额外的 Fake-IP 转换影响 NAT 类型:

always-real-ip = *.srv.nintendo.net, *.stun.playstation.net, xbox.*.microsoft.com, *.xboxlive.com

游戏机依赖 STUN 完成 NAT 类型探测、联机匹配和语音通信。将游戏机放入固定网段 172.16.5.0/24,先按来源网段放行 STUN,再拒绝其他 STUN。

# 通过游戏机IP段放行
AND,((SRC-IP,172.16.5.0/24),(PROTOCOL,STUN)),DIRECT
# 通过STUN域名放行
AND,((PROTOCOL,STUN),(DOMAIN-SUFFIX,srv.nintendo.net)),DIRECT
AND,((PROTOCOL,STUN),(DOMAIN-SUFFIX,stun.playstation.net)),DIRECT
AND,((PROTOCOL,STUN),(DOMAIN-WILDCARD,xbox.*.microsoft.com)),DIRECT
AND,((PROTOCOL,STUN),(DOMAIN-SUFFIX,xboxlive.com)),DIRECT

按协议阻断 STUN

Surge 支持识别 STUN 协议,不需要依赖域名或端口:

PROTOCOL,STUN,REJECT-DROP

该规则应位于 [Rule] 顶部,在保留游戏机STUN之后,在游戏、直连、代理和 FINAL 规则之前。

REJECT-DROP 会静默丢弃数据包,避免客户端收到错误后立即重试。对于已经形成请求风暴的 STUN 流量,它比返回 ICMP 错误的 REJECT 更合适。


评论