Nginx未匹配location时不会自动返回404，而是落入默认location /或按try_files查找文件；需显式配置末尾的location / { return 404; }兜底，或用try_files $uri $uri/ =404实现文件级404。
Nginx 在没有 location 匹配到请求路径时，**并不会自动返回 404**，而是会落入默认的 location /（如果存在），或使用 server 块中定义的 root + try_files 规则去尝试查找文件。若最终没找到资源，才可能返回 404——但这不是“匹配失败”的显式响应，而是文件查找失败的结果。
明确捕获“无 location 匹配”情况
想让所有未被任何 location 显式覆盖的请求，统一返回 404（或其它状态码），必须主动配置一个兜底规则：
- 在所有其他
location块之后，添加一个最长前缀匹配的location /，并在其中用return 404 - 确保它放在配置末尾，避免被更具体的规则（如
location /api/、location ~ \.php$）覆盖 - 示例：
location / {
return 404 "Path not configured";
}
配合 try_files 实现更可控的 404
如果你希望先尝试找真实文件，找不到再返回 404（比如服务静态资源），推荐用 try_files：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
-
try_files $uri $uri/ =404;表示：先查文件，再查目录，都不行就立即返回 404 状态（不走任何页面或重定向） - 这个写法比单纯
return 404更符合常规 Web 服务逻辑，尤其适合前端 SPA 或静态站点 - 注意：=404 中的等号表示终止处理并返回原始状态码，不是跳转
避免常见陷阱
以下情况会导致你以为“没匹配却没返回 404”，实际是配置干扰了预期行为：
-
location /被更早的正则 location（如location ~ ^/.*$）意外匹配，导致兜底失效 - server 块里漏写了
root，而location /内又没设root或alias，Nginx 不知道从哪找文件，可能报 403 或空响应 - 用了
proxy_pass却没配proxy_intercept_errors on，后端返回的 404 被透传，Nginx 的error_page 404不生效
需要返回 JSON 格式的 404 怎么办
如果业务要求返回结构化错误（如 API 场景），不能只靠 return 404，得结合 error_page 和内部 location：
- 在 server 块中加：
error_page 404 = /_404_json; - 再定义：
location = /_404_json {
internal;
add_header Content-Type "application/json; charset=utf-8";
return 404 '{"code":404,"message":"Not Found","path":"$request_uri"}';
} - 注意：
=表示保持状态码；internal防止用户直接访问/_404_json
