Override resolution with --resolve

Sometimes you need to send a request for one hostname to an address DNS would not give you. The classic case is testing a new server before switching DNS over to it: you want to know that example.org works on the new machine while the public record still points at the old one.

Editing a hosts file is global and easy to forget. Every application on your machine inherits the override, and a week later you are debugging “weird DNS” you caused yourself. --resolve gives one curl command a temporary hostname, port, and address mapping, and it evaporates when the command ends.

Map the hostname for one command

The format is hostname:port:address, like example.org:443:93.184.216.34. Look up the current address first, then aim curl at it:

addr=$(dig +short example.org | head -1)
curl --resolve "example.org:443:$addr" --verbose https://example.org/ -o /dev/null

In the verbose output you can confirm the override took effect: curl reports connecting to the address you supplied, not one from a fresh DNS lookup. In a real pre-migration test, you would put the new server’s address there instead.

Why this beats connecting to the IP

You might wonder why not just curl https://93.184.216.34/. Because that changes the request itself. The Host header becomes the IP, the TLS server name (SNI) becomes the IP, and certificate verification fails, since certificates are issued for hostnames.

With --resolve, curl still requests example.org and verifies that hostname. Only address selection changes for this transfer. The Host header, SNI, and TLS verification all behave exactly as they will after the DNS switch. That fidelity is the entire point: you are rehearsing production behavior, not an approximation of it.

If the certificate on the target address does not cover example.org, curl fails with a verification error. That is a finding, not an obstacle — it means the new server is not ready.

Stay authorized

Use an address you control or are authorized to test. An override can direct credentials and requests to a different server, and sending real session cookies or tokens to a machine that merely claims to be your API is how credentials leak in test environments.