用 Surge 精确阻断 iOS 更新的蜂窝下载链路

问题

iOS 系统更新在 Wi-Fi 环境下开始下载，但下载尚未完成时切换到蜂窝数据，系统可能继续拉取更新包。一次实际流量记录中，蜂窝侧消耗超过 8GB。

Surge 的流量统计显示，核心流量来源集中在：

cdn-apple.com -> 8.48GB

进一步拆分连接日志后，实际承担更新包下载的接口主要是：

updates.cdn-apple.com
appldnld.apple.com

这说明问题不在于「是否能检测到更新」，而在于「更新包下载链路没有在蜂窝网络上被精确拦截」。

原因

iOS 更新链路可以按控制面和数据面拆开看：

层级	域名	作用
控制面	mesu.apple.com	检测系统更新
控制面	gdmf.apple.com	获取更新策略与设备匹配信息
数据面	updates.cdn-apple.com	下载系统更新资源
数据面	appldnld.apple.com	下载 Apple 软件包资源

如果目标只是防止蜂窝网络继续下载系统更新包，就不应该封锁控制面。控制面保留后，系统仍然可以检测更新；数据面在蜂窝网络下被拦截后，实际大流量下载无法继续。

分析

一个直觉上的做法是直接封锁整个 Apple CDN：

DOMAIN-SUFFIX,cdn-apple.com,REJECT

这条规则确实可以阻止系统更新下载，但粒度过粗。

cdn-apple.com 是 Apple 的统一 CDN 承载域，不只服务系统更新，也可能承载壁纸资源、App Store 内容以及其他 Apple 静态资源。按 CDN 后缀整体封锁，会出现典型的 CDN 误伤：

系统更新下载被阻止 -> 符合预期
壁纸下载失败 -> 误伤
其他 Apple CDN 内容异常 -> 误伤

因此，问题本质不是「Apple CDN 要不要封」，而是「应该封到哪个粒度」。CDN 级封锁是错误粒度；这里需要的是子域名级策略，并且只在蜂窝网络接口上生效。

解决方案

只拦截 iOS 更新的数据面下载接口，并限制规则仅在蜂窝网络下触发：

DOMAIN-SUFFIX,updates.cdn-apple.com,REJECT,INTERFACE=CELLULAR
DOMAIN-SUFFIX,appldnld.apple.com,REJECT,INTERFACE=CELLULAR

这组规则的行为边界很明确：

场景	结果
蜂窝数据检测系统更新	允许
蜂窝数据下载系统更新包	拒绝
Wi-Fi 下载系统更新包	不影响
下载 Apple 壁纸资源	不影响
访问其他 Apple CDN 内容	尽量不影响

关键点有两个：

1. 不封锁 cdn-apple.com 整体后缀，避免 CDN 误伤。
2. 使用 INTERFACE=CELLULAR 把策略限定在蜂窝网络，避免影响 Wi-Fi 下的正常更新。

如果规则集里已经存在 Apple 相关分流规则，应把这两条 REJECT 规则放在更靠前的位置，确保它们先于宽泛的 Apple、CDN 或 DIRECT 规则命中。

验证

验证时不要只看系统设置页面的提示，要同时看 Surge 连接日志。

预期结果如下：

updates.cdn-apple.com -> REJECT
appldnld.apple.com -> REJECT

同时检查三个行为：

1. 在蜂窝网络下，系统更新可以检测，但无法继续下载更新包。
2. 切回 Wi-Fi 后，系统更新下载不受影响。
3. 壁纸资源可以正常下载，没有因为 cdn-apple.com 被整体封锁而失败。

如果日志里仍然看到 updates.cdn-apple.com 或 appldnld.apple.com 走了 DIRECT、PROXY 或其他策略，通常是规则顺序问题。把两条 REJECT 规则前移，再重新测试。

总结

这类问题的重点不是简单封锁 Apple 域名，而是识别控制面与数据面的边界。

工程上应遵循三个原则：

1. CDN 级封锁通常是错误粒度，容易误伤同 CDN 上的无关业务。
2. 对 iOS 更新下载，应使用 updates.cdn-apple.com 和 appldnld.apple.com 这种子域名级控制。
3. Surge 的 INTERFACE=CELLULAR 是关键能力，可以把高风险下载限制在蜂窝网络场景内，而不影响 Wi-Fi 下的正常使用。

最终规则保持为：

DOMAIN-SUFFIX,updates.cdn-apple.com,REJECT,INTERFACE=CELLULAR
DOMAIN-SUFFIX,appldnld.apple.com,REJECT,INTERFACE=CELLULAR