When a user says “the network is down,” the real problem is usually smaller and more specific: a bad IP address, a missing default gateway, broken DNS, or a routing failure somewhere past the local router. The fastest way to prove that is with network troubleshooting commands. Used in the right order, they turn vague complaints into hard evidence and help you narrow the fault layer by layer.
CompTIA A+ Certification 220-1201 & 220-1202 Training
Master essential IT skills and prepare for entry-level roles with our comprehensive training designed for aspiring IT support specialists and technology professionals.
Get this course on Udemy at the lowest price →Quick Answer
Network troubleshooting commands are command-line tools used to isolate connectivity problems by testing local TCP/IP function, addressing, gateway reachability, DNS, and routing. For CompTIA A+ candidates, the most useful tools are ping, ipconfig, tracert, pathping, nslookup, arp, and netstat. The key is using them in sequence, starting with the local machine and moving outward.
Definition
Network troubleshooting commands are command-line utilities that help technicians verify whether a network problem is caused by the local device, local network, name resolution, or a remote path failure. In CompTIA A+ support work, they provide a repeatable way to confirm each layer before making assumptions.
| Primary Focus | Diagnosing connectivity issues with command-line tools as of September 2026 |
|---|---|
| Core Commands | ping, ipconfig, tracert, pathping, nslookup, arp, netstat as of September 2026 |
| Best Use Case | Isolating whether the failure is local, DNS-related, gateway-related, or upstream as of September 2026 |
| Common Exam Relevance | CompTIA A+ troubleshooting questions about internet, LAN, and hostname failures as of September 2026 |
| Skill Level | Entry-level to junior support technician as of September 2026 |
| Typical Outcome | Faster root-cause identification and fewer unnecessary resets as of September 2026 |
Why Network Troubleshooting Commands Matter for CompTIA A+ Candidates
CompTIA A+ questions rarely hand you the answer. They describe a symptom, and you have to pick the best first tool or the best next step. That is why network troubleshooting commands matter: they map directly to the way support tickets are written in real life.
A technician may hear, “I can print to the office printer, but websites won’t load,” or “I can reach internal file shares, but not the internet.” Those are not generic outages. They are clues about the network layer that failed, and command-line tools let you prove whether the issue is IP configuration, the gateway, DNS, or routing.
That distinction matters for exam performance and for the help desk. The U.S. Bureau of Labor Statistics notes continued demand for computer support specialists, and those roles depend on fast triage, not guesswork. You can review the occupation outlook at the BLS Occupational Outlook Handbook. In other words, the commands are not just academic. They are the shortest path to evidence.
Good troubleshooting does not start with a fix. It starts with proving which layer is failing.
Pro Tip
On CompTIA A+ style questions, look for the first layer that still works. If the local machine responds but the internet does not, do not jump straight to replacing hardware. Test the gateway, then DNS, then routing.
Build the Right Troubleshooting Mindset Before Using Any Command
Troubleshooting mindset is the habit of moving from symptom to cause in a fixed order. That matters because users usually describe what they see, not what is actually broken. “The internet is down” may really mean only one website fails, or only DNS resolution is broken, or only one VLAN is unreachable.
The best approach is to work from the inside out: local device, local stack, local network, gateway, external path, and finally name resolution. That mirrors how traffic moves on a real network. Your machine talks to itself first, then to the LAN, then to the router, then beyond the subnet, and only then to remote services by name.
This layered method is also how the NIST problem-solving approach is commonly applied in IT operations: isolate, confirm, and only then change something. Random steps waste time and can hide the original issue. A reboot may temporarily clear a cache or renew a lease, but it does not explain why the failure happened.
Prove each layer before moving on
- Confirm the local TCP/IP stack works.
- Verify the IP address, subnet mask, default gateway, and DNS settings.
- Test reachability to the gateway and then to a remote IP.
- Check hostname resolution if IPs work but names do not.
- Trace the route if the break is outside the local subnet.
This sequence saves time because it prevents you from solving the wrong problem. If the address is wrong, no amount of traceroute output will help. If DNS is broken, pinging a hostname can mislead you into thinking the internet is down when the path is actually fine.
How Does Network Troubleshooting Work
Network troubleshooting works by testing one layer at a time and using each result to narrow the fault domain. That is the difference between a technician and someone guessing with a keyboard. Each command answers a specific question, and the next command depends on the answer.
- Start local. Ping 127.0.0.1 to verify the TCP/IP stack responds on the machine itself.
- Check configuration. Use ipconfig to confirm the computer has a valid IP address, gateway, and DNS server.
- Test the LAN. Ping the default gateway to prove the device can reach the local router or Layer 3 interface.
- Test beyond the LAN. Ping a remote IP address to separate routing problems from DNS problems.
- Test name resolution. Use nslookup when hostnames fail but IP connectivity still works.
The logic is simple, but the discipline is what makes it effective. For example, if a laptop can ping 8.8.8.8 but cannot open hostname-based sites, the path is not the main issue. DNS is.
CompTIA’s own objectives for A+ emphasize troubleshooting methodology, not command memorization. The official exam details are on CompTIA A+. If you are studying through ITU Online IT Training, this is the same layered thinking used in the CompTIA A+ Certification 220-1201 & 220-1202 training path: prove the layer, interpret the output, then move forward.
What Are the Key Network Troubleshooting Commands?
The most useful commands are the ones that answer a narrow, practical question. A command-line diagnostic is only valuable if you know exactly what it tells you and what it cannot tell you. The list below covers the tools CompTIA A+ candidates need most often.
- ping — tests basic reachability and latency.
- ipconfig — displays IP addressing, gateway, and DNS settings on Windows.
- tracert — shows the path packets take to a destination.
- pathping — combines route tracing with packet-loss analysis.
- nslookup — checks DNS name resolution.
- arp — shows IP-to-MAC mappings on the local segment.
- netstat — displays active connections and listening ports.
These tools are standard because they cover the most common failure points: local configuration, local reachability, name resolution, and routing. The Cisco command-line reference for network basics is also useful if you want to see how layered troubleshooting maps to real routing behavior; start with the Cisco documentation and learning resources. For Windows-specific behavior, Microsoft Learn is the right reference.
How each command fits the troubleshooting flow
| ping | Confirms whether a host responds and whether latency or loss is present as of September 2026 |
|---|---|
| ipconfig | Shows whether the device has a valid IP, gateway, and DNS values as of September 2026 |
| nslookup | Separates DNS failures from pure connectivity failures as of September 2026 |
| tracert/pathping | Identifies where the route breaks or degrades as of September 2026 |
Start with the Local Machine: Prove the TCP/IP Stack Is Working
TCP/IP stack is the set of networking components inside the operating system that handles local protocol processing, address handling, and packet delivery. The first thing to test is the loopback address. On Windows, run ping 127.0.0.1 or ping localhost.
If the loopback test succeeds, the device can communicate with itself through the networking stack. That means the problem is probably not the basic protocol stack or the operating system’s ability to handle IP traffic. You can move on to configuration and external reachability with more confidence.
If the loopback test fails, stop and investigate the local machine. That could point to a corrupted network stack, driver issues, or a deeper operating system problem. It is rare in day-to-day support, but it is important because it rules out the entire external network.
What the loopback test tells you
- Success means the local network stack is alive and responding.
- Failure means the issue is inside the device, not the external network.
- Value is in elimination, because it removes guesswork early.
This is why the loopback test is often the first command in a disciplined workflow. It is a fast way to prove that the machine is at least capable of talking to itself. That matters when a ticket is vague and the user has already restarted the PC three times.
Use Ipconfig to Verify Addressing, Gateway, and DNS Settings
ipconfig is the Windows command that displays the computer’s IP configuration. It shows the IP address, subnet mask, default gateway, and DNS server information that the system is using. If you are troubleshooting a device that can connect to the local network but cannot access the internet, this is one of the first commands you should run.
Look for obvious red flags. An APIPA address such as 169.254.x.x usually means the system failed to get a lease from DHCP. A missing default gateway means the host may still talk to local devices but cannot route beyond the subnet. Incorrect DNS servers can make web browsing fail even when raw IP connectivity works.
This command directly answers one of the most common CompTIA A+ style questions: a technician is troubleshooting a device that can connect to the local network but cannot access the internet. Which command should be used to verify the gateway and DNS settings on a Windows machine? The answer is ipconfig, usually with detailed output such as ipconfig /all.
What to compare in the output
- IP address — Does it match the expected subnet?
- Subnet mask — Is the network boundary correct?
- Default gateway — Is there a valid router address?
- DNS server — Are the DNS settings correct for the environment?
On a corporate network, compare the problem machine against a known-good workstation on the same VLAN. If one host shows a valid gateway and DNS values while the other does not, you have a configuration or DHCP issue rather than a general outage.
Warning
Do not assume “internet down” when ipconfig shows a private address. A working internal LAN can still exist even when DHCP, gateway configuration, or DNS settings are wrong on just one device.
Test Local Network Reachability with Ping
ping is a basic reachability test that sends ICMP echo requests and waits for replies. It is one of the most useful network troubleshooting commands because it tells you whether a target responds and how quickly it responds. Use it against the default gateway first, then against a remote IP address if needed.
If ping to the gateway succeeds, the local device can reach the router or Layer 3 interface on the subnet. If ping to the gateway fails but the loopback test succeeds, the problem is probably local addressing, cabling, Wi-Fi association, switch access, or the local gateway itself. If ping to a remote IP works but a website name fails, DNS is the more likely problem.
This also matches another common exam scenario: a technician is troubleshooting a network connectivity problem. Pings to the local wireless router are successful but pings to a server on the internet are unsuccessful. Which CLI command could assist the technician to find the location of the networking problem? The best next command is often tracert, because it shows where the path stops.
What ping can and cannot tell you
- It can tell you whether basic ICMP reachability exists.
- It can suggest latency, jitter, or packet loss when results are inconsistent.
- It cannot prove application access, because many services use ports and protocols beyond ICMP.
- It cannot guarantee the destination is healthy, because some systems block ICMP replies.
That last point matters. A failed ping is not always a down service. Some firewalls and endpoints intentionally drop ICMP while still allowing web traffic, SSH, or RDP. Interpret the result, don’t worship the result.
Use Tracert or Traceroute to Identify Where the Path Breaks
tracert on Windows and traceroute on many Unix-like systems show each hop between your device and a destination. This is the command you use when local pings work but traffic to remote systems fails. It is especially useful when you need to know whether the break is at the gateway, somewhere upstream, or near the destination.
Here is how to read it in practical terms. If the first hop fails, look at the local router or gateway. If several early hops respond and then the path dies, the problem may be upstream routing, a provider issue, or a filtered path. If the route reaches the destination and then stops, the issue may be with the target service, not the network itself.
Tracert is one of the best tools for answering this style of question: a technician is troubleshooting a network connectivity problem. Pings to the local wireless router are successful but pings to a server on the internet are unsuccessful. Which CLI command could assist the technician to find the location of the networking problem? The reason tracert helps is that it reveals where packets stop progressing.
When tracert is the better choice
- Gateway works but remote connectivity does not.
- Intermittent failure appears beyond the local subnet.
- You need path visibility rather than just a yes/no response.
The ISC2 and NIST-aligned troubleshooting mindset both emphasize evidence collection over assumptions. Tracert gives you that evidence in the form of hop-by-hop progression. It is not glamorous, but it is effective.
Use Pathping for a Deeper Look at Packet Loss Along the Route
pathping combines route tracing and packet-loss testing. It is slower than ping, but it gives you a more detailed view of where packets are being dropped along the path. Use it when the connection is unstable, not just unavailable.
That matters because some problems are intermittent. A user may say, “It works for a minute, then everything freezes.” Repeating ping over and over can show loss, but it will not always show where the loss begins. Pathping gives more context by measuring loss at each hop over time.
If the first few hops show no loss but a later hop shows a sharp increase, the issue may be beyond your local network. If the loss appears at the gateway, the local router, wireless path, or switch port becomes a stronger suspect. This makes pathping especially useful when a support ticket is about poor performance, not total failure.
Pathping vs. ping
- Ping is faster and better for quick checks.
- Pathping is slower but better for locating packet loss.
- Use ping first when you only need basic reachability.
- Use pathping when you need evidence of where instability begins.
For help desk work, that distinction is important. Repeating simple tests five times is not the same as analyzing a route. Pathping is the more intelligent choice when the issue is flaky and the user says the system is “kind of working.”
Use Nslookup to Diagnose DNS and Hostname Resolution Problems
nslookup is a DNS diagnostic command that checks whether a hostname can be translated into an IP address. If a computer can reach remote IP addresses but not website names or server names, DNS is the likely suspect. That is why nslookup belongs in every A+ candidate’s troubleshooting toolkit.
It directly answers another common exam-style clue: “The device can access the local network, but it cannot connect to other computers using hostnames.” That wording points to name resolution, not raw connectivity. In that case, nslookup can show whether the DNS server is responding, whether a record exists, and whether the host is being resolved correctly.
DNS issues are notorious because they look like internet outages. A browser error can tempt users to blame the network, but the real fault may be a bad DNS server entry or a missing record. If ping by IP works and nslookup fails, the path is probably fine and the problem is name resolution.
What to check with nslookup
- Verify the DNS server being queried.
- Confirm the hostname resolves to the expected IP.
- Compare the result with a known-good machine.
- Check for stale or incorrect records if the system is internal.
For Microsoft environments, Microsoft Learn DNS documentation is the best place to understand the underlying behavior. If a student is learning for CompTIA A+, this is also a good time to connect command-line output to real ticket triage. DNS failures are often the reason “everything seems broken” when only name resolution is broken.
Use Arp to Check Local Address Resolution on the LAN
ARP is the Address Resolution Protocol, and it maps IP addresses to MAC addresses on a local network. It is a local-layer troubleshooting tool, which means it helps when devices can see the same subnet but communication is still failing. It does not solve external routing or DNS issues.
The arp -a command displays the ARP cache. If a system has stale or incorrect mappings, local communication can become unreliable. That matters in situations where a device can reach some internal resources but not others, especially after a hardware replacement, IP change, or MAC address update.
ARP problems are less common than IP or DNS issues, but they are real. For example, if a device recently changed NICs or a static entry is wrong, cached address information can point traffic to the wrong place. Clearing stale mappings or refreshing the cache can resolve the symptom once the root cause is corrected.
When ARP is useful
- Local subnet communication fails even though IP settings look correct.
- Some LAN devices work and others do not.
- You suspect stale cache entries or address conflicts.
ARP is a good reminder that not every network issue is an internet issue. Many failures live entirely inside the local broadcast domain, and the right command saves you from wasting time on routers and DNS servers that are not involved.
Use Netstat to Inspect Active Connections and Listening Ports
netstat is a command that shows active connections, listening ports, and protocol statistics on the local machine. It helps you decide whether the problem is truly the network or whether the application itself is not listening on the expected port. That makes it one of the most practical troubleshooting commands for support work.
If a user says an application cannot connect, but the path and DNS look fine, netstat can help answer whether the local service is actually up. A server that is supposed to listen on port 443 but is not bound to that port will fail no matter how healthy the network path is. In that case, the issue is service configuration, not routing.
Netstat is also useful for spotting unexpected activity. Unfamiliar connections, repeated retries, or ports in the wrong state can point to software conflicts, failed services, or a security tool blocking access. It is not always the first command, but it becomes valuable when the network path appears healthy and the application still fails.
What netstat can reveal
- Listening state for local services.
- Established connections that prove traffic is flowing.
- Suspicious or unexpected activity that may indicate a software issue.
This is the command to use when the problem is probably local to the application or service rather than the path between devices. In other words, not every “network” ticket is actually a network ticket.
Create a Step-by-Step Troubleshooting Sequence You Can Reuse
A reusable sequence keeps you fast under pressure. The best technicians do not improvise every time; they follow a repeatable flow and adjust only when the output tells them to. That approach is especially useful for CompTIA A+ exam questions because it mirrors the expected troubleshooting process.
- Ping 127.0.0.1 to confirm the local stack works.
- Run ipconfig /all to verify IP, gateway, and DNS settings.
- Ping the default gateway to prove local reachability.
- Ping a remote IP to test routing beyond the subnet.
- Run nslookup if names fail but IPs work.
- Run tracert or pathping if the break appears upstream.
- Use arp and netstat when the fault seems local to the LAN or the application.
That sequence works because it follows the path packets actually take. Start with what is closest to the host, then move outward. If you reverse the order, you can burn time on routers, DNS servers, and upstream hops while the real issue is a bad local lease or an unplugged cable.
Key Takeaway
- ping proves basic reachability, but it does not prove application health.
- ipconfig is the first stop when gateway or DNS settings may be wrong.
- nslookup is the right command when hostnames fail but IPs work.
- tracert and pathping help locate where the path breaks or degrades.
- arp and netstat help when the problem is local to address mapping or service behavior.
What Are the Most Common Troubleshooting Scenarios?
Most real tickets fall into a small set of patterns. Once you recognize the pattern, the first command becomes obvious. That is why scenario-based practice matters so much for CompTIA A+ candidates.
Local network works but internet access fails
Start with ipconfig and ping. Check the default gateway and DNS entries, then ping the gateway. If gateway ping works, test a remote IP. If IP works but names do not, the issue is likely DNS.
IP addresses work but hostnames fail
Use nslookup first. This is the cleanest way to verify name resolution. If the hostname does not resolve, check the DNS server, the local cache, or the DNS record itself.
Some internal devices work but others do not
Check arp and the local subnet configuration. That pattern can indicate a cache issue, a duplicate address, or an address resolution problem on the LAN.
The connection is slow or unstable
Use pathping and then ping repeatedly to compare latency and loss. If loss appears at a specific hop, the route is more likely the source of the issue than the destination application.
An application will not connect even though the network seems fine
Use netstat to verify that the service is listening on the expected port. The network path can be perfect while the application is still down, misconfigured, or blocked locally.
These patterns show up in tickets and exams because they are easy to describe but tricky to diagnose. The command choice depends on the clue, not the complaint.
What Mistakes Do Students Make with Network Troubleshooting Commands?
Students usually miss the same things. The commands themselves are simple. The mistakes come from using them in the wrong order or reading the output too literally.
- Treating one failed ping as proof of a total outage. ICMP may be blocked while the service still works.
- Ignoring DNS. A healthy network can look broken when only hostname resolution is failing.
- Skipping ipconfig. If addressing is wrong, later tests waste time.
- Misreading tracert. A hop timeout does not always mean the route is broken.
- Assuming the service is reachable just because the host responds. Application ports still matter.
The CompTIA A+ exam rewards process. The real world does too. A technician who runs the same ordered checks every time is easier to trust, easier to escalate, and less likely to create false confidence by rebooting something that only appears to work afterward.
How Do These Commands Show Up in CompTIA A+ Exam Questions?
CompTIA A+ exam questions usually describe symptoms, not labels. That means you have to translate the wording into a likely fault layer before you can choose the right command. The exam is testing whether you can think like a support technician, not whether you can recite tool names from memory.
For example, the phrase “cannot connect using hostname” points toward DNS and nslookup. The phrase “can access local resources but not outside networks” suggests gateway, routing, or DNS checks, often starting with ipconfig and ping. If the prompt mentions connectivity to a router but failure to reach an outside server, tracert is often the best tool for finding where the path stops.
The official CompTIA exam page is the best place to verify current domains and exam structure: CompTIA A+. If you are studying through ITU Online IT Training, the practical goal is not just to memorize commands. It is to recognize the symptom pattern fast enough to choose the right command on the first try.
How to think during the exam
- Ask what layer is failing.
- Eliminate local issues first.
- Separate connectivity from name resolution.
- Choose the simplest tool that answers the question.
That approach helps more than memorizing a table of commands. If you understand why each command exists, the exam question becomes easier to decode.
Practical Tips for Using These Commands in Real Support Work
Good documentation makes troubleshooting faster the second time. When you run a command, record what you saw before you move on. That note can be the difference between a clean escalation and a second round of guesswork.
Compare the problem device with a known-good system on the same network. If both systems should have similar gateway and DNS settings, a quick ipconfig comparison can show the problem immediately. If one machine resolves names and the other does not, that tells you where to focus.
Consistency also matters. Use the same flow every time so your notes are easier to read and your handoffs are cleaner. If the issue needs escalation, senior technicians will want the path you tested, the hops that failed, and the exact outputs you captured. That is faster than asking the user to repeat the same story three times.
The best troubleshooting notes are short, factual, and tied to command output.
That style of work improves user trust. It also reduces repeat calls, because you are fixing the actual cause instead of clearing symptoms temporarily.
Real-World Examples of Network Troubleshooting Commands
These commands are not abstract exam material. They solve everyday problems in live environments.
Microsoft Windows workstation on a corporate LAN
A user can access file shares but cannot browse websites. ipconfig /all shows a valid IP address and gateway, but the DNS server is incorrect. A quick nslookup confirms that hostnames do not resolve, while ping 8.8.8.8 succeeds. The network path is fine. DNS is the real failure.
Office Wi-Fi client with gateway access but no internet
A laptop pings the local wireless router successfully, but a remote server does not respond. tracert shows the path dying after the first hop, which points toward the router, upstream firewall, or ISP path. The issue is no longer “the laptop,” and the technician has evidence to support escalation.
Internal application server that is not accepting connections
Users report that an internal app will not connect, but the server responds to ping. netstat shows the expected port is not listening. That tells the technician the problem is the application service, not the network route. This is exactly the kind of separation CompTIA A+ expects you to recognize.
For broader context on workforce expectations, the U.S. Department of Labor and BLS both reinforce the value of problem-solving and diagnostic skills in support roles. In practice, that means being able to prove what is broken instead of guessing.
When Should You Use These Commands, and When Should You Not?
Use these commands when you need evidence. Do not use them as a replacement for a basic physical check when the symptoms clearly point to a cable, switch port, Wi-Fi association, or power problem. The command-line is powerful, but it is not the first step in every ticket.
Use them when
- You need to isolate a connectivity failure layer.
- The user can reach some resources but not others.
- You suspect DNS, routing, or local addressing issues.
- You need proof before escalating.
Do not rely on them alone when
- The cable is unplugged or the NIC is disabled.
- Wi-Fi is not connected at all.
- The problem is clearly power, hardware, or physical layer related.
- The issue is an application login problem rather than a transport problem.
That boundary matters because it keeps you efficient. The right troubleshooting command is powerful only when the underlying question is already clear enough to answer.
Key Takeaway
- Start local with loopback and configuration checks before testing the wider network.
- Use ping for reachability, but remember that ICMP is not the same as application access.
- Use nslookup when names fail and IPs work.
- Use tracert or pathping when you need to find where the route breaks or loses packets.
- Use arp and netstat when the issue is local to LAN addressing or application ports.
CompTIA A+ Certification 220-1201 & 220-1202 Training
Master essential IT skills and prepare for entry-level roles with our comprehensive training designed for aspiring IT support specialists and technology professionals.
Get this course on Udemy at the lowest price →Conclusion
Effective network troubleshooting is about proving each layer in order: the local stack, the IP configuration, local reachability, name resolution, and then the route beyond the subnet. That is the fastest way to separate a real network failure from a DNS issue, a gateway problem, or a local application fault.
The commands that matter most are ping, ipconfig, nslookup, tracert, pathping, arp, and netstat. Used correctly, they are not just CompTIA A+ study items. They are the tools that help entry-level technicians diagnose tickets faster and explain their findings clearly.
If you are preparing for CompTIA A+ Certification 220-1201 & 220-1202, practice these commands in order and tie each one to a real troubleshooting question. The more consistently you work from symptoms to evidence, the faster you will find the root cause in class, on the exam, and on the help desk.
CompTIA®, A+™, Cisco®, Microsoft®, and ISC2® are trademarks of their respective owners.
