这种情况我之前处理过好几次，核心是Nginx的配置规则优先级或者隐性限制在起作用，咱们从几个常见方向拆解原因：

1. 高优先级的Location规则拦截 #

Nginx的Location匹配有严格的优先级顺序：精确匹配（=）> 前缀匹配（^~）> 正则匹配（~）> 普通前缀匹配。如果你的配置里存在其他针对/v1/doesnotwork的规则，比如：

location ^~ /v1/doesnotwork {
    deny all;
}

这类规则会比你的正则匹配（~ ^/v1/doesnotwork/(.*)$）先被匹配到，直接触发deny all导致请求被禁止。建议用nginx -T命令输出完整配置（包括所有引入的子配置文件），全局搜索doesnotwork相关的规则。

2. Server/Http级别的全局访问控制 #

检查Server块甚至Http块中是否存在基于请求URI的条件判断规则，比如：

if ($request_uri ~* /v1/doesnotwork) {
    deny all;
}

这类if规则会在Location匹配之前生效，直接拦截符合条件的请求，日志里就会显示access forbidden by rule。

3. 第三方安全模块的拦截 #

如果你的Nginx安装了ModSecurity、Naxsi这类安全模块，可能模块规则库中把doesnotwork标记为了恶意路径关键词，自动拦截了请求。可以临时禁用安全模块测试，或者检查模块的规则配置。

4. 本地文件路径的权限问题（静态资源场景） #

如果这个Location是指向本地文件目录而非代理后端服务，要检查doesnotwork对应的目录/文件权限：Nginx运行用户（通常是nginx或www-data）是否有读取权限。不过这种情况日志一般会显示permission denied，但也不排除个别场景下被归类为规则禁止。

快速排查步骤 #

• 执行nginx -T导出完整配置，全局搜索deny、doesnotwork、request_uri关键词，定位可疑规则；
• 临时将Location内的配置替换为return 200 "test";，测试是否还会返回403，排除后端服务的影响；
• 检查Nginx运行用户对目标路径的权限（静态资源场景）。

内容的提问来源于stack exchange，提问作者Manojkumar Khotele