The “Connection reset by peer” error occurs during a network connection when the other end or server closes the connection without reading the transferred data. The peer will return the data packet you sent while sending the RST (reset) bit and forcefully terminate the connection.
This issue usually happens if you are being blocked by the Firewall on any point in the route. But it can also happen due to other reasons. In this article, we mention different causes for the error along with how you can resolve it in each scenario.
Causes for Connection Reset By Peer
Here are some of the potential reasons for the “Connection reset by peer” error:
- Access blocked by firewall or hosts file.
- Your IP banned on the host server.
- Server settings changed without restarting the daemons.
- Low timeout period for connection.
- Server busy with maximum connections.
- Bugs in the program used to set up the connection.
How to Fix Connection Reset by Peer
First, make sure your system is not too busy. If you have high usage of CPU, memory or network, you’ll experience issues while setting up a new connection.
Also, try restarting the session and retry the attempt to make the connection. Then move on to the possible solution we have provided below.
Most of the steps we have mentioned are for a Debian based Linux server. If you have any other system, you can apply similar steps by searching on the internet for the exact process. Some commands also vary between the different Linux systems. So look out for those as well.
Check Logs
First, you need to check the logs or error messages to narrow down the reason for the error.
If you have access to the server, you can check the server-side logs as well.
For example, if you are experiencing this issue while setting up an ssh connection, you need to check the /var/log/auth.log file. To do so,
- Open the Terminal.
- Enter
tail -f /var/log/auth.log
.
It shows the logging information sent by the SSH daemon during the authentication attempts of your remote system.
Check Internet Connectivity and Routing
The next thing you should do is check for internet connectivity issues. You can check if the public or private server has gone down using IP lookup or similar websites.
You can also use use traceroute
or tracert
to trace the route between the two endpoints and check which access point is resetting your connection. The syntax is:
- On Linux:
traceroute [domain/IP]
- On Windows:
tracert [domain/IP]
If the public server or access points are down, you need to wait until they are up again. For issues with the private server, you can contact the system admin or restart it if you have access.
Check for IP Ban
One major reason for this issue while connecting to public servers is your IP being blacklisted by major security service providers. Most public servers ban IP addresses while conforming to these server’s database.
To check whether your IP address is blacklisted,
- Open the MX Toolbox Supertool webpage.
- Set the yellow drop down box to Blacklist Check.
- Enter your IP address on the text box and click Blacklist Check. If you don’t know you IP address, search for “What is my IP” on Google.
If your IP is blacklisted on multiple security networks, or important ones like BARRACUDA, BLOCKLIST.DE, Nordspam BL, etc., most servers or security filters will also ban you.
The only thing you can do is talk your ISP and have them contact the server admin to remove the ban.
You can also try changing your IP address using VPN to bypass this issue.
Check Firewall and Network Security Filters
The “Connection reset by peer” error occurs mostly due to Firewalls blocking access to the server.
If you have access to the private server you are trying to connect to, you can check if the firewall is actually blocking access to your IP. To do so on Linux,
- Open the Terminal
- Enter
sudo iptables -L --line-number
- Check for authentication attempts of your IP address and check if the target accepts or rejects the connection.
You can also check other security filters available on the server. The steps may vary between the respective programs, so check the official website or documentation for the methods.
Then, you need to whitelist your IP address on intrusion prevention apps like Fail2ban, DenyHosts, and so on, to make exceptions to the Firewall rules. The necessary steps to do so on Fail2ban is as follows:
- Open the Terminal and enter
sudo nano /etc/fail2ban/jail.conf
- Remove the # symbol in front of
ignoreip =
and add the IP addresses you want on the line. - For instance, the line can be
ignoreip = 10.10.10.8
- Save and exit.
Warning: Practices such as disabling Firewall or making exception for all IPs on the firewall is not recommended. Firewalls and security filters exist to protect your system. So rather than compromising the security, it’s better to search for a workaround.
Restart Services and Daemons
If you encounter this issue on a private network, it is possible that the server admin has changed the rules for the connection without restarting the daemon services. This causes the service daemons to get stuck as it is still want to conform to the previous settings.
- Contact the server administrator and ask them to restart the service and the daemons in such scenario.
- If you have access to the server, you can do it yourself. First, verify that the services and the daemons are running using systemctl command.
- Restart the relevant daemons. The command you need for this process in a debian-based system is
sudo systemctl restart “daemon name”
For instance, if you are setting up a FTP connection using samba share, you need to use the command sudo systemctl restart smbd
. Since SSH service is available on almost all distros of linux, you don’t have to install any service package for it. So, for SSH connection, the command is sudo systemctl restart ssh
.
And if you are using any other hosting services to set up the connection, you need to restart their daemons as well.
Edit Hosts File
Hosts files allow you to permit or deny access to particular IP addresses or hostnames. If you have access to the server, you should also check these files and make sure your IP address can establish a connection to the server.
To do so for a Debian System,
- Open the Terminal and enter
sudo nano /etc/hosts.deny
- Search for your local IP or host name on the file.
- If it’s there, comment it out by typing # before the line. You can also remove the line altogether.
You can also add your IP address on the hosts.allow
file to force the connection. The process is similar to the above.
- Open the Terminal and enter
sudo nano /etc/hosts.allow
. - Enter your IP address using the syntax is
daemon_list : client_list [: command]
- Save and exit.
The daemon for FTP is usually vsftpd and for ssh, scp, and sftp is sshd. So, to allow ssh connection with local address, 10.10.10.8
, you need to add sshd : 10.10.10.8 , LOCAL
It is also possible to edit the hosts file on Windows based server. You can refer to out article on editing hosts file on Windows for more to learn the necessary process.
Increase Timeout or Send Keepalive Packets
Many networking tools drop idle TCP and FTP connections after a certain period of inactivity.
There are two ways to prevent this issue:
- Increase the timeout period.
- Send periodic heartbeat data.
The first option is not a good solution. Keeping the timeout long can affect the server’s connections to other networks as they have to wait longer before attempting to set up a connection. You also need to increase the timeout on both ends, which is not always possible.
So, the better solution is to send regular heartbeat or keepalive packets. This prevents the connection from being idle and keeps the session alive for longer period.
Some connections allow sending keepalive packets but you have to enable this process for others. Here’s how you can enable the process of sending such packets:
On Linux
- Open the Terminal and enter
sudo nano /etc/sysctl.conf
- Add the following lines while changing the values (in seconds) per your preference:
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_intvl = 10
- Save and exit.
- Enter the command
sysctl --load=/etc/sysctl.conf
The above lines specify that the system waits for 300 seconds before sending the first keepalive packet. Then, it keeps sending the packet every 10 seconds. If it doesn’t receive ACK (acknowledgement) signal for 9 successive times, the connection is dropped.
Increasing the Keepalive period for SSH connections might compromise security as it remains open for a longer time. This connection is supposed to be very secure, so it’s not recommended to make any changes to the keepalive settings for ssh.
On Windows
- Open Run and enter
regedit
. - Navigate to
Computer\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
- Right-click on Parameters
- Add the following DWORD entries along with the respective values (in milliseconds) as you see fit:
- KeepAliveTime – 300000 (in Decimal)
- KeepAliveInterval – 1000
- To add an entry, right-click on Parameter, select New > DWORD (32-bit) Value and enter the name.
- Then, double-click on the entry to change its Value data.
Check sshd_config File
The sshd_config file configures all settings an SSH (Secure Shell) connection uses. So, if possible, you need to check this file on the server and make sure everything is alright.
- Open the file using the command
sudo nano /etc/ssh/sshd_config
. - Look at the options we have provided below and change accordingly. You may also change other options depending on your connection. We recommend checking out the sshd_config documentation for more information.
- After changing these values, save and exit.
- Restart sshd using the command
sudo systemctl restart ssh
Some of the options are:
MaxStartups
The MaxStartups value determines the maximum number of possible unauthenticated connections to the SSH daemon before the connections start dropping.
It has the format MaxStartups 10:30:100
, where,
- 10: Number of unauthenticated connections the dropping starts
- 30: Probability of dropping after reaching the maximum unauthenticated number
- 100: Maximum number of connections possible before dropping all of them
If your remote client needs to make more number of connections concurrently, you need to change these values.
Subsystem sftp
On a secure FTP connection using openssh package, the default value of Subsystem sftp is set to /usr/lib/openssh/sftp-server
. However, sometimes, the openssh binary is available at /usr/lib/ssh/sftp-server
instead. So you can alter this value and check if it works. If it doesn’t, revert it to the previous path.
ClientAlive
ClientAlive is a more secure keepalive setting. You can change the ClientAliveInterval and ClientAliveCountMax values in sshd_config to enable this setting.
ClientAliveInterval determines the interval of inactivity after which sshd sends an encrypted message to the client. And ClientAliveCountMax determines the max number of times sshd sends this message before dropping the connection if it doesn’t get any response.
Check Support for SSL
If the host server has enabled SSL (Secure Sockets Layer) but you haven’t enabled this service on your end, you can’t establish a connection.
So, you need to check the support for SSL on your TCP or any other network client and enable it. If it doesn’t support SSL, you need to use another client.
You also need to check your certificates and make sure you don’t have any malformed keys or certificates.
Change Open Connection Limit
Establishing a network connection also creates a socket, which is the logical window the client uses to communicate with the server. However, a server has a limit on how many sockets it can open at the same time.
If the server has already reached this limit, any new connection causes the server to drop the idle old connections. You can refresh or restart the session to renew the session. However, you can also increase the limit on the server side to facilitate more open connections.
If you want to change the limit for only the current session, you can use the command ulimit -n 65535
, while replacing the number depending on your requirement.
To change it permanently,
- Open the Terminal and enter
sudo nano /etc/security/limits.conf
- Add the following lines while changing the value of the limit if you want:
* soft nofile 65535
* hard nofile 65535
- Save and exit. Then, restart the daemons and the session.
For Debian and Ubuntu systems, you need to enable PAM user limits as well. To do so,
- Enter sudo nano
/etc/pam.d/common-session
- Add
required pam_limits.so
- Add this command on
/etc/pam.d/common-session-noninteractive
as well. - If you are using a SSH connection, add the line to
/etc/pam.d/sshd
Debug Your Scripts and Configurations
Many users have encountered this issue while creating their own connection applications. In such scenario, any bugs in the scripts or configuration that unnecessarily close the connection or don’t conform the connection with the protocol will cause this error.
So, we recommend carefully looking through the program. Some protocols have quit or close commands that makes the host server close the connection.
You also need to close all forked child processes before exiting to prevent zombie processes. The zombie processes stay in the process table even after terminating the child. If there are too many zombie processes, the process table gets full. This way, the system fails to create new processes, disrupting the connection.
If you have trouble debugging your program, we recommend getting help from technical forums such as stackoverflow while providing the source code.