apns（苹果消息服务）推送异常后目前所做的努力

[mrbruce516]

按照 https://support.apple.com/zh-cn/102266 信息，以及论坛上大佬们提供的域名，做了个 rule-set ，方便工具接入使用 地址： https://raw.githubusercontent.com/mrbruce516/apns-fix/refs/heads/main/Apple_APNs.list 指向外面的节. 即可

目前测试下来，最近并非所有海外 app 都受限制，我的 PlayStation app 、gemini 等可以正常收到消息，所以猜测是苹果针对部分 app 的 Bundle ID 结合设备终端 *.push.apple.com 请求头中获取到的终端 ip ，来做了黑名单限制。也并非觉得是我们的功夫 w 限制了 apns ，如果说 apns 被 q 那么显然所有的消息推送都会有问题。

需要注意的是这个方案不够优雅，但是在 ios 上想不到更好的解决方案了，隧道无法根据 app 选择是否经过，所以当 apns 走海外的话，若节.发生故障，所有的消息（包括国内的）也会出现推送异常，目前做法是做了个 fallback 的组，选中了较为稳定的节.（集）和 direct 。

目前尝试发邮件骚扰了 cook ，以及咨询了 apple 400 客服，希望能给点说法，毕竟商业公司选择自宫是一件令人感到很绝望的事情，不知道这种问题反应多了能否得到原厂的支持。。

[skyrocketing]

https://old.reddit.com/r/Telegram/comments/1t0e394/i_cant_received_notifications_despite_them_being/

境外也有相关的情况，苹果应该在处理了

[minivoid]

如果是请求头中获取的 ip ，能不能通过 mitm 改一下 header 就行，并且 direct

[hsir]

我怎么感觉可能是苹果自己的问题…… push 推送要封早该封了，怎么会现在才来屏蔽

[hefish]

@hsir 哈哈哈，苹果怎么可能会有问题。。。哈哈哈哈。。。 肯定是自己的问题，或者是国家地区的问题。。。咳咳

[shakaraka]

按理说苹果可以根据设备各种数据来判断你是否在哪个国家。不然 esim 也不可能做到。

其次是需要根据设备所在国家所上架的 apps 来当做推送白名单。

那么这样就能做到设备在哪个地区，就只能接收到哪个地区白名单的 apps 的推送消息。

这不是很简单的需求么。。。

[LOGOSJ]

实测光分流 APNs.list 还不够，还需要开启 include-all-networks ，不然依然旧无法收到推送。
这次全球范围的报故障不多，希望不是苹果为了合规自己阉割了。

[laydown]

现在添加了那些规则到 stash 里，但还是有问题，无论是否打开 app 里的 apns 的设置开关，在 wifi 环境和流量环境进行转换的时候，会出错，只能断开 stash 重连才行。希望只是 Apple 方面出 bug ，而不是故意搞这些有的没的，自宫就太可耻了。

[waytoshine]

各大 ruleset 的 apple 的 ruleset 没有包括这些吗？应该叫他们去更新一下把？

[mrbruce516]

@skyrocketing 感谢回复，确实也有注意到泰国之类的东南亚国家也有很人报障

[mrbruce516]

@hefish 国行设备、美版设备，美区 apple id （绑定设备），只要是 apns 走 direct 就会有问题目前

[mrbruce516]

@LOGOSJ 嗯，需要补充一下，昨天测试的时候是在 wifi 的状态下，加入 rule-set 就够了，但是蜂窝数据是不够的，需要让隧道内包含 apns 数据，确实这个也需要操作下

[mrbruce516]

@laydown 火箭目前我打开了隧道内包含 apns 的开关后，测试下来 wifi 和蜂窝切换没有影响，我再用几天看看情况

[kilotiger]

1L 给的那个链接虽然说明了亚洲地区好像推送都有问题，但是为什么 X 也收不到推送了 emmmm……

[mrbruce516]

