会话老化：越用越断的隐形故障

概述

有一类故障最容易被误诊：手机显示满格 5G、注册成功、会话建立成功，网管各项 KPI 全绿，可用户就是上不了网；重启网元无效、查日志无告警、翻遍配置找不到异常——因为问题根本不在信令面，而在用户面与中间设备之间那层没人管的会话状态。本文以一起脱敏复合案例为主轴，锚定 3GPP TS 32.421/32.422/32.423 的信令追踪（Trace）体系、TS 29.244 的 N4/PFCP 会话模型，讲透三件事：为什么"长连接"遇上"会话老化"必然出事；如何用六层取证链把这类故障从"KPI 全绿"里挖出来；以及故障发生后那个越来越短的取证保鲜期，为什么越晚动手越查不动。

目录

• 一、越用越断：一类最容易被误判的故障
• 二、六层取证链：每一层只回答一个问题
• 三、第一层到第三层：观察、会话、报文
• 四、实战复盘：七小时里逐渐失灵的专网
• 五、第四层到第六层：状态、变更、复现
• 六、抓包点速查：接口、端口与过滤串
• 七、取证保鲜期：越晚动手，能看到的越少
• 八、工具链：把实验室建成风洞
• 九、五条铁律
• 结语：让故障在年轻的时候被抓住

一、越用越断：一类最容易被误判的故障

先说一类故障的共同画像。

它的第一个特征是控制面完全正常。注册成功率 99.6%，PDU 会话建立成功率 99.5%，AMF、SMF、UPF 的 CPU、内存、会话数全部平稳，网管面板上一片绿。用户投诉"上不了网"，值班工程师的第一反应通常是"用户终端问题""家里宽带问题""APP 的锅"。

第二个特征是故障随时间漂移。早上零星几例，中午变成几十例，晚上高峰达到峰值；而每一台终端单独测试时，又往往是好的——因为新建立的会话是好的，只有"建立之后静置了一段时间"的会话是坏的。

第三个特征是重启无效。重启 UPF 会话表清空，新建的会话又能用一阵子；重启 SMF 无效；重启防火墙更糟，因为重启把表项清空，短时间内反而"全好了"，然后再次以同样的节奏失灵。

第四个特征是越用越断。同一部手机，上午还能刷视频，下午就完全没数据；连上 Wi-Fi 就正常，蜂窝数据就不行。

这四条拼起来，指向的是一个被长期忽视的地方：中间设备（防火墙、安全网关、NAT、负载均衡）的会话表项有自己的生命周期，而这个生命周期与电信业务的长连接特性，未必匹配。

电信网络的长连接特性是刻进骨子里的。5G SA 里，PDU 会话一旦建立就没有"心跳保活然后空闲释放"这回事——UE 静默不代表会话失效，运营商希望它一直留着（这是5G 相对 4G 的重要改进之一，也是移动性、寻呼、计费模型能成立的前提）。而很多安全设备的设计出发点恰恰相反：UDP 无连接、流表老化、默认几分钟不活动就回收——这是互联网领域的合理默认，因为互联网上的 UDP 大多是短时请求。

把这两个假设叠在一起，冲突就出现了：运营商认为会话还活着，中间设备认为会话早就该死了。终端下一次发包时，上行靠五元组还能被新建会话匹配上，但下行报文到达时，中间设备发现"这不属于任何活跃会话"，于是按未知流丢弃。用户侧看到的现象就是：上行像是通的（因为确实通了），下行凭空消失。

这类故障之所以难查，是因为它的根因在用户面，而绝大多数核心网监控体系盯的是控制面。PDU 会话建立成功率高，只能证明"门开了"，不能证明"货送到了"。

二、六层取证链：每一层只回答一个问题

一线排查失败，很多时候不是不会抓包，而是没有分层的取证顺序：一上来就抓包，抓到一堆包却不知道断在哪一跳；或者只盯 KPI指标，把一个用户面问题当成信令面问题查。

