全链路HTTPS加密要求客户端到Nginx、Nginx到后端服务全程启用并严格校验TLS：后端须自持有效CA签发证书并监听HTTPS端口，Nginx需配置proxy_ssl_verify on、proxy_ssl_trusted_certificate及proxy_ssl_name确保上游身份可信，同时限制X-Forwarded头来源并管控证书文件权限。
全链路加密不是简单打开 HTTPS 就完事，关键是 Nginx 到后端服务这段连接也必须加密且可信。否则，即便用户访问的是 HTTPS 网站，内部流量仍可能被监听或篡改。
确认上游服务已启用 HTTPS
后端服务（如 Node.js、Python Flask、Java Spring Boot）需自行配置 TLS，监听 443 或其他 HTTPS 端口，并提供有效证书。Nginx 不会替后端做加密，它只负责验证——所以后端必须先支持 HTTPS。
- 避免使用自签名证书直接上线；若测试阶段必须用，后续务必替换为 CA 签发证书
- 确保后端证书的 Common Name（CN）或 Subject Alternative Name（SAN）匹配 Nginx 配置中 proxy_ssl_name 指定的主机名
- 后端证书有效期、吊销状态需正常，否则 Nginx 启用 proxy_ssl_verify on 时会拒绝连接
在 Nginx 中启用并严格校验上游 TLS
仅设置 proxy_pass https://backend 是不够的，默认不校验证书，存在中间人风险。必须显式开启验证并指定信任锚点。
- 使用 proxy_ssl_verify on 强制启用证书验证
- 通过 proxy_ssl_trusted_certificate 指向包含根证书和中间证书的 PEM 文件（如 /etc/nginx/ssl/upstream-ca.crt），不能只放后端证书
- 设置 proxy_ssl_name "backend.example.com"，让 Nginx 校验证书中的域名是否匹配，防止证书错用
- 可选但推荐：添加 proxy_ssl_verify_depth 2 明确信任链深度，避免因路径过长导致验证失败
安全传递客户端信息，不破坏信任链
启用上游 HTTPS 后，X-Forwarded-For、X-Forwarded-Proto 等头仍需正确设置，但必须限制来源，防止伪造。
- 只从可信代理（如本机 127.0.0.1 或内网固定段）接收 X-Forwarded-* 头，用 set_real_ip_from + real_ip_header X-Forwarded-For 提取真实 IP
- 始终用 proxy_set_header X-Forwarded-Proto $scheme，确保后端明确知道原始协议是 HTTP 还是 HTTPS
- 禁用危险头透传：proxy_hide_header X-Powered-By、proxy_hide_header Server
证书与密钥权限必须严格管控
上游验证依赖本地 CA 证书文件，该文件若被篡改或泄露，整个验证机制即失效。
- CA 证书文件（upstream-ca.crt）权限设为 644 即可，但存放路径不应对外可读
- Nginx 主配置及 SSL 相关文件所在目录建议属主为 root:root，禁止非特权用户写入
- 定期检查证书有效期，可配合脚本 + cron 自动提醒更新 upstream CA 或后端服务证书
