大家好，
我最近在使用 Surge 时遇到了一个问题：无论是使用 Shadowsocks、Snell 还是 Trojan 协议，连接在平稳运行一段时间后都会中断。
核心现象：
通过客户端与服务端的抓包分析，我观察到客户端在发出 TCP ACK 包后收不到服务端的响应，随后客户端会进行多次重试。这个行为模式似乎会触发运营商防火墙更严格的速率限制，最终导致连接中断，甚至 IP 被封锁。重启 Surge 客户端后，连接可以恢复。
环境信息：
- 服务端：
- Shadowsocks/Trojan: 使用
sing-box 搭建。
- Shadowsocks 协议:
2022-blake3-aes-128-gcm，启用了 multiplex 和 padding。
- Snell: 使用官方服务端。
- 对比测试： 在相同的网络环境和服务端下，使用其他客户端（如 sing-box）不会复现此问题，连接能够长期保持稳定。
个人猜测：
- Surge 是否有特定的并发连接或流量优化机制，其行为模式触发了上游防火墙的策略？
- Surge 对 Shadowsocks 2022 协议（特别是
multiplex 功能）的实现，是否与 sing-box 的实现存在不兼容之处？
希望能得到开发团队的关注和解答，谢谢。
附：服务端 (sing-box) 与客户端 (Surge) 配置示例
服务端 (sing-box):
{
"inbounds": [
{
"type": "shadowsocks",
"listen": "::",
"listen_port": 8080,
"method": "2022-blake3-aes-128-gcm",
"password": "<PASSWORD>",
"multiplex": {
"enabled": true,
"padding": true
}
}
],
"outbounds": [
{
"type": "direct"
}
]
}
客户端 (Surge):
shadowsocks-server = ss, SERVER_IP, SERVER_PORT, encrypt-method=2022-blake3-aes-128-gcm, password="PASSWORD", udp-relay=true
