再讨论为何 Surge Reject 规则的处理方式跟 Safari 不太合得来
Dream4U · 2024-12-19 11:35:29 +08:00 · 2218 次点击这是一个创建于 372 天前的主题，其中的信息可能已经有所发展或是发生改变。
原因：
最近开始从 Arc 又转回 Safari ，发现 Safari 在打开某些网站时明显比 Arc 慢，看了一下网络请求，原因在于被 Surge Reject 掉的请求，在 Safari 里明显请求时间更长。
如图：
图一、Surge 中 Reject 掉的域名在 Safari 中的请求时间，这还是选择了预先匹配，如果不选择，时间要长好几倍，明显卡住。
图二、关掉 Surge ，通过 Adguard Home DNS 域名拦截，影响很小。
图三、在 Arc 中的请求，开不开 Surge 没有影响。
测试过 QX ，同样的 Reject 规则，没有影响，也就是说只有 Surge+Safari 会有这问题。
难道 Surge 的 Reject 处理方式跟 QX 不一样？ QX 处理方式应该是 DNS 处理。
最近开始从 Arc 又转回 Safari ，发现 Safari 在打开某些网站时明显比 Arc 慢，看了一下网络请求，原因在于被 Surge Reject 掉的请求，在 Safari 里明显请求时间更长。
如图：
图一、Surge 中 Reject 掉的域名在 Safari 中的请求时间，这还是选择了预先匹配，如果不选择，时间要长好几倍，明显卡住。
图二、关掉 Surge ，通过 Adguard Home DNS 域名拦截，影响很小。
图三、在 Arc 中的请求，开不开 Surge 没有影响。
测试过 QX ，同样的 Reject 规则，没有影响，也就是说只有 Surge+Safari 会有这问题。
难道 Surge 的 Reject 处理方式跟 QX 不一样？ QX 处理方式应该是 DNS 处理。
第 1 条附言 · 2024-12-19 17:36:21 +08:00
在 Surge 设置>权限管理中，把 VPN 和网络扩展重新安装了一下，好像是解决问题了，继续测试看看。
 |
1
oxoxoxox 2024-12-19 12:17:27 +08:00
貌似我这里没有你截图的这么严重，大部分 reject 的 timecost 在 20 ～ 40ms 之间，
规则配置如下： REJECT, pre-matching, extended-matching  |
 |
4
sadara 2024-12-19 12:39:19 +08:00
很头疼，safari 有的 reject 不掉~！
|
|
5
oxoxoxox 2024-12-19 13:59:51 +08:00
@Socrazy #2 SystemProxy 和 EnhancedMode 都开了
分开测试了 SystemProxy 、EnhancedMode 两种模式，都是几十 ms |
 |
7
Dream4U OP @sadara 我直接安装了 AdGuard for Safari ，非常好使，因为用的 Safari 内容拦截 API ，像我测试的 s2.zdmimg.com 这个请求竟然直接看不到了，在 Surge 中也看不到请求。
|
 |
8
aero99 2024-12-19 15:57:42 +08:00
图都挂了
|
 |
9
Crump 2024-12-19 16:04:44 +08:00
试了下都很及时，你可以尝试下增加 pre-matching 试试。
 |
 |
12
ligogid 2024-12-19 17:06:48 +08:00
没复现这个问题
最新系统，safari 插件 dark reader （未启用）和 wipr2 ，surge 只使用系统代理（关闭增强），用了 https://blog.skk.moe/post/i-have-my-unique-surge-setup/这个 blog 里的广告拦截，开启 pre matching 。 访问 smzdm 和我常用的一些网站均正常 |
 |
15
crac 2024-12-20 10:05:12 +08:00
你为啥不用 reject-tinygif 或者 reject-drop
|
|
17
Dream4U OP @1217950746 其实影响不大，性能已经很强了，用 iOS 测试 500 条记录基本在 0.xms ，多 10 万条规则，差异在 0.xms 之间。
|
Select Language