实战解决反向代理到第三方云存储（S3/OSS）时因 SNI 不匹配导致的 403 权限错误-Nginx-PHP中文网

Nginx反向代理S3/OSS出现403的主因是TLS握手时SNI为空，需启用proxy_ssl_server_name on并用bucket完整域名写proxy_pass；SNI与Host头必须一致且指向有效bucket。

实战解决反向代理到第三方云存储（s3/oss）时因 sni 不匹配导致的 403 权限错误

直接结论：Nginx 反向代理到 S3/OSS 类服务（如 bucket.s3.amazonaws.com 或 bucket.oss-cn-hangzhou.aliyuncs.com）时出现 403，且直连正常，大概率是 proxy_pass 写了 IP 或未启用 proxy_ssl_server_name on，导致 TLS 握手阶段 SNI 字段为空，上游云存储拒绝建立连接——它根本没认出你要访问的是哪个 bucket。

为什么 S3/OSS 对 SNI 敏感

S3 和主流对象存储都依赖 SNI 区分请求归属的 bucket。例如：

https://my-bucket.s3.us-east-1.amazonaws.com 和 https://other-bucket.s3.us-east-1.amazonaws.com 共享同一 IP，靠 Client Hello 中的 SNI 字段区分
如果 Nginx 发起 TLS 握手时不带 SNI（比如 proxy_pass https://52.216.128.100/），上游会默认返回一个“兜底”证书或直接拒连，常见表现为 403（不是 404，也不是 SSL 错误）
这种 403 不带明确提示，curl -v 看不到证书错误，但 Wireshark 抓包可确认 Server Name Indication 字段为空

必须启用 proxy_ssl_server_name on 并用域名写 proxy_pass

这是最常被忽略的硬性要求。Nginx 默认不会把原始请求的 Host 头复用为上游 SNI；它只认 proxy_pass 后面的域名。

✅ 正确写法：proxy_pass https://my-bucket.s3.us-east-1.amazonaws.com/;（结尾斜杠不能少）
✅ 必须加：proxy_ssl_server_name on;（Nginx 1.7.0+，低于此版本必须升级）
❌ 错误写法：proxy_pass https://52.216.128.100/;（SNI 丢失）
❌ 错误写法：proxy_pass https://s3.us-east-1.amazonaws.com/;（缺少 bucket 前缀，SNI 是 s3.us-east-1.amazonaws.com，无法路由到具体 bucket）

多级代理或动态 bucket 场景下要显式控制 SNI

如果你的业务需要通过一个统一入口反向代理多个 bucket（比如按请求路径 /bucket-a/xxx → bucket-a.s3.region.amazonaws.com），就不能只靠静态 proxy_pass。

腾讯文档智能助手

腾讯文档智能助手是一款AI办公效率工具，腾讯推出的AI文档生成和辅助工具。

下载

用 resolver 避免 DNS 缓存干扰：resolver 8.8.8.8 valid=30s;
用变量拼接 bucket 域名，并强制指定 SNI：proxy_ssl_name "$bucket_domain";
示例配置片段：

location ~ ^/([^/]+)/(.*)$ {
    set $bucket_name $1;
    set $bucket_domain "$bucket_name.s3.us-east-1.amazonaws.com";
    resolver 8.8.8.8 valid=30s;
    proxy_pass https://$bucket_domain/$2;
    proxy_ssl_server_name on;
    proxy_ssl_name "$bucket_domain";
    proxy_set_header Host $bucket_domain;
}

注意：proxy_ssl_name 是 Nginx 1.11.12+ 才支持，旧版本只能走静态域名 + proxy_ssl_server_name on。

别忘了 Host 头和证书验证的配合

SNI 解决了“连谁”，Host 头解决“找谁的资源”。两者不一致也会触发 403（尤其 OSS）：

proxy_set_header Host $host; 是错的——它会把客户端请求的 Host（比如 cdn.example.com）透传过去，上游不认识
应设为 bucket 域名：proxy_set_header Host $bucket_domain;（静态场景）或 proxy_set_header Host "$bucket_name.s3.us-east-1.amazonaws.com";
proxy_ssl_verify off; 可临时关闭证书校验（测试用），但生产环境必须配 proxy_ssl_trusted_certificate，否则可能因证书链不全被拒

真正容易被忽略的是：SNI 和 Host 头必须指向同一个逻辑 bucket，且这个 bucket 在云厂商控制台已正确配置跨域（CORS）与权限策略——否则即使 TLS 握手成功，HTTP 层仍会返回 403。