X-Frame-Options配置无效的主因是响应未实际携带该头，常见于Nginx遗漏always参数、CDN/WAF过滤、框架覆盖、大小写或拼写错误、meta标签无效及CSP frame-ancestors优先级更高。
为什么加了X-Frame-Options头页面还是能被嵌套
加了头 ≠ 生效。最常见的情况是：响应根本没带上这个头，或者被中间层抹掉了。
用浏览器 DevTools 打开 Network → Headers，找目标请求的响应里有没有 X-Frame-Options 字段。没有？说明配置没生效或被覆盖。
-
add_header在 Nginx 里必须带always参数，否则304、4xx、5xx响应不会发这个头 - CDN（比如 Cloudflare）、WAF、反向代理默认可能清除自定义响应头，得单独配白名单或开启透传
- 后端框架（如 Express、Django）如果也设置了同名头，会覆盖 Nginx 的设置——以第一个发出的为准
- 拼写必须严格：
X-Frame-Options（大小写敏感、连字符不能少），X-Frame-Option或x-frame-options都无效
Nginx 中add_header X-Frame-Options怎么写才不踩坑
别只往 location 块里塞，容易漏路径；也别省略 always —— 这是线上环境失效的主因之一。
- 推荐放在
server块顶层，确保所有响应都覆盖：add_header X-Frame-Options "DENY" always; -
DENY最安全，适合登录页、支付页等敏感路径；SAMEORIGIN允许同协议+同域名+同端口嵌套，但https://a.com嵌http://a.com仍会被拒 -
ALLOW-FROM已被 Chrome/Firefox 彻底弃用，不要用；现代替代方案是Content-Security-Policy的frame-ancestors - 如果同时配置了
Content-Security-Policy: frame-ancestors，浏览器会直接忽略X-Frame-Options—— 这是标准行为，不是 bug
Content-Security-Policy: frame-ancestors比X-Frame-Options强在哪
不是“更强”，而是标准演进后的事实优先级：Chrome 97+、Firefox 95+ 明确优先采用 frame-ancestors，X-Frame-Options 仅作兼容兜底。
立即学习“前端免费学习笔记（深入）”；
-
frame-ancestors 'none'等价于X-Frame-Options: DENY；frame-ancestors 'self'等价于SAMEORIGIN，但注意引号不能省：'self'有效，self无效 - 支持多源：
frame-ancestors 'self' https://admin.example.com;（空格分隔，末尾分号不能漏） - 语法容错极低：多一个空格、少一个单引号、漏掉分号，整条指令就失效
- IE11 不支持
frame-ancestors，所以生产环境建议两者共存，但以 CSP 为主
为什么<meta http-equiv="X-Frame-Options">完全没用
这不是你写错了，是浏览器根本不认。所有主流浏览器（Chrome 120+、Firefox 125+、Safari 17+）已彻底废弃该写法。
-
<meta http-equiv="X-Frame-Options" content="DENY">在 HTML 里写一百遍，DevTools Network 里也看不到响应头，防护等于零 - JS 检测（比如
window.top !== window.self）可被 iframe 的sandbox属性绕过，且无法阻止初始渲染，纯属事后补救 - 唯一可靠方式：由 Web 服务器在 HTTP 响应头中发送，且必须通过真实网络请求验证是否真实存在
