ToolActToolAct

Port Check Tool

Check if specific ports are open on any IP address or domain

Quick Fill:

Check up to 20 ports at once

Enter an IP address and port numbers, then click "Check Ports"

What is a Port Checker?

The Port Checker tests whether a specific network port on a host appears reachable. Ports represent services such as HTTP, HTTPS, SSH, SMTP, databases, or custom applications; when a port cannot be reached, the cause may be server status, firewall rules, NAT, DNS, routing, cloud security groups, or a service bound only to localhost. The tool helps with deployment checks, troubleshooting, monitoring, and confirming whether a service is visible from the outside. An open port does not automatically mean the application is healthy or secure, and a closed port does not reveal the exact cause by itself. Security assessment still requires protocol, authentication, configuration, and exposure review.

How to Use

How to use

  1. Enter the target server address in the IP/Domain field
  2. Enter port numbers to check, separated by commas
  3. Or use the quick fill buttons for common port presets
  4. Click "Check Ports" and wait for results
  5. View each port's status, response time, and any error messages

Network Interpretation

  • A closed or filtered result can be caused by firewalls, NAT, ISP blocking, service binding, or the wrong host address.
  • Check from the same network path your users will use; internal and external port visibility can differ.

Use Cases

Checking whether common service ports are openEnter a host or IP and a list of ports, then run a backend TCP probe that reports open or closed status, response time, and any error. Only the host and the ports you typed are sent; the page itself does not log, replay, or share the query with other services. Presets cover Web, SSH/database, mail, and common mixed service ports.
Scanning a small custom port list safelyThe parser accepts comma, whitespace, and Chinese-comma separated values, keeps only valid ports from 1 to 65535, removes duplicates, and limits each request to 20 ports. This keeps ad hoc checks focused rather than turning the page into a broad scanner. Use the timing column to separate quick RST replies (closed) from multi-second timeouts (filtered).
Copying results for operations handoffAfter a check, open and closed counts appear above a table that can be copied as tab-separated text. It is useful for firewall verification, deployment troubleshooting, support notes, and confirming whether a newly exposed service is reachable. Compare the result with DNS records, hosting dashboards, and firewall rules before closing an incident.
Confirming cloud security group or firewall changesAfter updating an AWS security group, Azure NSG, or iptables rule, run the same port list from outside the VPC to confirm the rule actually opened the path. Open status from this page only confirms TCP reachability, not application health, authentication, or whether the listener is the intended service and not a default placeholder.
Distinguishing filtered ports from truly closed onesA filtered result often means a firewall silently drops SYN packets instead of replying with RST, so the host may still be running the service. Use the timing column to compare response delays against known-open ports on the same host; a slow timeout on port 5432 next to a fast RST on port 3306 is a strong filtered signal.

Technical Principle

