iTranslated by AI
Why You Can't Access a Website by Entering its Resolved IP Address in a Browser
TL;DR
- Even if you resolve an FQDN and enter the resulting IP address into a browser, you often cannot access the site.
- The main reason is that in server environments like CDNs or VPS, multiple FQDNs are assigned to the same IP address.
- While typical explanations remain valid, the "let's try it out easily" approach has become difficult to demonstrate.
Introduction
I was observing the preparations for an internship at a certain company and felt that the typical explanation regarding name resolution has become a bit difficult to understand—or rather, impossible to grasp as is—in today's environment.
The general explanation for accessing an FQDN (like example.co.jp or example.com) is to first resolve the name and then access the resulting IP address.
However, I suspect that for the vast majority of sites, you cannot actually access them by entering that IP address into a browser.
Try it out
First, let's try it out.
You could use a browser, but since that would involve many images, I'll use PowerShell.
First, let's start with name resolution.
> Resolve-DnsName www.microsoft.com
Name Type TTL Section NameHost
---- ---- --- ------- --------
www.microsoft.com CNAME 474 Answer www.microsoft.com-c-3.edgekey.net
www.microsoft.com-c-3.edgekey. CNAME 474 Answer www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net
net
www.microsoft.com-c-3.edgekey. CNAME 474 Answer e13678.dscb.akamaiedge.net
net.globalredir.akadns.net
Name : e13678.dscb.akamaiedge.net
QueryType : AAAA
TTL : 5
Section : Answer
IP6Address : 2600:140b:1c00:1491::356e
Name : e13678.dscb.akamaiedge.net
QueryType : AAAA
TTL : 5
Section : Answer
IP6Address : 2600:140b:1c00:14a6::356e
Name : e13678.dscb.akamaiedge.net
QueryType : A
TTL : 15
Section : Answer
IP4Address : 23.221.141.222
A lot of things appeared, but for now, it seems like communicating with 23.221.141.222 should work.
> Invoke-WebRequest http://23.221.141.222
Invoke-WebRequest:
Invalid URL
Invalid URL
The requested URL "[no URL]", is invalid.
Reference #9.6604d817.1753160390.2d6fb685
https://errors.edgesuite.net/9.6604d817.1753160390.2d6fb685
It seems like it didn't work.
Let's try HTTPS too.
> Invoke-WebRequest https://23.221.141.222
Invoke-WebRequest: The remote certificate is invalid according to the validation procedure: RemoteCertificateNameMismatch
The atmosphere changed a bit, but it still seems to fail.
I'll provide the answer first and then explain the details.
Here, by using the -Headers parameter and specifying the Host header, I got a 200 OK—meaning I can now access it.
> Invoke-WebRequest https://23.221.141.222 -Headers @{ "Host" = "www.microsoft.com" }
StatusCode : 200
StatusDescription : OK
Content :
<!DOCTYPE html><html xmlns:mscom="http://schemas.microsoft.com/CMSvNext"
xmlns:md="http://schemas.microsoft.com/mscom-data" lang="en-us"
xmlns="http://www.w3.org/1999/xhtml"><head>…
Why Can't You Access It?
I mentioned that "you probably cannot access the vast majority of sites," and there are several technical reasons for this.
- In server environments such as VPS (Virtual Private Server), multiple FQDNs are often assigned to a single IP address.
- This is seen in services like Sakura VPS, where cases like assigning both
www.example.co.jpandwww-test.example.co.jpto the same IP address occur. - This pattern is likely common for small and medium-sized enterprises.
- This is seen in services like Sakura VPS, where cases like assigning both
- Sites using CDNs (Content Delivery Networks) route to different backends depending on which FQDN is being accessed.
- CDNs are frequently used for DDoS protection, WAF, or general load balancing of the website.
- Most large corporate websites and consumer-facing sites likely follow this pattern.
In both cases, the reason is essentially the same: at Layer 3 (L3) of the OSI model, which is IP address-based, it is impossible to know which FQDN is being accessed, so the server throws an error.
At Layer 7 (L7), since the FQDN is included in the Host header of the HTTP header, the server can identify which FQDN is being requested and determine how to handle it.
Is the Explanation Regarding Name Resolution Wrong?
So, is the explanation "resolve the name and communicate with that IP address" incorrect? No, that is not the case.
As described above, PCs and smartphones resolve the specified FQDN, and the resulting IP address is included in the L3 header. This part is the responsibility of the OS.
Additionally, the browser includes the specified FQDN in the Host header of the L7 HTTP header when accessing the server. This part is the responsibility of the browser.
Therefore, while the typical explanation is not wrong, the situation has changed such that the follow-up instruction to "try it out using a browser" rarely works anymore.
I have tried a few examples and confirmed the following behaviors:
- Dom Dom Hamburger (domdomhamburger.com)
- Accessible via http://219.94.206.38
- Google (www.google.co.jp)
- Accessing http://142.251.42.163 redirects to https://www.google.com
- Yahoo! JAPAN (www.yahoo.co.jp)
- Accessing http://183.79.219.252 returns a 404 Not Found
Errors When Accessing via IP Address in HTTPS
As a side note, when repeating the cycle of resolving an FQDN and testing in a browser, you will often see the screen turn red or encounter certificate errors.
This is because, during HTTPS communication, the server presents a certificate, but those certificates rarely include the IP address.
In some websites, I observed cases where they redirect to the official website if you take the somewhat risky approach of "proceeding anyway."
Summary
In this article, I have explained why you cannot access a site by entering the IP address resolved from an FQDN into a browser, along with the results of my tests.
While the typical explanation regarding name resolution is correct, the reality is that unless you consider a separate way to explain it effectively, traditional explanations will fail to apply in most modern cases.
Discussion