Author: wpx_

An IP subnet calculator turns an address and a prefix into the four numbers you need before you touch a switch: the network address, the broadcast address, the usable host range, and the host count. Feed it 192.168.1.0/24 and you get 192.168.1.0 as the network, 192.168.1.255 as the broadcast, 192.168.1.1 through 192.168.1.254 as usable hosts, and 254 addresses to assign. That is the whole job, done in a second, with no binary arithmetic on a whiteboard.

Once you can read those four fields correctly, you can size any LAN, split any block, and spot an overlapping route before it takes down a production segment. The math never changes; only the prefix does.

Subnetting mistakes rarely announce themselves. A DHCP scope that runs one address past a boundary, an ACL built from a subnet mask where a wildcard mask belonged, a /25 sitting inside a /24 someone else already advertised: these show up as intermittent failures three weeks later, not as an error at config time. PacketTools was built by a network and security engineer with 28 years in enterprise IT, hosting, and WAN/LAN environments, and the same verification habits that catch a bad VPN route catch a bad subnet boundary.

Work through the calculations below and you will be able to verify any addressing plan by hand, confirm it with a calculator, and explain why the boundary falls where it does.

How to Read the Results of a Subnet Calculation

Every subnet calculation reduces to one question: where do the network bits stop and the host bits start? The prefix length answers it, and every other field on the results page falls out of that single split.

Enter an IPv4 Address and Prefix Length

You need two inputs. An IPv4 address in dotted-decimal form, and a prefix length written as a slash followed by a number from 0 to 32.

The address can be any address inside the subnet, not just the network address. Enter 10.14.7.93/22 and the calculator works backward to the network boundary at 10.14.4.0. That behavior is useful in the field: you grab an IP off a live host, paste it in with the mask from ipconfig or ip addr, and immediately see which block it belongs to.

Some calculators accept a dotted-decimal mask like 255.255.252.0 instead of /22. Both describe the same 32-bit value.

Identify the Network Address and Broadcast Address

The network address is the first address in the block, with every host bit set to zero. The broadcast address is the last, with every host bit set to one.

Neither is assignable to an interface on a standard IPv4 subnet. In 192.168.1.64/26, 192.168.1.64 identifies the subnet itself and 192.168.1.127 is the broadcast address; a host configured with either will fail in ways that look like a cabling problem.

These two addresses are also your boundary markers. Any address between them belongs to this subnet, and anything outside it does not, which is the check you run when troubleshooting a network segment that cannot reach its own gateway.

Interpret the Usable Host Range and Host Count

Usable hosts equal 2^(32 − prefix) − 2 for any prefix from /1 through /30. The subtraction removes the network and broadcast addresses.

Read the usable host range as the assignable pool, then subtract your infrastructure. One address for the gateway, one or two for HSRP or VRRP peers, a handful for printers and management interfaces. A /26 advertising 62 usable hosts realistically supports around 55 endpoints before you feel crowded.

CIDR Notation and Subnet Masks Explained

CIDR notation and the dotted-decimal subnet mask carry identical information in different clothing. /24 and 255.255.255.0 both say “the first 24 bits identify the network,” and every router, firewall, and calculator treats them as equivalent.

What Does a /24 Prefix Mean?

A /24 prefix means 24 of the 32 bits are network bits, leaving 8 host bits. Two to the eighth power gives 256 total addresses, minus network and broadcast, for 254 usable hosts.

Classless Inter-Domain Routing was formalized in RFC 4632 and replaced the rigid class system, letting the prefix land on any bit boundary from /0 to /32. That flexibility is why a /27 for a 20-device wireless VLAN and a /21 for a large campus segment can coexist in the same routing table without waste.

The mental shortcut worth memorizing: each bit you add to the prefix halves the block.

Convert CIDR Notation to a Dotted-Decimal Mask

Write the prefix as that many consecutive 1 bits, pad with zeros to 32 bits, then split into four octets.

• /16 → 11111111.11111111.00000000.00000000 → 255.255.0.0
• /24 → 11111111.11111111.11111111.00000000 → 255.255.255.0
• /25 → 255.255.255.128
• /26 → 255.255.255.192

Only nine values ever appear in an octet: 0, 128, 192, 224, 240, 248, 252, 254, and 255. Seeing anything else in a mask field, like 255.255.255.100, means the config is malformed.

Why Classful Addressing No Longer Defines Modern Networks

Classful addressing assigned fixed prefixes by leading bits: Class A at /8, Class B at /16, Class C at /24. An organization needing 300 hosts had to take a full Class B and waste more than 65,000 addresses.

The class of an address still shows up as a display field on many calculators, and it still explains default masks on legacy gear. It has no bearing on how you size a subnet today. Set the prefix to fit the host count, then verify the boundary, and the class label becomes trivia.

Practical IPv4 Calculations You Can Verify

Four calculations cover most of what you will hit in production: a flat office LAN, a /24 split into quarters, private block selection from RFC 1918, and the special-case prefixes for router links and host routes.

Calculate 192.168.1.0/24 for a Standard LAN

192.168.1.0/24 gives you a network address of 192.168.1.0, a broadcast address of 192.168.1.255, and a usable host range of 192.168.1.1 to 192.168.1.254.

That is 254 assignable addresses in a single broadcast domain. In practice, reserve .1 for the gateway, .2 through .20 for static infrastructure, and hand the rest to DHCP.

A /24 stays comfortable up to roughly 200 active endpoints. Past that, broadcast traffic from ARP, mDNS, and discovery protocols starts eating switch CPU on older access hardware.

Split 192.168.1.0/24 Into /26 Subnets

Extending the prefix by two bits produces four equal subnets of 64 addresses each, 62 usable per subnet, with a mask of 255.255.255.192.

Notice the boundaries: 0, 64, 128, 192. The block size (64) equals 256 minus the last mask octet (192), which is the fastest way to find subnet boundaries without a calculator.

