安卓推送通知在 VPN 下收不到？逐项排查这些原因

在一部平时能通过公司 VPN 正常上网的手机上，通知却收不到了。网页能打开，应用也能启动，但消息只在家庭网络下或关闭隧道后才出现。对于基于 Firebase Cloud Messaging 的应用，推送通道是一条独立的、长连接的出站连接，并不是浏览器刚刚验证过的那条 HTTPS 路径。按顺序完成下面的检查，遇到第一项失败就停下。

确认应用确实在使用 FCM

并非所有通知都是推送。有些由应用本地定时触发，有些通过 HTTPS 轮询，还有一些走与 Firebase 无关的厂商通道。如果应用的清单文件和依赖中包含 Firebase Messaging，其通知通常走 FCM 连接，客户端库会在一个可预期的标签下记录注册信息。

adb logcat -s FirebaseMessaging:V
adb shell dumpsys package <package> | grep -i firebase

日志里出现注册令牌，就说明走的是这条传输通道。没有令牌，你排查的是应用层的通知链路，改防火墙不会有帮助。这个区分很重要，因为已送达却从未显示的消息，和根本没有到达的消息，在用户看来完全一样。

检查出站端口，而不是网站

FCM 的设备连接是由设备发起的 TCP，目标是 5228 端口，5229 和 5230 作为备用，443 作为最后手段。允许 443 用于浏览的防火墙仍可能让推送失效，而只放行某个应用 API 域名的规则并不覆盖消息端点，后者是独立的服务。

这些连接都是从手机发出的。你不需要在设备或 VPN 网关上发布入站端口，所以如果有人建议做端口映射，方案本身就已经错了。同理，把某个端口对互联网上所有地址开放也不可取：应当只限定在文档列出的目标上。

Firebase 的网络说明 也指出，FCM 的投递协议无法通过普通 HTTP 代理传输。因此浏览器能通过企业 Web 代理上网，并不能证明推送套接字可用：这是两个不同的客户端，路径也不同。

检查会切断套接字的空闲超时

FCM 连接在消息之间保持打开，因此对 NAT 和有状态检测的超时很敏感。Firebase 的说明要求在适用此类策略的环境中至少保留 30 分钟的空闲容忍时间。五分钟的会话超时会悄悄删除映射，手机只有在被唤醒时才会重连，于是消息成批到达，或者干脆不来。

读取防火墙或 VPN 网关上的会话表，找到手机到 5228-5230 的连接。把它的剩余寿命与文档值比较。若更短，应针对这些端口调高超时，而不是改动设备上的全部策略，因为全局超时改动难以论证，撤销起来更难。

推送投递还取决于端点映射能否在 Wi-Fi 与蜂窝网络之间切换时存活。绑定在单一接口上的映射，即使两个网络都放行端口，也可能在切换时被丢弃。

判断能否接受绕过 VPN

安卓 VPN 客户端可以允许流量绕过隧道，FCM 在这种绕过被允许时可能使用底层网络。此时推送通道仍然加密，但不再携带隧道的地址，VPN 的 IP 隐藏对它不生效。这是策略上的取舍，不是故障。

如果策略禁止绕过，隧道就必须承载这条连接：端口开放、超时足够长、代理不挡路。不要悄悄排除某个受管服务，也不要仅仅因为通知在非受管网络上能用就放松管控。VPN 图标不会告诉你某个服务实际走了哪条路径

把投递和显示分开，然后只测一次

权限、渠道设置、勿扰模式和各个应用的开关决定已送达的消息是否会显示。在 Android 13 及更高版本中，通知权限是运行时授予的，被拒绝时会出现与端口被封完全一样的安静。到了却没有显示的消息属于展示问题，要单独处理。

与其随手发消息，不如做一次受控测试。保持设备、账号和应用不变，发送一条带已知时间戳的消息，并把 VPN 环境与已获批的无 VPN 网络对比。记录每次运行的 logcat 接收时间和显示时间。若投递不同而显示相同，变量是网络路径；若两者一致，就继续从应用侧找原因。

把端口、代理限制、实测超时和绕过决策写成一页交给网络负责人。「把 VPN 关掉」不是结论，放行全部 Google 流量也不是有针对性的修复。