curl (56) Recv failure: Connection reset by peer - when hitting docker container [closed]
From an AWS ec2 instance (which runs docker
), I am trying to curl
my docker container-hosted web service.
Given:
[ec2-user]$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b56fa0d76d5c $REGISTRY/$WORK/metrics:v0.1.0 "/bin/sh -c 'sh /root" 3 minutes ago Up 3 minutes 0.0.0.0:80->80/tcp, 0.0.0.0:9000->9000/tcp insane_leakey
I can hit the web service from within the container:
[ec2-user]$ docker exec -it b56fa0d76d5c bash
root@b56fa0d76d5c:/# curl 'http://localhost/health'
Request is missing required query parameter 'apiName'
But, I can't hit it from the host:
[ec2-user]$ curl 'http://localhost/health'
curl: (56) Recv failure: Connection reset by peer
I looked at this detailed answer on this curl
error, but I'm not sure how to debug this issue.
Connection Reset to a Docker container usually indicates that you've defined a port mapping for the container that does not point to an application.
So, if you've defined a mapping of 80:80, check that your process inside the docker instance is in fact running on port 80 (netstat -an|grep LISTEN).
You get a reset as the Docker 'proxy' picks up the connection, attempts to connect to the process inside the container, fails, so resets the connection.
You can investigate this by installing tshark on the container and then do tshark -i any
:
If you then do a request externally you should see something like the below:
root@618910b515f0:/code# tshark -i any
Running as user "root" and group "root". This could be dangerous.
Capturing on 'any'
tshark: cap_set_proc() fail return: Operation not permitted
tshark: cap_set_proc() fail return: Operation not permitted
1 0.000000000 172.18.0.1 → 172.18.0.3 TCP 76 45844 → 8001 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=820044004 TSecr=0 WS=128
2 0.000019457 172.18.0.3 → 172.18.0.1 TCP 56 8001 → 45844 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
The network packet came in but it responded with a RST
, which means it was rejected.
Most probably you're listening on 127.0.0.1
rather than 0.0.0.0
- all IPs. You can verify this by running netstat -tulpn