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