37

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.

2
  • 1
    I wonder from time to time why this question was closed when it is just perfect.
    – toraritte
    Aug 14, 2021 at 12:29
  • Be aware if you're running a VPN this will change localhost/127.0.0.1. Try disabling your VPN if using one.
    – Preston
    Oct 13, 2021 at 12:35

2 Answers 2

30

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.

8
  • No netstat on the container, but I ran: ss -a | grep -i LIST to output tcp LISTEN 0 100 ::ffff:127.0.0.1:http :::*. If I read that output correctly, then it's listening on localhost:80? Apr 11, 2016 at 18:45
  • 13
    Actually, stackoverflow.com/a/26553296/409976 fixed my issue, i.e. using "0.0.0.0" as the interface, not "localhost". Apr 11, 2016 at 19:10
  • 7
    Thanks Jason. Your solution wasn't an actual fix for me, but it lead me to the issue. This happened to me because the service started on 127.0.0.1:9200 (inside container) and it wasn't "published" because of the IP. So I changed it to 0.0.0.0:9200 and then it started to work from outside of the container. You need to have the 9200 port exposed, but I'm sure you already know that. May 18, 2017 at 12:57
  • @KevinMeredith : Thanks for that.. been struggling for past 4 hours coz of that!!! Jul 18, 2017 at 16:03
  • 1
    This is such a beautiful answer. For some reason, in very simple words, it also gives such a beautiful understanding about the concept behind the problem.
    – Ashish
    Jul 14, 2023 at 3:29
10

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

Not the answer you're looking for? Browse other questions tagged .