ASP.NET Web API 经URL传长base64url编码JWT时直接返回400错误

请求未触发任何自定义业务代码就直接返回400，本质是请求在进入ASP.NET托管管道、执行Web API路由匹配之前，就被IIS/ASP.NET的原生请求拦截规则阻断了，和你编写的业务代码、路由配置逻辑完全无关。

• 配置层级不匹配导致URL长度限制未生效
  你目前修改的<system.web><httpRuntime maxUrlLength="10000"/>是经典管道模式下CLR层面的配置，在IIS 7+的集成管道模式下，这个配置对IIS原生请求过滤模块完全无效。
  IIS原生的请求过滤模块运行在内核层，不经过CLR，默认对整个URL长度的限制是260字符，只要触发这个限制就直接返回400，不会加载对应的应用程序池、不会执行任何托管代码。这和你的观察完全吻合：裁剪后的短令牌长度在260字符限制以内，能顺利穿过原生过滤层进入业务逻辑流程；完整长令牌触发长度限制后直接被拦截，自然看不到任何自定义逻辑的执行痕迹。
• URL字符触发原生过滤规则
  Base64url编码的JWT如果在传输过程中出现以下情况，会被直接拦截：
  • 字符串混入未转义的路径分隔符/，破坏原有路由结构
  • 出现双重转义的字符序列（比如字符被客户端错误编码两次，解码后包含非法的%序列）
  • 包含IIS默认拦截的未编码保留字符（如&、?、#等）
• 路径特殊字符的预处理拦截
  JWT本身包含.作为格式分隔符，ASP.NET在预处理阶段会把包含.的路径段识别为静态文件请求，如果路径不匹配静态文件处理规则，也会直接返回400，不进入Web API路由流程。

• 补充原生模块的配置放开限制
  在web.config的<system.webServer><security>节点下补充配置，覆盖IIS原生过滤模块的默认规则：

  <system.webServer>
    <security>
      <requestFiltering>
        <!-- 匹配放宽后的URL长度限制 -->
        <limits maxUrl="10000" maxQueryString="2048"/>
        <!-- 关闭双重转义拦截，避免JWT编码被误判 -->
        <allowDoubleEscaping enable="true"/>
      </requestFiltering>
    </security>
  </system.webServer>
  

• 快速确认拦截来源
  用Fiddler抓取400响应的响应头，如果Server字段仅显示Microsoft-IIS/10.0，没有附带ASP.NET版本标记，即可确认请求被IIS原生模块直接拦截，未进入托管管道。
• 从架构层面规避兼容性问题
  不要把JWT作为固定路径段传参，优先将JWT放到请求头Authorization中传输，从根源上规避URL长度、特殊字符拦截的问题；如果必须通过URL传递令牌，建议将令牌放到查询字符串中，而非路径段内，降低路径解析的兼容风险。

内容的提问来源于stack exchange，提问作者altaaf.hussein