我在 Surge Mac v6（VM 网关 / 旁路由模式）下遇到两个持续困扰的稳定性和兼容性问题，已影响公司约 50至200名用户 三家公司 三个Surge均有出现类似问题。问题在复杂链式 + 多层负载均衡架构下非常明显，通过大幅简化代理架构后可基本规避，怀疑是 Surge 在高并发、链式代理、负载均衡策略组组合下的连接管理 / 状态机存在 Bug。
Surge Mac版本为6.4.4-6.5.0BETA QUIC全局屏蔽
- 环境与配置概述
硬件：Mac mini（M2和M4 系列 万兆网口 CPU与内存占用正常 ）作为旁路由网关，Surge v6 VM 模式运行。
用户规模：公司约 100 人同时在线（高峰期并发较高）。
代理协议：全部使用 Snell v5 OBFS（已确认本地联通可跑满带宽且无丢包）。
服务器：
上游线路：2台线路服务器A1A2 + 2 台落地服务器B1B2
架构：线路服务器 → 故障迁移策略组(A1A2) → 落地服务器 → 负载均衡策略组(B1B2 未开启PCC) → 落地节点内部链式代理指向线路负载均衡组。
Snell 配置：未开启 连接复用 和 TFO（按官方推荐保守配置）。
策略组：
线路服务器放入一个故障转移组。
落地服务器放入另一个负载均衡（未开启PCC）组。
落地节点内使用 链式代理选择线路故障转移组。
- 问题现象
问题一：部分用户电脑网络整体卡死（需重启网卡/电脑恢复）
表现：用户电脑突然整个网络不可用（有线网络，DNS完全不工作无法查询），但其他设备正常
触发频率：随机，部分用户每天出现多次。
恢复方式：只需在用户电脑中关闭/开启网卡（或重启电脑）即可立即恢复。
怀疑点：可能是 Surge 在 VM 网关模式下对 TCP 连接状态管理出现异常，导致客户端网卡缓冲区或驱动层卡住。目前无法确定是服务器 TCP 调优问题还是 Surge 侧的连接池 / keep-alive 问题。
问题二：特定网站完全无法打开（最典型的是 Facebook Ads）
表现：浏览器直接显示错误页（类似“无法访问此网站”或 connection reset），页面压根打不开。
关键特征：
同一台电脑上，Telegram、Google、YouTube 等其他需要代理的网站完全正常。
同一个代理节点复制一份（完全相同的 IP、端口、密码、Snell 配置），在策略组里切换到“复制版”后，立即就能正常打开 Facebook Ads。
用户重启本机网卡也可解决
说明不是服务器封锁或 IP 问题，而是 Surge 在处理该域名流量时的连接建立 / 复用逻辑出现了状态不一致。
- 已尝试的排查与临时方案
协议切换：
将落地机改为 SS 协议 → 网站无法打开的情况进一步减少。
架构大改（当前稳定方案）：
在线路服务器上做端口转发 + 负载均衡。
Surge 侧仅保留 1 个 Snell 代理节点（不再使用链式 + 多层 Load Balance）。
结果：
网站无法打开的问题基本消失。
整体性能反而更好（延迟更低、吞吐更高）。
网络卡死现象也显著减少。
以上 workaround 证明问题根源极大概率出在 Surge 对「链式代理 + 多层 Load Balance 策略组」的处理逻辑上，而非后端服务器本身。
- 复现条件（供开发者参考）
高并发环境（50+ 用户同时在线）。
多台线路服务器加入到负载均衡组+多台落地服务器加入到负载均衡组（落地服务器每个节点内链式代理线路服务器的负载均衡组）
必须使用链式代理 + 至少两层 Load Balance。
Snell v5 + 未开启 connection-reuse / tfo。
无特定域名，但是触发概率极高。
- 希望官方协助
请开发者排查 Surge v6 在 VM 网关模式下，链式代理 + Load Balance 策略组的连接复用、状态同步、TCP 窗口管理机制是否存在问题。
是否与 Snell v5 协议的特定实现（尤其是多节点快速切换时）有兼容性 Bug。
建议优化点：增强多层 负载均衡 链式代理 场景下的连接池隔离、状态重置机制，或增加 debug 日志输出相关连接 ID / session 信息。
非常感谢 Surge 团队一直以来的优秀产品！这个架构在 100 人规模的公司网关场景非常实用，如果能修复上述问题，将极大提升 Surge 在企业级旁路由场景的稳定性。