A common error here is treating .63 as usable. It is subnet 1’s broadcast address, and a host assigned to it will send its traffic to every device in that /26.

Size Private Address Blocks for Internal Networks

RFC 1918 reserves three private ranges, and picking the right one prevents pain later.

• 10.0.0.0/8 gives 16,777,214 usable addresses. Best for multi-site enterprises where you want a whole octet for site codes.
• 172.16.0.0/12 covers 172.16.0.0 through 172.31.255.255. The least-used range, which makes it the safest choice for VPN and lab segments that must not collide with a partner network.
• 192.168.0.0/16 contains 256 /24 networks. Every consumer router ships in this range, so avoid 192.168.0.0/24 and 192.168.1.0/24 on any segment reachable by remote workers.

Overlapping private space is the single most common cause of site-to-site VPN failures. Document each allocation before it goes live, and confirm the addresses in use at both ends.

Use /31 and /32 Prefixes for Router Links and Host Routes

A /31 provides exactly two addresses and no broadcast address, which RFC 3021 permits specifically for point-to-point links. Cisco routers, Juniper, and Linux all support it.

Using /30 on point-to-point links burns four addresses to deliver two. Across 500 WAN circuits, switching to /31 recovers 1,000 addresses.

A /32 describes a single host: network, broadcast, and host are the same address. You use it for loopback interfaces, BGP router IDs, and host routes injected into a routing table.

Apply Subnet Results to Routing, Security, and Address Planning

Subnet math becomes operational the moment you write it into a routing table, an ACL, or a DHCP scope. VLSM lets each segment take only the addresses it needs, wildcard masks invert the subnet mask for Cisco access control lists, and overlap checks prevent the silent failures that surface weeks after deployment.

Plan Variable-Sized Networks With VLSM

Variable Length Subnet Masking lets you assign different prefix lengths inside one parent block. Allocate largest first, then work down.

From 10.20.0.0/22, a workable plan looks like this:

• 10.20.0.0/24 for 200 user endpoints
• 10.20.1.0/25 for 100 VoIP phones
• 10.20.1.128/27 for 25 servers
• 10.20.1.160/30 for a point-to-point link

Allocating in descending size order keeps blocks aligned on their natural boundaries. Assign the /30 first and you fragment the space so badly that the /24 no longer fits.

Derive Wildcard Masks for ACLs

A wildcard mask is the bitwise inverse of the subnet mask: subtract each octet from 255.

• 255.255.255.0 → 0.0.0.255
• 255.255.255.192 → 0.0.0.63
• 255.255.0.0 → 0.0.255.255

So access-list 10 permit 192.168.1.0 0.0.0.255 matches the entire /24. In a wildcard mask, a 0 bit means “must match” and a 1 bit means “ignore,” the reverse of a subnet mask.

Pasting a subnet mask where a wildcard belongs is a mistake that passes syntax checking and quietly matches the wrong traffic.

Prevent Overlaps in Routing Tables and DHCP Scopes

Two subnets overlap when one contains any address of the other. 10.1.0.0/16 and 10.1.5.0/24 overlap completely, and OSPF will install the more specific route while your intent said otherwise.

Check DHCP scope ranges against the subnet boundary every time. A scope of .1 to .255 on a /24 hands out the broadcast address, and clients that receive it lose connectivity in a pattern that mimics a failing NIC.

Keep an address plan in version control with the prefix, VLAN ID, and gateway for every allocation.

Account for NAT, Public Addressing, and APIPA

NAT translates RFC 1918 space to public addresses, so your internal /16 can sit behind one routable IP. That translation hides overlaps until two networks merge.

APIPA addresses in 169.254.0.0/16 are self-assigned when DHCP fails. Seeing one on a client means the DHCP request never got an answer, so check the relay or scope exhaustion before suspecting the endpoint. Multicast lives in 224.0.0.0/4 and never appears in a host subnet allocation.

When public-facing services depend on that addressing being right, verifying DNS records and SSL from one place catches the downstream breakage fast.

Know Where IPv4 Rules End and IPv6 Begins

IPv6 keeps prefix length notation and drops almost everything else you just learned about host counting. There is no broadcast address, subnets are effectively never sized to fit host counts, and the standard segment is a /64 regardless of whether it holds 5 devices or 500.

Why IPv4 Address Exhaustion Changes Subnet Design

IPv4’s 32-bit space caps out at roughly 4.3 billion addresses, and the regional registries ran dry years ago. Public IPv4 is now a leased or purchased asset.

That scarcity is why you tighten prefixes on public blocks and lean on NAT internally. A /29 with 6 usable hosts for a DMZ is normal practice when public space costs money per address.

Internally, RFC 1918 space is free, so oversizing an internal /24 to a /23 costs nothing and saves a renumber later.

How IPv6 Prefixes Differ From IPv4 Subnet Masks

IPv6 uses prefix length only. No dotted-decimal mask exists, and 2001:db8:acad:1::/64 is the complete specification.

Addresses are 128 bits, written as eight hextets in hexadecimal. Leading zeros compress, and one run of consecutive zero hextets collapses to ::.

A /64 contains 18.4 quintillion addresses. Calculating usable hosts is pointless at that scale, which is why IPv6 subnet calculators report the prefix range instead of a host count.

Use /64 Networks and SLAAC Without IPv4 Broadcasts

SLAAC requires a /64. Stateless Address Autoconfiguration derives the last 64 bits from the interface identifier, so any longer prefix breaks automatic addressing on that link.

Assign a /64 to every LAN segment. Point-to-point links can use /127, but a /64 per link stays consistent and costs nothing from a /48 site allocation.

IPv6 replaces broadcast traffic with multicast groups. Neighbor Discovery uses solicited-node multicast instead of the ARP broadcasts that flood an IPv4 segment, so the broadcast domain sizing limits that shape IPv4 design do not apply the same way.

