$tcpinfo_snd_cwnd 不是 Nginx 原生变量，需通过 getsockopt 主动读取内核 tcp_info；Nginx 默认不采集该字段，直接在 log_format 中使用无效。可行方案包括 ss -i、eBPF、应用层埋点或通过 HTTP 头透传。
$tcpinfo_snd_cwnd 并不是 Nginx log_format 原生支持的变量，Nginx 官方变量中不存在 $tcpinfo_snd_cwnd。这个字段属于 Linux 内核 struct tcp_info，需通过 getsockopt(sockfd, IPPROTO_TCP, TCP_INFO, ...) 主动读取，而 Nginx 的日志模块（包括 log_format）默认不采集、不暴露、也不解析 TCP 连接层的内核状态信息。
所以，直接在 log_format 中写 $tcpinfo_snd_cwnd 是无效的——Nginx 会把它当作普通字符串字面量输出，或报错“unknown variable”，具体取决于配置校验严格程度。
但如果你的目标是「监控拥塞窗口变化」，有更可行、更贴近生产环境的路径：
✅ 正确理解 Nginx 与 TCP 窗口的关系
Nginx 作为用户态应用，其 socket 行为受内核 TCP 栈控制，但它不主动读取 tcp_info。它能感知的仅是：
- 连接是否建立（
$connection、$status） - 请求/响应大小（
$bytes_sent、$request_length） - 延迟（
$request_time、$upstream_response_time） - 底层连接指标（如
$upstream_addr、$upstream_connect_time）
但 cwnd、rtt、retransmits 等字段，必须由程序显式调用 getsockopt(..., TCP_INFO, ...) 获取，Nginx 默认不这么做。
✅ 替代方案：分层监控，各司其职
| 层级 | 工具/方式 | 能获取的拥塞窗口信息 | 说明 |
|---|---|---|---|
| 内核态实时采集 |
ss -i 或 cat /proc/net/tcp（需解析） |
cwnd, rtt, ssthresh, unacked, retrans
|
ss -i dst <ip>:<port></port></ip> 可直接打印当前连接的 cwnd（单位：segments），适合脚本周期性抓取 |
| eBPF 动态追踪 |
bcc 工具集（如 tcpslow、tcpconnlat）、bpftrace
|
实时 cwnd 变化、RTT、重传事件 |
无需修改应用，可挂钩 tcp_set_congestion_control() 或 tcp_ack()，精准观测窗口升降时机 |
| 应用层埋点（C/C++/Go） | 自定义客户端或代理，在关键 socket 上调用 getsockopt(..., TCP_INFO, &info, &len)
|
全量 tcp_info 字段，含 tcpi_snd_cwnd
|
适合自研网关、RPC 框架或压测工具，可打点到日志或 metrics（如 Prometheus） |
| Nginx 配合外部服务 | Lua + ngx.socket.tcp()（OpenResty）+ cdata 调用系统调用 |
有限支持（需自己封装 getsockopt） |
OpenResty 可用 ffi 调用 C 函数读 tcp_info，但仅适用于 Lua 创建的 socket，不适用于 upstream 连接 |
? 示例：用
ss快速查看某连接的拥塞窗口# 查看所有 ESTABLISHED 连接及其 cwnd（单位：segments） ss -i state established | grep -v "cwnd" # 输出示例：10.0.1.100:45678 10.0.2.200:8080 ... cwnd:12 ssthresh:20 rtt:12345/4000
✅ 如果你坚持用 Nginx 日志“关联”拥塞窗口
可以采用间接方式：
- 在业务侧（如后端服务）主动记录
tcpi_snd_cwnd到请求头（例如X-TCP-CWND: 15） - Nginx 配置中用
$sent_http_x_tcp_cwnd或$http_x_tcp_cwnd（取决于传递方向）捕获该头 -
log_format中引用该变量：log_format tcpwin '$remote_addr - $remote_user [$time_local] ' '"$request" $status $bytes_sent ' 'cwnd=$sent_http_x_tcp_cwnd ' 'rtt=$sent_http_x_tcp_rtt';⚠️ 注意：这要求后端服务有能力读取 socket 的
tcp_info并注入响应头，属于应用协同方案，非内核直采。
❌ 不推荐的做法
- 尝试 patch Nginx 源码添加
$tcpinfo_*变量（维护成本高、升级困难） - 依赖第三方未验证模块（如老旧的
nginx-tcpinfo-module，多数已不兼容 1.20+） - 用
strace抓 Nginx 进程的getsockopt调用（开销大、不可持续）
不复杂但容易忽略：拥塞窗口是 per-socket、瞬时、内核态的状态，它天生不适合“被动日志化”。真正有效的监控，是主动、低开销、分层采集 —— 让 ss/eBPF 负责内核指标，让 Nginx 负责 HTTP 层行为，再用 Prometheus + Grafana 关联分析。
