上传被拒返回 413，先改程序限制还是先改网关限制

上传附件被拒绝并返回 413 时，应该先改程序里的限制还是先改网关层的限制？先改网关层。413 这个状态码是「请求体太大」的入口层应答——网关在读请求头与请求体时就把它拦下了，请求根本没到程序，程序里的限制再宽也不会生效。网关文档的原文可以对照：请求体上限的默认值是一兆，请求里的体积超过配置值时向客户端返回 413，并且文档明确写了浏览器不能正确展示这个错误。

413 说明请求停在了哪一层

停在「读请求」这一层。常见的这一层有：站点前面的反向代理、CDN 或边缘节点、容器入口的网关配置、面板里给站点配的规则。

判断依据有两条。一条是应答来源：413 由谁返回，日志落在谁那里——程序访问日志里没有这条请求，就是入口层拦的。另一条是错误体形态：入口层返回的是它自己的默认错误页，样式和程序内的错误页不同。

这两条查清之后再动手改配置。跳过这一步直接改程序限制，是这类问题最常见的无效操作：改完重启、再传一次，仍然是 413。

浏览器为什么只显示连接出错

文档里那句「浏览器不能正确展示这个错误」说的是实际现象：用户上传到一半，页面只给出模糊的失败提示，看不出是体积问题。

这对排查有两个影响。第一，用户反馈通常不会说「返回 413」，而是说「传不上去」，所以要自己去看服务端状态码；第二，前端脚本拿到的响应可能不完整，靠界面提示定位不可靠。

顺带一个常见误判：这类失败看起来像超时或网络断了。区别在于体积——换个小的文件能成功，就是上限问题而不是链路问题。

三层限制的对照与改法顺序

站内的上传与导入限制通常分布在三层，各自管不同的东西：

顺序不能反的原因很简单：上面一层没过，下面几层根本没被执行。三层里只要有一层比目标值小，实际可用上限就是那个更小的值。

改的时候按「目标体积留余量」来配：入口层的值要大于程序层，程序层的值要大于业务里单次操作需要的值。反过来的配置会带来一种很难描述的现象——小文件正常、大文件报应用层错误，看起来像程序 bug。

批量导入大文件时的实际做法

AnQiCMS 支持批量导入文档，可以走 ZIP 压缩包和 Excel 表格两种方式。导入大压缩包时，链路上要过的就是上面三层。

可用的做法有四条，按成本从低到高排：

一是拆包。按栏目或按时间切成多个较小的包分次导入，不需要动任何配置，也不会把入口层的上限抬高。

二是先压内容再打包。附件与图片占包体的大部分，导入前把不需要保留在包里的资源单独走媒体上传，包体会小很多。

三是放开入口层上限。确认需要长期支持大包导入时再改，改完要同时看程序层的值，两层一起调才有意义。

四是走接口分批提交。AnQiCMS 提供 /api/import/archive 文档内容导入接口，还支持按标题查询是否已存在，批量场景按条或按小批提交，受上限影响的可能最低。

部署形态会影响改哪里的配置：AnQiCMS 的部署方式包括宝塔面板一键部署、LNMP 命令行部署与 Docker 镜像，服务默认监听 8001 端口，站点前面通常还有一层反向代理。用面板部署的，站点入口限制在面板的站点配置里；用镜像加自建代理的，限制在前置网关那份配置里；直接暴露服务端口的，才主要是程序自身限制。

改完之后要做一次实际验证：拿一个略小于目标值的文件走完整流程，而不是只看配置。

常见问题

把上限设为零是不是就没了限制？ 文档里设为零表示不做请求体检查，但这不代表后面几层也不检查：程序层与业务层的约束仍在。而且完全不检查请求体大小，会把内存与磁盘压力留给应用自己承担，不建议对公网入口这样配。

改了配置为什么还是失败？ 三种可能：改的对象不是当前生效的那一份（多站点或容器场景常见）、前置的 CDN 或边缘节点还有一层、程序重启没真正生效。逐层用一个刚好超限的文件试一次，能定位到哪层没改到位。

上传限制和安全有关系吗？ 有。入口层的上限同时也是慢速大包与资源占用的第一道控制。放开时按实际需要给值，不要一次抬得很高。

图片很多时是不是只能提高上限？ 不一定。走媒体上传或接口分批都能避开大包，上限调高应当是收尾手段而不是第一个动作。