腾讯云异常号替换腾讯云 COS 上传文件报 403 AccessDenied？CAM 策略与 Bucket 权限排查

这类报错我见得最多的，不是 COS “坏了”，而是账号权限链路断在了某一层：要么 CAM 没放行，要么 Bucket 权限拦了，要么临时密钥过期了，要么账号本身因为实名、欠费、风控进入了限制状态。

如果你现在卡在“控制台能传，SDK 传不了”“某个子账号能读不能写”“前端直传一到生产就 403”，先别反复改代码，按下面的顺序排查，通常 10 分钟内能定位到问题点。

先看返回码，不同 403 不是同一种问题

返回内容	更像什么问题	优先看哪里
AccessDenied	权限没放行	CAM 策略、Bucket Policy、ACL
SignatureDoesNotMatch	签名错了	SecretId/SecretKey、签名算法、请求时间
RequestTimeTooSkewed	客户端时间偏差	服务器时间、手机端时间、NTP
NoSuchBucket / NoSuchKey	Bucket 名、地域、路径写错	Bucket 名、APPID、Region、Endpoint

很多人把“403”一律归到权限，其实如果你连的是错误地域，或者把 bucket 名和 APPID 写错，也会先表现成失败。先看 code，再看策略，效率最高。

最常见的 4 个拦截点

1）CAM 策略没有给“写入”权限

这是最常见的。子账号、STS 临时角色、CI/CD 用的访问密钥，常常只配了“读”，没配“写”。

上传文件至少要确认这些动作有没有覆盖：

PutObject
PostObject
如果走分片上传，还要看 InitiateMultipartUpload、UploadPart、CompleteMultipartUpload
前端直传或控制台列表查看时，很多场景还会碰到 ListBucket

