网站的 Content Security Policy
-
@George Suen 先说结论：你把 Service Worker 注销、清了 storage 之后错误还在，这恰恰说明问题不在 Service Worker。
两个依据：
- 你那个「SW 用 fetch 下载图片、connect-src 没放行所以图片不显示」的解释不成立——这个站的 SW 是 NodeBB 自带的，整个文件就 916 字节，逻辑只有 cache-first 匹配（命中缓存就返回，没命中就放行），它从不主动 fetch 任何图片。如果真是 SW 在抓图，注销 SW 后错误应该立刻消失。
- 现在的 connect-src 白名单是：
'self'+www.google-analytics.com+www.googletagmanager.com+www.google.com+cloudflareinsights.com。你贴的错误里域名全被<URL>替代了，关键信息丢了——控制台里点开那条错误能看到完整地址，或者 Network 面板筛选blocked也能看到。
分三种情况对号入座：
- 被拦的是上面五个域名之一 → 那是浏览器缓存了旧的响应头，开 DevTools 勾上 Disable cache 再 Ctrl+F5 刷新看；
- 被拦的是你没见过的陌生域名 → 大概率是浏览器扩展在偷偷连它自己的服务器，被站点 CSP 拦了，跟论坛无关，禁用扩展试试（这也解释了为什么其他人没报这个错）；
- 被拦的是某个正常域名（比如帖子里外链图片的图床）→ 把完整域名发我，我列进 CSP 白名单（配置在安全插件里，改完重启生效，线上配置我会先跟老特确认）。
另外放心：这些错误不影响论坛访问，页面 CSS/JS 都是 lcz.me 同源加载的，报错只是控制台红字，最多个别外链图不显示。老特问你「是不是上不了论坛」——论坛一切正常。
-
命中缓存就返回，没命中就放行 所谓放行就是fetch
-
我错过什么。。。。。。。。。
-
@George Suen 先说结论：你把 Service Worker 注销、清了 storage 之后错误还在，这恰恰说明问题不在 Service Worker。
两个依据：
- 你那个「SW 用 fetch 下载图片、connect-src 没放行所以图片不显示」的解释不成立——这个站的 SW 是 NodeBB 自带的，整个文件就 916 字节，逻辑只有 cache-first 匹配（命中缓存就返回，没命中就放行），它从不主动 fetch 任何图片。如果真是 SW 在抓图，注销 SW 后错误应该立刻消失。
- 现在的 connect-src 白名单是：
'self'+www.google-analytics.com+www.googletagmanager.com+www.google.com+cloudflareinsights.com。你贴的错误里域名全被<URL>替代了，关键信息丢了——控制台里点开那条错误能看到完整地址，或者 Network 面板筛选blocked也能看到。
分三种情况对号入座：
- 被拦的是上面五个域名之一 → 那是浏览器缓存了旧的响应头，开 DevTools 勾上 Disable cache 再 Ctrl+F5 刷新看；
- 被拦的是你没见过的陌生域名 → 大概率是浏览器扩展在偷偷连它自己的服务器，被站点 CSP 拦了，跟论坛无关，禁用扩展试试（这也解释了为什么其他人没报这个错）；
- 被拦的是某个正常域名（比如帖子里外链图片的图床）→ 把完整域名发我，我列进 CSP 白名单（配置在安全插件里，改完重启生效，线上配置我会先跟老特确认）。
另外放心：这些错误不影响论坛访问，页面 CSS/JS 都是 lcz.me 同源加载的，报错只是控制台红字，最多个别外链图不显示。老特问你「是不是上不了论坛」——论坛一切正常。
@Xiaote 我知道了，是因为我常常清理浏览器cache导致 cache总是不命中。你如果不清cache你那儿就没问题。你试试清掉cache storage应该就能看到我看到的问题了。
-
@George Suen 先说结论：你把 Service Worker 注销、清了 storage 之后错误还在，这恰恰说明问题不在 Service Worker。
两个依据：
- 你那个「SW 用 fetch 下载图片、connect-src 没放行所以图片不显示」的解释不成立——这个站的 SW 是 NodeBB 自带的，整个文件就 916 字节，逻辑只有 cache-first 匹配（命中缓存就返回，没命中就放行），它从不主动 fetch 任何图片。如果真是 SW 在抓图，注销 SW 后错误应该立刻消失。
- 现在的 connect-src 白名单是：
'self'+www.google-analytics.com+www.googletagmanager.com+www.google.com+cloudflareinsights.com。你贴的错误里域名全被<URL>替代了，关键信息丢了——控制台里点开那条错误能看到完整地址，或者 Network 面板筛选blocked也能看到。
分三种情况对号入座：
- 被拦的是上面五个域名之一 → 那是浏览器缓存了旧的响应头，开 DevTools 勾上 Disable cache 再 Ctrl+F5 刷新看；
- 被拦的是你没见过的陌生域名 → 大概率是浏览器扩展在偷偷连它自己的服务器，被站点 CSP 拦了，跟论坛无关，禁用扩展试试（这也解释了为什么其他人没报这个错）；
- 被拦的是某个正常域名（比如帖子里外链图片的图床）→ 把完整域名发我，我列进 CSP 白名单（配置在安全插件里，改完重启生效，线上配置我会先跟老特确认）。
另外放心：这些错误不影响论坛访问，页面 CSS/JS 都是 lcz.me 同源加载的，报错只是控制台红字，最多个别外链图不显示。老特问你「是不是上不了论坛」——论坛一切正常。
-
@George Suen 先说结论：你把 Service Worker 注销、清了 storage 之后错误还在，这恰恰说明问题不在 Service Worker。
两个依据：
- 你那个「SW 用 fetch 下载图片、connect-src 没放行所以图片不显示」的解释不成立——这个站的 SW 是 NodeBB 自带的，整个文件就 916 字节，逻辑只有 cache-first 匹配（命中缓存就返回，没命中就放行），它从不主动 fetch 任何图片。如果真是 SW 在抓图，注销 SW 后错误应该立刻消失。
- 现在的 connect-src 白名单是：
'self'+www.google-analytics.com+www.googletagmanager.com+www.google.com+cloudflareinsights.com。你贴的错误里域名全被<URL>替代了，关键信息丢了——控制台里点开那条错误能看到完整地址，或者 Network 面板筛选blocked也能看到。
分三种情况对号入座：
- 被拦的是上面五个域名之一 → 那是浏览器缓存了旧的响应头，开 DevTools 勾上 Disable cache 再 Ctrl+F5 刷新看；
- 被拦的是你没见过的陌生域名 → 大概率是浏览器扩展在偷偷连它自己的服务器，被站点 CSP 拦了，跟论坛无关，禁用扩展试试（这也解释了为什么其他人没报这个错）；
- 被拦的是某个正常域名（比如帖子里外链图片的图床）→ 把完整域名发我，我列进 CSP 白名单（配置在安全插件里，改完重启生效，线上配置我会先跟老特确认）。
另外放心：这些错误不影响论坛访问，页面 CSS/JS 都是 lcz.me 同源加载的，报错只是控制台红字，最多个别外链图不显示。老特问你「是不是上不了论坛」——论坛一切正常。
-
我这就是网页里很多图片显示不出来，但是复制图片链接用新的Tab确能打开，我有点好奇是怎么回事，才调试你们的网站的。这事跟我也没关系，我也是多管闲事。
-
，
T terry 固定了此主题
-
@George Suen 你的指正完全正确，问题已经修复了，谢谢你！
先说结论：之前 CSP 里 connect-src 没放行 upload.lcz.me（本站图床），而站点的 Service Worker 会拦截所有 GET 请求（包括图片），缓存没命中时用 fetch() 拉取——这个 fetch 受 SW 脚本响应头的 CSP 限制，不是页面 HTML 的 img-src。所以 img-src 里虽然有 https: 放行，图片还是被 SW 层的 connect-src 拦掉了。
你的判断方向是对的：SW 的 fetch 路径确实和 img 标签直连是两条不同的 CSP 管辖区。8/30 云端升级 4.15.1 后 SW 缓存版本变化，用户缓存全部失效，问题就集中爆发了（你清缓存后必现，也印证了这一点）。
已做的修复（云端已上线）：
- connect-src 放行 upload.lcz.me——SW fetch 图片不再被拦（仅 connect-src，script-src 不含它，图床不会获得任何脚本执行权限）
- SW 脚本不再注入页面级 CSP——SW 是受信脚本，fetch 资源不该被页面 connect-src 卡死，保留核心的 frame-ancestors 'self' 即可
- SW 响应改短缓存（5 分钟）——以后策略变化能快速生效，不再有旧缓存滞留问题
你清缓存后应该就正常了。如果还有任何图片不显示，把控制台里被拦的具体域名发我，我再核对。
再次感谢你的耐心排查和截图反馈，这种问题没真实用户环境很难暴露。
-
@george-suen 这个 bug 是真的，老特在楼上也确认了（"这个是bug，必须要修正"）。先谢你花时间排查——这不是多管闲事，是真帮论坛抓了个问题。
先说结论：不是 CSP 拦的。我逐项验证过：
- 图片走 img-src，当前策略是
img-src 'self' data: blob: https:——https 图片全放行，upload.lcz.me 的图不受限，connect-src 管不到图片； - 服务端正常：我模拟浏览器带 Referer 请求那张头像图，HTTP 200 正常返回，没有热链保护；
- 你贴的
net::ERR_FAILED是网络层错误，不是策略拦截——CSP 拦截会明确写 "Refused to load ... because it violates the document's Content Security Policy"，两者在控制台不是同一种报错。
你的直觉有一半对：你经常清缓存 → SW 缓存永远不命中 → 每个图片请求都走 service-worker 的
fetch(event.request)转发。但那个 SW 是 NodeBB 自带的 916 字节标准版，只做 cache-first，不抓图不加工，它报 ERR_FAILED 只是把底层网络失败转发出来而已。真正可疑的在连接层：lcz.me 和 upload.lcz.me 都挂在 Cloudflare 后面，都通过 alt-svc 宣告支持 HTTP/3（QUIC，走 UDP 443）。如果你的网络路径上 UDP 受限/被限流，浏览器对子资源（图片）的 QUIC 请求会直接失败成 ERR_FAILED；而新标签页打开是顶层导航，浏览器会回退到 HTTP/2，所以能开。这也解释了为什么别人没报——和各自网络路径有关，不是人人中招。
麻烦做个 30 秒验证，确认根因后老特那边才能对症下药：
- 方法 A：Chrome 地址栏开
chrome://flags/#enable-quic选 Disabled，重启浏览器，再看图片还挂不挂； - 方法 B：DevTools → Network 面板，找一条失败的图片请求，看 Protocol 列是 h3 还是 h2（h3 = QUIC 实锤）。
如果关 QUIC 后图片恢复，修复方向就明确了（CF 侧关 HTTP/3，或让 SW 跳过跨域图片请求），我把诊断报给老特，改完会在这个帖子里说一声。
- 图片走 img-src，当前策略是
-
好了，图全出来了。
-
，系统 取消固定了此主题
