我启用了Amazon CloudFront GZIP功能："压缩对象自动"。
这是我的CloudFront中的所有文件发生的，而其他CSS/JS文件正在加载为GZIP(仔细检查我的服务器请求标题正在接受GZIP文件Accept-Encoding: gzip(。
我真的迷失了尝试解决这个问题，因为所有教程和Google搜索结果都会对如何自动检查"无线电"按钮进行相同的解释。 - 显然无济于事。
我认为也许我不能GZIP文件，因为它们太小而无法压缩 - 但是在Google Speed测试之后清楚地说我可以用GZIP压缩这些文件。
Compressing https://Cloudfront.cloudfront.net/live/static/rcss/bootstrap.min.css could save 100.3KiB (83% reduction).
Compressing https://Cloudfront.cloudfront.net/live/static/rcss/style.css could save 60.5KiB (80% reduction).
Compressing https://Cloudfront.cloudfront.net/live/static/shop/css/jquery.range.css could save 4.6KiB (83% reduction).
Compressing https://Cloudfront.cloudfront.net/live/static/rcss/font-awesome.min.css could save 21.9KiB (77% reduction).
Compressing https://Cloudfront.cloudfront.net/live/static/rcss/responsive.css could save 20KiB (80% reduction).
Compressing https://Cloudfront.cloudfront.net/live/static/general.min.js?ver=9.70 could save 232.9KiB (72% reduction).
Compressing https://Cloudfront.cloudfront.net/live/static/rcss/magnific-popup.css could save 5.7KiB (75% reduction).
Compressing https://Cloudfront.cloudfront.net/live/static/bootstrap.min.js could save 26.4KiB (73% reduction).
Compressing https://Cloudfront.cloudfront.net/…ve/static/plugins/jquery.validate.min.js could save 14KiB (67% reduction).
Compressing https://Cloudfront.cloudfront.net/…tic/plugins/jquery.magnific-popup.min.js could save 13.2KiB (63% reduction).
Compressing https://Cloudfront.cloudfront.net/live/static/plugins/jquery.range.min.js could save 3.9KiB (66% reduction).
Compressing https://Cloudfront.cloudfront.net/live/static/voting/jquery.cookie.js could save 1.2KiB (53% reduction).
我缺少哪一部分，可以帮助我使用CloudFront GZIP？
这就是我的响应标头的样子：
Accept-Ranges:bytes
Cache-Control:max-age=0
Connection:keep-alive
Content-Length:122540
Content-Type:text/css
Date:Sun, 23 Apr 2017 13:14:07 GMT
ETag:"2cb56af0a65d6ac432b906d085183457"
Last-Modified:Tue, 02 Aug 2016 08:49:54 GMT
Server:AmazonS3
Via:1.1 2cb56af0a65d6ac432b906d085183457.cloudfront.net (CloudFront)
X-Amz-Cf-Id:eCPcSDedADnqDZMlMbFjj08asdBSn7_lfR0imlXAT181Y8qRMtSZASDF27AiSTK8PDQ==
x-amz-meta-s3cmd-attrs:uid:123/gname:ubuntu/uname:ubuntu/gid:666/mode:666/mtime:666/atime:666/md5:2cb56af0a65d6ac432b906d085183457/ctime:666
X-Cache:RefreshHit from cloudfront
我理解了200和304的回报概念 - 删除浏览器缓存时总是显示200个响应。
所以有一些来自Cloudfront的缓存？我将Bootstrap3.min.css文件添加到"无效"中。表 - 不起作用。
确保文件设置为压缩。
将其添加到我的weblity.com.conf文件中以启用GZIP并显示content-length标题：
DeflateBufferSize 8096
SetOutputFilter DEFLATE
DeflateCompressionLevel 9
尝试从我的.conf文件中删除DeflateBufferSize 8096，并将<AllowedHeader>Content-Length</AllowedHeader>添加到" CORS配置"中。 - 我确实得到了Content-Length - 但仍然没有GZIP。(在使用S3网站的CloudFront之后，Origin不提供GZPIPPECT文件(
这是我目前得到的：
Request URL:https://abc.cloudfront.net/live/static/rcss/bootstrap3.min.css
Request Method:GET
Status Code:200 OK
Remote Address:77.77.77.77:443
Referrer Policy:no-referrer-when-downgrade
Response Headers
Accept-Ranges:bytes
Age:1479
Connection:keep-alive
Content-Length:122555
Content-Type:text/css
Date:Wed, 26 Apr 2017 08:48:34 GMT
ETag:"83527e410cd3fff5bd1e4aab253910b2"
Last-Modified:Wed, 26 Apr 2017 08:43:05 GMT
Server:AmazonS3
Via:1.1 5fc044210ebc4ac6efddab8b0bf5a686.cloudfront.net (CloudFront)
X-Amz-Cf-Id:3ZBgDY0c1WV_Pc0o_Bjwa5cQ9D9T-Cr30QDxd_GvD30iQ8W1ImReQIH==
X-Cache:Hit from cloudfront
Request Headers
Accept:text/css,*/*;q=0.1
Accept-Encoding:gzip, deflate, sdch, br
Accept-Language:en-US,en;q=0.8
Cache-Control:no-cache
Connection:keep-alive
Host:abc.cloudfront.net
Pragma:no-cache
Referer:https://example.com/
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.81 Safari/537.36
以下内容：http：//docs.aws.amazon.com/amazoncloudfront/latest/developerguide/servingcompressedfiles.html
如果您配置了云方面以压缩内容，则云额将从其压缩的文件中删除ETAG响应标头。当存在ETAG标头时，CloudFront和您的Origin可以使用它来确定CloudFront Edge Cache中文件版本是否与Origin Server上的版本相同。但是，压缩后两个版本不再相同。
我获得相同的eTag含义 - 服务的CSS文件不会通过任何压缩。想想我可能没有为此特定文件设置压缩 - 现在设置为 */bootstrap3.min.css(因为它在目录内(。我之前有这个 bootstrap3.min.css两者都不起作用。
我的URL是：https：//abc.cloudfront.net/live/static/rcss/bootstrap3.min.css之后，我将无效部分编辑为：
/live/static/rcss/bootstrap3.min.css
/static/rcss/bootstrap3.min.css
/rcss/bootstrap3.min.css
/bootstrap3.min.css
这可以是我的实际问题吗？
X-Cache: RefreshHit from cloudfront
这意味着CloudFront通过有条件的请求(例如If-Modified-Since(检查了原点，并且响应为304 Not Modified，表明Origin Server(S3(上的内容与CloudFront最初缓存资源时没有变化。
...可能是在启用"自动压缩对象"之前被缓存的。
如果考虑到它，对于云的对象，当对象从来源进入时，而不是当它们向观看者出去时，它将更加有效，因此它已经已经被压缩了。p>记录了这一点：
CloudFront从您的原点获取文件时会在每个边缘位置中压缩文件。当您配置CloudFront以压缩您的内容时，它不会压缩已经在边缘位置的文件。此外，当文件在边缘位置到期并且CloudFront将文件转发到您的来源的另一个请求时，CloudFront如果您的来源返回HTTP状态代码
304，则CloudFront不会压缩文件，这意味着Edge位置已经具有最新的位置文件的版本。如果您希望CloudFront压缩已经在边缘位置的文件，则需要使这些文件无效。http://docs.aws.amazon.com/amazoncloudfront/latest/developerguide/servingcompressedfiles.html
因此，*的缓存无效，以清除未压缩版本。
但是等待...在同一页面上更高，似乎存在冲突的信息：
注意
如果CloudFront在缓存中具有未压缩的文件，它仍将请求转发到Origin。
鉴于上面的信息，这似乎是差异。但是，我相信这里的问题是一些不言而喻的假设之一。此信息很可能只适用于响应未发送Accept-Encoding: gzip的观众缓存的未压缩副本，在这种情况下，CloudFront的正确行为将是独立缓存压缩和未压缩的响应，以及如果没有可用的对象的压缩副本，请联系原点。
或者，它可以解释为表示Cloudfront确实发送了请求，但是由于响应是304，尽管没有压缩，但它服用了缓存的副本。
使您的缓存无效，然后等待无效显示它已经完成，然后重试。这应该是纠正此行为所需的全部。
可能是因为S3没有发送所需的Content-Length标头响应。
检查此答案以获取更多详细信息：https：//stackoverflow.com/a/42448222/4005566