先确认状态码#

1
curl -I https://blog.tjcheng.cn/posts/demo/

浏览器页面可能被前端路由或错误页包装，curl -I 能直接看到服务器返回状态。

404 的常见原因#

• 构建产物里没有对应 HTML。

• Nginx root 指向了错误目录。

• 静态站路径需要 try_files，但配置没有回退到 index.html。

• URL 末尾斜杠和实际生成路径不一致。

403 的常见原因#

• 文件或目录权限不足，Nginx 用户读不了。

• 访问的是目录，但没有 index 文件。

• 配置中禁止访问某些路径。

• SELinux 或安全策略限制，具体看系统环境。

看日志#

1
nginx -t
2
tail -n 50 /www/wwwlogs/blog.tjcheng.cn.error.log
3
ls -lah /www/wwwroot/blog_app/blog_web_app/dist

错误日志通常会明确写 permission denied 或 No such file or directory，比猜测快得多。

实战复盘#

使用《Nginx 404 与 403 排查》时，我会先确认环境边界：本地还是服务器，Windows 还是 Linux，开发环境还是线上环境。很多命令本身没错，但换了系统或权限就会得到完全不同的结果。

修复后不要只看报错消失，还要做业务层验证。比如端口释放后服务是否重新启动，缓存清理后页面是否显示新内容，pip 安装后目标环境是否真的能 import。

排查记录的质量取决于可复现性。只要别人能按文章从现象走到验证，这篇文章就不是临时笔记，而是一张可靠的操作卡片。

最小验收样例#

验收《Nginx 404 与 403 排查》时，我会保留一条修复前命令和一条修复后命令。前者证明问题存在，后者证明问题已经消失，而不是只凭浏览器或终端感觉判断。

如果这篇文章涉及服务器操作，还要记录当前路径、用户、服务名和关键配置文件。排查记录越能还原现场，下次遇到同类问题越不需要重新摸索。

小结#

Nginx 排查要先区分 404 和 403。一个查路径和构建产物，一个查权限和访问规则。