摘要：# 图片突然403？别慌，高防CDN接入后防盗链排查指南 ˃ 昨天还好好的，今天一接入高防CDN，网站图片全变叉烧包了，后台还一堆403错误——这场景，搞过网站运维的应该都不陌生吧。 我上周刚帮一个做电商的朋友处理过这事儿。他们为了应对大促可能出现的流…

图片突然403？别慌，高防CDN接入后防盗链排查指南

昨天还好好的，今天一接入高防CDN，网站图片全变叉烧包了，后台还一堆403错误——这场景，搞过网站运维的应该都不陌生吧。

我上周刚帮一个做电商的朋友处理过这事儿。他们为了应对大促可能出现的流量攻击，紧急上了某厂商的高防CDN，结果第二天运营就炸锅了：商品详情页的图片全挂了，控制台一片红彤彤的403。

“我们源站明明好好的啊！”技术小哥一脸懵。其实吧，问题往往不是出在源站，而是高防CDN那套默认的、你可能压根没注意的防盗链规则在“尽职尽责”地拦截你的正常请求。

---

01 403背后的“隐形杀手”：防盗链规则

说白了，403错误就是服务器对你说“没门儿，我不让你访问这个资源”。在高防CDN的场景下，这个“门卫”通常不是你的源站，而是CDN边缘节点。

很多朋友有个误区，觉得高防CDN就是个“流量中转站+盾牌”，配置完CNAME记录就完事了。大错特错。

高防CDN厂商为了帮客户节省源站流量（也防止资源被恶意盗用），默认会开启一套基础的防盗链策略。 这套策略的逻辑很简单：只允许来自你“自家域名”的请求访问图片等静态资源。

比如，你的网站是 www.yoursite.com，图片链接是 img.yoursite.com/xxx.jpg。如果你的网页通过 www.yoursite.com 去引用 img.yoursite.com 的图片，这没问题，属于“自家人”。

但问题就出在，现实情况往往比这复杂得多。

02 四个常见“坑点”，总有一个你踩过

我自己排查过的案例里，下面这几种情况占了绝大多数。你可以对照看看，是不是也中招了。

第一坑：域名白名单没加全。

这是最典型的。你只把主站域名 www.yoursite.com 加到了CDN的防盗链白名单里。但你的网站可能通过绝对路径引用了其他域名下的资源，或者有移动端H5页面（m.yoursite.com）、甚至第三方合作页面引用了你的图片。

结果就是： 来自 m.yoursite.com 的请求，被CDN节点无情地403了。

第二坑：本地调试和特定来源被误杀。

你们公司的开发、测试人员，经常直接在浏览器地址栏打开图片链接（Referer 为空），或者从本地文件（file:// 协议）打开HTML文件来测试。很多默认的防盗链规则，会把 Referer 为空的请求直接判定为“盗链”并拦截。

还有，如果你的网站内容被分享到微信、QQ等App里，这些App内置浏览器发起的请求，其 Referer 字段可能很特殊或者被修剪过，也容易被误伤。

第三坑：HTTPS与HTTP的“混搭”悲剧。

你的主站已经全站HTTPS了（https://www.yoursite.com），但图片等资源在代码里可能还残留着HTTP的绝对路径（http://img.yoursite.com/xxx.jpg）。

在HTTPS页面中通过HTTP加载资源，属于“混合内容”，现代浏览器为了安全，可能会在请求中剥离 Referer 信息。一个没有 Referer 的请求撞上严格的防盗链规则，结局可想而知。

第四坑：CDN配置的“缓存”在捣乱。

这个比较隐蔽。你发现403问题后，火速去CDN控制台修改了防盗链白名单，加上了遗漏的域名。然后刷新网页——怎么还是403？

别急，很可能你访问的CDN节点上，缓存了之前那条“拒绝访问”的规则或者错误状态码。你需要等待缓存过期，或者在CDN控制台执行“刷新缓存”操作（特别是刷新“配置缓存”）。

