Open Ports Explained + Common Port Numbers Guide

PAYATE Team· Oct 26, 2026· 19 min read

OPAYATE

If an IP address is like a building’s street address, then a port is like a numbered door on that building. A single server can run many services at once — a website, email, a database, remote login — and ports are how the operating system keeps them apart. When traffic arrives for port 443, it goes to the web server; port 25 goes to mail; port 22 goes to SSH. Understanding ports is fundamental to networking, security, and troubleshooting, yet they’re one of the most misunderstood topics for newcomers.

This guide explains what ports are, the crucial difference between open, closed, and filtered, a reference list of the common port numbers you’ll meet in the wild, and how to safely check whether a port is open — which you can do for any public host using the free Open Port Checker.

What Is a Port, Really?

A port is a 16-bit number — so there are 65,536 of them, from 0 to 65535 — that identifies a specific service or connection endpoint on a device. Combined with an IP address, a port forms a socket: the full coordinates of one end of a network conversation. 93.184.216.34:443 means “the HTTPS service on that server.”

There are two main transport protocols that use ports:

TCP (Transmission Control Protocol) — connection-oriented and reliable. It performs a handshake, guarantees delivery and ordering, and retransmits lost data. The web, email, SSH, and databases all use TCP. Port checkers test TCP.
UDP (User Datagram Protocol) — connectionless and fast, with no handshake or delivery guarantee. Used for DNS queries, video streaming, VoIP, and gaming, where speed matters more than perfect reliability.

TCP and UDP port numbers are independent namespaces, so “port 53” can mean two different things depending on protocol (DNS uses both). Most everyday port discussions — and most port checks — concern TCP.

The Three Ranges of Ports

IANA divides the port space into three ranges:

Well-known ports (0–1023) — reserved for core services like HTTP (80), HTTPS (443), SSH (22), and SMTP (25). On most systems, binding to these requires administrative privileges.
Registered ports (1024–49151) — assigned to specific applications by IANA, like MySQL (3306), PostgreSQL (5432), and RDP (3389).
Dynamic / ephemeral ports (49152–65535) — used temporarily by clients for the return path of a connection. When your browser connects out to port 443, the OS assigns it a random high port for the reply.

Open vs Closed vs Filtered: The Most Important Distinction

When you test a port, the result isn’t simply “yes” or “no.” There are three meaningful states, and knowing the difference is the key to interpreting any port check:

Open

Something is listening on that port and accepted the connection. A service is running and reachable. For a web server, port 443 being open is exactly what you want. For a database, port 3306 being open to the whole internet is usually a serious problem.

Closed

The host answered but actively refused the connection — nothing is listening on that port, but the machine is online and reachable. A closed port tells you “the server is there, but this particular door has no service behind it.”

Filtered

Nothing answered at all within the timeout. A firewall silently dropped the connection attempt, giving no response. Filtered is different from closed: closed means “no, actively,” while filtered means “silence,” which usually indicates a firewall policy. From a security standpoint, filtered is often preferable for ports you don’t want exposed — it gives attackers no information.

The Open Port Checker reports exactly these three states, so you can tell a refused connection (closed) apart from a firewalled one (filtered) — a distinction that matters a lot when debugging.

Common Port Numbers You Should Know

Here’s a practical reference of the ports you’ll encounter most often, grouped by what they do.

Web

80 — HTTP: unencrypted web traffic. Today mostly used just to redirect to HTTPS.
443 — HTTPS: encrypted web traffic. The port that should be open on any modern site.
8080 / 8443: common alternate HTTP/HTTPS ports for dev servers, proxies, and admin panels.

Email

25 — SMTP: server-to-server mail delivery.
587 — SMTP submission: how mail clients send outgoing mail (with authentication).
465 — SMTPS: SMTP over implicit TLS.
110 / 995 — POP3 / POP3S: downloading mail.
143 / 993 — IMAP / IMAPS: syncing mail across devices.

Remote Access & File Transfer

