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
dig +short example.comcurl -I https://example.com/curl --resolve example.com:443:203.0.113.10 -I https://example.com/
simulated output
What it looks like
::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.