Change one variable. Record every condition.

Step 1

Describe the symptom before testing.

Record whether the problem is consistently high ping, short spikes, packet loss or disconnects, or desync while the displayed ping appears normal. These symptoms have different likely causes.

Step 2

Establish a baseline.

Keep the same device, connection method, game region and party host. Record three baseline sessions and three comparison sessions instead of selecting the best run. Note household uploads, downloads and any known service incident. Three runs are a practical minimum for this worksheet, not proof of statistical significance.

• Record three baseline sessions under the same game server, device and connection conditions.
• For the three comparison sessions, change only one variable and state that change.
• Keep the time window, visible symptom, ping range and loss or spike observations with the raw notes. Repeat on another day before treating the finding as durable.

Step 3

Rule out causes a route cannot fix.

• Compare Ethernet with Wi-Fi where practical.
• Pause local uploads, cloud sync and downloads.
• Check the game publisher's official status or support source.
• Separate frame-rate or input delay from network delay.
• Repeat at another time before attributing a change to a tool.

Step 4

Publish the record, not a headline number.

A publishable result states the test date, region, ISP context, connection method, game target, sample count and all material limitations. It reports the typical result rather than the single lowest observation. Without that record, the page remains a method or troubleshooting guide—not a product verdict.

Download the blank CSV test log or use the local diagnosis tool to decide what to check first.

Windows walkthrough

Compare the local link with a public control.

This is a small ICMP check for a Windows PC, not a game-server test. It changes no network settings and does not require administrator access. Keep the original game symptom and current in-game readings beside these observations.

1. Identify the active connection. Open Command Prompt and run ipconfig. Find the Default Gateway under the Ethernet or Wi-Fi adapter actually in use. With a VPN or several adapters, the route can be ambiguous; record that limitation rather than selecting a random address. Keep this output private.
2. Measure the local gateway. Run ping /n 30 YOUR_GATEWAY, replacing YOUR_GATEWAY with that address. Record packets sent, received and lost, plus the minimum, maximum and average round-trip times. Some routers do not answer ICMP; silence alone does not prove a broken local connection.
3. Measure a public control. Run ping /n 30 1.1.1.1. This asks Cloudflare's public resolver to answer ICMP. It does not test the game's server, DNS lookup speed, or lost game packets. A network that filters these replies needs another permitted destination or a different check.
4. Compare one changed condition. Repeat both commands after pausing an upload, or after switching from Wi-Fi to Ethernet. Change only one condition. Retain three rounds per condition with timestamps; do not keep only the best average.

How to interpret the pair

Gateway and public control both worsen: investigate the local link or competing home traffic first. A wired comparison that repeatedly removes the symptom strengthens that lead; it still does not identify a faulty device by itself.

Gateway stays stable; public control worsens: the wider path or its destination is a lead. Repeat at another time and compare a second permitted public destination. A single host can deprioritize ICMP, and a public control can take a different path from the game.

Both stay stable; only the game feels bad: return to game region, service status, party context and frame time. Do not buy a router or routing subscription on the strength of a clean public ping alone.

Do not blame every asterisk in a route report

If support asks for a route report, pathping /n DESTINATION can collect longer per-hop observations. Use only the destination supplied by support, allow it to finish, and redact identifying addresses before sharing. Loss at an intermediate hop without corresponding loss farther along can reflect that router limiting its own replies. It does not establish that the router drops forwarded game traffic.

Command behavior and interpretation sources, checked September 22, 2026: Microsoft ipconfig, Microsoft ping, and Microsoft pathping.

Reading our retained data

What the August 19 web-edge record actually tells us.

We retained one short Windows network collection on August 19, 2026: a NordLynx tunnel over Ethernet, with an observed Melbourne exit. Each destination had 30 ICMP samples and 15 TLS handshakes across three rounds. The game-related destinations were official support or status web edges, not match servers. The four game guides refer to this same collection.

The Cloudflare public control had an ICMP median of 197.5 ms; Google's control had 197 ms. Both returned all 30 replies. This establishes a similar typical delay to those two public controls within that short window. It does not tell us which hop caused the delay, what the household ISP was behind the tunnel, or how a game session performed.

Cloudflare's TLS median was 412.4 ms. TLS connection setup and an ICMP echo measure different operations, so subtracting these numbers would not produce a gaming-latency penalty. There was no direct-ISP baseline and no alternate-route comparison. The record cannot establish whether NordLynx helped or hurt.

Even 30 replies out of 30 do not prove a route has zero loss over a longer session. Short collections can miss rare bursts, and a web edge can respond differently from a match server. The useful conclusion is the bounded observation above, not a product ranking.

Audit the numbers directly: raw per-sample CSV and collection summary and environment. The original collection date remains unchanged.

Browser test interpretation

A slow request is a clue, not a located fault.

The optional browser-path check makes HTTPS requests to Fix My Ping's Cloudflare endpoint at rest and during limited generated traffic. Browser scheduling, the access network, a VPN, Internet routing and the serving edge can all affect the timing. It cannot observe the individual hops, send game packets, or identify the physical location of the bottleneck.

A failed HTTP request is not an estimate of lost game packets. A timed-out, interrupted or incomplete run produces no comparison. Keep the tab active and use the symptom questions or the Windows check above when the endpoint cannot be measured reliably from your network. Do not increase traffic repeatedly just to force a result.

For a completed before-and-after comparison, keep device, connection context and serving endpoint consistent. Confirm that the original symptom improves inside the game. If only the browser number improves, record that narrower result.