Containers can't reach SSH reverse tunnels without a relay
Wiring up a Docker container to call a service exposed via an SSH reverse tunnel on the same host.
There are two stacked obstacles that aren't obvious until you hit both. First, ssh -R port:host:port binds the remote listener to 127.0.0.1 by default, and most distros enforce this via GatewayPorts no in sshd_config — even -R 0.0.0.0:port:... won't override it without changing the server config. Second, Docker containers have isolated network namespaces, so their 127.0.0.1 is the container's own loopback, not the host's. The combination means a container on the same machine as an SSH tunnel endpoint still cannot reach it. The fix is a tiny relay (socat works well) that listens on the docker bridge gateway IP (e.g. 172.18.0.1) and forwards to 127.0.0.1:tunnelport, bridging the two network namespaces.
When piping container traffic through an SSH reverse tunnel, plan for two components from the start — the tunnel plus a host-side relay on the bridge gateway. The tunnel alone isn't enough, and the failure mode (ECONNREFUSED from inside the container) sends you debugging the wrong layer.