PowerShell Test-NetConnection: check ports and connections on Windows
Published on 2026-10-26 by frfrand
Diagnose connectivity to an API, SSH, or PostgreSQL with PowerShell
An API is not responding and someone says «the server is down». Before restarting anything, you can check from Windows if you resolve the domain and if you reach the expected port. PowerShell already includes Test-NetConnection for that task.
The idea is to use it to solve a real problem, not to memorize commands because they look good in a screenshot. Let's go with the essentials, a work example, and the errors you should avoid most.
What Test-NetConnection does and when it is useful
A correct TCP test confirms connectivity up to a port, not that the application responds correctly. Ping uses ICMP and can fail even if HTTPS works. Separating DNS, TCP, TLS, and HTTP saves you from touching services that are not failing.
If you are learning, try it first in a repository or test environment. If you manage production, document the status before executing anything that alters files, history, or data. This allows you to understand what changed and recover if you make a mistake.
Example to copy and understand
Resolve-DnsName api.ejemplo.com
Test-NetConnection api.ejemplo.com -Port 443
Test-NetConnection api.ejemplo.com -Port 22
# Test TCP no equivale a verificar respuesta HTTP
Invoke-WebRequest https://api.ejemplo.com/healthDo not copy the final command without checking the previous status. Branch names, host, user, or paths are examples; replace them with those of your project. Some commands modify files or make requests that can write data.
How I would use it step by step
- Step 1. First check whether the name resolves to the expected IP.
- Step 2. Test port 443; if it fails, review network, firewall, and whether the process is listening.
- Step 3. If TCP works, make an HTTPS request to verify certificate and response.
- Step 4. Compare the result from another network to distinguish local restrictions.
- Step 5. Contrast with server logs before changing rules.
Stop after each step and verify the result. If something fails, note the exact message before changing strategy. Jumping between five random solutions usually makes it harder to find the real cause.
A case that could happen to you working with clients
You published a FastAPI API on a VPS and your computer reaches port 443, but /health returns 502. That points the problem toward Nginx or the upstream process, not necessarily toward DNS or the firewall.
The goal is not for it to "work once," but for you to be able to explain how you repeat it without compromising another application. If there are client data or credentials, work with separate tests and minimal access.
The most common mistake I see
Do not interpret PingSucceeded: False as server downtime. Many machines deliberately block ICMP. The PostgreSQL port should not be exposed just so this test returns True from the Internet.
A simple rule: if you can't explain what the command will do to your code or server, check its official help first. This way you avoid confusing a quick fix with a new problem.
Where does ArduMaker come in?
From ArduMaker you can review domain, services, and terminal of the VPS. Combining that data with PowerShell tests from your machine helps find at which point the connection fails.
For example, you can deploy from a Git repository to a VPS, associate an HTTPS domain, and manage services and databases from the same environment. The panel reduces repetitive infrastructure tasks, but does not replace Git, testing, or reviewing project permissions.
Quick questions before applying it
Does this change production? It depends on where you run the action. Test locally first, identify the affected commit or service, and prepare a recovery plan.
How do I verify it went well? Don't settle for the absence of error messages: check the status, run a functional test, and verify the corresponding logs or history.
Is it worth automating it? If it's repeatable and has verifiable results, yes. But automation should fail clearly and not hide errors or credentials.
To expand
Summary: the useful tool is not the one with the most options, but the one that allows you to understand what changed, verify it, and keep working without surprises.