4.1.1 RC1 版本已作为正式版本发布，二进制已更新，修正了日志中版本号未更新的问题，除此之外无变化。

Surge iOS 使用提示
最近几周接到若干用户回报，米家 app 开启时会产生大量请求，可能导致 Surge 因瞬时内存占用过高导致 Surge 被停止。确认该问题为米家 app 死循环请求所致。
部分用户采用 tun-excluded-routes 和兼容模式参数绕过，这其实是不合适的，即使不开启 Surge，系统仍然会因为米家 app 的疯狂请求而严重发热与大幅消耗电量。
目前的最佳解决方案是配置对应的 REJECT-DROP 规则。由于访问的 IP 是动态解析结果，我们无法提供具体的规则，需要自己根据请求列表结果配置，一个例子：
IP-CIDR,106.120.178.9/32,REJECT-DROP,no-resolve
请向米家 app 团队反馈该问题。

Surge iOS Beta 更新日志
- 优化了策略组图标的显示效果
- 优化 HTTP 引擎对非标准请求的兼容性
- 修正有时控制中心/桌面小组件在 Surge 已关闭时依然显示开启的问题
- 在没有网络时开启 Surge 将给出更明确的错误提示

Surge Mac & iOS Beta 更新日志
- [iOS]部分用户的网络存在异常，IPv6 的路由会被不断配置与清除，导致在 ipv6-vif=auto 的情况下 Surge 需要不断重新配置 VPN。该版本加入了一个 workaround，在同一个网络下，如果 IPv6 路由在存在的情况下又被清除，也不再重置 VIF 状态。
- 优化了加密 DNS 的错误处理逻辑，在遇到错误时将立刻进行重试

Surge 配置提示
在协助部分用户排查问题时，发现用户配置了过多的 DNS 记录（13000+）。如此多的内容会导致内存与性能问题。
由于 [Host] 段内容支持通配符且有先后顺序，无法进行索引优化，所以匹配的性能很低，因此并不建议在这里配置过多内容，也没有必要。（百条量级的话开销可忽略不计）
如果是为了区分解析，请参考白皮书，应正确配置规则系统确保解析在代理服务器发生，而非在本地进行解析。
如果是为了广告屏蔽，请使用 REJECT 规则。

Surge Mac & iOS Beta 更新日志
新的订阅功能：Shadowsocks 2022 加密协议支持
- 支持 2022-blake3-aes-256-gcm 与 2022-blake3-aes-128-gcm 两种模式
- UDP 转发同样需要配置 udp-relay=true
- 可配置 identity 参数以使用 SIP023 Shadowsocks 2022 Extensible Identity Headers，目前仅支持配置一层

关于 Shadowsocks 2022 的性能表现：
- 在延迟上，与原版完全相同
- 在吞吐量上，原版中限制单个 AEAD 加密 chunk 最大长度为 16383（0x3FFF），与 TLS 协议的 record 最大长度一致，而 SS-2022 为 0xFFFF。这导致在进行 iperf 等极端压力测试的情况下，SS-2022 的表现会更好。但是 chunk 长度过大可能导致解密延迟（因为必须接收完毕整个 chunk 的数据才可以开始解密）。不过在正常使用中，基本都属于可以忽略不计的区别。

Surge Mac & iOS Beta 更新日志
修改 SIP023 Identity 参数的配置方式为在 password 中使用 : 分隔，不再使用 identity 字段，与其他客户端相一致

Surge iOS Beta 更新日志
- 策略组列表视图支持配置自定义图标
- 修正带行尾注释的 DNS Mapping 项目无法在 UI 显示的问题
- 在全局模式下，若原选中策略不存在，将回退至第一个代理，而非 DIRECT

Surge iOS Beta 更新日志
- 新增 HTTP Capture 的控制中心开关
- 支持使用 Ponte 策略作为 underlying-proxy

有用户询问新参数与 ipv6-vif 参数的关系，ipv6-vif 参数控制是否开启 Surge VIF 的 IPv6，而 ipv6-vif-route-mode 控制在开启 IPv6 VIF 后的路由配置模式。
也就是说只有在，ipv6-vif=auto/always 下，ipv6-vif-route-mode 参数才有意义。

加入了一项 workaround，现在 ipv6-vif-route-mode 参数可以正确产生作用了

根据用户报告和反复测试，仅配置 2000::/3 路由对该特定 app 的 IPv6 请求问题的没有作用，下个版本将回滚代码取消该参数。
请尽量不要使用 ipv6-vif=always