我个人的做法是把取证拆成六层，每层有明确的待答问题、取证工具和典型失效模式。这套分层是笔者十八年一线沉淀的经验模型，不是任何标准里的东西，标准负责定义每一层用到的协议与消息，模型负责决定先走哪一层。

flowchart TD
    A["第一层 观察层<br>KPI与告警"] --> B["第二层 会话层<br>单用户追踪"]
    B --> C["第三层 报文层<br>接口镜像抓包"]
    C --> D["第四层 状态层<br>表项与配置"]
    D --> E["第五层 变更层<br>工单与时间线"]
    E --> F["第六层 复现层<br>实验室还原"]
    F --> G["根因确认"]
    G -.->|回溯校验| A

这条链最关键的设计，是不允许跳层。观察层告诉你"有200 个用户上不了网"，会话层告诉你"这 200 个用户的会话建立都成功了"，报文层告诉你"上行到了 UPF、下行死在防火墙入口"，状态层告诉你"防火墙表项没有这条流"，变更层告诉你"两周前新增的安全策略段把会话超时改成了 300 秒"，复现层告诉你"我在实验室把超时调到 60 秒，故障一模一样"。六层走完，根因才叫根因。

少任何一层，结论都只是"很可能"。

三、第一层到第三层：观察、会话、报文

3.1 第一层：先把"范围"问对

第一层只有一件事要做对：判断故障的范围和时间分布，而不是急于定位。

三个必问的问题：

1. 是全局还是局部？ 全网注册成功率跌了 3 个点，和某个园区 200 个用户上不了网，是完全不同的事件。前者是容量或共性问题，后者是局部配置或局部路径问题。
2. 是时间相关还是状态相关？ 让用户分别做两个测试：关掉再打开数据（重建会话）试一次；保持连接静置十分钟后再试一次。如果"重建就好、静置就坏"，时间相关性已经成立，接下来就应该往"什么会随时间变化"上想——老化、证书、许可、计数器溢出、定时任务。
3. 是控制面相关还是用户面相关？ 最快的判断方法：让用户用一张已停机的 SIM 卡试（或者让用户在覆盖良好区域对比），同时看网管上该用户的 PDU 会话是否处于激活状态。会话在、数据不通，几乎必然是用户面或承载面的问题，跟 NAS、cause 值、鉴权一点关系都没有。

第三问尤其重要。5G 排查里最常见的浪费，就是明明是数据面不通，却花几个小时去查注册、查签约、查 cause 值——那些都是控制面。

3.2 第二层：信令追踪是"按用户串联"的唯一手段

如果第一层判断是"控制面正常、用户面不通"，那么第二层的任务其实很轻：确认控制面信令确实完整走完了。这里最有效的手段是 3GPP 信令追踪（Trace）。

按 TS 32.421 的概念框架，追踪是一套由管理面驱动的定向采样机制：运维向网元下发追踪激活指令，指定追踪范围（用户、网元或小区）、要采集的事件列表以及追踪时长；网元在指定时间段内按条件记录相关消息，随后把记录汇聚到追踪收集实体（Trace Collection Entity）统一导出。TS 32.422 定义追踪文件的格式与传输方式，TS 32.423 给出追踪管理的功能架构。

对运维来说，这套机制的价值可以用一句话概括：它按用户把跨网元的消息按时间戳串成一条链。

相比在 N2 口镜像抓包，追踪有三个实打实的优势：

• 跨网元连续。N2 口抓包只能看到 gNB 与 AMF 之间的消息，看不到 AMF 与 SMF 之间的 N11 调用；追踪能把 UE→gNB→AMF→SMF→UPF 的消息按同一时间轴排好。
• 按用户过滤。网管上一张投诉工单的 IMSI 输进去，出来的就是这个用户这一次的完整故事，同一时刻其他几万个用户不会被淹没。
• 消息语义可读。追踪文件里带着消息类型与关键 IE，不需要在几百兆的 pcap 里大海捞针。

