浏览器可访问GCS对象但代理用同URL访问失败问题排查

问题场景 #

• 环境：GCS存储桶关联Cloud CDN、负载均衡，通过子域名cloud-storage-manager-test.<mydomain>.com对外提供资源服务
• 异常现象：浏览器直接访问http://cloud-storage-manager-test.<mydomain>.com/bob.png能正常显示图片，但通过代理访问同一个URL时，返回404错误，响应内容如下：

  <?xml version='1.0' encoding='UTF-8'?><Error><Code>NoSuchKey</Code><Message>The specified key does not exist.</Message></Error>
  

• 日志验证：CDN日志显示代理请求和浏览器请求的URL完全一致，但存储桶日志未记录任何错误，排查陷入僵局

排查过程 #

1. 代理特性测试：代理要求携带Bearer令牌才能转发请求，且不会自动删除该请求头，针对这点做了验证：
   • 占位令牌测试：执行命令

     curl -H "Authorization: Bearer xyzzy" http://<目标完整URL>
     

     返回认证错误：

     <?xml version='1.0' encoding='UTF-8'?><Error><Code>AuthenticationRequired</Code><Message>Authentication required.</Message></Error>
     

   • 真实代理令牌测试：使用代理专用的Bearer令牌（非GCS官方令牌）执行命令

     curl -H "Authorization: Bearer <代理专用真实令牌>" http://<目标完整URL>
     

     成功下载到目标资源
2. Host头排除测试：执行命令

   curl -H 'Host: Nonsense.com' <目标完整URL>
   

   能正常获取图片，排除Host头配置错误的可能

问题根因 #

GCS/Cloud CDN的请求头解析逻辑对非GCS标准的Authorization Bearer令牌处理异常，返回了错误的NoSuchKey（文件不存在）错误，而非更精准的认证类错误。代理请求时携带了GCS无法识别的Bearer令牌，触发了这个误报的404。

解决方案 #

• 直接处理方式：配置代理在转发请求到Cloud CDN时，移除Authorization请求头。因为存储对象已经开放全员访问，不需要携带该令牌；即使需要认证，代理的专用令牌也不被GCS识别，反而会触发错误。
• 保留代理认证逻辑的处理：调整代理的认证流程，让代理在完成自身认证后，转发请求到GCS/CDN时不再携带Authorization头，改用其他方式处理代理侧的认证需求。

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