Port & Protocol Reference

Port & Protocol Reference Overview

A port and protocol reference is a searchable database of TCP and UDP port numbers and the services that use them by convention. When configuring firewalls, writing security group rules, debugging network connectivity, or setting up a new service, engineers need to quickly look up which port a service uses, whether it is TCP or UDP, and what the security implications of exposing it are. Having this information instantly accessible reduces the time spent consulting documentation and eliminates common mistakes like accidentally opening port 3306 to the public internet.

Port numbers are a fundamental part of the TCP/IP networking model, defined in RFC 6335 and maintained by the Internet Assigned Numbers Authority (IANA). The 65,535 available port numbers are divided into three ranges: well-known ports (0–1023), which are assigned to core services and require elevated privileges to bind to on most operating systems; registered ports (1024–49151), used by application software and middleware; and dynamic or ephemeral ports (49152–65535), assigned by the OS for outbound connections. Understanding these ranges matters when writing firewall rules, configuring Kubernetes NetworkPolicies, or setting up cloud security groups.

Step-by-Step Example

Say you're writing an AWS security group for a new internal PostgreSQL instance and want to confirm you're locking it down correctly. Type "postgres" into the search box — the substring match scans port number, service name, category, and description simultaneously, returning the entry for port 5432/TCP under the Database category, with a description noting it should never be exposed to the public internet. Cross-check by clicking the Database category filter button to see it alongside MySQL (3306), Redis (6379), and MongoDB (27017) — all of which share the same exposure risk.

From there, you'd write a security group ingress rule scoped to TCP port 5432, sourced only from the application subnet's CIDR block or security group ID, never 0.0.0.0/0. If you instead needed to debug why an application can't reach an outbound SMTP relay, searching "smtp" surfaces port 25/TCP alongside a note that many cloud providers block outbound port 25 by default — pointing you toward port 587 with STARTTLS as the actual fix instead of spending an hour debugging security group rules that were never the problem.

Why DevOps Teams Use This

• Configuring firewall rules and cloud security groups: Look up the correct port and protocol before writing AWS security group ingress rules, GCP firewall rules, or iptables entries so that you open only the minimum necessary ports.
• Debugging connectivity failures: When a service is unreachable, check this reference to confirm you are targeting the correct port and protocol, and verify that no known security restriction applies to that port (such as cloud providers blocking port 25 for outbound SMTP).
• Writing Kubernetes NetworkPolicies: Reference port numbers for databases, message brokers, and microservice APIs when defining ingress and egress rules in Kubernetes NetworkPolicy manifests to achieve least-privilege pod networking.
• Planning a new service's port allocation: Before choosing a port for a new internal service, check this reference to avoid conflicts with well-known services or ports that are commonly blocked by corporate network policies or cloud provider restrictions.

Under the hood, the tool stores a curated database of over 200 port entries drawn from the IANA port registry and common DevOps usage patterns, each with a port number, service name, protocol (TCP, UDP, or both), category, and description. Category filter buttons and TCP/UDP toggle buttons narrow results in real time, and column header clicks trigger a client-side sort on the current filtered dataset — all filtering and sorting happens in the browser with no server round-trips.

Frequently Asked Questions