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 you switch DNS over. You want to know that example.org works on the new machine while the public record still points at the old one.

The old way is editing your hosts file. That’s global, and easy to forget. Every application on your machine inherits the override. A week later you’re debugging “weird DNS” you caused yourself.

--resolve gives one curl command a temporary mapping of hostname, port, and address. It disappears when the command ends.

Map the hostname for one command

The format is hostname:port:address, for example example.org:443:104.20.26.136. 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, the * Connected to example.org (104.20.26.136) port 443 line confirms the override. curl connected to the address you supplied, not one from a fresh DNS lookup.

Here we mapped the hostname to its real address, so nothing changes. That’s on purpose: it lets you see the mechanism safely. In a real pre-migration test, you’d put the new server’s address there instead.

Why this beats connecting to the IP

You might wonder why not just run curl https://104.20.26.136/. Because that changes the request itself.

The Host header becomes the IP. The TLS server name (SNI), which tells the server which certificate to present, becomes the IP too. And certificate verification fails, because certificates are issued for hostnames, not addresses.

With --resolve, curl still requests example.org and still verifies that hostname. Only the address selection changes. The Host header, the SNI, and TLS verification all behave exactly as they will after the DNS switch.

That fidelity is the whole point. You’re rehearsing production behavior, not an approximation of it.

If the certificate on the target address doesn’t cover example.org, curl fails with exit code 60. That’s a finding, not an obstacle. It means the new server isn’t ready yet, and you learned that before your users did.

Stay authorized

Use an address you control, or one you’re authorized to test. An override sends the full request, including any cookies or tokens attached to it, to the machine you named. Pointing real session credentials at a server that merely claims to be your API is how credentials leak in test environments.

Try this on your own project: find your site’s current address with dig, run the --resolve command above against your hostname, and read the * Connected to line. Next time you migrate servers, the only thing you’ll change is that address.