22 — SSH: secure remote shell and SFTP. A frequent target for brute-force bots — harden it.
3389 — RDP: Windows Remote Desktop. Exposing this to the internet is a leading cause of ransomware; keep it behind a VPN.
21 — FTP: legacy, unencrypted file transfer. Avoid in favour of SFTP (over 22) or FTPS.
23 — Telnet: ancient, unencrypted remote login. Should never be open on the modern internet.

Databases (Should Rarely Be Public)

3306 — MySQL / MariaDB
5432 — PostgreSQL
6379 — Redis
27017 — MongoDB
1433 — Microsoft SQL Server

These should almost never be open to the entire internet. Countless data breaches have come from a database port left exposed with weak or default credentials. Bind them to localhost or a private network and reach them through SSH tunnels or a VPN.

Infrastructure

53 — DNS (TCP and UDP).
123 — NTP: time synchronisation.
161 — SNMP: network device management.

Why Check Ports? Real-World Use Cases

Port checking isn’t just an academic exercise. Here’s when you’ll actually reach for it:

Confirming a new service is reachable. You deployed a web app — is port 443 actually open from the outside, or is a firewall blocking it? A quick external check answers it instantly.
Verifying a port-forward. You set up port forwarding on a router for a game server or self-hosted service; checking from an external vantage point confirms it works beyond your LAN.
Firewall debugging. “It works on localhost but not from the internet” almost always means a firewall is filtering the port.
Security auditing. Checking that sensitive ports (databases, RDP, admin panels) are not open to the world is a basic hygiene check.

Because the Open Port Checker tests from an external server, it shows you reachability from the public internet — which is exactly the perspective that matters, and the one you can’t get by testing from your own machine.

How to Check If a Port Is Open

The easiest way, with nothing to install:

Open the Open Port Checker.
Enter the host (a domain or IP) and the port number — or pick a common one from the list.
Read the result: open, closed, or filtered, with the service name and response time.

If you prefer the command line, the classics are nc -zv host 443 (netcat), nmap -p 443 host (the full-featured scanner), or PowerShell’s Test-NetConnection host -Port 443. For a quick one-off check — especially on a phone or a restricted machine — a web checker is faster.

Ports and Security: A Practical Checklist

The guiding principle of port security is “close everything you don’t need, and lock down what you do.” This is the essence of reducing your attack surface.

Expose only what’s necessary. A web server typically needs 80 and 443 open, and nothing else. Everything else should be filtered.
Never expose databases or admin ports to the world. Put 3306, 5432, 6379, 3389, etc. behind a VPN or firewall allow-list.
Harden SSH (22). Use key-based auth, disable password login, consider changing the port to cut down on bot noise, and use tools like fail2ban.
Retire insecure protocols. Telnet (23) and plain FTP (21) send credentials in the clear — replace them.
Audit regularly. Periodically check that no unexpected ports have opened up after a deployment or config change.

A Note on Responsible Use

Checking a single port on a server you own or administer is routine and legitimate. Running broad, aggressive port scans against systems you don’t have permission to test can be against acceptable-use policies or even illegal in some jurisdictions. Always have authorisation. The Open Port Checker is built for responsible, one-port-at-a-time checks against public hosts, and it blocks private and reserved addresses so it can’t be used to probe internal networks.

How Ports Fit With the Rest of Your Stack

Ports are one piece of a server’s public footprint. A complete picture usually involves a few quick lookups:

Find the server’s IP from its domain with the DNS Lookup (the A/AAAA record).
Check the port with the Open Port Checker to confirm the service is reachable.
Verify HTTPS on port 443 with the SSL Certificate Checker — an open 443 is no good if the certificate is expired.
Identify the host with the IP WHOIS & ASN Lookup to see which provider the server runs on.

Together these turn “is my service up and reachable?” into a repeatable, two-minute checklist.

The TCP Handshake: What “Open” Really Tests

When a port checker says “open,” what actually happened under the hood is a TCP three-way handshake — the short conversation every TCP connection begins with:

SYN — the client says “I’d like to connect.”
SYN-ACK — if a service is listening, the server replies “sure, go ahead.”
ACK — the client confirms, and the connection is established.