Port checking attempts to establish TCP connections to specified ports on a target host. A successful TCP three-way handshake (SYN, SYN-ACK, ACK) indicates the port is open and a service is listening. If the connection is refused (RST, reset), the port is closed (no service). If no response arrives (timeout), the port may be filtered by a firewall or NAT, or the host may be down. A browser-based port checker is fundamentally limited: the browser cannot send raw TCP SYN packets, so it uses a workaround. Common workarounds: 1) HTTP HEAD or GET to the port and check the response code (works for HTTP/HTTPS proxies on unusual ports, 80, 8080, etc.); 2) WebSocket upgrade to the port and check the handshake result (works for most servers because WebSocket starts as HTTP and then upgrades); 3) image-loading requests (the browser fetches a 1x1 image from http://host:port/ and the connection either succeeds or fails); 4) no-connect probes (the browser tries to fetch favicon, robots.txt, or a known path and infers from the response). The page uses the WebSocket approach as the primary probe: 1) construct ws://host:port/ or wss://host:port/, 2) call new WebSocket(url), 3) measure the time to either onopen (open) or onerror (closed/filtered). The 1-3 second timeout distinguishes open (immediate) from closed (fast refusal) from filtered (timeout). The page surfaces all three states with the latency. Port ranges: 0-1023 are well-known (HTTP 80, HTTPS 443, SSH 22, FTP 21, SMTP 25, DNS 53, POP3 110, IMAP 143, etc.), 1024-49151 are registered (often used by applications like databases, custom services), 49152-65535 are dynamic/private (used by the OS for outbound connections, often source ports). Port 0 is reserved (the OS picks an ephemeral port when you bind to 0). The page lets the user pick a single port, a list of common ports, or a custom range. A caveat: a browser-based check only sees what the browser can reach. Probing from behind a corporate proxy or NAT, you may get filtered for ports that are actually open on the destination. The page is intentionally not a security audit tool; the user should use nmap, masscan, or ZMap for that, which run on a host with raw socket access.

  • TCP three-way handshake: SYN, SYN-ACK, ACK = open; RST = closed; timeout = filtered or host down; this is the standard interpretation.
  • Browser workarounds: HTTP HEAD/GET probes (unusual ports), WebSocket upgrade (most servers), image fetches, favicon/robots.txt; page uses WebSocket as primary.
  • Port ranges: 0-1023 well-known (HTTP 80, HTTPS 443, SSH 22), 1024-49151 registered, 49152-65535 dynamic; port 0 is reserved.
  • Timeout distinguishes states: immediate = open, fast refusal = closed, no response = filtered; the page uses 1-3 second timeout.
  • Browser limitations: cannot send raw SYN, so cannot do full TCP scan (SYN scan, FIN scan, NULL scan, XMAS scan); the page is approximate.
  • Not a security tool: for penetration testing, use nmap, masscan, or ZMap on a host with raw socket access; the page is a quick check, not a security audit.
  • Common ports: HTTP 80, HTTPS 443, SSH 22, FTP 21, SMTP 25, DNS 53, POP3 110, IMAP 143, MySQL 3306, PostgreSQL 5432, Redis 6379, MongoDB 27017.

Examples

Web server reachability

Host:   example.com
Ports:  80 (HTTP), 443 (HTTPS)
Result: both open, web server responding
Use:    confirm a public site is reachable from the Internet; a 200/301 response means the stack is healthy

SSH access test

Host:   server.example.com
Port:   22 (SSH)
Result: open, SSH service is accepting connections
Use:    verify the bastion or jump host is reachable before key-based login; combine with credential check on the SSH client side

Database port exposure

Host:   db.example.com
Port:   3306 (MySQL)
Result: closed, MySQL is not exposed externally
Use:    good security posture; databases should be reachable only from the application network, not the public Internet

FAQ

How does the port check work?

Browsers can't open arbitrary TCP sockets to remote hosts, so this tool issues the check from our backend. We attempt a TCP connection (or HTTP probe for application ports like 80/443) and report success, failure, and response time. Your IP is not shown to the target - our server is.

What does 'open' vs 'closed' vs 'filtered' mean?

Open: the port accepts connections. Closed: the host responded with TCP RST (refusing). Filtered: no response (firewall dropped the SYN). Only 'open' means a service is reachable. Closed and filtered both mean unreachable, but for different reasons.

Can I check ports on my home router?

Yes - enter your public IP and the port number. Useful for confirming a hosted game server, NAS, or self-hosted service is actually exposed to the internet. Note that residential ISPs often block inbound ports (25, 80, 443) regardless of your firewall.

Does the check work for UDP?

TCP only on most builds. UDP is connectionless; absence of a reply doesn't necessarily mean closed. For UDP service checks, you need application-level probes (e.g. DNS query for port 53/udp) which is what nmap does in service-detection mode.

What about local LAN ports (192.168.x.x)?

Our backend can't reach your private LAN. Use the actual command-line `nc -zv host port` from a device inside your network, or run a port scanner from another LAN device.

Is this legal to run on any host?

Port-scanning is generally legal for hosts you own. Scanning hosts you don't own can violate computer-misuse laws, terms of service, and ISP policies depending on jurisdiction. Don't use this for opportunistic scanning of arbitrary IPs.

Why does port 22 / 3389 / 25 always show closed?

Many ISPs and cloud providers block common attack-magnet ports by default. Cloud security groups (AWS, Azure, GCP) also block by default. If you expect a port to be open, verify the firewall, NAT/port-forward, and security-group rules at every hop.