Can you go to a website by typing the IP address into the address bar?

Question

As I'm learning about networks and DNS servers and what not... I'm curious, can you go to a website by typing the IP address into the address bar?

Answer 1

TL;DR It depends on the server's configuration. A quick positive example is one.one.one.one / 1.1.1.1.

I'm assuming you're following the usual lecture on your Computer Networking course about how visiting a website works, which lays out the following procedure:

0. You enter www.example.com into the browser address bar and hit Enter.
1. The browser looks up www.example.com in DNS and retrieves its IP addresses.
2. The browser establishes a TCP connection to one of the learned IP addresses. Since you did not specify a port, the browser will use the default port for the HTTP protocol (80).
3. The browser sends an HTTP request to the server.
4. The browser receives an HTTP response and displays the web page.

There could be other factors affecting certain details in the above process, but let's put those aside for now.

---

The domain name is actually used twice in the process: One for DNS lookup, and the other inside the HTTP request in step 3. HTTP is one of the few protocols where the visiting domain name is sent to the server. In the above example, at a bare minimum, this is what the browser sends to IANA's server (that hosts www.example.com):

GET / HTTP/1.0
Host: www.example.com

If you visit it through bare IP address (assuming it's 192.0.2.1), your browser will send this over the TCP stream instead:

GET / HTTP/1.0
Host: 192.0.2.1

Most common HTTP servers (Nginx, Apache, IIS etc.) have a concept called "Virtual Server", which is selecting configuration based on the domain name (the HTTP Host header). This is the part where the answer resides: It depends on the server. Some servers may return the same site for a bare IP Host header, while some others may not. The servers all behave as their administrators configured them.

For Nginx, you may add the server IP to the server_name directive in the same server block as the domain name, or the request gets routed to the default server block (the one with default_server, or the first one if none has `default_server). I'm not familiar with either Apache or IIS, though, but they sure have a similar setting.

---

More details on factors that could affect the example process:

• Before the browser performs a DNS request, it first normalizes what it received from the address bar. So the actual URL that comes to later steps should be http://www.example.com/, with scheme prepended (http://) and a minimal path appended (/).
• Depending on network environment and system settings, the browser may query www.example.com twice for both A and AAAA records, which corresponds to IPv4 and IPv6 addresses. This doesn't influence later steps, though.
  • Obviously, if you enter a URL with a bare IP, DNS will not be involved.
• The browser may choose to use HTTPS for a couple of reasons:
  • If you enter the whole URL into the address bar, and it begins with https://.
  • The domain has HSTS configured, or better yet, preloaded to the browser. (Try visiting hstspreload.org via plaintext HTTP, and if you succeed, file a bug report for your browser.)
  • The specific URL was previously visited, and an HTTP 301 redirect from http:// to https:// is cached by the browser.
  • The browser is configured to "Always use HTTPS".
• If the browser decides to use HTTPS instead of plaintext HTTP, a few more changes apply:
  • The normalized URL begins with https://.
  • The default port is now 443, the standard port for HTTPS.
  • TLS is enabled, which adds another point where the domain name is used, in the initial packet called ClientHello, with the Server Name Indication extension. This allows the server to choose a proper certificate before anything is encrypted.
  • HTTP/2 and HTTP/3 may be used, which changes how the HTTP request inside the TLS layer is serialized. The general idea remains unchanged, as the request still contains the standard host header, with the request line replaced by a new set of pseudo-headers (:method, :path, :scheme and :authority).
  • If HTTP/3 is used, the connection is no longer run on TCP, but UDP instead. That's the new QUIC transport protocol.

Answer 2

The IP stack isn't really 'aware' or 'care' about the IP. All DNS does is tell you "this domain name is at this IP".

In the 'simplest' sense there's no difference between either scenario - only that you're relying on DNS to resolve the IP rather than your own memory (There's other mechanisms - hosts files are essentially 'static', per machine domain name records) as far as the IP protocol is concerned.

However if we're talking about web pages the request from your web browser will include things like the hostname it wants to talk to. Even if the IP address for the server, and two web domains pointing at that server,a.example.com and b.example.com are the same website you may get different webpages depending on how the server is set up.

With HTTP - So you might reach a website (or an error message), but not the one you want potentially - the IP could be pointing at a default page or just a landing or error page.

HTTPS is tied to a domain so you may get a dismissible error (or a non dismissible one)

Essentially, it depends on how the web server is configured.

Answer 3

Call me crazy but none of the current answers contains the word "header", which is the most important part for a web server like Apache, Nginx etc. to resolve the correct site. The host header is what makes you able to serve multiple sites on a single ip. For example nginx will match it against what is configured in server_name. If you want to serve a site without a domain (just ip) it will match agains the server marked with default_server.

Answer 4

To expand on Journeyman Geek's answer, in order for web servers handle multiple websites they differentiate between them using a combination of IP address, web address (e.g. www.example.com) and port number.

Each website must have a unique combination of those three. The most common scenario is to have each with the same IP address and port, but different host / web addresses, but there's nothing stopping the admin from using any other combination. On top of this, each website can be configured with multiple of these trios, so it will respond to more than one.

One possible combination includes having the IP address and port, but no host / web address, in which case you can obviously only have one website on the server using that IP address combination and port respond without a host / web address, since it needs to be unique. So if that has been setup by the admin of that web server then yes you can access the website with just the IP (though as noted, only using HTTP not HTTPS), but these days outside of default holding pages it's rare for you to see a website configured that way. But if you're administering your own webserver, it's perfectly possibly for you to configure it to do that.

Answer 5

Does the site have the IP address in their certificate Subject Alternative Name and are they using a reverse proxy?

Visiting a Page via URL

Suppose you enter "https://www.somesite.com/my/cool/page" in your browser's address bar and hit enter.

Your browser will resolve "www.somesite.com" to an ip address, for example 1.2.3.4.

The browser knows that the default port for the https protocol is 443.

It will then start a TCP/TLS connection to that IP address on port 443 and send an HTTP request - really just a blob of text:

GET /my/cool/page HTTP/1.1
User-Agent: Firefox(or whatever you're using)
Host: www.somesite.com
Accept: */*

Blank lines are used as delimiters in the HTTP protocol (it's an OLD protocol) so that the server knows when the client is done making the request. The server will parse this bit of text to find all the pieces of information and based on that it will decide how to respond. In this case, it would reply with the HTML code of my cool page.

Visiting a Page via IP

However let's say you directly used the IP address instead, "https://1.2.3.4/my/cool/page".

No DNS resolution is necessary, so your browser proceeds to try and establish the TCP/TLS connection to the server like before.

Certificate Errors

The first thing you'll likely run into is that the server's certificate will likely show as untrusted. This is because x509 certs have an extension called "Subject Alternative Name" that lists the server's trusted names. If the hostname or IP you specify for the request isn't on that list, the the browser will tell you that the cert is invalid and prevent you from connecting.

However let's assume that the certificate actually lists the specific IP you are using, or else that you ignore the certificate issues. The browser will make the connection to the server and send the following HTTP request:

GET /my/cool/page HTTP/1.1
User-Agent: Firefox(or whatever you're using)
Host: 1.2.3.4
Accept: */*

Notice that since the browser doesn't have a DNS name for the server, it falls back to just using the IP address you provided.

For simple sites this is not an issue - as long as the request arrives, it will respond based on the path (the middle bit of the first line specifying the exact page you are requesting).

Reverse Proxies

However, it's pretty common for sites to use a reverse proxy (nginx, traefik, caddy, etc) that can multiplex HTTP requests across multiple backend web servers based on the "Host" field.

Suppose that I'm running two different web applications, app1 and app2. They're small applications, and maybe they rely on some shared resources, so I want to run them on a single server. Applications can't share ports, and it would be inconvenient to run them on different ports since now the client would have to specify which port they are connecting to. Instead, I can use a reverse proxy.

I would set up two DNS entries for the same server (IP), "app1.somesite.com" and "app2.somesite.com". Then I would configure my reverse proxy to check the HTTP "Host" header and direct incoming requests to the two applications based on which one is being requested.

So even though HTTP requests for both apps will go to the same physical (or virtual) server identified by the IP address, the Host field is used by the reverse proxy to multiplex those requests across the actual applications running on the host.

In this case, making a request solely by IP address may get you only one of the apps or neither, depending on how the reverse proxy is configured.

Answer 6

As asked - Specifically that an END USER types an IP address into the address bar of a browser:

• HTTP: Yes - you will get a page, as long as there is a default site configured.
• HTTPS: Certificate error.

If the end user types in an IP address, the host header will be the IP address not a specific domain - so best case a HTTPS server may serve the response using whichever certificate is default (for that IP/port pair) - however the browser has no way to validate the certificate - hence by default it will render a certificate error.

If the user is savvy enough to click through the certificate error they will likely get whichever site is the default on the server (for that IP/port pair).

Answer 7

Not only can a server address serve multiple websites -- a website can be served by multiple server addresses.

When you do a DNS request for "mywebsite.com", you might get "1.2.3.4", and when you try again you might get "1.2.3.7"

Originally an IP address was a particular server -- that perhaps supported FTP, HTTP, NFS and several other protocols for retrieving files (HTTP for getting "HTML" files from the "www" folder) -- but for high-traffic websites that is no longer the case.

Answer 8

I'm on a Ubtuntu system and found the IP address of superuser.com using:

 nslookup superuser.com
Server:     127.0.0.53
Address:    127.0.0.53#53

Non-authoritative answer:
Name:   superuser.com
Address: 104.18.8.56
Name:   superuser.com
Address: 104.18.9.56

I tried entering http://104.18.9.56/questions/1810856/can-you-go-to-a-website-by-typing-the-ip-address-into-the-address-bar into the address bar in Chrome to get to this question, but are then presented with the error:

Error 1003 Ray ID: 80fddb60a82b3692 • 2023-10-02 15:07:46 UTC
Direct IP access not allowed
What happened?
You've requested an IP address that is part of the Cloudflare network. A valid Host header must be supplied to reach the desired website.

What can I do?
If you are interested in learning more about Cloudflare, please visit our website.

Trying instead https://104.18.9.56/questions/1810856/can-you-go-to-a-website-by-typing-the-ip-address-into-the-address-bar results in the error:

This site can’t provide a secure connection
104.18.9.56 uses an unsupported protocol.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH

I have set up filtering with my ISP to block access to unwanted types of content, so it might be the ISP blocking attempts to access the StackExchange using an IP address.

This serves as an example of how there can be proxies / content filtering between the actual server and the end user web browser which may handle IP addresses and names differently.

Edit: As @Jörg W Mittag has just said in a comment to a different answer, for the https case the above might also be due to the browser no longer allowing a TLS certificate for an IP address.

Answer 9

Short Answer

You will end up on one of the websites hosted on that IP, usually referred to as the default website.

Long Answer

The web servers are supposed to be able to serve hundreds of websites on a single IP. To facilitate this, the HTTP Host header is used.

Let me explain the whole process using IIS web server.

Step 1: DNS Setup

It is possible to have multiple DNS records point to a single IP. So we could have:

example.com      11.22.33.44
www.example.com  11.22.33.44
example.org      11.22.33.44
www.example.org  11.22.33.44

Step 2: IIS Setup

When you setup a website on IIS, you must specify the bindings for the website. The binding information consists of 3 parts:

1. IP
2. Port
3. Host name

The binding information also specified which protocol, http or https, is associated with the 3-tuple. Note that:

• It is possible for a server to be listening on multiple IPs. You can tell IIS to only serve the website on a specific IP, or use * for all IPs.
• You can tell IIS to serve the website on non-standard ports
• The host name could be blank

The bindings for the two websites above could look like this:

<site name="the example.com website">
  <bindings>
    <binding protocol="http" bindingInformation="*:80:example.com" />
    <binding protocol="http" bindingInformation="*:80:www.example.com" />
  </bindings>
</site>
<site name="the example.org website with ssl">
  <bindings>
    <binding protocol="http" bindingInformation="*:80:example.org" />
    <binding protocol="http" bindingInformation="*:80:www.example.org" />
    <binding protocol="https" bindingInformation="*:443:example.org" />
    <binding protocol="https" bindingInformation="*:443:www.example.org" />
  </bindings>
</site>

The HTTP Request

When the browser tries to display the website (e.g. http://example.com) it will lookup the IP address for the host example.com. It will then connect to that IP on the specified port using the specified protocol.

Once the connection is established, it will send a HTTP request, which will contain Host header:

Host: example.com

IIS will use the three variables (IP, port and host name) to determine (i) the protocol to use (ii) the website to display. In the above example, it will serve data from the example.com website using http protocol.

Back to your question

If you specify the IP address instead of host name (e.g. http://11.22.33.44) then the HTTP request will contain:

Host: 11.22.33.44

On IIS, when a matching host header is not found, it will use the binding with blank host name (the default website has a blank host name on stock installation). If no binding with a blank host name is found the user will get a 404 error.

Answer 10

Yes and no. As many of the other answers suggest, it all depends on the configuration of the web server (the software that "serves" your computer the web page).

When you make a web request, your computer communicates to the server over the HTTP protocol. This is essentially an agreed upon way of the computers talking to each other that works well on the web. An HTTP "request" (the message your computer sends to the server) looks something like this:

GET / HTTP/2
Host: www.google.com
User-Agent: curl/8.3.0
Accept: */*

What your computer is really saying is "I want the page located on the path / under the hostname www.google.com." Now, the same web server could be hosting many websites (such is the case with many popular "shared" hosting services like GoDaddy), which means many websites would have the same IP address. Thus, the Host header is what distinguishes which site you are interested in viewing.

On the server end, one can configure "virtual hosts" which allows you to serve several websites and web app configurations from the same server. On many servers configured with virtual hosts, trying to access the IP (over HTTP) directly/without a Host header will just give you an error (403 or 404), or redirect you to another website (e.g., the hosting company, their admin panel, etc.). On some that have a "default" host configured, it will serve a site configured under that default host configuration.

Answer 11

I believe completely yes. That is all the domain name translates too is an IP address, however it is true that multiple sites can exist on the same IP address.

They are distinguished often by network address translation or port. So an IP address and port number could translate to a subnet IP address on the servers subnet.

Additionally the server can distinguish however they like. Via html or what ever mechanism.

But an IP address and port could be required. Also a url could be required pertaining to the higher layer witch resides on the IP protocol. But the IP protocol typically identifies both an IP and port number.

Answer 12

Of course you can! Can you drive to a friend's house if you already know their address? Type 8.8.8.8 into your address bar. You will end up at Google's DNS website. So, yes, typing in the address will get you to a website, IF you know the address.

Just like driving - if you only know your friend's house number, you will need additional information to get there (like the street name). If the website you are trying to get to requires additional information (i.e. /questions/1810856/...) you will need all of that additional information to get to it, in addition to the superuser IP address (104.18.8.56). Play with nslookup a bit... try nslookup superuser.com Basically, all you are doing with DNS is using an old-fashioned phonebook, (if you're old enough to remember them). If you already know all the information, you don't need the phonebook.