A server can answer ping and still be unusable. An application may bind only to a loopback address, a firewall may deny the destination port, a certificate may be untrusted, or the client may be contacting a completely different endpoint because DNS is stale. None of those problems is diagnosed by memorizing “HTTPS is 443” alone. For CompTIA Network+ N10-009, common protocol numbers matter because they connect symptoms to network conversations: a source process selects a transport and a destination service, intermediate controls decide whether to forward the traffic, and the server application must actually be listening. Successful troubleshooting distinguishes each condition rather than attributing every timeout to “the network.”
Start with transport behavior
TCP is connection-oriented. Its three-way handshake helps establish that a client can send traffic toward a server and receive the expected response before application data flows. The transport tracks sequence numbers and acknowledgments, retransmits missing data, and manages sender/receiver flow. A failed TCP SYN may indicate a silent firewall drop, broken route, unavailable host, or return-path problem. A TCP reset may instead indicate an actively refused connection or a rejecting middlebox. Neither result proves the web application itself is healthy. If the handshake succeeds and the application then returns an HTTP 503, routing is likely less interesting than backend service health.
UDP does not establish an equivalent connection before sending a datagram. DNS queries, common real-time media traffic, network monitoring, and some VPN traffic can use UDP, though the exact transport differs with protocol and configuration. A UDP request without an answer is ambiguous: the service may be down, an intermediate filter may block traffic, or an application may not send a response to that payload. A UDP service cannot be judged by applying a TCP connect test to the same number. Protocol numbers and port numbers are also different fields: ICMP does not use TCP or UDP ports, and protocols such as GRE have their own IP protocol identifiers.
A TCP or UDP endpoint is usually identified by an address and port pair. A client typically opens an ephemeral source port when contacting a well-known destination port, allowing many independent sessions to coexist. A stateful firewall often sees the original outbound connection and permits the reverse traffic as part of that established flow. With port address translation, many internal clients can share a public IP because their sessions are differentiated by translated source ports. A packet capture should be read as a sequence of source/destination addresses, ports, transport flags and timing—not merely as a yes-or-no port label.
Know the service behind the number
DNS normally accepts queries over port 53, using UDP for common transactions and TCP when the exchange requires it, such as some larger responses and zone transfers. DHCP for IPv4 uses UDP server/client ports 67 and 68; IPv6 DHCP uses 547 and 546. HTTP is commonly 80 and HTTPS 443, but a web service may legitimately listen on another port when configured. SSH uses 22 for encrypted remote command access and SFTP, while Telnet at 23 offers no suitable protection for sensitive production administration. FTP control commonly uses 21 and transfers can involve other connection behavior, so a simple single-port allow rule may not explain every historical FTP failure.
Mail and collaboration services involve several ports with different roles. SMTP commonly appears on 25 for server transport and 587 for message submission; IMAP and POP3 have historically used 143 and 110, with encrypted service variants often on 993 and 995. SMB file sharing uses 445, LDAP directory queries commonly use 389, LDAPS uses 636, and remote desktop connections commonly use 3389. NTP synchronizes time over UDP 123. SNMP polling and notifications commonly use UDP 161 and 162, while syslog commonly uses UDP 514 or other secured transports by configuration. TACACS+ often uses TCP 49 and RADIUS often uses UDP 1812/1813. Learn the purpose and security context of each rather than indiscriminately opening everything on a firewall.
A common exam trap is treating a number as a sufficient security statement. SSH and Telnet can both provide remote terminal workflows, but they do not offer equivalent confidentiality. HTTPS normally protects HTTP with TLS; it does not automatically establish that the remote application is authorized to receive sensitive records, that the certificate matches the requested name, or that the backend is free of vulnerabilities. An encrypted directory connection reduces exposure of credentials in transit, but access controls still matter. Correct security design usually narrows which source systems may contact which service, over which transport and port, under which identity and inspection policy.
Separate DNS, reachability, and service acceptance
When an application URL fails, first resolve the name using the client’s configured resolver. Compare the returned addresses with the expected service deployment and note whether an IPv6 AAAA record or an IPv4 A record was preferred. A stale cached response can send a request to a retired address even though the actual service is healthy. DNS caching and TTL matter because clients, recursive resolvers, and applications do not necessarily refresh records at the same moment. Before blaming a TCP port, establish that the client is testing the intended endpoint.
Next determine what the underlying network can actually reach. A host may answer ICMP echo while its application listener is absent or filtered. Conversely, ICMP may be disabled by policy even while HTTPS works normally. A route trace can help identify path changes or probable reachability limits, but some routers deprioritize or suppress probe responses. Tests such as a TCP connection attempt to the exact destination address and port can distinguish a listener from a refusal or timeout, while the server’s local service status and socket listing can reveal whether it binds to the right interface. Observe both client and server logs when permitted; a load balancer may accept client connections while the backend pool is unhealthy.
An example illustrates the layers. A user reports that a secure intranet page stopped working after a DNS change. The DNS query now returns the right VIP, and TCP to 443 completes, but the browser fails with a certificate name error. Opening 443 again will not help. The correct investigation checks the certificate’s subject alternative names, SNI/server selection, deployment of the expected certificate chain, and whether a proxy is terminating TLS on the intended hostname. If the TLS handshake succeeds but authentication loops, investigate application and identity services. The network is a transport for several application-layer dependencies; success at one layer cannot prove success at the next.
DHCP, DNS, and authentication have distinct failure signatures
A newly connected client showing a self-assigned IPv4 address may lack a DHCP lease or the VLAN’s relay path to a server. It can often talk only to some local neighbors. A client with a proper address and gateway but wrong DNS server can reach IP destinations yet fail by name. A client with the right IP and DNS but incorrect time can fail certificate or token validation because authentication systems rely on clock agreement. These are different incidents and should produce different test evidence. DHCP, DNS, and IP address management explain the lease, relay, lookup and record behaviors that underlie them.
For a management login failure, distinguish network reachability from identity and authorization. An SSH daemon can be reachable on 22 but reject a user because of credentials, keys, allowed-source policy, account state or centralized AAA service. An RADIUS-backed network access control failure may prevent an endpoint from joining the intended VLAN before the user ever opens a browser. A VPN’s IPsec and IKE exchanges may work partially while the subsequent route or policy prevents private application access. Secure VPN connectivity provides the tunnel context, but the final diagnosis still requires observation of the application service and authorization decision.
Use diagnostic tools deliberately
Run a resolver query to document the actual A or AAAA response and its TTL. If you can use a test host with permission, attempt a TCP connection to the precise server and port; record whether it times out, is rejected, or establishes before the application fails. Check interface counters and routes, then correlate firewall logs with the same addresses, ports and timestamps. A packet capture can show SYN, SYN-ACK, RST, retransmissions and DNS answers; filter as narrowly as necessary and avoid collecting unrelated private traffic. Network monitoring logs and flow data are especially useful when sporadic events do not coincide with an engineer watching a terminal.
Do not use port scanning against systems you do not control. Even in a lab, first decide what question the test is supposed to answer. A single service test is often more informative than a broad sweep that produces ambiguous failures or security alerts. Record the working hypothesis, its supporting observation, the next discriminating test, and the exact result. A successful resolution means the intended user workflow works again, not merely that one test returns a green message.
Build a tiny service-failure lab
One safe practice exercise uses a local DNS service, a web server, and two test clients. First confirm that the name resolves to the correct lab address, that the web listener accepts a connection, and that an application request receives the expected content. Next change only one condition: point a client at the wrong resolver, stop the web listener, change the service bind address, or add a narrowly scoped test firewall deny. Record the error difference in each case and what the packet capture reveals. Restore the baseline between scenarios. This exercise makes common protocol ports memorable because each number corresponds to a specific conversation and an observable failure mode.
For a second exercise, compare a known-good HTTPS connection with one that produces a certificate error. The route and destination port can be identical while trust validation differs. Time synchronization adds another subtle dependency: even a correct certificate can appear invalid to a host whose clock is wrong. Treat the Network+ port and protocol objectives as a diagnostic vocabulary for real services. The fastest solver is usually the person who knows what a successful exchange should look like and can prove exactly where that exchange stopped.