Apache代理缓存如何精细化控制？Expires与Cache-Control指令详解与扩展实践

Apache在处理高并发访问时，缓存机制的合理利用往往决定了整个站点的响应速度。代理缓存控制的核心，就是通过HTTP响应头部告诉浏览器、CDN以及各类中间代理，哪些内容可以缓存、可以缓存多久、缓存失效后如何重新验证。Apache原生提供了mod_expires和mod_headers两个模块，前者负责基于文件类型设置过期时间，后者则可以灵活地增删改任意响应头，两者配合几乎能覆盖所有缓存控制场景。本文将从基础指令入手，逐步扩展到个性化的缓存控制方案。

一、理解缓存相关的HTTP头部与Apache基础指令

谈到Apache的缓存控制，绕不开两个核心响应头：Expires和Cache-Control。Expires是一个HTTP/1.0时代的老头部，它直接指定一个绝对过期时间，例如“2025年1月1日0点0分过期”。这种方式实现简单，但存在一个明显缺陷：如果客户端时钟与服务器时钟不同步，缓存判断就会出现偏差。Cache-Control则是HTTP/1.1引入的增强方案，支持max-age、s-maxage、no-cache、public、private等一系列指令，表达能力强得多。现代浏览器和代理服务器在两者同时存在时，会优先采用Cache-Control。

Apache中设置Expires头部需要启用mod_expires模块。以Debian系系统为例，执行a2enmod expires即可启用，随后在配置文件中通过ExpiresActive打开开关，再用ExpiresByType按MIME类型设置过期时长。一个典型的配置如下：

<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType image/jpeg "access plus 1 month"
    ExpiresByType image/png "access plus 1 month"
    ExpiresByType text/css "access plus 7 days"
    ExpiresByType application/javascript "access plus 7 days"
    ExpiresByType text/html "access plus 0 seconds"
</IfModule>

注意语法中的“access plus”表示以访问时间为起点计算，还可以用“modification plus”以文件最后修改时间为起点。对于内容不常变动的静态资源，建议使用modification基准；对于需要周期性刷新的资源，access基准更合适。另外要特别留意text/html设置为0秒，这意味着HTML页面本身不做长缓存，避免用户在内容更新后看到旧页面。

二、mod_expires与mod_headers的协同配置

mod_expires虽然方便，但它只会输出Expires头部，同时附带一个简单的Cache-Control: max-age。如果你需要更精细的控制，比如针对CDN设置独立的缓存时长（s-maxage），或者添加stale-while-revalidate这类扩展指令，就必须借助mod_headers。先启用模块：a2enmod headers，然后在配置中使用Header set指令。

<IfModule mod_headers.c>
    # 对图片资源设置代理缓存30天，浏览器缓存7天
    <FilesMatch "\.(jpg|jpeg|png|gif|webp)$">
        Header set Cache-Control "public, max-age=604800, s-maxage=2592000, stale-while-revalidate=86400"
    </FilesMatch>

    # 对API响应禁止缓存
    <Location /api/>
        Header set Cache-Control "no-store, must-revalidate"
    </Location>

    # 移除后端传递过来的多余头部
    Header unset X-Powered-By
</IfModule>

上面的配置里有几个关键点值得展开。s-maxage专门服务于共享缓存（如CDN、Squid代理），它的优先级高于max-age，允许你让CDN缓存得更久而浏览器刷新更频繁。stale-while-revalidate是近年来非常实用的扩展指令，它允许缓存在后台异步重新验证的同时，先返回一份过期内容给用户，用户感知零延迟，源站压力也大幅下降。而no-store则是最严格的禁用缓存指令，适用于包含敏感信息的接口响应。

还有一个容易混淆的地方：Header set会覆盖已有的同名头部，Header append则是追加，Header add允许存在多个同名头部。在代理场景下，如果后端（比如Tomcat或PHP-FPM）已经输出了Cache-Control，用set可以强制覆盖，确保策略统一；用append则可能产生重复头部，导致部分代理行为异常。建议在实际部署前用curl -I命令检查最终输出的头部，确认没有冲突。

三、扩展实践：分层缓存策略与条件请求

真实生产环境中，一套好的缓存策略往往是分层的。第一层是浏览器本地缓存，第二层是CDN或反向代理缓存，第三层才是源站。通过mod_headers结合Apache的表达式语法（2.4版本以上），可以根据请求特征动态输出不同的缓存策略。例如对登录用户返回private缓存，对匿名访客返回public缓存：

<IfModule mod_headers.c>
    # 根据Cookie判断用户身份，动态调整缓存可见性
    Header set Cache-Control "public, max-age=3600" env=!IS_LOGIN_USER
    Header set Cache-Control "private, no-cache" env=IS_LOGIN_USER

    SetEnvIfNoCase Cookie "sessionid=" IS_LOGIN_USER
</IfModule>

除了过期策略，条件请求也是缓存体系的重要一环。当缓存过期后，浏览器会携带If-None-Match或If-Modified-Since头部回源验证，Apache会自动根据ETag或Last-Last-Modified判断资源是否变化，未变化则返回304状态码，节省传输带宽。要确保mod_deflate等压缩模块不会破坏ETag：压缩会改变响应体大小，如果ETag中的强弱标记处理不当，可能导致304协商失效。必要时可以通过FileETag MTime Size指令明确ETag的生成依据。

最后需要提醒版本化的重要性。对于JS、CSS这类经常更新的资源，单纯依赖过期时间容易造成“缓存了改不掉”的尴尬局面。推荐的做法是在文件名或查询字符串中附加版本号，例如app.v20250101.js，配合长周期的max-age，既享受缓存加速，又能通过更换URL实现强制刷新。将这套版本化机制与前文提到的分层缓存策略结合，就构成了一套完整且可控的Apache代理缓存控制方案，足以应对绝大多数中大型站点的性能优化需求。

Apache缓存mod_expiresCache-Control修改时间：2026-09-07 06:00:34