On very fast internet connections the speed-limit is especially likely to cause the quasi-off condition.
However...
One limit increases reliability:
Max simultaneous downloads from single address (is good)
Use only that one. Try setting it to 1 or 2
My suggestion doesn't stop the old retry-flood = exit, nor the newer quasi-off condition. We still need a "watchdog" in Events, which would test the loopback 127.0.0.1 for alive (with .load 127.0.0.1/favicon?); and if no response, server off, then slightly into the future server on.
Edit: 5 second time before server on, so that the overload cause/bot has given up or gone elsewhere?
Edit2: Also, server off server on = server off. (not useful) So, I think that we have to quote server on to make it run last.
Maybe this: server off, if not server off then server off, else {:server on {.if not server on then {:server on:}.}:} can run in the correct order to change the quasi-off condition to server on? For server on, it may be necessary to check&loop until server is really on?
The key is this order: server off, Look Over There!!!, server on{:server on:}
Edit3: Only the .load macro + loopback can be used for watchdog purpose (must make an http request for watchdog test).