You're running a query from your app or SQL Management Studio, and bam — WSAEREFUSED (0X00002780). It's that moment when the database server just says "no thanks" to your connection attempt. This usually happens right after you deploy a new app, change a connection string, or restart the database server. The error is Windows Sockets' way of saying "connection refused" — the server got your request, but nothing was listening on the port you aimed at, or something actively blocked it.
Root cause: It's a network handshake rejection
When your client tries to connect to SQL Server (or any database), it sends a TCP SYN packet to the server's IP and port (default 1433 for SQL Server). If the server isn't listening on that port, or a firewall drops the packet, the server responds with a RST (reset) packet. That triggers WSAEREFUSED. In plain English: you knocked, but nobody answered — or the bouncer turned you away.
The culprit is almost always one of three things:
- SQL Server isn't listening on TCP/IP at all (it's disabled in configuration).
- A firewall (Windows Defender, third-party, or network hardware) is blocking port 1433.
- The server is listening, but on a non-standard port, and your connection string is pointing to the wrong one.
I've seen this error a hundred times, and it's rarely the database itself being down. It's a configuration mismatch or a firewall rule that's too strict. So let's fix it step by step.
Fix: Step-by-step
Step 1: Verify SQL Server is listening on TCP/IP
Open SQL Server Configuration Manager on the server. Under SQL Server Network Configuration, select your instance (e.g., MSSQLSERVER). Right-click TCP/IP and choose Enable. Then double-click TCP/IP, go to the IP Addresses tab, scroll to IPAll, and note the TCP Port (should be 1433 unless you changed it). If it's blank, set it to 1433 in the TCP Port box. Restart the SQL Server service after any change.
Step 2: Check if the port is actually listening
On the server, open Command Prompt as admin and run:
netstat -an | findstr :1433If you see a line with LISTENING on 0.0.0.0:1433, you're good. If nothing shows up, TCP/IP isn't enabled or the port is different. If you see 127.0.0.1:1433 listening, that means it's bound to localhost only — you'll need to change the IP addresses in the TCP/IP settings to allow remote connections.
Step 3: Check your connection string
If the port is 1433, but your connection string says something like Server=myserver;Database=myDB, that works. But if you're using a named instance (e.g., myserver\SQLEXPRESS), the client tries to use UDP 1434 to find the port — and if that's blocked, you'll get refused. Instead, specify the port directly:
Server=myserver,1433;Database=myDB;User Id=sa;Password=...;This bypasses the SQL Browser service, which is often the weak link. I've wasted hours on that one — trust the explicit port.
Step 4: Open the firewall on the server
On the SQL Server machine, open Windows Defender Firewall with Advanced Security. Create an inbound rule for TCP port 1433 (or your custom port). Make sure it allows the connection for Domain, Private, and Public profiles — depending on your network. Here's a quick command to add it:
netsh advfirewall firewall add rule name="SQL Server" dir=in action=allow protocol=TCP localport=1433Run that as admin, and you're set. For named instances, also allow UDP 1434 — but honestly, just stick to the explicit port approach and you can skip that.
Step 5: Test from the client
From the machine where the error appears, test TCP connectivity to the server and port:
telnet myserver 1433If telnet isn't installed (it's not by default on Windows 10/11), use PowerShell:
Test-NetConnection myserver -Port 1433If the TcpTestSucceeded result is True, your network path is fine — the problem is in the app or SQL config. If it's False, the firewall on the server or a network device is blocking. Check your cloud security group if it's AWS or Azure — that's a common gotcha.
Still failing? Check these next
You've done all the above and still see 0X00002780? Here's where I'd look next:
- SQL Server service status: Is the actual SQL Server service running? Sounds obvious, but after a restart it can fail to start. Check Services.msc.
- Network path: Are there any VPNs or proxies in between? A VPN that blocks certain ports can cause this. Try a direct IP instead of a hostname.
- Antivirus interference: Some security suites block SQL ports. Temporarily disable it (if your policy allows) to test — I've seen Norton and McAfee do this.
- Multiple instances: If you have more than one SQL Server instance, one might be grabbing the port. Run
netstat -anoand check for conflicts.
The WSAEREFUSED error is a stubborn one, but it's almost always a config issue you can fix in ten minutes. Once you've got the port open and the connection string pointing to the right place, you'll be back to querying without a hitch. And if you ever hit it again, just remember: it's not the database being mean — it's the network saying "not today."