Introduction

Connection reset by peer means the TCP connection was accepted or partially established and then closed abruptly by the other side. In a Docker setup, that usually means the process inside the container crashed, rejected the connection, or was listening in a way that the published port could not actually serve. The fastest way to debug it is to verify the process, the bind address, and the port mapping in that order.

Start with the Process Inside the Container

The first question is whether the application is still alive and listening:

docker ps
docker logs <container-name>
docker exec -it <container-name> sh

Inside the container, inspect listening ports:

ss -lnt

If the service crashed right after startup, the network error you see from outside is just the symptom. The real problem is in the application logs.

Bind to 0.0.0.0, Not Only to 127.0.0.1

A very common Docker-specific mistake is that the app listens only on localhost inside the container:

# Bad for Docker exposure
app.run(host="127.0.0.1", port=5000)

That means the process is reachable only from within the container namespace itself. To expose it through Docker port mapping, bind to all interfaces:

# Good for Docker exposure
app.run(host="0.0.0.0", port=5000)

If the server binds only to 127.0.0.1, published ports may appear configured correctly while connections still fail or reset.

Verify the Port Mapping

Check how Docker is publishing the container port:

docker ps
docker port <container-name>

Or in docker run:

docker run -p 8080:5000 my-app

This maps host port 8080 to container port 5000. If your service actually listens on another port inside the container, the mapping will not work.

The host port and container port must match the application's real listening port, not the one you intended it to use.

Test from Both Sides

Try the service inside the container first:

docker exec -it <container-name> sh
curl http://127.0.0.1:5000/

If that works internally but fails from the host, the problem is likely port publishing or firewalling. If it fails internally too, the problem is the application itself.

This split is one of the most useful debugging shortcuts in container networking.

Other Common Causes

Connection resets can also come from:

• the app immediately closing sockets after accept
• TLS expected by the container while the client speaks plain HTTP
• reverse proxy timeouts or upstream misconfiguration
• container restarts triggered by crashes, OOM kills, or health-check failures

That is why docker logs and container restart status matter as much as port inspection.

Common Pitfalls

• Publishing the port correctly while the app still binds only to 127.0.0.1.
• Assuming a network problem when the process inside the container is actually crashing.
• Mapping the wrong host or container port.
• Testing only from the host and never from inside the container.
• Forgetting that protocol mismatch, such as HTTP versus HTTPS, can also produce resets.
• Missing restart-loop symptoms because docker ps was not checked during the failure window.

Summary

• 'Connection reset by peer usually means the process on the other side closed the TCP connection abruptly.'
• In Docker, check the container process and logs before assuming the network is broken.
• Make sure the service listens on 0.0.0.0 inside the container.
• Verify that Docker port publishing matches the service's real listening port.
• Test from inside the container and from the host to isolate where the failure starts.