.NET Core 3.1默认路由在IIS环境失效，fallback异常触发问题

我来帮你梳理这个本地正常、IIS部署后默认路由失效的问题，结合你描述的细节，咱们从几个关键方向逐一排查：

一、先聚焦IIS配置的核心差异 #

1. 检查web.config的URL重写规则 #

IIS的URL重写模块很可能无意中干扰了路由匹配。打开你的web.config，重点看<rewrite>节点下的规则：

<rewrite>
  <rules>
    <!-- 示例规则，检查是否有改写默认路由路径的情况 -->
    <rule name="HTTP to HTTPS" stopProcessing="true">
      <match url="(.*)" />
      <conditions>
        <add input="{HTTPS}" pattern="off" ignoreCase="true" />
      </conditions>
      <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" />
    </rule>
  </rules>
</rewrite>

• 确认规则没有把/fr/Home/Index这类路径篡改（比如误加前缀、截断路径）
• 检查是否存在其他规则会优先匹配默认路由的路径，导致请求没走到端点路由

2. 验证应用程序池配置 #

IIS应用程序池的错误配置是这类问题的高发区：

• 打开IIS管理器，找到站点对应的应用程序池，确认**.NET CLR版本设置为无托管代码**（.NET Core应用必须用这个模式）
• 确认托管管道模式为集成，经典模式会导致路由逻辑异常
• 尝试重启应用程序池，清除可能的缓存问题

二、端点路由本身的排查 #

1. 确认路由注册顺序与约束逻辑 #

虽然你提到调试显示优先级正常，但可以再验证两点：

• 检查Startup.cs中UseRouting()和UseEndpoints()的顺序：UseRouting()必须在UseEndpoints()之前，且要放在UseStaticFiles()等中间件之后
• 临时移除lang约束，测试/Home/Index是否能正常匹配。如果可以，说明是约束在IIS环境下的解析问题——比如IIS修改了请求头（如Accept-Language），导致约束不生效

2. 添加路由调试日志 #

在UseEndpoints中添加一个调试端点，输出请求的路由匹配细节，部署到IIS后访问验证：

app.UseEndpoints(endpoints =>
{
    // 保留你原有的路由配置...
    
    // 添加调试端点
    endpoints.MapGet("/debug-route", async context =>
    {
        var routeData = context.GetRouteData();
        var requestPath = context.Request.Path;
        await context.Response.WriteAsync($"请求路径: {requestPath}\n路由数据: {System.Text.Json.JsonSerializer.Serialize(routeData?.Values)}");
    });
});

访问/debug-route和/fr/Home/Index，查看输出的路由数据，确认lang参数是否被正确解析，路由是否命中了默认路由的规则。

三、环境与配置差异排查 #

• 对比本地和IIS的ASPNETCORE_ENVIRONMENT环境变量：如果IIS用的是Production环境，检查appsettings.Production.json中有没有修改路由相关的配置
• 检查IIS站点的物理路径是否正确，有没有指向错误的发布目录导致路由配置未加载

四、额外验证点 #

• 确认IIS服务器已安装对应版本的.NET Core托管捆绑包（.NET Core 3.1的托管包），缺失托管包会导致路由逻辑异常
• 尝试在IIS中启用失败请求跟踪，捕获请求的完整处理流程，看请求是在哪一步被导向fallback路由的

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