5月27更新

今天在使用Apple Music的时候发现一个漏网之鱼，supportmetrics.apple.com，指向 supportmetrics.v.aaplimg.com。

---

众所周知，17.0.0.0/8(AS714)里面的所有ip都属于苹果，在全球几乎所有地方都能获得非常好的访问体验，尽管这些ip都不在国内，不过大部分国内用户需要的ip都已经做了peering。但是我最近发现Apple Music内自己上传的歌曲并不能流畅播放，经常会出现某一首歌一直加载，然后突然跳过了之后的数十首，直到播放到苹果自己平台上的音乐。本来想搜一下看有没有解决方案，结果反而看到了很多关于推送延迟的问题，但是并没有看到一个很好的解决办法，于是决定自己操刀尝试解决问题。

先给结论

最简单粗暴的解决方案

直接将整个17.0.0.0/8外加所有Akamai CDN代理出去。这样会涉及几个问题，比如如果想要部署在路由器上，并且采用的是dnsmasq-ipset方案（我就是），那么ipset将会存下整个/8段。又比如Akamai还有很多其他的网站在使用，比如steam，一刀切式的处理我想肯定不是最优解。

稍微没那么简单粗暴的方案

如果无法控制整个17.0.0.0/8的访问，那么可以退而求其次代理以下的ip段和端口，Akamai就随缘好了，至少还是能跑的。

TCP 端口 5223，用于与 APNS 进行通信
TCP 端口 443 或 2197，用于向 APNS 发送通知

IPv4
17.249.0.0/16
17.252.0.0/16
17.57.144.0/22
17.188.128.0/18
17.188.20.0/23

IPv6
2620:149:a44::/48
2403:300:a42::/48
2403:300:a51::/48
2a01:b740:a42::/48

根据域名判断的方案

苹果几乎所有的域名与服务都是公开了的，所以可以将所需要的域名添加到dnsmasq内，然后通过ipset代理访问，这个方案也是我最终选择的。以下是我自己的配置，仅供参考。

server=/gc.apple.com/dnsserver
ipset=/gc.apple.com/ipsetlist
server=/mzstatic.com/dnsserver
ipset=/mzstatic.com/ipsetlist
server=/gsa.apple.com/dnsserver
ipset=/gsa.apple.com/ipsetlist
server=/mask.icloud.com/dnsserver
ipset=/mask.icloud.com/ipsetlist
server=/idmsa.apple.com/dnsserver
ipset=/idmsa.apple.com/ipsetlist
server=/appleid.apple.com/dnsserver
ipset=/appleid.apple.com/ipsetlist
server=/apple-cloudkit.com/dnsserver
ipset=/apple-cloudkit.com/ipsetlist
server=/icloud-content.com/dnsserver
ipset=/icloud-content.com/ipsetlist
server=/mask-h2.icloud.com/dnsserver
ipset=/mask-h2.icloud.com/ipsetlist
server=/mask-api.icloud.com/dnsserver
ipset=/mask-api.icloud.com/ipsetlist
server=/blobstore.apple.com/dnsserver
ipset=/blobstore.apple.com/ipsetlist
server=/ns.itunes.apple.com/dnsserver
ipset=/ns.itunes.apple.com/ipsetlist
server=/itunes-apple.com.akadns.net/dnsserver
ipset=/itunes-apple.com.akadns.net/ipsetlist
server=/blobstore-apple.com.akadns.net/dnsserver
ipset=/blobstore-apple.com.akadns.net/ipsetlist

问题是如何解决的

如前文所说，虽然我没有找到成型的解决方案，但是我找到了苹果自己写的一篇关于推送的文章，《如果您的 Apple 设备无法收到 Apple 推送通知》，所以就有了第一个简单粗暴的方案，也就是直接将整个17.0.0.0/8段添加到ipset规则中。
但是问题很快就出现了，我忽略了/8段非同寻常的大小，无法和现有的ipset表相兼容。于是只好回到传统思路上，找苹果服务相关的域名，在使用时临时将这个域名代理即可。
之后我找到了Apple提供的服务列表(HT210060)，里面列举的非常详细，这里把对于大部分用户来说比较重要的摘抄一下。

主机	端口	协议	描述
*.push.apple.com	443、80、5223、2197	TCP	推送通知
identity.apple.com	443	TCP	APNs 证书请求门户
ns.itunes.apple.com	443	TCP
itunes.apple.com	443、80	TCP
doh.dns.apple.com	443	TCP	用于 DNS over HTTPS (DoH)

在按照上文添加完之后，我发现问题依然没有解决，推送速度快了很多，但是并没有解决Apple Music的问题，只好从dns请求记录入手，逐个筛查不在服务列表的域名。直接分析dns记录让我确定了两个事情，一个是苹果有很多服务会解析到Akamai CDN，虽然在海外，但是速度并不慢。可能是移动网络的问题，我到新加坡节点的速度非常快；另一个是国内除了连接到苹果自己或者Akamai，还有一些是连接到云上贵州的服务器，这个现象之前被我忽略了。解析结果并不是很好，比如在深圳会解析广西的服务器，有时连接速度甚至不如Akamai，只能说云上贵州还有待优化。
用这种方式虽然繁琐，但是非常准确，很快就找到了两个之前没有注意到的域名，store-032-lb.blobstore-apple.com.akadns.net以及store-032.blobstore.apple.com。这两个域名访问速度非常慢，添加到代理列表之后，Apple Music的体验直线提升。最终逐个测试其它平时需要用到的Apple域名并添加之后，现在Apple Music已经可以得到很不错的访问速度了。