追踪的代价也必须说清楚：

• 它是管理面动作，要预先开通。很多现网默认没有激活追踪的授权，开一次追踪往往要走审批、加开发票式的手续，等批下来，用户可能已经离网了。
• 它有开销、有采样。标准允许按事件类型采样，高频事件（心跳、周期上报）可能只记部分，这不是缺陷，是设计。追踪文件里"少了某些心跳"不等于"网络没发心跳"。
• 它不覆盖用户面。追踪是信令面机制，看不到 GTP-U 的数据包。它能证明"会话建立成功了"，不能证明"数据送到了"。

所以，第二层永远只是半场。

3.3 第三层：报文层要成对部署

进入第三层，纪律只有一个：抓包点必须成对部署。

单侧抓包会系统性地冤枉好网元。举个典型的冤案：在 SMF 侧抓 8805 端口，只看到 PFCP 请求反复重发、没有响应，看起来像 SMF 或 UPF 死了；在 UPF 侧再抓一次才发现，UPF 早就把响应发出来了，只是响应在出网卡之前被某个中间设备丢了。只看一面，你会把结论写反。

部署位置要贴着断点的两侧，而不是"随便找个服务器抓"。判断断点在哪一跳，会话层已经给出答案——N4 就在 SMF 和 UPF 各抓一个点，N3/N9 就在 UPF 和基站侧各抓一个点，SBI 就在调用方和被调方各抓一个点。

报文层有一个特别值得警惕的陷阱：中间设备的丢包，在两侧抓包里表现完全一样。UPF 侧抓包看到"上行到了、下行没离开 NIC"，防火墙镜像口抓包看到"报文进来了、没有对应会话表项"，两个证据叠起来，才能从"UPF 没发"升级为"防火墙丢了"。这中间的差别，就是责任边界的差别。

四、实战复盘：七小时里逐渐失灵的专网

下面这个案例来自笔者参与过的多起现网处置的复合重构，已做脱敏，数值取整，机制真实。它是本文方法论的一次完整走查。

4.1 背景与现象

某省政企 5G SA 专网，覆盖多个园区与工业用户，承载政企专线、园区监控与工业网关三类业务。全部用户面流量经新增的一台安全设备 F2 转发到出口。

D-14 日，传输侧完成一次变更：为 F2 新增安全策略段，放通 UDP 2152（GTP-U）、UDP 8805（PFCP）等端口。会话超时沿用了设备出厂默认段的值，未单独评估。

故障在 D1早高峰爆发。

4.2 一条被"绿色KPI"掩盖的失败路径

先看清这个故障在信令上是完全成功的：

sequenceDiagram
    participant U as 终端UE
    participant A as AMF
    participant S as SMF
    participant P as UPF
    participant F as 安全设备F2
    U->>A: 注册请求
    A-->>U: 注册接受
    U->>A: PDU会话建立请求
    A->>S: N11 创建SM上下文
    S->>P: N4 PFCP会话建立
    P-->>S: PFCP会话建立响应
    S-->>A: SM上下文建立应答
    A-->>U: 会话建立接受
    Note over U,F: 静默期超过F2会话老化时间
    U->>P: 上行数据包
    P->>F: 下行数据包
    F--xP: 无会话表项 按未知流丢弃
    P--xU: 用户面无数据

从 UE 到 AMF 到 SMF 到 UPF，链路完整，PFCP 会话按 TS 29.244 的模型建立成功——信令上没有任何一处出错。出错的是会话建立之后、终端静默的那段时间里，F2 的表项被悄悄清理掉了。

再看时间轴上的关系：

flowchart TD
    A["T0 会话建立成功"] --> B["终端转入静默"]
    B --> C["F2 记录会话表项"]
    C --> D["T0 加300 秒 表项老化清理"]
    D --> E["T1 终端再次发包"]
    E --> F["上行新建匹配 可通过"]
    F --> G["下行无表项 被丢弃"]
    G --> H["用户感知 时好时坏"]

