6 Diagnosing Network Problems

Start with the scope of the problem

Start with the simplest and nearest possible causes, then investigate farther along the network path. Define the symptom precisely: no connection, intermittent access, slow performance, or inability to reach one service. Determine whether it affects one device, several devices, or the entire network, note when it began and any recent changes, and test one link or network layer at a time.

Verify the physical and wireless links

For a wired device, verify that its network adapter is enabled, its cable is firmly connected, and link indicators are active at both the computer and switch. Try a known-good cable and a different switch port. A lit link indicator confirms that a physical link exists, but does not prove that the cable or connection is error-free. Check for a disabled or faulty switch port, a damaged cable, a loose connector, or incorrect port configuration.

For Wi-Fi, verify that Wi-Fi is enabled, the device has joined the intended network, and authentication succeeded. Move closer to the access point (AP) to test for a weak signal. Walls, distance, interference, congestion, or roaming between APs can cause weak or intermittent service. If Wi-Fi reports a connection but access still fails, continue checking IP settings, DNS, and the network path; the wireless link may be working while another part of the connection is not.

Check addressing and local connectivity

A device needs a valid IP address and subnet mask or prefix. It also needs a default gateway to communicate beyond its local network. On Windows, inspect the active adapter’s settings with:

Check that the settings are expected and that the address belongs to the correct network. On a Windows IPv4 adapter, an address beginning with 169.254 commonly means the device did not obtain a DHCP address. Investigate the adapter, the link, the DHCP server, or the path to that server. Do not assign a random static address: it could conflict with another device or fall outside the correct subnet.

If the device is configured to use DHCP, renewing its lease may help after a connection or DHCP issue has been corrected:

Test local connectivity in order: the device’s own network stack, another device on the same LAN, and the default gateway. Windows examples for testing the local stack and gateway are:

A failed gateway test can point to a local link, address, VLAN, or gateway problem. A successful ping does not prove that every service—or the internet—is reachable. Some devices and firewalls block ping, so verify important services with an appropriate application or port test as well.

Separate DNS from connectivity failures

DNS translates host names, such as example.com, into IP addresses. If an application fails when given a name, test the same destination by IP when practical and permitted, then query DNS directly:

If an IP-based test works but a name lookup fails, inspect the configured DNS server, whether it is reachable, and the queried record. A DNS timeout may indicate an unreachable or incorrect server, a server-side issue, or filtering of DNS traffic; the timeout alone does not identify which cause applies. On Windows, nslookup queries the configured DNS server rather than relying on the client’s DNS cache. If the problem appears to involve a stale local cache, clear that cache with:

Trace the route and test the service

If local-network access works but a remote destination does not, check the route beyond the default gateway. On Windows, tracert -d <destination> shows responding route hops without performing DNS lookups for each hop:

A missing response at one hop is not conclusive. Routers may suppress or deprioritize these probes while still forwarding ordinary traffic. Compare multiple destinations and, if possible, test the specific application service and port. Firewalls, VPNs, proxy settings, and the destination service itself can block an application even when general connectivity is available.

Investigate slow and intermittent performance

Compare performance on more than one device and, where possible, over both wired and wireless connections. If only one device is affected, inspect its adapter, driver, signal, background traffic, VPN, and security software. If several devices are affected, check shared equipment and the upstream service.

Slow or inconsistent performance can result from weak Wi-Fi signal, radio interference or channel congestion, high network demand, packet loss, overloaded or misconfigured equipment, or a slow destination service. Repeat tests at different times and locations. If delay or packet loss is suspected, compare tests to the local gateway and an external destination. Loss already present on the local segment points closer to the device or LAN, while loss appearing farther along narrows the search to the onward path. A single ping test is a clue, not a complete performance diagnosis.

Isolate faults in shared network equipment

Check shared network devices according to their role:

• Modem or internet gateway: Confirm power and service or link indicators, and check whether the outage affects all connected devices. A restart may restore service, but record the state first if the issue recurs.

• Router: Check power, WAN connection, configuration, and whether devices receive correct addresses and gateway information. A router may provide local connectivity while its internet-facing connection is down.

• Switch: Check power, port status, cable, port configuration, and whether the affected device is on the intended VLAN. A port may be disabled or misconfigured even when the device appears connected.

• Wireless AP: Check power and its wired uplink, coverage, client association and authentication, interference, and whether other clients can connect. A working radio link does not guarantee a working uplink.

Use a known-good cable, port, or device to isolate a suspected fault. Change one thing at a time and retest so it is easier to identify the cause rather than mask it. Overall, work outward from the device: verify the physical or Wi-Fi link, inspect IP configuration and DHCP, test local and gateway connectivity, check DNS, and then examine the route and specific application. Compare affected and unaffected devices, use multiple tests, and treat indicators such as ping failures or link lights as evidence rather than proof.