The port checker tests whether a specific TCP port is open on a remote host. Enter a hostname or IP address, select one or more ports, and get an instant result — open, closed, or filtered — with response time, DNS resolution details, and a short explanation of what the status means.
It is useful for system administrators and network engineers who need to quickly verify firewall rules, confirm service availability, or troubleshoot connectivity without installing additional tools.
How to use
- Enter a hostname or IP address in the first field — for example
example.comor203.0.113.10. If you enter a hostname, the tool will resolve and display its IP address automatically. - Enter one or more port numbers in the second field. Separate multiple ports with commas — for example
80, 443, 3389. You can check up to 5 ports at once. - Use the preset buttons — HTTPS 443, HTTP 80, RDP 3389, SSH 22, SMB 445, DNS 53 — to fill in common ports quickly. Clicking a preset again removes it from the list.
- Click Check port and wait for the results. Each port is checked individually and returns its own status badge, response time, and explanation.
- If you entered a hostname, the result block shows the resolved IP address and the PTR record when available. This helps confirm you are testing the correct host.
- Use Copy results to copy the full summary to the clipboard — including host, resolved IP, and all port statuses — in a plain-text format suitable for documentation or tickets.
- Recent checks are saved automatically. Click any entry in the history list to reload that host and port combination instantly.
Understanding the result
OPEN means the TCP connection was accepted. The host is reachable on that port and a service is actively listening. This is the expected result for publicly accessible services such as a web server on port 443 or an SSH server on port 22.
CLOSED means the connection was refused immediately. The host is reachable but no service is listening on that port, or the service is explicitly rejecting connections. This typically happens when a service is stopped or configured to reject connections from outside.
FILTERED means no response was received within 5 seconds. This usually indicates a firewall is silently dropping packets to that port rather than refusing them. A filtered result does not mean the host is down — it means something is blocking the connection before it reaches the service.
Practical examples
Verify a firewall rule after a change. You updated an NSG or Windows Firewall rule to allow inbound RDP on port 3389. Enter the server’s public IP and port 3389 to confirm the rule is active before attempting a Remote Desktop connection. A FILTERED result means the rule has not propagated or is applied at the wrong level.
Diagnose a web application that is not loading. Check ports 80 and 443 together on the same hostname. If 80 is OPEN but 443 is FILTERED, the issue is likely a missing HTTPS listener or a firewall rule that does not cover the secure port. Checking both at once avoids running two separate lookups.
Confirm a new service is listening before updating DNS. After deploying a service, check the expected port directly against the server IP to verify the process started and bound to the correct port. Use the preset buttons to add common ports quickly and check several candidates in one request.
Audit exposed services on a public server. Check ports 22, 445, 3389, and 1433 together to get a quick overview of which management and database ports are reachable from outside. A CLOSED or FILTERED result for SMB and RDP is the expected and correct state for most public-facing servers.
FAQ
Port checker help
CLOSED means the target host actively refused the connection — the port sent back a TCP RST packet. FILTERED means no response came back within the timeout period, which usually means a firewall is silently dropping packets. CLOSED confirms the host is reachable; FILTERED does not.
Yes. Enter up to 5 port numbers separated by commas in the port field — for example 80, 443, 3389. Each port is tested individually and returns its own status. You can also use the preset buttons to add common ports quickly and toggle them on or off before running the check.
When you enter a hostname, the tool resolves it to an IP address using a DNS A record lookup and displays the result above the port status. If a PTR (reverse DNS) record exists for that IP, it is shown as well. This confirms you are testing the correct host and often reveals the hosting provider or CDN in use.
The tool saves your last 10 checks in your browser’s local storage. Each entry shows the hostname, port statuses, and the time of the check. Click any entry to reload that host and port combination into the form. History is stored locally and is never sent to the server.
No. This tool runs checks from the zaur.it server, which has no access to your local network. Private address ranges such as 192.168.x.x, 10.x.x.x, and 172.16–31.x.x are blocked. To test ports on internal hosts, use PowerShell’s Test-NetConnection command or a local port scanning tool.
No. This tool checks TCP ports only. UDP is a connectionless protocol and does not confirm whether a port is open in the same way TCP does. Reliable UDP port checking requires raw socket access, which is not available on shared hosting.
OPEN means the TCP connection was accepted — a process is listening on that port. It does not guarantee the service is functioning correctly. A web server could accept connections on port 443 but return errors, or an SSH daemon could be listening but rejecting authentication. Use application-level tools to verify the service itself.
When a port is closed, the host sends back a TCP RST immediately — typically in under 1 millisecond. The tool rounds to the nearest millisecond, so very fast refusals display as 0 ms. This is correct behaviour and not a display error.
Related guides
- How to check open ports on Windows — built-in tools vs port checker — when to use netstat, Test-NetConnection, and an online tool, and what each output means.
- Netstat command in Windows — view active connections, listening ports, and routing tables from the command line.
- Nslookup in Windows — DNS troubleshooting — resolve hostnames, query specific record types, and diagnose DNS issues before running a port check.
Related tools
- DNS lookup — check A, AAAA, MX, TXT, CNAME, NS, and other record types for any domain.
- Reverse DNS lookup — find the PTR record for any IP address to identify the host behind it.
- Network diagnostics tool — run HTTP and HTTPS reachability checks with latency and jitter measurements.
- WHOIS lookup — query registration and ownership information for any domain or IP block.
- IP subnet calculator — calculate subnet ranges, masks, available hosts, and allocation details.
Reference
- Common network ports cheat sheet — a quick-reference table of TCP and UDP port numbers for the services you work with most.