Because of the "needs info" label:

https://help.nextcloud.com/t/nginx-reverse-proxy-discussion/233378/6

I personally think the NGINX defaults of 60 seconds are perfectly fine, and thous this setting isn't needed.
Others wanna play it save, so we thought that 5min instead of 1min is a good setting that should be more than enough for any setup and at the same time not overwhelm NGINX with stale connections.

Also added the send timeout setting so this value also gets increased from the default 1min to 5min.

see: #979 and #1809 for the reason this is set
it needs to be at least the same value as:

I might be suffering from the Dunning Kruger effect and my knowledge is currently at "mount stupid" but I don't think they are connected that way.

The php max execution time (which btw seems to be a rather small default, if you can really only upload a file for one hour) is not connected to these two proxy settings.

And the linked issue does not really convince me otherwise. Yes, maybe one extremely weak small system with bells and whistles like calmav can trigger a timeout error with the default 60. That is why the forum members suggests 300 instead of ditching the setting completely and let NGINX use the default 60s.

My thesis is that a "normal" system would even be fine with something like 5 seconds.
Hope to soon find the time for a test deployment to see if 5 seconds is enough. Will report back what I find out.

proxy_read_timeout is the time nginx waits for the response of Nextcloud/php, and NEXTCLOUD_MAX_TIME the time PHP allows Nextcloud to process a request and respond.
proxy_read_timeout should be at least a few seconds higher then NEXTCLOUD_MAX_TIME.

If NEXTCLOUD_MAX_TIME is higher: then nginx will break the connection even if php is still working, which should not happen
if proxy_read_timeout is higher: then php will time out and report the timeout back to nginx which is the better error handling
if they are the same: nginx will time out since its counter starts a bit earlier and php also takes a bit to respond back to nginx, it might be not even a second, but nginx will cancel first, but php canceling and reporting back to nginx is better

see: https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout

Still not sure how this exactly behaves.
Maybe some real world examples could help.

Example 1: Downloading a file for 59min, with proxy_read_timeout 60 and NEXTCLOUD_MAX_TIME 1h
This works fine, because we don't run into a php timeout.
The NGINX default of 60s is also no problem since:
"The timeout is set only between two successive read operations, not for the transmission of the whole response."

Example 2: Downloading a file for 120min, with proxy_read_timeout 60 and NEXTCLOUD_MAX_TIME 1h
Here we run into the PHP timeout.

Example 3: Having a severely underpowered system that takes more than 60s for the initial response, with proxy_read_timeout 60 and NEXTCLOUD_MAX_TIME 1h.
Here we run into the NGINX timeout. Which is not great, but also more of a symptom of underlying issues.
Maybe some disks have to spin up first.

If I am right on example 1, I can setup a test instance with a timeout of 5s and try to upload a big file for longer than 5s. I think I will be fine.

I think we are not generous enough with example 2. Downloading a 10GB file over a weak mobile connection (20MBit/s) would result in a timeout.

I get that example 3 would be bad, but with the proposed 5min timeout, this is extremely gracious.

But what is the downside of setting it to at least NEXTCLOUD_MAX_TIME + a few seconds / one day? I mean yes most time even the nginx default would be fine, and five minutes will also fix most problems, but is there a downside of setting it higher? I don't see one.
Other questions: why also change proxy_send_timeout?

Most likely there is no downside under normal conditions.
I could imagine an NGINX states overflow, if NC has some kind of bug.
But I also don't see any upsides.

IMHO since we are changing a default, the question should not be

what is the downside of doing so?

but

what is the reasoning for changing that default?

If there really is a realistic situation where it could time out, I think it is fine to change the default.
But my guess is that I can even set it to 5s on a 1vCPU VM with 4GB RAM and still not experience a timeout.
Will test that as soon as I find the time.

Other questions: why also change proxy_send_timeout?

Isn't that the logical consequence of changing proxy_read_timeout?
If we are convinced that we need to change the proxy_read_timeout timeout, because otherwise there is a risk of NGINX timing out while reading from NC, isn't the same true for sending something to NC?

Most likely there is no downside under normal conditions. I could imagine an NGINX states overflow, if NC has some kind of bug.

Should not happen, if Nextcloud/php still works nginx waits and if it has a bug then the connection is closed by PHP

what is the reasoning for changing that default?

I don't explain it again

proxy_read_timeout = time nginx waits for backend to respond
proxy_send_timeout = time nginx gives itself to send data to the backend

I don't explain it again

I (think) get what they are doing, I don't get the reasoning on your side why you think it is necessary to change the default, other than to play it extra safe. And if so, why that much longer than PHP and why only read not send.

As a test, I created a VM with 2vCPUs, 2GB RAM, and limited read and write IO to 10 and bandwith to 10MB/s.
10 is very, very low. Like single very old HDD, Raspi over USB low.
I could actually trigger timeouts.
By setting the read timeout to 6s, which is 10x smaller than the default.
Uploading a file worked for roughly 10min before it ran into a timeout.
Doing the same with the default of 60s worked without any issues.

BTW the same applies to send timeout. Setting it to 6s sometimes triggers a timeout.
That is why I would argue that we need to change both.

IMHO we have these possible options:

A: not touching them at all, leave it at their 60s default and hope that the hosts are fast enough all the time. Even on my not slow real word instance I experience sometimes timeouts, so I think this is not great.

B: Or by using a 10x higher than default value and set it to 600. I think that 10min should be more than enough for NC to react, so that should do the trick.

C: Playing it extra safe and set it to 3900 which is 5min longer than the PHP timeout.

D: What we currently have, de facto disable it by setting it to 86400s. But then we should do it for both.

PS: with the current 1h PHP limit, is a user not able to upload for more than 1h? That can't be true, right?

Sorry, but I'm probably out of this discussion, so don't expect an answer from me after this one. szaimen will decide about this.

The last thing I can give you is this link: https://docs.nextcloud.com/server/stable/admin_manual/configuration_files/big_file_upload_configuration.html

You are talking about one use case where it does not time out, but there are cases where it will time out if NEXTCLOUD_MAX_TIME and/or proxy_read_timeout are too low, different ways of file uploads, also non upload related tasks, etc. This maybe doesn't affect you, but others. Yes, in most cases the default of 60 seconds is fine, but not always and there is still no downside mentioned of this being this high.

And proxy_send_timeout is again unrelated to this, the default is fine for it. I feel like you have no understanding of what these values even do.

The value of proxy_read_timeout can be lowered, but should be a few seconds (not minutes) higher than NEXTCLOUD_MAX_TIME, but then this should be noted for users which increased NEXTCLOUD_MAX_TIME. This is the only thing I'm fine with, everything else will break in some cases, and still there is no downside of keeping it this high.

There are other directives which should be changed in the example and some which can be discussed (will create a PR soon), but this value is fine.

And proxy_send_timeout is again unrelated to this, the default is fine for it. I feel like you have no understanding of what these values even do.

I don't fully, that is why I am asking :)
And you don't explain it (no accusation, you don't have to), that is why I was running tests.

Unfortunately there was an error in my testing which lead me to believe that we also need to change send_timeout.
That is not the case.

I think your idea of setting it to higher than PHP but also mentioning that in the comments for people that changed the default is the best way to handle it. Thank you for your contribution and I hope I didn't offend you.