skip to content
Open Search
Network Problems (Fast Fixes)
These are the issues people search for most when “the internet is broken” — DNS failures, timeouts, high ping, blocked ports,
traceroute weirdness, and ISP outages. Pick the symptom, run the linked tool, and move on.
Use responsibly: only test systems you own or are authorized to troubleshoot.
Website won’t load: DNS not resolving (NXDOMAIN / SERVFAIL) DNS_PROBE_FINISHED_NXDOMAIN ERR_NAME_NOT_RESOLVED domain not resolving SERVFAIL
If a name can’t resolve, nothing else matters. Verify A/AAAA, NS, SOA, and TXT (SPF/DKIM) in one pass.
Do this (in order) Run a full DNS lookup (A/AAAA/CNAME/MX/NS/SOA/TXT). Confirm the authoritative NS are correct and consistent. Check for typos, missing records, or a bad CNAME chain. If only some locations fail: it’s likely propagation/caching or split-horizon DNS. High ping, jitter, or “lag spikes” high ping lag spikes jitter slow internet but speedtest is fine
Latency problems are usually routing, bufferbloat/congestion, or a bad hop. Measure from browser + edge to separate you vs the path.
Do this (in order) Use Ping Monitor to compare Browser vs Edge latency. If Browser is bad but Edge is fine: local Wi-Fi/LAN/device queueing. If both are bad: upstream congestion, routing change, or ISP issue. Look for jitter (variance), not just average RTT. Packet loss / timeouts (ERR_CONNECTION_TIMED_OUT) packet loss timeouts ERR_CONNECTION_TIMED_OUT request timed out
Timeouts happen when packets drop or a firewall/rate-limit blocks the flow. Confirm whether it’s the path, the port, or the destination.
Do this (in order) Run Ping Monitor and watch loss %, not just RTT. Run Traceroute to see where loss starts (don’t panic at ICMP-blocking hops). If the service is reachable from some networks but not yours: suspect ISP routing or filtering. Confirm the destination port is actually open. Port is blocked or closed (SSH/HTTPS/RDP/etc.) port closed connection refused port 443 closed ssh timeout
A host can be up while a service is down. Validate the port, grab a banner, and confirm TLS certificate when relevant.
Do this (in order) Scan the exact port(s) you expect (22/443/3389/etc.). If open: banner/TLS details often confirm you hit the right service. If closed: service down or host firewall rejecting. If timeout: upstream firewall, security group, route, or ISP filtering. Traceroute shows * * * or stops mid-path traceroute timeout traceroute stops stars in traceroute * * *
Some routers drop ICMP/UDP probes by design. Focus on where latency jumps or where the destination becomes unreachable.
Do this (in order) Run Traceroute Map and look for the first hop where RTT jumps. Ignore isolated “*” hops if later hops respond normally. If the trace never reaches the destination: routing, filtering, or outage. Correlate with Ping Monitor (loss/jitter) for confidence. Suspected ISP outage or routing incident internet outage near me isp outage routing issue BGP issue
Before you reboot everything, verify whether the problem is regional (outage signals) and identify the ISP/ASN to escalate with real data.
Do this (in order) Use Outage Detector to check reachability patterns + live anomaly signals. Open ISP Support Insights to collect ASN, RDAP contacts, and peering context. If multiple major targets fail: likely ISP/backhaul issue. If only one service fails: destination/CDN or a specific route. FAQ What’s the fastest way to diagnose “site is down”? Start with DNS Lookup (records + NS/SOA). If DNS is fine, run Ping Monitor for loss/jitter, then Port Scanner for the service port, and Traceroute for path-level clues.
Why does traceroute show * * * but the site still works? Many routers deprioritize or block traceroute probes (ICMP/UDP). If later hops respond and the destination is reachable, the * hops usually aren’t the issue.
How do I tell if it’s my Wi-Fi or my ISP? Compare Browser vs Edge latency in Ping Monitor. If Browser is worse, it’s local (Wi-Fi/LAN/device). If both are bad, it’s upstream (ISP/path).
