The port shows closed — is my config wrong?

Check in order of likelihood: nothing listening (verify with ss -tlnp), cloud security group blocking, OS firewall (iptables/nftables — a separate gate from the cloud group), the provider blocking inbound (residential lines commonly block 25/80/443), or the service bound to 127.0.0.1 instead of 0.0.0.0. Eliminate layer by layer.

Is an open port dangerous?

Open is not automatically risky — the risk lives in what answers: an SSH on port 22 with a weak password and a patched nginx are different threat levels. Principle: close what you do not use; put access controls (allowlists, fail2ban, strong auth) on what you must.

Is this TCP or UDP checking?

TCP detection completes a handshake — reliable. UDP is connectionless: silence can mean open or dropped packets, so results are only "probably open / no response". For UDP services like DNS (53/UDP), verify with a protocol-native tool instead.

Network Tools

Port Checker

Check whether specific ports on a host are open.

Hostname or IP Address

Port Number

ℹ️Due to browser security restrictions, port detection is implemented through HTTP/WebSocket connection attempts, and results may not be completely accurate. Only ports supporting HTTP/HTTPS or WebSocket protocols can be detected. For precise detection, please use system-level tools like nmap.

📋 Common Ports Reference

21FTPFile Transfer Protocol

22SSHSecure Shell

23TelnetTelnet Protocol

25SMTPSimple Mail Transfer Protocol

53DNSDomain Name System

80HTTPHypertext Transfer Protocol

110POP3Post Office Protocol v3

143IMAPInternet Message Access Protocol

443HTTPSHTTP Secure

465SMTPSSMTP Secure

587SMTPMail Submission

993IMAPSIMAP Secure

995POP3SPOP3 Secure

1433MSSQLSQL Server Database

1521OracleOracle Database

3306MySQLMySQL Database

3389RDPRemote Desktop Protocol

5432PostgreSQLPostgreSQL Database

5900VNCVirtual Network Computing

6379RedisRedis Database

8080HTTP-AltHTTP Alternate Port

8443HTTPS-AltHTTPS Alternate Port

27017MongoDBMongoDB Database

What is Port Checker?

Port checker tests whether specific network ports are open on a host, useful for firewall and service verification.

Common Ports

21 - FTP
22 - SSH
80 - HTTP
443 - HTTPS
3306 - MySQL
5432 - PostgreSQL

Use Cases

Firewall testing
Service availability check
Network troubleshooting

A browser-side port checker that probes host:port pairs by sending an HTTP request or a WebSocket handshake and reports each port as open, closed, timeout or error. It suits confirming that a freshly deployed web service is reachable on 80, 443, 8080 or 8443; it is not a TCP scanner.

Why a browser cannot send a bare TCP SYN

A port number is a 16-bit unsigned field covering 0-65535, split by RFC 6335 into System Ports (0-1023), User Ports (1024-49151) and Dynamic Ports (49152-65535); this tool accepts only 1-65535. A scanner like nmap opens a raw TCP connection and watches whether the three-way handshake of RFC 9293 returns SYN-ACK, which works against any protocol on the port. Browser JavaScript has no socket API - the only outbound primitives are fetch() and WebSocket, and those speak HTTP or the RFC 6455 Upgrade handshake respectively. So a port is marked open here only when something on it answers an HTTP request; SSH on 22, MySQL on 3306 and Redis on 6379 stay invisible even while they listen.

Protocol order and the fixed 3-second deadline

The probe order is hard-coded: 443 and 8443 are tried over https:// only, 80 and 8080 over http:// only, and every other port walks https://, then http://, then wss://host:port. Each attempt runs under an AbortController with a 3000 ms deadline, so a port on the three-protocol path can burn 9000 ms before it is judged. Workers are queued five at a time, which makes 100 ports twenty batches and roughly three minutes worst case. One consequence is easy to miss: this page is served over HTTPS, and browsers block plain http requests from an HTTPS document as mixed content, so the single-protocol ports 80 and 8080 fail instantly and fall through to a WebSocket attempt that a plain HTTP listener can never complete.