Use Accurate Subnet Boundaries With Confidence

Every subnet calculation comes back to four values: the network address at the bottom of the block, the broadcast address at the top, the usable host range between them, and the count of addresses you can actually assign. Get the prefix length right and those four fall into place.

Keep the block-size shortcut handy (256 minus the last mask octet) and the boundaries for /25 through /30 become fast enough to check in your head. Verify the result before it reaches a config, especially when splitting an existing /24 or adding a route that touches an already-advertised block.

For the diagnostics that follow an addressing change, from confirming reachability with a ping test to tracing a path hop by hop, PacketTools runs everything in the browser with no sign-in, no tracking, and no logging of your IPs or queries.

Traceroute answers a question that a ping cannot: when a connection is slow or broken, where along the path does it break down? Running one takes a single command, and the output gives you a hop-by-hop map from your machine to the destination, with timing at every router in between.

To trace a route, open Command Prompt on Windows and run tracert example.com, or open Terminal on macOS or Linux and run traceroute example.com; each numbered line that comes back is one router between you and the target, with three round-trip times in milliseconds. That is the whole mechanic. The skill is reading what those numbers mean without blaming the wrong hop.

Most people misread traceroute output the first few dozen times. A row of asterisks looks like a failure and often is not one. A 180 ms spike at hop 6 looks like a bottleneck and often is not one either. PacketTools builds and maintains free browser-based diagnostics used in live production networks to verify VPNs, analyze routing, and harden infrastructure, and the interpretation habits below come from that work.

By the end, you will be able to run a trace on any operating system, tell a real routing problem from a router that simply deprioritizes probe traffic, and hand your ISP evidence they cannot wave away.

Run a Trace From Windows, macOS, or Linux

Every major operating system ships a trace route utility, though Windows names its command differently and defaults to a different protocol than the Unix versions. Both accept either a hostname or a raw IP address as the target, and both walk outward one hop at a time until they reach the destination or hit the default 30-hop ceiling.

Use Tracert in Windows Command Prompt

Windows calls the utility tracert. Press the Windows key, type CMD, press Enter, then run:

tracert packettools.com

The console prints one line per hop and ends with Trace complete. Useful flags:

• -d skips reverse DNS lookups, which makes a slow trace finish much faster
• -h 15 caps the trace at 15 hops
• -w 500 shortens the per-probe timeout to 500 ms
• -4 or -6 forces IPv4 or IPv6

Windows tracert sends ICMP Echo requests, which matters when you compare its output against a Linux trace of the same target.

Use Traceroute in macOS and Linux Terminal

macOS includes traceroute in Terminal with no installation. On Ubuntu and Debian it is not present by default, so install it first with sudo apt install traceroute, then run traceroute packettools.com.

The Unix version defaults to UDP probes on high-numbered ports. Add -I for ICMP probes to match Windows behavior, -T for TCP, and -n to suppress hostname resolution. Combining them (traceroute -In) gives clean, fast output that lines up with tracert results.

macOS also exposes a Traceroute tab inside Network Utility for anyone who prefers a GUI, per this walkthrough of running traceroute across all three platforms.

Choose a Domain Name or IP Address to Test

Trace the exact thing that is broken. When a web app times out, trace its hostname, since that resolves through DNS and tests the same address your browser uses. When you suspect DNS itself, trace a known-good IP such as 8.8.8.8 and compare.

Tracing a URL with https:// in front will fail. Strip it down to the bare hostname or IP. Also remember that a hostname behind a CDN resolves to whichever edge node is nearest you, so two people tracing the same domain legitimately reach different endpoints.

Confirming which public address you are testing from helps too, and a what is my IP lookup takes two seconds before you start.

When an Online Trace Is More Useful Than a Local Command

A local trace only shows the path from your machine outward. When you need to know whether a server is reachable from elsewhere, run the trace from a different vantage point.

Browser-based diagnostics answer three situations a local command cannot:

1. Your own link is the suspect. If your uplink is saturated, every local measurement inherits that congestion.
2. You need an outside-in view of your own server. Customers reach it from the public internet, not from your LAN.
3. You are on a locked-down corporate network. Egress filtering frequently blocks ICMP and UDP probes entirely.

PacketTools runs its traceroute and related network tools in the browser with no sign-in, no logging of IPs or queries, and no analytics cookies.

How Traceroute Reveals the Network Path

Traceroute works by deliberately sending packets that expire early. It manipulates the time-to-live field in the IP header so each router along the way is forced to discard a packet and report back, which is how the tool discovers devices it was never told about.

What a Hop Represents Between Source and Destination

A hop is one Layer 3 device that decremented your packet’s TTL and forwarded it, so hop 1 is almost always your local gateway. Hop count is the number of routers between source and destination, and a typical path across the United States runs 10 to 18 hops.

Higher hop counts do not automatically mean worse performance. A 16-hop path over well-provisioned backbone links routinely beats an 8-hop path that detours through a congested peering point.

How TTL Expiration Produces Router Replies

Every IP packet carries a TTL value, a hop limit that each router reduces by one. When TTL reaches zero, the router drops the packet and returns an ICMP Time Exceeded message to the sender, which reveals that router’s address.

Traceroute exploits this by sending probes with TTL=1, then TTL=2, then TTL=3, and so on. Each round provokes a reply from one hop further along. The TTL-and-ICMP mechanism is documented in detail here. Most implementations send three probes per TTL value and print all three round-trip times, which is why each line has three timing columns.

Why ICMP, UDP, and TCP Traces Can Differ

Protocol choice changes results because firewalls treat protocols differently. UDP probes to high ports get dropped by edge ACLs constantly. ICMP is often rate-limited or deprioritized. TCP probes to port 443 slip through filters that block everything else, since that traffic looks like ordinary HTTPS.

Run at least two protocols before declaring a hop dead.

Why the Same Destination Can Follow Different Routing Paths

