How to test a website on a new IP without DNS changes using `curl --resolve` with full validation

During server migrations, the most classic error is testing by raw IP and blindly concluding that "it's okay," without actually validating the virtual host, TLS termination, and real domain-based redirects. The curl --resolve command decisively resolves this issue by effectively simulating a temporary DNS mapping per request, without ever touching the public DNS records.

Why testing by pure IP is categorically insufficient#

If you simply run:

curl https://NEW_IP

You are likely to receive:

• The default server vhost (wrong website content);
• An incorrect or mismatched TLS certificate;
• Inconsistent or broken relative redirects.

This procedure fundamentally fails to validate the actual production behavior of the domain on the target infrastructure.

Correct usage of --resolve#

curl -skI --resolve domain.com:443:148.113.xxx.xxx https://domain.com

This specific format injects local resolution strictly for that single call:

• Host: domain.com
• Port: 443
• Target IP: The new server's address

Minimum tests i execute before the formal cutover#

1) Homepage status validation#

curl -sk -o /dev/null -w "%{http_code}\n" --resolve domain.com:443:148.113.xxx.xxx https://domain.com/

2) Login/admin panel verification#

curl -skI --resolve domain.com:443:148.113.xxx.xxx https://domain.com/wp-admin

3) API health endpoint check#

curl -skI --resolve domain.com:443:148.113.xxx.xxx https://domain.com/api/health

4) Redirection chain integrity#

curl -skL --resolve domain.com:443:148.113.xxx.xxx -o /dev/null -w "final=%{url_effective} code=%{http_code}\n" https://domain.com

Simple automation script for bulk validation#

#!/usr/bin/env bash
set -euo pipefail

DOMAIN="domain.com"
NEW_IP="148.113.xxx.xxx"
PATHS=("/" "/wp-admin" "/api/health")

for p in "${PATHS[@]}"; do
  code=$(curl -sk -o /dev/null -w "%{http_code}" --resolve "${DOMAIN}:443:${NEW_IP}" "https://${DOMAIN}${p}")
  printf '%-20s -> %s\n' "$p" "$code"
done

TLS validation beyond simple HTTP status#

If the new host environment already possesses a valid certificate installation, perform the test without the -k (insecure) flag:

curl -sI --resolve domain.com:443:148.113.xxx.xxx https://domain.com

If this call fails, you must diagnose the certificate chain or SNI configuration before attempting the public DNS switch.

Cutover best practices#

1. Aggressively reduce the DNS TTL several hours before the migration window.
2. Validate all critical endpoints utilizing the --resolve methodology.
3. Maintain an immediate rollback plan pointing back to the legacy IP.
4. Closely monitor 5xx error rates and network latency immediately after the swap.

Common errors encountered during pre-cutover triage#

Test succeeds on HTTP but fails on HTTPS#

Cause: The certificate is physically missing or the chain is incomplete on the new host.

Homepage returns 200, but the application breaks#

Cause: Only the root endpoint was superficially tested; routes requiring authentication or specific API headers were left unvalidated.

Redirection loop on the new server#

Cause: A legacy rewrite rule dependent on specific headers or proxy configurations was not replicated on the destination.

This is precisely why I always test multiple routes and the entire redirection chain before modifying public DNS entries.

Production takeaways#

curl --resolve remains the most reliable method for staging and white-glove homologation of a new host without impacting live users. It validates the real-world scenario of the domain/HTTPS stack before the public cutover, significantly reducing the risk of downtime and emergency rollbacks.

See also

Infrastructure How to build a smart proxy for side-by-side server validation during migration

Infrastructure Surviving kernel panic: diagnosing and working around boot regressions in CachyOS with Limine

Infrastructure Gmail rejecting DirectAdmin system emails: authenticating server hostnames with SPF and DKIM

This post is licensed under CC BY-NC.