Nextcloud 上传文件返回 413
Nextcloud 网页或 WebDAV 上传返回 413。通过请求与日志定位限制所在的 Nginx，核对单次请求大小、站点配置及 location 覆盖，备份后调整上限、重载并验证，保留回退步骤。
Nextcloud 网页上传失败，只弹出“未知错误”；换成 WebDAV 客户端，同一个文件报 413 Request Entity Too Large。如果小文件能传、大文件失败，且请求经过 Nginx，可以核对这次上传命中的 client_max_body_size。
下面适用于能够管理 Nginx 配置、使用常规请求体处理，且已确认请求体限制导致 413 的部署；Apache、CDN 或其他网关返回的 413，需要处理各自的限制。
定位返回 413 的请求和代理层
网页上的“未知错误”不够具体。打开浏览器开发者工具的 Network 面板，重试一次上传，找到失败请求，记录状态码、请求方法、URL、时间，以及有无 Content-Length。如果用 WebDAV 客户端，则保留对应的错误和日志。排查时隐藏账号、文件名及认证信息，不把带 Cookie 或 Authorization 的完整请求贴到公开页面。
接着沿实际部署路径查日志。例如，浏览器先经过一台反向代理，再到运行 Nextcloud 的 Nginx，两层都可能限制上传。只修改后端，上游仍会拒绝同一个请求。
在怀疑的那一层 Nginx 错误日志中，搜索与本次请求时间、路径对应的内容：
sudo grep -nF 'client intended to send too large body' /path/to/nginx-error.log
/path/to/nginx-error.log 替换成这台实例实际使用的错误日志。Nginx 处理这类请求时会把已知的请求体长度与当前配置上限比较，超限后返回 413。匹配本次请求的日志能支持“这一层因体积拒绝请求”的判断；单凭响应里的 Server: nginx，无法分辨是哪一层 Nginx。
没有这条日志时，不能据此排除大小限制：也可能查错日志、请求尚未到达该实例，或采用了不同的传输方式。先确认入口及日志位置，再决定是否改配置。401、403、连接失败，以及上传结束后的 504，也不能直接按 413 处理。
上限针对单次请求，不等于整个文件大小
client_max_body_size 默认值是 1m，可以放在 http、server 或 location 中。请求体超过上限会返回 413；设为 0 则关闭这项大小检查。
所以注释掉一行并不等于取消限制。当前层级没有设置时，会继承上级配置；如果上级也没有设置，才落到默认值。反过来，在 server 中提高限制，也不能覆盖某个上传 location 里已经明确设置的较小值。
桌面同步能传、文件管理器的 WebDAV 不能传，并不矛盾。同步客户端会把文件分成较小的块上传，一个大文件可以由多次较小的请求完成，另一个客户端则可能直接发一个完整文件的 PUT 请求。判断上限时要看实际失败请求的大小，不能只看文件总大小，也不能据此断言同步客户端绕过了 Nginx。具体传输过程应从请求和客户端行为确认。
确认修改的是这个站点使用的配置
先确认正在服务该域名的 Nginx 实例、二进制路径和启动参数。宿主机的 Nginx、容器里的 Nginx、面板安装的另一份 Nginx，可能各用一套配置。
下面的命令以宿主机上的 Nginx 使用默认配置路径为前提。若服务启动时带了 -c 或 -p，检查和重载时也要使用对应的参数；若实际服务在容器里，则在该容器中查看配置，后续修改它的持久化配置来源，不能拿宿主机的检查结果代替。
config_dump=$(mktemp) || exit 1
sudo nginx -T > "$config_dump" || exit 1
grep -nE 'configuration file|server_name|listen|location|client_max_body_size|error_log|client_body_temp_path' "$config_dump"
mktemp 创建的文件用于本机查看，不要公开上传整份配置。nginx -T从 1.9.2 起可用，会检查并输出读取到的配置文件，其中的文件标记可以帮助找到指令来自哪个 include 文件。筛选结果只用于定位；还要读对应的完整 server 和 location，确认域名、监听端口以及失败 URL 的匹配关系。
例如，HTTPS 请求通常要核对承接 HTTPS 的站点块，不能只改负责 HTTP 跳转的块。WebDAV 路径也可能经内部跳转进入 PHP 处理位置，不能只看外层 /。Nginx 请求匹配说明介绍了服务器与位置的选择过程；找到文件中的同名域名，只是核对的一部分。
-T 展示的是本次从磁盘读取的配置，不能证明正在运行的 worker 已经加载这些内容。如果之前编辑过文件却没有成功 reload，磁盘和运行状态仍可能不同。
备份后，只调整这条上传路径的限制
先按需求定上限。假设这条路径需要允许约 132MB 的单次上传请求，256m 可以作为留有余量的配置示例；它不是 Nextcloud 的统一推荐值，也不承诺允许任意大小的文件。若用户需要单请求上传更大的文件，应结合明确的业务上限、代理链和存储容量另行确定。
上限应有明确的并发与容量依据，不需要照搬其他部署的 10GB 设置。对照所用 Nextcloud 版本保留既有路由和 PHP 配置，只调整已确认的上传限制，不用一份旧配置替换整个站点。
在 Linux 上，先备份刚才确认的实际配置文件。site_config 必须指向将要编辑的那个普通文件；如果站点入口是符号链接，先确认并使用它的真实目标路径。如果还需改其他 include 文件，每个文件都要有自己的备份。
site_config=/path/to/active-nextcloud.conf
backup_dir=$(sudo mktemp -d /var/backups/nextcloud-nginx.XXXXXX) || exit 1
sudo cp -p -- "$site_config" "$backup_dir/site.conf" || exit 1
printf 'Backup: %s\n' "$backup_dir/site.conf"
记下输出的备份路径。新建目录默认权限为 0700，可能被 umask 进一步收紧。备份成功后再编辑。对于由面板或部署工具生成的配置，应从其管理入口修改，避免下一次更新覆盖手工改动；容器的 bind mount 配置则修改已确认的宿主机源文件。
在对应站点现有的 server 中设置下面这一行。如果同一层级已有该指令，就修改它，不要重复添加：
client_max_body_size 256m;
同时核对实际上传经过的 location。其中若有较小的显式值，需要按该路径的用途调整，或在确认应继承站点限制时移除这一条覆盖。不要为了容纳这行配置新建 WebDAV location，否则可能改变原有路由、鉴权或 PHP 转发行为。
同一个请求体沿途经过的代理层，都要允许所需大小。调整已确认阻拦的层后，再验证下一层的结果。也不要把这个值直接放进全局 http，让其他站点一起放宽。
检查配置并重载，再用原客户端验证
保存后先检查，检查成功才重载：
sudo nginx -t && sudo nginx -s reload
这里仍以同一实例、默认配置路径为前提。自定义启动参数的部署必须对应调整这两个命令，容器和面板部署则使用该实例的检查及重载入口。检查失败就修正文件，不执行重载。
Nginx master 会检查并尝试应用新配置；失败时继续使用旧配置。因此，命令发出后还要查看实际实例的错误日志，确认没有重载失败，不能只看磁盘中的值已经变大。
用原先失败的客户端和上传方式，再传一次同一个测试文件，最好使用专门的测试目录，避免覆盖已有文件。然后核对：
- 原先的请求不再返回 413，对应日志不再出现同一次上传的体积拒绝记录。
- 客户端确实显示上传完成，而非只完成一个分块；在 Nextcloud 中确认最终文件大小，并下载核对内容，必要时比较校验和。
- 小文件上传和日常访问仍正常。若继续报 413，重新定位返回错误的层与命中的配置，而不是不断把数值调大。
如果 413 消失，却变成超时或空间不足，那是新的排查线索。Nginx 的 client_body_buffer_size 负责请求体的内存缓冲，较大的请求可能写入临时文件；它不是另一个上传大小上限。临时空间还需承担上传处理和并发。放大请求上限前后，都要关注实际临时目录所在分区及 Nextcloud 存储的容量，不能靠放大内存缓冲或放开目录权限解决 413。
也不要把 upload_max_filesize、post_max_size 当成所有 WebDAV 请求的直接限制。这些 PHP 参数可能不适用于单文件 WebDAV PUT 或分块上传。只有日志和所用上传路径指向 PHP 限制时，才继续核对实际 Web 服务使用的 PHP 配置；CLI 的 PHP 配置不能代替 PHP-FPM 的配置。
出现副作用时恢复这一份配置
提高上限允许更大的请求进入后端，会增加请求处理、临时存储和并发容量的压力。保留有依据的上限，不把 0 作为默认修复办法，也不需要删除 Nextcloud 数据、重装服务或更改文件权限。
如果调整后出现副作用，确认该配置文件没有其他需要保留的新改动，再从刚才的备份恢复。以下两个路径均需替换成实际路径；不要恢复其他站点或更早的整套配置：
sudo cp -p -- /var/backups/nextcloud-nginx.XXXXXX/site.conf /path/to/active-nextcloud.conf &&
sudo nginx -t && sudo nginx -s reload
恢复后继续查日志并验证访问。原先的上传上限会一同恢复，测试大文件也可能重新返回 413。此时需要重新安排合适的限制或上传方式；恢复配置本身不会删除上传数据。