部署IIS的Bot Framework机器人遇Skype频道RequestEntityTooLarge错误求助

我之前帮朋友排查过几乎一模一样的问题，结合Bot Framework和IIS的特性，给你几个实用的排查方向：

• 补全IIS底层的请求大小限制
  你只设置了ASP.NET层面的maxRequestLength（单位是KB），但IIS本身还有一个更底层的拦截规则：maxAllowedContentLength（单位是字节），这个配置在requestFiltering节点下，必须和maxRequestLength同时设置，否则IIS会先拦截超出限制的请求。
  在web.config里添加或修改这段配置：

  <system.webServer>
    <security>
      <requestFiltering>
        <!-- 设置为2GB，足够覆盖绝大多数场景 -->
        <requestLimits maxAllowedContentLength="2147483647" />
      </requestFiltering>
    </security>
  </system.webServer>
  

• 排查数据中心的代理/负载均衡限制
  数据中心的服务器通常会前置反向代理或负载均衡（比如Nginx、F5等），这些中间件也有自己的请求大小限制。比如Nginx的client_max_body_size默认可能只有1MB，即使IIS设置好了，代理层也会先返回413错误。联系运维团队检查这些设备的配置，确保它们的请求大小限制不低于你设置的IIS值。

• 检查Bot Framework SDK版本与通道交互细节
  旧版本的Bot Framework SDK可能存在隐性问题：比如某些场景下会重复封装消息内容，导致请求体积意外增大。尝试升级到最新的稳定版SDK（比如Bot Framework SDK v4的最新补丁版）。另外，虽然你的Hero Card和图片很小，但Skype通道在传输时会附加一些元数据，你可以用抓包工具看看实际发送的请求大小，确认是否真的是内容体积问题。

• 查看服务器日志定位具体原因
  打开Windows事件查看器（应用程序日志）和IIS的站点日志，里面会记录更详细的错误信息：比如具体是哪个请求触发了限制，请求的实际Content-Length是多少，甚至能看到是哪个模块拦截了请求。这些日志能帮你快速排除“假的”体积问题——比如可能是某个错误的请求格式导致的异常触发，而不是真的内容太大。

• 临时关闭IIS压缩测试
  少数情况下，IIS的动态压缩模块会对请求处理产生干扰，导致原本正常的请求被误判为过大。可以临时关闭站点的动态压缩功能，测试是否还会出现错误：

  <system.webServer>
    <urlCompression doDynamicCompression="false" />
  </system.webServer>
  

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