Can a reverse proxy route SSH, or is it only for web traffic?

It is possible, and the important thing to understand is that it is a different kind of routing with different capabilities, not the same feature applied to another protocol.

Modern proxies have two modes:

• HTTP routing. The proxy reads the request, sees the host header and the path, and can route on either. It can also terminate TLS, add headers, rewrite paths and load-balance on application-level rules.
• TCP routing. The proxy forwards a raw connection to a backend, seeing only bytes. Configured with a TCP-style entry point and a router.

SSH is not HTTP, so it can only use the second. That immediately tells you the limitation: there is no hostname in an SSH connection, so the proxy cannot route two SSH services by name on one port. It knows the port and the source address and nothing else.

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.

So the practical options:

One SSH service, dedicated port. A TCP entry point on port 22 forwarding to the container. Simple and it works. You have not saved a port, you have gained consistent configuration alongside everything else, which is the real benefit.

Several SSH services. Each needs its own port. There is no way around this at the TCP layer, and any guide claiming otherwise is doing something else.

Name-based routing over TLS. Proxies can route TCP by server name when the client sends one during a TLS handshake, which is how several TLS services share port 443. SSH does not do a TLS handshake, so this does not apply — but it is why the feature exists and why people expect it to work here.

A tunnel or a bastion. If the actual goal is reaching several machines' SSH through one entry point, that is what a jump host or an overlay network does, and it does it far better than a reverse proxy.