WordPress 上传不了大文件，先找到限制在哪一层

WordPress 后台显示最大上传 2MB，换了一台磁盘更大的服务器，限制却没有变化。磁盘容量和请求大小是两件事：浏览器发出的文件，要先经过代理和 Web 服务器，再交给 PHP，最后才能写入目录。

先看失败发生在哪里

选择一个允许上传的文件类型，记录大小、错误提示和 HTTP 状态。刚开始上传就收到 413，先检查接收请求的 Nginx 或其他代理；已经进入 WordPress，页面提示超出允许大小，则继续核对 PHP 和站点设置。使用 CDN、负载均衡或额外反向代理时，每一层都可能有自己的上限。

Nginx 的 client_max_body_size 控制请求体大小，可以配置在 http、server 或 location 中。要检查实际命中的配置，不能只改一个没有被加载的文件。语法检查通过后再按部署方式重载，并用同一个文件重试。

upload_max_filesize 限制单个上传文件，post_max_size 限制整个 POST 请求。一个请求除了文件，还有表单字段及封装数据，因此后者应大于前者。只调大文件上限，仍可能被整个请求的上限挡住。

例如，准备允许单个 64MB 文件时，可把以下两项作为配置起点，再检查其他层的限制：

upload_max_filesize = 64M
post_max_size = 80M

这不是任意插件都能上传 64MB 的保证。多站点模式、插件、执行时间和内存需求仍需分别核对。PHP CLI 与处理网站请求的 PHP-FPM 也可能读取不同配置，终端里看到的数值不能直接当作网页运行环境的结果。

使用 Docker 或面板部署时，先确认 PHP 配置由镜像、挂载文件还是面板生成。直接进入容器编辑文件，可能在重建或更新时丢失；应把设置放入部署实际支持的持久配置，再重新加载对应进程。

核对配置时避免把包含环境信息的 phpinfo() 页面长期暴露在公网。完成检查后移除临时入口，同时保存改动位置，方便下次升级复核。

上传会使用临时目录，最终目录也需要剩余空间和正确权限。检查应用所用的磁盘，而不是只看整台机器标称容量；缓存、日志和旧备份可能占满同一个文件系统。不要用放开所有目录权限的方式替代定位。

只有确认容量、内存或部署需求确实不足，才需要比较新的阿里云 ECS 配置。换机器无法自动修复旧的请求限制。

改完后分别测试小文件、目标大小文件和一次正常业务上传，确认附件能打开、后台不报错。最后把实际限制和持久配置位置记入维护记录，避免程序升级后再次从头排查。