`curl --resolve` Is the Command You Need When You Want to Test a Hostname Against a Specific IP Without Waiting for DNS to Catch Up
A practical guide to `curl --resolve` for validating virtual hosts, TLS endpoints, and load-balancer targets using a chosen IP while keeping the original Host header and hostname in play.
Why this command matters: sometimes you need to test the server you expect the hostname to point to before public DNS actually points there.
If you are validating a new load balancer, testing a just-provisioned server, or checking whether a virtual host works behind a specific IP, curl --resolve is a very useful trick. It lets you keep the intended hostname while overriding the DNS answer for the request.
The command
curl --resolve example.com:443:203.0.113.10 https://example.com/That tells curl:
- when requesting
example.com - on port
443 - use IP
203.0.113.10
This is powerful because it preserves the hostname, which means the TLS SNI and Host header behavior stays relevant.
Why that matters
Testing with a raw IP alone is often misleading. A lot of modern web stacks route by hostname. If you do this:
curl https://203.0.113.10/you may hit:
- the wrong virtual host
- a certificate mismatch
- a default backend
curl --resolve gives you a more realistic pre-DNS or alternate-DNS test.
Great use cases
It is especially useful for:
- validating a new server before a DNS cutover
- checking a specific load balancer target
- testing HTTPS behavior with the correct hostname
- comparing old and new infrastructure intentionally
This command is one of the cleanest ways to ask “if DNS pointed here, would the app actually work?”
Final recommendation
If you need hostname-accurate testing against a chosen IP, use curl --resolve instead of switching your whole machine’s DNS or making weaker raw-IP requests. It is precise, fast, and much closer to the real traffic shape you care about.