mrbruce516

yaml 工程师选择 gemini 聊天窗口+ antigravity 周轮转 + glm 的白嫖

@rebelliouswhiz 确实，昨晚给作者发了邮件，作者回复了确实是 iOS 系统问题，说是在测试版已经修复了，期待正式版更新
以下为邮件内容中可参考的链接：
includeAllNetworks and createTCPConnectionThroughTunnelToEndpoint bug：
https://developer.apple.com/forums/thread/774225
https://mullvad.net/en/blog/why-we-still-dont-use-includeallnetworks

@vokins 有参考原文么

@isbase 嗯 我的规则就是主要靠一条 *.push.apple.com 加上苹果官方提供的 v4,v6 地址 来的，按理说你这一条就够了

@ZeoKarl 确实体感上是会有的，因为先经过了代理节。

最近开始严肃使用 obsidian 了，搭配自托管插件，git 插件，还有几个插件几乎平替 notion

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

@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 就是干净的，所谓的“精准黑名单”也就不攻自破啦。

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