A Field Guide to netsh, Get-NetTCPConnection, and Test-NetConnection for VPS Network Troubleshooting

Network faults on a Windows VPS usually show up as a single symptom — “the app can’t connect” — while the cause sits somewhere between DNS, the firewall, the listener, and the provider’s edge. Three tools cover most of that ground: Test-NetConnection for end-to-end reachability, Get-NetTCPConnection for local listener state, and netsh for the lower-level interface, firewall, and trace work. Knowing which to reach for, and in what order, cuts troubleshooting time dramatically.

Start With Test-NetConnection

Test-NetConnection is the modern replacement for telnet-based port checks and answers several questions at once.

• Test-NetConnection web01 -Port 443 — does the TCP handshake complete? TcpTestSucceeded: True is the answer you want.
• Test-NetConnection web01 -InformationLevel Detailed — adds source address selection, ping results, and route hints; useful when a host is reachable by IP but not by name.
• Test-NetConnection 10.0.0.5 -TraceRoute — shows the path, which exposes asymmetric routing and provider edge problems.
• Use the IP form to separate a DNS failure from a connectivity failure: if the IP works and the name does not, the problem is resolution, not transport.

Then Check the Local Listener

If the connection fails from outside, confirm something is actually listening and on which address.

• Get-NetTCPConnection -State Listen — every TCP listener with its local address and owning process.
• Get-NetTCPConnection -LocalPort 443 -State Listen | Select-Object LocalAddress, OwningProcess — narrow to the port in question.
• Get-Process -Id (Get-NetTCPConnection -LocalPort 443 -State Listen).OwningProcess — identify the process behind the port.
• A listener bound to 127.0.0.1 will never accept remote traffic. This is the most common cause of “the service is running but unreachable” on a VPS.

netsh for the Lower Layers

• netsh interface ipv4 show config — full interface configuration including metrics, which decide which NIC wins when several are present.
• netsh advfirewall firewall show rule name=all — dump every firewall rule; search for the port and check profile, protocol, and action.
• netsh advfirewall firewall add rule name="App 8090" dir=in action=allow protocol=TCP localport=8090 — add an allow rule when you have confirmed the listener is correct.
• netsh trace start capture=yes tracefile=C:\temp\net.etl then netsh trace stop — a built-in packet capture when you need evidence for the provider.
• netsh int ip reset and netsh winsock reset — last-resort stack repairs that require a reboot.

A Diagnostic Order That Works

Step	Command	What a failure means
1. Resolve name	Resolve-DnsName host	DNS / zone / forwarder issue
2. Test port	Test-NetConnection host -Port n	Route, firewall, or listener
3. Confirm listener	Get-NetTCPConnection -LocalPort n -State Listen	App not bound or bound locally only
4. Check firewall	netsh advfirewall firewall show rule name=all	Local rule blocking the traffic
5. Capture	netsh trace start	Evidence for provider escalation

Provider-Edge Problems Are Their Own Category

If steps 1-4 all pass locally but traffic still does not arrive, the block is outside the VM: a provider firewall, a security group, or an upstream ACL. This is where the netsh trace capture earns its keep — it is the artifact a support engineer can act on. Keep a note of the ports you actually use and open only those; a tidy, documented set of inbound rules makes escalation faster and audits shorter. If inconsistent results point to the host platform rather than your configuration, it is worth reviewing the VPS platform choices before you assume the app is at fault.

Keep the Toolkit Close

These three commands cover name resolution, port reachability, local binding, firewall state, and packet evidence — the whole chain from client to listener. Practicing them on a known-good server first means that when something breaks at 2 a.m., the sequence is muscle memory rather than guesswork.