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?

  • 36
    Did you try before asking? Also you must enter an "URL"; a plain IP address isn't an URL, but most browsers will try to fix it by adding https::// these days.
    – U. Windl
    Oct 2 at 12:00
  • 21
    Yes. What stopped you from trying it out? The only caveat is if the IP address hosts multiple domains then you will get website content for the domain which the server admin deemed as "default" instead of the domain you assumed. Or, if the admin failed to configure things properly then you'd get an error.
    – MonkeyZeus
    Oct 2 at 14:14
  • 10
    There are several good answers, but I want to highlight the 10.000 ft. view: while in principle it doesn’t matter whether you open a network connection to a web server by its DNS name or it’s IP address, the HTTP/HTTPS protocols have a number of features that require the web browser to know the “name” of the web site, features that go beyond the basic “locate the correct network address that will respond to the request”. Without knowing the web site name, those features don’t work, and sites that rely on those features (most do nowadays) will not work correctly Oct 2 at 15:09
  • 8
    Talk about "This question does not show any research effort"!
    – pipe
    Oct 3 at 6:03
  • 3
    I remember working at a government facility in the late 90's. We discovered that in many cases we could get around the URL filter by typing the IP address of a web site directly into the browser's address bar - after pinging the domain name to get the IP address. Oct 4 at 4:13

12 Answers 12


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

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:

  1. You enter www.example.com into the browser address bar and hit Enter.
  2. The browser looks up www.example.com in DNS and retrieves its IP addresses.
  3. 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).
  4. The browser sends an HTTP request to the server.
  5. 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, your browser will send this over the TCP stream instead:

GET / HTTP/1.0

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.
  • 1
    +1 This very good answer about HTTP, this can be even more improved by adding the bits about HTTPS. In which way does TLS (HTTPS = HTTP over TLS) solve the cat-tail-problem that the hostname is given within the HTTP header, which is necessary to select the right TLS certificate, if the stream is not yet decrypted ("Server Name Indication"). Oct 3 at 6:30
  • 1
    Great answer. I'm going to be a pedant though: HTTP 1.0 doesn't actually require a HOST header. That said, you'd be hard pressed to find a client that doesn't send the HOST header.
    – 9072997
    Oct 3 at 14:01
  • 2
    @9072997 You're right: None of the headers are required by the standard, but Host is practically required for any server to return something meaningful.
    – iBug
    Oct 3 at 14:20
  • "the browser will use the default port for HTTP (80)" most browsers nowadays default to 443, they try to use https first or have a setting that forces https everywhere. Oct 4 at 2:17
  • 1
    @CausingUnderflowsEverywhere That's yet to be the default to be taught in an undergrad course.
    – iBug
    Oct 4 at 8:18

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.

  • 3
    I think you must consider both independently: (a) The transport connection (TCP) and the application protocol (HTTP): While any connection just uses the IP address (and the port), HTTP may make a difference on how the GET URL looks like (e.g.: name based virtual servers).
    – U. Windl
    Oct 2 at 12:06
  • 1
    "how is server configured" for example: serverfault.com/q/871705 - this is how you host multiple websites on the same server. Combinations of configuration.
    – WernerCD
    Oct 2 at 12:34
  • 3
    "HTTPS is tied to a domain" - typically, yes. That said, it seems like it may be possible to do HTTPS on an IP address. Although I don't know how they do it from a certs perspective, Cloudflare did HTTPS for an IP address here. Admittedly, it's rare, but I think it's possible. Might be wrong, though
    – cocomac
    Oct 2 at 14:28
  • 2
    @U.Windl that separation is complicated by TLS
    – OrangeDog
    Oct 2 at 16:47
  • 1
    @cocomac you can easily view the certificate. It has "IP Address" entries in addition to the "DNS Name" entries in its "Subject Alt Names".
    – OrangeDog
    Oct 2 at 17:06

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.

  • 3
    Second most important under HTTPS. HTTPS web servers can be configured to require SNI to identify the TLS certificate to use for the server: "if one server hosts multiple sites on a single listener, the server has no way to know which certificate to use in the TLS protocol". Without that the server and client can't establish the TLS connection to get to the point of the client being able to send the header. Oct 2 at 15:59
  • Not quite that it can't establish the connection, but it requires a different organisation of certificates. With separate IPs (or ports) or SNI it can use separate single-host certificates, because it knows which host you're trying to connect to up front (before it has a chance to read the Host header). Without that, it must blindly offer a certificate before it knows which host you're trying to reach, so it can only offer a multi-host certificate (either wildcard or just containing multiple hostnames).
    – Miral
    Oct 3 at 5:52

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.

  • 1
    The name for what is described in your first paragraph is virtual hosting. Oct 2 at 7:22
  • 3
    In Apache yes, but not sure that is universal, certainly that's not a term used in IIS, where they're simply referred to as Sites. Was focusing on the wider concept rather than digging into specifics that may be irrelevent to the OP. :) Oct 2 at 15:48

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

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, "".

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)
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.


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).


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 "", and when you try again you might get ""

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.


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

 nslookup superuser.com

