域名已经解析到服务器，Nginx服务也显示正常，浏览器却只返回403 Forbidden。这个状态码说明请求已经到达能够处理它的服务，但当前资源被拒绝访问，和端口完全不通不是同一类问题。
最危险的处理方式是对网站目录执行递归 chmod 777。页面可能暂时打开，文件却变成所有本地用户都可写。正确顺序应该是先看错误日志和实际路径，再只修改确认有问题的那一层。
先确认403由哪一层返回
记录故障域名、URL和时间，用响应头和日志确认返回者：
curl -I http://example.com/
sudo tail -n 100 /var/log/nginx/error.log
sudo nginx -T | less面板环境可能为每个站点保存独立错误日志，路径应以 nginx -T 展示的生效配置为准。网站前面还有CDN、WAF或应用框架时，403也可能由访问策略或程序返回。
错误日志常会写出 directory index is forbidden、permission denied、access forbidden by rule 等线索。先按日志中的实际原因分支，比反复改权限更快。
检查请求命中了哪个server配置
同一IP部署多个网站时，域名可能命中默认站点。检查 server_name、监听端口、证书对应站点以及 root 或 alias：
sudo nginx -T | grep -nE 'server_name|listen|root|alias|index'不要只查看某个配置文件，Nginx可能通过 include 加载其他目录，面板也可能生成新的站点配置。改错文件后即使重载成功，实际请求仍由另一段配置处理。
使用IP直接访问与使用域名访问，可能命中不同的 server。测试时应保留真实Host头，避免因为测试方式不同得出错误结论。
首页文件不存在时也可能返回403
请求目录 / 时，Nginx会按 index 指令顺序查找首页文件。站点根目录里没有对应文件，而目录列表又未开启时，常见结果就是目录索引被禁止。
先确认配置和实际文件：
ls -la /var/www/example
sudo nginx -T | grep -n 'index '静态站点通常需要存在 index.html；PHP站点还要让 index.php 出现在 index 配置中，并正确转交给PHP-FPM。不要为了显示目录内容而随意打开 autoindex on，这可能暴露备份、上传文件和内部目录。
用namei检查整条目录权限
Nginx工作进程需要能够穿过站点路径上的每一级目录，并读取目标文件。先确认实际运行用户和完整路径权限：
ps -eo user,group,comm | grep nginx
namei -l /var/www/example/index.html目录的执行权限决定能否进入，文件的读取权限决定能否读取内容。父目录缺少权限时，只修改最末级网站目录仍然无效。
权限方案要结合部署方式确定。由发布用户写入、Nginx只读的站点，可以通过合理的用户组和目录权限实现，不需要把所有内容交给Nginx用户，更不需要把整棵目录改成777。
检查deny规则和location覆盖
Nginx配置可能明确包含 deny all、IP白名单、Basic Auth、referer限制或只允许内部访问的location。面板的防盗链、访问限制和安全插件也会生成相应规则。
重点查看实际URL最终命中的 location，尤其是正则location、隐藏文件规则和通过 include 加载的安全配置。某个子目录403而首页正常，通常比全站403更接近location或目录级权限问题。
修改后执行：
sudo nginx -t
sudo systemctl reload nginx语法检查通过再平滑重载，每次只改一类配置并保留前后日志，便于确认真正生效的改动。
RHEL系系统还要核对SELinux
传统权限看起来正常，但RHEL、Rocky Linux或AlmaLinux仍持续记录permission denied时，检查SELinux状态、文件标签和审计日志：
getenforce
ls -Zd /var/www/example
sudo ausearch -m AVC -ts recent自定义站点目录通常需要匹配Web内容的安全上下文。应通过 semanage fcontext 记录规则，再用 restorecon 应用；不要长期关闭SELinux，也不要看到拒绝日志就直接用 audit2allow 生成宽泛策略。
旧面板迁移后路径、属主和安全标签混在一起时，可以在 萤光云 准备同发行版环境复现配置，也可以使用按小时计费的 LightNode 做短期对照。对照环境应保持相同Nginx版本、目录结构和安全策略，否则新服务器能打开并不能直接证明旧环境的根因。
修复后怎么验收
使用域名分别访问首页、静态资源、PHP页面和原先403的具体路径，状态码应符合预期。Nginx错误日志不再新增权限或目录索引错误，安全策略也没有被整体关闭。
再用非管理员账号检查网站目录，确认无关用户不能随意写入。页面恢复与最小权限同时成立，才算真正修复。
常见问题
为什么网站首页403，某个具体HTML却能打开？
通常是首页文件名称与 index 配置不一致，或根目录没有首页文件且目录列表被禁止。先核对日志和 index 指令。
把网站目录改成755、文件改成644一定正确吗？
不一定。还要看属主、用户组、父目录、部署程序是否需要写入，以及SELinux等附加控制。权限数字不能脱离实际运行用户套用。
403会不会是CDN造成的？
会。先用响应头、CDN日志和绕过CDN的受控测试确认返回层，再决定修改源站Nginx还是平台访问规则。
