Apache作为使用广泛的开源Web服务器，其代理缓存能力由mod_cache及一系列配套模块提供。缓存确实能降低源站压力、缩短响应时间，但一旦缓存了不该缓存的内容，比如带用户会话信息的页面、内部接口响应，就可能引发数据串号、信息泄露等严重问题。对Apache代理缓存做一次合规性审计，本质上就是回答三个问题：什么内容被缓存了、缓存了多久、被谁取走。本文将从审计目标、配置核查、缓存策略验证和日志留痕四个层面展开。
一、审计前必须搞清楚的缓存决策机制
Apache的缓存决策并不只看配置文件，而是配置指令与HTTP响应头共同作用的结果。mod_cache在收到源站响应后，会综合判断Cache-Control、Expires、Last-Modified、ETag等头部，再结合httpd.conf中的缓存策略决定是否存储该响应。审计人员如果只检查配置文件而忽略响应头，结论往往不准确。
举个例子，即使配置了CacheEnable disk /，如果源站返回了Cache-Control: private或Cache-Control: no-store，Apache默认不会缓存该响应。反过来，如果配置中使用了CacheStorePrivate On强制缓存私有内容，这就是一个明显的合规风险点，需要重点核查是否有业务理由支撑。
此外，缓存键的生成也直接影响合规性。默认情况下缓存键包含主机名、端口、路径和查询字符串。如果配置不当导致不同用户看到同一份缓存内容，而该内容本身因Vary头或Cookie而异，就会产生数据串号。理解这套机制，是后续所有审计工作的基础。
二、核心配置核查清单与典型违规场景
审计的第一步是收集完整的缓存相关配置。可以在服务器上执行apachectl -M查看已加载模块，重点关注mod_cache、mod_cache_disk、mod_cache_socache、mod_socache_shmcb等模块是否存在。然后逐项核查以下配置：
# 查看已加载的缓存相关模块 apachectl -M | grep cache # 导出当前生效的完整配置 apachectl -D DUMP_INCLUDES apachectl -t -D DUMP_RUN_CFG
典型的合规基线配置应当类似下面这样：
LoadModule cache_module modules/mod_cache.so
LoadModule cache_disk_module modules/mod_cache_disk.so
<IfModule mod_cache.c>
CacheEnable disk /
# 明确排除敏感路径，这是合规审计的核心检查点
CacheDisable /api/private
CacheDisable /admin
CacheDisable /user/profile
# 禁止缓存私有响应和未指定过期时间的响应
CacheStorePrivate Off
CacheStoreNoStore Off
CacheIgnoreNoLastMod On
# 限制缓存对象的最大体积，防止异常大响应占满磁盘
CacheMaxFileSize 10000000
CacheMinFileSize 1
# 缓存时效控制，防止内容长期陈旧
CacheDefaultExpire 3600
CacheMaxExpire 86400
CacheLastModifiedFactor 0.1
# 不忽略URL中的查询字符串，避免不同参数命中同一缓存
CacheIgnoreQueryString Off
</IfModule>
<IfModule mod_cache_disk.c>
CacheRoot "/var/cache/httpd/proxy"
CacheDirLevels 2
CacheDirLength 1
</IfModule>审计时要特别留意以下几类违规场景。第一类是缺少CacheDisable的兜底排除，新上线的后台路径或接口被无意纳入缓存范围。第二类是CacheStorePrivate On配合共享缓存使用，这直接违反了HTTP语义中private指令的意图，属于高危配置。第三类是CacheIgnoreHeaders Set-Cookie这类写法，如果开启了它，包含会话Cookie的响应也可能被缓存并分发给其他用户，是数据泄露的常见根源。
还有一个容易被忽视的点：CacheKeyModifyURL和CacheIgnoreURLSessionIdentifiers的配置。如果业务URL中携带会话标识，而审计发现配置中移除了这些标识参与缓存键计算，必须确认被缓存内容确实与会话无关，否则就会发生A用户缓存被B用户命中的串号事故。
三、响应头与缓存策略的实测验证
配置核查只是静态层面，合规审计还需要动态验证实际行为。最直接的方法是用curl模拟请求，观察响应头中的缓存相关字段以及Apache是否命中缓存。通常可以借助X-Cache这类自定义头，配合Header set和CacheDetailHeader来判断命中情况：
# 第一次请求，观察源站返回的缓存策略头 curl -sI https://www.ipipp.com/news/list | grep -iE "cache-control|expires|etag|vary" # 第二次请求，检查是否命中缓存 curl -sI https://www.ipipp.com/news/list | grep -iE "age|x-cache|hit" # 验证带敏感头的请求是否被缓存 curl -sI -H "Cookie: sessionid=abc123" https://www.ipipp.com/news/list
验证时要重点核对Vary头的处理。如果源站对Vary: Accept-Encoding声明了差异，Apache会为不同编码分别存储缓存对象，这是正常行为。但如果源站返回了Vary: Cookie或Vary: *，说明内容随用户身份变化，此时缓存层是否正确处理直接决定合规与否。Vary: *的响应按规范不应被缓存，若审计发现这类响应出现在磁盘缓存目录中，说明存在配置覆盖或模块版本缺陷。
磁盘缓存的实物抽查也很有效。进入CacheRoot目录，可以使用htcacheclean工具配合-v参数查看缓存使用情况，也可以直接抽查缓存文件内容，确认其中没有出现用户名、手机号、令牌等敏感字段。抽样时建议覆盖动态接口、静态资源、登录后的页面路径三类样本。
# 查看磁盘缓存占用并执行清理 htcacheclean -p /var/cache/httpd/proxy -v -l 512M # 抽查缓存文件中是否含敏感信息 grep -rl "sessionid" /var/cache/httpd/proxy | head -20 grep -rl "Authorization" /var/cache/httpd/proxy | head -20
四、日志留痕、监控与持续合规
一次审计的结束应该是持续监控的开始。建议在Apache中开启缓存相关的详细日志，LogLevel cache:trace5能够输出缓存决策的完整过程，便于事后追溯某条响应为何被缓存或绕过。生产环境长期开启trace级别会产生较大日志量，可以只在审计窗口或测试环境使用，日常运行采用cache:info级别。
同时应建立缓存配置的变更管理机制。任何对CacheEnable、CacheDisable、CacheStorePrivate的修改都应经过评审并留下记录，与等保或行业合规要求中对变更控制的条款对应。可以配合版本管理工具维护httpd.conf片段，审计时直接比对仓库基线与线上配置的差异，快速发现未授权变更。
最后，把审计结论文档化。一份合格的Apache代理缓存审计报告至少应包含：模块加载清单、缓存路径排除表、敏感内容抽查结果、Vary与Cookie处理策略、配置与基线的差异列表以及整改建议。定期执行，例如每季度一次，并在业务新增接口时触发增量审计，才能让缓存层始终保持性能与合规的平衡。
Apache代理缓存mod_cache配置合规性审计修改时间：2026-09-06 19:58:40