Possibly fastcgi_read_timeout.
(mentioned briefly in the Admin Manual - Uploading big files: Nginx chapter section, but this chapter could use an overhaul to make things way clearer).
During the MOVE (chunk assembly), the connection is idle (no traffic is being transmitted) while it waits for that big operation to finish (constrained by disk I/O most likely).
This also aligns with your Nautilus versus Web UI test, since Nautilus isn’t using chunking (unless something has changed in its support).
It sounds like perhaps your environment is more storage I/O bound (rather than network throughput bound), at least for this particular type of transaction.
So I’d also experiment a bit with bumping up the Web UI client’s max_chunk_size from the default (10 MiB in <=v30) significantly (easily 10x or even 100x). This may help with the timeouts in your case (depending on why assembly is taking so long).
You may even want to experiment with disabling chunking in the Web UI client (setting max_chunk_size to 0). This should effectively make it equivalent to the Nautilus transactions.
Just beware max_chunk_size currently is global scope… (i.e. impacts all accounts on the same instance).
Along the same vein of things, anything you can do to speed up your server’s underlying disk I/O performance could help.