Problem: Only one specific website won't open (everything else works) — from curl timeout to layer-by-layer diagnosis —— Trove problem library

What you will run into

On the same machine, https://www.google.com/ (or Baidu, GitHub) opens fine, but one particular website never loads: the browser spins and finally reports "connection timed out" or "this site can't be reached".

Most people's first reaction is "the website is down" — but if only one specific domain fails, your network clearly reaches most sites, so the fault usually sits in one layer of the path from you to that site: DNS resolution, TCP connection, TLS handshake, HTTP response, or a local proxy rule.

Why this happens

Opening an HTTPS site passes at least four layers: DNS resolution (domain -> IP) -> TCP connection (three-way handshake) -> TLS handshake (certificate/key negotiation) -> HTTP request (content).

If any layer breaks, the browser only shows a vague "can't open".

The real causes vary widely:

• DNS layer: your DNS server times out for that domain or returns a bad record (cache poisoning, upstream failure, filtering rules);
• TCP layer: the resolved IP is unreachable (blocked, blackholed, CDN node down) or the port is filtered;
• TLS/HTTP layer: certificate chain issues, SNI filtering, server-side rejection - rarer but possible;
• Proxy layer: your system proxy / Clash rules route that domain to an unreachable node.

Key insight: "won't open" is only a symptom — it does not mean "site is down" or "blocked".

Use the command line to pin the fault to one layer first, then decide the fix: switching DNS, switching proxy nodes, or changing the network path are completely different directions.

"Only one specific domain fails" is valuable because it gives you a natural control: your egress works (other HTTPS sites return 200), so suspicion collapses to the path from you to that domain.

curl's -v output shows exactly where it stalls: stuck after Trying <ip>... = TCP layer; stuck after Connected to <ip> = TLS layer; getting a response header = server layer is fine.

nslookup <domain> <dns-server> asks a specific server instead of the system one, and curl --resolve skips DNS entirely by pinning an IP — those two commands split "resolution" from "connection", which is the whole secret of layer-by-layer diagnosis.

In the source case (public write-up, 2026-08-17), the failing machine's default DNS could not resolve the target domain in time; switching to 1.1.1.1/8.8.8.8 immediately returned the CDN addresses — the textbook ending of a DNS-layer fault.

Step by step

1. Confirm scope: only this one domain fails — Required

curl -sI -m 8 https://www.baidu.com -o /dev/null -w "baseline http=%{http_code}\n"
curl -sI -m 8 https://target-domain -o /dev/null -w "target  http=%{http_code}\n"

Baseline 200 and target timeout/failure = continue with this article. If both fail, check the network itself first (gateway, proxy, DNS all down); this article does not apply.

2. DNS layer: does the domain resolve? — Required

getent ahosts target-domain | head -1
# Expected: <IP> STREAM target-domain
# No output (exit != 0) = resolution failure -> DNS layer; jump to step 5 and switch DNS

Having an IP does not rule out DNS — the record itself may be bad (poisoned cache, stale CDN node). Continue to step 3 to verify whether that IP is actually reachable.

3. TCP/path layer: is the direct connection to this IP alive? — Required

curl -v -I -m 10 https://target-domain 2>&1 | tee /tmp/curl-v.txt
# No progress after Trying <ip>... = TCP-layer failure (network path / unreachable IP)
# Stuck after Connected to <ip> = TLS layer (rare; inspect certificate and SNI)

4. Bypass DNS: fully separate resolution from connection — Required

IP=$(getent ahosts target-domain | head -1 | awk '{print $1}')
curl -sI -m 10 --resolve target-domain:443:$IP https://target-domain -o /dev/null -w "bypass http=%{http_code}\n"

• Bypass connects (http=200/301/403 all mean reachable) -> DNS layer is broken: the resolution chain hands out a wrong/unstable IP. Fix: step 5.
• Bypass still times out -> network path is broken: resolution is fine, but the route to that IP is not (blocked/blackholed/CDN node down). Switching DNS will not help; see step 6.

5. DNS layer broken: verify with public DNS — the fix

# Where dig exists, compare directly; otherwise switch the system DNS and retry step 1
dig @223.5.5.5 target-domain +short    # Aliyun public DNS
dig @1.1.1.1   target-domain +short     # Cloudflare
dig @8.8.8.8   target-domain +short     # Google (UDP 53 is often unreachable on CN networks; a timeout here is not a conclusion)