这就是"越用越断"的完整机理：故障点是"静默时长超过老化阈值"这个交叉点。用户频繁使用的时段（通话中、视频中）不受影响，因为会话持续有流量、表项被刷新；用户最需要网络的时段（早上刷消息、中午休息、下午办公间隙）恰恰是静默期，最容易踩雷。这也解释了为什么投诉集中在早高峰——那不是话务高峰，而是静默时长最容易超过阈值的时间窗。

4.3 影响评估

按受影响用户范围与持续时长估算（示例值）：受影响用户为接入 F2 策略段的政企专线与园区专网用户，规模在万级；持续时间自 D1 早高峰至 D1 16:30 临时处置生效，约七小时；期间语音业务未受影响（IMS 走独立承载路径）；未产生计费差错——会话建立成功、计费按正常规则出账，用户感知是"上不了网但能打电话"，这类"半可用"状态在话单上完全看不出来。

这一条值得单独强调："能注册、能建会话、能打电话，就是上不了网"这种半可用故障，在计费系统、告警系统、话单分析里都是隐形的。只有从用户视角主动探测，才能看见。

五、第四层到第六层：状态、变更、复现

5.1 第四层：状态层要查"表"，不是查"告警"

状态层是本案定性的关键一层。操作要点有三个：

第一，要主动查设备内部状态，而不是等告警。这类故障的告警特征是"没有"——F2 不会告诉你"我丢了一个下行包"，因为丢未知流是它的正常行为。所以必须主动查询：2152 端口的会话表项、当前会话条目数、会话超时配置值、超时动作（老化回收还是老化但保留状态）。查询语法各家不同，但要查的东西是同一个：那条流的超时是多久，超时后动作是什么。

第二，状态查询有采样延迟。很多设备的状态查询返回的是周期采样值而非实时值，两次查询之间可能已经变了。涉及时间点的判定，务必带上采样周期这个事实。

第三，配置项要看"生效值"而不是"界面上显示的值"。本案里 F2 的界面显示 UDP 会话超时为默认段继承值，而实际生效的是策略段内的一个更短的超时值——这类"继承与显式覆盖"的差异，是配置审计最该覆盖的场景。

5.2 第五层：变更层要查"时间窗"，不只查"最近"

变更检索有两个常见失误：

失误一：只查最近三天。本案 D-14 的变更与 D1 的故障相隔两周。故障当天没有任何变更，值班工程师查"最近变更"必然一无所获。

失误二：只查"网元变更"，不查"传输与安全设备变更"。本案的变更发生在安全设备上，在核心网侧的变更工单系统里根本查不到——它属于传输专业。变更视野必须覆盖无线、传输、承载、安全、核心网五个域，而这五个域的变更往往分属不同系统。

本案能查出来的关键前提是：复盘时把"故障时间往前推两周的所有变更"列成了一张全量清单，而不是只看核心网的单。

5.3 第六层：复现是最硬的证据

实验室复现的价值不在于"证明我们没瞎猜"，而在于它能一次性验证多个假设。

本案的复现设计很轻：一套开源 5G 核心网（AMF/SMF/UPF/UDM 等）加一个终端模拟器，前面接一台带会话老化功能的防火墙，把2152 端口会话超时调到 60 秒；终端完成注册与 PDU 会话建立后静默 120 秒，再发一个上行数据包。

结果与现网完全一致：上行通，下行不通；重建会话立刻恢复，几分钟后再次失效；信令面无任何异常。

复现一成功，根因就从"最可能"升级为"已确认"——因为只有一个变量在动。复现完成后还要做反向验证：把超时调回原值，故障消失。这一步不做，复现也可能只是巧合。

复现还顺手回答了一个重要问题：这类故障在生产网能不能被主动检测？答案见下一节。

六、抓包点速查：接口、端口与过滤串