What open, closed and timeout actually mean

The three verdicts map onto different network events, and conflating them is the main source of wrong conclusions. open means fetch() resolved or the WebSocket fired onopen; because the request uses mode: no-cors the response is opaque, so a 404 and a 200 look identical and no status code is ever displayed. closed means the WebSocket raised onerror: the peer replied RST (no listener, or an explicit reject rule) or the TLS handshake on wss:// failed. timeout means the 3000 ms deadline expired without any event, the fingerprint of packets dropped silently by a DROP default rather than rejected. A closed port still tells you the host is reachable; a timeout proves nothing either way.

Worked example

Expanding a mixed port list and scheduling the probes

Input

host:  example.com
ports: 80, 443, 6379, 8000-8001

Output

parsed, de-duplicated and sorted: 80, 443, 6379, 8000, 8001  (5 ports)

80    HTTP    http://                       1 attempt   3000 ms cap
443   HTTPS   https://                      1 attempt   3000 ms cap
6379  Redis   https:// > http:// > wss://   3 attempts  9000 ms cap
8000  -       https:// > http:// > wss://   3 attempts  9000 ms cap
8001  -       https:// > http:// > wss://   3 attempts  9000 ms cap

queue: 5 workers for 5 ports = one batch, every probe starts at once

Only 443 and 8443 get a single https:// attempt, only 80 and 8080 get a single http:// attempt, and everything else walks all three protocols. Because the port list is exactly as large as the five-worker queue, every probe starts simultaneously and the total wall clock equals the slowest port, not the sum.

Limits and pitfalls

One run probes at most 100 ports: a range such as 8000-8199 is filled only up to the 100th entry, so 8100-8199 are dropped without any warning.
open means an HTTP or WebSocket request was answered, so a listening SSH, MySQL or Redis daemon is still reported as closed or timeout.
The page runs on HTTPS, so the plain http probes for ports 80 and 8080 are blocked as mixed content and a healthy HTTP listener can show as closed.
The host field accepts only dotted-quad IPv4 or a domain whose TLD is two or more letters; localhost, single-label hostnames and IPv6 literals fail validation before anything is sent.
Service names come from a fixed 23-entry table covering 21 to 27017; an unlisted port shows no label, and any other daemon on 8080 is still displayed as HTTP-Alt.

Related tools

Whether port 22 is listening: what this page answers and what it never will

What you are trying to find out	This port checker	Where to go instead
Whether a daemon on 22, 3306 or 6379 is actually listening	It only ever sends an HTTP request or a WebSocket handshake, so a healthy SSH, MySQL or Redis listener answers neither and lands on `closed` or `timeout`. Those ports also walk the full `https` / `http` / `wss` chain first, so the wrong verdict takes up to 9000 ms to appear.	`nc -zv host 22` or `nmap -Pn -p 22,3306,6379 host` opens a real TCP connection, which any protocol accepts. Stay here only to prove a negative on those ports: silence is the expected answer and says nothing about the daemon.
Which service sits behind the port, and what it answers	Requests leave as `HEAD` with `mode: no-cors`, so the response is opaque by construction: 200, 404 and a redirect to a login page all collapse into `open`, and no status code or `Server` header is ever rendered.	`curl -sI https://host:8080` returns the status line and every header, and the HTTP status code reference on this site decodes the number. Keep this page when yes-or-no reachability is the whole question.
No terminal in reach — phone, locked-down laptop — and you just want to know if a port you opened answers	Everything runs in the tab: type the host, press the Web ports preset (80, 443, 8080, 8443), and all four probes start together — the queue allows five at a time — with a 3000 ms cap per attempt.	With a shell available, `curl -I http://host:8080` is one line and reports the real status. Choose this page when installing nothing is the hard constraint, and remember that the HTTPS origin blocks the plain `http` probes for 80 and 8080.
Telling a firewall that drops packets apart from a port with nothing behind it	The separation is indirect: `timeout` means 3000 ms passed with no event, which is what a DROP rule looks like; `closed` means the WebSocket raised an error, covering both an RST and a failed `wss://` TLS handshake, so a refused handshake is indistinguishable from a refused connection.	`nmap -Pn` separates `filtered` from `closed` by inspecting the reply type, and `hping3 -S` shows whether an RST comes back at all. Ask that question in a shell once textbook reachability is already settled here.
Sweeping a block such as 1-1024 to find everything that is open	Hard stop at 100 ports per run — a `8000-8199` range fills only to the 100th entry and the rest is dropped without a warning — and five workers mean each three-protocol port can burn 9000 ms.	`nmap -Pn -p 1-1024 host` covers the same ground in one command with no protocol restriction. Keep this page for the four or five ports you already suspect.
The host is an IPv6 literal, `localhost`, or a single-label intranet name	All three are rejected before a packet is built: IPv4 must be four dotted octets of 0-255, and a hostname needs at least one dot plus a TLD of two or more letters.	`curl -g -6 "http://[::1]:8080"`, `nc -zv ::1 8080`, or `Test-NetConnection localhost -Port 8080` in PowerShell all accept the addresses this field refuses. Resolve the name first with the DNS lookup tool if you are unsure where it points.

