.NET Core 6 API部署后Swagger正常但接口返回404问题排查咨询

1. 核对路由前缀配置 #

本地请求无虚拟路径，部署后URL带有/Services/Myservice前缀，需确认API是否配置了对应路径基准：

• 在Program.cs中添加app.UsePathBase("/Services/Myservice")，确保应用识别该前缀并正确解析后续路由。

2. 验证IIS核心配置 #

• 确认站点物理路径指向API发布后的wwwroot目录，而非项目源码根目录。
• 应用程序池的**.NET CLR版本**需设置为无托管代码，适配.NET Core的无托管运行模式。
• 检查服务器是否安装ASP.NET Core托管捆绑包（ASP.NET Core Hosting Bundle），缺少该模块会导致IIS无法将请求转发给.NET Core应用。

3. 检查控制器路由匹配逻辑 #

控制器路由为[Route("[controller]")]，动作路由为[HttpGet("{listName}/Item/{id}")]，完整路由应为/List/{listName}/Item/{id}，结合部署后的虚拟路径，需确认：

• 动作上的HttpGetAttribute可简化为[HttpGet]，避免属性使用方式可能引发的匹配问题。
• 新增简单测试动作（如[HttpGet("test")]），请求https://myserver.mydomain.ca/Services/Myservice/List/test，验证基础路由是否正常，排除参数匹配干扰。

4. 启用路由调试日志定位问题 #

在appsettings.json中添加日志配置，开启路由调试级别的日志输出：

{
  "Logging": {
    "LogLevel": {
      "Microsoft.AspNetCore.Routing": "Debug"
    }
  }
}

部署后查看应用日志（可通过dotnet trace工具或IIS的stdout日志），确认请求是否进入路由匹配流程，以及匹配失败的具体原因。

5. 排查IIS重写规则与模块 #

• 检查站点的URL重写规则，确保未拦截或篡改API请求路径。
• 若未使用自定义重写逻辑，无需额外配置URL重写模块，避免干扰ASP.NET Core模块的请求转发。

6. 确认应用正常启动 #

• 查看IIS应用程序池状态是否为“运行中”，排查意外停止情况。
• 查看应用的stdout日志（默认在站点根目录logs文件夹，可在IIS管理器的“ASP.NET Core”模块配置日志路径），确认启动过程无依赖缺失、配置读取失败等报错。
• 在服务器本地通过dotnet YourApi.dll直接启动应用，用localhost:端口/List/ListXYZ/Item/270访问，验证应用本身是否正常，排除IIS转发环节问题。

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