我之前也碰到过一模一样的问题，这个curl (56) Recv failure: Connection reset by peer错误本质是TCP连接建立后被对方主动重置了，大概率是网络连通性、服务状态或者容器配置出了问题。给你列几个我亲测有效的排查和解决步骤：

先进入容器内部排查服务本身：

• 用ps aux或者systemctl status <你的服务名>（如果容器用systemd管理）确认服务有没有启动。比如跑Nginx的话，先看Nginx进程是否存在。
• 用ss -tulpn（比netstat更高效）检查服务是否在监听正确的端口，重点看绑定的地址是不是0.0.0.0——如果服务只绑定了127.0.0.1，那容器内用127.0.0.1 curl能通，但用容器自身IP或者外部IP就会失败，因为服务只监听本地回环。

先测基础连通性，再看端口：

• 先ping目标IP：ping <目标IP>，如果ping不通，说明容器和目标之间的网络链路有问题（比如容器网络模式不对、宿主机防火墙拦截）。
• 如果ping通但curl失败，用nc -zv <目标IP> <端口>测试TCP连接能不能建立。这个命令能直接告诉你端口是否开放：
  • 如果显示Connection refused：说明目标端口没被监听，回到第一步检查服务状态。
  • 如果显示succeeded!但curl还是失败：那问题出在HTTP层（比如服务路径配置错误、SSL证书问题），直接去看服务日志找线索。

不管是容器内还是宿主机的防火墙，都可能悄悄拦截流量：

• 容器内部：如果装了ufw或iptables，可以临时关闭测试：ufw disable或者iptables -F，然后再curl试试。
• 宿主机/云环境：如果是访问外部服务，检查宿主机的防火墙是否允许出站流量；如果是云服务器，还要看云服务商的安全组有没有放行对应的端口。

很多时候错误的细节都藏在服务日志里：

• 比如Nginx的错误日志默认在/var/log/nginx/error.log，Java应用可能有自己的application.log，去看日志里有没有报错（比如端口被占用、配置文件语法错误、请求处理异常）。
• 如果是容器启动时服务就失败了，用docker logs <容器ID>看容器启动日志，说不定能找到服务启动失败的直接原因。

如果用了自定义网络或者特殊网络模式，额外检查这几点：

• 检查容器是否加入了目标网络：docker network inspect <网络名>，看容器列表里有没有你的容器。
• 如果是host网络模式，确认宿主机上的服务是否正常监听（因为host模式下容器共享宿主机网络）。
• 实在不行可以重启Docker服务试试：systemctl restart docker（Linux），或者重启Docker Desktop（Windows/Mac），有时候Docker网络驱动会抽风导致连通性问题。

我之前踩过的坑是：容器里的Spring Boot服务默认只绑定127.0.0.1，导致用容器IP curl直接被重置，把启动参数改成--server.address=0.0.0.0就搞定了。

内容的提问来源于stack exchange，提问作者sysadmin umesh