Port numbers are the tiny address labels that keep network traffic from turning into a digital food fight. An IP address gets data to the correct computer, while a TCP or UDP port helps the operating system deliver that data to the correct application. Without ports, your browser, email client, database, game, and video call would all arrive at the same front desk and begin shouting their names.
This guide explains the most popular TCP and UDP port numbers, what they normally do, why the transport protocol matters, and how to troubleshoot or secure them. It also distinguishes official assignments from common defaults. That difference matters because a port number suggests a service; it does not magically prove which application is actually listening.
What Is a TCP or UDP Port Number?
A port number is a 16-bit value ranging from 0 through 65535. It works with an IP address and a transport protocol to identify a communication endpoint. A web server might listen on TCP port 443, for example, while a client connects from a temporary high-numbered source port. The conversation is identified by the source and destination IP addresses, source and destination ports, and transport protocol.
The Internet Assigned Numbers Authority divides the port space into three broad ranges:
- System or well-known ports: 0–1023. These are associated with foundational services such as SSH, DNS, HTTP, and HTTPS.
- User or registered ports: 1024–49151. Vendors and application developers commonly register services here, including database and remote-access products.
- Dynamic or private ports: 49152–65535. Operating systems commonly use this range for temporary client-side connections, although the exact ephemeral range can vary by platform and configuration.
Research basis: IANA registry and RFC 6335.
TCP vs. UDP: Same Port Number, Different Lane
TCP Is Connection-Oriented
Transmission Control Protocol establishes a connection and provides ordered, reliable delivery. It tracks sequence numbers, retransmits missing data, and controls traffic flow. That overhead is useful for web pages, email, file transfers, remote shells, and database sessions where missing or rearranged bytes can ruin the party.
UDP Is Datagram-Oriented
User Datagram Protocol sends independent datagrams without creating a reliable byte stream. UDP itself does not guarantee delivery, ordering, or duplicate protection. Applications use it when low overhead, fast exchanges, multicast, broadcast, or application-controlled recovery is more valuable than built-in reliability. DNS lookups, DHCP, NTP, voice traffic, and modern QUIC-based HTTP/3 are familiar examples.
TCP port 53 and UDP port 53 are therefore separate transport endpoints, even though both are associated with DNS. A firewall rule allowing one does not automatically allow the other. That small detail has caused enough troubleshooting sessions to qualify as a recurring workplace tradition.
Research basis: TCP, UDP, DNS, and HTTP/3 standards.
Most Popular TCP and UDP Port Numbers: Quick Reference
| Port | Protocol | Common Service | Typical Use |
|---|---|---|---|
| 20 | TCP | FTP data | Active-mode FTP data connection |
| 21 | TCP | FTP control | Commands, authentication, and session control |
| 22 | TCP | SSH | Secure remote shell, tunneling, SFTP, and SCP |
| 23 | TCP | Telnet | Legacy plaintext remote terminal access |
| 25 | TCP | SMTP | Mail transfer between servers |
| 53 | TCP/UDP | DNS | Name resolution, larger replies, and zone-related operations |
| 67 | UDP | DHCP server | Receives DHCPv4 client requests |
| 68 | UDP | DHCP client | Receives DHCPv4 server replies |
| 69 | UDP | TFTP | Simple file transfer, often for boot or device provisioning |
| 80 | TCP | HTTP | Unencrypted web traffic and redirects to HTTPS |
| 88 | TCP/UDP | Kerberos | Network authentication and ticket exchange |
| 110 | TCP | POP3 | Legacy email retrieval |
| 123 | UDP | NTP | Clock synchronization |
| 143 | TCP | IMAP | Email mailbox access and synchronization |
| 161 | UDP | SNMP | Network monitoring queries and responses |
| 162 | UDP | SNMP traps | Unsolicited monitoring notifications |
| 389 | TCP/UDP | LDAP | Directory queries and authentication-related lookups |
| 443 | TCP/UDP | HTTPS / HTTP/3 | Encrypted web traffic over TCP; HTTP/3 commonly uses UDP |
| 445 | TCP | SMB | Windows file and printer sharing |
| 465 | TCP | Message submission over TLS | Implicitly encrypted email submission |
| 500 | UDP | IKE | IPsec key exchange |
| 514 | UDP/TCP | Syslog | Traditional network event logging |
| 587 | TCP | Mail submission | Authenticated client-to-server email submission |
| 636 | TCP | LDAPS | LDAP over an implicit TLS connection |
| 993 | TCP | IMAPS | IMAP over implicit TLS |
| 995 | TCP | POP3S | POP3 over implicit TLS |
| 1433 | TCP | Microsoft SQL Server | Default database engine connection |
| 1521 | TCP | Oracle Net Listener | Default Oracle database client connections |
| 3306 | TCP | MySQL | Classic MySQL client/server protocol |
| 3389 | TCP/UDP | RDP | Microsoft Remote Desktop |
| 4500 | UDP | IPsec NAT-T | IPsec traffic through network address translation |
| 5060 | TCP/UDP | SIP | Voice and video session signaling |
| 5061 | TCP | SIP over TLS | Encrypted SIP signaling |
| 5432 | TCP | PostgreSQL | Default PostgreSQL server connection |
| 8080 | TCP | HTTP alternate | Web applications, proxies, development servers, and admin consoles |
Assignments and defaults checked against IANA, IETF RFCs, Microsoft, MySQL, PostgreSQL, and Oracle documentation.
Popular Port Numbers by Service Category
Web and Remote Access
TCP 80 is the default for HTTP, while TCP 443 is the default for HTTPS. HTTP/3 commonly uses UDP 443 through QUIC, so modern web traffic can use either transport. Ports 8080 and 8443 frequently host development servers, proxies, dashboards, and alternate web services, but the number alone does not prove that HTTP is present.
SSH normally listens on TCP 22, Telnet on TCP 23, and Remote Desktop on TCP and UDP 3389. SSH supports encrypted administration, tunneling, SFTP, and SCP. Telnet lacks modern transport encryption and belongs only in carefully isolated legacy situations. Internet-facing SSH and RDP should be restricted by source, protected with strong authentication, and preferably reached through a VPN, bastion, gateway, or identity-aware proxy.
Official web, SSH, Telnet, RDP, and cloud firewall guidance.
Email, DNS, Addressing, and Time
TCP 25 primarily carries SMTP relay between mail servers. Clients commonly submit outgoing mail on 587 or use implicit TLS on 465. POP3 uses 110 and POP3S 995; IMAP uses 143 and IMAPS 993. DNS needs both UDP and TCP 53, DHCPv4 uses UDP 67 for servers and 68 for clients, and NTP normally uses UDP 123 for clock synchronization.
Permitting UDP 53 but blocking TCP 53 can cause larger DNS responses and zone-related operations to fail. Accurate time is equally easy to underestimate: certificates, authentication, event correlation, and distributed applications all become grumpy when clocks drift.
Email, DNS, DHCP, and NTP standards.
File Sharing, Monitoring, Directories, and Databases
FTP uses TCP 21 for control; active-mode data is associated with TCP 20, while passive mode negotiates additional ports. TFTP uses UDP 69. SMB commonly uses TCP 445 and should rarely be exposed directly to the public internet. SNMP normally uses UDP 161 for queries and 162 for notifications, while LDAP commonly uses 389 and LDAPS 636.
Major database defaults include TCP 1433 for Microsoft SQL Server, 1521 for Oracle, 3306 for MySQL, and 5432 for PostgreSQL. These listeners should normally be limited to approved application hosts, administrators, or private network paths rather than the entire internet.
FTP, SMB, SNMP, LDAP, and database references.
Registered Port Does Not Mean Guaranteed Service
Port assignments are conventions, not enforcement mechanisms. An administrator can run SSH on 2222, a web app on 9000, or a custom service on 443. Likewise, malware can use a familiar port to blend into expected traffic. Security devices increasingly inspect application behavior, encryption metadata, identities, and traffic patterns instead of trusting port numbers alone.
Changing a default port can reduce low-effort scanning noise, but it is not a substitute for authentication, patching, encryption, segmentation, monitoring, or rate limiting. Moving the front door does not make the house burglar-proof; it merely confuses delivery drivers for a while.
Port-based identification limitations and application-aware guidance.
How to Check Which Ports Are Open or Listening
A listening port exists because a process has bound to it. A remotely reachable port additionally requires a working route and permission through host firewalls, network firewalls, cloud security groups, access control lists, and any intervening load balancer or proxy.
Useful Commands on Linux
Useful Commands on Windows
UDP testing needs extra care. Because UDP has no connection handshake, silence can mean the port is filtered, the packet was lost, the service ignored the request, or the service received it and had nothing useful to say. Packet captures and application logs often provide the missing context.
Security Best Practices for TCP and UDP Ports
- Allow only required services. Begin with a restrictive policy and create narrow exceptions.
- Limit the source. Administrative and database ports should usually accept traffic only from approved networks, hosts, VPNs, gateways, or identity-aware access services.
- Prefer encrypted protocols. Replace Telnet with SSH, plaintext web access with HTTPS, and insecure management protocols with protected alternatives.
- Patch the listening application. A firewall cannot repair a vulnerable service that must remain reachable.
- Monitor both standard and unusual ports. Attackers and administrators can move services away from defaults.
- Document ownership. Every allowed port should have a business purpose, service owner, expected traffic direction, and review date.
Cloud and enterprise guidance consistently favors minimizing public exposure, especially for SSH, RDP, SMB, and database services. An open port is not inherently a vulnerability, but an unnecessary open port is an unnecessary opportunity.
Security basis: NIST, CISA, AWS, Google Cloud, Red Hat, and Microsoft guidance.
Experience-Based Lessons from Real-World Port Troubleshooting
Note: The following are composite field scenarios drawn from recurring network-administration patterns. They are practical lessons, not claims that every environment is configured the same way.
Lesson 1: “The Firewall Is Open” Is Only the Beginning
A common support ticket says, “Port 443 is open, but the website is down.” The firewall rule may indeed allow 443, yet the application could be stopped, listening only on 127.0.0.1, bound to the wrong interface, or waiting behind a load balancer with an unhealthy backend. The fastest troubleshooting sequence is layered: confirm the process, confirm the local listener, test from the same host, test from the local network, and finally test across the firewall. Skipping directly to the perimeter often turns a five-minute diagnosis into an afternoon of enthusiastic finger-pointing.
Lesson 2: DNS Needs More Than One Checkbox
One memorable class of failure occurs when UDP 53 is permitted but TCP 53 is blocked. Most browsing appears normal because many DNS answers fit in UDP. Then a larger response, DNSSEC-related exchange, or zone operation needs TCP, and the application behaves as though the internet has developed selective amnesia. The lesson is not to open everything blindly; it is to understand the full transport requirements of the service instead of copying a one-line port list from an old diagram.
Lesson 3: FTP Has a Supporting Cast of Ports
Teams often allow TCP 21 and expect FTP to work completely. Authentication succeeds, the directory may even appear, and the actual file transfer stalls. Passive mode negotiates an additional data port, so the firewall, server configuration, and network address translation rules must agree on a defined passive range. FTP troubleshooting teaches a durable principle: the first connection may only negotiate the second connection. Reading the protocol flow is more useful than staring harder at the famous port number.
Lesson 4: Moving SSH or RDP Does Not Make It Invisible
Changing SSH from 22 to 2222 or RDP from 3389 to a high port can reduce log noise from simplistic bots. It can also create a false sense of safety. Broad scans find nonstandard listeners, and a protocol fingerprint can reveal what is running. The stronger pattern is layered access: restrict source networks, require keys or multifactor authentication, use a bastion or VPN, patch promptly, and alert on unusual login behavior. A custom port is seasoning, not the meal.
Lesson 5: Database Defaults Are Convenientand Easy to Mis-Expose
Development environments frequently begin with a database listening locally. Later, someone changes the bind address to all interfaces so a teammate or container can connect. The application starts working, everyone celebrates, and the database may quietly become reachable from a much larger network than intended. The fix is not merely changing 3306 or 5432. The durable fix is defining exactly which application subnets or identities need access, enforcing encryption and strong credentials, and checking the exposure from outside the host.
Lesson 6: UDP Silence Is Not a Verdict
A TCP test usually produces a recognizable success, rejection, or timeout because TCP performs a handshake. UDP can simply remain quiet. A scanner may label the port “open or filtered,” which is accurate but emotionally unsatisfying. Administrators get better answers by sending a valid application request, checking server logs, capturing packets on both sides, and verifying return-path rules. With UDP, lack of applause does not prove the audience left the theater.
Conclusion
The most popular TCP and UDP port numbers form a practical vocabulary for networking. Ports 22, 53, 80, 443, 445, and 3389 can quickly suggest SSH, DNS, web traffic, SMB, and Remote Desktop, while ports such as 1433, 1521, 3306, and 5432 point toward common database platforms. Still, a port is only a clue. The actual service, transport, encryption, exposure, and access policy determine what the traffic means and whether it is safe.
Use port lists as a starting map, not an autopilot. Verify the listener, understand every required flow, permit the smallest necessary scope, and monitor what crosses the boundary. Networks are much easier to manage when every open door has a purposeand when somebody remembers who has the key.
Research note: Port assignments and operational guidance were synthesized from 14 authoritative organizations and documentation sites, including IANA, the RFC Editor/IETF standards archive, NIST, CISA, Microsoft, Red Hat, Cisco, AWS, Google Cloud, Cloudflare, Oracle, IBM, MySQL, and PostgreSQL. Registry details were checked on July 20, 2026. Default ports can be changed, and local policy or product configuration may differ.
Cross-check sources from additional authoritative domains.
