Nginx反向代理CloudFront访问S3出现403权限拒绝问题求助

针对你遇到的Nginx→CloudFront→S3架构下代理访问返回403的问题，结合直接访问CloudFront正常的现象，以下是具体排查思路和解决办法：

1. Host头不匹配（最可能原因） #

你的Nginx配置中设置了proxy_set_header HOST $host;，这会将请求的Host头（redacted.co.uk）转发给CloudFront。而CloudFront分发默认仅接受自身域名（redacted.cloudfront.net）或已配置的Alternate Domain Names（CNAME）作为合法Host头。如果redacted.co.uk未添加到CloudFront的CNAME列表中，CloudFront会直接拒绝请求返回403。

修复方式：

• 方案一：修改Nginx的Host头配置，直接指定CloudFront域名：

  proxy_set_header HOST redacted.cloudfront.net;
  

• 方案二：在CloudFront分发配置中，将redacted.co.uk添加为Alternate Domain Names（CNAME），同时确保配置了对应域名的SSL证书（HTTPS场景下）。

2. Nginx路径拼接验证 #

虽然理论上当前location和proxy_pass的组合会将/cdn/somefile.js转发到/cdn/aa/somefile.js，但仍需确认实际转发路径是否正确：

• 开启Nginx的请求URI日志，或添加proxy_set_header X-Original-URI $request_uri;，然后查看CloudFront日志中的uri字段，确认转发路径与直接访问的路径一致。
• 如果路径存在拼接错误，可改用rewrite规则明确映射：

  location /cdn/ {
      rewrite ^/cdn/(.*)$ /cdn/aa/$1 break;
      proxy_pass https://redacted.cloudfront.net;
      # 保留必要的SSL和代理配置
      proxy_ssl_protocols TLSv1.2;
      proxy_ssl_server_name on;
  }
  

3. CloudFront缓存清理与规则检查 #

短暂正常的现象可能是缓存了之前的合法请求，后续缓存失效后触发403：

• 登录CloudFront控制台，手动清除/cdn/aa/*路径的缓存。
• 检查CloudFront的路径规则，确认/cdn/*规则正确关联到S3 origin，且无基于请求头的缓存策略导致权限验证失败。

4. 请求头干扰排查 #

除Host头外，其他转发的请求头可能触发CloudFront或S3的权限限制：

• 暂时注释掉X-Forwarded-Proto、X-Real-IP等非必要的proxy_set_header配置，仅保留Host头和SSL相关配置，测试是否恢复正常。
• 逐步添加其他头配置，定位导致问题的具体字段。

5. S3路径与权限二次确认 #

虽然直接访问正常，但仍需确认：

• S3桶中cdn/aa/somefile.js文件确实存在，注意路径大小写（S3路径区分大小写）。
• CloudFront的Origin Access Control（OAC）或Origin Access Identity（OAI）配置正确，确保CloudFront有权限访问S3资源。

内容的提问来源于stack exchange，提问作者Liam