List of TCP Ports and UDP Ports (Well-Known)

What “well-known ports” really mean (and why you should care)

A port is a 16-bit number (0–65535) used to route network traffic to the right application on a device.
The industry commonly groups ports into ranges:
well-known/system ports (0–1023),
registered/user ports (1024–49151),
and dynamic/private (49152–65535).
The official registry of service-name and port assignments is maintained by IANA, and the ranges are widely referenced in vendor guidance.

So what makes a port “well-known”? It’s not that it’s famous on social media. It’s that the number is traditionally reserved for
a widely recognized service. For example, if you tell someone “HTTPS,” they assume TCP 443 unless you say otherwise.
That shared expectation is what keeps networks interoperableand what makes port lists so useful when you’re diagnosing
“Why won’t this connect?” at 2:00 a.m.

One important reality check

Port numbers are conventions, not laws of physics. Administrators can run web apps on TCP 8443, SSH on TCP 2222,
or DNS on a custom port in controlled environments. Still, when you’re scanning logs, tuning firewall rules, or reading a vendor’s
documentation, the well-known port list is your first language.

TCP vs UDP: the fast mental model

TCP: “I need this delivered correctly.”

TCP is connection-oriented and reliability-focused. It’s commonly used where order and delivery matter:
web browsing (HTTP/HTTPS), email transport, file transfer control channels, directory services, and remote admin sessions.
If you’ve ever waited for a big download to finish, you’ve benefited from TCP’s “no missing pieces” attitude.

UDP: “I need this delivered quickly.”

UDP is connectionless and lightweight. It’s commonly used for time sync (NTP), simple queries (DNS is often UDP-first),
telemetry, streaming-style needs, and protocols where the application can tolerate (or handle) loss. UDP is the reason your network
can do lots of small, fast requests without throwing a formal dinner party for every packet.

Many services can use both TCP and UDP depending on the situation. DNS is a classic example: it’s mostly UDP on port 53,
but it also uses TCP 53 in cases like larger responses or specific operations.

Quick-reference table: common well-known TCP/UDP ports (0–1023)

Below is a practical, most-seen-in-the-wild list of well-known ports. It’s not every single historical assignment in 0–1023
(the official registry is enormous), but it covers the ports you’ll routinely bump into in IT operations, networking, and security work.

Tip: When you see “TCP/UDP” in the table, it means you might encounter either transport in real deployments.
Always check the service configuration and the vendor documentation for the exact implementation you’re using.

A quick note about the table: you may notice a couple of entries above 515 that are still below 1024 (like 993 and 995).
They’re still in the well-known range, even if your day-to-day work mostly revolves around the “headline” ports (22, 53, 80, 443, 445, etc.).

Ports you’ll see together in real life (because networks travel in packs)

1) “Why can’t I browse the web?” starter pack

• TCP 443 (HTTPS) and sometimes TCP 80 (HTTP)
• UDP/TCP 53 (DNS) so names like example.com can become IP addresses
• UDP 123 (NTP) in environments where time sync is enforced (certs and auth care about time)

If HTTPS fails but DNS works, you might reach an IP but get blocked at a firewall rule. If DNS fails, everything looks broken
even if the internet is finebecause you can’t “phone a friend” when you don’t know the friend’s number.

2) Windows-heavy networks: the “lots of ports, lots of feelings” bundle

• UDP/TCP 53 (DNS)
• TCP/UDP 88 (Kerberos)
• TCP 135 (RPC endpoint mapping) plus dynamic high ports depending on services
• TCP 445 and sometimes TCP 139 (SMB/file sharing history)
• TCP/UDP 389 (LDAP) and/or TCP 636 (LDAPS)

This is where people learn the difference between “a port is open” and “the app behind it is healthy.”
You can have a listening port and still fail authentication, certificates, or policy checks.

3) Monitoring and logging: “tell me what’s happening” traffic

• UDP 161/162 (SNMP polling and traps)
• UDP 514 (syslog default; sometimes TCP/TLS in modern setups)

Monitoring works best when it’s boring. If your graphs are exciting, something is probably on firemetaphorically, ideally.

4) Email plumbing: it’s more than “just send it”

• TCP 25 (SMTP transfer)
• TCP 110/995 (POP3 / POP3S)
• TCP 143/993 (IMAP / IMAPS)

Email has multiple “lanes” because sending, receiving, and syncing are different jobs. If a mail app can’t fetch messages,
the issue might be IMAPS (993) even if SMTP (25) is perfectly fine.

Security notes: what to open, what to question

Default doesn’t mean “safe to expose”

Well-known ports are well-known to everyoneadmins, developers, scanners, and attackers. That doesn’t mean you should play
“open bar” with them. For example:

• SSH (22) is essential for admins, but you usually want it restricted to trusted IP ranges, VPNs,
  or bastion hostsespecially in cloud environments.
• SMB (445) is frequently targeted. If it’s exposed to the public internet without strict controls,
  that’s not “brave”it’s “a future incident report.”
• SNMP (161/162) is useful, but only when locked to specific management systems, with strong auth and minimal exposure.

Cloud and firewalls: open the minimum, not the mood

A practical rule: if you’re adding inbound rules like SSH (22) or RDP (3389), authorize only the specific IP ranges that need access,
not the entire internet. “0.0.0.0/0” is convenient, but convenience is rarely free.

Ports are symptoms; configuration is the diagnosis

If a service “uses” a port, that doesn’t mean every flow is one simple rule. Windows services, clustering, and many enterprise apps
can involve dynamic port ranges or additional dependencies. When troubleshooting, capture the actual flow:
source IP, destination IP, destination port, and transportthen validate what the application expects.

How to look up ports the right way (without guessing)

Step 1: Confirm what the app is listening on

• Windows: netstat -ano (pair with Task Manager / PID mapping)
• Linux/macOS: ss -lntup or lsof -i :443

This tells you whether the service is actually bound to the port (and to which interface). “Listening on 127.0.0.1”
is very different from “listening on 0.0.0.0.”

Step 2: Confirm network reachability

• From a client: try the service (browser for 443, SSH client for 22, etc.)
• From the network edge: check firewall/security group rules for the exact port and protocol

Step 3: Confirm the “both TCP and UDP” gotcha

Some services trip people up because the same number can show up under different transports. DNS (53) is a classic:
you can allow UDP 53 but block TCP 53 and then wonder why “most stuff works, but some lookups fail in a very dramatic way.”

Step 4: Use the authoritative registry when you’re unsure

When a port number looks unfamiliar, rely on the official service-name/port registry for current assignments,
and treat random internet lists as “helpful hints,” not gospel.

Experience section: lessons learned the hard way (so you don’t have to)

Here are some real-world “ports and consequences” momentsgeneralized, anonymized, and served with a side of humorbecause nothing
teaches networking like the gentle panic of a production alert.

1) The “DNS is fine” lie (a classic)

A team once swore DNS was healthy because most lookups worked. The twist: the firewall allowed UDP 53 but blocked
TCP 53. Smaller responses sailed through; bigger ones face-planted. The symptom wasn’t “DNS down,” it was
“only certain domains randomly fail, especially the ones you need right now.” The fix wasn’t magicaljust allowing TCP 53 where needed
but the lesson stuck: if a service can use both transports, verify both paths.

2) Time drift: the silent saboteur

When authentication breaks, people blame passwords. When certificates fail, people blame “the cert thing.” But more than once,
the real culprit was time. NTP (UDP 123) was blocked outbound, so servers drifted. Logs didn’t line up. Kerberos got cranky.
TLS validation got suspicious. The environment felt haunted. Once time sync was restored, the “mysterious” issues evaporated.
Moral: if your systems disagree on what time it is, they will also disagree on what reality is.

3) SSH exposed “just temporarily” (famous last words)

Opening TCP 22 to the world for a quick maintenance task feels harmlessuntil you check the logs and discover you’ve become
the star of an unsolicited global audition for password guessing. Even if you change the port, scanners will still find you.
Better habits: restrict by IP, use keys, add MFA where possible, and keep the “temporary” rule from becoming a permanent souvenir.

4) SMB on the internet: don’t

Another evergreen: exposing TCP 445 (and sometimes the NetBIOS era ports) beyond where it belongs. SMB is powerful inside a
trusted environment with modern hardening. Outside? It’s an invitation to trouble. The “experience” here is mostly watching security tools
light up like a Christmas tree and then spending the afternoon explaining to leadership why “file sharing” should not be “file sharing with
literally everyone.”

5) Syslog and SNMP: useful, but not a free-for-all

Logging and monitoring are the grown-up versions of “tell me everything,” using ports like 514 (syslog) and 161/162 (SNMP).
The mistake is letting “everything” include the entire network (or worse, the internet). The best experience I’ve seen is when teams treat
these as management-plane services: tightly scoped sources, well-defined destinations, and deliberate authentication/encryption choices.
The worst experience is when someone learnsvia a surprisewhat “unauthenticated management traffic” can do.

The big takeaway from years of port wrangling is simple: ports are a map, not the territory.
They tell you where to look first, how traffic is supposed to flow, and what dependencies might exist. But the real truth lives in
configuration, identity, encryption, and the sometimes-chaotic reality of “what changed last Friday.”
Keep your port list handy, verify with authoritative references when needed, and remember: the network is never brokenjust misunderstood.