GCP Cloud CDN可缓存内容在Chrome/Firefox中未缓存的原因排查

现象总结 #

• 配置GCP Cloud CDN对接GCS存储桶后，二级子目录下的图片（如http://example/foo/bar/image.jpeg）在Chrome/Firefox中，非首次请求返回304状态，statusDetails显示"response_sent_by_backend"，看似未命中CDN缓存；但用curl -s -D - -o /dev/null http://example/foo/bar/image.jpeg请求该图片能正常命中缓存（statusDetails为"response_from_cache"），一级目录下的图片在浏览器中也能正常缓存。
• 该图片响应头完全符合CDN缓存要求：Status:200、Cache-Control: public,max-age=3600、Content-Length:313695，存储桶已授予allUsers Storage Object Viewer权限。
• 最终确认所有功能运行正常。

原因解析 #

这是浏览器与curl的请求行为差异导致的正常现象，核心在于浏览器的条件请求机制：

1. 浏览器首次请求资源后，会在本地缓存资源，并记录Last-Modified或ETag响应头的值。
2. 再次请求同一资源时，浏览器会自动发送If-Modified-Since（对应Last-Modified）或If-None-Match（对应ETag）请求头，询问后端资源是否更新。
3. GCS收到条件请求后，若资源未修改，会返回304 Not Modified响应，此时CDN会将该304响应转发给浏览器，因此statusDetails显示"response_sent_by_backend"。
4. 浏览器收到304后，直接使用本地缓存的资源，不会重新下载，功能完全正常，只是表面看起来未命中CDN缓存。
5. curl默认不会发送这些条件请求头，所以CDN直接返回缓存的200响应，表现为命中缓存，耗时极短。

验证与结论 #

• 虽然浏览器请求显示304且状态详情指向后端，但实际浏览器是在使用本地缓存，资源加载逻辑正常。
• 若要验证CDN是否真的缓存了该资源，可在浏览器中禁用缓存（Chrome：F12→Network→勾选"Disable cache"）后刷新请求，此时会发送不带条件头的请求，应能看到CDN返回200且statusDetails为"response_from_cache"。

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