Apache mod_log_config 无法记录 TCP 连接建立耗时,因其工作始于 HTTP 请求接收,而 TCP 建连发生在更早的网络层;%D 表示 Apache 接收首字节到发送完响应头的微秒数,不含建连时间;无内置变量(如 %C、%K)可获取 SYN→SYN-ACK→ACK 耗时;需客户端测量(如 curl %{time_connect})或系统级工具(tcpdump/eBPF)捕获。

Apache 的 mod_log_config 无法直接记录 TCP 连接建立耗时(即三次握手完成时间),因为该模块只在请求已进入 HTTP 处理阶段后才开始工作——此时 TCP 连接早已建立完毕。
TCP 连接耗时发生在网络层和内核协议栈,远早于 Apache 接收第一个 HTTP 字节。mod_log_config 提供的 %D、%T、%I、%O 等变量,全部基于 HTTP 请求生命周期,起点是“Apache 收到请求第一个字节”,而非“TCP 连接建立完成时刻”。
所以,真实答案很明确:
- ✅
%D记录的是:从 Apache 接收到请求首字节,到发送完响应头为止的微秒数(含网络传输、Apache 路由、后端代理等待等,但不含 TCP 建连); - ❌ 没有
%C、%K或类似内置变量能表示“SYN → SYN-ACK → ACK”耗时; - ❌
mod_log_config不接触 socket 创建、connect() 调用、TCP 状态机,无能力测量该指标。
如果你确实需要 TCP 建连耗时,可行路径只有两类:
1. 在客户端侧测量(最常用、最可靠)
让发起请求的客户端(如 curl、浏览器、Java HttpClient、前端 JS)自己打点:
Apache Superset 是一个广泛采用的开源 BI 平台,用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时,此技能非常有用。
- 记录
new Date().getTime()或System.nanoTime()在调用connect()或发 HTTP 请求前; - 记录收到响应头(或首个字节)的时间;
- 差值 ≈ TCP 建连 + TLS 握手 + HTTP 发送 + 服务端处理 + 响应头返回的总和;
- 若需单独剥离建连时间,可配合
curl -w "@format.txt"使用%{time_connect}变量(它专指从开始到 TCP 连接建立完成的时间)。
示例(curl):
curl -w "connect: %{time_connect}s, total: %{time_total}s\n" -o /dev/null -s https://example.com/
2. 在服务端操作系统/内核层捕获(需额外工具)
Apache 本身不提供该能力,但可通过以下方式间接获取:
- 使用
tcpdump或Wireshark抓包,过滤 SYN/SYN-ACK 时间戳(适合排查偶发延迟); - 使用
ss -i或netstat -s查看系统级 TCP 统计(宏观趋势,非单请求); - 利用 eBPF 工具(如
bcc中的tcpsynbl、tcpconnlat)跟踪每个 connect() 耗时(Linux 4.1+,需 root 和调试支持); - 配合
mod_ssl日志开启SSLLog并结合%{SSL_PROTOCOL}x和%{SSL_CIPHER}x,虽不直接给建连时间,但可辅助判断是否 TLS 握手拖慢了整体感知。
补充说明:别混淆这几个常见概念
-
%D≠ TCP 连接耗时:它是 Apache 层面的“请求服务耗时”,起点晚于建连完成; -
KeepAliveTimeout不是建连耗时:它控制已有连接空闲多久后关闭,与新建连接无关; -
TimeOut指读写超时:比如接收 POST 数据的间隔上限,也不是建连指标; -
%{X-Process-Time}o是 Java 应用写的:它反映后端逻辑执行时间,更靠后。
总结一句话
Apache mod_log_config 没有机制、也没有变量可以记录每个请求的 TCP 连接建立耗时。这个指标必须由客户端主动测量,或由系统级观测工具(tcpdump/eBPF)在内核层面捕获。想靠改 LogFormat 实现,这条路走不通。










