What is a Port Check?
Every network service runs on a numbered port — a logical endpoint that lets your operating system route incoming connections to the correct application. Web servers listen on port 80 (HTTP) and 443 (HTTPS), SSH daemons on port 22, and databases on their own dedicated ports. When you run a port check, you test whether that endpoint is reachable from the outside world.
TCP vs UDP
TCP (Transmission Control Protocol) is connection-oriented. To check a TCP port, a tool initiates a three-way handshake (SYN → SYN-ACK → ACK). If the remote server completes the handshake, the port is open. If it sends back a RST (reset) packet, the port is closed. If there is no response at all, the port is likely filtered — blocked by a firewall before the packet ever reaches the service.
UDP (User Datagram Protocol) is connectionless and harder to test definitively. A UDP port check sends a datagram and waits for a response or an ICMP "port unreachable" message. Silence can mean the port is open and the service is running, or it may mean a firewall is silently dropping packets — context and protocol-aware probing usually help disambiguate.
Port States Explained
Every port check returns one of three results. Open means a service is actively listening on the port and accepted the connection — your application is reachable. Closed means the host responded but no service is listening — the port is accessible but not in use. Filtered means a firewall, security group, or ACL blocked the connection and no response was received within the timeout window.
Common Reasons to Check a Port
Verify a newly deployed service is accessible after configuring firewall rules. Troubleshoot why users cannot connect to a database or API endpoint. Confirm a VPN or hosting provider is not blocking specific ports. Test whether a service is reachable globally or only from certain regions. Validate that a security configuration correctly blocks unauthorized ports.