Linux下Nginx防XSS需配置含always参数的安全响应头，核心是Content-Security-Policy（禁用'unsafe-inline'/'unsafe-eval'、白名单指定可信资源），辅以X-Content-Type-Options、X-Frame-Options、X-XSS-Protection等头协同防护，并统一在http/server块中配置，禁用Server头。
Linux 上在 Nginx 中配置防跨站脚本（XSS）的响应头，核心不是过滤内容，而是用标准安全头控制浏览器行为——重点是 Content-Security-Policy，所有头都必须加 always 参数，确保 404、500 等错误响应也不漏防。
必须配置的 CSP 策略（现代 XSS 防护主力）
CSP 是当前最有效的服务端 XSS 控制手段，不能只写 default-src 'self' 就完事：
- 禁用高危指令：明确排除
'unsafe-inline'和'unsafe-eval'，否则内联脚本和eval()仍可执行 - 指定可信资源：如需加载 CDN 脚本，必须白名单写出完整域名，例如
script-src 'self' https://cdn.example.com，不能用通配符* - 基础推荐策略（根据业务调整）：
add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.example.com; object-src 'none'; base-uri 'self'; form-action 'self';" always; - 上线前先用
Content-Security-Policy-Report-Only模式观察 3–7 天违规日志，再切为正式策略
配套安全头一个都不能少
这些头协同工作，缺一不可，且全部要加 always：
-
X-Content-Type-Options: nosniff—— 防止浏览器 MIME 嗅探误执行文本文件，避免 .txt 或 .json 被当脚本运行 -
X-Frame-Options: SAMEORIGIN—— 防点击劫持，防止恶意页面用 iframe 嵌套你的登录页诱导用户操作 -
X-XSS-Protection: "1; mode=block"—— 虽已被 Chrome/Firefox/Edge 主流版本弃用，但作为兜底仍可启用；mode=block表示检测到可疑内容直接阻断加载，不尝试修复
配置位置与避坑要点
策略生效依赖正确写法和部署位置：
- 统一在
http或server块中配置，避免多个location重复定义导致覆盖或冲突 - 检查后端（如 PHP、Node.js）是否也输出同名头，如有则必须关闭，只由 Nginx 单一源头管理
- 不要在
if块里写add_header—— 它不会生效；add_header必须放在上下文块顶层 - 禁用 Nginx 默认暴露的
Server头：在http块加server_tokens off;，减少指纹泄露
不推荐但偶有需求的请求层拦截（仅作补充）
这类规则效果有限、易绕过，仅适合快速屏蔽明显扫描器流量，不能替代 CSP：
- 简单过滤查询字符串中的典型载荷：
if ($query_string ~* "( - 限制 User-Agent 中含危险关键词的请求（注意：部分合法客户端也可能触发误拦）
- 禁止路径穿越：
if ($request_uri ~ "\.\./|\.\.$|//") { return 400; } - ⚠️ 所有
if应放在proxy_pass之前，且仅用于轻量匹配；复杂逻辑请交给 WAF（如 ModSecurity）或后端处理
