.NET 5 WebApi部署本地IIS后Swagger测试抛417错误，IIS Express正常

417 Expectation Failed 错误的核心触发逻辑为：服务端无法满足客户端请求携带的Expect: 100-continue请求头的交互要求。结合IIS Express运行正常、正式IIS部署后全接口报417的场景，常见触发原因和排查路径如下：

• 应用池配置不匹配
  .NET 5为跨平台自宿主运行时，部署到IIS时如果选择了带.NET Framework托管模式的集成/经典应用池，请求管道会自动对请求头做二次处理，和Kestrel本身的请求处理逻辑冲突，直接拦截携带Expect头的请求返回417。
  正确配置要求：为站点分配无托管代码模式的应用池，不要绑定旧版本.NET Framework的托管管道。
• IIS请求筛选规则拦截
  IIS自带的请求筛选模块默认对请求头长度、内容长度有阈值限制，当Swagger发出的请求携带的Expect头长度超过阈值时，模块会直接触发417拦截，不会将请求转发给后端的Kestrel进程。
  可通过修改站点根目录web.config中security/requestFiltering节点的maxAllowedContentLength参数，调整请求内容的允许阈值，验证是否为规则拦截导致的问题。
• 系统级代理的请求头追加干扰
  本地系统如果开启了全局代理，Swagger前端发出的请求会先经过本地代理转发到IIS站点，代理会自动追加Expect: 100-continue请求头，而IIS上的ASP.NET Core模块没有正确适配该头的处理流程，就会返回417。
  排查时可临时关闭系统全局代理，重新测试Swagger的接口请求是否正常。
• IIS反向代理模块的头处理异常
  如果站点配置了ARR反向代理、URL重写等模块，这类旧模块对100-continue的协议支持存在兼容性问题，无法正确完成请求头的交互流程，会直接返回417。

可通过临时在请求管道中过滤Expect头的方式快速验证问题根源，参考代码：

// 在Startup.cs的Configure方法中添加全局请求中间件，过滤异常请求头
app.Use(async (context, next) =>
{
    context.Request.Headers.Remove("Expect");
    await next();
});

如果添加该中间件后417错误消失，即可确认是请求头处理逻辑不匹配导致的问题，再针对性调整IIS侧的配置即可。

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