How to Check Your Network Connection Using Ping, Tracert and Ipconfig

 Almost everyone in IT can type ping google.com. Far fewer can look at the result and say anything more useful than "it works" or "it doesn't."

That gap is the entire subject of this article. These three tools produce numbers, and those numbers carry precise meaning. Latency tells you distance and congestion. Jitter tells you stability. TTL tells you roughly how many routers a reply crossed. Packet loss percentage tells you the severity of a fault.

This guide is about how to check network connection with ping, tracert, and ipconfig — not as commands to memorize, but as measurements to interpret.

Start With ipconfig, Always

Running any connectivity test before checking your own configuration is backwards. If your device has no valid address, ping results are meaningless.

ipconfig

Three values matter, and you should be able to explain all three:

1. IPv4 Address — your identity on this network.
2. Subnet Mask — how your device decides whether a destination is local or remote.
3. Default Gateway — where your device sends anything it cannot deliver locally.

What your IP address tells you instantly

This is the fastest diagnosis in the entire toolkit:

• A normal private address (192.168.x.x, 10.x.x.x, or 172.16–31.x.x) means DHCP succeeded. Your device and router are communicating.
• An address beginning 169.254 is APIPA, assigned by Windows when no DHCP server responds. This single result eliminates DNS, the browser, the website, and the provider from your investigation. The fault is physical, or the DHCP service on the router.
• No address at all means the adapter is disabled or there is no link.

For full detail, including DNS servers and lease information:

ipconfig /all

The DNS server addresses listed here matter enormously, because name resolution failures account for a large share of "the internet is down" reports.

Understanding What Ping Actually Measures

Ping sends an ICMP echo request and waits for an echo reply. It measures the complete round trip — there and back.

This is worth stating explicitly: a latency figure of 40ms does not mean 40ms to reach the destination. It means 40ms for the round trip. The one-way journey is roughly half that.

Reading ping results properly

ping 8.8.8.8

Four things to read, in order of importance:

1. Packet loss

Zero percent is the only acceptable result on a stable connection. Anything above zero on a wired local network indicates a real problem.

• 1–2% loss — noticeable in video calls, invisible in web browsing.
• 5% loss — voice and video become unusable.
• Above 10% — the connection is effectively broken.

2. Latency, and what is normal

• Under 1ms — same local network, wired.
• 1–5ms — local network, possibly wireless.
• 10–40ms — a server in the same country or region.
• 50–150ms — international.
• Above 200ms — a distant destination, a congested link, or a satellite connection.

3. Variation between packets, which is jitter

This matters more than most people realize. Four replies of 30, 31, 30, 32ms indicate a healthy, stable link. Four replies of 15, 180, 22, 240ms average out to something similar but describe a connection that will break every voice call.

Consistency is a stronger health indicator than raw speed.

4. TTL in the reply

TTL starts at a fixed value on the sending system and decreases by one at every router hop. A reply with TTL 118 from a source that started at 128 means roughly ten hops. It is not precise, but it is a quick sanity check that the reply came from where you expected.

Ping options that matter

ping -t 8.8.8.8

Continuous ping until you press Ctrl+C. This is the correct tool for intermittent faults, which a four-packet default test will almost always miss.

ping -n 100 192.168.1.1

One hundred packets for a statistically meaningful sample. Four packets prove very little.

ping -l 1400 8.8.8.8

Sends larger packets. Useful for finding MTU problems, where small packets pass and large ones fail — a fault that produces the maddening symptom of "some websites load and others hang."

ping -a 192.168.1.50

Resolves the address to a hostname, which helps identify an unknown device on your network.

The ping ladder that isolates any fault

Run these four in sequence. The first failure identifies the problem layer.

1. ping 127.0.0.1 — the loopback. Tests your own TCP/IP stack. Failure means a software problem on your machine, not a network fault.
2. ping <your own IPv4 address> — tests your network adapter.
3. ping <default gateway> — tests the path to your router. Failure here means cable, switch port, or router.
4. ping 8.8.8.8 — tests internet connectivity by IP address. Success here combined with a failing website means DNS is your fault, not connectivity.

This ladder is the most valuable routine in this article. It narrows any connectivity problem to one segment in under sixty seconds, and it requires no special tools or access.

