概述

2026年秋天，某省网大批用户投诉同一件事：手机在桌上安静躺四十分钟，拿起来满格信号，微信却在原地转圈，语音来电整批漏接。无线指标全绿、核心网指标全绿，问题出在哪？本文以一次三小时的真实排查为主线，还原定位过程：根因不在基站，不在AMF，而在防火墙肚子里那本会话账——GTP-U隧道状态被空闲老化，下行数据被静默丢弃。文章讲清机理、给出可抄的排查路径、修复参数与监控补法，供核心网与数通两个工种对照自查。

目录

• 一、满格信号下的转圈投诉
• 二、机理：防火墙肚里那本会话账
• 三、定位：三小时抓包实录
• 四、修复：三味药，各治一头
• 五、放大器：漫游与边缘机房
• 六、教训：把「静默」当成指标

一、满格信号下的转圈投诉

投诉是下午两点十分涌进来的，形态高度一致：上午还好好的，午休回来手机就“半死”——打开微信转圈十几秒才缓过来，期间别人发的消息、打的语音电话全部没收到，解锁后也不补送。受影响用户集中在几个地市，但机型、号段、套餐全打散，2G老手机没人投诉，智能机投诉扎堆。

值班同事第一反应是查无线。附着成功率正常，PDU会话建立成功率正常，寻呼成功率正常，掉话率曲线平得像尺子画的。查核心网，AMF/SMF无告警，UPF流量曲线只有轻微毛刺。所有“建立类”指标全绿——可用户感知明明塌了。

这就是这类故障最阴的地方：建立类KPI量的是“能不能连上”，保持类体验取决于“连上之后、没话说的那些分钟里，路通不通”。前者我们有几百个计数器盯着，后者一个计数器都没有。手机满格，说明空口信令好好的；信令好好的，说明问题大概率在用户面的“静默期”里——那是一段没人看的时间。

二、机理：防火墙肚里那本会话账

要讲清这事，得先讲状态防火墙怎么记账。

运营商级防火墙的核心是一张会话表：每个流过它的连接记一行，五元组加方向加计时器。TCP有握手挥手，连接生死分明；UDP没有连接的概念，防火墙只能靠空闲超时——超过设定时间没有报文刷新，表项就删。这是数通世界的常识，也是RFC 4787对NAT类设备的通用要求：UDP映射的保活刷新底线是两分钟，超时即删。目的很朴素：表项是资源，不删迟早撑爆。

再看移动网这边。GTP-U——按3GPP TS 29.281的定义——承载在UDP 2152端口上，手机每条PDU会话（4G里叫EPS承载）在S1-U/N3/N9各段都有隧道，隧道靠头里的TEID区分。关键在于：隧道不是“有流量才存在”的，它是随会话建立的，会话活多久它活多久。现代智能手机的PDU会话动辄挂几个小时甚至一整天，而用户的实际流量是脉冲式的：刷两分钟，静十分钟，再刷两分钟。

把这两边拼起来，故障机理就浮出来了：

• 手机静置，无线侧把它挪进省电状态，隧道还在，TEID没变，只是没流量；
• 应用服务器下发推送，UPF按原来的TEID封装下行包，发往基站方向；
• 中途的状态防火墙一查表：这条GTP-U会话的空闲时间早就超过老化阈值，表项已删——陌生的包，丢；
• 手机端收不到任何东西，而它自己没有主动发包的动机，死锁形成。

更拧巴的是恢复路径。如果无线侧已经把手机放进了空闲态，下行数据本该触发寻呼、服务请求、空口与传输重建——但这条恢复链路全程是信令，不经过用户面，给防火墙刷新不了任何表项。等到用户面真正恢复、第一个下行包过来时，它面对的还是那张已经删掉的账。而如果手机只是屏幕亮着、应用心跳间隔拉得很长（IM类应用的心跳周期，长的能到十几分钟量级），连寻呼都省了，UPF按老隧道发的下行包就是干脆蒸发。

flowchart TD
    A["手机静置 无流量"] --> B["应用服务器下发推送"]
    B --> C["UPF 按原隧道封装下行"]
    C --> D{"防火墙会话表"}
    D -->|"表项还在"| E["送达基站 正常收到"]
    D -->|"空闲已老化"| F["包被静默丢弃"]
    F --> G["手机一直转圈"]
    A --> H["信令面一切正常<br/>KPI 全绿"]

为什么“转圈十几秒又好了”？用户解锁的瞬间，应用层并发发出一串上行请求——上行包在防火墙上重建了会话，随后下行自然就通了。丢失的只是静默期里到达的那几条推送，其中就包括没打进来的微信语音。症状、机理，严丝合缝。

三、定位：三小时抓包实录

这套流程里最值钱的一步是对点抓包：在UPF出口和基站入口同时抓，上游有、下游无，中间设备无处遁形。抓包是排障里最笨的手筋，也是最诚实的手筋——日志会说谎，KPI会缺位，但线上的包不会。当然，抓包点要选对：S1-U/N3用户面是第一嫌疑，别在信令接口上浪费时间——本案里信令面确实一身清白。