Non-authoritative answer:
Name:   superuser.com
Name:   superuser.com

I tried entering 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 results in the error:

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

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.

  • Wow, Cloudflare. I thought Stack Exchange was all-in Fastly, has something changed?
    – iBug
    Oct 2 at 18:11
  • @iBug Just tried connecting using my phone, rather than broadband ISP, and got the same Cloudfare error tying to use Trying to use the https version got a SSL_ERROR_NO_CYPHER_OVERLAP error from firefox. Oct 2 at 18:39
  • 1
    Yep. Cloudflare is a CDN service that runs millions of websites on a limited pool of IP addresses. No surprise that it denies bare IP HTTP requests. It needs the Host header to identify which website the client is trying to visit.
    – iBug
    Oct 2 at 18:42
  • The HTTPS case is another thing: Your browser is requesting a certificate for the IP address, which Cloudflare refuses to provide one. Subsequent steps in the TLS handshake fails, and HTTP is not even in play here.
    – iBug
    Oct 2 at 18:44
  • @iBug yes.
    – Andrew T.
    Oct 3 at 5:52

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:


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">
    <binding protocol="http" bindingInformation="*:80:example.com" />
    <binding protocol="http" bindingInformation="*:80:www.example.com" />
<site name="the example.org website with ssl">
    <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" />

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. then the HTTP request will contain:


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.


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:

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.


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.


Of course you can! Can you drive to a friend's house if you already know their address? Type 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 ( 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.

  • 3
    This is misleading. The HTTP protocol has the Host header, which tells the HTTP server which host the client is trying to access. While it is certainly possible and legal to set up the HTTP server in such a way that it responds to a Host header which is simply the IP address, there are many HTTP servers which aren't set up that way. My server, for example, will respond to such an HTTP request with an HTTP 404 Resource not found status code, since it hosts two separate websites and without the proper name in the Host header, it doesn't know which site to deliver. Oct 2 at 15:12
  • 3
    Furthermore, while it used to be possible in the past, you cannot get a TLS certificate for an IP address signed by any reputable CA, so HTTPS is not possible. And since all large implementors of HTTP/3 have decided to only support HTTPS, that means HTTP/3 is out as well. Oct 2 at 15:17
  • 3
    The OP question was a simple question: "Can you get to a website by typing the IP address..." The answer to that is 'yes'. Typing quad 8's into the address bar proves that. He admitted he's just learning about DNS. "Can you get to every website by ONLY typing the IP address..." would be a completely different question, which is what the comments here answer. Piling a ton of extra info in an attempt to show how much you know is not helpful to someone just learning. I answered the question. The comments here answered a different question, which really was never asked by the OP.
    – Ron
    Oct 2 at 15:33
  • 2
    @ Andrew Henle "No, it is not always possible to get to a website" of course it isn't, but that's not what the OP asked. I don't see "always" anywhere in the original question. He asked if it's possible. Yes, it is.,, etc. will get you to a website. Too many answers here reference everything but DNS, which is what he's trying to learn. Try being helpful instead of puffing your chest to show how much you know instead of answering the simple question that was asked.
    – Ron
    Oct 2 at 16:02
  • 1
    I tried to edit your answer with an apartment building analogy. Here's the edit if it doesn't get approved: It gets a little more complicated if your friend lives in an apartment building though. Depending on how the webserver is set up you might reach your friend, someone else's house, or get no where at all. The IP gets you to the apartment building. Maybe the door man knows where your friend's apartment is and lead you there. Otherwise you're stuck and will need the domain name as it would forward the host name header to the web server (think of it as giving you the apartment number). Oct 4 at 2:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .