## 概述 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按老隧道发的下行包就是干脆蒸发。 ```mermaid flowchart TD A["手机静置 无流量"] --> B["应用服务器下发推送"] B --> C["UPF 按原隧道封装下行"] C --> D{"防火墙会话表"} D -->|"表项还在"| E["送达基站 正常收到"] D -->|"空闲已老化"| F["包被静默丢弃"] F --> G["手机一直转圈"] A --> H["信令面一切正常
KPI 全绿"] ``` 为什么“转圈十几秒又好了”？用户解锁的瞬间，应用层并发发出一串上行请求——上行包在防火墙上重建了会话，随后下行自然就通了。丢失的只是静默期里到达的那几条推送，其中就包括没打进来的微信语音。症状、机理，严丝合缝。 ## 三、定位：三小时抓包实录 | 时间 | 动作 | 看到什么 | 结论 | |---|---|---|---| | 14:10 | 投诉涌入，开始排查 | 投诉形态高度一致：静置后失联 | 疑点指向共网段 | | 14:35 | 查无线与核心网KPI | 建立、寻呼、掉话全绿 | 排除空口与信令面 | | 15:02 | 测试机复现：静置40分钟 | 必现；静置5分钟不现 | 与“空闲超时”类特征吻合 | | 15:30 | UPF出口与基站侧对点同时抓包 | 上游有下行GTP-U包，下游没有 | 包死在中间设备 | | 16:15 | 查防火墙会话与日志 | 大量GTP-U报文被丢弃，理由是会话不存在或已老化 | 根因锁定 | | 17:00 | 调参并拨测验证 | 静置一小时的测试机推送秒到 | 修复确认 | 这套流程里最值钱的一步是**对点抓包**：在UPF出口和基站入口同时抓，上游有、下游无，中间设备无处遁形。抓包是排障里最笨的手筋，也是最诚实的手筋——日志会说谎，KPI会缺位，但线上的包不会。当然，抓包点要选对：S1-U/N3用户面是第一嫌疑，别在信令接口上浪费时间——本案里信令面确实一身清白。 ```mermaid 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救不了每条隧道，还是得回到药一调超时。 | 计时器 | 量级（工程经验） | 谁配的 | 备注 | |---|---|---|---| | 基站无线不活动计时器 | 秒级 | 无线侧 | 决定手机多快进省电态 | | IM类应用心跳间隔 | 数分钟到十几分钟 | 互联网侧 | 本网不可控，只能适配 | | 防火墙UDP会话老化 | 几十分钟级常见，各厂家不一 | 数通侧 | RFC 4787给NAT类设备定了两分钟底线 | | GTP感知检测的隧道老化 | 几十分钟级常见，各厂家不一 | 数通侧 | 本案根因；数值以各厂家官方文档为准 | | GTP-U 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](https://www.3gpp.org/dynareport/29281.htm) — GTP-U协议规范，UDP 2152承载、TEID结构、Echo Request/Response路径保活的权威出处 2. [3GPP TS 23.501: 5G系统架构](https://www.3gpp.org/dynareport/23501.htm) — PDU会话、寻呼与服务请求流程的架构依据 3. [RFC 4787: NAT UDP行为要求](https://www.rfc-editor.org/rfc/rfc4787) — UDP映射保活与刷新底线的标准依据 4. [GSMA IR.77: Inter-PLMN Backbone Guidelines](https://www.gsma.com) — 运营商间承载网与跨网GTP-U保活指引（文档编号IR.77，GSMA官网检索获取） 5. [ShareTechnote GTP专题](https://www.sharetechnote.com) — 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 等场景全覆盖。