取证阶段的效率，取决于抓包点选得对不对、过滤串写得好不好。下面这张表是 5GC 现网最常用的几个点，可以直接抄进作业手册。

过滤串（Wireshark）：

ngap                                   # NGAP 全部消息
nas-5gs                                # 5GS NAS，需先剥 NGAP 的 NAS 承载
sctp                                  # SCTP 偶联与重传
pfcp                                  # PFCP（UDP 8805）
gtp                                   # GTP-U（UDP 2152）
http2                                  # SBI 明文流；TLS 需网元侧导出 SSLKEYLOGFILE

抓包落盘的命令，通常成对执行：

# SMF 侧
tcpdump -i any -w smf_n4.pcap udp port 8805
# UPF 侧
tcpdump -i any -w upf_n4.pcap udp port 8805

两个文件放在一起，用 Sequence Number 做配对，这是判定"请求没发 / 响应没回 / 响应回了但没出去"三种情况的唯一硬证据。

顺带提醒一个常被跳过的动作：GTP-U 外层封装开销约 36 字节（IPv4）到 56 字节（IPv6），N3/N9 链路 MTU 与对端不一致时大包分片丢失，症状是"小包通、大包死、网页打不开但能注册"——和本案的用户表象相似，排查时别忘了这一层。

七、取证保鲜期：越晚动手，能看到的越少

复盘本案时，最让人后怕的不是故障本身，是取证窗口的收窄速度。

三条由此推出的纪律：

第一，故障发生后的第一个小时，不要做会污染现场的动作。重启网元、清表项、改配置——每一步都在销毁证据。本案里现场同学"重启 UPF 无效"这一步，直接毁掉了观察"会话表项持续增长还是持续掉"的窗口。

第二，日志留存策略要按"取证需求"倒推，而不是按"存储成本"设定。核心网网元日志写本地盘的留存时长常常只有几小时到一天，而排障往往在次日上班才开始——这是取证链上最常见也最荒唐的断点。可行的折中是：关键日志实时汇聚到日志平台并延长留存，本地盘只做应急。

第三，故障复现要主动制造，不能指望用户再犯一次。本案能定位，靠的不是等下一个用户投诉，而是在故障窗口内制造了一次受控复现（让用户在指定时间再次操作），并同步开启追踪与抓包。故障进行时的复现机会，价值是事后的一百倍。

八、工具链：把实验室建成风洞

现网不敢试的操作，实验室里随便试。核心网运维团队值得常备的最小工具集：

其中最有价值、也最容易被跳过的是第三项：你必须能在实验室里制造"静默"这个变量。很多故障只在"时间维度"上才会出现，而现网的时间是不可控的，实验室的时间是可编排的。

公开社区里就有现成的素材可参考：Open5GS 社区曾记录过两起典型的"控制面正常、用户面异常"工单——一起是 gNB 的 SCTP 偶联重建后残留了陈旧的 UE 上下文，注册与 SM 上下文创建日志全部正常，用户面却拿不到数据（Open5GS #4427）；另一起是 UDM 侧的订阅池被长期占用，500 台终端批量注册只有 375 台成功，拒绝原因指向"5GS 服务不允许"，重启 UDM 后500 台全部通过（Open5GS #4789）。这两起工单共同印证了一件事：在 SBI 架构下，故障点、告警点与用户感知点经常不在同一个网元上，所以取证必须分层、必须成对、必须跨网元串联。

九、五条铁律

十八年下来，这五条被我写进了每一份割接方案和故障复盘的模板里。

铁律一：长连接业务，必须和中间设备的会话老化时间对表。这是"越用越断"的唯一根因。核心网侧的长会话、终端的静默、省电策略导致的长时间不发包，三者叠加的时间尺度（分钟级、小时级），必须落在安全设备、NAT、负载均衡的会话超时的安全边界内。对表这件事应该常态化——把设备默认超时纳入配置基线并登记，变更时显式配置，不允许"继承默认值"这种含糊状态存在。