Routing tables change, and carriers load-balance across parallel links. Two traces run 30 seconds apart can list different hop 7 addresses without anything being wrong.

Return paths add another wrinkle. The route back to you may not mirror the route out, so an RTT measured at hop 9 includes a return leg you never see in the output.

Read Traceroute Output Without Misdiagnosing a Hop

Read traceroute output as a cumulative measurement, where each line’s timing includes everything before it. A single ugly row in the middle of an otherwise healthy trace is usually a router being polite to real traffic and rude to your probes.

What Round-Trip Times and Response Times Measure

Each of the three numbers on a line is the round-trip time in milliseconds for one probe: your machine to that router and back. These are not per-hop delays; hop 9’s RTT already contains hops 1 through 8.

For nearby networks, RTT values sit below 100 ms, while distant international paths reach up to 300 ms. Watch the trend across hops. Rising, stable numbers describe a normal path. Numbers that jump and stay high mark a real transition point.

How to Interpret Hostnames and IP Addresses

The last column shows the responding router’s IP and, when reverse DNS resolves, its hostname. Carrier hostnames encode geography and link speed in abbreviations: ae-3.chi01, dal-edge-12, ten0-0-0-1.nyc.

Reading those city codes tells you when traffic crossed from Dallas to Chicago, which explains a legitimate 25 ms increase. A missing hostname means no PTR record exists, which says nothing about that router’s health. If IP address basics are shaky, the private ranges at the start of a trace are your own network.

What Asterisks and Request Timed Out Messages Actually Mean

Three asterisks and Request timed out mean no reply came back within the timeout window. Four causes produce that identical output:

• The router is configured not to return traceroute responses
• A firewall filters ICMP traffic at that boundary
• ICMP rate limiting kicked in on a busy control plane
• The router is genuinely down

Here is the test that settles it: if hops after the starred hop respond normally, that hop is forwarding traffic fine and simply declined to answer. Asterisks at the end of a trace, continuing to hop 30, are the ones worth investigating.

When Destination Net Unreachable Signals a Route Failure

Destination net unreachable is different from a timeout. A router actively sent back an ICMP Destination Unreachable message, saying it has no route to the target network.

That points to a routing problem: a missing or withdrawn route, a BGP issue upstream, or an ACL rejecting the traffic. Note which hop returned it, because that device is the last one with a decision to explain.

Use Trace Evidence to Isolate Latency and Reachability Problems

Isolating a fault means assigning it to a network segment you can name: your LAN, your ISP’s access network, a transit carrier, or the destination host. Traceroute output splits into those zones, and the hop where behavior changes tells you which team owns the ticket.

Identify a Sustained Latency Increase Rather Than One Slow Reply

Look for a jump that persists through every subsequent hop. A path that reads 2, 9, 11, 14, then 86, 88, 91 has a real problem between hops 4 and 5.

One inflated probe surrounded by normal ones is control-plane noise. A hop showing 140/12/13 ms across its three probes is a router that answered one probe slowly while forwarding everything else at 12 ms.

Latency that climbs at a hop and drops back down at the next hop is the clearest signature of probe deprioritization. Real congestion never gets faster downstream.

Separate Local Gateway, ISP, Transit, and Destination Issues

Traceroute output falls into five recognizable groups, as this operating-system-agnostic breakdown describes: your local network, your ISP, the internet backbone, the destination’s host network, and the destination itself.

• Hop 1 slow or timing out: your router, cabling, or Wi-Fi. Fix it locally.
• Hops 2 to 4 degraded: your ISP’s access network. Open a ticket with the trace attached.
• Middle hops degraded: transit or peering congestion, which neither you nor your ISP controls directly.
• Final hop slow, everything before it clean: the destination server is loaded, not the network.

When hop 1 is fine but nothing beyond it works, the pattern described in Wi-Fi connected but no internet applies.

Investigate a Trace That Stops Before the Destination

A trace that runs to hop 30 with nothing but asterisks after hop 12 means one of two things: packets stop being forwarded past hop 12, or the destination network filters probe traffic entirely.

Distinguish them by testing reachability directly. If a ping or an HTTPS request to the destination succeeds while the trace dies at hop 12, the path works and the filtering is cosmetic. When both fail, you have a genuine reachability break, and hop 12 is where to point.

Run tracert -T -p 443 on Linux against a web host before concluding anything, since many production edges answer TCP on 443 and drop everything else.

Compare Paths by Time, Location, and Protocol

A single trace is one sample. Run the same trace three times over ten minutes, and the hops that degrade consistently are your suspects.

Then vary the other two axes. A trace from a second location isolates whether the fault is on your access link. A protocol switch from UDP to ICMP to TCP tells you whether a “dead” hop is filtered or broken. Comparing a trace to a working destination against the failing one narrows the divergence point to a specific hop.

Corroborate a Trace With PacketTools Network Diagnostics

A traceroute tells you about the path, and it stays silent on name resolution, certificate validity, and whether the problem is intermittent. Pairing it with two or three other checks converts a suspicion into evidence.

Check Name Resolution Before Escalating a Route Problem

Confirm DNS first. When a hostname resolves to a stale or wrong address, your trace faithfully maps the path to the wrong server, and the routing looks broken when the record is the fault.

Run a lookup, note the returned IP, then trace that IP directly. Matching results clear DNS from the investigation. A recent record change calls for a DNS propagation checker across global resolvers, and resolver-side failures follow the patterns covered in DNS server not responding.

Use Ping and Repeated Tests to Establish a Baseline

Traceroute gives you three probes per hop at one moment. Sustained testing shows whether the degradation is constant or bursty.

Ping the destination and the last clean hop side by side. If both show the same packet loss percentage, the loss originates at or before that hop. A ping test run for several minutes establishes the normal RTT range for that path, which makes tomorrow’s spike measurable against a number instead of a memory.

