Use Netforge’s Wi-Fi health check alongside three speed tests

Run Netforge’s guided health check on the computer experiencing trouble, then repeat it over Ethernet and on Wi-Fi near the router. That comparison is more useful than a single scan: it helps separate a local wireless problem from DNS or internet-path trouble.

The health check is connectivity triage, not proof of your Wi-Fi speed. Purple documents checks for active adapters, gateway latency, DNS resolution and HTTP egress timing—not a download/upload throughput measurement within the guided check. Use a separate speed test alongside it before deciding to upgrade your plan or router.

What Netforge checks

As of October 26, 2026, Purple lists Netforge as a free desktop app for Windows, macOS and Linux, with no account required. Its guided health check includes known-good baseline comparisons and PDF report export.

Here is how to use the documented checks:

Check	What it helps you investigate	What it cannot establish alone
Active adapters	Whether the expected network interface is active	Whether traffic is taking the route you intended
Gateway latency	Response time to your local gateway, usually the router at home	Whether a spike comes from Wi-Fi, device load or the gateway’s handling of probes
DNS resolution	Whether name lookups succeed and how their timing changes	Your available download speed
HTTP egress timing	Whether an external web request succeeds and how long it takes	Whether a delay belongs to the ISP, route or remote service

Purple describes Netforge as offline-first, with local processing. That does not mean every diagnostic works without connectivity: external HTTP requests and path probes still need to communicate with their network targets. Treat “offline-first” as a description of the app’s local operation, not a promise that internet checks work offline.

Run a repeatable health check

1. Record the conditions

Use the same computer throughout. Note the time, room, Wi-Fi band, connected access point or mesh node, and whether a VPN is active. Record the device’s Wi-Fi standard if you know it.

Pause backups, downloads and streams for the initial comparison. If your problem happens only during busy periods, test that condition separately afterward. Keep VPN status consistent; a VPN-on result describes a different network path from a VPN-off result.

2. Capture three connection conditions

Run the guided health check under each condition, preferably two or three times to distinguish persistent changes from one-off spikes:

1. Ethernet to the router: switch off Wi-Fi temporarily so the comparison is clearly wired. Check that the Ethernet adapter and port can support your plan’s speed.
2. Wi-Fi near the router: disconnect Ethernet and test in the same room with no substantial obstruction. As a repeatable starting point, TP-Link recommends six to nine feet between router and device for its wireless troubleshooting tests.
3. Wi-Fi in the problem location: repeat at the desk, bedroom or meeting room where the symptoms occur.

Save a known-good baseline while the connection is behaving normally. Label the connection conditions in your notes so you do not mistake a change from Ethernet to distant Wi-Fi for a new fault.

3. Add a speed test at each location

Record download and upload in Mbps, plus idle latency, loaded latency and jitter in milliseconds where available. Keep the same test service and server selection throughout; server location and test methodology can materially change results.

Loaded latency measures response time while traffic is being transferred. Jitter measures variation between latency samples. These can reveal a connection that downloads quickly but becomes unpleasant for calls or gaming when busy. Cloudflare’s methodology explains these measurements, while noting that its test assesses connection quality rather than maximum throughput.

Our three-test Wi-Fi speed-test guide covers the comparison in more detail.

Read the pattern, not just the warning

• Wired and nearby Wi-Fi are stable, but the problem room deteriorates: investigate coverage, interference or the mesh connection before buying a faster internet plan. As an illustrative comparison, 400 Mbps near the router and 40 Mbps at the desk points toward the wireless path to that desk—not proof that the ISP delivers only 40 Mbps.
• Wired works well, but nearby Wi-Fi repeatedly struggles: check the connected band, router settings and device. Repeat with another capable device before blaming the router. See why phone Wi-Fi can be slower than laptop Wi-Fi.
• Gateway response stays stable, but DNS repeatedly fails: investigate name resolution. Confirm with repeated lookups before changing DNS settings; one slow lookup is not enough.
• DNS succeeds, but HTTP timing worsens on both wired and wireless: investigate the internet path or target service. Compare another destination before attributing the problem to your provider.
• Quiet tests look good, but loaded latency rises sharply during transfers: investigate congestion and queueing. Repeat over Ethernet to check whether the issue is specific to Wi-Fi.

Use path analysis carefully—and export useful evidence

For intermittent internet-path trouble, Purple says Netforge provides continuous hop-by-hop statistics, a latency timeline and packet-loss percentages, built on the Trippy engine, which combines traceroute and ping.

A hop showing loss is not automatically a broken router. Intermediate devices may ignore or deprioritize diagnostic replies while forwarding normal traffic. Netskope explains this traceroute limitation. Look for repeated changes that also affect later hops or a responding destination and coincide with the actual symptom; even then, the trace is evidence to investigate, not a verdict.

Export the health report with your timestamps, connection conditions and separate speed-test results. Review it for network details before sharing. A useful support ticket says which tests failed, whether Ethernet was affected, and what changed from the known-good baseline—not simply “Wi-Fi is slow.”