How to Use the Windows PowerShell ‘Test-NetConnection’ Command to Diagnose Network Issues

The Legacy of Ping and Tracert

For decades, when a Windows user couldn’t connect to the internet, they would open the Command Prompt and type ping google.com. If they needed to see where the connection was failing, they would type tracert google.com.

While these tools are iconic, they rely entirely on the ICMP protocol. Modern enterprise firewalls and cloud services routinely block ICMP traffic for security reasons. This means you might ping a web server and get a “Request Timed Out” error, leading you to falsely believe the server is offline, even though the actual website (running on TCP port 443) is working perfectly.

To perform accurate network diagnostics in modern, firewalled environments, Windows administrators must use the PowerShell cmdlet: Test-NetConnection (often aliased as tnc).

1. The Superior Ping

At its most basic level, Test-NetConnection acts like a highly detailed ping.

Test-NetConnection google.com

Unlike the classic ping command, which just spits out raw millisecond times, Test-NetConnection returns a structured PowerShell object. It tells you the resolved IP address, the interface alias (e.g., “Wi-Fi” or “Ethernet”) it used to route the traffic, the source IP of your machine, and whether the ping was successful.

2. Testing Specific TCP Ports (The Game Changer)

This is where the cmdlet shines. If you want to know if a server is actually listening for web traffic, or if a database port is open through the firewall, you can test specific TCP ports directly.

To test if a server is allowing remote desktop (RDP) connections on port 3389:

Test-NetConnection 192.168.1.50 -Port 3389

PowerShell will attempt a full TCP handshake. Look at the TcpTestSucceeded field in the output. If it says True, the port is open and the firewall is allowing the traffic. If it says False, the connection is blocked, regardless of whether a standard ICMP ping succeeds.

(Note: For common services, you don’t even need to know the port number. You can use the -CommonTCPPort parameter, like -CommonTCPPort HTTP or -CommonTCPPort SMB).

3. Performing Route Tracing

If the connection fails and you need to see exactly which router or firewall along the path is dropping the packets, you can invoke a route trace (similar to tracert).

Test-NetConnection 8.8.8.8 -TraceRoute

This provides a clean, hop-by-hop breakdown of the route your data takes across the internet or your internal network.

4. Detailed Diagnostic Information

If you are troubleshooting a complex routing issue on a machine with multiple network cards (e.g., a laptop connected to both Wi-Fi and a physical Ethernet dock), you need to know exactly how Windows is deciding to route the traffic.

Add the -InformationLevel Detailed flag to any command:

Test-NetConnection digitash.com -InformationLevel Detailed

This outputs a massive amount of diagnostic data, including the exact Next Hop (Gateway) MAC address and the specific network adapter Windows chose to prioritize for the connection.

Conclusion

The classic DOS-era networking commands are no longer sufficient for diagnosing modern, heavily secured networks. By migrating your troubleshooting workflow to the PowerShell Test-NetConnection cmdlet, you can perform deep TCP port analysis, bypass ICMP blocks, and receive structured, scriptable diagnostic data.