关闭 proxy_ssl_verify off 会完全跳过对后端 HTTPS 证书的校验，导致无法验证 CA 签发、域名匹配、有效期及吊销状态，使中间人攻击、误连错误服务等风险失控，严重违反 PCI DSS、等保2.0 等安全合规要求。
关闭 proxy_ssl_verify off 会让 Nginx 完全跳过对后端 HTTPS 服务证书的校验，这在对接自签名证书时看似“省事”，实则埋下严重安全隐患——它等于主动放弃 TLS 身份认证这一核心安全能力。
跳过验证等于放弃身份确认
启用 proxy_ssl_verify off 后，Nginx 不再检查：
- 后端证书是否由可信 CA 签发（自签名证书天然不被系统信任）
- 证书中的域名（SAN）是否匹配预期（如 proxy_ssl_name 设置值）
- 证书是否在有效期内、是否已被吊销（即使支持 OCSP/CRL 也无效）
这意味着只要 TCP 连通、TLS 握手能完成，无论后端是目标服务、测试环境、镜像节点，还是中间人伪造的恶意服务器，Nginx 都会照常转发流量。
典型攻击面与实际后果
这种配置直接削弱 HTTPS 的四大安全基石中的“身份认证”和“完整性”：
- 中间人攻击（MitM）无防护：攻击者可在网络路径中部署仿冒后端，返回任意内容，Nginx 无法识别并拒绝
- 误连风险高发：DNS 污染、配置错误、服务漂移（如 Kubernetes Pod IP 变更）都可能导致请求被路由到错误服务，且无告警
- 调试掩盖真实问题：本该暴露的证书链缺失、域名不匹配、过期等问题被静默忽略，延迟发现生产隐患
- 合规性失效：PCI DSS、等保2.0、GDPR 等均要求服务间通信具备可验证的身份机制，off 状态不满足基线要求
比“关验证”更稳妥的自签名应对方案
若后端确为自签名或私有 CA 签发，应保持 proxy_ssl_verify on，并通过以下方式合法纳入信任链：
- 将自签根证书或私有 CA 根证书内容（PEM 格式）写入 proxy_ssl_trusted_certificate 指向的文件
- 显式设置 proxy_ssl_name 匹配证书中 SAN 字段（不可省略，尤其当 proxy_pass 使用 IP 或变量时）
- 开启 proxy_ssl_server_name on，确保 SNI 正确传递，避免后端返回默认证书
- 根据证书链层级设好 proxy_ssl_verify_depth（自签名单层证书设为 1 即可）
- 禁用会话复用：proxy_ssl_session_reuse off，防止异常证书被缓存绕过校验
为什么不能靠“浏览器点继续”来解决？
前端浏览器手动信任自签名证书，只影响该浏览器与 Nginx 之间的连接；而 Nginx 到后端的连接是服务端行为，完全独立。用户在浏览器点“继续”对 Nginx 的 upstream 校验毫无作用。把安全责任推给终端用户点击，既不可靠也不可控，更不符合零信任原则。
