## 导读

线上崩溃最麻烦的一种现场，是进程什么都没解释，只是在系统日志里留下一行 日志：
![图一.png](https://developer.qcloudimg.com/http-save/yehe-12635806/994b65344fa49c2170b174d41005a91f.png)

没有业务错误码。

没有完整调用栈。

只有一个访问地址、一个指令地址，以及一个已经退出的 worker。

但这类问题并不是无从下手。只要读懂这一行日志，再把系统日志、源码和业务时序串联起来，`segfault` 信息就能成为破案入口。

本文复盘一次 TLCP/GMVPN 场景下 OCSP 校验触发的Nginx worker 崩溃问题：记录如何从 `kern.log` 出发，一步步定位到代码缺陷，重点不是 OCSP 校验本身，而是一次可复用的排障路径：

```
结合kern.log判断崩溃类型
结合addr2line定位源码崩溃语句
结合业务日志还原执行时序
源码分析解释状态为什么失效
最小复现验证
```



## 第一条线索：`segfault at 28` 不是代码地址

业务现象很直接：Nginx HTTPS 代理服务在开启客户端证书 OCSP 校验后，使用国密双向认证压测时，worker 偶发退出。

系统日志中可以看到类似信息：

```text
nginx[780589]: segfault at 28 ip 0000555c3f496487 sp ... error 6 in nginx[96487,555c3f400000+2a0000]

nginx[...]: segfault at 50 ip 0000000000477073 sp ... error 4... in nginx[...]
```

这类日志看起来只有地址，没有调用栈。但实际上，里面已经包含了定位问题的第一批关键线索。其中几个字段最重要：

```text
nginx[780589]    崩溃进程和 PID
segfault at 28   访问了非法地址 0x28
ip ...           触发崩溃的指令地址
sp ...           当时的栈指针
error 6          页错误类型
in nginx[...]    崩溃发生的二进制
```

这里最容易犯的错误，是把 `segfault at 28` 当成代码地址。

它不是。

**`segfault at 28` 表示程序试图访问非法内存地址 `0x28`。真正用于定位代码的是 `ip`，也就是 CPU 当时正在执行的指令地址。**

`0x28`、`0x50` 这种很小的地址，通常不是随机野指针，更像：

```text
NULL + 结构体字段偏移
```

也就是说，某个结构体指针已经是 `NULL`，代码还在读写它的成员。

再结合 `error` 可以进一步判断访问类型：

```text
error 6  常见为写非法地址
error 4  常见为读非法地址
```

到这一步，还没看源码，我们已经能做出第一层判断：

> 这不是普通业务失败，而是一次空指针字段访问；接下来应该用 `ip` 去映射源码。

问题已经从“worker 偶发退出”，收敛成了“某个回调里访问了失效状态”，下一步是把 `ip` 映射到源码行。





## 第二条线索：真正该追的是 `ip`

如果二进制没有开启 PIE，`ip` 可以直接用于映射：

```bash
addr2line -f -C -e /path/to/nginx 0x477073
```

得到类似结果：

```text
ngx_ssl_ocsp_handler
ngx_event_openssl_stapling.c:1604
```

如果是 PIE/ASLR 形式，kernel 日志里有时会给出相对偏移，例如：

```text
in nginx[96487,555c3f400000+2a0000]
```

这里 `0x96487` 就是相对二进制基址的偏移，可以这样定位：

```bash
addr2line -f -C -e /path/to/nginx 0x96487
```

如果没有直接给偏移，也可以手算：

```bash
python3 - <<'PY'
print(hex(0x0000555c3f496487 - 0x0000555c3f400000))
PY
```

**这一步有个硬要求：一定要使用崩溃当时运行的那个二进制。**只要重新编译过，哪怕源码只改了一点点，地址都可能对不上。

本次映射后，崩溃点落在 OCSP 回调处理逻辑：

```c
c = ctx->data;
ocsp = c->ssl->ocsp;
ocsp->ctx = NULL;
```

结合 `segfault at 28`，基本可以判断：

```text
ocsp == NULL
```

如果现场是 `segfault at 50`，则可能意味着：

```text
c->ssl == NULL
```

两种现场的表现不同，但方向一致：

> OCSP 异步回调执行时，连接上的 SSL/OCSP 状态已经不是回调期望的状态。

到这里，我们只知道“崩在哪里”，还不知道“为什么会崩”，真正的线索藏在业务日志的时间线里。



---

严格来说：`0x28` 对应 `ocsp == NULL`、`0x50` 对应 `c->ssl == NULL`，并不是只凭 C 源码的推断，而是可以由 ASan 报告、反汇编和调试符号核实的。

本次本机复现的 ASan 报告给出了更直接的证据：

```text
runtime error: member access within null pointer of type 'struct ngx_ssl_ocsp_t'
ERROR: AddressSanitizer: SEGV on unknown address 0x000000000028
The signal is caused by a WRITE memory access.
Hint: address points to the zero page.

#0 ngx_ssl_ocsp_handler src/event/ngx_event_openssl_stapling.c:1605

Register values:
rax = 0x0000000000000000
```

这几行信息说明三件事：

1. 崩溃是一次写访问。
2. 写入目标地址是 `0x28`，也就是零页附近。
3. 崩溃指令执行时 `rax == 0`。

同时，二进制的反汇编`ngx_ssl_ocsp_handler` 对应指令如下：

```asm
0x1ab2e18 <ngx_ssl_ocsp_handler+383>: mov    0x50(%rbx),%rax
0x1ab2e1c <ngx_ssl_ocsp_handler+387>: mov    %rax,-0x18(%rbp)

0x1ab2e91 <ngx_ssl_ocsp_handler+504>: mov    -0x18(%rbp),%rax
0x1ab2e95 <ngx_ssl_ocsp_handler+508>: movq   $0x0,0x28(%rax)
```

`addr2line` 映射确认：

```bash
addr2line -f -C -e /path/to/nginx 0x1ab2e95
```

输出：

```text
ngx_ssl_ocsp_handler
src/event/ngx_event_openssl_stapling.c:1605
```

也就是说，实际崩溃指令就是：

```asm
movq $0x0, 0x28(%rax)
```

而 ASan 报告中的寄存器值又显示：

```text
rax = 0
```

所以 `segfault at 0x28`，已经不只是“根据源码猜测”，而是可以闭合为：

```text
rax == ocsp == NULL
0x28 == offsetof(ngx_ssl_ocsp_t, ctx)
执行 ocsp->ctx = NULL 时写入 NULL + 0x28
```

字段偏移也可以用调试符号直接确认：

```gdb
(gdb) p/x (unsigned long)&((ngx_ssl_ocsp_t*)0)->ctx　# ngx_ssl_ocsp_t.ctx 偏移 0x28
$1 = 0x28

(gdb) p/x (unsigned long)&((struct ngx_ssl_connection_s*)0)->ocsp #ngx_ssl_connection_s.ocsp 偏移 0x50
$2 = 0x50

(gdb) p/x (unsigned long)&((ngx_connection_t*)0)->ssl #ngx_connection_t.ssl 偏移 0x90
$3 = 0x90
```

这也解释了另一类 `segfault at 0x50` 为什么会指向 `c->ssl == NULL`：反汇编中的

```asm
mov 0x50(%rbx), %rax
```

对应的是读取 `c->ssl->ocsp`：当时 `rbx == 0`，也就是 `c->ssl == NULL`，这条指令读取 `NULL + 0x50`，从而出现 `segfault at 0x50`。

---





## 第三条线索：一次握手里出现了两个 OCSP 请求

`addr2line` 只能告诉我们崩在哪一行，但不能解释为什么这个指针会变成 `NULL`。真正的原因必须回到业务日志，按时间线还原崩溃前发生了什么。

这次复现里，关键时序非常清楚：

```text
*2 ssl ocsp validate
*2 connect to 127.0.0.1:23019, fd:12

epoll: fd:12 ev:0004                                                                      
*2 ssl ocsp write handler                                                                 
*2 send: fd:12 386 of 386  

*2 ssl ocsp validate
*2 connect to 127.0.0.1:23019, fd:13                                                               
                                                                                            
epoll: fd:13 ev:0004                                                                      
*2 ssl ocsp write handler                                                                 
*2 send: fd:13 386 of 386

epoll: fd:13 ev:2005                                                  
*2 ssl ocsp read handler                                              
*2 recv: fd:13 1883 of 16384 
*2 ssl ocsp validated, certs:1
*2 ssl ocsp resume handshake
*2 SSL negotiation finished successfully
*2 close http connection
*2 SSL_shutdown: 1

epoll: fd:12 ev:0005
*2 ssl ocsp read handler
*2 recv: fd:12 1882 of 16384
*2 ssl ocsp process body
ngx_ssl_ocsp_handler:1605 SEGV
```

这条时序里，最反常的不是 OCSP 返回失败，而是：

```text
同一个连接 *2，在一次握手里发起了两次 OCSP 请求。
```

然后事情按这样的顺序发生：

1. 第一次 OCSP 请求发出，使用 `fd:12`。
2. 第二次 OCSP 请求发出，使用 `fd:13`。
3. `fd:13` 先返回 `good`。
4. 第二个 OCSP 请求的响应返回后恢复 SSL 握手。
5. 握手成功，HTTP 连接关闭，执行 `SSL_shutdown`。
6. 稍后，`fd:12` 这个先发出请求的响应才返回。
7. 迟到回调再次进入 `ngx_ssl_ocsp_handler()`。
8. 此时连接上的 OCSP 状态已经失效，触发空指针崩溃。

异步 bug 最难的地方就在这里：

> 崩溃发生在“后来”，根因却埋在“之前”。

这次不是高并发随机把 worker 打崩，而是请求返回顺序被打乱后，迟到回调访问了过期状态。



## 第四条线索：为什么同一连接会发起两次 OCSP？

继续看源码，OCSP 校验入口在证书 verify callback 中：

```c
if (err == X509_V_OK) {
    if (depth == 0) {
        ngx_ssl_ocsp_validate(c, x509_store);
    }
}
```

也就是说，每当客户端证书链校验到 leaf 证书时，都会发起一次 OCSP 校验。

在普通单证书 TLS 场景中，这通常不是问题。

但在 TLCP/GMVPN 双证书场景下，客户端可能同时涉及签名证书和加密证书。但实现没有明确区分“签名证书”和“加密证书”，也没有保证“同一逻辑 leaf 证书只触发一次 OCSP verify”。

结果就是：同一个 SSL 连接里，可能启动两次客户端证书 OCSP 校验，OCSP请求超过了它依赖的连接生命周期导致发生`Segfault`。

**尝试使用构建出的最小配置，可以稳定复现该现象。**



## 根因闭环

完整链路可以总结为：

```text
kern.log 出现小地址 segfault
→ 判断为空指针字段访问
→ 用 ip / addr2line 定位到 ngx_ssl_ocsp_handler
→ 源码确认回调依赖 c->ssl->ocsp 单指针
→ error log 发现同一连接发起两次 OCSP 请求
→ 第二个 OCSP 先返回并恢复握手
→ 握手完成后连接关闭
→ 第一个 OCSP 迟到返回
→ 迟到回调通过旧连接指针回查当前状态
→ 当前状态已失效，触发崩溃
```

根因不是 OCSP responder 返回异常，也不是压测工具问题，而是：

```text
同一连接内多个异步 OCSP 请求共享单一 c->ssl->ocsp 状态；
请求乱序返回后，迟到回调访问了已经失效的连接状态。
```

这也是为什么这个问题看起来偶现：只有当两个 OCSP 请求返回顺序、握手恢复、连接关闭这几个事件刚好交错时，崩溃才会发生。



## 结语

`kern.log` 里的一行 `segfault` 看起来信息很少，但它不是终点，而是入口。可复用的排查方式是：

```text
系统日志定位崩溃类型
源码定位崩溃语句
业务日志还原执行时序
源码模型解释状态为什么失效
最小复现验证假设
```

当这些证据能互相闭合，所谓“偶现崩溃”就不再偶然，从而演变成为一个可以被解释、复现和修复的工程问题。




但这类问题并不是无从下手。只要读懂这一行日志，再把系统日志、源码和业务时序串联起来，segfault 信息就能成为破案入口。

一次握手两次OCSP校验：一次 Nginx worker 崩溃排查实录

本文复盘一次 TLCP/GMVPN 场景下 OCSP 校验触发的Nginx worker 崩溃问题：记录如何从 `kern.log` 出发，一步步定位到代码缺陷，重点不是 OCSP 校验本身，而是梳理总结出可复用的排障路径。

资深网关研发

后端

安全

运维

Nginx HTTPS代理服务在国密双向认证压测时偶发worker崩溃，系统日志显示segfault at 28。通过分析kern.log、addr2line定位源码，发现OCSP异步回调访问了已失效的SSL连接状态。业务日志显示同一连接发起两次OCSP请求，乱序返回导致迟到回调触发空指针崩溃。本文详细拆解了从系统日志到源码缺陷的完整排障路径，为类似异步状态管理问题提供了可复用的分析方法。

代码解释

国密

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Nginx HTTPS代理服务在国密双向认证压测时偶发worker崩溃，系统日志显示segfault at 28。通过分析kern.log、addr2line定位源码，发现OCSP异步回调访问了已失效的SSL连接状态。业务日志显示同一连接发起两次OCSP请求，乱序返回导致迟到回调触发空指针崩溃。本文详细拆解了从系统日志...

一次握手两次OCSP校验：一次 Nginx worker 崩溃排查实录-腾讯云开发者社区-腾讯云

一次握手两次OCSP校验：一次 Nginx worker 崩溃排查实录

一次握手两次OCSP校验：一次 Nginx worker 崩溃排查实录

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