An honest caveat

Many servers and firewalls deliberately block ICMP. A device that does not answer ping is not necessarily down. Always test against a target known to respond — major public DNS resolvers are reliable for this — before drawing conclusions.

Tracert: Finding Where the Path Breaks

Ping answers whether the destination is reachable. Tracert answers where the journey stops.

tracert google.com

How it works is genuinely clever: tracert sends packets with a TTL of 1, then 2, then 3, and so on. Each router that decrements TTL to zero returns an error message identifying itself. By incrementing TTL and collecting those errors, tracert maps the path one hop at a time.

Reading tracert output correctly

Each line is one hop, with three separate latency measurements.

Patterns and what they mean:

1. Steadily increasing latency across hops — normal. Each hop adds distance and processing.
2. Timeouts at one hop, but later hops respond — not a fault. That router is configured not to reply to these probes. This confuses beginners constantly. The path is fine.
3. Timeouts from one hop onward, continuing to the end — this is a genuine break. The last responding hop is where to focus.
4. A large latency jump that persists through all subsequent hops — a congested or geographically distant link at that point.
5. A large jump at one hop that returns to normal afterwards — usually harmless. That router deprioritized your probe while forwarding real traffic normally.

Point five matters. People frequently report a "problem" at hop four because it shows 90ms while hop five shows 45ms. If the later hops are fine, the path is fine. Routers treat ICMP as low priority.

The first hop is always your own router. If hop one fails or shows high latency, stop looking at the internet.

pathping for conclusive evidence

pathping google.com

This combines ping and tracert. It maps the route, then sends a large number of packets to every hop over several minutes and calculates packet loss at each one individually.

It takes far longer — typically five minutes — but it is the tool that proves intermittent problems. When you need evidence to give a provider, pathping output is what convinces them.

Building a Baseline, and Why It Changes Everything

Here is the habit that separates people who diagnose networks from people who guess at them.

Run these tests when everything is working normally, and write down the results.

Capture:

1. Ping to your gateway — 100 packets, recording average latency and loss.
2. Ping to a public DNS server — 100 packets, same figures.
3. Tracert to a major site — save the full output.
4. ipconfig /all — save the entire configuration.

Why this matters so much: when someone reports the network is slow, "45ms average" means nothing on its own. But "45ms average when the baseline is 12ms" is a measurement, an argument, and a starting point.

Without a baseline, you are comparing today's numbers against a feeling. With one, you have evidence.

Repeat the capture quarterly, and after any significant network change.

A Complete Testing Procedure

When a connectivity problem is reported, run this sequence:

1. ipconfig — valid address? A 169.254 address ends the investigation immediately.
2. ping 127.0.0.1 — is the local stack functioning?
3. ping <gateway> — is the router reachable?
4. ping 8.8.8.8 -n 20 — is the internet reachable, and how stable is it?
5. nslookup google.com — is DNS resolving?
6. tracert 8.8.8.8 — where does the path degrade?
7. pathping 8.8.8.8 — if the fault is intermittent and you need proof.

Each step eliminates a possibility. By step seven you either have the answer or you have demonstrated that the fault lies beyond your network — which is itself a valuable, defensible conclusion.

Mistakes That Produce Wrong Conclusions

1. Testing a website name first and calling it a connectivity failure when DNS is the real problem.
2. Trusting four packets to characterize an intermittent fault.
3. Reading intermediate tracert timeouts as failures when later hops respond normally.
4. Ignoring jitter and looking only at average latency.
5. Skipping ipconfig and starting with complex tools.
6. Testing only one destination — a single slow server tells you about that server, not your network.
7. Having no baseline, so every measurement is uninterpretable.
8. Assuming a blocked ping means a dead host.

Conclusion

These three tools are not a list of commands. They are a measuring instrument, and like any instrument, their value depends entirely on knowing what a normal reading looks like.

Do one thing today while your network is working properly: run ping <your gateway> -n 100 and ping 8.8.8.8 -n 100, and write down the average latency and loss for each. That takes two minutes and gives you a reference point. The next time someone says the network feels slow, you will be able to prove whether it is — and that is the real reason to know how to check network connection with ping rather than simply run it.