strp

iPhone 连上网，首先会连接 gateway.icloud.com 从云端 bootstrap FaceTime + keepalive ，连接全程使用 TLSv1.3 + QUIC ，当接到 FaceTime 通话，云端会给设备下发多个位于以下列表中的 IP 用于接通前通讯。

https://support.apple.com/en-hk/102266

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

iCloud / APNs (推送) / FaceTime / iMessages 均共享这些 IP ，GFW 无法只封锁其中一项服务，需要注意 FaceTime 其中一个功能是 P2P 加密通话且无法禁用此选项，在接通通话后，任意一方拥有 NAT1 等能够进行 STUN 的则会创建 P2P 隧道，因此双方的 IP 地址均会被泄露，如果无法建立 P2P 隧道则通过上列的苹果服务器中转(TLSv1.3 / QUIC)，无法建立 P2P 不会改变 IP 已经泄露了的事实，有 NAT1 的用户一般不会卡，还有如果你国内配置了软路由翻墙的话，首先确定是否启用 FullCone NAT ，然后可以尝试白名单以上 IP ，因为受机场后端配置(主要是 UDP 路由)和线路原因，这也是导致卡顿的其中一个可能性。

最近其实也有人讨论过了，Apple 不知道是有意还是无意，我之前有帖子也说过，现在大概问题就是 iOS 很多时候没有办法从 QUIC 完全回落到 TLSv1.3 ，但是仅阻断 TLSv1.3 很多时候不会导致 APNs / FaceTime / iMessages 无法使用，反而是 iCloud / App Store 炸了，所以现在就变成了因为行为很随机很不稳定，两个都不能阻断，TLSv1.3 / QUIC 其中一个炸了都会导致任意苹果服务(甚至几乎所有主流的第三方 iOS App)极其缓慢甚至完全不可用(因为它们也是直接按照苹果给的开发套件和开发者文档进行开发，所以都会出问题)。

现在只有 IDC 线路特别签了带有跨省不限速的合同的不会被限速，家宽，商宽，互联网专线，任何没有签署跨省不限速条款的线路都这样，直接买个几十块的最便宜的阿里云，装个 WireGuard 把非移动和非海外流量全都分流到阿里云就行了。

@xiaoxiangzaici 这个型号我也有，一样的问题，我当无线 AP 用了，目前已经避雷 ASUS TP-LINK 和中兴，买的全都在两年刚过保坏掉了，看看中兴什么时候坏再考虑。

其实核对才是对的，防止底下的人执行的时候偷换设备，把贵的拿去卖，搞个便宜的给客户用，或者单纯多出来的设备直接就卖了，纯纯就是贪污，很多地方都是这么干的，欧美港澳这些还明确标注设备为租赁性质，客户需承担丢失责任。

@sheayone 确实，已经全部恢复了，GFW 同步真快，我都怀疑是不是谁 iptables -I 然后 -D 的事了

狠起来自己都杀
gov.cn 也似了（从国内访问国外 CDN ）

@GDSR Cloudflare 可以用非常规端口，现在测试策略是双向的，国外访问国内的 443 也不行

@GDSR 太长了，就是便开几个网站全都是连接被重置，不过看起来仅限于 443 端口，其他端口没事。

不演了哈哈哈