必须配齐 proxy_ssl_verify on、proxy_ssl_trusted_certificate、proxy_ssl_name 和 proxy_ssl_server_name on 四项指令并置于同一 location 或 upstream 块内，缺一不可；否则校验失效或返回 502 错误。
要让 proxy_ssl_verify on 真正发挥网关级严格校验作用，不能只打开开关，而需构建一套完整、可信、可验证的 TLS 上游链路。核心是确保 Nginx 在每次主动连接后端 HTTPS 服务时，都完成证书有效性、域名匹配性、信任链完整性三重检查。
必须配齐的四个基础指令
这四项缺一不可，且必须写在同一个 location 或 upstream 块内（写在 http 或 server 块中无效）：
-
proxy_ssl_verify on; —— 显式启用校验开关（默认是
off，不设等于跳过所有检查） - proxy_ssl_trusted_certificate /etc/nginx/ssl/ca-bundle.crt; —— 指向纯 PEM 格式的可信 CA 文件，只含根证书和中间 CA（不含私钥、不含后端证书）
-
proxy_ssl_name "api.internal"; —— 明确声明期望匹配的域名，用于比对证书 SAN 字段；即使
proxy_pass写的是 IP 或变量（如https://$backend_ip），也必须设置且大小写、通配符完全一致 - proxy_ssl_server_name on; —— 启用 TLS SNI，确保握手时发送正确域名，避免后端返回默认或泛域名证书
调优证书链深度与协议安全性
基础四指令能跑通，但生产环境需进一步收紧策略，防止链路被绕过：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
-
proxy_ssl_verify_depth 3; —— 默认只验证 1 层（终端直连根 CA），多数商业证书为“终端 → 中间 CA → 根 CA”三级链，设为 3 更稳妥；设为 1 会导致
unable to get issuer certificate - proxy_ssl_protocols TLSv1.2 TLSv1.3; —— 显式禁用 TLSv1.0/v1.1，规避协议降级攻击干扰校验逻辑
- proxy_ssl_ciphers HIGH:!aNULL:!MD5:!RC4; —— 排除弱加密套件，提升传输层抗篡改能力
关闭会话复用，防止状态缓存绕过校验
开启 TLS session 复用虽可降低握手开销，但在安全校验场景下反而带来风险：
- proxy_ssl_session_reuse off; —— 强制每次连接重新执行完整证书校验，避免异常证书状态被缓存复用
- 尤其在 WSS 代理、证书轮换频繁或后端集群存在证书不一致时，此项必不可少
验证文件权限与内容合法性
配置再正确，若证书文件不可读或格式错误，仍会失败：
- 确保
proxy_ssl_trusted_certificate路径存在，Nginx worker 进程（如www-data或nginx用户）有读取权限（建议644） - 文件必须为纯 PEM 格式：每张证书以
-----BEGIN CERTIFICATE-----开头、-----END CERTIFICATE-----结尾 - 可用命令快速验证：
openssl pkcs7 -print_certs -in /path/to/file.crt -noout能正常输出即为合法 - 若后端用私有 CA 或自签名证书，需把其根证书内容追加进该文件，不能仅依赖系统默认证书包
