Docker Published the Port. Is the Proxy Listening There?
Check the listener inside a proxy container as well as Docker's host port mapping when connections are refused or reset.
A published Docker port supplies a path to a container endpoint. It neither starts the proxy nor changes the address on which that process listens.
For a typical bridge-network mapping, compare these three values:
| Part of the path | Value to inspect |
|---|---|
| Client entry | The host address and published port the client contacts |
| Forwarding target | The container address and port selected by the mapping |
| Service | The address and port the proxy actually binds inside the container |
A proxy bound only to 127.0.0.1 inside the container may not receive traffic forwarded to its network address. This differs from publishing a host port only on host loopback: that restricts who can reach the mapping, while container loopback can keep the mapping from reaching the service.
Choose the internal listener for the intended deployment while preserving restricted host publication and proxy access. A Dockerfile's exposed-port declaration does not start a service, and a successful container launch does not establish that the process is listening at the forwarding target.
Follow how far a failed connection gets. Refusals and resets vary with the platform and forwarding implementation, so neither uniquely identifies a setting. Once it reaches the service, look for a valid proxy greeting and apply the required SOCKS version, authentication and destination policy. A reachable host port alone cannot establish those capabilities.