`read-timeout` is too high, effectively does nothing in some scenarios

# Specify a read timeout for connections here. The default is 30 seconds.
read-timeout = 30000

The default read-timeout of 30 seconds matches the (modern) client value exactly. When a backend server dies/stalls completely (simulate with kill -STOP <pid>), the client disconnects itself after 30 seconds. Instead of Velocity considering this a read timeout (and sending them to a fallback server, or gracefully disconnecting the client), the client hard disconnects with "Timed out".

Setting the default read-timeout to some delta below the client's timeout would be the solution here, e.g. 25000 (25 seconds). I'd argue this could be even lower, but 25 seconds seems like a reasonable value, keeping the client's timeout in mind.

One issue here is that a PR updating the default to 25 seconds won't fix existing setups. Could this warrant a migration?

No file or test is named in the report. Start by locating the default read-timeout configuration and the client timeout handling, then trace how a stalled backend is classified. Done means the configured default expires before the client timeout, triggering the documented fallback or graceful disconnect behavior, with existing configurations and any migration path considered.