Common network ports and what a port number tells you

A practical port reference

Use the service's official requirements for real configuration. Some protocols use additional negotiated ports or different transport arrangements. A compact reference cannot replace a product's deployment documentation.

Distinguish a label from a verified service

A custom application could listen on TCP 22 without being SSH. A website could use HTTPS on 8443. Tools may display a conventional service name from a port table even when they have not identified the application.

TCP and UDP port numbers are separate. A TCP check on 53 does not prove that UDP DNS queries work. A timeout can reflect filtering, a missing listener, a stopped service, routing trouble, or probe behavior; it is not a detailed vulnerability finding.

Separate local use from public exposure

A service needed within a trusted LAN may not belong on the public Internet. Keep file sharing and administration behind appropriate private access boundaries. If you intentionally publish a service, scope the firewall rule, require authentication, keep software supported, and monitor its own logs.

Using an unusual port may reduce incidental noise but does not replace those controls. A broad rule can expose more than the one service you meant to test, and automatically created mappings should be reviewed.

Use port information in a diagnostic sequence

1. Identify the intended application, transport, and port.
2. Confirm the actual listener and local connectivity.
3. Check host and router rules, plus any upstream NAT or ISP filter.
4. Test externally with the correct protocol and the service's supported diagnostic.

This site's port checker attempts only selected TCP ports on your observed public IP. Its output is a useful reachability observation, not permission to scan another network or a certification that your server is secure.