文件明明在服务器目录中，访问静态资源仍返回404。对Nginx来说，关键是请求URI最终映射到了哪一个磁盘路径。
先确认请求命中了哪个location，再区分root与alias。两者构造路径的方式不同。
确认请求和命中的配置
记录实际访问的URI、响应状态以及对应虚拟主机。执行sudo nginx -T查看完整生效配置，并在访问日志和错误日志中找对应请求。一个更具体的location或正则匹配可能改变实际处理路径。
在变更前用ls -l或namei -l检查目标文件及上级目录。文件存在也不等于Nginx工作进程有权限穿过每一级目录。
root和alias分别怎样构造文件路径
官方文档中的root会把完整请求URI附加到根目录；alias则用指定目录替换匹配到的location前缀。例如location /assets/ { alias /srv/site/static/; }会把/assets/app.css指向/srv/site/static/app.css。
检查前缀和目录末尾的斜杠是否与示例关系一致。不要把root的路径拼接方式照搬到alias。
只改实际错误的映射
若当前配置写成location /assets/ { alias /srv/site/static; }，要按预期文件路径重新核对尾部斜杠与目录名称。修改后执行sudo nginx -t，通过语法检查再执行sudo nginx -s reload。
先保存原配置并确认已有会话仍可访问。语法通过只说明配置可解析，并不能证明资源路径或权限正确。
用具体URL验收而非只看首页
请求一条实际存在的静态文件和一条不存在的路径，对比状态码、内容类型与错误日志。若仍是404，检查是否被其他location、try_files或上游代理接管。
如果响应变为403，重点转向目录遍历权限、文件权限或访问控制；不要把403和路径不存在混作同一个问题。
VPS迁移目录时的注意点
更换实例或发布目录时，路径和权限都要重新核对。萤光云与LightNode可用于独立复现配置；在生产机上重载前，先验证目标目录与回退配置。
FAQ
问：nginx -t通过，为什么还会404？答：它主要检查配置语法与可打开的相关文件，不会替你验证每个URI的映射结果。
温馨提示
温馨提示：静态目录若位于用户家目录，还需检查父目录可遍历性与额外访问控制，避免为修复404而盲目放宽全局权限。
