iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
Your domain can work perfectly while opening the server’s numeric IP address shows the wrong site, a default page, a redirect, or an HTTPS warning. That is usually expected on modern hosting: DNS gets the browser to an address, but the web server still needs the requested hostname to choose the right virtual host. HTTPS also needs that hostname for certificate selection and identity checking. The server may be online; the IP-only request is simply taking a different routing path.
What happens when you open a website by its domain
A browser does more than translate a name into a number. The domain remains part of the request all the way through connection setup, and shared servers use it to decide which website should answer.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minute
- DNS resolution: The browser asks DNS for the domain’s A record (IPv4) and, when available, its AAAA record (IPv6). It receives one or more addresses.
- Connection: The browser connects to one of those addresses on port 80 for HTTP or port 443 for HTTPS. Address selection can make IPv4 and IPv6 appear to behave differently.
- Hostname routing: For HTTP/1.1, the request carries a
Hostheader such asexample.com. HTTP/2 and HTTP/3 carry the equivalent authority value. A server with several sites on one address uses that name, together with the port, to select a virtual host. - HTTPS negotiation: Before encrypted HTTP headers are available, the TLS handshake carries the hostname through Server Name Indication (SNI). The server uses SNI to choose the certificate and the HTTPS virtual host.
- Certificate verification: The browser checks that the certificate identifies the host in the URI. A domain name is checked against DNS names in the certificate; a literal IP address must be covered as an IP identity.
Apache describes this behavior explicitly: creating virtual-host configurations does not create DNS records, and Apache discriminates between matching virtual hosts using the HTTP Host header. DNS and web-server routing are separate configuration layers.
Why the same server IP produces a different result
The IP request names no particular site
When you enter http://203.0.113.10/, the request’s host value is normally the IP literal, not example.com. If several domains share that address, none of their name-based virtual hosts may match. The server then applies its unmatched-request behavior: it may serve the first or designated default virtual host, show a generic welcome page, redirect elsewhere, or reject the request.
#1 Best Overall
The default page is not proof that the intended site is missing. It often proves that the network connection reached the machine but the request did not identify a configured hostname.
DNS points to a front end, not necessarily the origin
A domain may resolve to a reverse proxy, content-delivery network, load balancer, or hosting edge rather than the web server you think of as the origin. That public address can be shared by many customers. Typing it directly removes the hostname information used by the front end and may expose only its default response. The origin’s private address may not accept public traffic at all.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteIPv4 and IPv6 can lead to different configurations
If the domain has both A and AAAA records, a browser can select IPv6 while your manual test uses IPv4. One address might point to the correct virtual host and the other to an old server, a different load balancer, or no listener. Always compare both record types before treating an IP discrepancy as a web-server failure.
Why HTTPS usually fails by IP even when HTTP appears to work
Certificate identity is tied to the URI host
For https://example.com, the browser expects a certificate containing example.com (or an applicable wildcard) in its subject alternative names. For https://203.0.113.10, it expects that numeric address as an IP identity. A certificate issued only for the domain does not automatically authenticate the address.
Depending on the browser and certificate, the result is a certificate warning, a blocked connection, or an error describing a name mismatch. This check is independent of whether the IP is reachable.
SNI must be sent before HTTP routing
TLS encryption is negotiated before the server can read an HTTP Host header. SNI solves that ordering problem by carrying the requested hostname in the TLS handshake. The server can then select the certificate for example.com and establish the matching HTTPS virtual host. An IP-only URL sends an IP as the SNI name (or may provide no usable hostname), so the server can return its default certificate instead.
This explains a common pattern: plain HTTP by IP reaches a generic page, while HTTPS by IP stops at a certificate error. The two requests differ in both virtual-host selection and certificate identity.
Domain access versus IP access
| Routing element | Opening the domain | Opening the numeric IP |
|---|---|---|
| DNS | A/AAAA lookup supplies one or more addresses. | No DNS lookup is needed; you choose an address directly. |
| HTTP host value | The domain is sent as Host (or the HTTP/2/3 authority). |
The IP literal is normally sent, so a name-based site may not match. |
| TLS SNI | The domain is sent during the handshake. | The IP is sent or no site name is available for name-based selection. |
| Certificate identity | Checked against the domain name. | Must contain the literal IP as an IP identity. |
| Selected virtual host | The configuration matching the requested hostname. | The default, first, or unmatched virtual host, or a rejection. |
| Proxy/CDN path | Hostname rules can select the correct public service and origin. | The shared address cannot identify which customer or site you intended. |
How to diagnose the problem step by step
1. Confirm which addresses the domain actually uses
Run both record types from a machine that can reach the site:
dig +short A example.com
dig +short AAAA example.comOn Windows, nslookup -type=A example.com and nslookup -type=AAAA example.com provide the same basic check. Compare every returned address with the IP you are testing. If they differ, you are not testing the same endpoint. If an address recently changed, cached DNS responses can also make different networks reach different servers until the old TTL expires.
2. Test the suspected address while preserving the real hostname
Use curl’s --resolve option. It connects to the chosen address but keeps the domain in the URL, so curl sends the correct HTTP host value and SNI name:
curl -v --resolve example.com:80:203.0.113.10 http://example.com/
curl -v --resolve example.com:443:203.0.113.10 https://example.com/If the second command succeeds while https://203.0.113.10/ fails, network reachability is probably fine and the difference is hostname routing or certificate identity. Do not disable certificate verification merely to hide the symptom; that removes the check you are trying to diagnose.
3. Separate HTTP host routing from TLS routing
For an HTTP-only test, you can connect to the IP and set the host header explicitly:
curl -v --http1.1 -H 'Host: example.com' http://203.0.113.10/A correct response here confirms that the server needs the hostname to choose the virtual host. This technique does not solve HTTPS by itself: a manually supplied HTTP header arrives too late to choose the TLS certificate. Use --resolve for HTTPS so SNI and the certificate check also use the domain.
4. Check listeners and virtual-host definitions
On the server, verify that the intended site is listening on the address and port reached by the test. Then check the name declarations:
- In Apache, inspect each
VirtualHostblock’sServerNameandServerAlias, and confirm the block listens on the expected address and port. - In Nginx, inspect
listendirectives and theserver_namelist. Identify which block is markeddefault_serveror appears first for that listener. - For either server, verify that the configuration is enabled, syntax-tested, and reloaded after changes. A correct file that is not loaded has no effect.
- Check both port 80 and port 443. It is common for HTTP to have the right names while HTTPS still uses a default block or an old certificate.
Unmatched requests are commonly handled by the first or explicitly default virtual host. Therefore, the content of the IP-only response can reveal which configuration is first, not which site owns the address.
5. Inspect the certificate and SNI response
To see which certificate a server presents when the correct hostname is supplied, run:
openssl s_client -connect 203.0.113.10:443 -servername example.com </dev/nullReview the certificate’s subject alternative names and the handshake result. Repeat without -servername if you need to compare the default certificate. A certificate that contains only the domain will validate for the domain test, but not for a URL containing the numeric IP.
6. Account for a reverse proxy or CDN
If DNS resolves to a proxy or CDN, inspect that service’s hostname rules, origin mapping, and TLS settings. Test the public domain with --resolve rather than guessing an origin address. If you administer the origin separately, test it with the internal hostname and the appropriate network path; the public edge address is not necessarily a valid direct route to the origin.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Rank #4
What common symptoms mean
| Symptom | Most likely interpretation | Next check |
|---|---|---|
| Domain works; IP shows a welcome page | The request reached a server but matched its default virtual host. | Compare a domain request with an IP request using verbose curl output. |
| Domain redirects; IP redirects somewhere unexpected | Redirect rules are hostname-dependent or belong to the default site. | Test with --resolve and inspect the Location header. |
| HTTP by IP works; HTTPS by IP warns | The certificate does not identify the numeric IP, or the default TLS virtual host is being selected. | Check SAN entries and compare SNI and non-SNI handshakes. |
| Domain works on one network but not another | Different DNS answers, cached records, or IPv4/IPv6 paths may be in use. | Collect A and AAAA answers from both networks. |
| Every request times out | Firewall, routing, security policy, or a stopped listener may be involved; virtual-host selection has not yet been reached. | Check connectivity to the specific port, then inspect firewall and service logs. |
| IP returns a 400, 421, or similar rejection | The front end or application requires an allowed hostname. | Confirm configured hostnames and proxy allow-lists rather than removing the restriction blindly. |
How to fix or intentionally support IP access
If visitors should use the domain
- Publish correct A and AAAA records for the public service and remove stale records that point elsewhere.
- Configure the site’s canonical hostname in the web server and proxy, including every required alias.
- Make port 80 and port 443 virtual hosts agree on the intended names, redirects, and application routing.
- Install a certificate whose names match the public domain and configure SNI-aware HTTPS virtual hosting.
- Keep the default host deliberate: return a neutral response or a clear redirect rather than exposing an unrelated site’s content.
If administrators genuinely need IP-based HTTPS
The certificate authority must issue a certificate containing the numeric IP as an IP subject-alternative identity, and the TLS and HTTP configuration must deliberately accept that host. This is separate from adding a DNS record and may not be supported by every certificate workflow. Even with a valid certificate, a shared server still needs an explicit rule for requests whose host is the IP; otherwise they can continue to land on the default virtual host.
If the goal is testing, not public access
Do not change production DNS just to test a new address. Use curl --resolve, a controlled hosts-file entry, or an equivalent test environment that preserves the real hostname. These methods exercise the same Host and SNI routing that visitors will use while directing traffic to the address under investigation.
When an IP-only URL can work normally
Direct IP access is legitimate in a limited set of designs: a single site owns the address, the server intentionally treats the IP as its host, the service is HTTP-only, or the HTTPS certificate explicitly contains the IP. It can also work when a test tool supplies the intended hostname separately. None of these cases is guaranteed merely because the address responds to ping or accepts a TCP connection. Reachability, virtual-host selection, and certificate validation are separate tests.
Bottom line
A working domain proves that DNS, hostname routing, and (for HTTPS) certificate selection align for that domain. It does not promise that the same server will serve the intended site when the hostname is replaced with an IP literal. Compare A and AAAA records, test with the real hostname forced to the suspected address, then inspect virtual-host order, proxy rules, listeners, SNI, and certificate identities. A default page or certificate warning is usually a configuration clue—not evidence that the server is down.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Frequently Asked Questions
Why does ping succeed when the website cannot be opened by IP?
Ping tests ICMP reachability, while a website requires the correct TCP port, listener, hostname routing, and—on HTTPS—a matching certificate. A host can answer ping while rejecting or misrouting web requests.
Will changing the DNS record make the IP URL work?
Changing DNS changes which address the domain resolves to; it does not make an IP-literal request carry the domain name. You still need the appropriate virtual-host and certificate configuration if direct IP access is a requirement.
How can I tell whether a public IP belongs to a proxy instead of my origin server?
Compare the domain’s A and AAAA answers with the address documented for your origin, inspect response headers and proxy configuration, and test the public hostname with curl --resolve. A shared edge address commonly serves a default response when no hostname is supplied.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →
