Test a Website Before a DNS Change with curl

Training scenario: a copy of your website is ready on another hosting platform, but the domain still points to the old server. How can you check the new environment without switching visitors over? Testing a website before a DNS change with curl --resolve lets you contact a chosen IP address while keeping the normal domain in the URL. This does not change DNS for everyone: it is an individual verification request from your computer.

The goal of this exercise is to collect three separate pieces of evidence: the connection reaches the intended address, HTTPS verification succeeds, and the response belongs to the intended copy. Do not confuse this with full migration acceptance. The commands below will not test payments, the email queue or JavaScript behaviour in a browser. They can, however, help you stop before switching traffic if the new server is not ready.

Prepare the address and a verification marker

The example is intended for a macOS or Linux terminal with curl and HTTPS support, without an HTTP or SOCKS proxy. Administrator privileges are not required, and you can run it from any directory: these requests do not write anything locally. First, check that the tool is available. If the command is not found, install curl using your operating system’s standard package manager and its documentation; there is no need for a random installation script.

curl --version

In the examples, example.com is a placeholder domain and 192.0.2.10 is a documentation address, not a server for a real test. Replace them with your domain and the new hosting IP supplied by your provider. Port 443 is used for HTTPS. Only test your own website or an environment you have permission to test.

Before running the commands, ask the person responsible for the copy to prepare a safe public verification marker: for example, a file named migration-check.txt containing an agreed non-secret string that is absent from the old environment. This is a separate change to the test environment: agree on it, do not overwrite an existing file, and plan to remove it after acceptance. Do not use a database dump, password, configuration file or personal data for this purpose.

Get a response from the new server itself

curl --resolve example.com:443:192.0.2.10 \
  --connect-timeout 5 --max-time 15 \
  --silent --show-error --dump-header - \
  --output /dev/null \
  --write-out 'HTTP=%{http_code} IP=%{remote_ip}\n' \
  https://example.com/

The command sends a normal GET request, displays the headers and the final HTTP and IP fields, but discards the response body through /dev/null. The time limits prevent the check from hanging for too long. Compare a completed request with your expected status; 200 alone does not confirm that the content is correct. Do not add automatic retries to requests that could create orders or other data.

The --resolve option supplies a mapping for a specific domain and port pair only within this curl invocation. It does not edit the system hosts file, and there is no DNS change to roll back afterwards. The domain in the HTTPS URL remains the website’s domain, so this test is not replaced by simply opening an IP address in a browser. Check the syntax in the official curl documentation.

Compare the IP field with the new environment’s address. If they differ, do not conclude that the migration has been checked: first establish the request route, whether a proxy is involved, or whether an argument is wrong. On a corporate network, do not bypass a mandatory proxy on your own initiative. Agree on a direct verification method with the administrator, or run the check in an approved environment without an intermediary.

Do not hide TLS or redirect errors

If curl reports a certificate problem, do not add -k just to obtain a reassuring result. Check the domain, the new server’s certificate, its certificate chain and the client’s trust store. Certificate verification must remain enabled. Trust behaviour depends on the curl build and TLS library; the TLS verification documentation explains these differences. An error alone does not prove that the server itself is broken.

The first command deliberately does not follow redirects. If you see 301 or 302, read Location: the website may point to www, another subdomain or an old address. For every approved destination domain, make a separate request with its own --resolve mapping. Following redirects automatically without this check could silently return you to the old hosting environment and create a false impression of a successful migration.

Likewise, do not extend a conclusion about one domain to all its variants. Successfully checking HTTPS without www does not mean that a separate www virtual host is configured correctly. List the addresses the project requires before testing and mark each separately. If the server has additional access restrictions, agree on the test rather than disabling protection for the entire website.

Confirm the copy before making a decision

curl --resolve example.com:443:192.0.2.10 \
  --connect-timeout 5 --max-time 15 \
  --silent --show-error \
  https://example.com/migration-check.txt

This request displays the verification file’s body in the terminal. The expected result is the exact agreed string, not an arbitrary page with a successful status. If you receive an HTML error page, a redirect or different text, record the observation and check the file location and virtual host configuration. Do not publish raw headers if they contain cookies or other sensitive values.

A test record only needs the domain, target IP, date, HTTP status, TLS result and verification marker. Add separate entries for an important internal page and a static resource. This is not a load test: a few sequential requests are enough. If necessary, describe the problem using AriZone’s guide to writing a bug report, so the person responsible can reproduce it without guessing.

Conclusion: first establish the connection address, working HTTPS and the identity of the content, and only then plan the DNS change. Browser behaviour, integrations, email and backup restoration still require separate checks. If you need help accepting a new hosting environment, contact AriZone with a short test record, without passwords or private keys: this lets the investigation start with a specific failed step instead of repeating the migration blindly.