头像

白日梦与诗

林深时见鹿，海蓝深见鲸

Cloudflare ImgBed图床无法访问排查与修复

9分钟阅读

关联主题:: 图床
同级:: 2026-06-04_星期四
下一级:: Cloudflare给pages和Worker优选域名

Cloudflare ImgBed图床无法访问排查与修复

问题现象

最开始访问图床自定义域名：

https://i.brmys.cn/

浏览器提示找不到页面，或者 Cloudflare 返回 404。

继续检查 Cloudflare Pages 自动生成的默认域名：

https://cloudflare-imgbed-6lu.pages.dev/

也无法访问。

这一步很关键，因为如果 pages.dev 默认域名都打不开，问题就不只是自定义域名解析，而是 Cloudflare Pages 项目本身没有正确部署出来。

第一次误判：以为是域名解析问题

一开始看到 i.brmys.cn 的解析链路里出现了优选域名：

i.brmys.cn
-> cf.090227.xyz

所以很容易怀疑是 cf.090227.xyz 这个优选域名的问题。

后来发现事情没这么简单。brmys.cn 的权威 DNS 在 Cloudflare，但 i.brmys.cn 这个子域名单独通过 NS 委派到了 DNSPod：

i.brmys.cn NS f1g1ns1.dnspod.net
i.brmys.cn NS f1g1ns2.dnspod.net

也就是说，i.brmys.cn 真正生效的解析要去 DNSPod 看，而不是只看 Cloudflare 里的普通 DNS 记录。

这也是一个经验：只看某一个 DNS 面板不一定可靠，要看当前权威解析到底在哪里。

可以用下面的命令确认：

dig +trace i.brmys.cn
dig +short i.brmys.cn CNAME @f1g1ns1.dnspod.net

真正根因：新版部署输出目录变了

后来在 Cloudflare 里测试历史部署时发现：

两个月以前的部署可以访问
两个月以内的新部署都无法访问

这说明旧版本本身是好的，是最近的新部署出了问题。

进一步看 GitHub 仓库后发现，Cloudflare-ImgBed 近期由自动同步触发了更新。GitHub 上看起来有一次最近的成功记录，但这个“成功”不等于 Cloudflare Pages 最终可访问。

核心变化是：Cloudflare-ImgBed 新版要求 Pages 构建输出目录改成：

/frontend-dist

如果 Cloudflare Pages 里仍然使用旧配置，比如输出目录是 /，部署过程可能看起来没报错，但最终根路径没有正确的 index.html，访问时就会出现 404。

修复步骤

先进入 Cloudflare：

Workers & Pages
-> cloudflare-imgbed-6lu
-> Settings
-> Build & deployments
-> Build configuration

把构建配置改成：

Build command: npm install
Build output directory: /frontend-dist
Root directory: 留空或 /

然后重新部署最后一次部署。

修复后先访问默认域名：

https://cloudflare-imgbed-6lu.pages.dev/

确认默认域名正常后，再访问自定义域名：

https://i.brmys.cn/

这次两个地址都恢复正常。

关于优选域名和境内外访问速度

图床恢复后，又遇到一个问题：开启 Clash 后访问很慢，关闭 Clash 后速度也不一定稳定。

排查后发现，i.brmys.cn 现在适合做分线路解析：

国内线路 -> cf.090227.xyz 这类 Cloudflare 优选域名
境外 / 默认线路 -> cloudflare-imgbed-6lu.pages.dev

原因是 cf.090227.xyz 这类优选域名通常是为了国内访问 Cloudflare 更快，不一定适合海外访问，也不一定适合代理节点访问。

比较稳的方案是：

中国大陆：走优选域名
默认 / 境外：走 Cloudflare Pages 默认域名

如果后续要继续优化国内速度，也不要盲目换网上流传的优选域名，最好用测速工具按自己的网络环境测试。

Clash 规则的小坑

为了测试代理访问，我在 Clash 里给 i.brmys.cn 添加了规则：

类型：匹配完整域名
规则内容：i.brmys.cn
代理策略：节点选择

但连接页里仍然显示：

链路: DIRECT
规则: DomainSuffix(cn)

这说明规则没有命中，而是被更前面的 .cn 直连规则匹配走了：

- 'DOMAIN-SUFFIX,cn,DIRECT'

正确做法是把 i.brmys.cn 这条规则添加为前置规则，让它排在 DOMAIN-SUFFIX,cn,DIRECT 前面。

如果希望走代理：

- 'DOMAIN,i.brmys.cn,节点选择'

如果希望直连：

- 'DOMAIN,i.brmys.cn,DIRECT'

还有一个容易忽略的小点：Clash 规则修改后，已经建立的旧连接不会自动重新判定规则。

所以改完规则后，需要关闭当前连接、重启浏览器，或者在 Clash 的连接页手动断开旧连接。断开后重新访问，规则才会重新命中。
image.png

这次的排查顺序

以后遇到类似问题，可以按这个顺序排查：

  1. 先访问 Cloudflare Pages 默认域名，确认项目本身是否可用。
  2. 如果默认域名 404，优先查部署日志和构建输出目录。
  3. 如果默认域名正常，自定义域名异常，再查自定义域名绑定和 DNS 解析。
  4. 如果涉及优选域名，确认子域名有没有被 NS 委派到 DNSPod。
  5. 如果开启 Clash 后异常，查看连接页实际命中的规则和链路。
  6. 修改 Clash 规则后，记得断开旧连接重新测试。

经验总结

这次最重要的经验是：不要只看表面的“部署成功”或“DNS 已配置”，要拆开验证每一层。

对于 Cloudflare Pages 项目：

GitHub 自动同步成功 != Cloudflare Pages 内容一定部署正确
Cloudflare Pages 部署成功 != 构建输出目录一定正确
自定义域名打不开 != 一定是 DNS 问题

对于 DNS 和优选域名：

Cloudflare 面板里的记录 != 一定是当前实际生效记录
子域名如果做了 NS 委派，要去被委派的 DNS 服务商那里看
优选域名适合国内优化，但不一定适合海外或代理节点

对于 Clash：

规则要看优先级
前置规则才会覆盖订阅里的通用规则
旧连接不会因为规则更新而自动切换链路

最后这次真正解决问题的关键动作其实很简单：

Cloudflare Pages 输出目录改为 /frontend-dist
重新部署最新版本
Clash 里把 i.brmys.cn 规则放到前置
断开旧连接后重新访问

这套排查链路以后还可以复用到其他 Cloudflare Pages、Worker、自定义域名和图床类项目上。

关系图谱

1