Each of the three port states maps to a different outcome of this handshake. Open means the SYN-ACK came back — a service accepted. Closed means the server replied with a RST (reset), actively refusing because nothing is listening. Filtered means nothing came back at all — a firewall dropped the SYN silently, so the checker waits and eventually times out. Understanding this is why “filtered” takes longer to report than “closed”: closed gets an instant refusal, while filtered has to wait out the timeout.

Firewalls: How They Decide Your Port’s State

The difference between closed and filtered comes down to a firewall, so it’s worth understanding what one does. A firewall is a set of rules that inspects each incoming packet and decides to allow, reject, or drop it:

Allow — the packet reaches the service; the port appears open (if something’s listening) or closed (if not).
Reject — the firewall sends back a refusal, so the port looks closed.
Drop — the firewall silently discards the packet with no reply, so the port looks filtered.

Most security-conscious firewalls drop rather than reject, because silence gives attackers no information — they can’t even tell whether a host exists. This “stealth” behaviour is exactly why a well-defended server shows most ports as filtered. On Linux the firewall is typically iptables/nftables or the friendlier ufw; on cloud platforms it’s “security groups” or “network ACLs”; on Windows it’s Windows Defender Firewall.

NAT and Why Your Local IP Is Different

A frequent point of confusion: you check your “IP” and see something like 192.168.1.50, but a port checker needs your public IP. That’s because of NAT (Network Address Translation). Your home or office router has one public IP from your ISP, and every device behind it shares that address using private, internal IPs. The router keeps a table mapping internal connections to the public side.

This matters for port checking because an inbound connection to your public IP doesn’t know which internal device to reach — unless you’ve set up port forwarding. Find your public IP with the IP Lookup, and remember that checking a port on it tests whether your router forwards that port inward, not just whether a local service is running.

Port Forwarding, Step by Step

Give the target device a static internal IP (or a DHCP reservation) so it doesn’t change.
In your router’s admin page, find Port Forwarding and create a rule: external port → internal IP + internal port, TCP (and/or UDP).
Make sure the device’s own firewall allows that port.
Verify from outside your network with the Open Port Checker — testing from inside your LAN won’t prove it works from the internet.

Securing SSH: A Deep Dive on Port 22

Because SSH (port 22) grants full control of a server, it’s the single most attacked service on the internet — automated bots hammer it constantly. If you run a server, hardening SSH is non-negotiable:

Use key-based authentication and disable password login entirely (PasswordAuthentication no). Keys can’t be brute-forced the way passwords can.
Disable root login (PermitRootLogin no); log in as a normal user and escalate with sudo.
Consider a non-standard port. Moving SSH off 22 doesn’t add real cryptographic security, but it dramatically cuts the noise from automated scanners.
Run fail2ban to auto-ban IPs after repeated failures.
Restrict by source IP where possible, or put SSH behind a VPN so it isn’t exposed to the whole internet at all.

After hardening, use the Open Port Checker to confirm SSH is reachable only where you intend — and that you haven’t accidentally left a test port open.

An Expanded Port Reference

Beyond the essentials, here are more ports you’ll bump into, with a note on whether they should typically face the internet:

853 — DNS-over-TLS: encrypted DNS. Fine to expose if you run a DoT resolver.
989/990 — FTPS: FTP over TLS.
1194 — OpenVPN: VPN server (UDP by default).
51820 — WireGuard: modern VPN (UDP).
5060/5061 — SIP: VoIP signalling.
9000 — PHP-FPM / various apps: should be localhost-only, never public.
2375/2376 — Docker API: exposing this unauthenticated is a critical risk — keep it off the internet.
9200 — Elasticsearch: another database-class service that has caused many breaches when left open.

The recurring theme: application back-ends, container APIs, and data stores should live on localhost or a private network. If a check shows any of these open to the world, treat it as an incident.

Ephemeral Ports and Connection Tracking

A detail that confuses many people: when your browser connects out to a web server on port 443, which port does the reply come back to? Not 443. Your operating system assigns a temporary ephemeral port from the high range (49152–65535) for the client side of the connection, and the server replies to that. The OS keeps a connection-tracking table matching each outbound connection to its ephemeral port so replies reach the right process.

This is why you don’t need to “open” ports to browse the web — outbound connections and their replies are handled automatically. You only need to open (and possibly forward) a port when you want the outside world to initiate a connection to a service you’re hosting. Understanding the client-vs-server distinction clears up a huge amount of port confusion.

