应直接拒绝未加密的明文API请求，在协议入口层拦截：通过Nginx监听80端口并匹配/api/路径返回400，配合X-Forwarded-Proto头校验、上游HTTPS强制及日志审计，杜绝HTTP API访问。
直接拒绝未加密的明文 API 请求，关键不是“拦截后处理”，而是让 HTTP 请求根本无法抵达业务逻辑层——在协议入口就切断。
强制重定向到 HTTPS（针对所有 API 路径）
在 server 块中监听 80 端口，对匹配 API 路径的请求统一 301 跳转：
- 用正则精准识别 API 入口，避免误跳静态资源或前端页面：
location ~ ^/api/ { if ($scheme = http) { return 301 https://$host$request_uri; } } - 不推荐用全局
if ($scheme = http) { return 301 ... }，否则可能影响非 API 的健康检查或监控探针 - 确保后端服务只监听 HTTPS 的 upstream，避免 Nginx 自己降级代理
关闭 HTTP 端口上的 API 响应能力
比重定向更严格的做法：直接拒绝对 API 路径的 HTTP 请求，不返回跳转，而是明确拒绝：
server { listen 80; location ~ ^/api/ { return 400 "API requires HTTPS"; } }- 返回 400 比 403 更准确——这不是权限问题，是协议违规
- 配合日志记录：
log_format api_http_denied '$remote_addr - $request_time "$request"';，便于审计明文尝试
校验上游响应头，防止后端意外暴露 HTTP 接口
即使 Nginx 层做了限制，也要防住后端服务自己开了 HTTP 监听并被绕过：
- 在 proxy_pass 后添加安全头校验：
proxy_hide_header Location;防止后端 302 到 HTTP 地址 - 用
proxy_ssl_verify on;（若走 HTTPS 上游）+ 严格证书校验，避免中间人伪造响应 - 对 /health、/status 等路径也启用相同规则，避免探测接口成为突破口
补充：真实 IP 与 CDN 场景下的协议一致性
如果流量经过 CDN 或 LB，需确保 X-Forwarded-Proto 头可信，并据此判断原始协议：
- 先声明可信代理：
set_real_ip_from 192.0.2.0/24; # 替换为你的 CDN IP 段 - 再基于头判断：
if ($http_x_forwarded_proto != "https") { return 400; } - 务必配合
real_ip_header X-Forwarded-For;和real_ip_recursive on;，避免伪造
