Port & Protocol Reference

Looking a Port Up Here vs Grepping /etc/services

Every Linux and macOS machine already ships a local port reference at /etc/services, and grep postgres /etc/services will return a line for port 5432. So why reach for a browser tool instead? Coverage and context are the difference. /etc/services is a decades-old, sparsely maintained file that lists a port-to-name mapping and nothing else — no category, no security guidance, no note that a port is commonly blocked outbound by cloud providers. It also lags behind reality: newer conventions like Kubernetes' default NodePort range or common self-hosted app ports (Grafana on 3000, Prometheus on 9090) were never registered with IANA and don't appear there at all. This reference layers curated categories, protocol flags, and security context — like "never expose to the public internet" — on top of the same underlying facts, which is what a raw system file can't provide.

nmap -sV and a cloud console search answer a different question entirely: what's actually listening on a live host right now, not what a port is conventionally used for or whether opening it carries risk. Use this reference to decide what a port should be used for before configuring anything; use nmap when you need to confirm what's actually running.

Situations Where This Reference Actually Gets Used

• Writing a cloud security group before provisioning a database: Confirm the exact port and protocol for PostgreSQL (5432/TCP), MySQL (3306/TCP), Redis (6379/TCP), or MongoDB (27017/TCP) before writing an ingress rule, and note that all four should be scoped to an application subnet or security group, never 0.0.0.0/0.
• Debugging a connection that mysteriously times out: When a client can't reach a service, check whether the target port is one that's commonly blocked at the network edge — outbound SMTP on port 25 is blocked by default on most major cloud providers, which explains connection timeouts that have nothing to do with your security group rules.
• Writing a Kubernetes NetworkPolicy: Look up the correct port numbers for databases, message brokers, and internal APIs when defining ingress and egress rules, so pod-to-pod traffic is scoped as tightly as the application actually requires.
• Choosing a port for a new internal service: Before hardcoding a port in a service manifest, check that it doesn't collide with a well-known service or fall inside a range a corporate proxy or cloud provider commonly restricts.

What's Actually Stored Behind the Search Box

Port numbers form a core part of the TCP/IP model, standardized by IANA and formally described in RFC 6335. The full 0–65535 range splits into three bands: well-known ports (0–1023), reserved for foundational services and requiring elevated OS privileges to bind on Unix-like systems; registered ports (1024–49151), used by application software and middleware without special privileges; and dynamic or ephemeral ports (49152–65535), assigned automatically by the operating system for the client side of outbound connections. This tool's dataset holds over 200 entries drawn from that registry plus common real-world DevOps usage, each tagged with a port number, service name, protocol (TCP, UDP, or both), category, and a plain-English description of what it's for and any exposure risk.

Assumptions About Ports That Cause Outages

• Assuming a service only needs TCP because HTTP does: DNS famously uses both — UDP for ordinary lookups and TCP for zone transfers or responses over 512 bytes — and a firewall rule that only opens UDP/53 will work for months until a zone transfer or a large DNSSEC response silently fails.
• Exposing a database port directly to the internet "temporarily": Port 3306, 5432, 6379, or 27017 open to 0.0.0.0/0 — even briefly for debugging — is one of the most common causes of automated credential-stuffing and ransomware scans finding a database within minutes.
• Assuming outbound SMTP just works: Most cloud providers block outbound port 25 by default to curb spam, so an application trying to send mail directly rather than through port 587 with STARTTLS will fail in production despite working from a local dev machine with no such restriction.
• Forgetting privileged-port restrictions on Unix: Binding directly to port 80 or 443 requires root or CAP_NET_BIND_SERVICE on Linux, which is why most production setups either run a reverse proxy on the privileged port and forward to an unprivileged application port, or grant the capability explicitly rather than running the whole application as root.

Confirming What's Actually Listening, From the Terminal

This tool tells you what a port is conventionally used for; to see what's actually bound to a port on a live host, use ss -tulpn (or the older netstat -tulpn) on Linux, which lists every listening TCP and UDP socket along with the owning process. To check reachability from a remote machine, nmap -p 5432 10.0.1.20 or a simple nc -zv 10.0.1.20 5432 confirms whether a port is open, closed, or filtered by a firewall in between. Pair this reference for "what should this port be and is it safe to expose" with ss or nmap for "what is actually happening on this host right now" — the two questions look similar but need different tools to answer.

Frequently Asked Questions