Common Self-Hosting and Gaming Scenarios

Port knowledge becomes very practical the moment you host something at home. A few typical cases:

Game server (Minecraft on 25565, for example) — forward the game’s port on your router to the host machine, then verify it from outside with the Open Port Checker so friends can actually connect.
Self-hosted web app — forward 80/443 (or run behind a reverse proxy and a tunnel service), add a DNS record pointing at your public IP, and confirm both the port and the certificate are good.
Home NAS or media server — be cautious. It’s tempting to forward the admin port, but exposing a NAS directly to the internet is risky; a VPN back into your network is far safer than opening ports.
Remote desktop — never forward RDP (3389) straight to the internet; it’s a top ransomware vector. Use a VPN.

In every case the workflow is the same: forward the port, allow it through the device’s own firewall, point DNS at your public IP, and verify from outside — because testing from your own LAN won’t reveal a router or ISP that’s blocking inbound traffic.

How Port Scanning Works

“Checking a port” is a gentle, single-door version of what security scanners do across many ports. The main techniques, briefly:

TCP connect scan — completes the full three-way handshake. Reliable and what simple checkers (and unprivileged tools) use. If it connects, the port is open.
SYN scan (“half-open”) — sends a SYN and watches the reply but never completes the handshake, making it faster and stealthier. Used by tools like nmap with elevated privileges.
Service/version detection — after finding an open port, the scanner talks to the service to identify what’s running and which version — valuable for defenders auditing their own exposure, and for attackers finding vulnerable software (which is why you minimise what you expose).

For everyday needs — “is port 443 reachable?” — a single TCP connect check via the Open Port Checker is exactly the right tool: precise, responsible, and instant. Full scanning tools are for authorised, systematic audits of systems you control.

Ports and IPv6

Everything about ports works identically over IPv6 — the same port numbers, the same open/closed/filtered states, the same TCP handshake. The twist is that IPv6 often doesn’t use NAT: devices can have globally routable addresses directly. That makes host firewalls even more important, because there’s no router NAT implicitly shielding internal devices. When auditing an IPv6-enabled server, check the same sensitive ports over its IPv6 address too — a service firewalled on IPv4 but left open on IPv6 is a classic oversight.

Troubleshooting: “My Service Is Unreachable”

This is the single most common port-related support scenario, and a methodical approach solves it fast. Work from the outside in:

Is DNS correct? Confirm the domain resolves to the right IP with the DNS Lookup. If it points at the wrong server, no amount of port fiddling will help.
Is the port open from outside? Test it with the Open Port Checker. “Filtered” points to a firewall; “closed” means the host is reachable but nothing is listening; “open” means the network path is fine and the problem is higher up.
Is the service actually listening? On the server, check with ss -tlnp (or netstat -tlnp). A frequent gotcha: the service is bound to 127.0.0.1 (localhost only) instead of 0.0.0.0 (all interfaces), so it works locally but refuses external connections.
Is a firewall blocking it? Check the host firewall (ufw status, iptables -L) and, in the cloud, the security-group rules.
Is it a router/NAT issue? For home hosting, confirm port forwarding is set up and test from a network outside your own.
Is it IPv6 vs IPv4? The service may listen on one family but not the other — check both.

Following this ladder isolates the problem to a specific layer — DNS, network path, firewall, binding, or NAT — instead of guessing. The external port check is the pivotal step, because it cleanly separates “the internet can’t reach my server” from “my server isn’t serving.”

Load Balancers, Reverse Proxies, and Ports

In modern deployments you rarely expose your application’s raw port to the world. Instead, a reverse proxy or load balancer sits in front, and this changes the port picture in a useful way:

The proxy (Nginx, HAProxy, a cloud load balancer, or Cloudflare) listens on the public ports 80 and 443.
Your application listens on a high internal port like 3000 or 8000, bound to localhost or a private network, not exposed publicly.
The proxy forwards requests inward, terminates TLS, and often adds caching, rate-limiting, and the very security headers we care about.

