在搭建Apache反向代理缓存时，Age头是一个容易被忽略但极其关键的响应头。它用于告知客户端当前响应从源站生成或从缓存节点缓存开始，已经过去了多长时间。Apache通过mod_cache模块自动管理Age头的写入与累加，其计算方式直接关系到Cache-Control新鲜度判断、CDN边缘节点协同以及终端用户看到的缓存命中状态。如果不清楚Apache内部如何推导Age，就可能在排查缓存不更新、旧内容残留等问题时走弯路。
Age头的基础语义与Apache写入时机
根据HTTP规范，Age头是一个非负整数，单位为秒，表示响应在缓存系统中存活的估计时间。当Apache作为反向代理且启用了mod_cache时，如果自身缓存中已有对应资源，它会在返回给客户端时附上Age头；若缓存未命中而回源，Apache会检查源站响应里是否带有Age头，并基于此决定如何向后传递。
Apache的缓存子系统在将响应存入缓存时会记录一个本地时间戳，我们称之为缓存写入时刻。当后续请求命中该缓存条目，Apache用当前时间减去写入时刻得到缓存内停留秒数，再加上源站响应中的原始Age（如果存在），最终写入响应的Age头。这意味着Age不是简单的“缓存存了多久”，而是“源站内容年龄加本地代理停留年龄”的累计值。
需要注意，若源站本身也是一层缓存（例如源站前面还有CDN），源站返回的Age可能已经很大。Apache不会重置它，而是继续累加，从而保证整条链路上内容真实年龄的可观测性。这一设计避免了多层缓存互相掩盖内容陈旧度的问题，但也要求运维人员在看Age时要减去自己这一层的代理停留时间，才能知道源站内容的真实生成时间。
mod_cache中Age计算的核心逻辑与配置指令
Apache通过CacheQuickHandler、CacheHeader等指令控制缓存行为，其中CacheHeader设为on时会确保Age等缓存相关头被正确处理和输出。在源码层面，mod_cache在cache_save_filter和cache_filter两个阶段分别处理写入与读取：写入阶段调用apr_time_now获取当前时间并存入笔记结构；读取阶段计算时间差并拼装Age。
下面是一段简化的伪代码逻辑，展示Apache风格的计算过程。注意其中对源站Age的解析与本地停留时间的相加。
// 伪代码：Apache mod_cache 中 Age 计算示意
apr_time_t now = apr_time_now();
apr_time_t cached_at = cache_entry->create_time; // 缓存写入时刻
int local_age = (int)((now - cached_at) / APR_TIME_SEC);
// 从上游响应获取原始 Age
const char *origin_age_str = apr_table_get(headers_out, "Age");
int origin_age = 0;
if (origin_age_str != NULL) {
origin_age = atoi(origin_age_str);
}
int total_age = local_age + origin_age;
// 将 total_age 写入最终响应头
apr_table_set(headers_out, "Age", apr_psprintf(ptemp, "%d", total_age));
在实际配置中，如果使用了CacheIgnoreHeaders排除了Age，那么Apache不会透传源站Age，也不会自行计算写入，这会导致下游无法感知内容年龄。另一种情况是后端用mod_headers强行覆盖了Age，这会让Apache的累加逻辑失效。因此保持默认的Age处理，或在明确需求下用RequestHeader/BrowserMatch精细控制，才是稳妥做法。
此外，CacheMaxExpire和CacheMinExpire决定缓存条目本身存活时长，它们与Age是两套概念：前者是“最多存多久”，后者是“已经存了多久”。当Age超过Max-Age（来自Cache-Control）时，Apache会认为缓存陈旧并触发回源验证，此时若源站返回304，Apache会刷新缓存写入时刻，Age重新从接近0的本地停留开始累计。
时钟偏差与多层代理下的Age误差分析
在分布式系统中，各节点系统时钟不可能完全一致。Apache计算本地停留时间依赖自身时钟，如果代理服务器时钟比源站快或慢，虽然Age计算只用本机时间差（写入与读取都在同一台机器），不会引入跨机误差，但源站Age若由另一台时钟异常的机器生成，则整体Age会包含那个偏差。因此保证NTP时间同步，是让Age可信的前提。
当存在多级Apache代理，例如边缘Apache A缓存中间Apache B，B又缓存源站，此时A收到的响应里Age已经是B的本地停留加源站Age。A再次累加自己的停留时间，最终客户端看到的Age = A停留 + B停留 + 源站Age。这种嵌套累加符合规范，但也意味着任一层重启或缓存清空都会让该层停留归零，而上层Age不会回退，从而呈现出非单调的年龄跳变。
我们可以通过一个对比表理解不同场景下的Age构成：
| 场景 | 源站返回Age | 代理本地停留 | 最终响应Age |
|---|---|---|---|
| 单层代理首次回源 | 0 | 0 | 0 |
| 单层代理命中缓存 | 0 | 120 | 120 |
| 多层代理均命中 | 30 | 各层共200 | 230 |
| 源站本身是CDN节点 | 600 | 10 | 610 |
从运维角度看，若发现Age异常偏大，应先确认是否源站前面还有缓存层，再检查本机缓存命中率。利用Apache的日志记录%{Age}o可以观测每个响应输出的Age值，结合缓存命中日志，就能快速定位是本地缓存过期频繁还是上游内容本身就旧。
总结来说，Apache代理缓存的Age头计算是一个本地停留加源站年龄的线性累加模型。掌握它在模块层面的写入时机、配置指令的影响以及多层架构下的传递规律，能够帮助我们精准判断内容新鲜度，构建可预测的缓存体系。