How DNS Previewer works

When you migrate a site to a new host, your domain still points to the old server until you update DNS. That’s a problem: you can’t easily test the new host under its real domain, and a botched switchover is visible to every visitor.

The standard workarounds — and why they hurt

• Editing /etc/hosts: only works on your machine. Can’t share with clients or QA.
• Using the server’s IP directly: wrong Host header, SSL cert errors, broken vhosts.
• Staging subdomain: often has a different code path than production, so issues slip through.

What DNS Previewer does

1. You tell us your domain (example.com) and the new server’s IP or hostname.
2. We generate a short subdomain like a7xk2p.dnspreviewer.com and open a reverse proxy on it.
3. When you visit that URL, our proxy connects to your target server using the correct Host header and TLS SNI for your domain — so your server serves the right vhost and content.
4. Responses are streamed back to your browser. HTML and CSS that reference your domain are rewritten to the preview URL so clicks and assets keep working inside the preview.
5. After 15 minutes the session expires and the URL returns a friendly expired page.

What’s stripped or rewritten

• X-Frame-Options, Content-Security-Policy, and Strict-Transport-Security headers are removed so the preview can load.
• Set-Cookie domain attributes are removed so cookies bind to the preview subdomain.
• Location redirects to your domain are rewritten to stay inside the preview.
• Response bodies are decompressed before rewriting (we ask upstream for identity encoding).

Known limitations

• JavaScript that hardcodes your apex domain in fetch()/XMLHttpRequest will hit CORS errors. This is inherent to any preview proxy.
• WebSockets are not proxied. Most apps fall back to long polling.
• Responses larger than 4 MB pass through without link rewriting.
• Third-party services (OAuth, payment gateways) may not accept requests that originated from a subdomain they don’t recognize.

Try it now