Validate HTTPS and Email Services Alongside Reachability

Reachability and service health are separate questions. A path can be perfect while TLS negotiation fails on an expired certificate or a broken chain.

An SSL/TLS check confirms the handshake and certificate validity at the endpoint your trace reached. For mail problems, delivery failures more often trace to SPF, DKIM, or DMARC records than to routing, and the SuperTool runs DNS, MX, SPF, DKIM, DMARC, blacklist, and SSL tests against a domain in one pass. Tenant-specific records get their own check through the M365 domain checker.

Capture Useful Evidence for an ISP or Hosting Provider

Support desks act on specifics. Save raw output rather than describing it: tracert 8.8.8.8 > result.txt on Windows, or traceroute 8.8.8.8 > results.txt on Linux and macOS.

Include in the ticket:

• Timestamps for each trace, with at least three runs showing the same hop degrading
• Both a failing trace and a working trace to a comparable destination
• Ping statistics with loss percentage and RTT range
• Your public IP and the exact target hostname or address
• The protocol used, since a UDP-only failure means something different from an ICMP failure

Further diagnostic walkthroughs live in the PacketTools network troubleshooting library.

Build Better Troubleshooting Decisions From the Full Path

A traceroute test earns its value when you read it as a whole path instead of hunting for the single worst-looking line. Run the command, note where round-trip times rise and stay risen, and check whether hops after a starred row still respond.

That reading assigns a routing issue to a segment: your gateway, your ISP’s access network, a transit carrier, or the destination host. Confirm it with DNS and repeated ping tests before you escalate, and attach the saved output with timestamps.

Three traces to the same target ten minutes apart, plus one trace to a known-good destination, give any provider enough to open an engineering ticket on the network connection instead of asking you to reboot your router.

When Windows throws “DNS server not responding” or a Linux box starts timing out on every lookup, the resolver itself is rarely the broken piece. Nine times out of ten the fault sits between your NIC and port 53: a stale cache entry, a VPN hijacking DNS traffic, an adapter still holding a DHCP lease from a network you left an hour ago.

Confirm the fault with ping 8.8.8.8 first: if ICMP replies come back but nslookup times out, you have a name resolution problem and not a connectivity problem, and every fix below narrows down from there. That single test saves you from resetting a router that was never at fault.

The steps here are the same ones we run against production networks at PacketTools, where the network tools log nothing and store nothing. You will finish with a working resolver and a repeatable way to prove it.

What the Error Actually Indicates

The message means your stub resolver sent a query and got nothing back before the timeout expired. It says nothing about whether the DNS server is healthy, only that no answer arrived at your machine within the window.

How DNS Resolution Turns Domain Names Into IP Addresses

Your application hands a hostname to the OS stub resolver, which forwards it to the configured recursive resolver. That resolver walks the domain name system from root to TLD to authoritative nameserver, then returns an A or AAAA record with the IP address.

Every hop in that chain has its own timeout. A slow authoritative server 60 ms away can surface on your desktop as a dead local resolver.

Why a Timeout Does Not Always Mean the Resolver Is Down

Windows gives up on a DNS query fast, and a UDP packet dropped by a firewall produces the exact same silence as a crashed server. Corporate VPN clients intercept port 53 and route it to an internal resolver that your split-tunnel config never reaches.

A DNS outage at the provider is possible. An overloaded resolver under load or a broken DNSSEC chain returns SERVFAIL, which is a different failure with a different fix.

Symptoms That Separate Local, Network-Wide, and Domain-Specific Failures

Map the symptom to the scope before you touch a single setting. Changing resolver addresses on a laptop does nothing when the zone’s nameservers are unreachable.

Isolate the Fault Before Changing Settings

Spend three minutes proving where the failure lives and you avoid an hour of blind config changes. The goal is to answer two questions: does raw IP connectivity work, and does the configured resolver answer direct queries?

Test Another Browser, Device, and Network Path

Open the same URL in a second web browser. Chrome and Safari both run their own DNS-over-HTTPS stack and browser cache, so a failure in one and success in the other points at the browser rather than the network connection.

Then try a second device on the same Wi-Fi. Two devices failing identically moves the fault upstream to the router or the ISP.

Compare Wi-Fi, Ethernet, VPN, and Mobile Data Results

Tether to mobile data and retest. Resolution working over a hotspot while the LAN fails isolates the problem to your local network connections or ISP DNS.

Disconnect the VPN and test again. VPN clients push their own resolvers and rewrite /etc/resolv.conf or the Windows interface metric, and a stale tunnel leaves you pointed at an unreachable internal server. The same applies to a system proxy holding a dead PAC file.

Use Ping, Nslookup, and Dig to Test the Configured Resolver

Ping the resolver’s IP directly. If ICMP replies but queries do not, port 53 is filtered somewhere between you and it.

ping 8.8.8.8
nslookup packettools.com 192.168.1.1
dig @192.168.1.1 packettools.com +short

Substitute your actual resolver address. A timeout means unreachable; SERVFAIL means it answered but failed upstream; NXDOMAIN means it answered that the name does not exist. Our ping test gives you an outside-in reference point when you need to compare against a path you do not control.

Check Whether the Failure Is Limited to One Domain

Query a known-good domain and the failing one against the same resolver. One domain failing while everything else resolves is a zone problem, and the fix belongs to whoever runs the nameservers.

Repair DNS Resolution on Windows

Start with the cache and the DHCP lease, since those two account for most Windows 10 and Windows 11 DNS errors that clear without a reboot. Work down to adapter state and security software only when the cheap fixes fail.

Flush the Local Cache and Renew DHCP Configuration

Open Command Prompt as administrator and run these in order:

ipconfig /flushdns
ipconfig /release
ipconfig /renew
ipconfig /registerdns
netsh winsock reset
netsh int ip reset

