上传失败不是一处配置项的问题，而是链路中某一层先拦截了请求。调高某一个地方的上限，其他的地方没有同步调整的话，错误依然存在，只会使排查的时间变长。
按照请求的顺序一层层进行验证。反向代理层的请求体限制决定了是否可以接收，超时参数决定大文件是否可以上传完成，临时目录所在的分区不够大就会造成写入失败。脚本运行环境还有自己的上限，单文件大小、表单总量、内存占用、最大执行时间这四项要一起调整，任何一项偏小都会中断传输。应用服务器和框架也有各自的报文长度限制，容器化部署的时候还要检查网关以及入口控制器的默认值。
前端也要进行确认。表单提交方式、请求超时、进度提示都会影响到实际体验，几百兆的文件通过一次请求上传，即使后端开放了，也很容易在中间链路断开。
错误代码可以用来作为排查问题的线索。请求体过大一般会返回一个明确的错误状态码，而网络关闭或者超时的情况下则会表现为连接断开，根据这些现象来判断出卡在哪里，比逐个修改更高效。
长远的方法就是减少单次请求的依赖。分片上传把文件分成若干小块，一块块地提交给服务器进行合并，如果某一块失败了只需要重新上传这一块就可以了，配合断点续传功能可以在网络不稳定的情况下继续传输。更彻底的方式是直传对象存储，由服务端签发临时凭证，浏览器直接写入，应用服务器只负责登记元数据，请求体不再经过业务进程。
放开限制的同时要配套相应的安全措施。根据扩展名和文件头来判定文件类型，设置单文件、单用户的总量上限，限制并发分片数，对异常频繁上传的行为进行速率控制，防止存储容量被滥用。
完成之后用真实的大文件进行回归测试，在不同的网络环境和终端上运行，确保每一层的日志里都没有被截断的情况。