How to Verify and Spoof Domains When Specifying IP Addresses with curl
When building a web server, switching DNS providers, or investigating site access outages, situations frequently arise where you want to “access a specific domain by specifying a target IP address rather than the IP address on the DNS."
Normally, a method of editing the local PC’s hosts file (such as /etc/hosts) to temporarily change the mapping between the domain and IP address is used. However, this is time-consuming to edit and carries the risk of causing incorrect verification results due to browser DNS cache or TLS cache.
This article explains how to use the command-line tool curl to verify communication by specifying (spoofing) the domain name while accessing an IP address directly, without modifying the hosts file at all. The goal is to reduce working time from a few minutes per task to under 10 seconds and build a strict verification environment free from cache interference.
Communication Issues Caused by Direct IP Address Specification
When you perform HTTP/HTTPS access by directly specifying an IP address without waiting for DNS propagation, there are two patterns where you may not get the intended website response.
The first is when virtual hosting (a mechanism to operate multiple domains on a single IP address) is configured on the web server side. If you specify the IP address as-is (e.g., 192.168.232.33), the web server cannot determine which website is being requested and returns the default virtual host (such as 404 Not Found).
The second is an SSL/TLS certificate verification error during HTTPS communication (TLS handshake). If you attempt a direct HTTPS connection to an IP address, the domain name (CN/SAN) in the certificate returned by the server does not match the destination IP address, causing a certificate error and terminating the communication.
curl -v https://192.168.232.33:443
SSL: no alternative certificate subject name matches target host name '192.168.232.33' Closing connection 0 curl: (60) SSL: no alternative certificate subject name matches target host name '192.168.232.33'
To solve these problems and obtain the correct domain response, you must utilize curl command-line options to override request information and name resolution.
Two Approaches to Specify and Spoof Domains with curl
To spoof a domain name while connecting to an IP address using curl, there are two methods: using -H (to specify the Host header) and using –resolve (to override name resolution). It is important to choose the appropriate one depending on your use case.
Method Using the Host Header (-H Option)
This is the simplest method, which forcefully rewrites the Host field included in the HTTP request header information.
curl -kv -H "Host: donguri3.net" https://192.168.232.33/
Advantages: The command is concise, making it suitable for checking virtual host behavior in HTTP communication (port 80) or when you want to skip SSL certificate verification (by adding the -k option) to check only the response body.
Disadvantages: Since SNI (Server Name Indication) during the TLS handshake uses the destination IP address or the hostname of the URL, SSL errors cannot be avoided unless the certificate verification is disabled with the -k option.
Method Overriding Name Resolution (–resolve Option) *Recommended
This method overrides the internal DNS cache of curl, statically mapping the destination IP address for a specified “domain:port" combination.
curl -v --resolve donguri3.net:443:192.168.232.33 https://donguri3.net/
Advantages: The correct domain name (donguri3.net) is sent as SNI during the TLS handshake, and server certificate verification is performed successfully. Because you can mimic HTTPS communication procedures completely identical to the production environment without using the -k option, this is the most reliable verification method.
Disadvantages: You must correctly specify the port number and IP address format (domain:port:IP).
[Practical Example] Troubleshooting via Domain Spoofing with curl
Here is a practical example of identifying a problem using this curl technique during incident response for a WordPress site (https://donguri3.net/) that actually became inaccessible.
First, run a connection test to the target server’s IP address (192.168.232.33) by specifying the IP address directly.
curl -kv https://192.168.232.33:443
HTTP/2 404 server: LiteSpeed
Since HTTP/2 404 was returned as a response, it was confirmed that the web server (OpenLiteSpeed) itself was running and there were no network connectivity issues.
Next, add the -H “Host: …" option to request a response for the target domain.
curl -kv -H "Host: donguri3.net" https://192.168.232.33/
HTTP/2 500 content-type: text/html; charset=UTF-8 ...
An HTTP/2 500 Internal Server Error along with an HTML output for “Error establishing a database connection" was returned. This verification instantly revealed that the cause was not an issue with the web server or TLS settings, but rather a connection failure from the application (WordPress) to the database (MariaDB). We also verified the behavior of normal name resolution overriding using the –resolve option.
curl -kv --resolve donguri3.net:443:192.168.232.33 https://donguri3.net/
Equivalently, a 500 error and database connection error response were confirmed, corroborating that there were no abnormalities in the entire communication path including TLS verification.
https://amzn.to/4be85vzRapid Recovery Effects through Efficient Investigation
As a result of precise troubleshooting using the curl command, we were able to immediately conclude that the cause of the failure was a stopped database service (ols-db container), without spending time modifying hosts files or clearing browser caches.
Without wasting time on web server restarts or configuration file changes, we executed the restart command for the relevant database container, completing site recovery in a short amount of time.
docker-compose restart ols-db
Conclusion
In web server operation verification and failure troubleshooting, domain specification using the curl command is extremely powerful. By using -H “Host: domain name" for casual virtual host checks, and –resolve domain:port:IP for strict HTTPS communication tests including certificate verification, you can perform verifications without modifying hosts files or being affected by caches. In actual troubleshooting as well, combining direct IP access and Host specification allowed us to isolate web-tier and database-tier errors within 10 seconds and succeed in rapid site recovery.