网页文字都出来了，偏偏有张图一直空白。Chrome 的网络面板里有一行 ERR_BLOCKED_BY_CLIENT，Clash 日志也刚好跳出几行 REJECT。先记下那张图的请求地址和发生时间。一个页面会同时加载图片、脚本和接口，屏幕上两行红字挨得近，可能对应两件事。

先找到缺失的那个资源

在电脑端 Chrome 打开开发者工具 → Network／网络。如果当时面板已经打开，先用已有记录。面板只记录打开后捕获到的请求，列表也可能被筛选条件藏掉。需要补一条记录时，可以在没有未保存内容的公开网页上正常加载一次。登录验证、付款和提交表单的页面适合直接保留现有线索。

1. 先按出问题的内容缩小范围。图片可从 Img 分类找起，网页里的按钮没反应时，可以看看 JS 和 Fetch/XHR。类别只是筛选入口，没找到就回到 All 再看。
2. 点开可疑的行，从 Headers／标头 核对请求地址和资源名，再看 Status／状态 的提示。若状态只显示简写，可以到 Console／控制台查同一地址旁的报错原文。这里只看已有消息。相关入口见 Chrome 控制台文档。
3. 看 Initiator／发起方。这里可以帮助你追到哪个页面或脚本发起了加载。如果显示脚本，顺着链接或悬浮提示可以看到触发位置。要定位具体拦截动作，还需要另一条记录。

同一个域名可以承载许多资源。同一张图也可能在刷新后再次请求。对照时尽量把资源、页面动作和时间对齐。字段说明见 Chrome 网络面板文档。

把图片地址单独贴进地址栏，会变成一次新的页面导航。扩展规则可以按发起域名和资源类型匹配，同一地址换个加载方式，可能得到不同结果。要复核原来的失败，留在原页面查看那次图片加载。匹配条件见 Chrome 扩展规则示例。

错误原文能把范围缩小到哪里

ERR_BLOCKED_BY_CLIENT 是 Chromium 给出的客户端阻止请求的错误。安装的内容过滤扩展是一条排查线索。要归因到某个扩展，需要核对它在当时对该资源做了什么。Chromium 另外定义了管理员 URL 列表拦截的错误 ERR_BLOCKED_BY_ADMINISTRATOR，遇到单位管理的浏览器，可把原文交给管理员核对。详见 Chromium 网络错误定义。

浏览器扩展可以在发出请求前处理拦截，也可以在收到响应头后按规则终止加载。看到客户端拦截时，请求可能已经发出。这也是为什么判断传输路径时还要看对应的连接记录。相关阶段见 Chrome 扩展规则评估说明。

遇到明确的 HTTP 数字状态，例如 403，先去这条请求的标头里核对状态和响应来源。若状态写的是 (blocked:devtools)，可查看 DevTools 的 Request conditions／请求条件 里是否已有匹配项。详见 Chrome 请求条件说明。

用已有记录判断该找谁处理

扩展本身如果提供过滤记录，可以查已有条目里的目标、时间和处理结果。只看到某个扩展安装在浏览器里，证据还停留在“它可能参与”。记录能够对上具体资源时，再向该扩展的维护者核实规则用途。扩展没有展示过滤记录时，先记下浏览器的错误和发起来源，保留未确认的部分。

Clash 的 REJECT 要在实际出站里确认。假设图片来自一个资源域名，日志里的 REJECT 对着另一个统计域名，就先分开看。目标和时间都吻合、实际出站也确实是 REJECT，才值得沿该连接查命中的规则。连接结束过快或记录未保留时，结果可以先写成“暂无可对应的代理记录”。规则的查法见 Clash REJECT 排查。

如果问题需要交给别人看，先整理一条简短描述，比如“公开文章能打开，图片加载失败，错误是 ERR_BLOCKED_BY_CLIENT，发起方显示为页面脚本，现有记录里还没找到匹配的拦截规则”。时间、错误原文、资源类型和处理结果通常就够开始排查。需要发送记录时，可按 求助日志隐私检查 先去掉账号、地址参数和订阅凭据。