flowchart TD
    A["静置后收不到推送"] --> B["查无线与寻呼指标"]
    B -->|"全绿"| C["测试机复现静置"]
    C --> D["UPF 出口抓包"]
    D --> E{"下行包发出没"}
    E -->|"没发"| F["查UPF与PFCP状态"]
    E -->|"发了"| G["基站侧对点抓包"]
    G --> H{"对面包到没"}
    H -->|"没到"| I["查中间防火墙会话"]
    I --> J["定位: 会话老化丢弃"]

还有一条经验值得写进值班手册：满格信号不等于用户面通。一线受理看到“信号满格却上不了网”，条件反射是查覆盖查干扰，但本案里覆盖从头到尾没问题——账本被人翻了页而已。

四、修复：三味药，各治一头

药一：把GTP会话的空闲老化时间调长。定值原则是“最长静默期加余量”。应用的空闲心跳间隔我们管不着，长的按十几分钟量级估，再叠加省电策略拉长的间隔，建议老化时间放到一小时量级起步，具体数值结合本网防火墙的表项容量评估后定——表项占用会随老化时间线性涨，容量和时长要一起算，不能拍脑袋给个24小时把表撑爆。

药二：对内网用户面网段放宽逐隧道检测。S1-U、N3、N9这些段落在物理上都是自己的地盘，安全模型允许的话，改成基于地址对/端口的放通策略，不做GTP感知的逐隧道跟踪。隧道粒度的记账比五元组更细，过期得也更快，能不用就不用。哪些段能放、哪些段必须保留深度检测，要过安全评审，不是运维单方面说了算。

药三：缩短用户面静默。应用侧的心跳管不了，但UPF侧有标准件：TS 29.281定义了GTP-U的Echo Request/Response报文，专门做路径保活，周期性发Echo可以把路径级状态刷新住。注意一个容易踩的坑——Echo保的是“路径”（远端IP粒度），不是每一条隧道。对只按五元组记账的设备，Echo能救命；对按隧道粒度做GTP感知检测的设备，Echo救不了每条隧道，还是得回到药一调超时。

说明一句：表里的量级是工程经验值，不是任何厂家的默认值承诺——标准允许多种实现，具体行为以各厂家官方文档为准。

变更纪律照旧：这类改动动的是用户面的“交通规则”，必须走割接窗口，先对一个POOL灰度，配合双灯塔用户加拨测脚本验证——脚本逻辑很简单：测试机静置N分钟，远端发推送，看到达时延。N取覆盖最长静默期的值，比如六十分钟。

五、放大器：漫游与边缘机房

有两个场景会让这个问题成倍放大，值得提前设防。

第一个是漫游。用户出了国，用户面要穿越运营商间网络（IPX），拜访地与归属地的UPF之间隔着运营商间防火墙和NAT——那本“会话账”又出现了，而且这回的记账人不是自己人，老化策略完全看不见摸不着。GSMA的IR.77《Inter-PLMN Backbone Guidelines》对跨网承载的保活给出过指引，业界通行做法就是周期性发GTP-U Echo把中间设备的状态刷新住。“出国后信号有、收不到推送”的投诉里，有一部分查到最后就是这类中间设备状态问题，排查时别一头扎进拜访网的无线侧出不来。

第二个是边缘机房。UPF下沉到边缘已是通行做法，防火墙跟着一起下沉。边缘盒子空间、功耗、表项容量都抠得紧，出厂老化配置普遍偏保守，恰恰是问题最容易冒头的环境。新边缘机房上电验收时，建议把“静默期专项测试”加进验收用例：放一台测试机进去静置一小时，收不到推送就不给验收签字。

六、教训：把「静默」当成指标

这单故障修完，值得留下三条制度化的东西。

第一，补一类拨测。现有KPI体系全是建立类指标，对“静默期用户面是否还通”零覆盖。补一种探针：定时器每半小时唤醒一次测试机收推送，记录到达时延和丢失率，曲线一旦抬升就告警。这种拨测成本极低，却能盯住KPI全绿之下的盲区。

第二，把防火墙纳入网络资产生命周期。数通设备在多数核心网团队那里是“哑盒子”，策略多年没人复审。这次之后应立规矩：任何防火墙策略变更走和核心网一样的变更管理，任何新增用户面路径的设备上线前必跑静默期测试。

第三，也是最根本的一条认知：信令面把隧道管得井井有条——建立、修改、释放、寻呼，一环不落；但用户面的包在穿过别人的设备时，生死取决于那张我们没有写入权限的会话表。核心网工程师的地图上，必须把防火墙、NAT这些“别人家的盒子”画进来，哪怕它不归你管。它不出告警，不代表它没在影响你的用户。

参考来源

1. 3GPP TS 29.281: GTPv1-U — GTP-U协议规范，UDP 2152承载、TEID结构、Echo Request/Response路径保活的权威出处
2. 3GPP TS 23.501: 5G系统架构 — PDU会话、寻呼与服务请求流程的架构依据
3. RFC 4787: NAT UDP行为要求 — UDP映射保活与刷新底线的标准依据
4. GSMA IR.77: Inter-PLMN Backbone Guidelines — 运营商间承载网与跨网GTP-U保活指引（文档编号IR.77，GSMA官网检索获取）
5. ShareTechnote GTP专题 — GTP-U报文结构与TEID机制的工程师向科普资料

本文由「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 等场景全覆盖。