03 实战排查：五步锁定问题

别被一堆术语吓到，排查起来是有章可循的。下次再遇到，按这个路子走，心里不慌。

第一步：打开浏览器开发者工具（F12）。

这是你的“侦探眼镜”。直接打开出错的页面，找到一张显示403的图片，在“网络”(Network)标签页里找到它的请求记录。

重点关注两个头信息：

• Referer： 看看这个值是什么。如果是空的，或者不是你白名单里的域名，那基本就是它的问题。
• Host 和实际请求的URL： 确认请求是不是真的走到了你的高防CDN域名上（比如 xxx.cdn.gf.com），而不是因为解析错误直接回了源站。

第二步：核对CDN控制台配置。

登录你的高防CDN服务商控制台，找到“防盗链”或“访问控制”配置项。重点看：

1. 白名单里到底放了哪些域名？ 用逗号分隔的，一个个检查，别漏了 m. 这种子域名。
2. 是否开启了“允许空Referer”？ 如果你们的业务场景需要（比如APP内嵌、本地文件），这个可能需要勾上。
3. 规则是“黑名单”还是“白名单”模式？ 绝大多数高防CDN默认是“白名单”（只允许列表内的），别搞反了。

（说真的，我见过不止一个团队，在这里把规则模式选错了，那真是拦得自家网站亲妈都不认识。）

第三步：模拟请求，验证规则。

光看不够，得动手试。用 curl 命令或者Postman这类工具，手动构造请求。

# 模拟一个带正确Referer的请求
curl -I "https://img.yoursite.com/pic.jpg" -H "Referer: https://www.yoursite.com"

# 模拟一个空Referer的请求（比如从APP发起）
curl -I "https://img.yoursite.com/pic.jpg"

看看返回的状态码是200还是403，就能立刻验证你的防盗链规则是否按预期工作。

第四步：检查代码和资源引用。

让开发同事全局搜一下代码库，看看有没有硬编码的、非白名单域名的资源链接，或者HTTP/HTTPS协议不统一的问题。特别是那些老页面、第三方插件引入的静态资源，都是重灾区。

第五步：刷新CDN缓存并测试。

在完成上述检查和修改后，务必在CDN控制台执行“刷新”操作。不是只刷新那个文件URL，最好把“目录刷新”和“配置刷新”都做一下。然后，清理本地浏览器缓存，再访问测试。

---

04 如何设置才稳妥？我的几点私货建议

1. 上线前，测试环境先跑通。 别在生产环境直接调规则。正规的高防CDN都提供测试域名或预览配置功能，先用起来。
2. 白名单宁宽勿紧（初期）。 刚接入时，如果业务复杂，不妨先把“允许空Referer”打开，白名单把可能用到的域名（主站、移动站、API域名等）全加上。等稳定运行一段时间，通过CDN日志分析出真实的、合法的 Referer 来源后，再逐步收紧规则。
3. 善用CDN的“忽略参数”缓存功能。 如果你的图片链接带有随机参数（比如 ?v=12345）来防浏览器缓存，记得在CDN缓存配置里设置好“忽略查询字符串”，否则每个带不同参数的相同图片都会被当成新文件，可能绕过缓存触发规则检查，增加源站压力。
4. 日志是你的最佳战友。 开启CDN的访问日志下载功能。出现403时，去日志里搜对应的请求，里面 Referer、User-Agent、Client-IP 一清二楚，比瞎猜强一万倍。

最后说句大实话：高防CDN的防护能力是强，但它附带的这些“默认设置”就像一把双刃剑。 用好了，既安全又省流量；没弄明白就往上怼，分分钟把自己业务搞挂。接入任何新服务，“默认配置”这四个字最要命，一定得亲手过一遍。

行了，排查思路和工具都给你了。下次图片再403，知道该从哪儿下手了吧？