A game server that friends cannot join, a remote desktop session that times out, or a security alert about an exposed service often leads to the same question: how to check open ports. The right test depends on what you are trying to confirm. A port can be listening on your computer but blocked by a firewall, forwarded incorrectly by a router, or unreachable from the public internet.
Think of an IP address as a street address and a port as a numbered door at that address. A device can have thousands of possible doors, but only the doors with a service listening behind them can accept traffic. Checking open ports helps you find out which services are available and whether they are visible only inside your network or to the internet.
What an Open Port Actually Means
A port is a number from 0 through 65535 used by TCP or UDP, the protocols that carry most internet traffic. Web servers commonly use TCP port 80 for HTTP and TCP port 443 for HTTPS. Remote Desktop often uses TCP 3389. Many games and voice applications use a mix of TCP and UDP ports.
An open TCP port normally means a device received a connection attempt and a program responded. A closed port means the device is reachable but no service is accepting connections on that port. A filtered result usually means a firewall, router, or ISP is silently blocking the test.
UDP is less straightforward. UDP does not establish a connection the way TCP does, so a scanner may report an UDP port as open, closed, or open|filtered. That last result does not prove a service is available. It means the test did not receive enough information to distinguish an open service from filtered traffic.
The key distinction is scope. A local port check tells you what your device is listening for. An external port check tells you what an outside device can reach through your public IP address. You often need both.
How to Check Open Ports on Your Computer
Start on the device running the service. This is the fastest way to confirm whether the application has opened its intended port.
Check listening ports in Windows
Open Command Prompt as an administrator and run:
“`text netstat -ano “`
Look for entries marked `LISTENING` in the State column. The Local Address column shows the local IP address and port, such as `0.0.0.0:3389`. `0.0.0.0` means the service is listening on all IPv4 network interfaces. An entry beginning with `127.0.0.1` is listening only on the same computer, so it cannot accept connections from other devices.
The final column is the process ID, or PID. To identify the application behind a PID, run:
“`text tasklist /fi “PID eq 1234” “`
Replace `1234` with the PID shown by netstat. This is useful when you find an unexpected listener and need to determine whether it belongs to a known application.
PowerShell provides a more readable option:
“`text Get-NetTCPConnection -State Listen “`
To test whether a TCP port can be reached from the same Windows computer, use:
“`text Test-NetConnection localhost -Port 8080 “`
A successful result confirms that something is responding locally. It does not confirm that the port is accessible from another device or from the internet.
Check listening ports in macOS and Linux
On macOS or Linux, this command lists listening TCP and UDP sockets along with their associated processes:
“`text sudo lsof -nP -iTCP -sTCP:LISTEN “`
On many Linux distributions, `ss` is also available:
“`text sudo ss -tulpn “`
Review the local address carefully. A service bound to `127.0.0.1` or `::1` is intentionally local-only. A service bound to `0.0.0.0` or `::` may be reachable from other devices, subject to host and network firewall rules.
Test a Port From Another Device
Testing from a second device on your home or office network separates application problems from firewall and routing problems. If the service works locally but fails from another device, check the operating system firewall first.
From a Windows computer, run `Test-NetConnection` against the server’s private IP address:
“`text Test-NetConnection 192.168.1.50 -Port 8080 “`
On macOS or Linux, you can use Netcat:
“`text nc -vz 192.168.1.50 8080 “`
Replace the private IP address and port with your own values. Private IPv4 addresses usually begin with `192.168.x.x`, `10.x.x.x`, or fall within `172.16.x.x` through `172.31.x.x`. These addresses work inside a local network but are not directly routable across the public internet.
If this test succeeds, the application is listening and local network traffic can reach it. If it fails, review the application configuration, the device firewall, and whether the service is bound to the correct network interface.
Check Whether a Port Is Open to the Internet
An external test must come from outside your network. Testing your own public IP from a device connected to the same Wi-Fi network can produce misleading results because some routers do not support NAT loopback, also called hairpin NAT.
First, identify your public IPv4 address. This is the address assigned to your router or gateway by your ISP, not the private address shown on your computer. WhatIsMyPublicIP.com can display that public-facing address immediately, which is useful when comparing it with the WAN or Internet IP shown in your router settings.
Then use a port-scanning utility from an external network, such as a mobile phone using cellular data, a trusted remote server, or an authorized external testing service. Nmap is a common command-line option for TCP testing:
“`text nmap -Pn -p 25565 203.0.113.10 “`
Replace the example IP and port. The `-Pn` option tells Nmap not to rely on a ping response before scanning. Scan only IP addresses and systems you own or have explicit permission to test. Port scanning third-party systems without authorization can violate policies or trigger security monitoring.
For a quick check of several expected services, specify them together:
“`text nmap -Pn -p 80,443,25565 203.0.113.10 “`
A result of `open` means the target answered on that TCP port. `closed` means the public IP was reachable but no service accepted the connection. `filtered` means a firewall or network device prevented Nmap from determining the port state.
Why a Port Can Be Open Locally but Closed Externally
Home networks commonly use network address translation, or NAT. Your router shares one public IPv4 address among phones, computers, consoles, and smart devices that each have separate private IP addresses. An unsolicited inbound connection reaches the router first, not your computer.
To make a local server accessible, create a port-forwarding rule in the router. The rule maps an external port to a specific private IP address and internal port. For example, TCP 25565 might forward to `192.168.1.50:25565` for a game server. Reserve that device’s IP address in the router or configure a stable DHCP reservation so the rule does not point to the wrong device after a restart.
A correct forwarding rule still will not work if Windows Defender Firewall, macOS Firewall, or a Linux firewall blocks the service. Allow only the exact port and protocol required. If the application needs UDP, a TCP-only forwarding rule will not solve the problem.
Your ISP can also be the obstacle. Some providers block inbound ports associated with email servers or other commonly abused services. Others place residential customers behind carrier-grade NAT, or CGNAT. With CGNAT, the WAN address on your router is not truly public, so normal port forwarding cannot receive unsolicited internet traffic. Ask your ISP whether it offers a public IPv4 address, a static IP option, or IPv6 connectivity.
Do Not Forget IPv6
IPv6 changes the usual home-network pattern. Devices may receive globally routable IPv6 addresses, meaning they can potentially be reached without IPv4-style NAT or port forwarding. That does not mean every service should be exposed.
Your router and device firewall should still block unsolicited inbound IPv6 traffic by default. When testing an IPv6 service, use the device’s public IPv6 address and verify the firewall rule separately. An IPv4 port scan does not test IPv6, and the reverse is also true.
What to Do When You Find an Unexpected Open Port
An open port is not automatically a problem. A web server needs web ports; a VPN gateway needs its configured VPN port. The concern is an exposed service you did not intend to run or no longer need.
Identify the owning process, confirm why it is running, and update the software if it is legitimate. If it is unnecessary, stop or uninstall the service and remove any router forwarding rule. For services that must remain public, use strong unique credentials, disable default accounts, apply updates promptly, and limit access by IP address or VPN where practical.
Avoid exposing remote management interfaces, file shares, databases, and Remote Desktop directly to the internet unless you have a clear operational reason and appropriate security controls. A VPN or managed remote-access solution is often the safer choice.
Checking ports is most useful when it leads to a specific decision: fix a service that should be reachable, or close one that should not. Test from the right location, verify the router and firewall path, and leave only the doors you genuinely need open.