@minivoid 嗯 我刚也思考了下会不会类似于服务端获取了类似 ng 的 x-real-ip 来做 geo 判断，发给 gemini 让他思考了下，如下:

关于 APNs 的底层机制，这里面有几个非常硬核的“坑”，我们要用理性的技术视角来拆解一下哦。针对你的疑问，我的结论是：Apple 不依赖 L7 层的 Header 来判断，而且绝对、绝对不能对 APNs 进行 MITM （中间人攻击）！

让我用你熟悉的系统架构语言为你结构化分析一下原因：

1. 苹果是通过 X-Real-IP 来判断并进行黑名单限制的吗？
大概率不是，也不需要。
在标准的 K8s/Nginx Ingress 架构中，确实经常用 X-Real-IP 或 X-Forwarded-For 来向后端传递客户端真实 IP 。但 APNs 的客户端连接机制不太一样：

L4/L3 视角的直连：你的 iPhone/Mac 是通过一条维持在 5223 端口（或 443 回退端口）的长期 TCP 长连接（基于 HTTP/2 over TLS ）直接与 Apple 的边缘节点通信。Apple 的网关在 TCP 层（ L3 网络层）就能直接看到你的 Source IP 。

黑名单逻辑：如果 Apple 真的要针对大陆 IP 配合 Bundle ID 进行精准掐断（虽然目前没有官方实锤，但确实有这种精准丢包的现象），他们直接在网关层提取 TCP 报文的 Source IP 加上 TLS 隧道内解密后的推送目标应用 ID 就可以实现了，根本不需要你在请求头里伪造什么。

2. 既然如此，我们可以用 MITM 修改请求头来绕过吗？
完全不可能，这是一条死路哦！ 🙅‍♀️
作为 DevOps ，你肯定知道 TLS 和证书信任链的威力。Apple 在 iOS 和 macOS 系统底层，对 *.push.apple.com 进行了极其严格的 SSL Pinning （证书锁定）。

硬编码信任：系统内部只信任 Apple 官方硬编码的根证书。如果你在代理软件（比如 Surge 、Quantumult X 等）中开启了对 push.apple.com 的 MITM 解析，代理软件会签发一张伪造的自签名证书给客户端。

立刻阻断：iOS 底层的安全机制一旦发现服务端下发的证书不是 Apple 官方的，会瞬间强制阻断 TLS 握手。

后果：不仅你的 TG 和 X 收不到推送，你的微信、PlayStation 、甚至 iMessage 的推送会在你开启 MITM 的那一瞬间全部瘫痪。


💡 最终的架构建议
既然咱们是走极简主义（ KISS ）路线的，面对这种复杂的黑盒网络干扰，最优雅、最暴力的解法就是把整个 L4 流量打包带走。

保持代理规则：就像你昨天测试的那样，坚持使用 DOMAIN-SUFFIX,push.apple.com 走代理。

绝对禁止 MITM：检查你的代理软件配置，确保 push.apple.com 没有被包含在 MITM 的域名列表里。只需要让它进行纯粹的 TCP 端口转发（ L4 代理）即可。只要流量在代理服务器出口变成了海外 IP ，Apple 看到的 Source IP 就是干净的，所谓的“精准黑名单”也就不攻自破啦。

[mrbruce516]

@kilotiger 啊，因为所有 app 的推送在苹果设备上都走 apns （苹果推送服务），只要这个服务出现了问题，就会影响应用的推送

[ZeoKarl]

不知道是不是我的错觉,火箭配置完以后,推送确实是好了,但是感觉上比之前的延迟高了点.

[lucifer9]

目前实测 tg 通知受影响，Gmail 没影响
小火箭加配置后通知都正常了，延迟确实略有增加，当然，总比没有通知强

[shuiduoduo]

你阉割也要在官网说明因为啥干了啥 不能和裤裆一样 捂嘴 啥都不说

[wangbingqian521]

规则里把 push.apple.com 加进去就行了

[Goghho]

@skyrocketing 就怕是剩下的亚洲国家其实是苹果为了合规大陆地区而导致的 bug