Common Network Ports Every IT Student Should Know

Network ports are one of the first things that make networking feel real.

IP addresses tell you which device traffic is going to. Ports tell you which service or application should receive that traffic on the device.

If you see this:

192.168.1.10:443

You are looking at:

• Host: 192.168.1.10
• Port: 443
• Likely service: HTTPS

That small number after the colon gives you a strong clue about what is happening on the network.

This guide is a practical port-number reference for IT students, junior system administrators, help desk technicians, networking beginners, and anyone preparing for IT fundamentals or networking exams.

If you are building the foundation, read Network Communication Basics, Internet Protocol (IP) Explained, TCP vs UDP Explained With Examples, and DNS Explained too. Ports sit on top of those concepts.

Reading path: Start with the mental model, follow the worked request or packet examples, and finish with the troubleshooting or memory guide.

What Is a Port?

A port is a 16-bit number used by transport protocols such as TCP and UDP to identify an application or service on a host.

The port number is not enough by itself. A network conversation is identified by a combination of values:

A network conversation is identified by five values: source IP, source port, destination IP, destination port, and the transport protocol.

Example:

• Client: 192.168.1.25:51432
• Server: 93.184.216.34:443
• Protocol: TCP

In that example:

• 51432 is the client’s temporary source port.
• 443 is the server’s destination port.
• TCP carries the connection.
• The destination port suggests HTTPS.

The server listens on a known port. The client usually uses a temporary high-numbered source port.

Port Numbers Are Clues, Not Proof

This is one of the most important lessons in the whole post:

Port number != guaranteed application

Port 443 usually means HTTPS, but an administrator can run something else on 443. Malware can use common ports to blend in. Developers can run web apps on 8080. A database can be moved from its default port to a custom one.

So port numbers are extremely useful clues, but they are not final proof.

You should combine port information with:

The key items here are Process information on the host, Service banners, Firewall rules, Packet inspection, Application logs, TLS certificate details, and Endpoint or server configuration.

IANA, the official registry authority for service names and port numbers, makes the same general point: assigned ports help identify services, but traffic on a registered port is not automatically good traffic and does not necessarily correspond to the registered service.

TCP vs. UDP Port Numbers

TCP and UDP both use port numbers, but they behave differently.

The same port number can exist for both TCP and UDP.

For example:

• 53/tcp
• 53/udp

Both are DNS-related, but they are different transport sockets.

That is why you should write ports with the protocol when clarity matters:

When clarity matters, write the transport with the port: TCP/443, UDP/53, TCP/22, or UDP/123.

Port Ranges

Port numbers range from 0 to 65535.

The ranges matter because they tell you what kind of port you are probably looking at.

If a server is listening on 22, that is likely a well-known service port.

If a client connects from 52418, that is probably a temporary source port.

The Core Ports to Memorize First

If you are new, start here.

You do not need to memorize every port on the internet. You do need to recognize the ones that appear constantly in troubleshooting, firewall rules, packet captures, and exam questions.

Web Ports

Web traffic is where most students first see ports in action.

When you type:

https://example.com

The browser assumes:

TCP/443

Unless the URL specifies another port:

https://example.com:8443

For plain HTTP:

http://example.com

The browser assumes:

TCP/80

Modern browsers may also use HTTP/3, which runs over QUIC on UDP/443. That is why UDP/443 in logs is not automatically suspicious. It may be normal modern web traffic.

DNS and Addressing Ports

These ports help devices find names, addresses, and network configuration.

DNS usually starts with UDP because most DNS lookups are small and quick.

DHCP uses UDP because a new client may not have a working IP address yet. It needs broadcast-style local network discovery before it can fully participate on the network.

If a user says:

Troubleshooting symptom: “I am connected to Wi-Fi, but websites do not open.”

Think about:

• Did DHCP assign an IP address?
• Is the default gateway correct?
• Are DNS servers configured?
• Can the client resolve names?
• Can the client reach the resolved IP?

Ports 53, 67, and 68 often appear early in that troubleshooting path.

Remote Access and Administration Ports

Remote access ports are important because they are powerful.

From an IT operations perspective:

• SSH should use strong keys or strong authentication.
• Telnet should usually be disabled.
• RDP should not be exposed directly to the internet.
• WinRM should be carefully scoped and monitored.

Remote access ports are not bad by themselves. They are risky when exposed too broadly or protected poorly.

Email Ports

Email has more ports than many beginners expect because sending and receiving mail are separate functions.

The practical distinction:

The practical distinction is simple: SMTP sends mail, while IMAP and POP3 retrieve mail.

For most modern clients, IMAP over TLS on 993 is more common than POP3.

For sending mail from a client application, 587 is the standard port to expect in many configurations.

Port 25 is still important, but it is more about mail server to mail server delivery than a normal user submitting mail from a laptop.

File Transfer Ports

File transfer protocols vary a lot in security and behavior.

FTP is old and awkward with firewalls because it uses separate control and data channels.

SFTP is not “FTP with encryption.” It is a different protocol that runs over SSH.

TFTP is simple and commonly seen in device bootstrapping, firmware workflows, PXE environments, and network equipment scenarios. It should not be treated as secure.

SMB is central to Windows file sharing:

A Windows UNC path such as \\server\share normally points to an SMB file share, commonly reached over TCP/445.

That usually means TCP/445 somewhere in the background.

Windows and Directory Service Ports

Windows environments have several important ports.

If you work around Active Directory, these ports appear constantly.

For a domain-joined Windows machine, “network login” is not one single thing. It can involve DNS, Kerberos, LDAP, SMB, RPC, and time synchronization.

That is why Active Directory troubleshooting often starts with:

The key items here are DNS resolution, Time sync, Domain controller reachability, Kerberos, LDAP, and SMB.

