Nginx配置的Content-Security-Policy未生效问题求助

从你遇到的情况来看，浏览器拿到的是一套严格到离谱的默认CSP规则，而不是你费劲配置的自定义规则，再加上代理直接访问WordPress完全正常，那问题肯定出在Nginx这边，给你几个排查方向：

1. 先检查你的CSP配置语法有没有问题 #

看你贴的CSP配置，好多地方都截断了：比如https:/$、https://ssl.google-analytics.c$，这明显是配置没写完啊！Nginx遇到这种语法错误，直接就忽略这个add_header指令了，自然不会用你的自定义规则。另外你还重复写了好几次'unsafe-inline' 'unsafe-eval'，虽然语法上不算错，但冗余的内容也可能导致解析异常。

给你个修正后的示例参考，把截断的URL补全，去掉重复的指令：

add_header Content-Security-Policy "default-src 'self' https://example.com; 
script-src 'unsafe-inline' 'unsafe-eval' 'self' https://example.com https://*.wp.com https://ssl.google-analytics.com; 
img-src 'self' https://example.com https://ssl.google-analytics.com; 
style-src 'unsafe-inline' 'self' https://example.com https://fonts.googleapis.com; 
font-src 'self' https://example.com https://blog.hellodadiam.world; 
frame-src 'self' https://example.com https://assets.zendesk.com; 
object-src 'self' https://example.com;" always;

记住，unsafe-inline和unsafe-eval每个指令里写一次就行，别重复堆。

2. 排查Nginx配置的作用域是不是被覆盖了 #

Nginx的add_header是继承生效的，但如果子块（比如处理PHP请求的location ~ \.php$）里自己定义了add_header，就会完全覆盖父块（server或http）的配置。比如你在server块加了自定义CSP，但某个location块里有默认的CSP头，那你的规则就被顶掉了。

你要做的：

• 检查所有相关的配置文件（包括nginx.conf、站点配置、引入的子配置），搜Content-Security-Policy，看有没有其他地方定义了默认规则；
• 如果某个location块需要用你的CSP，要么不在这个块里单独写add_header（继承父块的），要么把你的自定义CSP也加到这个块里。

3. 确认Nginx加载的是最新配置 #

有时候改完配置忘了重启或重载Nginx，旧配置还在跑。先执行这个命令检查语法：

nginx -t

如果提示语法没问题，再重载配置：

nginx -s reload

要是nginx -t报错，那就是你CSP配置的锅，先回去修语法。

4. 为啥Firefox没事？ #

Firefox对CSP的容错性比其他浏览器高，比如遇到解析错误的CSP头，它可能会忽略，继续用之前缓存的有效规则；或者收到冲突的CSP时，会选更宽松的那个。但这只是临时现象，等你把配置修好，所有浏览器都会正常用你的自定义CSP。

5. 排除安全模块的干扰 #

如果你装了ModSecurity这类Nginx安全模块，有些模块会自动加默认的CSP规则，直接覆盖你的配置。可以先临时禁用这类模块，测试下CSP是不是正常生效，要是好了，再去调整模块的规则就行。

内容的提问来源于stack exchange，提问作者SimYouLater