The last two require a reboot. ipconfig /flushdns clears the DNS cache; the release and renew pair forces a fresh DHCP lease, which matters when the adapter is still holding DNS server addresses from a previous network.

Confirm the result with ipconfig /all and read the DNS Servers line. On domain-joined machines, check whether Group Policy is pushing a resolver that overrides your edit.

Set and Validate IPv4 and IPv6 Resolver Addresses

Press Win+R, run ncpa.cpl, right-click the active adapter, choose Properties, then Internet Protocol Version 4 (TCP/IPv4). Set a preferred DNS server and an alternate DNS server, for example 1.1.1.1 and 8.8.8.8.

Repeat for Internet Protocol Version 6 (TCP/IPv6) or the stack keeps querying an unreachable AAAA path. Some Windows builds resolve the error only after you disable IPv6 on the adapter, though a working IPv6 resolver is the better outcome.

Validate before you close the dialog:

nslookup packettools.com 1.1.1.1
Resolve-DnsName packettools.com -Server 8.8.8.8

Inspect Adapters, Drivers, and Conflicting Virtual Interfaces

Open Device Manager and check the network adapter for a warning icon. Roll back or reinstall the network adapter driver when the error appeared right after a Windows Update.

Virtual interfaces cause more grief than physical ones. Hyper-V switches, VMware adapters, and leftover VPN TAP devices sit at a lower interface metric and win the DNS race:

Get-DnsClientServerAddress
Get-NetIPInterface | Sort-Object InterfaceMetric

Disable every unused connection under Change adapter settings in Network and Sharing Center.

Use Safe Mode and Security Controls to Identify Local Interference

Boot into Safe Mode with Networking. Resolution working there and failing in a normal boot points at a third-party service, and antivirus software with a web-filtering module is the usual candidate.

Temporarily disable the firewall and the antivirus DNS protection layer, retest, then re-enable immediately. Windows Defender rarely blocks port 53 outright, so treat a Defender-only machine as a lower-probability cause and keep looking at drivers and virtual adapters.

Repair DNS Resolution on Linux and macOS

On Linux, find out what is answering queries before you edit anything, because /etc/resolv.conf is a symlink to a stub on most modern distributions. On Mac, the fix path runs through mDNSResponder and the per-interface resolver order.

Inspect Resolver Configuration and systemd-resolved Status

Run these from a terminal:

resolvectl status
systemctl status systemd-resolved
ls -l /etc/resolv.conf
cat /etc/resolv.conf

A nameserver 127.0.0.53 line means systemd-resolved is the stub and the real upstreams appear in resolvectl status per link. Editing /etc/resolv.conf directly on that setup gets overwritten on the next network event.

On macOS, scutil --dns prints the resolver list in priority order along with the search domains attached to each interface.

Clear Local Caches and Restart Network Services

sudo resolvectl flush-caches
sudo systemctl restart systemd-resolved
sudo systemctl restart NetworkManager

Older systems use sudo systemd-resolve --flush-caches or an nscd restart. If dnsmasq is running locally, flushing systemd’s cache changes nothing, so check with systemctl status dnsmasq first.

On macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. Toggle Wi-Fi off and on afterward, and run Wireless Diagnostics when the interface keeps dropping.

Check VPN, NetworkManager, and DHCP-Supplied DNS

DHCP-supplied resolvers overwrite static entries on every lease renewal. Pin them per connection:

nmcli con show
nmcli con mod "Wired connection 1" ipv4.ignore-auto-dns yes
nmcli con mod "Wired connection 1" ipv4.dns "1.1.1.1 8.8.8.8"
nmcli con up "Wired connection 1"

Bring the VPN down and rerun resolvectl status. A tunnel that exits uncleanly leaves a routing domain (~.) claiming all queries for a resolver that no longer answers. Reboot the router and modem only after ruling out the host, and verify the router configuration is not still forwarding to a dead upstream.

Use Terminal Diagnostics to Confirm the Active Resolver

dig packettools.com +short
dig @1.1.1.1 packettools.com
resolvectl query packettools.com

dig bypasses nsswitch and talks to the resolver in /etc/resolv.conf, while resolvectl query follows the same path glibc applications use. When those two disagree, the problem is in nsswitch or the systemd-resolved link config, not the upstream server. Watch the wire with sudo tcpdump -i any port 53 to see whether queries leave the host at all. For a wider methodology across hosts and zones, our guide to network troubleshooting covers the same ordering applied to routing and latency faults.

Validate Resolvers and Investigate External DNS Problems

Once the host is clean, prove the answer is correct from outside your network. Local tools tell you what your resolver returned; they cannot tell you what the authoritative nameservers are publishing.

When to Test Google DNS, Cloudflare, or Another Public Resolver

Query a public DNS resolver directly and compare. Google DNS runs on 8.8.8.8 and 8.8.4.4, Cloudflare on 1.1.1.1, and Quad9 on 9.9.9.9 with malicious-domain filtering built in.

dig @8.8.8.8 packettools.com
dig @1.1.1.1 packettools.com

Both answering while your configured resolver times out confirms an ISP DNS or router forwarder failure. Setting Cloudflare as primary and Google as secondary, as this DNS troubleshooting walkthrough recommends, covers most single-provider failure scenarios.

Check Records, Delegation, and Propagation From Outside the Network

Pull the delegation and compare it against what the zone serves:

dig NS packettools.com +trace
dig @ns1.example-provider.net packettools.com SOA
dig MX packettools.com

Mismatched serials between nameservers mean zone transfers are failing quietly. A DNS propagation checker shows what resolvers in different regions currently hold, which is the fastest way to separate a stale TTL from a genuine record error. For a full sweep of DNS, MX record, SPF, DKIM, DMARC, blacklist, and SSL checks in one pass, the SuperTool runs them together.

Identify DNS Hijacking, Secure DNS, and DNS-over-HTTPS Mismatches

