The problem I’m having:
Hi all, I’m running a PHP video sharing app (ColorFul Tube CMS) behind Caddy 2 with php_fastcgi. Uploads of 1-2 GB videos sometimes fail mid-way. My current Caddyfile:
Is request_body max_size the right directive, and are there Caddy-side read/write timeouts I should raise for slow uploads, or is this purely PHP-FPM (upload_max_filesize, max_execution_time)? Thanks!
Error messages and/or full log output:
No Caddy error captured yet; uploads just stop partway. I will add debug and post logs if needed.
Caddy version:
Caddy v2 (installed from the official package; exact version to be posted)
How I installed and ran Caddy:
a. System environment:
request_body { max_size 4GB } handles the Caddy ingress cap, but for 1-2 GB uploads failing mid-stream over unix//run/php/php8.2-fpm.sock, the bottleneck is almost always the combination of FastCGI transport read/write timeouts and PHP-FPM’s worker termination timer rather than Caddy’s HTTP listener alone.
Three settings to align so large multipart uploads don’t get cut off:
1. Inside your php_fastcgi block, explicitly raise the FastCGI transport timeouts so Caddy waits while PHP-FPM finishesassembling and moving the temp file:
php_fastcgi unix//run/php/php8.2-fpm.sock {
transport fastcgi {
read_timeout 30m
write_timeout 30m
}
}
2. In /etc/php/8.2/fpm/pool.d/www.conf, check request_terminate_timeout (if set to 30s or 60s, the master FPM process kills the worker mid-upload with a 502/504) and ensure your upload_tmp_dir points to a filesystem with at least 2x the max upload size in free space (not a small tmpfs /tmp mount).
3. In php.ini (for 8.2/fpm), ensure post_max_size >= upload_max_filesize (e.g. 4G), max_input_time = 1800, and max_execution_time = 1800. Also, once you reload php8.2-fpm, verify the master process PID timestamp actually updated so your workers are running the latest patched 8.2 runtime. Feel free to DM me your www.conf if it still drops mid-upload and I’m happy to take a look.