A port number identifies a transport-layer endpoint inside a host. It does not identify the whole application, guarantee that the expected software is listening, or decide whether the person initiating a connection is authorized. Those distinctions are the foundation of safe firewall policy, troubleshooting and service deployment. A web server might listen on TCP port 443, but the service also depends on the server address, network route, TLS configuration and application authentication.<\/p>\n
The useful question is not simply which ports are open. It is which protocol and endpoints communicate, how the connection is established, which component maps the traffic to a process, and what security decisions happen after a packet reaches that process. TCP ports and UDP ports share familiar numbers but use distinct transport namespaces. A policy describing port 53 without its protocol, direction and endpoint can hide the actual behavior being permitted.<\/p>\n
TCP uses 16-bit source and destination port fields. A host's TCP stack associates an established connection with its transport protocol and source\/destination addresses and ports, commonly described as the five-tuple. Two browsers can contact the same TCP 443 listener simultaneously because their client addresses or source ports differ; the server distinguishes the connections rather than dedicating one server port to each user. The sequence, acknowledgment and flag fields carried alongside those ports belong to the TCP header<\/a>, not to DNS or HTTP.<\/p>\n UDP also has source and destination port fields, but it does not establish a TCP-style connection or provide TCP's ordered, reliable byte stream. An application protocol built over UDP must handle its own exchanges and any necessary reliability or replay controls. Port 53 can be used over both UDP and TCP for DNS operations, but allowing UDP 53 alone may be insufficient for responses or operations that use TCP. The transport and the application's design determine what the rule actually permits.<\/p>\n A useful troubleshooting example is an HTTPS request from IANA divides port-number registries into System ports 0\u20131023, User ports 1024\u201349151 and Dynamic\/Private ports 49152\u201365535. RFC 6335 establishes those registry ranges; RFC 7605 explains how software should use assigned and unassigned transport ports. A registered number indicates an assignment in a registry, not a guarantee that a given host runs that software, or that every implementation must use only that number.<\/p>\n Many operating systems reserve binding low-numbered ports for privileged processes or configured capabilities, but that is a platform enforcement choice, not an intrinsic TCP packet rule. The client operating system chooses ephemeral source ports according to its configured policy and available sockets; it need not draw them exclusively from the IANA Dynamic range. Administrators should confirm the local ephemeral range before writing a rule that assumes one universal client range.<\/p>\n Port examples are still useful: TCP 22 commonly carries SSH, TCP 80 HTTP and TCP 443 HTTPS. A scanner finding TCP 443 reachable proves neither that TLS is correctly configured nor that the protected application rejects unauthorized requests. The packet must reach a listening process, and that process must implement the intended authentication, authorization and input validation.<\/p>\n The original service inventory also included mail transfer on TCP 25 and common database listeners such as MySQL on TCP 3306 and PostgreSQL on TCP 5432. These are conventional service mappings, not guaranteed identities or permission to expose a database to the internet. For a database maintenance path, verify the server’s actual bound interface and socket, restrict the approved client addresses, and test database authentication separately from basic TCP reachability. An ACL allowing the right port cannot establish that a database role is appropriately scoped.<\/p>\n A listening socket is ready to receive connection attempts at a local transport endpoint. On TCP, a successful three-way handshake establishes transport connectivity, but it does not complete an HTTP login or demonstrate application health. A connection refused response often indicates that nothing is listening or a rejecting device responded. A timeout may mean packet loss, filtering, routing problems, an overloaded service or no response from the destination. These observations should not be collapsed into the statement that a port is down.<\/p>\n Compare evidence from three places: the service host's socket and process inventory, a packet capture near the client or server, and the firewall or load-balancer logs. If the server shows a listener but no SYN arrives, investigate routing and policy first. If a SYN arrives and the server responds with RST, examine the binding, address family, service process and local firewall. If TCP connects but the client reports failure, move up to TLS, application routing and authentication.<\/p>\n A port scan is one observation channel. Network address translation, rate limiting, firewalls and service proxies can make a single scan look different from the service's actual health. Scan only systems for which testing is authorized; the intent is to confirm expected exposure and close unexpected paths, not infer compromise from an open number alone.<\/p>\n192.0.2.10:53124<\/code> to 198.51.100.20:443<\/code>. The client port 53124 usually exists for this session, while the server's destination port identifies a configured listener. A reverse-path firewall rule must recognize the established flow or otherwise allow the response. If a port translation occurs, the observed tuple on the WAN need not match the internal tuple.<\/p>\nSystem, user and dynamic ranges describe allocation\u2014not universal privilege rules<\/h2>\n
Listening, connecting and timeouts are different states<\/h2>\n
NAT and port forwarding change addresses and exposure<\/h2>\n