在HTTP缓存体系中，ETag（实体标签）用于标识资源的特定版本，是客户端与服务器之间验证缓存是否仍然有效的重要机制。Apache服务器内置了ETag生成与校验逻辑，开发者只要理解FileETag指令的作用，就能准确控制缓存验证行为，避免不必要的带宽消耗和请求延迟。下面从ETag的生成依据、验证流程以及生产环境配置三个方面进行详细分析。
Apache生成ETag的底层机制
Apache生成ETag主要依赖文件元数据，而不是文件内容的哈希值。其核心指令是FileETag，该指令可以出现在服务器级别、虚拟主机、<Directory>、<Files>以及.htaccess文件中。默认情况下，Apache会使用三个组件来构造ETag：文件的inode号、最后修改时间（MTime）以及文件大小（Size）。这三个值组合在一起后，Apache会对它们进行格式化，最终生成形如"1a2b3c-5d6e-7f8"的ETag字符串。
使用inode号意味着ETag与文件系统位置强相关，即使文件内容完全相同，只要它被移动到另一个分区或复制到其他服务器，生成的ETag就可能发生变化。MTime是文件最后修改时间，通常以秒为精度；Size则是文件字节数。当这三个属性中任意一个发生变化时，ETag都会随之变化，因此Apache默认生成的ETag属于强验证器，能够精确反映文件是否发生改变。
管理员还可以通过FileETag指令调整组件组合。常见的配置包括：FileETag MTime Size表示只使用最后修改时间和文件大小，FileETag INode MTime Size等价于默认值，FileETag All表示使用所有可用组件，而FileETag None则用来完全禁用ETag的生成。下面的示例展示了在虚拟主机中配置ETag组件为MTime和Size的方式：
<VirtualHost *:80>
ServerName ipipp.com
DocumentRoot /var/www/html
<Directory "/var/www/html">
FileETag MTime Size
</Directory>
</VirtualHost>
需要注意的是，当Apache启用了gzip压缩时，如果响应经过动态压缩处理，生成的ETag可能会带有W/前缀，表示这是一个弱验证器。弱验证器只要求资源在语义上等价，不要求每个字节完全一致，因此它更适合经过内容重写、格式转换或代理压缩的场景。
ETag的验证流程与304响应
当浏览器第一次请求某个静态资源时，服务器会在响应头中返回ETag。浏览器会将这个ETag与资源一起缓存起来。当用户再次访问该资源时，浏览器会发送If-None-Match请求头，并把之前保存的ETag值附在后面。服务器收到请求后，会重新计算当前资源的ETag，并与请求中的值进行比较。如果两者一致，说明资源没有变化，服务器返回304 Not Modified状态码，并且不发送响应体；如果两者不一致，则返回200 OK以及新的完整资源和新ETag。
使用curl命令可以非常直观地观察这个过程。首先执行curl -I https://ipipp.com/js/app.js获取响应头，记录下ETag值；然后再次执行下面的命令模拟条件请求：
# 首次请求，记录 ETag curl -I https://ipipp.com/js/app.js # 使用上次获得的 ETag 值发起验证请求 curl -I -H 'If-None-Match: "5f8b3c-1c2d"' https://ipipp.com/js/app.js
第二次请求的响应通常会包含HTTP/1.1 304 Not Modified，同时不会返回Content-Length或者内容体。这表明缓存验证成功，客户端可以继续使用本地缓存。如果修改了服务器上的文件，Apache重新计算出的ETag会发生变化，第二次请求就会得到200 OK并重新下载完整内容。
还需要注意ETag与If-Modified-Since的优先级关系。当请求同时携带If-None-Match和If-Modified-Since时，服务器会优先处理If-None-Match。因为ETag提供的是精确到资源版本的验证，而If-Modified-Since只能精确到秒，在文件修改时间未变但内容发生变化的情况下，后者的判断可能失效。因此，只要ETag校验未通过，服务器就不会再返回304，即使Last-Modified条件满足也是如此。
多服务器环境下的ETag一致性问题
在负载均衡或多台源站同步部署的场景中，Apache默认的ETag生成方式会出现一个典型问题：同一个文件在服务器A和服务器B上的ETag不同。原因在于inode号由文件系统分配，不同机器上的同一个文件几乎不可能拥有相同的inode值。即使使用rsync或同步工具保持了文件内容一致，inode差异仍会导致ETag完全不同。客户端可能第一次从节点A获取ETag，第二次请求被负载均衡转发到节点B，节点B发现ETag不匹配，于是返回200而不是304，缓存命中率大幅下降。
解决这个问题的方法就是在所有源站上统一修改FileETag配置，去掉inode组件，仅保留MTime和Size。以下配置可以放在Apache主配置文件或虚拟主机中：
FileETag MTime Size
这样一来，只要文件的最后修改时间和大小在不同服务器之间保持一致，生成的ETag就会完全相同。需要注意的是，文件同步工具必须保留原始的mtime时间戳，否则时间不同仍然会造成ETag不一致。对于通过NFS共享存储或分布式文件系统提供服务的场景，由于inode可能在各挂载节点间一致，但仍建议统一为MTime Size以降低环境差异带来的不确定性。
ETag的优化与调优建议
对于大部分静态资源来说，启用ETag能够减少不必要的响应体传输，特别是在Cache-Control有效期结束后仍需要验证的场景。但ETag并不是所有内容都适合开启。动态接口返回的JSON或HTML内容是每次请求动态生成的，服务器即使为它们生成ETag也需要额外计算，而且这些内容通常不会被重复利用，因此可以在动态路径上使用FileETag None关闭ETag，仅依赖Cache-Control策略。
如果希望针对特定文件类型禁用ETag，可以使用<FilesMatch>指令进行匹配。下面的示例对PHP文件动态内容关闭ETag：
<FilesMatch "\.(php|html)$">
FileETag None
</FilesMatch>
此外，安全方面也需要考虑inode信息泄露的问题。默认ETag中包含inode号，可能会向攻击者暴露服务器文件系统的内部标识，虽然危害有限，但生产环境更推荐使用MTime Size组合。性能方面，Apache为每个请求计算ETag所消耗的资源很小，因为这只是读取文件的stat信息，而不是计算内容摘要。不过在高并发大流量场景下，省略inode查询可以略微降低文件系统的系统调用开销。
综合来看，合理使用ETag需要结合缓存策略统一设计。对于版本号明确的静态资源，可以通过文件名哈希和长Cache-Control来减少验证请求；对于版本不明确的资源，可以保留ETag作为兜底验证，同时调整FileETag组件以适配多服务器部署。理解ETag如何生成、何时参与验证以及不同配置带来的影响，有助于在实际项目中制定更精准的HTTP缓存方案。
Apache ETagETag生成缓存验证修改时间：2026-08-23 08:06:03