Answers to what actually comes up. If yours isn't here, email [email protected] and a human will reply.
When a device sends more data than the line can carry, the excess waits in a buffer. If that buffer is oversized, time-sensitive traffic — a video call, a game — gets stuck behind a queue of bulk transfer. Your speed test still looks great, but everything feels broken whenever the connection is busy.
The app grades it A+ through F based on how far latency climbs under load. Anything at C or worse is worth fixing, and the fix is usually free: turn on SQM (Smart Queue Management), fq_codel or CAKE in your router. Some routers label it Adaptive QoS or bufferbloat control. If yours has none, capping QoS bandwidth at roughly 90% of measured speed gets most of the benefit.
Look at jitter and p95 rather than the headline number. Jitter is how much latency wobbles between measurements; p95 is your bad-moment latency — what 5% of your traffic experiences. Voice and video tolerate slow far better than they tolerate inconsistent. Jitter above roughly 30 ms is where calls start breaking up.
Two routers on your network are both routing — typically an ISP gateway plus your own router behind it. It breaks port forwarding, gives consoles "Strict NAT", and can interfere with VPNs. Fix it by putting the ISP box in bridge mode or IP passthrough, or setting your own router to access-point mode, so only one device routes.
Carrier-grade NAT means your ISP shares one public address among many customers. Nothing inbound can reach you, so port forwarding and self-hosting are impossible no matter how you configure things. Remote access has to go through a relay such as Tailscale or Cloudflare Tunnel — or ask your ISP about a static IP.
That is the app doing its job: it measured latency to your own router (fast) and to the wider internet (slow), placing the problem past your equipment. Rebooting your router will not help. Export the report from the Diagnose panel and take it to your ISP — timestamped evidence gets a very different response than "the internet feels slow".
Apple restricts what any App Store app can see. Rather than fake these, Network Hamster does the most useful thing that is genuinely possible and tells you where the line is.
Wireless Health measures the Wi-Fi hop, not radio signal. iOS provides no API for RSSI, noise floor or channel scanning, so no App Store app can report them. Instead the app burst-pings your router and measures latency, jitter and loss across the wireless link, then compares that against internet jitter — which tells you whether instability is being created on the air or upstream of your router. In practice that is the answer you actually need.
| Commonly asked for | Why not | What the app does instead |
|---|---|---|
| Wi-Fi signal strength (dBm) | No iOS API exists | Measures real latency and loss across the wireless hop |
| Wi-Fi channel scanning | Requires an entitlement Apple does not grant | — |
| Detecting deauth packets | iOS has no monitor mode; raw 802.11 frames are unavailable | Detects the repeated forced disconnects a deauth flood causes |
| Which cell tower I'm on | Apple blocks tower and cell ID | Shows the radio type (LTE / 5G) and maps measured quality by location |
| Sniffing all network traffic | The app sandbox forbids it | Watches inbound traffic arriving at your own device |
Scroll to the bottom and turn on Advanced tools. That reveals Monitor Mode, Wireless Health, Ping Lab, Buffer Probe, MTR, DNS lookup, the event log and network info. The main screen stays deliberately simple for everyone else.
Yes — start a Monitor Mode session and the screen stays awake so measurements continue. Plug the phone in. iOS suspends apps in the background, so the app does need to stay in the foreground; that is an operating-system rule, not a design choice.
Run Diagnose, then tap the share icon in that panel. You get a plain-text report with latency per server, jitter, packet loss, bufferbloat grade, traceroute and a timestamped event log. Monitor Mode additionally exports raw CSV for longer windows.
Normal. Many routers are configured not to reply to traceroute probes, or to rate-limit them. A hop showing * is usually silent rather than broken — what matters is whether latency climbs and stays high from a particular hop onward.
Different servers, different methods, different moments. This app is less interested in the biggest achievable number than in consistency, latency under load, and where a problem originates. If you want to compare, compare its results against its own over time.
General help: [email protected]
Privacy questions: [email protected]
Bugs and feature requests are genuinely welcome — include your iOS version and
what you were doing.
Network Hamster is built and maintained by Harborview IT LLC in McKinney, Texas.