应使用 $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 版本或加密套件，但不属于“协议标识”核心字段，属增强调试信息。

不复杂但容易忽略