应使用 $scheme 变量准确标识 https 协议,其值为 http 或 https,直接反映客户端原始请求协议;在标准 https 配置下天然生效,优于 $https 和 $server_port,多层代理时需配合 map 指令处理 x-forwarded-proto。

Nginx 的 access_log 本身不直接提供 $scheme 或 $https 变量来标识 HTTPS 协议,但可以通过内置变量 准确、可靠地反映请求是否走 HTTPS。关键在于:协议信息由客户端发起时决定,Nginx 通过 $scheme 和 $server_port 等变量间接体现,而非硬编码判断。
✅ 正确获取 HTTPS 协议标识的方法
$scheme
是最直接、推荐的方式。它返回请求实际使用的协议,值为http或https。
✅ 前提:Nginx 必须正确接收并解析原始请求(即未被中间代理篡改)。在标准 HTTPS 配置(如listen 443 ssl;)下,该变量天然生效。
❌ 不依赖 SSL 模块是否启用——只要该连接是 HTTPS,$scheme就是https。-
$server_port+$scheme组合验证(辅助判断)
若需进一步确认端口语义(例如区分80/443),可搭配使用:-
$server_port返回监听端口号(如443) - 但注意:端口 ≠ 协议(如反向代理可能将 HTTPS 请求转为 HTTP 到后端,此时
$server_port是443,但$scheme仍是https)
-
$https(仅作参考,不推荐主用)
该变量值为on或空字符串,表示当前连接是否启用了 SSL/TLS。
⚠️ 局限性:它只反映 Nginx 当前 socket 层是否加密,不等同于客户端原始协议(尤其在多层代理场景下易失真);而$scheme更语义化、更稳定。
? 示例:在 log_format 中加入 HTTPS 标识
log_format https_log '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" ' '$scheme $server_port $request_time';
然后启用:
access_log /var/log/nginx/access_https.log https_log;
日志中将看到类似:
192.168.1.100 - - [07/Jul/2026:11:05:22 +0000] "GET /api/v1/user HTTP/1.1" 200 1245 "-" "curl/8.7.1" https 443 0.023
⚠️ 注意事项
不要写
if ($scheme = https) { ... }来动态切换日志格式 ——if在access_log上下文中无效,且日志格式必须静态定义。
Teleport tsh SSH (Identity-First SSH Access, no passwords/static keys)下载使用tbot机器ID身份文件配合tsh CLI,通过Teleport访问控制SSH登录托管主机或执行远程命令。
-
若 Nginx 前有负载均衡器(如 ALB、CDN),需确保它透传
X-Forwarded-Proto: https,并在 Nginx 中用map提前映射$scheme,否则$scheme可能仍是http(因后端收到的是 HTTP 请求):map $http_x_forwarded_proto $real_scheme { default $scheme; https https; http http; } log_format proto_log ... '$real_scheme ...'; $ssl_protocol、$ssl_cipher等变量仅在启用 SSL 模块且实际处理 HTTPS 连接时有效,可用于记录 TLS 版本或加密套件,但不属于“协议标识”核心字段,属增强调试信息。
不复杂但容易忽略










