大家好，

我最近在使用 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