When a network connection fails, start by narrowing the problem rather than changing several settings at once. A useful investigation separates the device's local link, its address and route, name resolution, and the application being used. One successful ping or one error message rarely proves that every other layer is healthy.
Start with scope and the last change
Write down the affected device, connection type, exact error and time. Check whether one website fails, all internet access fails, or even a local service is unreachable. Compare another device on the same network and, where practical, the same device on a known-working connection. Note recent router, driver, VPN or firewall changes.
Keep existing settings and a way to reach the router before changing them. On a remote server, a lease release, interface change or reboot can cut off your own administration connection. Avoid a factory reset as an early troubleshooting step; it removes configuration without establishing the cause.
Check the link and local configuration
For Ethernet, inspect the cable, port and reported negotiated rate. Try a known-good patch lead or another suitable port while changing one item at a time. A connection near 100Mbps may reflect a Fast Ethernet port, adapter, damaged cable or another bottleneck. A 94Mbps speed-test result alone does not identify particular broken wire pairs.
For Wi-Fi, confirm the intended SSID, band and connected node. Compare the same task near the router and in the problem room. Signal strength, interference and a mesh satellite's upstream link are separate factors. No single RSSI threshold guarantees good performance for every device or application.
Inspect the active network adapter's address, subnet, default gateway and DNS servers. Ignore unrelated disconnected, VPN or virtual adapters when interpreting a different connection. On Windows, use ipconfig /all. Do not assume that every router's gateway is 192.168.1.1; use the address shown for the actual connection.
An IPv4 address in 169.254.0.0/16 is link-local. On a Windows adapter expected to obtain a normal DHCP lease, it can indicate that no usable DHCP configuration was obtained. Check the correct network, link, DHCP service and address pool. That address is not suitable for routed IPv4 internet access, but the machine may still have another working interface or IPv6 path.
Read-only diagnostic starting points
| Task | Windows | Linux or macOS equivalent |
|---|---|---|
| Inspect addresses and DNS | ipconfig /all | Linux: ip addr show and the active resolver's settings. macOS: the selected Network service's TCP/IP and DNS panels |
| Inspect IPv4 routes | route print -4 | Linux: ip route show. macOS: inspect the router field in TCP/IP settings |
| Query a hostname | nslookup example.com | dig example.com where installed, or the system's resolver diagnostics |
| Inspect local neighbours | arp -a | Linux: ip neigh show; macOS: arp -a |
| Trace an IPv4 route | tracert -d 1.1.1.1 | traceroute -n 1.1.1.1 where available; required packages and probe types differ |
The names and utilities available on Linux depend on the installed image and network manager. For example, resolvectl applies to systemd-resolved; it is not the DNS-management interface on every machine. These commands inspect different pieces of state and should be read together, rather than treated as one universal pass/fail test.
Test addresses, DNS and the actual service
Try a ping to the actual gateway, then an appropriate external address if the network permits it. A response proves that those ICMP packets made a round trip. A missing response can also mean ICMP is filtered or deprioritised; it does not automatically prove the destination or internet connection is down.
An ARP entry can be cached and only concerns a local neighbour. It does not prove the cable, Wi-Fi or every layer-2 path is completely healthy. Likewise, an asterisk in a trace can mean an intermediate router does not answer those probes while later traffic continues. Focus on the destination and the failing application.
If a hostname fails, query it directly and inspect the result. When permitted, compare the configured resolver with a specific public resolver, for example nslookup example.com 8.8.8.8. A different result is evidence to investigate; changing DNS permanently is not the first requirement. Managed networks may require their own resolver, and browsers or VPNs can use a different DNS path from that command.
On Windows PowerShell, test the intended TCP service directly. Replace the example with the hostname and port you actually need:
Test-NetConnection -ComputerName example.com -Port 443 -InformationLevel DetailedTcpTestSucceeded concerns that TCP connection. Success does not validate an HTTPS certificate, application login or every request. Failure may involve routing, a stopped listener, firewall rules or the wrong address/port. Check the service's own logs and whether it is listening on the interface clients use.
Renewal, restarts and configuration changes
Renew DHCP only on an interface configured to use it. Windows supports ipconfig /renew with an adapter name. Releasing a lease first discards configuration and can disconnect the machine, so use a specific adapter and preserve another access route if working remotely. Static addresses need their own valid configuration; renewing DHCP is not a repair for an incorrect manually assigned address.
On macOS, select the active network service, open its Details > TCP/IP settings and use Renew DHCP Lease when that service uses DHCP. On Linux, use the documented method for the active manager; do not start an unrelated dhclient process over NetworkManager or systemd-networkd and assume they cooperate.
A planned power cycle can help after recording the symptom. Follow the equipment's instructions, allow the modem or internet handoff to become ready, then the router and client. A fixed 30-second delay is not a guarantee for every device. Avoid interrupting upgrades or other important operations.
Treat symptoms as clues
| Symptom | Next useful checks |
|---|---|
| Wi-Fi connected, no internet | Active address/gateway, captive login, DNS, guest/VLAN policy and upstream status |
| Address conflict | DHCP leases/reservations, static assignments and duplicated devices; an ARP cache alone does not identify every cause |
| Low transfer rate | Negotiated ports, cable/adapter, Wi-Fi/backhaul, source storage and internet-plan limits |
| Some HTTPS sites fail | Exact TLS error, system time, certificate, proxy/security software and service status; investigate MTU only when evidence points there |
| One local service fails | Correct hostname/port, listener, credentials, routes and specific firewall policy |
Do not globally lower MTU to 1492 or 1420 because a browser displays an SSL error. The correct path MTU depends on the actual links and tunnels. Similarly, inspect a relevant firewall rule instead of disabling the whole firewall to make a test pass.
When escalating to the ISP or service administrator, provide the time, affected path, comparable working test and exact failure. Remove credentials from shared logs. That evidence gives the next person a useful starting point and helps verify whether a proposed fix changed the problem.