The 23 service labels this page can print, with the probe path each port takes

Port	Label shown	Protocols tried, in order	Worst case for that port
21	FTP	`https` → `http` → `wss`	9000 ms
22	SSH	`https` → `http` → `wss`	9000 ms
23	Telnet	`https` → `http` → `wss`	9000 ms
25	SMTP	`https` → `http` → `wss`	9000 ms
53	DNS	`https` → `http` → `wss`	9000 ms
80	HTTP	`http` only	3000 ms
110	POP3	`https` → `http` → `wss`	9000 ms
143	IMAP	`https` → `http` → `wss`	9000 ms
443	HTTPS	`https` only	3000 ms
465	SMTPS	`https` → `http` → `wss`	9000 ms
587	SMTP	`https` → `http` → `wss`	9000 ms
993	IMAPS	`https` → `http` → `wss`	9000 ms
995	POP3S	`https` → `http` → `wss`	9000 ms
1433	MSSQL	`https` → `http` → `wss`	9000 ms
1521	Oracle	`https` → `http` → `wss`	9000 ms
3306	MySQL	`https` → `http` → `wss`	9000 ms
3389	RDP	`https` → `http` → `wss`	9000 ms
5432	PostgreSQL	`https` → `http` → `wss`	9000 ms
5900	VNC	`https` → `http` → `wss`	9000 ms
6379	Redis	`https` → `http` → `wss`	9000 ms
8080	HTTP-Alt	`http` only	3000 ms
8443	HTTPS-Alt	`https` only	3000 ms
27017	MongoDB	`https` → `http` → `wss`	9000 ms

These are the only labels the tool can produce: a port outside the table (5000, 8000, 7001) shows no name at all, and any program bound to 8080 or 8443 still reads HTTP-Alt or HTTPS-Alt. The same 23 cards sit below the results, and clicking one replaces the entire port field with that single number rather than appending it to the list. Ports 25 and 587 both display SMTP, so the label does not tell submission from relay.

Frequently Asked Questions

The port shows closed — is my config wrong?: Check in order of likelihood: nothing listening (verify with ss -tlnp), cloud security group blocking, OS firewall (iptables/nftables — a separate gate from the cloud group), the provider blocking inbound (residential lines commonly block 25/80/443), or the service bound to 127.0.0.1 instead of 0.0.0.0. Eliminate layer by layer.
Is an open port dangerous?: Open is not automatically risky — the risk lives in what answers: an SSH on port 22 with a weak password and a patched nginx are different threat levels. Principle: close what you do not use; put access controls (allowlists, fail2ban, strong auth) on what you must.
Is this TCP or UDP checking?: TCP detection completes a handshake — reliable. UDP is connectionless: silence can mean open or dropped packets, so results are only "probably open / no response". For UDP services like DNS (53/UDP), verify with a protocol-native tool instead.

Content reviewed: 2026-10-22