How to use command line tools to diagnose network issues

When a web page will not load, the visible symptom can be misleading. A browser may show a timeout, a DNS error, a refused connection, or a blank response, yet each message points to a different part of the path between your device and the website. Command line tools can separate local connection faults from router problems, domain resolution failures, filtering, and server-side outages.

This approach is useful for households, schools, and small offices across Australia, where a connection may pass through an NBN service, a home router, carrier-grade NAT, and several regional networks before reaching a server. You do not need advanced equipment. A few carefully chosen commands, recorded with their times and results, can create a clear picture of what is happening.

Start with the simplest reachability checks

Open Terminal on macOS or Linux, or Command Prompt or PowerShell on Windows. Begin with ping, which sends small test packets to a destination and measures whether replies return. For example:

ping 1.1.1.1

A stable series of replies suggests that basic IP connectivity is working, although it does not prove that a particular website is available. Some servers ignore ping requests, so a lack of replies is not automatically evidence of an outage. Look for packet loss and unusually high or changing latency rather than focusing on one isolated result.

Next, test the website by name:

ping example.com

If the numeric address works but the domain name does not, the likely issue is DNS rather than the broadband link. If both fail, compare the result on another device. A fault affecting a single laptop may involve its Wi-Fi adapter, security software, or local configuration, while a failure on every device points more strongly towards the router, provider, or destination.

Use traceroute to locate delays

The traceroute command on macOS and Linux, and tracert on Windows, displays the network hops between your device and a destination. Use it with a domain name:

traceroute example.com

On Windows, run:

tracert example.com

The first hop is usually your home router. Later hops may belong to your internet provider, an exchange, a transit carrier, or the hosting network. Asterisks can appear when a router is configured not to answer diagnostic requests; they do not necessarily mean traffic has stopped. Pay attention to where the path becomes consistently slow or begins timing out.

Results can vary between Sydney, Brisbane, Perth, and regional locations because traffic may take different routes. A slow hop in the middle of the display is not conclusive if later hops return quickly. A sustained failure from a particular point onwards is more useful evidence, especially when the same pattern appears at different times or from another connection.

Test whether DNS is providing the right answer

DNS converts a readable domain name into an IP address. The main command line tools are nslookup, available on Windows, macOS, and Linux, and dig, commonly installed on macOS and Linux. Try:

nslookup example.com

or:

dig example.com

Record the returned address and the DNS server shown in the response. Then compare it with a public resolver:

nslookup example.com 1.1.1.1

Different answers can result from caching, geographic routing, a recent hosting change, or a faulty resolver. Australian internet providers may use local DNS infrastructure, so a record can update at slightly different times across networks. A domain that has recently changed hosts may therefore work on mobile data but fail over home broadband until caches expire.

You can also check whether the domain has mail or authoritative name server records, although these tests do not confirm that a web service is healthy. Avoid assuming that changing DNS will solve every problem. If a domain is blocked by a network policy, altered by a filtering service, or incorrectly configured at its registrar, a different resolver may produce useful evidence but will not repair the underlying issue.

Inspect your device and gateway

Local configuration is often overlooked. On Windows, use:

ipconfig /all

On macOS or Linux, common options include:

ifconfig

or:

ip addr

Look for an IP address, subnet information, default gateway, and DNS servers. A private address such as 192.168.x.x or 10.x.x.x is normal on a home network. An address beginning with 169.254 usually indicates that the device did not receive a usable address from the router.

Test the gateway shown by your configuration:

ping 192.168.1.1

Replace that address with the actual default gateway. If the gateway cannot be reached, check Wi-Fi association, Ethernet cables, router status lights, and whether another device is connected. In an Australian household, restarting an NBN modem or router may restore a temporary session problem, but frequent repetition suggests a configuration, hardware, or provider fault rather than a lasting fix.

Check the service and the web port

A domain can resolve correctly while its web server remains unreachable. Use curl to inspect the response headers:

curl -I https://example.com

A status such as 200, 301, or 302 means that an HTTP service responded. Codes in the 400 range usually relate to the request or access policy, while 500-range codes generally indicate a server-side problem. A timeout means that no usable response arrived within the command's waiting period, but it does not identify the exact cause by itself.

To test whether a secure web port is reachable, use Netcat where available:

nc -vz example.com 443

Windows PowerShell provides a similar check:

Test-NetConnection example.com -Port 443

Port 443 is used for HTTPS and port 80 for unencrypted HTTP. A successful TCP connection followed by an application error points to a higher-level issue, such as a broken certificate, virtual host, or website application. Avoid scanning ports you do not own or administer. Testing a website's normal public port is very different from probing a broad range of systems.

Recognise filtering, caching, and hosting faults

If the command results look healthy but a browser still displays an error, compare browsers, devices, and networks. A corporate, school, or public Wi-Fi network may filter categories or domains. Libraries, cafés, and transport hubs often require a sign-in page before allowing normal traffic. Mobile data can provide a useful comparison, though carrier filtering and coverage limitations can also affect the result.

Caching creates another layer of confusion. Your browser, router, DNS resolver, content delivery network, or the website itself may retain an older response. Flush local DNS only after recording the current results. On Windows, the usual command is:

ipconfig /flushdns

A website can also be unavailable because its domain has expired, its hosting account is suspended, its certificate is invalid, or its origin server is overloaded. The holding page explains common causes of an unavailable page without presenting itself as a live support service. That distinction matters: command line evidence can identify the likely failure area, but it cannot restore a domain or hosting account controlled by someone else.

Keep a small diagnostic record

Write down the exact time, device, connection type, destination, command, and result. Include whether the test was performed over home NBN, a phone hotspot, or public Wi-Fi. A change from a Telstra, Optus, or Vodafone mobile connection to a fixed-line service can reveal whether the fault follows the network or the device.

Avoid publishing full IP addresses, router identifiers, usernames, or copied logs in public forums. Australia’s Privacy Act 1988 and general workplace security practices make careful handling of personal and operational information important, even when a diagnostic command seems harmless. Remove private details before sharing evidence with an administrator or provider.

If a reset is appropriate, make sure you know the Wi-Fi name, password, and any provider-specific settings first. The network settings guide covers a basic reset approach, but resetting should follow diagnosis rather than replace it.

Practical checks worth keeping

Use these habits to make command line troubleshooting faster and safer:

• Test a numeric IP address, the affected domain, and the local gateway separately.
• Compare nslookup or dig results with a second DNS resolver.
• Run tracert or traceroute from more than one network before judging the route.
• Use curl -I or Test-NetConnection to distinguish web-service errors from basic connectivity failures.
• Save dated results while the problem is occurring, then remove private information before sharing them.

A clear record helps an ISP, network administrator, or hosting provider avoid repeating basic questions. It also prevents unnecessary changes, such as replacing healthy equipment or repeatedly resetting a connection that is actually affected by a remote outage.

Run the checks in order, beginning with the gateway and a known numeric address before moving to DNS, routing, and HTTPS. Keep the results together and compare them across devices and networks. That small evidence trail turns an unexplained loading error into a practical diagnosis and gives the right technical person useful information to act on.