Levent

Worth stepping back to the goal, because it decides whether this is worth doing at all.

If it is to avoid opening a second port, be clear the proxy does not avoid it — the entry point is still a listening port. You have moved which process listens.

If it is consistent configuration, that is a genuine reason and the TCP router is the right answer.

If it is to expose SSH to the internet safely, a proxy adds nothing to the security of it. Key-only authentication, no password login and a modern configuration are what matter, and none of them are the proxy's job.

If it is to reach it from outside without exposing anything, an overlay network is a better answer than either. No open port at all, and it works from anywhere.

The detail that makes any of these work reliably, and which most guides skip: use a proper local domain and be consistent about it.

Give the network a domain, hand it out with the address leases, and refer to machines as thing.yourdomain rather than as bare names. Bare single-label names are resolved by a mixture of mechanisms depending on the client and are the reason it works on one device and not another.

What to use: a subdomain of a domain you actually own is the safest. Failing that, .internal is now reserved for exactly this. Avoid .local, which belongs to multicast discovery and will conflict, and avoid inventing a name that might become a real top-level domain.

The options in increasing order of correctness, if you want to do better than switching it off:

1. Let the backend serve plain HTTP internally. Many services offer this and it is the simplest correct answer — encryption where it matters, none where it does not. Not available when the service refuses, which is your case.

2. Tell the proxy to trust that specific certificate. Most proxies let you supply a CA or a specific certificate for a backend, rather than disabling checking entirely. This keeps verification on and is the genuinely correct fix. The cost is renewing it and updating the proxy when it changes, which is why people avoid it.

3. Run an internal certificate authority. Issue backend certificates from it, trust it in the proxy. Correct at scale and considerable setup for one service.

4. Disable verification, knowingly and only on a trusted path.

Most home and single-host setups land on 4 with a comment, and that is a reasonable engineering decision rather than a shortcut, provided the topology is the first case.

The other half is that wifi has failure modes that look like software bugs, which is why the advice is so absolute among people who have debugged it.

A dropped connection that recovers in seconds shows up as a device that did not respond, a message that vanished, an automation that ran once and not the next time. Nothing logs a network error, because as far as the application is concerned the connection was fine before and after.

People spend weeks debugging their configuration for that. It is one of the most reliably wasted efforts in this hobby.

And there is a specific hardware trap: on a lot of small single-board computers the wifi radio and the USB controller share a bus. If your hub also has a radio dongle plugged in — which most do — heavy wifi traffic and the dongle interfere with each other, and the symptom is devices dropping off, not slow internet. Moving to ethernet fixes an apparent radio problem, which is why the advice sounds superstitious until it works.

On whether to switch: the honest answer is that for most people on current hardware the newer server is now the better default, and the exceptions are specific rather than general.

Reasons to stay on the older one, all legitimate:

• An application you depend on that has no portal support and no replacement.
• Remote desktop or accessibility software that only works there.
• An older or unusual graphics setup where the newer stack is unstable.
• Screen recording or streaming workflows built on unrestricted capture.

Because it is a per-login choice, the sensible approach is to try it for a week, keep a list of what breaks, and go back if the list is unacceptable. There is no migration and nothing to undo, which makes this a much lower-stakes decision than it reads.