铁律二：控制面成功率高，不等于网络可用。必须养一只"从外面看"的眼睛。拨测不能只测"注册成功"，要测长时在线——每隔固定周期发一次小包下行探测，验证静默之后的通路。故障发生时，这只眼睛比任何 KPI 曲线都先发现问题。

铁律三：取证要分层，第一层没做完不要进第二层。先问范围、问时间相关性、问控制面还是用户面，再决定用追踪还是抓包。跳过这一步的代价，通常是两小时的无用功。

铁律四：故障窗口内，制造一次受控复现。复现越晚，能拿到的证据越少。日志会滚动，表项会重建，用户会离开现场。所有取证动作都要排在复现之前。

铁律五：能复现的故障，才算找到根因。不能复现的根因分析，止步于"高度怀疑"。实验室里把那个变量调出来，再调回去，这个闭环闭上，故障才算真正结束。

结语：让故障在年轻的时候被抓住

会话老化这类故障的恶劣之处，不在于它多复杂——恰恰相反，它的机理简单到一句话就能说清：中间设备的表项活得太短，而运营商的会话活得太长。

它的恶劣之处在于它专门挑监控的盲区下手。控制面成功率99.6% 掩盖了用户面 100% 的丢弃；日志平台安静如常，因为丢包不是异常，是安全设备的正常动作；甚至投诉工单里"手机显示 5G、注册成功、也能打电话"这些描述，都在把排查方向往信令面引。

所以真正的分水岭不是技术，是你有没有把用户面当成一等公民去监控。当你的拨测体系开始测"静默之后还能不能通"，当你的配置基线里登记了每一台中间设备的会话超时，当你的取证习惯是先分层再下手——这类故障就会在用户投诉之前被抓住。

让故障在年轻的时候被抓住，是运维这门手艺真正的价值所在。

参考来源

1. 3GPP TS 32.421 — 信令追踪（Trace）管理规范页 — 追踪的概念、功能与用例定义出处；本文"第二层 会话层"追踪机制的概念依据
2. 3GPP TS 32.422 — 追踪文件格式与传输规范页 — 追踪文件的组织方式与导出格式定义，配合 TS 32.423构成完整追踪管理体系
3. 3GPP TS 32.423 — 追踪管理功能架构规范页 — 追踪激活下发、网元记录与追踪收集实体汇聚的功能架构出处
4. 3GPP TS 29.244 — N4 接口 PFCP 协议规范页 — PFCP 会话建立/修改与 PDR/FAR/QER/URR 规则定义；本文用户面会话模型与"会话在、数据不通"判定的协议依据
5. 3GPP TS 23.502 — 5G 系统流程规范页 — 注册与 PDU 会话建立等 Stage 2 流程定义；本文会话层取证的消息链依据
6. 3GPP TS 24.501 — 5G 非接入层协议规范页 — 5GMM/5GSM 消息与原因值定义；本文"先分清控制面还是用户面"判断步骤的协议依据
7. Open5GS Issue #4427 — gNB SCTP 重连后残留 UE 上下文导致 PDU 会话失败 — 公开工单：注册与上下文创建日志全部正常而用户面无数据的真实案例，本文"控制面正常不等于网络可用"的社区证据
8. Open5GS Issue #4789 — UDM 订阅池被占满导致批量注册被拒 — 公开工单：500 台终端注册 375 台成功、重启单一组件即恢复的完整数据与复现步骤
9. free5gc — 开源 5G 核心网 — 实验室 5GC 底座，本文"把实验室建成风洞"一节的工具依据
10. UERANSIM — 5G gNB/UE 模拟器 — 无需真基站即可跑通 N1/N2/N3 全流程的终端与基站模拟器
11. Towards NWDAF-enabled Analytics and Closed-Loop Automation in 5G Networks (arXiv:2505.06789) — 5G 网络数据分析与闭环自动化的系统性研究；本文"从用户视角主动探测、让故障提前暴露"一节的学术参照

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