Sedat

Good addition. The repeating pattern at a fixed interval is the giveaway that it is a client retrying rather than a server crashing.

The timed revert is the trick worth knowing. It turns an irreversible mistake into a ten minute wait.

One case worth knowing about because it is not your fault and no amount of checking your own zone will find it: the break can be above you.

If the operator of your top-level domain has a problem with their signing, every domain under it fails validation at once while each individual zone is perfectly correct. It looks exactly like your problem.

The tell is that the debugging chain shows the break at the parent rather than at your zone, and that other domains under the same suffix fail identically. If you find that, there is nothing to fix on your side: the answer is to wait, and meanwhile to get a certificate by a route that does not depend on the broken lookup.

Which is the practical workaround for any of this: if HTTP validation is available to you, it does not need the authority to resolve anything beyond your address, so it can succeed while a DNS-based challenge cannot.

What is disconnecting is the live channel, not the application. Modern interfaces keep a long-lived connection open to receive updates: a WebSocket, or a server-sent event stream - and it is that connection dropping, not the HTTP requests.

That is why everything else works. Loading a page is a short request that succeeds; the banner is about the persistent one.

And the usual culprit is the proxy, because a long-lived connection needs treatment that ordinary requests do not:

• The upgrade has to be forwarded. A WebSocket starts as an HTTP request carrying Upgrade and Connection headers, and a proxy that does not pass them through downgrades the handshake and the connection never establishes.
• The read timeout kills it. Proxies close connections that have been idle for some period, often sixty seconds by default. A live channel that is quiet for a minute is exactly that, so it gets cut, reconnects, and gets cut again. The interval between banners is usually a giveaway.
• Buffering breaks event streams. A proxy that buffers responses holds the stream instead of passing events through.

So the fixes, in the order to try them:

1. Pass the upgrade headers for that route, and set the protocol version the proxy uses to the backend to one that supports it.
2. Raise the read timeout substantially for that route - minutes, not seconds - or configure keepalive pings if the application offers them.
3. Turn off response buffering on that route if the application uses an event stream.

And there is a fourth option that is often the easiest and gets overlooked: many applications can switch transports. If the app supports server-sent events as an alternative to WebSockets, setting that is a single environment variable and event streams pass through far more proxies unmodified, because they are ordinary HTTP responses that simply never end.

If you are behind a content delivery network as well as your own proxy, check its settings too: several buffer or terminate long connections regardless of what your proxy says.

On not locking yourself out - take this seriously, because a bridge configuration reassigns the interface you are connected through.

Use the try mode. The tool has a command that applies the configuration and automatically reverts it after a timeout unless you confirm. If the change breaks your connection, you cannot confirm, and it puts everything back. This exists for precisely this situation and it has saved me more than once.

Have a second route in if the machine is remote, a console, a second interface, physical access. On a desktop you are sitting in front of it, so this matters less.

Keep a copy of the working configuration before editing.

And validate the YAML before applying anything. Indentation errors in this format are silent about what they mean and produce a machine with no network at all.

Quick way to see what is actually driving the card right now, before installing anything:

lspci -k | grep -A 3 -i vga

That shows the device and the kernel module in use. If the expected module is listed as in use, the driver is loaded and working, and anything you install is adding userspace rather than fixing the display.

If no module is in use, that is the case where something genuinely is missing - and it is usually firmware or kernel age rather than a downloadable driver.