.NET Core Razor Pages 大文件/视频上传返回400错误，OnPostAsync未触发

断点未触发OnPostAsync方法，说明请求根本没有进入应用的业务处理管线，拦截动作发生在请求进入业务逻辑之前的前置校验环节，与业务代码、数据库存储逻辑无直接关联。

常见拦截诱因与对应排查点 #

• 多层级请求大小限制的配置漏配、错配
  大文件上传的请求大小限制是分多层独立生效的，单独修改某一层的配置无法解决问题：
  • Kestrel服务器层默认限制请求体最大为28.6MB（约30MiB），这个限制的拦截优先级高于IIS配置、页面特性标注，哪怕在web.config里放开了IIS的上传限制，只要请求体积超过Kestrel的默认阈值，就会被直接拦截返回400，根本不会传递到后续管线。
    • 之前尝试在启动配置加规则时报错，大概率是混淆了.NET版本的配置写法：.NET 6+采用最小托管模型时，Kestrel的配置需要直接在WebApplicationBuilder阶段配置，示例代码：
      builder.WebHost.ConfigureKestrel(options => options.Limits.MaxRequestBodySize = 500 * 1024 * 1024);
      抄用旧版Startup类的配置写法会导致找不到对应配置对象报错。
  • web.config中的上传配置需要核对参数单位：maxAllowedContentLength节点的参数单位是字节，不是MB，比如要支持300MB文件上传需要设置为314572800，误写为300会导致实际限制变成300字节，直接拦截所有大文件。同时要确认requestLimits节点配置在system.webServer/security/requestFiltering路径下，放错配置层级会导致规则不生效。
  • multipart表单解析层有独立的大小限制：服务端默认将multipart格式请求的最大总长度限制为128MB，哪怕Kestrel、IIS层放开了限制，只要multipart请求总长度超过这个默认值，就会在解析请求体的环节被拦截。需要在服务配置中单独调整FormOptions的对应参数，示例：

    services.Configure<FormOptions>(options => 
    {
        options.MultipartBodyLengthLimit = 500 * 1024 * 1024;
        options.ValueLengthLimit = int.MaxValue;
    });
    

• 请求大小限制特性的使用位置错误
  很多开发者对MVC/Razor Page的限制特性生效范围存在误解：
  • [RequestSizeLimit]特性需要标注在页面处理方法/Action上，标注在承载上传文件的模型属性上根本不会被框架识别，自然不会生效。
  • [MaxFileSize]特性仅用来校验单个上传文件的体积，不会限制整个请求体的总大小，如果请求总大小（包含表单其他字段、multipart格式的结构开销）超过了服务器层的全局限制，哪怕单个文件符合[MaxFileSize]的阈值要求，依然会被前置校验拦截。
• 表单基础配置缺失
  标准file上传控件需要配合<form>标签上的enctype="multipart/form-data"属性才能正常提交，如果遗漏了这个属性，浏览器会以默认的url编码格式提交文件内容，服务端在解析请求体时会直接判定格式异常，返回400状态码，根本不会触发后续的模型绑定和OnPostAsync方法。
• 上游网络层的默认拦截
  如果应用部署在反向代理、API网关、CDN等上游网络节点之后，这些节点自身也有默认的请求体大小限制（比如Nginx默认限制为1MB），这类拦截发生在请求到达应用服务器之前，应用的日志中不会留下请求记录，断点自然不会被触发。
• 前置安全校验拦截
  Razor Page/MVC框架会在进入业务方法之前执行防伪令牌（Antiforgery）校验，如果提交的请求没有携带有效的防伪令牌（自定义提交逻辑漏传了__RequestVerificationToken字段），框架会直接返回400状态码，不会执行后续的业务逻辑。

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