You can compare IPv4 and IPv6 reachability in Windows without disabling IPv6. Use family-specific probes to the same named destination, record which address is selected and keep the application’s real behavior alongside the result. The comparison gathers evidence; it does not establish that one protocol is universally faster.
This is most useful when only certain services fail or a support team asks for family-specific observations. If every device has lost internet access, start with the shared connection instead of assuming the problem is IPv6.
Keep the network configuration intact
Microsoft’s IPv6 configuration guidance recommends against broadly disabling IPv6 components or unbinding IPv6 from interfaces. This diagnostic does not require a registry edit, adapter reset or router-wide protocol change.
Leaving the configuration intact also makes the experiment easier to interpret. If you change address-family preferences, DNS servers, the VPN and Wi-Fi connection together, you cannot tell which change affected the service.
Choose one destination and one symptom
Use a hostname relevant to the problem or a test host you own or are permitted to probe. It must have the appropriate address records for the family you want to test. Not every service publishes both IPv4 and IPv6 destinations, and not every destination answers ICMP echo requests.
Record what the application actually does: a page times out, an app cannot sign in or a transfer stops after starting. “Internet is broken” loses the detail that helps compare probe evidence with a real task.
Do not substitute a public DNS resolver for the failing website halfway through the pair. That changes the destination and the question. If you need a separate known-working comparison, run it as a second pair and label it separately. This preserves the difference between a service-specific issue and a pattern repeated across suitable destinations.
Run a small paired comparison
Microsoft’s Ping command reference documents IPv4 and IPv6 selection, reply timing and name-resolution behavior. On Windows, use a small count rather than an indefinitely running test:
ping /4 /n 4 HOSTNAME
ping /6 /n 4 HOSTNAMEReplace HOSTNAME with the same actual hostname in both commands. The word is a placeholder, not a destination to copy unchanged. The four-query count is a bounded first observation, not a statistical reliability requirement.
- Record the command and the address Windows displays for each family.
- Record whether name resolution failed, replies arrived, or requests timed out. These are different outcomes.
- Keep the reply timings and any missing replies, without replacing an unavailable value with zero.
- Try the relevant application under the same connection conditions.
- Repeat at another suitable time if the issue is intermittent. Preserve each run separately instead of combining the best pieces.
The two families normally select different destination addresses and can take different routes. Even with the same hostname, you may be comparing different service infrastructure as well as different protocols. That limits how confidently you can attribute a timing difference to IPv4 or IPv6 itself.
Interpret the result by failure stage
| Observation | Next question |
|---|---|
| One family cannot resolve the hostname | Does that hostname provide the relevant address record, and is name resolution working? |
| An address is displayed but probes time out | Does the target answer those probes, and does the actual application work? |
| Both families reply but the app still fails | Investigate the application’s connection, authentication or service context; echo replies do not test every application function. |
| A problem repeats for one family across suitable destinations | Preserve the evidence for the network owner or provider rather than making a blanket protocol change. |
A successful echo response establishes a limited reachability observation. It does not test HTTPS, a game session or every packet size and traffic pattern. A timeout is also ambiguous when the service intentionally does not answer those probes.
Avoid confusing this with an internet speed comparison
Ping timing is not download throughput. A browser speed test performs HTTP transfers to its documented service and may not choose the same destination or family as your command. Read how the measurements work before comparing the numbers.
Similarly, a browser may successfully reach a service even though one explicit family-specific command fails. The application can have different connection behavior from the probe. Record that difference rather than declaring the test invalid or the application proof that both families work equally.
For broad Windows connectivity symptoms, use the limited-connectivity guide or the Slow Internet Troubleshooter. This paired test answers a narrower question about address-family evidence, not every possible reason an app is slow.
Make an escalation record
Keep the Windows version, adapter connection type, VPN state, test times, commands, resolved addresses and outcomes. Include whether another device on the same network behaves similarly and whether the real application succeeds or fails.
When sharing publicly, remove private identifiers while retaining enough context to explain the comparison. A provider or network administrator can use a repeatable family-specific record to investigate routing or configuration without you first making disruptive registry or network-wide changes.