核心在于严格分离前端https与后端https处理逻辑：前端配置ssl_certificate和ssl_certificate_key匹配域名；后端连接则通过proxy_ssl_verify、proxy_ssl_trusted_certificate等指令按信任模型独立控制tls校验，避免混用证书导致502或握手失败。
核心在于区分“前端 HTTPS”和“后端 HTTPS”的处理逻辑，不能混为一谈。前端是用户访问你的域名（如 s3.example.com），需要正确配置 SSL 证书；后端是 Nginx 去连 OSS、COS、MinIO 等服务，此时 TLS 行为必须按信任模型单独控制，否则极易出现 502、握手失败或签名异常。
严格分离前后端证书处理
前端只管 ssl_certificate 和 ssl_certificate_key，确保匹配公网域名；后端连接不复用这些证书，而是靠 proxy_ssl_verify 和 proxy_ssl_trusted_certificate 控制校验行为：
- 对接公有云（OSS/COS/S3）：保持
proxy_ssl_verify on，并指定系统 CA 包，例如/etc/ssl/certs/ca-certificates.crt - 对接自签名 MinIO 或内网 S3 兼容服务：必须设
proxy_ssl_verify off，或加载私有 CA 文件到proxy_ssl_trusted_certificate
按信任模型拆分 upstream
所有后端不能塞进同一个 upstream。混合配置会导致策略冲突——比如给 MinIO 开了校验，请求立刻失败；给 COS 关了校验，又失去安全性。
- 建独立
upstream分组，如upstream cos_group { ... }和upstream minio_internal { ... } - 每组内部保证证书策略一致，避免交叉污染
- 示例中
minio_internal可直接关校验：proxy_ssl_verify off;
显式开启并传递 SNI 信息
部分云存储（尤其是兼容 S3 的私有网关）依赖 SNI 才能正确选证和路由。Nginx 默认不传 SNI，必须手动启用：
- 在对应
location块中加proxy_ssl_server_name on; - 同时设置
proxy_set_header Host $host;，确保后端收到正确 Host 头 - 若后端要求特定 SNI 名（如
bucket.ap-beijing.myqcloud.com），用proxy_ssl_name显式覆盖
修复重定向与协议头错乱
HTTPS 流量经代理后跳转出错（如返回 HTTP Location、地址栏变 HTTP），本质是后端响应没感知真实协议。需补两个关键头：
-
proxy_set_header X-Forwarded-Proto https;：告诉后端用户实际用的是 HTTPS -
proxy_redirect http:// https://;：自动把后端返回的Location: http://...改成https:// - 若后端是 Spring Boot 等框架，还需确认其是否读取
X-Forwarded-Proto来生成跳转链接
