一句话总结:移动宽带的原因,地理位置河北保定下面的小县城
具体现象: 手机息屏 20 分钟后,发任何消息,如微信、FaceTime 等消息时,屏幕不亮,没有任何消息提示(声音、震动)只有手机解锁打开,亮屏后,才能收到消息,可以看到消息都是几分钟,十几分钟前发过来的。
断断续续排查了 5 年,起初一直怀疑是设备本身的问题,但随着家里都陆陆续续的用苹果手机,发现在我家会有很高概率这个消息收不到的问题,经过一系列的排查,才发现问题的根本起因是移动宽带。
之前没发现是因为当移动数据和 Wi-Fi 同时开启的时候,如果 Wi-Fi 无法连接到苹果的 APNs 推送服务时,它会自动切换到移动网络,这个问题影响了我排查的方向,现在所有的苹果设备关掉移动网络后,只连移动宽带,二十分钟后就会有这个问题。
但具体更深层次为什么宽带会有这个问题,请教大家有知道的么。
目前移动的人员来我家做的事情:关掉了 ipv6 ,但是没效果
1
LxnChan 31 天前
这不就移动墙中墙的问题
|
3
i8086 31 天前 ![]() |
4
fds 31 天前
感觉要调试这个,你得换个支持全天候显示的比如 iPhone14Pro ,看看是收到了通知没响,还是真没收到通知。通知的声音和其他应用的声音是有不同的设置,也建议看看设置里是否关掉了。
|
7
busier 31 天前 via iPhone ![]() 更新 WiFi 路由器固件,或换其他品牌路由器试下
感觉是苹果 WiFi 待机低功耗状态与 WiFi 存在兼容问题 |
![]() |
9
chztv 31 天前
家人和你用的是同一个 iCloud 账号吗?
如果是,我建议用登录其他 iCloud 账号的设备来测试一下。 |
12
snow0 31 天前
判断原因就是因为手机息屏引起的,是息屏后推送服务挂了还是息屏后 wifi 连接问题就要你排查了
|
13
wiken 31 天前
可以换个路由器试试, 我在路由器后台看到我的 iphone 也不是一直在线的, 有时没在, 过一会又在了
|
14
yinmin 31 天前 via iPhone
iphone 熄屏几十分钟后,用电脑 ping iphone 的 wifi ip 地址,看看 iPhone wifi 有没有挂了
|
15
longfei210 31 天前
同样碰到这个问题,增加 DHCP Lease Time 解决。之前是 RouterOS 默认值十分钟,基本上锁屏后一段时间断网接收不到离线通知。
现 Lease Time 改为 7d 解决,留给其他人碰到问题尝试解决的思路。 |
17
leena 31 天前 via iPhone
在移动宽带的网络环境下,soul 广场加载不出来,还不如数据呢
|
![]() |
19
JConlee 31 天前
是不是 dns 的问题
|
21
Rhianu OP @longfei210 我的情况也不是这的问题,DHCP 这个我也排查过,目前就把路由器当成交换机在用,直接用猫拨号+DHCP 下发,也是不行。
|
22
Rhianu OP @longfei210 你这个情况应该会表现 Wi-Fi 图标是断开的,然后开机瞬间连上 Wi-Fi 类似这样。 我的情况不是,我的是 Wi-Fi 在手机上一直上显示连接的
|
![]() |
23
JConlee 31 天前 ![]() 问了一下 gemini:
综合以上所有线索,最可能的原因是: 河北保定该县城区域的中国移动宽带,其网络出口处的 NAT 设备或防火墙,对 TCP 长连接设置了非常短的“会话保持时间” (Session Timeout) 或 “NAT 老化时间”,大约在 20 分钟左右。 详细解释: 墙中墙 (Wall within a Wall): 网友 LxnChan 提到的“墙中墙”是一个非常形象的说法。这并非指 GFW ,而是指运营商在自己的网络内部,由于设备、管理策略、成本控制等原因,设置的额外网络限制。小县城的网络设备和配置策略,往往与大城市(如北京)不同,可能会更“激进”地回收网络资源。 TCP 长连接被“杀死”: 你的 iPhone 在连接 Wi-Fi 后,会与苹果 APNs 服务器建立一个 TCP 长连接(通常在 5223 或 443 端口)。 为了维持这个连接,即使没有消息,设备和服务器之间也会有定时的心跳包 (Keep-Alive) 来“保活”。 然而,你所在区域的移动宽带网络设备(可能是汇聚层交换机、BRAS 或出口防火墙)有一个规则:如果一条 TCP 连接在 20 分钟内没有“足够”的数据流量通过(心跳包可能被设备认为是非活动流量),就强制将其从会话表 (Session Table) 中清除,也就是“超时关闭”。 这种关闭是单方面的,它不会通知你的 iPhone 或苹果服务器。因此,在接下来的时间里,你的 iPhone 依然以为连接是好的,苹果服务器也以为连接是好的。 当有新消息时,苹果服务器通过这条“已经死亡”的连接发送推送,但消息石沉大海。 直到你点亮屏幕,iPhone 恢复网络活动,尝试通过该连接通信时才发现“路不通了”,于是立即重新建立连接,接收所有积压的消息。 为什么 longfei210 提到的 DHCP Lease Time 可能是个思路? longfei210 提到的“增加 DHCP 租期”解决问题,虽然 OP 换路由器没解决,但原理是相通的。DHCP 租期过短(比如 10 分钟),会导致设备频繁重新获取 IP ,这个过程也可能中断网络,从而影响长连接。不过,从 OP 的描述来看,TCP 超时问题的可能性远大于 DHCP 问题。 给楼主的建议 既然已经和 Apple 技术团队沟通,并且他们确认了问题,这是最好的进展。在与移动沟通时,可以尝试提供更技术性的描述: “你好,我家的移动宽带存在一个问题。所有苹果设备在 Wi-Fi 熄屏 20 分钟后都无法接收推送消息。经过排查,基本确定是贵公司在我这个区域的网络设备对 TCP 长连接的会话超时时间( Session Timeout )设置过短,导致设备与苹果推送服务器( APNs )的连接被强制中断。这个问题在北京的移动宽带上不存在,是地区性的网络策略问题。能否请技术人员检查并调整相关网络设备的 NAT 老化时间或 TCP 会话保持时间?” 这种具体的技术描述,比单纯说“收不到消息”更有可能让对方的高级技术人员理解并解决问题。 总结:这几乎可以肯定是地方运营商网络策略导致的 TCP 长连接超时问题。这是一个典型的、非用户侧能完美解决的 ISP 问题。 |
24
Rhianu OP @JConlee 哈哈,感谢感谢。我的确确实是类似的话术跟移动这么沟通的,我跟他们说就是 TCP 长连接被莫名其妙的挂起了。 目前他们已经承认这边的移动和苹果的通知有问题,但是因为小县城技术能力有限,他们对我的内容都是一知半解的。
|
26
datocp 31 天前 via Android
iPhone 手机熄屏 20 分钟后收不到消息,那么亮屏 20 分钟后能收到消息嘛。。。
|
27
Rhianu OP @datocp 没有这样具体测试,但是可以肯定是手机如果在使用状态,是完全没问题的。 如果是 23 楼的长连接问题导致的,理论上来说亮屏和熄屏的本质是 TCP 数据包的活跃,那如果数据包不活跃的话,亮屏和熄屏理论上应该是一样的表现。
|
29
zhangyou1010 31 天前
携号转网,换电信
|
![]() |
30
aduangduang 31 天前
其他手机在同网络环境下有这样的问题吗?
|
31
Leez088 31 天前
安卓手机会有这种问题吗
|
![]() |
32
Comodo 31 天前
这个问题感觉应该算是很明显的,
我这边朋友换苹果设备给自己账号设置头像不显示,我就说你把 Wi-Fi 关了,用流量就看到了😂 |
![]() |
33
nolan1864 31 天前 via iPhone
@longfei210 我觉得没啥用。在路由器侧持续 ping 手机 ip ,息屏后过一段时间也会断开,不过再过一会会恢复。感觉就是息屏后隔一段时间连一下网的样子。试了好几个路由器都是这个样子,数据则不会断。
|
![]() |
34
xinzhanghello 31 天前
原来真有人会用移动的宽带
|
![]() |
35
0312birdzhang 31 天前
@xinzhanghello 毕竟当年可以不要钱用一年,一年后可以通过一些操作继续免费用
|
37
littlewing 31 天前
不应该是宽带的问题,如果是宽带的问题会有很多人出现这个问题,而且你是熄屏的时候才出现,问题大概率出在 7 楼说的你的路由器和苹果的兼容性问题
|
![]() |
38
PPPaul 31 天前 via iPhone
@nolan1864 不知道你说的是不是 ios 的后台机制吧,我试过基本上十分钟左右后台会休眠,然后隔几分钟唤醒一下连接网络,周而复始,我实在 network extension 里面测试的
|
40
fengkookoo2 31 天前
微博问下 tombkeeper ,网络安全高手
|
![]() |
41
nolan1864 31 天前 via iPhone
@PPPaul 我不确定是不是就我自己这样,但感觉不是什么路由器的问题。把手机数据关了,路由器 ping 手机,然后息屏,我这里应该一两分钟就 timeout 了,不确定安卓手机什么情况。
|
43
wymam 31 天前 via Android
这个应该是 dns 问题,你试试 dhcp 设置把移动 dns 直接下发给终端或者手动在苹果设备里设置移动 dns 基本就解决了
|
44
ttvast 31 天前 ![]() @JConlee 你这个推理有个漏洞,既然这个 TCP 长链接通过 Keep-Alive 来维持, 那么当链接断开后,Keep-Alive 也有能力检测到链接的断开,从而重新链接。
|
45
gwbw 31 天前
提供一个控制变量的思路:息屏,但是保持手机网络活跃——打开一个直播间,开启后台播放,息屏放声音。如果这个状态下 20 分钟后能收到消息,那可能真是前面提到的长连接问题。
|
46
questionyu 31 天前
@JConlee #23 这不就是以前 FCM 遇到的问题么,没想到苹果也要如此被对待了?
|
![]() |
47
Kenshiro 31 天前 via iPhone
其实就是🧱的问题,编制内的朋友表示现在不翻几乎接不到推送
|
![]() |
48
flynaj 31 天前 via Android
桥接用 openwrt 24.10 拨号,国内这些光猫用的上老版本的 op
|
49
Rhianu OP |
![]() |
50
JConlee 30 天前 ![]() @ttvast 猜测:对于 iPhone 来说,它只是发了一个包,然后没有收到任何回应(既没有收到预期的 ACK 确认,也没有收到 RST 错误)。在正常的网络活动中,TCP 协议栈在几次重试失败后,会很快判定连接超时并关闭连接。但是,iPhone 在熄屏状态下,一切行为都以“省电”为最高优先级。为了省电,操作系统会大幅延长 TCP 的 RTO 。它不会像亮屏时那样,在几百毫秒或几秒后就积极重试,而是可能会等待几十秒甚至数分钟才进行下一次尝试。并且,系统不会轻易地因为几次 Keep-Alive 失败就判定连接“死亡”。因为它需要平衡“维持连接”和“节省电量”这两个目标。频繁地断开重连会消耗大量电量。因此,系统宁愿“相信”连接只是暂时网络抖动,而不是真的断了。
|
![]() |
51
hideonwhere 30 天前
以前我用联通的时候也是,手机待机就是失联,直接弃用苹果和联通了。坐标深圳
|