网站上的图片全部打不开，是403还是权限问题？

首页正常打开，文字都在，CSS、JS、图片全变成403。F12里一片红，页面裸奔成纯文本加几个蓝色链接。这种一半正常一半403的情况，跟站点程序没关系，问题在静态文件这一层。同一台机器上别的站正常，就更能确定是本地的权限或者规则。

nginx的worker进程不是用root跑的，Debian系是www-data，CentOS是nginx。它读文件靠的是权限里的other位。文件644、目录755，谁都能读，不会出问题。你要是图省事，把整个站点都设成700，属主是自己的登录账号，nginx直接读不到，报出来的就是403。文件权限对了还要看目录：进一个目录需要x位，只给r不给x，ls能列出名字但进不去，效果一样是403。chmod -R 777之所以能修好，就是它把other位放开了，代价是任何用户都能往这个目录里写东西。还有个细节：图片是PHP生成的，属主是www-data；用root跑过一次脚本之后，新缩略图的属主变成root，权限摆得再对，nginx一样读不了。

namei -l /var/www/site/wp-content/uploads/2026/03/a.jpg把路径上每一级的权限一次列全，哪一级断了看得清清楚楚，比自己一级一级cd过去试快得多。再补一条sudo -u www-data cat那个文件，能读出内容就是权限没问题，读不出就是权限问题。两条命令分完，基本不会有第三种可能。namei输出里出现问号的那一级，就是断掉的地方。

权限全对还是403，去看nginx配置。location里写了deny all的，正则匹配到静态文件就会命中。防盗链、防跨站的规则写宽了也一样，比如把location ~ \.(js|css|png|jpg)$整段deny掉。还有try_files最后那个=403，本意是挡目录遍历，结果把不存在的路径也变成了403。error.log里写client denied by server configuration，这一行能直接定位到是哪条规则。还有一种顺序问题：两个正则location，按配置文件里出现的先后生效，不按长短，调换位置命中的规则就变了。

CentOS上还有一层。SELinux是enforcing的话，文件上下文不对，权限给到777也读不了。ls -Z看类型，站点目录应该是httpd_sys_content_t。getenforce确认状态，setroubleshoot的日志里会有AVC denied的详细记录。临时验证可以setenforce 0，能打开就确认是它，验完记得切回enforcing。

有些程序故意把不存在的文件返回403，防止别人探测目录结构。这个做法本身没错，排查的时候却会误导人：以为权限出了问题，其实文件根本不在。curl -I拿到403之后，再看error.log里写的是Permission denied还是directory index of is forbidden，两种完全不是一回事，后者是目录没配index，跟权限无关。想再快一点，请求一个确定存在的文件，比如/favicon.ico：它也403，就是全站级规则；它正常，问题只在那批后缀上。

修完别只刷新首页。把F12的Network按状态码排一遍，403清空了才算完。顺手把权限收一遍：目录755、文件644、上传目录不给执行权限。上传目录再单加一条location，把PHP执行关掉，比靠权限挡更稳。