加always参数很关键，因默认add_header仅对2xx/3xx响应生效，加always后才确保4xx/5xx错误响应也发送x-content-type-options: nosniff头，防止攻击者利用错误页面绕过防护。
直接在 Nginx 配置中添加 add_header X-Content-Type-Options "nosniff" always; 即可强制开启，但必须注意作用域和覆盖规则，否则容易失效。
为什么加 always 参数很关键
默认情况下，add_header 只对 2xx 和 3xx 响应生效；遇到 404、500 等错误响应时，该头就不会发送。攻击者可能利用错误页面绕过防护。
加上 always 参数后，无论状态码是多少，这个头都会稳定输出，确保全链路防护不中断。
配置位置决定是否真正生效
这个指令不是继承式配置，写在 http 或 server 块里，不会自动带入所有 location 块。常见失效原因就是只在顶层写了，但在某个 location 里又定义了其他 add_header，结果把前面的覆盖掉了。
- 推荐统一写在
http块最外层，并带 always - 如果用在
server或location中，需确保该块内所有子路径都显式包含该指令 - 多个
add_header指令在同一作用域下，后写的会完全替换前面的——不能靠叠加实现多头
验证是否真的生效
别依赖浏览器开发者工具看 Network 面板，它可能受缓存或中间代理干扰。最可靠方式是用命令行直连 Nginx：
curl -I http://your-domain.com/any-path- 检查返回头中是否有 X-Content-Type-Options: nosniff
- 特别测试一个 404 路径，确认错误响应里也存在该头（验证 always 是否起效）
配合正确 MIME 类型才真正安全
nosniff 的作用是“不让浏览器乱猜”，但它无法修正服务器本身发错的 Content-Type。比如后端返回一张图片却标成 text/plain，启用 nosniff 后浏览器会直接拒绝加载。
- 静态资源：确保
types模块启用，且文件扩展名与类型映射准确 - 动态接口：后端代码必须显式设置正确的
Content-Type，例如 JSON 接口返回application/json - 上传文件处理：尤其要注意用户上传的文件，服务端响应时务必按实际内容设类型，否则 nosniff 会阻断渲染
