报错页脚写着 nginx

客户发来截图，403 页面底部一行小字：nginx。很多人看到这四个字母就慌了。

其实它只说明一件事：这个响应是 Web 服务返回的，不是你的应用返回的，方向立刻清楚。

为什么这很重要

这一层分错，后面全白干，还会给同事添乱。

如果是应用返回 403，说明请求已经打到后端，问题在权限和业务逻辑，得翻代码。

如果是 nginx 返回 403，请求可能压根没进后端，改代码当然没效果，白改一整天。

第一件事就是分清这个 403 是谁签发的，这一步定生死。

常见的几张面孔

它们长得像，成因完全不同，只能靠日志和路径区分。

目录访问：没开 autoindex，又没有 index 文件，直接 403，日志会写得很清楚。

文件权限：nginx 运行用户没有读权限，静态文件一访问就 403，换目录就复现。

index 缺失：请求的是目录，找不到默认首页，又不允许列目录，报错一模一样。

try_files：规则写错，把请求落到一个不存在的路径上，最后兜成 403。

deny：配置里有拒绝规则，命中了就返回 403，这条最容易被忘掉。

用测速先看范围

范围决定要不要动配置，也决定改动的影响面。

用宝塔拨测的网站测速跑多地区多运营商节点，只看这一条地址，别把整个站一起拖进来。

所有节点都 403：配置层面的问题，和地区无关，专心看配置就好。

只有部分地区 403：先看那一路的节点或策略，别急着改 nginx，改也不是那里的问题。

同域名其他路径正常：范围缩到这条路径上，问题非常具体，几分钟能定位。

三个动作定位

三个动作做完，基本就知道是哪条规则，剩下只是改。

看 nginx 的错误日志，403 会写明原因，比如权限拒绝或者目录索引被禁止，比猜快十倍。

用命令行直接请求一次，看响应头里的服务标识和返回体特征，也方便贴给别人。

在配置里搜这条路径相关的 location、try_files、deny 规则，一处一处对，别跳着看。

改动顺序与复测

能回退的改动，才敢做，配置改错了影响面很大。

先改最可能的一条，别同时改三处，改完才知道是哪条起效。

改完重载配置，再测同一地址，别测首页就算过。

连测三次确认稳定，再把改动写进变更记录，下次同类问题直接查记录。

改对了，页面才真的能打开。