Compare the A record your resolver returns against 1.1.1.1. Different IP addresses for the same hostname signal DNS hijacking, a captive portal, or an ISP redirecting NXDOMAIN responses to an ad page.

Secure DNS settings in Chrome and Edge send queries over DNS-over-HTTPS to a resolver you never configured at the OS level, so browser lookups succeed while nslookup fails. Disable DoH in the browser when troubleshooting to keep both paths on the same resolver. Enterprise environments with DNS filtering should verify the policy allows the domain before assuming a fault. Related hardening topics live in our cybersecurity coverage.

Know When the Issue Belongs to the ISP, DNS Provider, or Domain Owner

Escalate to the ISP when public resolvers answer and theirs does not, and confirm from a mobile hotspot first so you arrive with evidence. The DNS provider owns it when the authoritative servers return SERVFAIL or refuse queries. The domain owner owns it when the records are simply wrong or the registrar delegation points at retired nameservers. Microsoft 365 tenants with mail routing failures should validate the required records with an M365 domain check before opening a ticket.

A Repeatable Path From DNS Failure to Verified Recovery

Run the same sequence every time and a DNS resolution failure stops being guesswork. Ping an IP to prove the internet connection, query the configured resolver directly, flush the cache and renew DHCP, then set a known-good resolver on both IPv4 and IPv6.

When the host checks out, move outward: compare answers from 1.1.1.1 and 8.8.8.8, trace the delegation, and check propagation from outside your network before deciding whose problem it is.

Close the loop with a verification query rather than a browser reload. dig packettools.com +short returning an address, plus a second lookup against a public resolver returning the same address, is proof the fix held. Record which step resolved the DNS error so the next incident on that network starts at step three instead of step one, and keep the DNS troubleshooting workflow handy for the ones that do not clear in five minutes.

Your laptop shows full bars, the network name is right there in the tray, and nothing loads. That gap between “connected” and “online” is the whole problem: your device finished its wireless handshake with the router, but something further along the path is broken.

When Wi-Fi is connected but no internet access appears, the fix depends on one question you can answer in under two minutes: is only one device offline, or is every device offline? One device points at that device’s IP, DNS, or driver state. Every device points upstream at the router, the modem, or the ISP.

At PacketTools, the same diagnostic sequence gets used on production networks: isolate the layer first, then change exactly one thing. Guessing burns an hour. A structured path usually resolves this in ten minutes, and it teaches you where the fault actually lived so you recognize it faster next time.

What a Connected Status Actually Proves

A “connected” indicator confirms one thing: your wireless adapter successfully authenticated to the access point and holds a radio link. It says nothing about whether the router can reach your ISP, whether you received a valid IP address, or whether DNS resolves.

Wi-Fi Association Is Not Internet Reachability

Association happens at layer 2. Your device negotiated the security handshake with the wifi router and joined the wireless network. Internet reachability lives several layers above that, requiring a valid TCP/IP configuration, a working default gateway, and an upstream WAN link that carries traffic.

Windows knows the difference. That yellow warning triangle appears because Windows sends a small probe to a Microsoft connectivity endpoint after joining. When the probe fails, the label changes to “No internet, secured” while the radio link stays perfectly healthy.

The Path From Wireless Device to ISP

Traffic crosses four distinct handoffs before it reaches a web server:

1. Device to router: the radio link, plus a DHCP-assigned IPv4 or IPv6 address
2. Router internal routing: NAT, firewall rules, and the default gateway
3. Router WAN to modem: the physical uplink, often an Ethernet cable
4. Modem to ISP: the DOCSIS, fiber, or DSL circuit that carries you to the wider internet

Any one of those four can fail while the first stays green. That is why a single “restart everything” reflex fixes the problem sometimes and wastes ten minutes the rest of the time.

Why Full Signal Bars Can Still Mean No Web Access

Signal bars measure received signal strength from the access point. A router sitting six feet away with a dead WAN port still broadcasts a beautiful five-bar signal.

Strong signal with no traffic also shows up when the router hands out an address from the wrong subnet, when a captive portal login has expired, or when the ISP has suspended the account. In each case, the wi-fi signal is irrelevant to the fault.

How to Locate the Fault in Two Minutes

Three quick tests narrow the fault from “somewhere on the network” to a single component: a second device, a wired connection, and a raw IP ping against a domain name lookup. Run them in that order before touching any network settings.

Check Whether One Device or Every Device Is Offline

Pick up a phone or tablet on the same network and open two familiar sites. Testing two sites matters because a single site can be down while your connection is fine.

If the second device works, leave the router alone and troubleshoot the first device. If nothing works, move upstream to the modem, router, and ISP. This one check eliminates half the possible causes in about thirty seconds.

Compare Wi-Fi With an Ethernet Connection

Plug a laptop directly into a router LAN port with an Ethernet cable and disable the wi-fi adapter. Working wired traffic isolates the fault to the wireless side: radio, band steering, or the wireless adapter itself.

If the wired connection is also dead, the problem sits at the router WAN or beyond. As a hands-on troubleshooting walkthrough puts it, comparing your wired vs. wireless connection tells you whether you are facing a Wi-Fi problem or an internet problem.

Test an IP Address and a Domain Name Separately

Open a terminal and run two pings back to back:

• ping 1.1.1.1 (a raw IP address, no name resolution involved)
• ping google.com (requires a working DNS server)

The IP succeeding while the name fails is a textbook DNS failure, and it means your internet connection itself is intact. Both failing points at routing, the gateway, or the WAN link. A browser-based ping test run from another machine confirms whether the destination is reachable from outside your network.

When the Entire Network Has Lost Internet Access

Every device offline means the fault sits at the router, the modem, or the ISP circuit. Work through the power cycle first, read the status lights second, and only then start a conversation with the provider.

Power-Cycle the Modem and Router in the Right Order

Order matters because the modem must complete its ISP handshake before the router requests a WAN address.

