阿里云403报错，先查权限、防盗链还是WAF？

遇到阿里云返回403，很多人第一反应是去看权限，但它其实可能来自对象存储、CDN、WAF 或 API 网关等不同产品。HTTP 403 只说明请求被拒绝，不说明原因。所以排查时先找出是哪一层拒绝了请求，再去处理那一层的问题，会省不少时间。

先看403是哪一层返回的

不同产品的403响应长得不一样，看一眼返回内容，基本能先缩小范围。

对象存储OSS：响应体是XML，里面有 Code 字段和 RequestId，响应头通常带 x-oss-request-id。
CDN：响应头或错误页里常见阿里云CDN相关标识，多半和防盗链、IP黑白名单或签名URL过期有关。
Web服务器：如果响应头显示的是 Nginx 或 Tengine，问题大概率出在服务器本身的目录权限或访问配置上。
API调用：返回JSON，错误信息里带 Code，比如 NoPermission、InvalidAccessKeyId、InvalidSecurityToken.Expired。

具体错误码以控制台返回和官方文档为准，别只凭印象判断。

某电商团队把商品图传到OSS，前端直接用对象URL展示，结果图片全部403，返回的XML里 Code 是 AccessDenied。原因很直接：Bucket 是私有读写，匿名用户读不到对象。

这时要先想清楚图片是不是公开的。如果确实要对外展示，可以把读权限改为公共读，或者用 Bucket Policy 只放开某个前缀，比如 images/ 目录。如果只允许特定用户看，那就保持私有，由服务端生成带有效期的签名URL，链接过期自然失效。

这个团队最后选了后一种，并把商品图和用户隐私图拆到两个Bucket里。公开内容和私有内容混在一起，早晚会配错一次。

内容团队给实习生建了RAM子账号，用来上传文章配图。上传时报 NoPermission，提示缺少 oss:PutObject 权限。

RAM子账号默认什么权限都没有，需要显式授权。团队给实习生绑定了一条自定义策略，只允许写入指定Bucket下的某个目录，资源写法类似 acs:oss:*:*:your-bucket/articles/*。重新上传就正常了，而且实习生删不掉其他业务数据，也算符合最小权限的思路。

一个博客把图片放在OSS并经过CDN加速。自己的站点访问没问题，但别的网站引用这些图片时全部403。

这通常是开了防盗链，Referer白名单里只有自己的域名。验证方法很简单，用curl分别带不同的 Referer 去请求同一个URL，白名单外的返回403，白名单内的返回200。

要不要放开，取决于你的态度。允许别人引用，就把域名加进白名单；不想被盗用，就保留防盗链。注意别把空Referer也拦掉，很多浏览器的正常访问不带 Referer，拦了会误伤真实用户。改完配置后，CDN一般要等几分钟才生效，别急着判断没用。

有位开发者在本地用SDK调OSS，报 SignatureDoesNotMatch。查了半天，发现AccessKey Secret 复制时多了一个空格。修掉之后，另一台服务器又报 RequestTimeTooSkewed，这说明服务器时间和标准时间差得太远。

两类错误的处理方向不一样。签名不匹配，先核对AccessKey ID和Secret是否完整、有没有多余空格，以及是不是用了已经删除或轮换过的旧密钥。时间偏差，则需要同步服务器时间，比如用 NTP 服务，执行 chronyc makestep 后再测一次。

一个数据同步任务用STS临时凭证访问OSS，跑了几个小时后开始报 InvalidSecurityToken.Expired。凭证有效期到了，任务却没有刷新。

正确做法是让任务在凭证到期前主动换新，而不是把长期AccessKey直接写进代码里。这一点很容易被忽略，因为任务刚上线时一切正常，问题往往要几个小时后才出现。

遇到403，先确认来源，再核对权限，然后检查凭证，最后看网络和配置。按这个顺序走，大部分问题都能较快定位。