WSAECONNREFUSED 0X0000274D: Target Machine Refused Connection
This error means a service on the target machine isn't listening or a firewall is blocking you. Fix it in steps starting simple.
The 30-Second Fix: Check the Basics
You're getting WSAECONNREFUSED (0X0000274D) — the target machine literally told your computer to buzz off. Before you go deep, check one thing: is the service actually running? I've seen this countless times with Remote Desktop on Windows Server. Had a client last month whose entire print queue died because of this. He'd rebooted the print server, but the Spooler service hadn't started. Same with SQL Server, IIS, or any listening app.
On the target machine, open Services.msc and look for the service you're connecting to. For Remote Desktop, it's Remote Desktop Services (TermService). Make sure it's running, not stopped. If it's stopped, right-click and Start. Then try your connection again. That's it. You're done in under a minute.
The 5-Minute Fix: Telnet and Firewalls
If the service is running but you still get the error, it's usually a firewall or the wrong port. Don't guess — test. Open Command Prompt on the client machine and run:
telnet 192.168.1.50 3389Replace that IP with the target machine's IP and 3389 with the port you're trying (1433 for SQL, 80 for HTTP, 443 for HTTPS). If you get a black window or a blinking cursor — good, the port is open and listening. If you get Connecting To... Could not open connection, then the port is blocked or nothing's listening.
If telnet fails, check the Windows Firewall on the target machine. Run wf.msc and look for an Inbound Rule that allows traffic on that port. For Remote Desktop, the rule is named Remote Desktop (TCP-In). If it's disabled, enable it. Also check if a third-party antivirus firewall (like Norton, McAfee, or the built-in Windows Defender Firewall) is blocking it. Turn that off temporarily to test — I've seen Kaspersky silently block SQL ports more times than I can count.
The 15+ Minute Fix: Service Bindings and Port Conflicts
Still broken? The service might be listening on the wrong IP or port. Run this on the target machine with admin rights:
netstat -ano | findstr :3389Change the port number to yours. You'll see output like:
TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING 1234If you see 0.0.0.0:3389, it's listening on all interfaces — good. If you see 127.0.0.1:3389, it's only listening locally, so remote connections won't work. That happens sometimes with SQL Server when the TCP/IP setting is misconfigured. Check your service's configuration to bind to All IPs or a specific external IP.
Also check for port conflicts. Run netstat -ano and look for anything else using that port. If another service is hogging it, you'll see ESTABLISHED or LISTENING with a different PID. Use tasklist | findstr 1234 to identify the process. You can kill it with taskkill /PID 1234 /F or change the port on the conflicting service.
One more thing — if you're on a corporate network, the network team might have a firewall between subnets blocking the port. Run a traceroute to see if you hit the target:
tracert 192.168.1.50If it stops at a router before the target, that's your clue. Talk to the network admin.
When to Give Up and Reboot
After all this, if the error persists, reboot both machines. I've seen weird socket states that only clear with a restart. Had a client last month whose SQL Server had a hung listener after a patch — reboot fixed it in two minutes. Sometimes the simplest thing works.
Was this solution helpful?