1. Unplug both the modem and the router.
2. Wait two to five minutes so capacitors drain and the ISP releases the old session.
3. Plug in the modem alone. Wait until its online or globe light goes solid.
4. Plug in the router. Give it another five minutes before testing.

Rushing step three is the most common mistake. A router that boots against a modem still syncing will grab a bogus WAN address and hold it until the next reboot.

Inspect WAN Status, Cables, and Router Indicators

Router indicator colors follow a consistent convention across most manufacturers: green, blue, or white for normal operation, orange or amber for limited connectivity, and red or unlit for no connection at all. A dark globe icon with a healthy Wi-Fi icon is the exact signature of this problem.

Reseat the Ethernet cable between the modem’s LAN port and the router’s WAN port, then check the router’s admin page for the WAN status. An address of 0.0.0.0 or 169.254.x.x on the WAN interface means the router never received an ISP lease.

When to Check for an Outage or Contact the ISP

Escalate once wired and wireless both fail, the modem shows no sync, and a full power cycle changed nothing. Check the ISP’s status page from cellular data, and look for scheduled downtime notices before assuming hardware failure.

Have two details ready: the modem’s light pattern and whether the WAN interface received an address. Those two facts skip most of the scripted first-tier questions.

How to Repair a Single Offline Device

One device offline while everything else works points to a stale saved profile, a bad DHCP lease, a driver fault, or a VPN and firewall conflict. Fix them in that order, since each step takes less time than the one after it.

Forget the Network and Reconnect From a Clean Profile

Saved profiles accumulate stale security parameters, old proxy entries, and outdated band preferences. Removing the profile forces a fresh negotiation.

On Windows 11 and Windows 10, open Settings > Network & internet > Wi-Fi > Manage known networks, select the network, and choose Forget. Reconnect with the password. On iOS and Android, tap the network name and pick Forget This Network.

If that fails, disable and re-enable Wi-Fi entirely, then toggle airplane mode once to reset the radio stack.

Renew DHCP Addressing and Verify the Default Gateway

An address starting with 169.254 means DHCP never answered and Windows self-assigned. Open Command Prompt as administrator:

ipconfig /release
ipconfig /renew
ipconfig /all

Confirm the IPv4 address matches your router’s subnet and that the default gateway is the router’s LAN address. Ping that gateway. No reply means the problem is between your wireless adapter and the router, not upstream.

Check Drivers, Services, VPNs, and Firewalls on Windows

Disconnect any VPN client fully, then confirm its virtual adapter is not still holding the default route. Third-party firewalls with a “block all” state after an update produce this symptom on one machine only.

Open Device Manager, expand Network adapters, and update or roll back the Wi-Fi driver. In services.msc, verify WLAN AutoConfig is running and set to Automatic. Disabling fast startup in Power Options resolves the cases where the adapter never fully initializes after shutdown. Run the built-in network troubleshooter last; it repairs the simple cases and names the failing component in the rest.

Use the Right Recovery Steps on macOS, Android, and iPhone

On macOS, remove the network under Wi-Fi settings, then delete mDNSResponder-related caches by restarting. Renewing the DHCP lease sits under Advanced > TCP/IP.

On Android, use Reset network settings from System > Reset options. On iPhone, the equivalent network reset lives under General > Transfer or Reset iPhone > Reset > Reset Network Settings. Both clear saved Wi-Fi passwords, so have credentials ready.

How to Diagnose DNS and TCP/IP Configuration Problems

DNS failures are the single most common cause of a device that pings by IP but loads nothing in a browser. The layer is easy to confirm, easy to flush, and easy to repoint at a public resolver.

Recognize When DNS Is the Only Broken Layer

The signature is exact: ping 8.8.8.8 succeeds, ping google.com returns “could not find host.” Your routing works and your gateway works. Name resolution alone is broken.

A second tell is browsers failing while a VPN, a game client, or an app with hardcoded IPs keeps running. Deeper name resolution faults are covered in our guide to troubleshoot DNS issues.

Flush Stale DNS Cache Entries

A poisoned or stale DNS cache holds expired records that point nowhere. On Windows, open Command Prompt as administrator and run:

ipconfig /flushdns

Follow with netsh winsock reset and netsh int ip reset when the flush alone does not restore access, then reboot. On macOS, restart mDNSResponder with sudo killall -HUP mDNSResponder.

Verify DHCP, IPv4, and DNS Server Settings

Open Network Connections, right-click the adapter, choose Properties, then Internet Protocol Version 4 (TCP/IPv4). In most home setups, both address and DNS should be set to obtain automatically.

Manually specifying a public resolver isolates a broken ISP DNS server:

Apply, then flush the cache again before testing. If pages load with the public resolver, the ISP’s DNS was the fault.

Use IPv6 Changes Only as a Controlled Test

Disabling Internet Protocol Version 6 (TCP/IPv6) occasionally clears connectivity on networks advertising IPv6 without working upstream routing. Treat it as a diagnostic step, not a permanent configuration.

Re-enable IPv6 once you identify the real cause. Leaving it off breaks IPv6-only services and masks the underlying router misconfiguration you still need to fix.

Test the Path Before Changing More Settings

Wi-Fi connected but no internet access resolves fastest when you identify the broken layer before touching a setting. One device offline means fix that device’s profile, DHCP lease, or driver. Every device offline means power-cycle the modem first, then the router, and read the WAN status.

The two tests that carry the most weight take under a minute: swap to Ethernet, and ping a raw IP alongside a domain name. Everything after that follows from what those two results tell you.

Once connectivity returns, verify the path from outside your own network. The free network tools at PacketTools run DNS lookups, ping, traceroute, and SSL checks in the browser with no sign-in, no tracking, and no logging of IPs or query data. Confirming that your records resolve correctly with a DNS propagation checker rules out the resolver layer for good, and a quick what is my ip check confirms your public address changed as expected after a modem reboot.