WSAECONNRESET Fix: Connection Forcibly Closed by Remote Host

When This Error Hits You

You're in the middle of a file transfer, or maybe your app is talking to a database, and then — bam. The connection drops. You see WSAECONNRESET (0X00002746) — An existing connection was forcibly closed by the remote host. I've seen this most often with FTP clients trying to upload large files, or with SQL Server Management Studio timing out on a big query. Last month, a small law firm had their entire document management system lock up because this error kept killing their SQL connection every 30 seconds.

What's Actually Happening?

Plain English: Your computer sent data to the server. The server replied with a TCP RST (reset) packet. That's the network equivalent of hanging up the phone mid-sentence. The server decided it didn't want to talk anymore, for one of these reasons:

• The server's firewall or antivirus killed the connection as suspicious
• The server timed out because your request took too long
• The server's app crashed or closed the socket improperly
• There's a misconfigured load balancer or proxy in between

The key thing: it's almost never a physical network issue. The connection was working fine — then it wasn't. That's why the error says "forcibly closed." The server actively terminated it.

The Fix — Step by Step

Step 1: Check Server-Side Firewall and Antivirus

This is the #1 cause. Windows Defender or third-party AV (looking at you, Norton, McAfee) often flag long-lived connections as threats and kill them. On the server (the machine that's closing the connection):

1. Open Windows Defender Firewall with Advanced Security
2. Check inbound rules for your app's port (e.g., 1433 for SQL, 21 for FTP)
3. Make sure there's no rule that drops connections after X seconds
4. Disable any "intrusion prevention" or "network protection" features temporarily

If you're using a third-party firewall, look for "stateful inspection" or "TCP reset" rules. Kill those.

Step 2: Increase Timeout Values

If the server is closing the connection because your client took too long, bump up the timeouts. This is common with SQL queries or large file uploads.

For SQL Server (if that's your use case):

-- On the server, increase remote query timeout (seconds)
EXEC sp_configure 'remote query timeout', 0;  -- 0 = no timeout
RECONFIGURE;

Also increase the connection timeout in your client app. In SSMS: Tools > Options > Query Execution > SQL Server > Advanced > set "SET LOCK_TIMEOUT" to -1 (infinite).

For FTP or file transfers:

In FileZilla, go to Edit > Settings > Transfers > set "Timeout in seconds" to 120 or higher. Also check the server's FTP daemon — most have a Timeout or IdleTimeout setting. Set it to 0 (no timeout) if your security allows.

Step 3: Check for Proxy or Load Balancer Issues

If your traffic goes through a proxy (corporate network) or a load balancer, those devices can kill idle connections. This is especially sneaky because the error message comes from your app, not the proxy. Talk to your network admin and ask them to check if the device is sending RST packets after a certain idle period. Common culprits: F5 BIG-IP with TCP profile settings, or NGINX with proxy_read_timeout set too low.

Step 4: Enable Keep-Alive on the Client

This tells your app to send tiny "I'm still here" packets to the server, preventing timeouts. In Windows, you can set this globally (but be careful — it affects all apps):

reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" /v KeepAliveTime /t REG_DWORD /d 30000 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" /v KeepAliveInterval /t REG_DWORD /d 1000 /f

This sends a keep-alive after 30 seconds of inactivity, then every 1 second until the server responds. Reboot after changing these.

Step 5: Update Network Drivers and Disable Offloading

Bad NIC drivers or hardware offloading (where the network card tries to handle TCP packets itself) can cause random resets. Here's the fix:

1. Go to Device Manager > Network adapters > right-click your NIC > Properties
2. Under the Advanced tab, find "TCP Checksum Offloading" or "Large Send Offload"
3. Set both to Disabled
4. Also disable "VMQ" (Virtual Machine Queues) if present
5. Update the driver from the manufacturer's site — don't use Windows Update

If It Still Fails

You've done all the above and still get the error? Time to capture network traffic. Install Wireshark on both the client and server. Filter for the server's IP and look for packets with the RST flag set. If you see RST from the server, the server's app or OS is killing the connection. If RST comes from somewhere else (like a router IP), that's the middlebox causing it.

One more thing: check the server's event logs (Application and System) for crashes or errors at the exact time the reset happened. A server app crashing silently will close all sockets, and you'll see this error on the client side.

And if you're on a VPN, disconnect and test directly. I've had three clients where the VPN concentrator was sending RST packets for no good reason. Switching to a different VPN protocol (e.g., from OpenVPN to WireGuard) fixed it every time.