This pattern is both more secure and more flexible: only two well-understood ports face the internet, your app stays private, and you can swap or scale back-ends without touching DNS or firewall rules. When you audit such a setup with the Open Port Checker, you should see 80 and 443 open and the application’s internal port filtered from outside — exactly the result you want. If that internal port is reachable from the internet, it’s a misconfiguration to fix immediately.

A Pre-Launch Port Audit Checklist

Before putting any server into production, run through this quick audit with the Open Port Checker and your server’s own tooling:

Confirm the ports you need are open — typically just 80 and 443 for a web server.
Confirm everything else is filtered — especially databases (3306, 5432, 6379, 27017), caches, container APIs (2375), and app back-ends (9000, 8000).
Check SSH is reachable only as intended — ideally restricted by IP or behind a VPN.
Verify 443 has a valid certificate with the SSL Certificate Checker — an open HTTPS port with an expired cert is still broken.
Repeat over IPv6 if the server has a public IPv6 address.
Re-run after every major change — new software can open ports you didn’t expect.

Ten minutes of auditing here prevents the single most common cloud-security mistake: a sensitive service accidentally exposed to the entire internet.

Frequently Asked Questions

What does it mean if a port is “filtered”?

Filtered means no response came back at all — a firewall silently dropped the connection. It’s different from “closed,” where the host actively refused. Filtered usually indicates a firewall policy and is often the desired state for ports you don’t want exposed.

Why does a port show closed when I know my service is running?

Common causes: a firewall allowing only certain source IPs, the service listening on IPv6 only (or on localhost instead of all interfaces), the service being temporarily down, or a router port-forward that isn’t set up. Testing from an external checker helps isolate which.

Is it dangerous to have open ports?

Open ports are necessary for services to work — an open 443 is how your website is reachable. The danger is open ports you don’t need, especially databases and remote-admin ports exposed to the whole internet. Close what you don’t use.

What’s the difference between TCP and UDP ports?

TCP is reliable and connection-based (web, email, SSH, databases); UDP is fast and connectionless (DNS, streaming, gaming, VoIP). They use separate numbering, and most port checks test TCP.

Can I check a port on my home network from outside?

Yes — that’s the point of an external checker. Enter your public IP (find it with the IP Lookup) and the forwarded port to confirm it’s reachable from the internet.

What’s the difference between a port and a socket?

A port is just the number (like 443). A socket is the full combination of an IP address and a port — for example 93.184.216.34:443 — which uniquely identifies one end of a specific connection. One listening port can handle many simultaneous sockets, because each client connection is distinguished by the client’s IP and ephemeral port.

How many ports can a server have open at once?

Technically up to 65,535 per protocol, but a well-run server keeps the number tiny on purpose — often just 80 and 443 facing the internet. The goal isn’t to open ports; it’s to expose the absolute minimum and keep everything else filtered. Audit yours with the Open Port Checker to be sure nothing crept in unnoticed.

Conclusion

Ports are the numbered doors through which all network services communicate, and understanding them unlocks a huge amount of practical ability: deploying services, debugging firewalls, verifying port-forwards, and auditing your security posture. Remember the three states — open (a service is listening), closed (reachable but nothing there), and filtered (a firewall is dropping it) — and keep the common port numbers handy as a reference.

Most importantly, apply the golden rule: expose only the ports you truly need, and keep databases and admin interfaces off the public internet. When you want to confirm what’s reachable, the Open Port Checker gives you the outside world’s view in seconds — the perspective that actually matters for both uptime and security.

Key Takeaways

A port is a numbered door on a server; combined with an IP it forms a socket identifying one end of a connection.
Know the three states: open (a service is listening), closed (reachable but nothing there), filtered (a firewall is silently dropping it).
Memorise the common ports: 80/443 web, 22 SSH, 25/587 mail, 3306/5432 databases, 3389 RDP.
Expose only what you need. Keep databases, admin interfaces, and container APIs off the public internet.
Test from outside. NAT means a service that works on your LAN may not be reachable from the internet — verify with an external checker.
Harden SSH with keys, no root login, and fail2ban, and put remote-desktop and sensitive services behind a VPN.

Written by PAYATE Team

The PAYATE team builds free tools for merchants and developers.