看起来你遇到的这个间歇性大文件上传失败问题，核心是日志里的Expected filesize of X bytes but read Y bytes错误——要么是传输过程中反向代理截断了请求，要么是服务器存储端写操作出了问题。结合你已经做的配置，我整理了几个针对性的排查和解决方向：

大文件上传依赖分块机制，默认的分块大小可能和反向代理的限制不匹配，导致部分分块被截断。在nextcloud/config/config.php中添加以下配置：

'chunked_uploads' => true, // 强制开启分块上传
'chunk_size' => 5242880, // 设置为5MB（比日志里的10MB更小，降低代理截断概率）
'max_chunk_size' => 26214400, // 最大分块设为25MB
'dav_chunk_size' => 8388608, // WebDAV分块大小设为8MB

这样调整后，单块数据更小，不容易触发代理的连接中断限制，同时保证分块上传的稳定性。

因为你无法控制前端的反向代理，只能在Apache层面做适配，避免中间环节超时或缓冲溢出。在Nextcloud根目录的.htaccess或者Apache虚拟主机配置中添加：

# 延长超时时间，适配大文件上传的耗时
Timeout 7200
ProxyTimeout 7200

# 禁用请求压缩与缓冲，避免代理对压缩后的请求处理异常
SetEnv no-gzip 1
SetEnv dont-vary 1
RequestHeader unset Accept-Encoding

# 允许最大请求体大小与PHP配置一致
LimitRequestBody 10737418240 # 对应10G，和php.ini的upload_max_filesize匹配

这些设置能减少Apache和反向代理之间的交互冲突，降低连接中断的概率。

你已经设置了上传大小和执行时间，但还有两个容易忽略的点需要确认：

• 内存限制：在php.ini中设置memory_limit = 512M（或更高），处理大分块需要足够的内存空间，避免内存不足导致写入中断
• 临时目录：检查upload_tmp_dir配置的目录是否有足够磁盘空间，且PHP进程拥有读写权限——临时文件写入失败会直接导致上传分块丢失
• 可以通过创建phpinfo.php文件（内容<?php phpinfo();?>）访问，确认所有PHP配置是否生效

日志提到可能存在存储写入问题，需要确认：

• Nextcloud的data目录磁盘空间充足，用df -h命令查看剩余空间
• 检查data目录的权限：确保Apache/PHP进程（通常是www-data用户）拥有读写权限，可通过chown -R www-data:www-data /path/to/nextcloud/data修复
• 排查磁盘IO瓶颈：用iostat命令查看上传过程中的磁盘读写负载，如果IO使用率长期100%，可能是磁盘性能不足导致写入超时

如果Web端上传持续失败，建议用Nextcloud桌面客户端测试：

• 桌面客户端的分块上传机制更稳定，且对代理的兼容性更好
• 如果桌面客户端上传正常，说明问题出在Web端的前端逻辑或反向代理对Web请求的特殊限制，可以尝试临时禁用Nextcloud的WebApp（在config.php中加'webapp_enabled' => false）测试

内容的提问来源于stack exchange，提问作者Hermann Schwarz