上传大附件被挡在413，报错为什么在浏览器里看不明白

上传大附件时被网关挡下返回413，浏览器里之所以看不明白，是因为这条限制在请求进入应用之前就已生效：承担反向代理的那一层读完请求头里的体积就决定放不放行，程序没有机会接管这次请求，也就没法返回站内统一格式的错误说明。用户看到的往往是一个空白页或一段没有上下文的提示，而不是「哪一个文件超限」。

上限管的是哪一段

它管的是整个请求体的体积，不是单个文件大小。表单里同时带上附件、字段和令牌时，这些内容会合并计算，所以「明明没到限制却被挡」常常是别的字段把体积顶上去了。

反向代理层给的默认值并不高，nginx 的对应指令默认在一兆这个量级，且可以在整站、单个站点和单个位置三段分别覆盖。也就是说，同一个站点里上传入口和接口入口完全可以有不同上限，配置时按入口分开设，比整站拉高更稳。

为什么报错在浏览器里读不出来

超限响应由代理层直接给出，通常不带站内的页面模板，也不走前端的错误处理分支。前端脚本等待的是一个结构化返回，收到的却是一段最简响应，于是表现为进度条卡住、提示缺失或一直显示上传中。

要让它可读，得在两处配合：一是前端在提交前按体积做本地校验，把超限拦在发起请求之前；二是代理层之外的应用层也要有自己的上限，两级上限的关系是「应用层不高于代理层」，否则超限请求会先进入程序再被内部规则拒绝，报错信息才终于有站内格式。

站内三类上传入口怎么核对

站内的批量导入支持压缩包和表格两种形式，这类请求体积大、耗时长，只调一处上限经常出现「页面能传、接口不能传」。而通过接口上传附件时，文件内容会以 base64 编码形式放进请求体，编码本身会带来体积膨胀，按原始文件大小估算上限容易偏低。

部署时还有一处容易漏

程序默认监听 8001 端口，前面通常由反向代理转发。部署时要确认代理转发的那一段是否也受同一上限约束：多层代理时每层都要放开，只改最外层会出现换网络环境后时好时坏。同理，超时与体积是两类参数，只调体积不调超时，大附件仍然会在传输中途断掉。

常见问题

只改一处上限行不行？ 不行，代理层、应用层与前端校验是三处，只放开一处会把报错挪到更不好读的位置。

改完为什么还是失败？ 先看是不是超时不是体积；再看请求是否经过多层代理；最后核对接口与页面走的是不是同一段配置。

上传图片和上传附件要不要同一个上限？ 分开更合理，常规图片上限低、附件与导入包上限高，按路径分别覆盖比整站提高更安全。

编码内容上传要注意什么？ 编码后的请求体比原文件大，估算时留余量，并在日志里区分「被代理挡下」和「被程序拒收」。