Back to lessons

Web Server Rescue

Your Site Is Not Down. DNS Might Be Lying.

A domain appears unreachable, but you need to separate a real server outage from stale or wrong DNS.

Command

curl --resolve example.com:443:203.0.113.10 https://example.com/

What changed

The request bypasses normal DNS for one call and tests the HTTPS server directly.

Danger

safe

When to use it

Use this when DNS, browser cache, router DNS, or CDN routing may be hiding the real server state.

When not to use it

Do not treat a successful forced request as proof that public DNS is correct.

Undo or recovery

No system state is changed. Remove the forced IP and test normal DNS again.

Expected output

HTTP response headers or page content from the target server.

demo script

Disposable terminal steps

  1. dig +short example.com
  2. curl -I https://example.com/
  3. curl --resolve example.com:443:203.0.113.10 -I https://example.com/

simulated output

What it looks like

disposable vessel
::fixture-ready::
$ dig +short example.com
198.51.100.44
::exit-code::0
$ curl -I https://example.com/
curl: (6) Could not resolve host: example.com
::exit-code::6
$ curl --resolve example.com:443:203.0.113.10 -I https://example.com/
HTTP/2 200
server: fake-nginx
content-type: text/html

::exit-code::0

YouTube Short

Your server is not down. DNS is lying.

Before you blame Nginx, force one request straight to the VPS. If that works, the server is alive and DNS is the suspect.

LinkedIn hook

The browser said the site was gone. The server was answering fine.

Question: When a site disappears, do you check DNS first or the web server first?

experiments

A/B tests to run

Metric: short_click_through_rate

A: Your server is not down. DNS is lying.

B: Before you blame Nginx, run this.