Randomly gets "Connection reset by peer" on my droplet. Noticed only at DO

Deployed a service in my DO k8s cluster. It is stunnel proxy with custom openssl build (GOST-engine for OpenSSL) which proxy traffic from localhost:8000 to removeserver:443

Randomly, if I try curl from the pod I get “Connection reset by peer error” message. I would say ratio it 1:2

For example:

/ # curl -X GET localhost:8000 -I
curl: (56) Recv failure: Connection reset by peer
/ # curl -X GET localhost:8000 -I
HTTP/1.1 200 OK
Server: nginx/1.14.0
Date: Thu, 19 Aug 2021 16:08:03 GMT
Content-Type: text/html
Content-Length: 89
Last-Modified: Fri, 12 Mar 2021 17:59:55 GMT
Connection: keep-alive
ETag: "604bac1b-59"
Strict-Transport-Security: max-age=15768000
Accept-Ranges: bytes
/ # curl -X GET localhost:8000 -I
curl: (56) Recv failure: Connection reset by peer

Tested that docker image elsewhere (locally, other cloud providers) outside Digital Ocean and it works fine. Can it be related to Droplets network configuration or blacklisted DO IPs?

Thank you.

Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Want to learn more? Join the DigitalOcean Community!

Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in Q&A, subscribe to topics of interest, and get courses and tools that will help you grow as a developer and scale your project or business.


Do you have multiple pods running on your Kubernetes cluster for that service? As the ratio is 1:2 it sounds like that the traffic is hitting a problematic pod which is not responding.

I would recommend checking the state for all pods on the cluster to see if this is the case.

If not, I could also suggest running an mtr or a traceroute to see where the connections are being dropped exactly.