ASP.NET Core接口Token验证通过却返回404状态码的原因分析

安全阿岳

2026-5-7

分析与解决方案

这问题确实有点费解——明明日志显示请求已经被识别、令牌验证成功，你的代码逻辑里也只返回200或500，却偶尔出现404。我来梳理几个最可能的原因，以及对应的排查方向：

1. 方法根本没被执行（路由匹配后被拦截）

先给你的MyMethod第一行加个日志，确认方法是否真的被触发：

_logger.LogInformation("Entered MyMethod successfully");

如果返回404时这条日志没出现，说明请求虽然匹配到了路由，但在进入方法执行前就被拦截了。大概率是全局过滤器/中间件搞的鬼：

检查有没有自定义的ActionFilterAttribute、IAsyncActionFilter或者全局中间件，在授权验证后、方法执行前的环节，存在返回404的逻辑（比如某些权限二次校验、请求参数校验的自定义逻辑写错了）。
排查模型绑定相关的全局配置：虽然你的方法没有参数，但如果客户端发送的application/x-www-form-urlencoded数据有无法解析的内容，某些自定义模型绑定器可能错误地返回404（正常应该返回400）。

虽然你标注了[HttpPost("my-method")]，但还是可能存在路由冲突：

检查其他控制器中是否有同名的[HttpPost("my-method")]路由，ASP.NET Core可能在某些并发场景下优先匹配了另一个端点，而那个端点可能被禁用或者不存在实际实现（导致返回404）。
确认路由大小写匹配：如果你的应用手动开启了路由大小写敏感（默认不敏感），而客户端偶尔发送了大小写不一致的请求（比如/My-Method），可能导致匹配异常。
检查控制器的路由前缀：如果你的控制器上有[Route("api/[controller]")]这类前缀，实际路由应该是api/xxx/my-method，但日志里的请求是/my-method——不过日志显示令牌验证成功，说明前缀应该没问题，但还是要确认。

如果你的应用部署在反向代理（比如Nginx、IIS）后面，可能存在路由转发的问题：

检查反向代理的配置，确保请求的URL被正确转发到应用，没有被重写或截断。比如某些代理会把POST /my-method重写成其他路径，导致应用端收到的路径不对，但日志可能记录的是代理前的URL。
确认是否正确配置了ForwardedHeadersOptions，如果应用依赖反向代理传递的头信息来解析路由，配置错误可能导致路由匹配异常。

某些特定版本的ASP.NET Core存在端点路由的偶发Bug，比如授权验证通过后端点未被正确执行的情况。如果你用的是较旧的版本（比如.NET 6的早期版本），建议升级到对应分支的最新补丁版本，看看问题是否消失。

内容的提问来源于stack exchange，提问作者Tao Gómez Gil