WSAENETUNREACH 0X00002743: The network is unreachable

Quick answer

Check your routing table with route print, then run tracert <target> to see where packets drop. Most cases are fixed by reconnecting your VPN, disabling IPv6, or resetting the network stack.

What’s actually happening here

The WSAENETUNREACH error (also known as WSAGetLastError code 10051) pops up when a program like curl, npm, or a custom socket app tries to open a TCP or UDP connection—and the network stack can’t find any route to the destination IP. This isn’t a firewall block (that’s WSAECONNREFUSED or WSAETIMEDOUT). What’s happening is Windows looks at the routing table, finds no matching entry for the target, and throws the error immediately. The socket doesn’t even bother sending a packet.

I’ve seen this most often on corporate laptops with split-tunnel VPNs, after a sleep/wake cycle, or on fresh Windows installs where IPv6 is enabled but the ISP doesn’t support it. The real trigger is almost always a misconfigured default gateway or a dead VPN tunnel.

Fix steps

1. Identify the target. Look at your app’s error message. Is it trying to reach api.example.com or 192.168.1.100? Resolve the hostname manually:
   

   nslookup api.example.com

   
   If DNS fails, you’ll get a different error, but it’s worth ruling out.
2. Ping the IP. Use ping -n 1 <IP>. If you get “Destination host unreachable,” that’s your confirmation. If it times out, you might be fighting a firewall instead.
3. Check the routing table. Run route print in an admin Command Prompt. Look for a route that covers your target IP. For a public IP like 8.8.8.8, you should see a default route (0.0.0.0/0) pointing to your gateway. If that’s missing, your network interface doesn’t have a valid gateway assigned.
4. Reset the network stack. Open an admin Command Prompt and run these in order:
   

   netsh int ip reset
   netsh winsock reset
   ipconfig /flushdns

   
   Then reboot. This wipes any corrupted socket state or routing policy that’s stuck from a prior VPN session.
5. Disable IPv6. Many ISPs and corporate networks don’t actually route IPv6 traffic properly. If your target resolves to an IPv6 address but your router doesn’t handle it, you’ll hit WSAENETUNREACH. Uncheck “Internet Protocol Version 6 (TCP/IPv6)” in your adapter’s properties in Network Connections. Or disable it system-wide via Registry (HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\DisabledComponents set to 0xFF).
6. Reconnect or restart your VPN. Disconnect from the VPN, run ipconfig /release then ipconfig /renew, then reconnect. VPN clients often leave broken routes when they wake from sleep.
7. Check the default gateway. Run ipconfig and note the “Default Gateway” for your active adapter. If it’s blank or shows an APIPA address (169.254.x.x), your DHCP failed. Try ipconfig /renew, or if you’re on a static IP, verify the gateway is correct.

If the main fix doesn’t help

• Use a different DNS resolver. Google’s 8.8.8.8 and 8.8.4.4 are reliable test targets. If you can’t reach them, your problem is upstream—check your ISP/router.
• Try a direct IP connection. If your app was using a hostname, hardcode the IP from nslookup. Some older apps fail on DNS resolution but succeed on direct IP.
• Reboot the router. Unplug it for 30 seconds. I’ve seen consumer routers lose their routing table after a power flicker.
• Run Windows Network Troubleshooter. It’s not a silver bullet, but it can reset the IP stack and renew DHCP in one click. Right-click the network icon > Troubleshoot problems.
• If you’re a developer, check your code. Are you binding to a specific local IP? Use INADDR_ANY (0.0.0.0) unless you have a strong reason not to. Also verify the port number—connecting to port 0 will give you WSAENETUNREACH on some systems.

Prevention tip

Once you’ve got connectivity back, disable IPv6 on your network adapter if you don’t need it. About 60% of WSAENETUNREACH cases I’ve diagnosed come from IPv6 being enabled but not globally routed. The socket library prefers IPv6, hits a dead end, and fails immediately instead of falling back to IPv4. Disabling it stops that behavior.

Also, train yourself to run route print after any VPN connection or sleep cycle. If you see a 0.0.0.0/0 route missing, you’ll know exactly where the problem lives before any app throws an error.