实际排错里，最容易忽略的是资源路径写窄了。比如只授权到了 bucket 根目录，没带 /*，结果目录能看到，文件就是传不进去。

{
  "version": "2.0",
  "statement": [
    {
      "effect": "allow",
      "action": [
        "name/cos:PutObject",
        "name/cos:PostObject",
        "name/cos:InitiateMultipartUpload",
        "name/cos:UploadPart",
        "name/cos:CompleteMultipartUpload"
      ],
      "resource": [
        "qcs::cos:ap-guangzhou:uid/125xxxxxxxx:mybucket-125xxxxxxxx/*"
      ]
    }
  ]
}

如果你要做列表或目录判断，再补 bucket 级别资源；如果只上传单文件，先把写入权限跑通，再慢慢收紧。

2）Bucket ACL 或 Bucket Policy 把你拦了

Bucket 设成私有并不会影响“有权限的账号上传”，真正出问题的是：

Bucket Policy 里有显式拒绝
ACL 和 CAM 策略互相冲突
你以为自己是 owner，实际上传用的是另一个子账号或临时身份

我处理过一个很典型的场景：开发把 Bucket 设成“只允许指定 IP 上传”，结果公司出口 IP 换了，SDK 一夜之间全 403。控制台看策略没问题，实际上是网络条件被限制了。

3）临时密钥过期，或者前后端时间不一致

如果你是前端直传 COS，基本都会用 STS 临时密钥。这里最常见的问题不是权限不够，而是：

Token 过期了
签名有效期太短
客户端时间偏差大
前端缓存了旧凭证

经验上，前端直传出问题时，先看接口是不是在上传前 5 分钟内拿到的临时凭证；如果是长时间开着页面再上传，403 很容易出现。生产环境里我通常会把 STS 时效控制得比较保守，不会给得太长，但也不会短到用户一拖文件就失效。

4）账号状态异常：实名认证、欠费、风控

这部分很多人会漏掉。尤其是新购账号、刚实名、刚充值的账户，权限看着都对，但资源就是不能正常写入。

你要重点看这几件事：

账号是否已经完成实名，主体是否和实际业务主体一致
是否有欠费、余额不足、套餐到期未续费
是否触发过风控，尤其是频繁创建密钥、短时间多地登录、异常高频上传
如果是代开账号，是否存在实名主体不在你手里的情况

实际业务里，“权限没问题但还是 403”，很多时候是账号状态限制，不是策略问题。先去看控制台通知、账单和安全中心，比盲改 policy 更快。

按你的使用方式排查，别一上来就改全局权限

场景 A：控制台上传都报 403

腾讯云异常号替换 这时优先排查账号状态和 Bucket 归属，不要先怀疑 SDK：

确认登录账号是不是 Bucket 所属主账号或被授权子账号
检查实名、欠费、冻结通知
看 Bucket 是否在正确地域
腾讯云异常号替换 确认上传目录是否被策略限制

场景 B：控制台能传，程序上传 403

大概率是 CAM、签名、临时密钥问题：

SecretId / SecretKey 是否写错、串号、过期
Region 是否和 Bucket 一致
是否用了旧的 STS token
SDK 是否做了分片上传，但策略没放开分片相关动作

场景 C：前端直传一直 403

不要把主账号密钥塞到前端。实操上我更建议：

后端签发 STS 临时凭证
只给指定 bucket、指定前缀、限定时长
前端只拿临时凭证做上传

这样即使凭证泄露，损失面也小。真正线上事故里，前端直传最怕的是“为了解决 403，临时把权限开大”，最后问题是解决了，风险也放大了。

账号购买、实名认证、充值续费会不会影响上传

会，而且经常被低估。

新购账号如果还没完成实名认证，很多资源创建、权限开通、支付后的生效速度都会受影响。尤其是企业项目，建议一开始就把主体信息、联系人、发票抬头统一好，不然后面做 Bucket 权限、密钥归属、账单分摊时会很乱。

充值续费方面，别等到业务停了再充。COS 上传一旦碰到欠费或资源限制，排障时会出现“权限全对但就是上传失败”的假象。先确认账单状态，再看 CAM。

支付方式也会影响开通节奏：

个人项目通常更看重快捷支付和余额充值
企业项目更常用对公支付、企业卡、预充值方式
如果是海外站点，信用卡可用性、币种和风控阈值会更敏感

我的建议是：业务上线前就把续费提醒、余额阈值、主备支付方式配好。很多 403 的根因，最后追到不是权限，而是资源状态切换。

怎么配最省事，也最不容易出事故

方案	适用场景	优点	风险点
主账号密钥直连	临时测试	配置快	泄露风险高，不适合生产
子账号 + CAM 最小权限	后端服务、CI/CD	边界清楚	策略写窄会 403
STS 临时凭证	前端直传、移动端	暴露面小	过期、时间偏差、策略过严
Bucket Policy 额外限制	多团队共用 Bucket	便于统一管控	容易和 CAM 冲突

如果你现在是“上传总失败但又想尽快上线”，我通常会建议：子账号 + STS + Bucket 私有 + 仅放行目标前缀。这套组合虽然比直接开大权限麻烦一点，但后续出问题，定位速度最快。

腾讯云异常号替换常见踩坑清单

Bucket 名写对了，地域写错了
只授权了桶，没有授权对象路径
分片上传没放开完整动作链
前端缓存旧 token，刷新后才恢复
把主账号密钥放进了前端
账号刚实名/刚充值，资源状态还没完全生效
策略里有 IP 白名单，但出口 IP 已变化

最后给你一个排查顺序

先看错误码：AccessDenied 还是 Signature 问题
用控制台上传测试，分离“账号问题”和“代码问题”
核对 Bucket 地域、名字、APPID
检查 CAM 是否包含写入动作和对象路径
检查 Bucket Policy / ACL 是否有显式拒绝
确认 STS 是否过期、客户端时间是否正常
再看实名、欠费、风控状态

常见决策问题

Q：新项目要不要直接给主账号权限？
A：不建议。测试可以临时用，正式环境最好拆成子账号或 STS，不然后面一旦泄露，排查和止损成本都高。

Q：Bucket 设成私有，会不会导致上传 403？
A：不会。私有不等于不能上传，关键看有没有写权限。真正拦你的是 CAM、Bucket Policy 或临时凭证。

Q：控制台能传，程序不能传，最可能是什么？
A：先查密钥、Region、STS 过期，再查分片上传动作是否放开。不要先改 Bucket 公网权限。

Q：刚充值后还是 403，要等多久？
A：如果是账单或资源状态问题，先看控制台是否已经解除限制；如果是策略问题，充值本身不会自动修好权限。

如果你现在手上已经有报错截图、CAM 策略片段、Bucket 权限配置，直接对着这三样排，通常很快就能定位。COS 的 403 不可怕，怕的是一边改策略一边加公网权限，最后把真正的问题盖住了。