Connected but nothing loads: nine checks in order

The client says connected, latency looks green, and the browser still will not load anything. Nine causes ordered by frequency, with a clear test for each.

By MaoUpdated 2026-08-265 min read

"The client says connected, the latency is green, and the browser loads nothing."

The trouble with this one is that the word "connected" misleads you into looking in the wrong place.

Ordered by how often each turns out to be the cause.

1. Is the system proxy on?

The most common single cause.

A running client and proxied traffic are two different things.

Client	Where
Clash Verge Rev	Settings → System Proxy
v2rayN	Tray right-click → Set system proxy
Shadowrocket	Main toggle
sing-box	Main toggle

Test: load any IP lookup page.

Shows the node's region → the proxy is working
Shows your own address → this is your problem

2. Is the mode set to Direct?

Clash-family clients have Rule / Global / Direct.

On Direct, the client runs and routes nothing. Rule is the correct everyday setting.

3. Is the node genuinely alive?

The displayed latency may be cached.

Many clients show the last test result, and the node may have died since.

Re-run the latency test. Do not trust the number already on screen.

Everything times out → the whole list is dead; refresh or replace the subscription
Some pass → switch to one that does

4. DNS

Symptom: some sites load, others do not at all. Or "cannot resolve the server's DNS address".

In a Clash-family client, confirm the DNS block:

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query

If local network devices — a NAS, a printer, a router page — became unreachable, fake-ip has captured them too:

  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "your-nas-hostname"

Flush the local cache afterwards:

ipconfig /flushdns                                          # Windows
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder   # macOS

5. Browser works, other software does not

Symptom: Chrome is fine, Steam crawls, games cannot reach servers, curl times out.

Cause: those programs ignore the system proxy and leave via the physical adapter.

Fix: enable TUN mode, which creates a virtual adapter and captures everything.

Caveats: administrator rights, possible antivirus conflicts, occasional route conflicts on machines running virtualisation. Details in Clash Verge Rev setup.

Without TUN, configure the tools individually:

git config --global http.proxy http://127.0.0.1:7890

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"

Match the port to your client — Clash defaults to 7890, v2rayN to 10809.

6. Clock skew

Symptom: every vmess node fails while Trojan and SS nodes work.

Cause: vmess is time-sensitive. About two minutes of difference from the server and the handshake fails.

Check: automatic time synchronisation is enabled. On Windows: Settings → Time & language → Date & time → Sync now.

Sneaky, because the error only ever says the connection failed.

7. Port conflict

Symptom: the client errors on launch, or reports connected with no traffic at all.

Check:

netstat -ano | findstr :7890     # Windows
lsof -i :7890                    # macOS / Linux

Any output means something else holds the port. Change it in client settings, and update every other program where you entered the old one.

8. Rules sending foreign traffic direct

Check: open the Connections view, load a foreign site, and read which rule matched.

It should name a node. If it says DIRECT, the rules classified it as local.

Usual cause: rule order. Rules match top to bottom and stop at the first hit, so a broad GEOIP,CN,DIRECT placed too early swallows things it should not.

# wrong
rules:
  - GEOIP,CN,DIRECT              # matches first
  - DOMAIN-SUFFIX,xxx.com,Proxy  # never reached

# right
rules:
  - DOMAIN-SUFFIX,xxx.com,Proxy  # specific first
  - GEOIP,CN,DIRECT
  - MATCH,Fallback

9. Environment

Everything above ruled out, check these:

Antivirus or firewall. Disable temporarily to identify it, then allow-list the client.

Corporate or campus network restrictions. Test on a phone hotspot. If the hotspot works, the network is the problem.

IPv6 leaking around the proxy. Set ipv6: false in the client, or disable IPv6 temporarily.

Browser extensions. Proxy-management extensions fight with the client. Disable and retest.

Browser cache. Clear it, especially after changing nodes.

The shortcut that saves half the work

Checklist

[ ] System proxy on?
[ ] Mode is Rule, not Direct?
[ ] Re-tested latency — are nodes actually alive?
[ ] Does an IP lookup show the node's region?
[ ] All software affected, or only some? (only some → TUN)
[ ] Clock synced?
[ ] Port free?
[ ] Do foreign requests match a node or DIRECT?
[ ] Antivirus disabled as a test?
[ ] Phone hotspot as a test?

If all ten pass and it still fails, import the same nodes into a different client. Working there means your client configuration is the issue.

Questions people keep asking

The client says connected. Why is nothing loading?

Connected" only means the client is running; it does not mean your traffic is going through it. The three usual causes are the system proxy being off, the mode being set to Direct, and the node actually being dead while the client displays a cached latency figure.

The browser works but games and Steam do not.

Those programs do not read the system proxy setting and go straight out of the physical adapter. Browsers do read it, which is why they work. The fix is TUN mode, which captures traffic at the adapter level instead.

Local sites load, foreign ones do not.

That means your routing rules are working correctly for local traffic, and the proxy side is broken. Concentrate on whether the node is genuinely alive and on your DNS configuration.

I changed nodes and it still fails.

If every node fails, the problem is almost certainly local rather than with the nodes — real blocking is patchy, not uniform. Work through checks 6 to 9.