nginx“默认拒绝”实为请求未匹配任何location块而落入兜底行为。需通过debug日志查$uri确认实际匹配路径，用nginx -t验证配置是否生效，排查优先级、斜杠、编码、嵌套等匹配陷阱，并设置明确兜底location。
请求被“默认拒绝”，通常不是 Nginx 主动拦下了你，而是它根本没找到能处理这个请求的 location 块，最后落入了 server 块的默认行为——比如返回 404，或更隐蔽地交由 root 目录下的 index 文件响应（若存在），甚至触发 try_files 循环。排查重点不是“谁拒绝了它”，而是“谁本该接住它却没出现”。
确认请求实际匹配到了哪个 location
别看配置写了啥，要看 Nginx 真正选了谁：
- 开启
info或debug日志，在log_format中加入$uri和$request_uri，例如：log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$request_uri" "$uri"'; - 用
curl -I /your/path发起一次请求，查 access.log，看$uri值是否和你预期的 location 路径一致 - 如果
$uri是/api/user，但日志里显示它进了location /，说明你写的location /api根本没被命中——可能被更高优先级规则截断，也可能压根没加载
检查 location 是否真的被加载且未被覆盖
配置写了不等于生效了：
- 运行
nginx -T（大写 T），输出当前全部生效配置，搜索你的目标路径，确认该location块确实存在、拼写正确、没有被注释掉 - 注意嵌套结构：如果它在
if块、map块或错误的server块里，Nginx 会直接忽略 - 检查是否有更高优先级的
=或^~规则提前终结了匹配链，导致你的正则或普通前缀 location 根本没机会参与竞争
验证是否存在“空匹配”陷阱
有些请求看似有路径，实则因 URI 归一化被悄悄改写：
- 请求
/static//logo.png（双斜杠）会被 Nginx 自动规范化为/static/logo.png，如果你只配了location /static/，它能匹配；但若配的是location /static（无尾斜杠），就可能因长度判断失效而落到location / - 请求带编码字符如
/path%2Fsub，$uri中是解码后的/path/sub，但配置中若用正则匹配原始字符串，需用$request_uri - 结尾斜杠不一致：请求
/admin和配置location /admin/不匹配；反之亦然。建议对目录类路径统一加尾斜杠，并用alias显式指定路径
补上兜底逻辑，避免“无处可去”
没有显式 location 匹配时，Nginx 默认使用 location /（如果存在）或直接返回 404。这不是安全，是不可控：
- 在
server块开头或末尾，加一个明确的兜底location /，并配上return 404或deny all，让“没匹配到”变成可预期的行为 - 如果依赖
try_files，确保最后一项是真实存在的文件，或由另一个精确location =块接管，否则容易陷入内部重定向循环 - 对 API 接口等关键路径，优先用
location = /api/v1/users这类精确匹配，避免因路径微小差异（如多一个斜杠、少一个参数）就掉出匹配范围
