Curl to a Specific IP While Sending a Host Header (HTTPS-safe)

When you’re debugging load balancers, CDNs, or virtual hosts, you’ll often need to hit a specific IP address but still send the Host header for the site you care about. Here’s the right way to do it for both HTTP and HTTPS—without breaking TLS.

TL;DR

• HTTP (no TLS):
  
  curl -H 'Host: example.com' http://203.0.113.10/path

  1 2	curl -H 'Host: example.com' http://203.0.113.10/path

• HTTPS (TLS/SNI & cert validation intact) – preferred:
  
  curl --resolve example.com:443:203.0.113.10 https://example.com/path

  1 2	curl --resolve example.com:443:203.0.113.10 https://example.com/path

• HTTPS alternative (endpoint rewrite, keeps SNI intact):
  
  curl --connect-to example.com:443:203.0.113.10:443 https://example.com/path

  1 2	curl --connect-to example.com:443:203.0.113.10:443 https://example.com/path

⚠️ Don’t do https://203.0.113.10/... with only -H 'Host: example.com'. TLS will fail because SNI/cert validation will be against the IP, not the hostname.

Why this matters

• Name-based virtual hosting: Many sites share the same IP. The server uses the Host header (HTTP/1.1) or :authority (HTTP/2) to route your request.
• TLS/SNI: For HTTPS, the client must present the hostname during the handshake (SNI) so the server can serve the right certificate. If you connect to an IP directly, SNI uses the IP and cert validation fails.

HTTP (no TLS): just set Host

If there’s no TLS involved (port 80 or internal plain HTTP), put the IP in the URL and override the Host header.

IPv6:

HTTPS (with TLS): use --resolve (recommended)

--resolve injects a one-off DNS entry for this curl invocation. Curl will:

• Connect to the IP you specify
• Use example.com for SNI
• Validate the certificate against example.com
• Send Host: example.com

Custom port:

IPv6:

You can repeat --resolve multiple times to add several entries (e.g., www.example.com, api.example.com, etc.).

HTTPS alternative: --connect-to

--connect-to rewrites the network endpoint while leaving the URL host intact. That means:

• SNI and certificate checks still use the URL hostname
• TCP connection goes to the IP/port you specify

This is handy when you want to redirect only certain host:port pairs or when testing via proxies where --resolve might not apply the way you expect.

Choosing between --resolve and --connect-to

In most simple HTTPS tests, --resolve is the most natural/explicit choice.

Quick recipes

Send a custom header and see response headers (HTTP):

Check just the status and headers (HTTPS):

Verbose TLS debug:

Custom CA (staging PKI):

(If you must) bypass TLS verification for a one-off test
Not recommended outside of controlled debugging.

Common pitfalls

• HTTPS to an IP + Host header: Fails SNI/cert validation because the TLS handshake is for the IP, not the hostname.
• Forgetting the port in --resolve: The mapping key is host:port. If the site listens on 8443, include it.
• Wrong certificate: Even with --resolve, the server must present a certificate valid for the hostname you’re using (e.g., example.com or a matching SAN).
• IPv6 syntax: Wrap IPv6 literals in brackets in URLs; in --resolve, put the literal in brackets as shown above.

Troubleshooting checklist

1. Use verbose output
   -v shows which address curl connects to and the SNI/cert details.
   
   curl -v --resolve example.com:443:203.0.113.10 https://example.com/

   1 2	curl -v --resolve example.com:443:203.0.113.10 https://example.com/

2. Confirm the virtual host
   Add -H 'Host: …' for plain HTTP; rely on the URL host for HTTPS with --resolve/--connect-to.
3. Check ports
   Is the service on 443 or a nonstandard port? Mirror that in both the URL and the flag.
4. Validate cert path
   If you’re using a private CA, provide --cacert or --capath instead of -k.

Copy-paste examples (replace with your values)