概述：手机显示5G满格，网页却转圈到死——这类“假在线”故障，无线侧查不出毛病，DNS也洗脱嫌疑，真正的问题往往藏在核心网深处那条不起眼的N4接口上。本文复盘2025年秋某省会城市5G SA网的一次真实脱敏案例：一次看似无害的防火墙参数优化，如何让SMF与UPF之间的PFCP心跳“有去无回”，进而让整片城区的5G用户面陷入黑洞。文章以3GPP TS 29.244规范为解读主轴，给出完整的排障时间线、根因算术、监控盲区分析与整改检查清单，供一线核心网与承载网同事参考。
那是2025年10月的一个周四，凌晨00:25，我手机开始连续弹用工单：城区多个区片的5G用户集中反映“信号满格，上不了网”。微博本地超话里已经有人吐槽，12345转来的申诉单开始爬坡。
值班同学拉出的现象画像很典型：
这个组合排除了很多嫌疑人：无线侧如果出问题，信号格和接入就不该正常；DNS出问题，通常表现为部分域名解析失败而不是全部超时；鉴权出问题，用户会直接掉网重选，而不是“假在线”。典型的用户面黑洞：控制面还活着，手机和AMF相安无事，但SDF（业务数据流）背后的GTP-U隧道已经断了。
影响面初步评估：受影响的是该市5G SA数据话务的约三成，对应一个UPF资源池（下称UPF集群A）承载的全部PDU会话。集群A背后是当周刚完成割接的一对域间防火墙——这个信息当时还没人把它和故障联系起来，直到三小时后。
要看懂这起故障，得先把N4接口的来龙去脉讲清楚。
4G的EPC时代，服务网关SGW的控制面和用户面长在一个盒子里。R14引入CUPS（控制面和用户面分离）后，这个盒子被拆成了SGW-C和SGW-U，两者之间定义了Sxa接口。到了5GC，这个思路成了先天架构：SMF管信令，UPF管转发，中间的接口就叫N4，跑的协议是PFCP（Packet Forwarding Control Protocol），由3GPP TS 29.244《Interface between the Control Plane and the User Plane functions; Stage 3》定义（3gpp.org/dynareport/29244.htm，可从ETSI官网免费下载全文PDF，见文末参考来源[1][2]）。
SMF要在UPF上装一条转发规则，整个交互长这样：
PFCP有几个和传统电信信令不一样的脾气，这正是本案的伏笔：
顺便说一句，标准在心跳周期、重试次数等参数上给出了建议默认值，但明确允许运营方和厂家调整，各网络实际配置差异很大，具体以本网参数表和厂家官方文档为准。本文案例中的取值，是案发网络的实配。
| 时间 | 事件 |
|---|---|
| 23:40 | 安全部门执行域间防火墙策略优化割接（涉及UDP会话参数收紧） |
| 00:12 | 网管告警：UPF集群A的N4会话建立成功率跌破90%，持续走低 |
| 00:25 | 热线工单涌入，城区5G用户集中反映无法上网，4G正常 |
| 00:40 | 核心网值班初判：用户面黑洞，锁定SMF-UPF集群A链路，暂停后续变更 |
| 01:10 | 在SMF侧N4口抓包：Heartbeat Request发出后无Response回包 |
| 01:50 | 复核当晚防火墙变更单：UDP空闲会话老化180秒→30秒 |
| 02:20 | 防火墙回退老化时间，并补齐N4双向放通，心跳恢复 |
| 03:05 | 用户重新发起会话建立成功，指标复位，转复盘 |
值班同学的排查路径值得完整讲一遍，因为这是5GC运维的经典决策树：
第一步看KPI分层。无线上线率正常、NAS注册成功率正常，说明接入和鉴权没问题；N4会话建立成功率从99.9%跳水到不足90%，且失败集中在集群A对应的SMF实例——用户面的嫌疑立刻最大。
第二步看日志。SMF日志里刷PFCP会话建立失败，Cause指向请求超时而非资源拒绝——注意这个细节，“超时”和“拒绝”是两种完全不同的病：拒绝说明对端活着但给不了资源，查容量和配置；超时说明报文根本没走通或者对端已经“死了”，查链路和中间设备。
第三步抓包定罪。在SMF侧N4口镜像抓包，用Wireshark的pfcp过滤器（Wireshark原生支持PFCP解析），按序列号（Sequence Number）对齐请求和响应，画面非常直观：Heartbeat Request一条条发出去，对面鸦雀无声。再做一步反向抓包——在UPF侧入口抓，能看到Request其实到了UPF，UPF的Response也发出了，但回包在中间的防火墙上消失了。
sequenceDiagram
participant S as SMF
participant F as 防火墙
participant U as UPF
S->>F: Heartbeat Request 序列号1001
F->>U: 命中会话表 放行
U-->>F: Heartbeat Response
F-->>S: 回程命中动态表项 转发
Note over S,U: 变更前稳态：心跳周期60秒 持续刷新180秒老化的表项
S->>F: 变更后 Heartbeat Request
F->>U: 首包 重建30秒老化的表项
U-->>F: Heartbeat Response
Note over F: 表项已到期 回包被判为未知入向流丢弃
S->>S: 重试连败 拆除PFCP关联
到这里，故障域从“核心网还是承载网”收缩到“那对防火墙”。调出当晚变更单，一切对上了：安全部门为了收紧暴露面，把域间防火墙的UDP空闲会话老化时间从180秒压到了30秒，同一批变更还顺带清理了“冗余”的明细放通策略，N4口全靠动态建会话通行。
排障全过程的决策逻辑如下：
flowchart TD
A["5G假在线<br/>有信号无数据"] --> B["网管KPI分层"]
B --> C{"N4会话建立<br/>成功率异常?"}
C -->|异常| D["查SMF日志<br/>超时还是拒绝"]
C -->|正常| E["转查无线侧<br/>与DNS分支"]
D --> F["N4口双向抓包"]
F --> G{"心跳有去<br/>有回吗?"}
G -->|无回包| H["查中间设备<br/>防火墙与NAT"]
G -->|有回包| I["查Cause与容量<br/>看UPF资源配置"]
H --> J["比对当晚变更单<br/>老化与放通策略"]
J --> K["回退参数<br/>心跳恢复 复盘归档"]
把根因写成一道算术题，就一目了然了。
变更前的稳态：心跳周期60秒，防火墙UDP空闲老化180秒。每次心跳经过，防火墙就刷新一次会话表项的“最后活跃时间”。表项寿命是心跳间隔的3倍，链路稳如老狗。这套配置能跑两年，不是因为设计得多好，而是因为参数恰好相容。
变更后的死局：老化30秒 < 心跳周期60秒。发完一次心跳，30秒后防火墙表项到期销毁；下一个心跳（第60秒）作为“首包”重新建表，放行Request到达UPF；UPF立刻回Response——但这次回程不再命中“已放行的会话表”，因为对防火墙来说这个方向上根本没有活跃会话，Response被默认策略丢弃。SMF侧看到的现象就是心跳超时，重试数次后按规范拆除PFCP关联。
更狠的是连锁反应：关联一拆，SMF重建会话的每一个Session Establishment Request同样过不了这堵墙（时灵时不灵，取决于表项生死），N4会话建立成功率掉到90%以下；已在UPF上的存量会话，随着关联释放，转发规则被清空，GTP-U隧道成了断头路。用户手机的5G图标由AMF的NAS状态驱动，照样显示满格5G——数据通道空了，控制面还在。
一句话总结：不是谁“攻击”了网络，是一次善意的安全加固，把心跳的呼吸间隔压得比防火墙的记忆还短。这类“参数各自都对、拼在一起就死”的故障，是跨域组网里最阴险的一类——每个专业单独看自己的参数表都没错，错的是两个专业的参数从来没有人放在一张纸上对过。
复盘时最扎心的问题是：心跳断了20多分钟才通过用户投诉兜底发现，监控系统去哪了？
三个盲区，层层漏光：
这次故障是不小心把心跳掐死了，而PFCP的另一个隐忧是主动暴露：N4接口跑在UDP 8805上，协议本身没有原生的认证和加密。Oracle通信2021年发布的5G核心网安全报告就点名过PFCP缺乏认证机制的问题；在海外一些网络里，安全研究员扫描发现公网可达的8805端口并不罕见。
Palo Alto Networks旗下Unit 42团队2021年发布的研究《Attackers Abuse PFCP to Conduct DDoS Attacks》（unit42.paloaltonetworks.com/attackers-abuse-pfcp-to-conduct-ddos-attacks）演示了攻击者如何把公网暴露的PFCP端点当作反射放大器，向受害者发起DDoS攻击——原理和经典的反射放大一致（见Cloudflare对反射放大攻击原理的科普，参考来源[4]），只是载体从memcached、SSDP换成了电信专属的PFCP。对运营商而言这意味着两重风险：外部被当炮架打别人，招来监管问询；内部若N4可达面被渗透，攻击者可以伪造会话操作，直接操纵用户面转发。
好消息是，后续版本的标准与产业实践已在补课：TS 29.244为PFCP扩展了IPsec和TLS类安全机制的适配路径，业界也普遍建议N4接口严格限定在专用隔离域内、禁止跨互联网明文可达。标准允许多种安全部署形态，具体做法以各厂家官方文档与本网安全基线为准。本案中那对防火墙“误伤”心跳固然是事故，但反过来讲，域间防火墙的存在本身，就是N4不该裸奔的证明——要做的是把它的参数和核心网参数对齐，而不是把它拆了。
这起事故的整改清单，我后来整理成了核心网专项检查项，在好几个网络的巡检里都用过：
| 检查项 | 案例网整改前 | 整改后 |
|---|---|---|
| N4心跳周期 | 60秒 | 30秒（提高刷新频率，缩短盲窗） |
| 域间防火墙UDP空闲老化 | 30秒 | 不小于心跳周期的5倍（≥150秒） |
| 心跳专项监控 | 无 | 心跳失败率>0即告警，往返时延设双阈值 |
| N4承载方式 | 与普通业务流量共防火墙域 | 划入核心网隔离域，减少中间设备 |
| 变更会签 | 安全线独立审批 | 跨域参数变更强制核心网专业会签 |
| 故障预案 | 无N4专项预案 | 心跳全断一键核查卡（抓包点、比对项、回退项） |
三条经验，值得刻在脑子里：
5G SA网络把用户面从“盒子”里拆出来分散部署，换来了灵活和性能，也把N4这条“看不见的线”铺得越来越长。线越长，掐住它的手越多。下次再遇到“满格5G上不了网”，先别骂无线——去抓一把8805端口的心跳，看看它是不是又被谁悄悄捂住了嘴。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。