ASP.NET Core 6部署Azure App Service遇.dd结尾URL路由404问题

这个问题和ASP.NET Core代码逻辑无关，是Azure App Service Windows宿主前端的IIS反向代理层默认拦截规则导致的：
本地开发时直接通过Kestrel运行项目，所有请求直接进入应用路由管线，所以所有路径都能正常响应。部署到Azure App Service（Windows计划）时，平台默认用IIS做反向代理，请求会先经过IIS的处理逻辑再转发给应用，IIS默认有两个规则会提前拦截请求：

• 静态文件优先匹配：如果请求路径的后缀在IIS已注册的MIME静态文件映射列表里，IIS会先去站点物理目录下查找对应文件，找不到就直接返回404，不会把请求转发给Kestrel
• 旧版8.3短文件名兼容逻辑：当路径最后一段符合单个任意字符 + 点 + 2个任意字符的格式时，IIS会触发Windows文件系统的短文件名匹配逻辑，直接查找物理文件，查找失败直接返回404，不进入后续转发流程

你访问的/resources/d.dd刚好同时命中两个规则：.dd在Azure App Service默认IIS的MIME映射列表中，且路径最后一段完全符合短文件名格式，所以请求根本没到你的应用，直接被IIS返回了默认404页。
你测试的其他路径不触发问题的原因完全对应规则：

• 带末尾斜杠的/resources/d.dd/：路径最后一段为空，不触发文件匹配逻辑
• 后缀为.vn等其他顶级域后缀：不在默认MIME静态映射列表里，IIS直接放行转发
• 前缀更长的/resources/hello.dd：不符合短文件名1字符前缀的格式要求，不触发短名校验
• 后缀3个字符的/resources/d.ddd、/resources/d.txt：不满足2字符后缀的短名校验规则，IIS正常转发

按优先级从高到低选择方案即可：

方案1：配置web.config让所有请求由ASP.NET Core接管（推荐） #

Web API项目不需要IIS处理静态文件，直接让ANCM（ASP.NET Core Module）接管所有请求是最彻底的解决方式，后续也不会再遇到其他后缀被拦截的问题。
在项目根目录创建或修改已有的web.config文件，写入如下配置：

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <!-- 移除默认静态文件、目录浏览处理器 -->
      <remove name="StaticFile" />
      <remove name="DirectoryBrowse" />
      <!-- 配置ANCM处理所有请求 -->
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
    </handlers>
    <!-- 替换成你自己的项目入口dll名称 -->
    <aspNetCore processPath="dotnet" arguments=".\YourProject.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" />
    <security>
      <requestFiltering>
        <!-- 清空后缀拦截规则，允许所有后缀的请求 -->
        <fileExtensions allowUnlisted="true" applyToWebDAV="false">
          <clear />
        </fileExtensions>
      </requestFiltering>
    </security>
  </system.webServer>
</configuration>

将该文件随项目发布到Azure App Service后即可生效。

方案2：单独映射.dd后缀，保留IIS静态文件能力 #

如果你需要IIS处理站点下的静态资源，可以只针对.dd后缀做配置覆盖，在web.config的<system.webServer>节点下添加如下内容：

<staticContent>
  <!-- 先移除默认的.dd后缀映射避免重复添加报错 -->
  <remove fileExtension=".dd" />
  <!-- 重新配置后缀映射，不触发静态文件查找拦截 -->
  <mimeMap fileExtension=".dd" mimeType="application/octet-stream" />
</staticContent>

方案3：调整路由规则规避拦截 #

如果不想修改服务器配置，也可以调整端点路由格式，比如在id参数段后增加固定后缀、强制要求末尾斜杠等，但这种属于临时规避方案，后续遇到其他符合规则的路径还是可能出问题，不推荐使用。

发布完成后可以直接访问/resources/d.dd测试，也可以通过响应头判断：如果响应头中存在Server: Kestrel字段，说明请求已经成功转发到你的应用，不会再出现IIS默认的404提示。

内容的提问来源于stack exchange，提问作者Thai Anh Duc