Nginx 无 $upstream_http_server 内置变量，因该变量名不合法；实际应使用 $upstream_http_server（全小写、无短横）才能获取后端响应头中的 Server 字段，前提是后端明确返回该头，否则为空。
不能直接用 $upstream_http_server 记录后端技术栈，因为 Nginx 没有这个内置变量 —— 它不存在。
为什么 $upstream_http_server 不可用
Nginx 的 $upstream_http_* 系列变量只支持读取后端响应头中**实际存在且名称合法**的字段，格式为 $upstream_http_xxx，其中 xxx 会自动转为小写并用下划线替代短横（如 X-Server → $upstream_http_x_server）。但标准 HTTP 响应头里没有 Server 字段的别名或等效变量；Nginx 本身不解析、也不暴露原始 Server 响应头为 $upstream_http_server。
也就是说：
– $upstream_http_server 是无效写法，配置会报错或始终为空；
– 真正能拿到后端 Server 头的方式，是显式使用 $upstream_http_server 对应的合法变量名：$upstream_http_server ❌ 不行，$upstream_http_server 不存在；$upstream_http_server 应该写成 $upstream_http_server？不对 —— 正确写法是：$upstream_http_server 依然错误。正确的是：$upstream_http_server 不能用，必须用 $upstream_http_server？等等 —— 实际上，Nginx 允许访问任意响应头，只要按规范转换命名：
-
Server: nginx/1.20.1→ 变量名是$upstream_http_server✅（注意：全小写，下划线替换短横，但Server无短横，所以就是server） -
X-Powered-By: Express→ 变量名是$upstream_http_x_powered_by -
X-Backend: Django/Gunicorn→ 变量名是$upstream_http_x_backend
如何真正记录后端 Server 响应头
前提是后端服务在响应中明确返回了 Server 头（例如 Flask 默认不发，Spring Boot 默认发 Server: Apache-Coyote/1.1，Node.js + Express 需手动设置）。
步骤如下：
- 在
http块中定义 log_format，加入$upstream_http_server：
log_format upstream_tech '$remote_addr - [$time_local] "$request" ' '$status $body_bytes_sent ' '$upstream_addr $upstream_response_time $upstream_status ' '$upstream_http_server $upstream_http_x_powered_by';
- 确保后端确实返回
Server头（可先用 curl 测试：curl -I http://backend-host/） - 若后端出于安全隐藏了
Server头，建议改用自定义头，例如让后端返回X-Backend-Tech: Go+Gin，然后在日志中用$upstream_http_x_backend_tech - 该变量仅在 proxy_pass 成功转发并收到响应时有值；如果请求未到达 upstream（如 499、503 或超时），对应字段为空
更可靠的技术栈识别建议
依赖 Server 头不稳定，推荐组合策略：
- 强制后端注入可读标识：统一约定返回
X-Backend: Python/FastAPI、X-Backend: Java/Spring等，日志中取$upstream_http_x_backend - 结合
$upstream_addr和 upstream 分组名（需配合 map 模块做地址→标签映射） - 用
$upstream_http_content_type辅助判断（如application/json; charset=utf-8常见于 API 服务） - 避免单点依赖：
Server头易被移除或伪造，X-*自定义头更可控、语义更明确
