newrevolution Surge for Mac has been very unstable since the introduction of SSH protocol. The last stable version was 4.5.2. I'm going to downgrade back to 4.5.2
SurgeTeam wangpao 不是不打算解决，而是没法解决，只有极少部分用户遇到了该问题，我们也咨询了 Apple 的工程师，他们也不能解释产生这种情况的可能，再没有更多信息前我们没有办法解决该问题。
byheaven SurgeTeam 具体现象是：Mac作为网关，给Apple TV提供代理。当Mac屏幕关闭或锁屏(已确认设置Mac没有进入睡眠)1分钟之后，Apple TV网速就会出现巨幅下降。策略改为全部直连依旧如此，但峰值(20Mbps)会比代理高一些(<10Mbps)。今天重新进行了测试，使用同样的配置文件和规则，下载ClashX Pro并使用网关模式对比，在屏幕关闭后网速依旧正常。所以可以排除是MacOS 13本身的问题，应该也可以排除是配置文件的问题。
byheaven SurgeTeam 您好，cpu占用都正常。系统重置，干净的系统也一样的问题(同样的条件下和ClashX做了对比，确认是surge独有的问题)。但是刚刚突发奇想尝试了连接iPhone5G热点，竟然发现不会出现问题了，在全屏下网速不会降低了。保持所有条件不变，再切换回WiFi网络，chrome全屏几分钟之后，速度降低再次复现。
byheaven SurgeTeam 今天用有线(1000Mbps)进行了测试，结果比无线时速度上限高了很多，但是全屏vs不全屏Mac本体播放视频\关闭或不关闭Mac屏幕状态下网关模式其他设备，这两种对比均能够发现比较明显的性能下降，例如YouTube播放同样的4K，缓冲时间明显变长。但确实比无线时快了很多，可以支持4K播放。
byheaven SurgeTeam 对比发现在全屏播放，网速巨幅下降时，surge CPU<10%，非全屏时 surge CPU占用大约20%，另外使用该命令“renice -20 -p surgePID”并没有作用。
byheaven SurgeTeam 新建了一个空配置，在出站使用全部直连的情况下，不会出现网速下降；之后分别尝试添加了一个ss和Trojan节点，并选择全局代理，均会出现问题。tfo和udp relay都没有开启，ss用的是aes-128-gcm
byheaven byheaven 感谢提供测试节点，使用新空白配置全局代理测试，chacha20的ss依然会出现全屏后网速急剧下降的问题(注意是会在1·2分钟后才开始下降，随后就几乎完全卡住无法播放)。
