nginx官方稳定版不支持$tcpinfo_rtt变量，因其运行在应用层，未集成内核tcp_info系统调用；可行替代方案包括tcpdump/tcprstat抓包分析、proxy protocol v2透传（需上游支持）或客户端js上报rtt。
目前 Nginx 官方稳定版（截至 2026 年 5 月）不支持直接记录 $tcpinfo_rtt 变量。该变量并不存在于标准 ngx_http_core_module 或任何官方模块中，也未被主流发行版（如 nginx.org 官方包、RHEL/CentOS 的 nginx-stable）所实现。
为什么看不到 $tcpinfo_rtt？
Nginx 运行在应用层（HTTP/Stream 模块），而 TCP RTT 是内核协议栈维护的 socket 级状态，需通过 getsockopt(fd, IPPROTO_TCP, TCP_INFO, ...) 获取。标准 Nginx 不在每个请求或连接生命周期中主动调用该系统调用，也不暴露其返回结构体中的 tcpi_rtt 字段为变量。
- 所谓 “$tcpinfo_rtt” 常见于部分定制分支（如 Tengine 旧版、OpenResty 的某些实验 patch）、第三方模块（如
ngx_tcpinfo_module）或用户误传的文档 - 官方日志变量列表中无此变量，源码中亦无对应定义（搜索
tcpinfo_rtt在 nginx-1.25.x / 1.26.x 主干中结果为空） - 即使使用
stream模块处理纯 TCP 流量，Nginx 默认也不解析或透传底层 TCP 控制块信息
替代方案：真实可行的 RTT 监控路径
若目标是监控客户端到 Nginx 的网络往返时延，应转向更可靠、可落地的方式：
-
用 tcpdump + tcprstat 或 bpftrace 分析服务端入口连接：在 Nginx 所在机器抓包，过滤 SYN/SYN-ACK 时间戳，计算初始 RTT；或使用
tcprstat -p 80 -n 1实时统计监听端口的连接 RTT 分布 -
启用 PROXY Protocol v2 并依赖上游负载均衡器透传：若 Nginx 前有支持 PROXYv2 的 LB（如 HAProxy、NLB、Traefik），它可在连接建立时读取内核
TCP_INFO并将 RTT 作为自定义 TLV 写入 PROXY header；Nginx 可用$proxy_protocol_tlv_0x23（需 patch 或 OpenResty）或自定义模块提取 —— 但标准 Nginx 仍无法原生解析 TLV -
客户端主动上报 RTT（最实用）：前端 JS 调用
performance.getEntriesByType('navigation')或发起timing-Allow-Origin允许的探测请求，将responseStart - requestStart（近似 HTTP 层 RTT+处理时间）打点上报；后端记录时关联$remote_addr和时间戳，做聚合分析
检查你是否误用了非标准模块
如果你在某份配置里看到 $tcpinfo_rtt 被成功使用，请确认：
- 是否安装了第三方模块（例如 GitHub 上的
nginx-tcpinfo-module），且已重新编译 Nginx 并加载 - 是否实际运行的是 OpenResty（基于 Nginx+Lua），并通过
lua_socket_getbyname或getpeername+ffi调用系统 API 获取 - 是否混淆了
$upstream_connect_time（后端建连耗时，含三次握手，但不含客户端到 Nginx 的 RTT）
想获得接近真实的客户端网络 RTT，优先从基础设施层或客户端侧入手，而非依赖 Nginx 原生命令。标准 Nginx 日志能力聚焦于 HTTP/Stream 行为本身，不深入内核 TCP 状态。
