You know that an IP address points to a machine on the network. But a single machine runs many services at once — a web server, a database, SSH, mail. How does traffic reach the right one? Ports.
If the IP address is a building's street address, the port is the room number. Let's make that concrete.
What a port is
A network port is a number (0–65535) that identifies a specific service on a machine. When you connect to example.com:443, you're reaching the host at that IP, on port 443 — where its web server is listening for HTTPS.
Every networked service listens on a port. The combination of IP + port is what actually pinpoints a service.
The ports you'll meet
A handful of "well-known" ports come up constantly:
| Port | Service | What it's for |
|---|---|---|
| 80 | HTTP | Unencrypted web traffic |
| 443 | HTTPS | Encrypted web traffic |
| 22 | SSH | Secure remote login |
| 25 / 587 | SMTP | Sending email |
| 53 | DNS | Name resolution |
| 3306 / 5432 | MySQL / PostgreSQL | Databases |
| 6379 | Redis | Cache / key-value store |
When someone says "the database is on the default port," they mean one of these.
Open, closed, or filtered
A port is in one of three states, and the difference matters when debugging:
| State | Meaning |
|---|---|
| Open | A service is listening and accepting connections |
| Closed | Nothing is listening — connection refused (instantly) |
| Filtered | A firewall is silently dropping traffic — connection hangs |
That distinction explains a lot: a connection refused is "closed" (instant no), while a hanging timeout is usually "filtered" (a firewall dropping packets).
Why monitor a port directly?
A website check tells you HTTP is working. But plenty of critical things aren't websites — a database, a mail server, a custom TCP service, a game server. Port monitoring opens a real connection to a host and port to confirm the service is actually accepting connections.
This catches a class of problem a page check misses entirely:
- A database that stopped accepting connections (even though the website is up).
- A mail server whose SMTP port closed.
- A service that crashed but the web tier in front of it is fine.
A TCP check can even time the handshake, so you also catch a port that's open but slow.
A quick how-to
To monitor a port, you point a check at a host and port and confirm the connection succeeds:
- Pick the host and port (e.g. your DB host on
5432). - Have the monitor open a TCP connection on a schedule.
- Alert if it's refused, filtered (times out), or slow to connect.
- Check from multiple locations so a single network hiccup doesn't page you.
The bottom line
| In one line | |
|---|---|
| What | A number identifying a specific service on a machine (IP = building, port = room). |
| Common | 80/443 web, 22 SSH, 25 mail, 53 DNS, DB ports. |
| States | Open (listening), closed (refused), filtered (dropped). |
| Monitor it | Confirm the service accepts connections — catches non-web outages. |
Ports are how one machine offers many services without them colliding. And because not everything important is a website, monitoring the right ports catches outages — a dead database, a closed mail port — that a homepage check would never see.
Test a port instantly with the free port checker, or set up continuous checks with network monitoring.