map 指令不能单独设置 X-Frame-Options 响应头，因其仅在请求解析阶段做变量映射，不触发响应头写入；必须配合 add_header 指令在 server 或 location 块中显式输出，且需加 always 参数覆盖错误响应。
Map 指令本身不直接支持设置 X-Frame-Options 响应头，因为 Nginx 的 map 模块仅用于**变量映射与条件赋值**，不能触发响应头写入。它常被误认为可“动态加头”，但实际必须配合 add_header 或 proxy_hide_header 等指令协同使用，且受 Nginx 响应头处理阶段限制。
为什么 map 不能单独实现 X-Frame-Options 动态控制
Nginx 中 map 只在请求解析阶段运行，生成一个自定义变量（如 $frame_policy），但该变量不会自动变成响应头。必须显式调用 add_header 才能输出 HTTP 头——而 add_header 在 location / server 级生效，且**不支持在 if 块或 map 内部直接调用**。
更关键的是：add_header 不继承父块，且多个同名头会全部发出（浏览器只取最后一个），容易引发策略覆盖或冲突。
真正可行的动态方案：map + add_header 组合
以下是在 Nginx 中基于请求特征（如路径、域名、User-Agent）动态设定 X-Frame-Options 的标准写法：
- 在
http块中定义映射逻辑，将请求特征转为策略值 - 在
location或server块中用add_header引用该变量 - 注意：需禁用默认静态头，避免重复或冲突
示例配置：
# http 块内定义动态策略
map $host $xfo_policy {
default "SAMEORIGIN";
~^admin\..+ "DENY";
~^partner\..+ "ALLOW-FROM https://trusted.example.com";
}
<p>map $request_uri $xfo_policy_by_path {
~^/api/.<em> "DENY";
~^/public/.</em> "SAMEORIGIN";
default $xfo_policy; # 回退到 host 级策略
}</p><h1>server 块中启用（需确保无其他 add_header X-Frame-Options）</h1><p>server {
listen 443 ssl;
server_name example.com;</p><pre class="brush:php;toolbar:false;"># 清除可能存在的旧头（尤其反向代理场景）
proxy_hide_header X-Frame-Options;
location / {
add_header X-Frame-Options $xfo_policy_by_path always;
# ... 其他配置
}}
必须避开的典型陷阱
- 不要在 if 块里写 add_header：Nginx 官方明确不推荐，行为不可靠，可能丢失头
-
always 参数很重要：默认情况下
add_header仅对 2xx/3xx 响应生效；加always才能覆盖 4xx/5xx 错误页，防止错误响应暴露在 iframe 中 -
ALLOW-FROM 兼容性差：Chrome、Firefox 已弃用，仅 IE/Edge Legacy 支持；生产环境建议改用 CSP 的
frame-ancestors -
缓存加固 ≠ X-Frame-Options 本身缓存：X-Frame-Options 是响应头，不参与内容缓存；若想防止含该头的响应被代理缓存，需额外配
Cache-Control: no-store
与缓存加固的关联要点
所谓“缓存加固”，在此语境下实指：防止攻击者利用中间代理缓存的、未设 X-Frame-Options 的旧响应，绕过防护。因此需确保：
- 所有响应（含错误页、重定向、API 接口）都携带一致且有效的
X-Frame-Options - 禁止 CDN 或反向代理缓存无该头的响应 → 配置
Cache-Control: private, no-store - 若使用了
proxy_cache，应在 cache key 中包含头策略变量，避免混存不同策略响应
