When Chrome reports “connection dropped” on sites like x.com or github.com, the instinct is to blame the browser. In practice, the problem is almost always a network‑level issue that Chrome is simply surfacing. This post documents a real debugging session on a CachyOS (Arch‑based) laptop and the systematic approach to isolate the root cause.

🗺️ Diagnostic Flow

Before diving into commands, here’s the decision tree we followed:

Architecture Diagram

1. Verify DNS Configuration

The first step is confirming which DNS servers the system actually uses.

cat /etc/resolv.conf

On a systemd‑based distro (like CachyOS), this typically shows:

nameserver 127.0.0.53

That’s the systemd‑resolved stub — it forwards queries upstream. To see the real upstream servers:

systemd-resolve --status | grep "DNS Servers"

Our output:

DNS Servers: 8.8.8.8#dns.google 8.8.4.4#dns.google
Fallback DNS Servers: 9.9.9.9#dns.quad9.net

Verdict: Google Public DNS is the primary resolver. DNS is working correctly — both hostnames resolved to valid IPs.

2. Ping Test

ping -c 5 x.com
# PING x.com (162.159.140.229) — 5 packets transmitted, 0 received, 100% packet loss

ping -c 5 github.com
# PING github.com (20.205.243.166) — 5 packets transmitted, 0 received, 100% packet loss

Verdict: Both hosts are unreachable at the network layer. Since DNS resolved successfully, the problem is not DNS — it’s somewhere in the packet path between our machine and the destination.

3. Traceroute — Where Do Packets Stop?

traceroute -n x.com
traceroute -n github.com

A typical output when the problem is local:

1  192.168.8.1    1.2 ms   ← your router
2  * * *                   ← packets never reach the ISP
3  * * *

If the trace stops at your gateway (hop 1 or 2), the issue is local — firewall, NAT misconfiguration, or router problem.

Note: On CachyOS, traceroute may not be installed by default. Install it with paru -S traceroute or use the pre‑installed tracepath -n x.com as an alternative.

4. Firewall / iptables Inspection

sudo iptables -L -v -n | grep -E "OUTPUT|REJECT|DROP"

Look for rules that DROP or REJECT outbound traffic to the destination IPs (162.159.140.229, 20.205.243.166) or to ports 80/443.

5. Test From Another Network

The simplest isolation test: tether a phone hotspot and retry:

ping -c 3 x.com
ping -c 3 github.com

If it works on the hotspot, the problem is specific to your current LAN or ISP.

6. Common Fixes

Root Cause Fix
Router / modem glitch Power‑cycle: unplug → wait 30s → plug back in
Local firewall rule Remove or adjust the offending iptables / nftables rule
ISP blocking Contact ISP with traceroute evidence
VPN / proxy interference Disconnect VPN, disable proxy, retest
Stale DNS cache sudo systemd-resolve --flush-caches

Key Takeaway

Network connectivity problems often masquerade as browser bugs. By systematically checking DNS → ping → traceroute → firewall you can pinpoint the failure layer in minutes and either fix it locally or hand concrete evidence to your ISP.

Architecture Diagram

In our case the failure was at Layer 3 (ICMP packets never reached the destination), which means Chrome’s “connection dropped” error was just the messenger — not the cause.

Related: CachyOS Mirror Timer Fix