A common network ports list is a reference, not a verdict. It tells you what a port number is most often registered for, but it cannot tell you which application is actually running on a host, whether observed traffic is safe, or whether a firewall should allow it. Treating a curated table like a one-stop answer leads to the mistakes that hurt most in production work: opening firewall rules for the wrong service because a number looked familiar, assuming a registered name proves identity, copying a 40-row list into a runbook and calling it complete, and trusting a single search hit without checking the authoritative registry. Avoiding those mistakes starts before you ever look at a row. You decide which question you are actually asking, you remember that any short curated table is deliberately incomplete, and you plan a verification step that uses platform-native tools, service configuration, logs, and the IANA registry before any policy change. The list is a translator, not a judge.
The Mistakes That Come From Treating a Port List as an Answer
Most port-list mistakes fall into a small number of patterns. The catalog below names them, because naming a mistake is the first step to avoiding it.
- Confusing registration with identity. A registered name is what IANA assigned to a number; it is not what is necessarily running on your server. A port absent from the list may be valid, registered, private, ephemeral, or simply outside the curated set.
- Confusing a hit with safety. An open port is a packet destination, not a verdict about the application behind it. Traffic on a registered number may belong to a different program, a misconfiguration, or an attacker reusing a known number.
- Confusing scope with coverage. A 40-row curated table covers familiar services. It does not enumerate the dynamic range 49152 through 65535, vendor conventions, or every modern protocol extension such as SCTP or DCCP.
- Confusing a copy-paste with a policy. A tab-separated export of visible rows is a reference snippet for notes and tickets. It is not a firewall allowlist and it is not a complete audit artifact.
- Confusing a one-time lookup with a habit. The list gives you a likely service. Confirming it with ss, netstat, lsof, service configuration, and a registry check is part of the lookup, not an extra chore you do when you have time.
What a Curated 40-Port List Actually Covers
The Common Network Ports List is a curated table of 40 frequently encountered TCP and UDP service ports, deliberately short so the rows stay readable. Every row carries one numeric port, the selected IANA service name, one or more relevant transport protocols, a short plain-language description, and a category used by the filter. Ports are sorted numerically and unique within the table. Search matches the port number, the service name, the description, and the category, so a query for 443 returns HTTPS, a query for PostgreSQL returns 5432, and a query for mail can return SMTP, POP3, IMAP, message submission, and their TLS variants.
The table is honest about its shape. It does not pretend to reproduce the entire IANA registry, and it favors common operational use over exhaustive coverage. DNS appears with TCP and UDP, while HTTPS is shown with TCP in this concise table. That choice makes the list scannable, but it is not an exhaustive statement about every modern protocol, every alternate registration, or every deployment convention. When a decision needs exhaustive or time-sensitive evidence, the linked IANA registry is the next step, not a fallback.
How to Look Up a Port Without Drawing the Wrong Conclusion
The lookup itself has three moves. Doing them in order keeps the result in proportion to what the list can actually say.
- Enter a port number, service name, product term, or description in the search field. The search is case-insensitive and matches against the port number, the selected IANA service name, the description, and the category, so the same field handles 443, HTTPS, PostgreSQL, and mail.
- Optionally narrow the visible rows with the TCP or UDP protocol filter and the service category filter. The protocol filter distinguishes transport where that distinction changes your mental model, and the category filter can isolate databases, web services, network infrastructure, remote access, or another supported group without changing the underlying data.
- Review the matching registration hints, then copy only the visible rows as tab-separated text when you need a reference snippet for a ticket, note, runbook, or study session. The copy action exports what is on screen, so a filtered view stays a filtered export.
After these three steps, the list has told you what a number most often means. It has not told you what is running on the host you actually care about.
Why "Open" Does Not Mean "This Application"
The most expensive mistake with a port list is reading the table as proof of identity. IANA explicitly warns that assignment does not endorse an application and does not prove observed traffic is good. A server can listen on an unusual port, several registered names may exist for one number, and a packet using a registered number may belong to a different program entirely. The article on open ports and running applications walks through the same caution in detail; the short version is that a port number is a hint, never an identifier, and never a safety stamp. Confirming the actual process, the actual configuration, the actual traffic, and the actual endpoint belongs in the same workflow as the lookup, not after it.
The IANA Port Ranges and Why Absence Is Not Proof
RFC 6335 and the IANA registry divide the 16-bit port space into three ranges. Knowing them keeps a "missing" row from being misread as a "blocked" or "unsafe" verdict.
| Range | Numbers | Common use |
|---|---|---|
| System Ports | 0 through 1023 | Assigned services that typically require privileged bind on most operating systems |
| User Ports | 1024 through 49151 | Registered services available to ordinary user processes |
| Dynamic or Private Ports | 49152 through 65535 | Ephemeral source ports and private or unassigned use |
A 40-row curated table covers familiar System and User Ports. It does not enumerate the dynamic range, and a port absent from the table may still be valid, registered, private, ephemeral, or widely used by vendor convention. Absence from the table means only that the number is outside the curated set, never that the number is unavailable, dangerous, or unknown to the registry.
Verifying a Hit Before It Becomes a Policy
For troubleshooting, the list translates a number into a likely service. Confirming the actual endpoint is the next step. Use platform-native tools such as ss, netstat, or lsof to see which process is bound, then read the service configuration and recent logs to confirm the binding. A common ports reference is the starting hypothesis, not the conclusion.
For firewall work, the list is even further from a decision. A policy needs verified business purpose, direction (inbound or outbound), source, destination, protocol, authentication, encryption, business owner, and least-privilege scope. The piece on whether a can a common ports list be a firewall allowlist spells out why a 40-row reference is not a rule set; the same logic applies to deny lists, segmentation policies, and security exception tickets. The official IANA Service Name and Transport Protocol Port Number Registry is the authority for the assignment, and RFC 6335 defines how the number space is divided and assigned. When a row matters, follow it back to one of those two sources before you write a rule.
Building a Runbook Habit That Stays Honest
The final mistake worth naming is the habit of using a port list as a shortcut past the registry. Treat the list as a fast local lookup for common cases, with explicit limits, stable filters, and a direct path to the authoritative registry when a decision needs exhaustive or time-sensitive evidence. Reference rows were checked against the IANA registry, but the descriptions are shortened for scanning and do not override the registry wording. When a row is missing, follow the absence back to the registry rather than treating the table as a closed world. The list tells you what a port is most often called. The registry, the host, and the policy are what tell you what is actually true.