再讨论为何 Surge Reject 规则的处理方式跟 Safari 不太合得来

[Socrazy]

原因：
最近开始从 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 处理。

[oxoxoxox]

貌似我这里没有你截图的这么严重，大部分 reject 的 timecost 在 20 ～ 40ms 之间，
规则配置如下：
REJECT, pre-matching, extended-matching

[Socrazy]

@oxoxoxox 你是用的网关模式是吧？没有开代理模式？我测试只开网关模式会好很多。

[Koma]

@Socrazy 跟上面一样，代理模式，都是几十 ms 。

[sadara]

很头疼，safari 有的 reject 不掉~！

[oxoxoxox]

@Socrazy #2 SystemProxy 和 EnhancedMode 都开了
分开测试了 SystemProxy 、EnhancedMode 两种模式，都是几十 ms

[Socrazy]

@oxoxoxox #5 好怪，也找不出原因来了。

[Socrazy]

@sadara 我直接安装了 AdGuard for Safari ，非常好使，因为用的 Safari 内容拦截 API ，像我测试的 s2.zdmimg.com 这个请求竟然直接看不到了，在 Surge 中也看不到请求。

[aero99]

图都挂了

[Crump]

试了下都很及时，你可以尝试下增加 pre-matching 试试。

[Socrazy]

@aero99 imgur 的图床，应该没挂吧

[Socrazy]

@Crump 第一张图就是开了 pre-matching 后的结果，不开的话，每个请求都是两三秒钟。

[ligogid]

没复现这个问题
最新系统，safari 插件 dark reader （未启用）和 wipr2 ，surge 只使用系统代理（关闭增强），用了 https://blog.skk.moe/post/i-have-my-unique-surge-setup/这个 blog 里的广告拦截，开启 pre matching 。
访问 smzdm 和我常用的一些网站均正常

[Socrazy]

@ligogid 嗯，我把 VPN 和网络扩展重新安装了一下，好像是可以了，再试一段时间。