CloudFront未返回Content-Encoding头，S3托管压缩CSS/JS缓存问题求助

Hey Greg, let's work through your CloudFront + S3 compression and caching header issues step by step—this is a super common pain point, so we’ll get it sorted out.

First, let’s tackle why compressed files aren’t reaching the browser. CloudFront’s automatic compression has specific prerequisites, so let’s verify each one:

• Confirm CloudFront’s compression setting is enabled
  Go to your CloudFront distribution → Behaviors tab → Edit the behavior for your CSS/JS files. Make sure the Compress objects automatically option is set to Yes. This tells CloudFront to compress eligible files on the fly (or serve pre-compressed files if you’ve uploaded them that way).

• Ensure your files are eligible for compression
  CloudFront only compresses files that meet these criteria:

  • File size is between 1KB and 10MB
  • MIME type is in CloudFront’s supported list (for your use case, confirm text/css and application/javascript are included—they’re enabled by default)
  • If you uploaded pre-compressed files (e.g., style.css.gz), you need to:
    1. Add Accept-Encoding to your CloudFront behavior’s Cache based on selected request headers (so CloudFront serves the right compressed version based on the browser’s request)
    2. Make sure the S3 object’s Content-Encoding metadata is set to gzip (or br for Brotli)

• Test with curl to validate
  Run this command to check if compression is working:

  curl -H "Accept-Encoding: gzip, br" -I https://your-cloudfront-domain/path/to/style.css
  

  Look for Content-Encoding: gzip or br in the response headers, and confirm the Content-Length is smaller than the uncompressed file size.

Next, let’s set up the cache headers to ensure browsers cache your static assets long-term. The easiest way is to use CloudFront’s cache and response header policies (instead of relying solely on S3 metadata):

• Create a custom Cache Policy

  1. Go to CloudFront → Policies → Cache Policies → Create policy
  2. Set TTL values: For static CSS/JS, use 31536000 (1 year) for Minimum/Maximum/Default TTL (you can adjust if you need more frequent updates, but 1 year is standard for immutable assets)
  3. In Cache key settings, add Accept-Encoding to the Headers list—this ensures CloudFront caches separate versions for compressed and uncompressed files
  4. Save the policy

• Create a custom Response Headers Policy

  1. Go to CloudFront → Policies → Response Headers Policies → Create policy
  2. Under Custom headers, add a Cache-Control header with the value public, max-age=31536000
  3. (Optional) Add an Expires header with a far-future date like Thu, 31 Dec 2037 23:59:59 GMT for legacy browser support
  4. Save the policy

• Attach policies to your CloudFront Behavior
  Go back to your distribution’s Behaviors tab → Edit the relevant behavior. Under Cache policy, select your custom cache policy; under Response headers policy, select your custom response header policy. Save the changes.

• Invalidate old CloudFront cache
  Since CloudFront caches content at edge locations, you’ll need to invalidate existing cache to apply the new settings:

  1. Go to your distribution → Invalidations tab → Create invalidation
  2. Enter /* as the path and submit—this clears all cached content (it takes a few minutes to propagate)

• Test the caching headers
  Run this command to check the response headers:

  curl -I https://your-cloudfront-domain/path/to/script.js
  

  You should see Cache-Control: public, max-age=31536000 in the response. After a second request, check for CloudFront-Cache-Status: HIT to confirm CloudFront is serving cached content.

• If changes aren’t showing up: Wait for CloudFront configuration to propagate (usually 5-10 minutes) or disable browser cache in DevTools when testing
• Ensure your S3 bucket uses an Origin Access Control (OAC) or Origin Access Identity (OAI) so CloudFront can access files without making them public
• If S3 has existing Cache-Control metadata, CloudFront will use that unless you enable the Override origin option in your response header policy

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