首先要确认404是Nginx自身返回还是透传后端响应；若access log中$location为空，说明未匹配任何location；需重点检查location优先级、末尾斜杠一致性及proxy_pass路径拼接逻辑。
遇到 Nginx proxy_pass 转发后返回 404，首先要确认：这个 404 是 Nginx 自己返回的（说明请求根本没匹配到任何 location），还是透传了后端的真实响应（说明 location 匹配成功但后端拒绝）。检查 location 匹配是否生效，是定位的第一步。
看 access log 确认是否命中 location
Nginx 的 access log 会记录每条请求最终使用的 location。确保你的 log format 包含 $location 变量（需在 http 块中定义）：
log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for" "$location"';
然后查日志：
grep "404" /var/log/nginx/access.log | tail -10
如果某行显示 "$location" 为空或为 "-"，说明该请求没匹配到任何 location —— 很可能路径写错了、server 块监听不对，或被更高优先级的 location 截获。
验证 location 匹配逻辑是否符合预期
不要依赖“写在哪就用哪个”，Nginx 的匹配是按优先级自动选的。重点核对三类情况：
-
精确匹配（=）优先级最高：比如写了
location = /api，那/api/或/api/users都不会命中它，只会走其他前缀或正则规则 -
前缀匹配选最长：请求
/api/v2/users时，location /api/v2/比location /api/优先；但若只写了location /api（无尾斜杠），它会错误匹配到/api-docs这类非预期路径 -
^~ 阻断正则检查：如果用了
location ^~ /static/，即使后面还有location ~ \.js$，只要 URI 以/static/开头，就不会再进正则分支
用 curl 模拟请求，观察实际转发路径
临时加一条最简 location 测试匹配行为：
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
location /test-match { return 200 "matched: $uri\n"; }
访问 curl -v http://your-domain/test-match/hello，看返回内容和状态码。如果返回 404，说明连这个基础 location 都没匹配上，问题出在 server 块范围、listen 端口、server_name 或请求 Host 头不一致。
再把测试路径换成你真正要代理的路径，比如 /api/users，配合 return 200 "$uri → $request_uri → $location"，能直观看到 Nginx 解析后的 URI 和最终选中的 location。
检查 proxy_pass 是否因斜杠导致 location 实际未触发
一个常见陷阱：location 写了 /api/，但 proxy_pass 写成 http://backend（无斜杠），此时 Nginx 仍会匹配 location，但转发路径变成 http://backend/api/users —— 后端 404 不代表 location 失效，而是路径拼错了。反过来说，如果 proxy_pass 写成 http://backend/（有斜杠），而 location 是 /api（无斜杠），Nginx 会把整个 /api/users 替换为 /users，也可能导致后端收不到预期路径。
简单判断法：只要 proxy_pass 目标地址末尾有斜杠，且 location 以斜杠结尾（如 /api/），转发才大概率正确剥离前缀；否则务必手动验证转发结果。
