NetEngToolkit

How to Troubleshoot Network Connectivity Step by Step

Troubleshooting · Last updated 12 October 2026 · 6 min read

A layered method for finding where a connection breaks: local configuration, gateway, routing, DNS, the path, the port, and the application, with commands for Windows, Linux, and macOS.

The problem and the approach

"The network is down" or "it's slow" describes a symptom, not a cause. A connection can fail at many points: the cable or Wi-Fi, the device's address settings, the local gateway, routing beyond it, DNS, a firewall on the path, the destination port, or the application itself. The efficient method is to test in layers and stop at the first one that fails, then fix that before looking further.

First gather the basics: what exactly fails, since when, for whom (one device, one site, everyone), and what changed. Only test networks and systems you are authorized to troubleshoot.

Step 1: Check the local interface and IP configuration

# Windows
ipconfig /all

# Linux
ip addr show
ip route show

# macOS
ifconfig
netstat -rn

Confirm the device has an address, a subnet mask, a default gateway, and DNS servers. Warning signs:

  • An address starting 169.254. This is a link-local address that the device assigned itself because it could not get one from DHCP (RFC 3927). The problem is between the device and the DHCP server: a cable, Wi-Fi association, VLAN, or the DHCP service.
  • No default gateway, or a gateway outside the device's subnet. Check with the Subnet Calculator: the gateway's address must be inside the same subnet as the device, calculated with the device's own mask.
  • An unexpected address or mask, such as the wrong subnet for the VLAN or a leftover static setting.

Step 2: Reach the gateway

ping 192.168.1.1

Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
(illustrative)

If the gateway answers, the local link works. If it does not, check the cable, Wi-Fi signal and association, VLAN membership, and the switch port. Note that some devices are configured not to answer ICMP echo, so a missing ping reply alone is not proof of failure; the ARP table (arp -a) showing a gateway MAC address is further evidence the link works.

Step 3: Reach beyond the gateway by IP address

Ping a well-known public address by number, which tests routing and internet access without involving DNS:

ping 1.1.1.1
ping 8.8.8.8

If this works, your connection to the internet is fine, and any remaining problem is DNS or something higher. If it fails while the gateway works, the problem is the gateway's upstream: the ISP, a routing or NAT configuration, or a firewall.

Step 4: Test DNS

Now test with a name:

ping example.com
nslookup example.com
nslookup example.com 1.1.1.1

If pinging by IP works but by name fails, DNS is the problem. The last command asks a public resolver directly: if that works, the fault is in your configured resolver. The DNS troubleshooting guide covers the full procedure, and the DNS Lookup shows what public resolvers return.

Step 5: Trace the path

# Windows
tracert example.com

# Linux / macOS
traceroute example.com

# Continuous, with per-hop statistics (Linux/macOS, mtr installed)
mtr -rwc 50 example.com

Each line is a router on the path with its response time. How to read it:

  • Rows of * * * usually mean that hop does not answer the probes (often filtered), not that traffic stops there. If later hops respond, the path works.
  • Loss at one intermediate hop but not at later hops is generally routers rate-limiting their own ICMP replies, not real packet loss. Real loss shows up at that hop and every hop after it.
  • A big jump in latency that persists in all later hops marks where delay is added, such as a long-distance or congested link.
  • The trace stops and never reaches the destination suggests a filter or failure at or beyond the last responding hop.

Step 6: Test the specific port

A host can be reachable by ping and still refuse the service you need, or a firewall may permit ICMP but block your port. Test the actual port (look up the usual port in the Port Lookup):

# Windows PowerShell
Test-NetConnection example.com -Port 443

# Linux / macOS
nc -vz example.com 443

Connection to example.com 443 port [tcp/https] succeeded!
(illustrative)
  • "Connection refused" means the host answered and nothing is listening on that port (or a firewall actively rejects).
  • A timeout means packets are being silently dropped, typically by a firewall, or the host is unreachable.

Step 7: Check the application

If the port is open but the service fails, test the application layer. For web services use the HTTP Status Checker to see the response, redirects and errors, then read the status code guide; check the TLS certificate with the SSL/TLS Checker. For other services, consult that application's own logs.

A special case: it connects but large transfers hang

If small requests work (a ping, a page's HTML) but large transfers or some HTTPS sites stall, suspect an MTU problem: packets larger than some link on the path can carry are dropped, and the ICMP messages that should inform the sender are blocked (Path MTU Discovery, RFC 1191). Test by sending packets that must not be fragmented:

# Windows (1472 data + 28 header bytes = 1500)
ping -f -l 1472 example.com

# Linux
ping -M do -s 1472 example.com

# macOS
ping -D -s 1472 example.com

If 1472 fails but a smaller size succeeds, lower the size until it works; the largest working value plus 28 is the path MTU. Tunnels and VPNs commonly reduce it, and the usual fixes are adjusting the interface MTU or clamping TCP's maximum segment size on the tunnel endpoint.

When it works but is slow

Slowness has distinct causes; tell them apart:

  • High latency (long round-trip times) affects interactive use and any protocol that waits for acknowledgements. Compare latency to the destination over time.
  • Packet loss forces retransmissions and cripples throughput even when latency is low. It shows as loss at the destination in ping and mtr.
  • Limited bandwidth shows as a steady ceiling on transfer speed. Use the Bandwidth Calculator to compare the speed you measure with what the link should deliver.
  • Wi-Fi problems (interference, distance, congestion) look like intermittent loss and latency spikes; test with a wired connection to isolate.
  • The remote server may be the slow part. The Ping / Latency tool measures HTTP response time from a location outside your network; note it is an HTTP test, not ICMP.

Quick reference

Test                         If it fails, the problem is probably...
IP configuration              DHCP, VLAN, cable/Wi-Fi, static settings
Ping gateway                 Local link, switch port, VLAN
Ping 1.1.1.1 (by IP)         Gateway upstream: ISP, routing, NAT, firewall
Ping by name / nslookup      DNS resolver or records
Traceroute stops             Filter or fault at/after the last hop
Port test refused / timeout  Service not listening / firewall dropping
Large transfers hang         MTU / blocked ICMP on the path
Application errors           The service itself: status codes, TLS, logs

Security and operational considerations

  • Run tests only against systems and networks you own or have permission to test. Repeated probing of third-party hosts can look like an attack.
  • Do not disable firewalls to test; add a temporary, narrow rule and remove it afterwards.
  • Keep notes: what you tested, what you saw, and what you changed. A change made while troubleshooting is easy to forget and hard to find later.

Tools used in this guide

  • IPv4 Subnet Calculator — Calculate network, broadcast, usable range, mask, and wildcard from an IP + CIDR or subnet mask.
  • DNS Lookup — Query A, AAAA, CNAME, MX, NS, TXT, SOA, CAA, and SRV records for a domain.
  • Port Lookup — Look up well-known TCP/UDP ports by number or by service name.
  • HTTP Status Checker — Check the live HTTP status code, response time, and redirect chain for any URL.
  • Ping / Latency — Run an HTTP-based latency test against a host and see min/avg/max response times.
  • Bandwidth Calculator — Estimate file transfer time from size and bandwidth, or work backward to required bandwidth.

References and further reading

References are primary sources (standards and official documentation). Commands and sample output are illustrative; behavior can vary by operating system and software version.

Keep reading