Monitoring and Logging Ports

Monitoring tools need ways to query devices and receive events.

Time synchronization deserves special attention.

If clocks are wrong, many systems become painful:

The key items here are Kerberos authentication can fail, Logs are harder to correlate, Certificates can appear not yet valid or expired, and Incident timelines become unreliable.

NTP on UDP/123 is boring until it breaks.

SNMP is common for network devices, printers, UPS systems, servers, and monitoring platforms. Older SNMP versions should be treated carefully because community strings are not strong authentication.

Database Ports

Database ports are useful for developers, administrators, and security reviews.

Database ports should usually be tightly restricted.

A public website may need to expose TCP/443 to the internet. A production database usually should not expose TCP/5432, TCP/3306, or TCP/1433 to the internet directly.

Better patterns include:

The key items here are Private networks, Firewall allowlists, VPN or private access, Managed database private endpoints, Strong authentication, and TLS for database connections.

Identity and Access Ports

Authentication and authorization systems have their own common ports.

RADIUS is common in:

The key items here are Wi-Fi authentication, VPN authentication, Network access control, and 802.1X environments.

LDAP and Kerberos are common in enterprise identity environments, especially Active Directory.

Cloud identity systems such as Microsoft Entra ID are usually accessed through HTTPS on TCP/443 from the client side, but hybrid identity environments may still rely on these traditional infrastructure ports internally.

Common Port Groups by Scenario

Sometimes it is easier to remember ports by workflow rather than by number.

Loading a Website

Getting an IP Address

Remote Admin

Sending and Reading Email

Windows File Sharing

Monitoring

How Ports Appear in Real Troubleshooting

Ports show up in real support tickets all the time.

Example 1: Website Does Not Load

Start with layers:

1. Can the user resolve the name?
2. Can the user reach the IP?
3. Can the user connect to TCP/443?
4. Does TLS succeed?
5. Does HTTP return a valid response?

Useful commands:

Resolve-DnsName example.com
Test-NetConnection example.com -Port 443

On Linux/macOS:

dig example.com
nc -vz example.com 443

Example 2: RDP Does Not Work

Ask:

• Is the target online?
• Is Remote Desktop enabled?
• Is TCP/3389 reachable?
• Is a firewall blocking it?
• Is a VPN required?
• Is Network Level Authentication involved?
• Are user permissions correct?

Command:

Test-NetConnection server01 -Port 3389

Example 3: DNS Works on Mobile Data but Not Office Wi-Fi

That points toward the local network path.

Check:

The key items here are DHCP DNS server assignment, Local resolver health, Firewall rules for UDP/TCP 53, VPN or proxy settings, and DNS over HTTPS settings in the browser.

Example 4: Email Client Cannot Send Mail

Check:

• Is the client using 587 or 465?
• Is authentication configured?
• Is TLS enabled?
• Is the ISP blocking outbound 25?
• Is the mail provider expecting modern authentication?

The port is only part of the answer, but it tells you where to start.

Commands Every Student Should Practice

Windows PowerShell

Test whether a TCP port is reachable:

Test-NetConnection example.com -Port 443

Check DNS:

Resolve-DnsName example.com

Show listening TCP ports:

Get-NetTCPConnection -State Listen

Show process information:

Get-Process -Id (Get-NetTCPConnection -LocalPort 443 -State Listen).OwningProcess

Windows netstat

netstat -ano

Useful columns:

The key items here are Local address, Foreign address, State, and PID.

The PID can be matched to a process in Task Manager or PowerShell.

Linux ss

ss -tulpen

Common flags:

netcat

nc -vz example.com 443

This is useful for quickly checking whether a TCP port is reachable.

curl

curl -I https://example.com

This checks the HTTP layer, not just the port.

That distinction matters:

A port can be open while the application behind it is unhealthy, misconfigured, or unable to complete its protocol handshake.

Reading Firewall Rules

Firewall rules usually need five things:

A firewall rule usually describes five fields: its source, destination, protocol, port, and the resulting action.

Example:

A port list helps you understand what a firewall rule is probably trying to do.

But always ask:

• Does the source really need this access?
• Does the destination need to expose this service?
• Is the protocol correct?
• Is the port encrypted or plain text?
• Is there a safer management path?

Plain Text vs. Encrypted Ports

Many protocols have older plain-text ports and newer encrypted variants.

This does not mean every connection on the encrypted port is automatically safe, but it is a better default.

If you are designing or reviewing a network, be suspicious of plain-text management protocols.

Ports That Should Make You Pause

Some ports are not always bad, but they deserve extra attention when exposed broadly.

The lesson is not “block everything.” The lesson is:

• Expose only what needs to be exposed.
• Restrict who can reach it.
• Monitor what happens.

A Practical Memory Method

Do not try to memorize 100 ports in one night.

Group them by job:

Then practice recognizing them in context:

1. Why would a client talk to UDP/53 before TCP/443?
2. Why would a Windows file server need TCP/445?
3. Why is UDP/123 important for authentication?
4. Why is TCP/3389 risky on the public internet?
5. Why would a database port be blocked by default?

Questions like these turn memorization into understanding.

Quick Reference Table

Further Reading

Official references:

• IANA Service Name and Transport Protocol Port Number Registry
• RFC 6335: IANA Procedures for the Management of the Service Name and Transport Protocol Port Number Registry

Final Thoughts

Ports are small numbers with a lot of meaning.

They help you read firewall rules, understand packet captures, troubleshoot applications, recognize risky exposure, and explain how services are reached across a network.

The key is to remember the role of ports without overtrusting them:

A useful memory aid is: IP address = which host, port number = which service, and protocol = how the communication behaves.

Once you understand that, the port list stops being trivia. It becomes a practical map of how real networks work.