OBS 用着用着报 403？先把桶、存储类别和权限这三件事捋清楚

想把网站图片扔到云上，桶建好了，文件也传上去了，浏览器一打开链接——403 Forbidden。当时第一反应是文件没传上去，又传了三遍，结果一模一样。后来才明白，OBS 里“传上去了”和“能访问”是两码事，中间隔着桶、存储类别、权限三道坎。今天就把这三件事捋一遍。

先说建桶。区域这东西，选跟业务近的就行，离得近延迟低；要是以后想做静态网站，也得跟访问来源一起考虑。反正桶建好之后区域改不了，动手前想清楚。桶名是全局唯一的，起名字多试几个，别跟常用词撞车。

存储类别看访问频率选：天天要读的放标准存储；一个月难得读几次的放低频访问；基本不读、留着备查的放归档；压箱底、几年不动一次的放深度归档。类别选错了也能改，但归档类取回要花时间，思路上最好一开始就按真实访问频率选，省得来回折腾。

新手最容易踩的一个坑：把备份文件一股脑全扔进标准存储。一年下来才发现，九成文件就写进去那一次，之后再也没读过。传之前先想清楚数据的“热度”，热数据放标准，冷数据往下沉。

然后是权限，这也是 403 的重灾区。OBS 默认是私有的：只有桶的拥有者能读写，其他人直接拼 URL 访问，一律 403。想让别人能看，有两种路子。

一种是公开读：把桶或对象设成匿名可读。注意公开读放开的是读，写权限还是自己的。做图床、静态资源分发适合这个。但千万别把存着敏感备份的桶设成公开读——公开了就是真公开，谁拿到链接都能看。

另一种是保持私有，用带时效的签名 URL 临时授权：链接里带上签名，过期就失效。适合分享给特定的人，或者后端生成临时下载链接的场景，权限收得紧，心里踏实。

桶策略和对象权限的关系，很多人搞混。桶策略是挂在桶上的“一揽子规则”，一次性能规定哪些人能对哪些对象做什么；对象权限是单个文件的“小纸条”，粒度更细。两个地方是叠加生效的，排查 403 的时候两边都要看，别只看一个就下结论。

静态网站托管，大致思路就三步：桶里放好首页这类静态文件，把桶设成允许公开读（或者用桶策略放行读），再在静态网站托管配置里指定首页和错误页。之后就能用桶的网站域名直接访问了。记住这只解决静态页面，动态接口还得另想办法，别指望一个桶搞定全站。

重点来了：403 到底怎么查？按这个顺序来，别乱试。

先看桶策略有没有放行。很多人文件传上去了，但桶策略里压根没给匿名读授权，浏览器直接访问当然 403。去桶策略里确认一下：读权限到底放没放行，资源范围写得对不对——比如只放行了某个前缀，文件却在另一个目录下，这种错位很常见。

对象本身的权限也得看。桶策略放行了，但单个对象的权限可能是私有的，或者对象是后来覆盖上传的，权限被重置了。点开出问题的那个对象，单独确认它的读权限，别想当然。

接下来查签名和地域端点。用了签名 URL 的话，看看签名是不是过期了；直连访问的话，确认用的域名跟桶所在区域对得上，域名拼错区域也会出各种奇怪的错误，看着像 403，其实是找错了门。

还有一个很隐蔽的：跨域。浏览器地址栏直接打开图片没问题，但网页里用脚本去拉就失败，多半是它。浏览器的同源策略在拦，OBS 这边要在桶的跨域配置里把你的网站域名加进去，允许它跨域读。前端调 OBS 资源出问题，先怀疑跨域，十有八九。

再多一句提醒：排查的时候改一个地方、测一次，别一口气改五六处。一下子全改了，最后都不知道是哪一下修好的，更不知道是哪一下埋的雷，回头复盘都没法复。

说到底，OBS 的 403 很少是服务本身坏了，多半是权限这层没捋顺。建桶时想清楚区域和存储类别，权限上分清公开读和私有、桶策略和对象权限，出了 403 按“策略→对象→签名/端点→跨域”这个顺序查，一大半问题都能自己解决。