TCP Port Checks

Every network service listens on a port, waiting. Email servers on port 25. Web servers on 80 and 443. Databases on their designated numbers. A TCP port check asks the simplest possible question: "Is anyone home?"

The answer tells you less than you think.

The Three-Way Handshake

When you check a port, you're initiating the TCP handshake—the ritual that establishes every TCP connection:

1. SYN: Your monitoring system sends a synchronize packet to the target port
2. SYN-ACK: If the service is listening, it responds with synchronize-acknowledge
3. ACK: Your system completes the handshake with acknowledge

Handshake completes? The port is open. The check succeeds.

But here's what makes port checks interesting: the failure modes are diagnostic.

If the server responds with RST (reset), the port is closed—nothing is listening there. If the connection times out with no response, a firewall is probably swallowing your packets. These different failures point to different problems: service down, firewall misconfigured, or network unreachable.

The Lie of the Open Port

A successful port check means the service is accepting connections. It doesn't mean the service is working.

Consider a database server. It accepts your connection on port 3306—handshake succeeds, port check passes. But the database is corrupted, or out of memory, or deadlocked. It can't execute a single query. For your application's purposes, the database is down. But your port check is green.

Or a web server that accepts connections on port 443 but returns 500 errors for every request. Port open. Service broken.

This is why port checks are necessary but not sufficient. They catch the obvious failures—service crashed, server unreachable, firewall blocking—with minimal overhead. They're the smoke detector, not the fire inspector.

The Common Ports

Web: 80 (HTTP), 443 (HTTPS)

Email: 25 (SMTP), 110 (POP3), 143 (IMAP), 587 (submission)

Databases: 3306 (MySQL), 5432 (PostgreSQL), 1433 (SQL Server), 27017 (MongoDB)

Remote Access: 22 (SSH), 3389 (RDP)

DNS: 53 (UDP for queries, TCP for zone transfers)

These aren't arbitrary numbers. They're conventions that let the Internet work—everyone agrees where to find things.

Timeouts: The Art of Giving Up

How long should you wait for a connection before declaring failure?

Wait too long, and your users experience problems for minutes before you know about them. Wait too short, and network hiccups trigger false alarms.

The answer depends on normal behavior. If your service typically responds in 100 milliseconds, a 10-second timeout is absurdly generous. If it sometimes takes 5 seconds under load, a 2-second timeout will cry wolf.

For local network services with consistent latency: 1-5 seconds. For Internet-facing services with variable paths: 5-15 seconds. For services over slow or unreliable links: longer, but recognize that users are suffering before you even know.

Location, Location, Location

Where you check from determines what you learn.

If all your monitoring locations report failure simultaneously, the service is probably down. If only one location fails, network routing problems are blocking that path. If your monitoring says everything is fine but customers are screaming, your monitoring has a better route than your customers do.

This is why checking from multiple locations matters. A service can be reachable from your data center and unreachable from half the Internet.

Firewalls: The Invisible Wall

Port checks and firewalls have a complicated relationship.

Firewalls block ports from untrusted sources. If your monitoring system isn't whitelisted, checks fail even when the service is perfect. Many organizations maintain explicit rules allowing their monitoring provider's IP ranges.

Security systems might interpret frequent connection attempts as port scanning. Check too often from the same IP, and intrusion detection blocks you. Your monitoring becomes a victim of your security.

Cloud security groups add another layer. A misconfiguration might allow application traffic while blocking monitoring traffic—creating a blind spot where you can't see the service but everyone else can.

Beyond Basic Checks

Sophisticated port monitoring goes further:

Banner grabbing: After connecting, read what the service announces. Many services identify themselves when you connect. Verifying the banner confirms the right service is running—not something else that grabbed the port.

Protocol validation: Attempt a basic exchange. Connect to port 25, send EHLO, verify you get a proper SMTP response. This confirms the service functions at a protocol level.

TLS verification: For encrypted services, verify the handshake succeeds and the certificate is valid.

Response time: Measure how quickly connections establish. Slowness often precedes complete failure.

The Layered Approach

Port checks work best as the first line of defense in layered monitoring:

Layer 1 - Port checks: Fast, lightweight. Is the service accepting connections at all? Catches hard failures instantly.

Layer 2 - Protocol checks: HTTP requests, DNS queries, database connections. Is the service responding correctly to its protocol?

Layer 3 - Application checks: Business logic validation. Can users actually do what they came to do?

If the port check fails, don't bother with deeper checks—the service isn't even accepting connections. If the port check passes but protocol checks fail, the service is limping. If everything passes but application checks fail, you have a logic problem, not an infrastructure problem.

When Checks Fail

Systematic troubleshooting:

1. Is the service running? Log into the server. Check process status. Use netstat or ss to verify it's listening on the expected port.

2. Can you connect locally? From the server itself, try telnet localhost PORT or nc -zv localhost PORT. If local connections fail, the service isn't listening correctly.

3. What's blocking the path? Check firewall rules—iptables, firewalld, cloud security groups. Verify your monitoring IP is allowed.

4. Where do packets die? From your monitoring location, traceroute to the server. See where the path breaks.

5. What do logs say? Services usually explain why they're refusing connections. Configuration errors, resource exhaustion, dependency failures—the logs know.