HTTP响应头是服务器与浏览器沟通的重要渠道，Cache-Control、Access-Control-Allow-Origin、X-Frame-Options这些头部信息直接决定了缓存行为、跨域权限和页面安全策略。在Apache中，要对这些响应头做精细化控制，mod_headers模块是首选工具。它提供的指令集足够灵活，既能全局设置，也能按目录、按条件动态修改。本文将系统讲解这个模块的配置方法与实战技巧。
mod_headers基础与模块加载
mod_headers是Apache自带的标配模块，绝大多数发行版在编译或打包时都会包含它。不过模块存在不代表配置文件里启用了它，先确认httpd.conf或apache2.conf中是否加载。不同发行版的写法略有差异，Debian系通常在mods-enabled目录下软链接了headers.load，而CentOS系则直接在主配置中有一行LoadModule指令。
# Debian/Ubuntu 检查模块是否启用 ls /etc/apache2/mods-enabled/ | grep headers # 启用模块 a2enmod headers systemctl restart apache2 # CentOS/RHEL 检查 grep headers /etc/httpd/modules.mod # 或直接确认主配置中存在 LoadModule headers_module modules/mod_headers.so
加载完成后，配置指令可以放在四个作用域中：全局配置、VirtualHost虚拟主机、Directory目录段以及.htaccess文件。如果要在.htaccess中使用，必须保证对应的Directory配置里AllowOverride包含FileInfo选项，否则指令会被直接忽略，这也是很多人配置不生效的首要原因。
核心指令详解：set、add、append、unset
mod_headers提供了一组语义明确的操作指令，理解它们的差异是正确配置的前提。Header set会设置一个头部，如果该头部已存在则直接替换；Header add则不管原来有没有，一律追加一条，这可能导致同名头部出现多份；Header append是把新值合并到已有头部的值后面，常用于拼接多个值；Header unset用于删除指定头部；Header echo则是把请求头原样回显到响应中，多用于调试。
举个典型例子，设置浏览器缓存策略和安全头时，推荐统一使用set，确保结果可控：
<IfModule mod_headers.c>
# 静态资源缓存策略
<FilesMatch "\.(css|js|png|jpg|webp|woff2)$">
Header set Cache-Control "public, max-age=31536000, immutable"
</FilesMatch>
# 安全相关响应头
Header set X-Content-Type-Options "nosniff"
Header set X-Frame-Options "SAMEORIGIN"
Header set Referrer-Policy "strict-origin-when-cross-origin"
Header always set X-XSS-Protection "1; mode=block"
# 删除暴露服务器信息的头部
Header unset X-Powered-By
</IfModule>注意配置中的双引号包裹整个值，如果值本身包含分号等特殊字符，整段必须用引号包住，否则Apache解析时会报语法错误。另外，Header set默认只作用于正常响应（2xx状态码），错误页面上的响应头需要配合条件表达式处理。
Always前缀与onsuccess条件的区别
很多教程会让你在指令前加always，比如Header always set X-Robots-Tag "noindex"，但它的实际含义常被误解。Apache内部把响应头表分成两个：onsuccess表只包含成功响应的头部，always表则对所有响应（包括4xx、5xx错误页）都生效。加了always前缀的指令操作的是always表。
这在反向代理场景下尤其重要。当后端应用返回错误状态码时，如果你希望错误响应也带上CORS头或安全头，必须使用always前缀，否则浏览器在跨域请求失败时会因为缺少Access-Control-Allow-Origin而无法读取错误信息：
# 反向代理场景，错误响应也需要CORS头
<IfModule mod_headers.c>
# 成功和失败响应都要带上
Header always set Access-Control-Allow-Origin "https://www.ipipp.com"
Header always set Access-Control-Allow-Methods "GET, POST, OPTIONS"
Header always set Access-Control-Allow-Headers "Content-Type, Authorization"
# 处理预检请求
RewriteEngine On
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule ^(.*)$ $1 [R=204,L]
</IfModule>需要提醒的是，如果同一个头部既在onsuccess表又被always设置，可能出现重复头部。排查时用curl -I逐项检查，发现同名头部出现两次时，检查是否同时存在带always和不带always的同名指令，保留一处即可。
条件配置与表达式灵活控制
mod_headers支持条件表达式，可以根据请求特征决定是否设置头部。Header set X "value" "condition"的第三个参数是条件，只有条件成立时指令才执行。也可以用Header unset X "condition"做条件删除。条件支持正则匹配环境变量，功能相当强大。
# 仅对特定路径禁用索引
<Location "/internal/">
Header set X-Robots-Tag "noindex, nofollow"
</Location>
# 根据User-Agent条件设置
BrowserMatch "MSIE" is_old_browser
Header set X-Compatible-Hint "legacy" env=is_old_browser
# Apache 2.4 表达式语法，按来源IP区分
<If "%{REMOTE_ADDR} =~ /^192\.168\./">
Header set X-Debug-Info "internal"
</If>
# 仅在响应头已存在某字段时追加内容
Header append Cache-Control "no-transform" "expr=%{CONTENT_TYPE} =~ m#text/html#"Apache 2.4引入的expr=表达式语法比老式的env匹配更直观，可以直接引用%{REQUEST_URI}、%{HTTP_USER_AGENT}等变量。条件配置的价值在于避免一刀切，比如内网调试头只暴露给办公网段，外部访客完全感知不到，既方便排障又不泄露内部信息。
常见踩坑问题与排查思路
第一个高频问题是配置写了但响应头没出现。排查顺序建议是：确认模块已加载，用apachectl -M | grep headers验证；检查指令所在作用域，特别是.htaccess是否被AllowOverride限制；确认VirtualHost没有覆盖掉全局配置，因为更具体的作用域里unset指令会屏蔽外层设置。第二个问题是头部重复，根源几乎都是set与add混用，或者always与onsuccess两个表同时写入。统一改用set并清理冗余指令即可解决。
第三个问题涉及执行顺序。mod_headers作用于输出过滤器阶段，如果请求经过反向代理转发，后端已经发送的头部可能会与本地设置产生叠加。此时可以在代理配置中显式忽略后端的某些头部，再由前端统一补齐。另外，某些头部如Strict-Transport-Sinux类似的预加载要求整站HTTPS，若页面还残留HTTP资源，浏览器会拒绝生效，这属于配置正确但环境不满足的情况，需要从证书和跳转层面解决。
# 验证响应头的实用命令 curl -I https://www.ipipp.com/static/app.js # 只看指定的头部 curl -sI https://www.ipipp.com/ | grep -i "cache-control" # 模拟跨域预检请求 curl -X OPTIONS -I \ -H "Origin: https://www.ipipp.com" \ -H "Access-Control-Request-Method: POST" \ https://api.ipipp.com/data
改完配置后记得用apachectl configtest做语法检查再重启服务，避免一条语法错误导致整个站点无法启动。对于CDN架构的站点，还要注意源站的响应头可能被CDN层改写，最终以浏览器开发者工具Network面板看到的为准。掌握这些细节后，无论是做缓存优化、安全加固还是跨域联调，mod_headers都能应付自如。
mod_headersApache响应头Header set配置修改时间：2026-09-07 18:06:48