网站直连源站正常，接入 CDN 后却返回 403 Forbidden，并不一定是文件权限出了问题。CDN 边缘节点、WAF、源站防火墙、Nginx 访问控制、防盗链、对象存储权限和签名 URL 都可能主动拒绝请求。排查时先确认 403 由哪一层返回，再改对应规则。直接关闭全部安全策略，往往会把故障变成安全风险。
先确认 403 是 CDN 返回的，还是源站返回的
先保存一份失败请求的响应头：
curl -sS -D - -o /dev/null https://www.example.com/path/file.jpg
检查 Server、Via、X-Cache、请求 ID、Ray ID 等响应头，同时查看错误页样式。各家 CDN 的字段不同，单个响应头不能直接定责，最好把响应时间、访问 URL、客户端 IP 和请求 ID 一起保存。
如果知道源站 IP，可在不改 DNS 的情况下绕过 CDN 测试：
curl -sS -D - -o /dev/null \ --resolve www.example.com:443:203.0.113.10 \ https://www.example.com/path/file.jpg
--resolve 会保留域名、Host 和 TLS SNI，比直接访问 https://IP/ 更接近生产请求。若 CDN 路径返回 403、源站路径返回 200，重点检查边缘 WAF、CDN 访问控制、回源请求头和缓存。两条路径都返回 403，则继续查源站 Web 日志、防火墙和文件访问规则。
在安全日志中定位命中的 WAF 规则
WAF 拦截通常带有规则 ID、动作、匹配字段和请求 ID。按故障时间与请求 ID 查询安全事件，确认是托管规则、自定义规则、Bot 策略、速率限制还是地域限制触发。
不要为了恢复访问直接关闭整套 WAF。更稳妥的处理方式是复制一条真实失败请求，在测试域名或灰度规则中复现，然后只调整误报的匹配条件。可以限制到具体路径、请求方法或业务参数，并保留原规则，方便回滚。
如果只有上传、登录或 API 请求报 403，检查请求体、Cookie、Authorization、Content-Type 和请求方法是否被规则识别为异常。不要把真实密码、Cookie 或令牌直接写进共享终端历史。
检查源站是否把 CDN 节点当成了陌生 IP
源站接入 CDN 后，TCP 连接的对端通常是 CDN 回源节点。安全组、云防火墙、iptables/nftables 或 Nginx 若只允许旧 IP，很容易把回源请求全部挡掉。
核对 CDN 官方公布的回源 IP 段，并检查 IPv4、IPv6 是否都覆盖。IP 段可能调整，长期手工复制一份列表却不更新，会留下间歇性故障。还要注意多台源站的规则是否一致，避免一台返回 200、另一台返回 403。
Nginx 的 allow 与 deny 按顺序匹配，第一条命中规则就会生效。下面这类配置要确认网段和顺序：
location / { allow 192.0.2.0/24; allow 2001:db8:1234::/48; deny all;}修改前备份配置，执行 nginx -t 通过后再平滑重载。临时放开全部公网访问虽然能帮助判断方向，但会暴露源站，不适合直接用于生产恢复。
防盗链规则可能误伤正常请求
图片、视频和下载文件常按 Referer 做防盗链。隐私浏览器、App、命令行客户端或经过代理的请求可能不携带 Referer，也可能被中间设备清空。规则只允许固定页面来源时，这些正常访问会收到 403。
Nginx 官方文档也说明，Referer 很容易伪造，因此它适合减少普通浏览器的批量盗链，不适合作为严格鉴权。可按业务需要允许无 Referer 请求，或对私有资源改用有有效期的签名 URL：
valid_referers none blocked server_names *.example.com;if ($invalid_referer) { return 403;}上线前至少测试站内页面、直接打开资源、App、搜索引擎抓取和跨域请求。不要只用自己的浏览器验证一次。
核对域名绑定、Host、SNI 和允许的方法
有些 CDN 要求自定义域名同时完成 DNS 指向和控制台绑定。DNS 已经指向分发地址，但域名没有加入 CDN 配置时，请求可能直接返回 403。
回源 Host 配错也会命中源站的默认虚拟主机或错误站点。HTTPS 回源还要检查 SNI 与证书域名是否一致。排查时比较 CDN 实际发送的 Host、源站 server_name、证书 SAN 和应用允许的主机名。
若页面 GET 正常，表单提交、文件上传或跨域预检失败，检查 CDN 是否允许并转发 OPTIONS、POST、PUT、PATCH、DELETE。只开放业务需要的方法，别为了消除 403 把所有写操作一并放开。
对象存储和私有内容要单独检查权限
对象存储作为源站时，403 还可能来自桶策略、对象 ACL、私有源站授权、路径大小写或签名 URL。部分对象存储对不存在的私有对象也可能返回 403，不能看到状态码就认定文件一定存在。
确认 CDN 使用的源站身份有读取权限，资源路径与对象键完全一致，签名 URL 没有过期，客户端时间没有明显偏差。公开静态资源与付费下载、会员文件应使用不同的访问策略，避免用一条宽泛规则同时处理。
修复后清理错误缓存并做多路径验证
部分 CDN 会短暂缓存 403。规则已经修正但边缘仍返回旧错误时，可刷新准确 URL 或等待错误缓存过期，不要一开始就全站清缓存。
验证时至少覆盖以下场景：
CDN 域名与保留 Host/SNI 的源站请求都返回预期状态；
普通页面、静态资源、API 和跨域预检分别测试；
不同网络或地区节点不再间歇出现 403；
WAF 日志、源站访问日志与防火墙日志能对应同一请求；
源站仍只接受预期的回源流量，没有因临时排查长期暴露。
403 的处理顺序可以固定下来：保存失败样本，区分边缘与源站，按请求 ID 查规则，做最小范围修改，再刷新错误缓存并复测。这样既能恢复访问，也不会为了赶时间把 WAF、白名单或私有资源保护全部拆掉。