新的订阅功能 Pre-matching
（Mac 版本不需要订阅）

用于描述使用 REJECT 策略的规则，如

[Rule]
DOMAIN,ad.com,REJECT,pre-matching

被标记了 pre-matching 的规则，将在正常的规则匹配流程前就提前生效，因此该规则相当于拥有最高优先级。

该功能的意义是，由于 Surge 的规则系统可判断的内容非常多，所以规则判定需要在收到首个 TCP 数据包后才可以进行，对于应对风暴请求或者去广告需求，产生了过多不必要的开销。

所有被标记了 pre-matching 的规则将会被提取出来进行优先匹配，在 DNS 解析与 TCP SYN 阶段就执行判断。若 DNS 域名命中，则直接返回 No Record，若 TCP SYN 阶段命中，将直接产生 ICMP REFUSED 响应，大量请求时升级至丢包，UDP 同样处理。

同时，对于每条规则，每 30 分钟仅会在最近请求列表中出现一次，避免因为大量请求刷屏。

可以使用 pre-matching 标记的规则类型有：

- DOMAIN 类型：DOMAIN,DOMAIN-SUFFIX,DOMAIN-KEYWORD,DOMAIN-SET,DOMAIN-WILDCARD。
- IP 类型：IP-CIDR,IP-CIDR6,GEOIP,IP-ASN。
- 逻辑规则：AND,OR,NOT
- 其他：SUBNET,DEST-PORT,SRC-PORT,SRC-IP

RULSET 也可以使用，但是其内容同样受到上述限制。

举例来说，对于最近米家 App 的疯狂请求，就可以靠配置

[Rule]
DEST-PORT,5222,REJECT,pre-matching

在低开销的情况下进行屏蔽。

注：未续订的情况下，该标记不会影响 Surge 开启，只是会无法生效，避免造成干扰。

--------------
以上内容为设计草案，有待修改。

相比最初版本进行了修订，不再限制 DOMAIN 类型不带有 extended-matching 标记， 不再限制 IP 类型一定需要 no-resolve 标记。
Surge Mac Beta Build 2971 已经可以开始测试该机制。

关于 Pre-Matching 功能的一些补充说明：
1. Pre-Matching 规则的 REJECT 策略依然有意义，对于 REJECT/REJECT-NO-DROP 策略，TCP 请求会在 SYN 时立刻收到 TCP RST（客户端表现为 Connection refused），DNS 请求会收到 No Record 响应。
而对于 REJECT-DROP 策略，TCP 的 SYN 包与 DNS 查询包将被直接丢弃，不做任何响应。
REJECT 同样会在一定频次后（30 秒内 50 次触发），自动升级为 REJECT-DROP。
除有明确的特殊需求外，建议使用默认的 REJECT，没必要主动使用 REJECT-DROP。

更新中加入了对代理模式接管的请求的 pre-matching 处理，REJECT 行为是进行 TCP RST，DROP 行为是将 socket 挂起。

REJECT-NO-DROP 改进
接到部分用户回报，在用于去广告等用途时，如果 DNS 返回 NXDOMAIN/No Record 可能导致应用等待，而返回 127.0.0.1 会使得应用立刻认为请求失败。

出现该区别的原因，是因为应用开发者对于不同错误的处理逻辑不同。然而在 DNS 中返回 127.0.0.1 进行屏蔽，是一项非常不标准的行为，本质是将请求导向了回环网络 lo0，由本地系统产生一个 TCP refused 响应拒绝请求。

1. 如果本地系统上正好监听了访问的端口，会导致对应监听服务收到该请求，产生非预期结果。
2. 如果被屏蔽的应用重试逻辑非常暴力，由于 connect 127.0.0.1 会被系统极快的拒绝，可能导致 CPU 占用 100%。（即手机发热）

为此 Surge 提供了一个全新的解决方案，对于使用 REJECT-NO-DROP 的请求，Surge DNS 将固定返回特殊 IP 地址 198.18.0.244。对于该地址的所有 TCP 请求，将由 Surge VIF 产生 TCP refused，同时当发现往该地址的 TCP SYN 极高时，进行丢包处理以避免引发高 CPU 占用。

这种处理方式既保留了返回 127.0.0.1 的优点，同时消灭了可能导致的副作用。如果在使用 REJECT 时，出现了 app 等待过长的问题，可尝试使用 REJECT-NO-DROP。