$upstream_last_server_name 不存在于标准 nginx 变量中，官方未定义；替代方案可用 $upstream_addr、$upstream_status、$upstream_response_time 等组合实现动态后端可观测性。
目前 Nginx 官方版本（包括 1.25.x）并不支持 $upstream_last_server_name 这个变量，它**不存在于标准 Nginx 变量列表中**，也未被任何主流模块（如 ngx_http_upstream_module 或 ngx_http_proxy_module）定义。因此，直接在 log_format 中使用该变量会导致启动失败或日志中显示空值/破折号（-）。
为什么 $upstream_last_server_name 不可用
官方 Nginx 的 upstream 机制在负载均衡时确实会选中某个后端 server（IP:port），但默认不记录“被选中的 server 名称”——尤其当使用 IP 直连或未显式命名 upstream server 时，根本无“server name”可言。即使配置了 server example.com:8080，Nginx 内部也只解析并缓存为 IP 地址，不会保留原始域名作为运行时上下文变量。
部分第三方模块（如 nginx_upstream_check_module 或某些定制化分支）可能扩展了类似能力，但非通用方案，且与主线版本不兼容。
替代方案：用现有变量监控动态后端行为
虽然不能直接获取“最后选中的 server name”，但可通过组合标准变量观察上游转发逻辑是否按预期工作：
-
$upstream_addr：记录实际通信的后端地址（含 IP 和端口），若使用域名且开启resolver，此处会显示解析后的 IP（如10.1.2.3:8080）。若为多个 upstream server，还会以逗号分隔列出所有尝试过的地址（如10.1.2.3:8080, 10.1.2.4:8080）。 -
$upstream_status：对应每个$upstream_addr的 HTTP 状态码（同样逗号分隔），可用于判断是否发生重试、是否 fallback 到备用节点。 -
$upstream_response_time：各次 upstream 请求耗时（毫秒级，逗号分隔），结合$upstream_addr可分析不同后端响应性能差异。 -
自定义 upstream 名称 + map 映射：若你控制 upstream 配置，可为每个 server 指定唯一标识（如注释或利用
id参数），再配合map模块将$upstream_addr映射为可读名称（需注意 IP 可能复用，需确保映射唯一性）。
实用 log_format 示例（聚焦可观测性）
以下格式能有效支撑动态后端诊断：
log_format upstream_log '[$time_local] $remote_addr - $request '
'$status $body_bytes_sent '
'upstream: "$upstream_addr" '
'status: "$upstream_status" '
'rt: "$upstream_response_time" '
'uht: "$upstream_http_x_request_id"';
搭配此格式，日志样例为：
[12/Jan/2025:10:30:45 +0800] 192.168.1.100 - GET /api/v1/users HTTP/1.1 200 1243 upstream: "10.20.30.101:8000, 10.20.30.102:8000" status: "200, 502" rt: "0.023, 0.107" uht: "req-abc123"
从中可清晰看出：首次请求发往 10.20.30.101 成功；若失败则重试至 10.20.30.102 并返回 502 —— 这正是动态解析+故障转移的关键证据。
若真需 server 域名级别追踪（进阶建议）
可考虑以下路径：
- 在 upstream 配置中统一使用带端口的域名（如
server api-v1.example.com:8000），并启用resolver+resolve（需编译时启用--with-http_realip_module等依赖），再通过 Lua 模块（ngx_lua）在rewrite_by_lua*阶段解析并 set 变量（如$chosen_upstream_host），最后写入 log。 - 改用 OpenResty，在 upstream 阶段用 Lua 控制选主逻辑，并将目标 host 存入 context 变量供日志引用。
- 在服务发现层（如 Consul Template、Nginx Plus 的 API 或 eBPF 工具）前置注入 metadata 到请求头，由 Nginx 记录
$http_x_upstream_target。
这些方法绕开了原生限制，但引入了额外复杂度和维护成本，应按实际可观测性 ROI 权衡。
