代理缓存是提升Web服务响应速度的常用手段，但很多运维人员在部署Apache反向代理时只关注命中率，忽略了缓存数据本身的存放安全。默认情况下，mod_cache将上游服务器返回的响应体完整写入磁盘文件，包括Cookie、会话标识、个人数据等敏感内容，且全部以明文形式存在。这篇文章围绕Apache代理缓存的加密与安全存储展开，从原理、方案到具体配置逐一说清楚。
一、先弄清楚mod_cache的存储机制与风险点
Apache的缓存体系由两层组成：mod_cache负责缓存决策（判断哪些响应可以缓存、缓存多久），而具体的存储由存储提供模块完成，常用的有mod_cache_disk（磁盘存储）和mod_cache_socache（共享内存存储）。在反向代理场景中，通常配合mod_proxy一起工作，流程是：客户端请求到达Apache，Apache先查缓存，命中则直接返回，未命中则通过代理转发给后端，拿到响应后按规则决定是否写入缓存。
风险主要出在磁盘存储上。mod_cache_disk会把响应体原样写到CacheRoot指定的目录下，文件按URL哈希分目录存放。这意味着如果响应里含有Set-Cookie头、用户个性化数据或API返回的敏感字段，这些内容都会明文躺在磁盘上。常见的暴露途径有三个：服务器被入侵后攻击者直接读取缓存目录、运维打包备份时把缓存目录一并带走、缓存目录权限设置过宽导致同机其他用户可读。
还有一个容易被忽视的点：即使传输层用了HTTPS，缓存里存的仍然是解密后的明文响应。mod_ssl保护的是客户端到Apache之间的链路，与缓存落盘内容是否加密没有关系。很多人误以为上了HTTPS缓存就是安全的，这是一个需要纠正的概念。
二、方案一：用磁盘加密技术保护缓存目录
最直接可靠的思路是让CacheRoot指向一个加密文件系统或加密块设备上。Linux下可以用LUKS创建加密分区，也可以用eCryptfs做目录级加密。这样即使磁盘或备份文件泄露，没有密钥也无法读取缓存内容。
# 创建一个100MB的回环加密卷用于缓存 dd if=/dev/zero of=/etc/httpd/cachestore.img bs=1M count=100 # 关联回环设备 losetup /dev/loop0 /etc/httpd/cachestore.img # 用LUKS格式化并打开 cryptsetup luksFormat /dev/loop0 cryptsetup luksOpen /dev/loop0 apachecache # 格式化为ext4并挂载 mkfs.ext4 /dev/mapper/apachecache mkdir -p /var/cache/httpd-enc mount /dev/mapper/apachecache /var/cache/httpd-enc chown apache:apache /var/cache/httpd-enc chmod 700 /var/cache/httpd-enc
挂载完成后，在Apache配置中将缓存根目录指到加密挂载点即可：
LoadModule cache_module modules/mod_cache.so
LoadModule cache_disk_module modules/mod_cache_disk.so
<IfModule mod_cache.c>
CacheEnable disk /
CacheRoot "/var/cache/httpd-enc"
CacheDirLevels 2
CacheDirLength 1
CacheMaxFileSize 500000
CacheIgnoreNoLastMod On
</IfModule>
这个方案的优点是对应用完全透明，不需要改动任何业务代码，加密强度取决于LUKS的密钥管理。缺点是密钥管理引入了新的运维复杂度：服务器重启后需要输入密钥或配置keyfile自动解锁。如果用keyfile，要确保keyfile本身存放在受保护的位置且不与加密卷放在同一台备份介质中，否则加密形同虚设。对于高并发站点还要评估加解密带来的IO性能损耗，建议先在测试环境压测对比。
三、方案二：从源头控制，对敏感内容禁用缓存
换一个角度想，与其加密保护缓存，不如让敏感内容根本不进缓存。Apache提供了多种手段在请求和响应两个阶段干预缓存决策。对于包含会话信息的路径，最稳妥的做法是显式禁用缓存：
# 登录、个人中心等路径完全不缓存
<Location "/login">
CacheDisable on
</Location>
<Location "/user/profile">
CacheDisable on
ProxyPass http://backend.local/profile
ProxyPassReverse http://backend.local/profile
</Location>
# 全局：绝不缓存带Cookie的响应
<IfModule mod_cache.c>
CacheIgnoreCookies Off
</IfModule>
需要注意一个反直觉的默认行为：mod_cache默认是可以缓存带Set-Cookie头的响应的，只是会在返回给客户端前去掉该头。这个设计在多人共用缓存的场景下容易造成会话串用。除了服务端控制，也可以依赖后端正确返回Cache-Control: private或no-store，并在Apache侧配合CacheStorePrivate Off、CacheStoreNoStore Off（均为默认值）确保这些指令被尊重。如果后端开发不守规范，就必须在Apache侧用
另一个实用技巧是利用CacheIgnoreHeaders精细控制哪些头不参与缓存一致性判断，以及用CacheKeyModifyURL配合Vary头处理按用户区分的响应。原则只有一条：凡是响应内容因请求者身份而异的资源，一律不该进公共缓存。
四、权限加固与日常运维要点
无论选择哪种加密方案，基础的权限加固都不能省。首先要确保缓存目录的属主是Apache运行用户，权限收紧到700；其次要检查htcacheclean清理工具的运行身份，不要用root跑完留下root属主的缓存文件。下面是一套完整的检查清单：
# 检查缓存目录权限 ls -ld /var/cache/httpd-enc # 只允许apache用户读写 chown -R apache:apache /var/cache/httpd-enc chmod -R 700 /var/cache/httpd-enc # 定期清理过期缓存，以apache身份运行 htcacheclean -p /var/cache/httpd-enc -l 500M -t -v # 将缓存目录排除出系统备份 # 在rsync或tar命令中排除 tar --exclude=/var/cache/httpd-enc -czf backup.tar.gz /etc/httpd
日志审计方面，建议开启CacheDetailHeader on并在响应头中观察缓存命中情况，配合LogLevel cache:trace5临时排查缓存行为异常。如果发现本不该缓存的内容出现在缓存目录中，优先检查后端是否漏发了Cache-Control头。最后提一句灾备场景：加密卷的解锁密钥要有离线备份和轮换机制，密钥泄露后应立即更换LUKS口令并清空重建整个缓存目录，因为旧缓存内容已不可信。
总结一下做法的组合：公共静态资源正常走缓存提升性能，敏感路径用CacheDisable硬性隔离，缓存目录落在加密文件系统上，权限收严并排除出备份。四层措施叠加，代理缓存的安全短板基本就补齐了。
Apache代理缓存mod_cache加密缓存安全存储修改时间：2026-09-05 06:10:39