$scheme 是 nginx 日志中不可替代的协议锚点，精准反映客户端原始请求协议（http/https），用于审计跳转率、发现协议降级、暴露代理透传漏洞、归因敏感行为，并需配合脱敏策略防范信息泄露。
$scheme 在 Nginx 的 log_format 中看似简单，仅输出 http 或 https，但它在安全分析中承担着不可替代的“协议锚点”作用——不是锦上添花，而是判断请求真实意图与基础设施可信边界的底层依据。
精准识别协议降级与跳转链路风险
当用户本应走 HTTPS 却被错误导向 HTTP（如配置失误、中间人篡改或 CDN 透传异常），$scheme 是唯一能直接反映原始协议的变量。它不依赖 $http_x_forwarded_proto（可伪造）、不依赖端口（$server_port 无法区分反向代理后的真实协议），也不受重定向响应影响——哪怕返回了 301 https://...，原始请求的 $scheme 仍是 http，这正是审计跳转率、发现未强制 HTTPS 的入口页、定位混合内容（mixed content）源头的关键证据。
暴露代理层协议剥离漏洞
在反向代理架构中，若前端负载均衡器终止 TLS 后以纯 HTTP 转发至 Nginx，Nginx 的 $scheme 将恒为 http，即使客户端发起的是 HTTPS 请求。日志中持续出现 https 请求却记录为 http，说明协议信息未被正确透传（如缺失 proxy_set_header X-Forwarded-Proto $scheme;），这不仅影响监控准确性，更意味着业务层无法基于协议做安全决策（如拒绝非 HTTPS 的敏感操作），构成隐蔽的信任链断裂。
支撑敏感行为的协议上下文归因
- 排查登录接口异常：结合
$scheme和$status，可快速确认失败是否集中发生在 HTTP 通道（如 CSRF 防护缺失导致的跨协议攻击）； - 审计 API 密钥泄露：若日志中含
$args或$request_body（不推荐），$scheme可辅助判断密钥是否曾通过明文通道传输； - 验证 HSTS 策略效果：统计 HTTP 请求占比下降趋势，比单纯看 HTTPS 响应数更能反映用户实际访问路径迁移情况。
避免成为新的敏感信息出口
虽然 $scheme 本身无敏感性，但若其所在日志格式中混入 $http_cookie、$args、$upstream_http_set_cookie 等变量，就会形成“协议+凭证”的强关联泄露组合。安全实践中必须坚持：启用 $scheme 的同时，严格剔除所有可能携带身份标识、会话令牌、原始参数的变量；错误日志级别设为 warn 或更高，防止调试信息意外落盘；日志文件权限收紧至 600，并避免写入网络共享目录。
