Nginx access_log 默认不记录客户端源端口，也无法通过内置变量获取；仅能记录服务器监听端口（$server_port）和上游端口（$upstream_port），客户端源端口需依赖前置设备透传或底层抓包实现。
Nginx 的 access_log 默认不记录客户端请求所使用的入站网络端口（即客户端发起连接时的源端口），也无法直接通过内置变量获取该端口。
这是因为 HTTP 请求日志关注的是应用层行为（谁、何时、访问什么、结果如何），而客户端源端口属于传输层（TCP）信息，Nginx 在处理完 TCP 连接建立后，通常不保留或暴露该字段——它既不在 $remote_addr 中体现，也没有对应的 $remote_port 变量（该变量不存在）。
哪些端口信息 Nginx 实际能记录？
-
✅ 服务器监听端口（即 Nginx 接收请求的目标端口）：
可用$server_port获取，例如80或443。
示例日志片段：192.168.1.100 - - [07/Jul/2026:17:21:00 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/8.5.0" server_port=443
✅ 客户端 IP + 代理链中 X-Forwarded-For 的原始 IP（需配合反向代理配置）：
但依旧不包含该原始 IP 对应的源端口。❌ 客户端源端口（如 54321）：
Nginx 不解析、不记录、也不提供变量访问。这是由 Linux 内核和 socket 层决定的——一旦连接建立，应用层（Nginx）看到的是已关联的 socket 文件描述符，而非三次握手时的源端口号。
如果你确实需要客户端源端口，怎么办？
-
方案一：在 TCP 层抓包分析（非 Nginx 日志范畴）
使用tcpdump或Wireshark捕获流量：tcpdump -i any 'port 80 or port 443' -nn -q | grep -E 'IP .*\.'
输出示例：
IP 192.168.1.100.54321 > 10.0.0.1.443: ...
Teleport tsh SSH (Identity-First SSH Access, no passwords/static keys)下载使用tbot机器ID身份文件配合tsh CLI，通过Teleport访问控制SSH登录托管主机或执行远程命令。
-
方案二：在前置设备（如负载均衡器、防火墙、WAF）记录并透传
某些高级 LB（如 AWS ALB/NLB、F5、Cloudflare）支持将客户端源端口作为自定义 header（如X-Client-Port）注入请求，然后你在 Nginx 中用$http_x_client_port记入日志：log_format with_port '$remote_addr:$http_x_client_port - [$time_local] "$request" $status $body_bytes_sent'; access_log /var/log/nginx/access.log with_port;
⚠️ 注意：这依赖上游设备支持且主动设置，Nginx 自身无法生成该值。
方案三：使用 systemd journal 或 conntrack 辅助审计（仅限 Linux）
通过conntrack -L | grep :80查看当前 NAT 连接表，可看到src=192.168.1.100:54321 dst=...，但这是实时连接快照，不可替代日志持久化。
小结
- Nginx
access_log不记录、也无法获取客户端源端口； - 能记录的是
$server_port（服务监听端口）和$upstream_port（如果用了 upstream）； - 若业务强依赖源端口（如安全审计、连接复用分析），需在更底层（网络设备或抓包）实现，而非依赖 Nginx 日志。
不复杂但容易忽略。
