
Let's say something like this is being return when issuing a curl command.
(56) TCP connection reset by peer
This means that the system you are connecting to (the peer) has sent a RST (reset connection) packet. You would have to have access to the peer then examine the peers logs to determine why the peer sent the RST (reset connection) packet. If you do not have access to the peer, here are a few things you can try.
Use the curl --version command to determine the version of curl you are using.
~]$ curl --version
curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.44 zlib/1.2.7 libidn/1.28 libssh2/1.8.0
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz unix-sockets
If you are using version 7.71.0 or higher, the --retry-all-errors, --retry and --retry-delay options can be used to retry after the peer sends the RST packet. In this example, there will be 5 retries with a 1 second delay between retries.
curl --url https://www.example.com/foo --retry-all-errors --retry 5 --retry-delay 1
If you are below version 7.71.0, the --retry and --retry-delay options might allow you to retry the connection x time. In this example, there will be 5 retries with a 1 second delay between retries.
curl --url https://www.example.com/foo --retry 5 --retry-delay 1
Did you find this article helpful?
If so, consider buying me a coffee over at