Reverse proxy to PHP-FPM for large video uploads: request_body max_size and timeouts

  1. 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:
example.com {
    root * /var/www/clf/public
    request_body {
        max_size 4GB
    }
    php_fastcgi unix//run/php/php8.2-fpm.sock
    file_server
}

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!

  1. 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.

  2. Caddy version:
    Caddy v2 (installed from the official package; exact version to be posted)

  3. How I installed and ran Caddy:
    a. System environment:

Linux, systemd, PHP 8.2 FPM

b. Command:

systemctl start caddy

c. Service/unit/compose file:

Default caddy.service from the official package

d. My complete Caddy config:

See the Caddyfile above.

  1. Links to relevant resources:
    https://clfcms.com/

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.