Ports & Firewall: Is Something Blocking the Connection?
How to manually check whether a specific port is open, and whether a firewall is the reason it isn't.
Tools required: Test-NetConnection (PowerShell), telnet (optional), Windows Firewall
Overview
A domain resolving correctly doesn't mean the service behind it is reachable. This guide checks a specific TCP port directly, and tells apart the three outcomes that look similar but mean very different things: 'connection refused' (something is listening but rejecting), 'timed out' (nothing answered at all, often a firewall silently dropping it), and 'open' (working).
Step-by-Step Manual Check
Test whether the port is open from your machine
PowerShell's Test-NetConnection is a modern replacement for telnet that also reports basic route information.
Test-NetConnection -ComputerName example.com -Port 443Replace example.com and 443 with your target host and port. On macOS/Linux use: nc -zv example.com 443
Healthy result
ComputerName : example.com RemoteAddress : 93.184.216.34 RemotePort : 443 TcpTestSucceeded : True
Problem result
TcpTestSucceeded : False (with WARNING: TCP connect to (93.184.216.34 : 443) failed)
What it means
TcpTestSucceeded: True means the port is genuinely open and something is listening. False on its own doesn't tell you WHY yet - continue to Step 2 to tell apart 'refused' from 'timed out'.
If unresolved, escalate to: Level 1 — Basic
Distinguish 'connection refused' from 'timed out'
These two failure modes point to completely different root causes, but PowerShell's summary output doesn't always make the distinction obvious - a raw connection attempt does.
telnet example.com 443telnet may need enabling via 'Windows Features' on Windows. On macOS/Linux it's usually preinstalled, or use nc -v.
Healthy result
Connected to example.com. (a blank/connected screen - the port accepted the connection)
Problem result
Connection refused. (fast failure, seconds) -- OR -- Connecting... (hangs for a long time, then times out)
What it means
'Connection refused' fails FAST and means a device actively answered and rejected you - typically no service is listening on that port, but the host itself is reachable. A 'hang then timeout' means nothing answered at all - most commonly a firewall (yours, the destination's, or something in between) silently dropping the packets rather than rejecting them.
If unresolved, escalate to: Level 1 — Basic
Check your own machine's firewall rules for the port
Before assuming the remote side is at fault, rule out your own outbound firewall rules.
Get-NetFirewallRule -Direction Outbound -Enabled True | Where-Object { $_.DisplayName -like "*443*" -or $_.DisplayName -like "*HTTPS*" }Adjust the port/keyword to match what you're testing. This lists outbound rules; for inbound (i.e. testing a server you run), swap -Direction Inbound.
Healthy result
(No blocking rules found - default Windows Firewall allows all outbound by default, so an empty result here is normal and healthy)
Problem result
DisplayName: Block HTTPS Outbound Action: Block Enabled: True
What it means
If you find an active Block rule matching the port, that's your answer - your own firewall is the cause, no need to look further. If nothing blocks it locally, the problem is on the remote side or somewhere on the network path in between.
If unresolved, escalate to: Level 2 — Intermediate
Confirm the remote firewall/security-group state (if you manage the destination)
If you have access to the destination server or its cloud security group/firewall, confirm the port is explicitly allowed for the source you're testing from.
netsh advfirewall firewall show rule name=all | findstr /i "443"Run this ON the destination server, not your own machine. For cloud-hosted servers, also check the provider's security group/network ACL, which filters traffic before it even reaches the OS firewall.
Healthy result
Rule Name: Allow HTTPS Enabled: Yes Direction: In Action: Allow LocalPort: 443
Problem result
(No matching rule found, or a rule exists but Enabled: No)
What it means
A missing or disabled inbound Allow rule for the port on the destination server explains a 'timed out' result perfectly - the server's own firewall is dropping the traffic before any application ever sees it.
If unresolved, escalate to: Level 3 — Expert / Critical
Interpreting the Results
The key diagnostic split is refused vs. timed out. Refused = something answered, no service listening (an application-layer problem - check the service is actually running). Timed out = nothing answered at all (a firewall problem - check both ends and everything in between, including cloud security groups).
Common Causes
| Symptom | Likely Cause | Fix |
|---|---|---|
| Connection refused | No application/service is actually listening on that port on the destination | Start/restart the service, or confirm you're using the correct port. |
| Times out from off-site but works locally on the server | Firewall or cloud security group blocking inbound traffic from external IPs | Add an explicit Allow rule for the port from the required source. |
| Works for HTTP (80) but not HTTPS (443) | Only one port has an allow rule configured | Add the missing port to the firewall/security group rule set. |
Automated by
Diagnostic Suite - Network Security Diagnostic & Fix (Option 1)
Automatically checks ports 80, 443, and 22 and reports open/closed/timed-out for each.