How to switch DNS: Windows - change DNS in the network adapter properties; router - change the upstream DNS in its admin page (root fix, applies to every device); WSL - see the related canonical "WSL DNS resolution failure".

Re-run step 1 right after switching; if it opens, the DNS layer is confirmed.

6. Network path broken: change the path, not the DNS — the fix

• System proxy / Clash-like tools: switch to another node first (rules sending that domain to a dead node are a top cause);
• Test through the proxy explicitly: curl -x http://127.0.0.1:7890 -sI -m 10 https://target-domain (use your actual proxy port);
• Tether your phone's hotspot and compare: another path that opens = your original network's route to that IP is broken;
• If none of the above works and access is genuinely restricted: use compliant mirrors/acceleration (see the GitHub/mirror canonicals).

How to confirm it is fixed

curl -sI -m 10 https://target-domain -o /dev/null -w "http=%{http_code} dns=%{time_namelookup}s connect=%{time_connect}s total=%{time_total}s\n"
# 200/301/403 and total no longer timing out = fixed

Hard refresh (Ctrl+F5) opens the site in the browser = user-side confirmation. Note CDN/browser caches: if the first attempt still fails after the fix, wait 1-2 minutes or retry in an incognito window.

Other environments

Symptoms

Typical signs of "only one website won't open":

Browser:  Connection timed out / This site can't be reached / ERR_CONNECTION_TIMED_OUT
curl:     curl: (28) Connection timed out after 10000 milliseconds
ping:     Request timed out (ping failing does not mean the site is down - many sites block ICMP)

Features: other HTTPS sites work on the same network; the failing domain reproduces consistently (same in another browser); restarting the router or flushing the DNS cache may fix it briefly then it recurs (the illusion of a refreshed DNS cache).

Cause

"Won't open" is the only symptom the user can see, and it can originate at any layer: DNS resolution fails or returns a bad IP (poisoned cache/upstream failure/filtering rules), TCP connection times out (unreachable IP, blackhole, port filtering, CDN node down), TLS handshake fails (certificate/SNI, rare), or HTTP is rejected (server-side policy). Proxy tools add their own break points: rules routing the domain to an unreachable node. Different layers map to completely different fixes — which is exactly why you must layer first and act second. Another common trap is judging site health with ping: ICMP and HTTPS are entirely different paths, and "ping fails but the browser opens" or "ping works but the browser times out" are both normal.

Solution

1. Confirm scope: baseline 200 and target failing -> "single domain" troubleshooting (if both fail, check the network itself first).
2. Check DNS: getent ahosts target-domain - no result = DNS layer; a result does not rule out DNS, continue.
3. Connect and observe: curl -v -I -m 10 https://target-domain - stuck at Trying = TCP layer; stuck at Connected = TLS layer.
4. Bypass DNS to split layers: curl --resolve target-domain:443:<IP> https://target-domain - connects = DNS layer broken; still times out = network path broken.
5. DNS layer broken: switch to public DNS (223.5.5.5 / 1.1.1.1); Windows adapter, router upstream, or WSL resolved.conf.
6. Network path broken: switch proxy nodes, test through the proxy explicitly, tether a phone to change the path; if access is genuinely restricted, use compliant mirrors/acceleration.
7. Verify: curl status code + browser hard refresh; for CDN scenarios wait 1-2 minutes before judging.

Related canonicals

Read in order: precondition -> same root / same domain / related:

• Precondition (rule out first):
• Proxy env vars not taking effect / some tools bypass the proxy (confirm proxy vars and NO_PROXY semantics before layering)
• WSL DNS resolution failure (all domains failing inside WSL; for a single failing domain read this article first)

• Same domain (network/DNS family, different environments):
• DNS resolution fails inside Docker containers (some/all domains failing inside a container)
• GitHub direct connection slow/failing (same layering idea: curl checks the network layer first, then acceleration)

• Related (similar symptom, different root cause):
• curl large download cannot resume (same curl context, but the symptom is in the transfer stage)
• docker pull fails / mirror (the fix path when a registry domain is unreachable)