Most Linux network tickets look messy at first, yet the fix often starts with the same checks. For CompTIA A+ 220-1202, Domain 1 (Operating Systems), Objective 1.9, you're expected to use common Linux tools to test and confirm network behavior. This post focuses on core commands (ip, ping, curl, dig, traceroute) and the practical skill of locating where a problem lives: your PC, the local network, DNS, or the remote site.
Three terms make the process easier. An interface is a network connection on your system, such as Ethernet or Wi-Fi. A gateway is the router address your device uses to reach other networks, including the internet. DNS (Domain Name System) translates names like example.com into IP addresses. Once you can verify each layer, you stop guessing and start proving.
Start by checking your IP settings with the ip command
When a user says "the network is down," begin with ip. It gives fast evidence about link state, addressing, and routing. In practice, it answers four early questions: Does the interface have a link, does it have a valid IP, does it know the default gateway, and are there clues that DNS is mis-set?
Linux interface names vary by system. You might see eth0 on older systems, enp0s3 on many virtual machines, and wlan0 on some Wi-Fi setups. On modern desktops, NetworkManager often manages these links, while servers may use other tools. Either way, ip shows the truth as the kernel sees it.
Also, remember permissions. Reading most ip output works as a normal user. Changing settings, bringing interfaces up or down, or adding routes typically requires sudo. On an exam question or a real ticket, that detail matters because it changes what you can test quickly.
A good mental model is to treat ip output like a map legend. First, confirm the cable or radio link. Next, confirm the address and subnet. Then, confirm the route off the subnet. Only after those checks should you spend time on DNS and application issues. Many "internet down" incidents end up being a simple missing default route, a disconnected Wi-Fi SSID, or an expired DHCP lease.
If you can't show link, address, and default route, don't waste time blaming DNS or the website.
Confirm you are on the network: interface state and IP address
Start with ip link to check whether the interface is up. Look for flags like UP or DOWN. If the interface shows DOWN, the system won't send traffic on it. If it shows NO-CARRIER, the interface is enabled, but it can't detect a physical link. That often points to an unplugged cable, a dead switch port, or a disabled Wi-Fi radio.
Next, use ip addr to confirm the interface has an IP address. A "good" sign is an inet line with an address and prefix length, such as 192.168.1.25/24 or 10.0.5.14/16. In contrast, if you only see a 127.0.0.1 loopback address, the host isn't configured for the network. If you see a 169.254.x.x address on IPv4, that suggests the system failed to get DHCP and fell back to a link-local address.
Private IPv4 ranges help as a quick sanity check:
10.0.0.0/8172.16.0.0/12192.168.0.0/16
An address in these ranges is common on home and many enterprise LANs. A public address can be valid too, yet it should match the site design.
If Wi-Fi is disconnected, ip link may still show the interface as up, while it has no useful IP. In that case, confirm you're on the correct SSID using your desktop network settings, or re-connect through NetworkManager tools. High-level fixes include reseating the Ethernet cable, verifying the SSID and password, and restarting the network service (for example, restarting NetworkManager with sudo systemctl restart NetworkManager on systems that use it).
Check your route to the internet: default gateway and routing table
After address checks, run ip route. The key line is the default route, which often looks like default via 192.168.1.1 dev enp0s3. That gateway IP is the next hop out of your local subnet. Without it, you may reach local devices but fail to reach anything off-network.
A common failure is simply no default route at all. In that case, the system doesn't know where to send internet-bound traffic. DHCP usually provides the default gateway, so a missing default route often ties back to DHCP trouble, a bad static config, or a broken network profile.
Wrong subnet settings can also mislead you. If the prefix length is wrong, you might reach some local hosts but not others. For example, if your LAN is /24 but the host uses /25, half the addresses will look "remote" and traffic may go to the gateway or fail. The symptom feels random, yet it's consistent with the math.
Wrong gateway IP is another classic. If the gateway points to an unused address, traffic leaves your host but goes nowhere. You can often identify the correct gateway by checking another working machine on the same LAN, reviewing DHCP settings on the router, or looking at network documentation. The gateway matters because it is the bridge between your local network and the rest of the world. If that bridge is missing, no app fix will help.
Use ping to separate local problems from internet problems
Once ip suggests the interface, address, and route are reasonable, use ping to test reachability. Ping sends ICMP echo requests and listens for replies. It gives a clear yes or no signal, plus basic timing. Still, ping has limits. Some systems block ICMP, so a failed ping doesn't always mean the host is down. Also, a successful ping doesn't prove that web browsing or DNS will work.
Even with those limits, ping remains a strong sorting tool. It can show whether your problem is inside your machine, on the local LAN, at the gateway, or beyond your network. The main idea is to test from near to far. If the near tests fail, stop and fix local issues. If near tests pass but far tests fail, you've narrowed the fault domain.
Ping also helps you describe the issue in a way others can act on. "I can ping the gateway but not a public IP" sounds like a routing or ISP problem. "I can ping a public IP but not a hostname" points toward DNS.