Can a single server be associated with multiple domains?
Can a single server be associated with multiple domains?
Yes. This would be done by pointing those domains at your web server via DNS.
If I own the "x.x.x.x" web server, can I make two separate sites on "x.x.x.x/one" and "x.x.x.x/two" and give them two different domains?
This depends on your web server software. You could certainly point both domains to your server, but it would then be up to the server software to distinguish which traffic was intended for which domain.
Some smaller web server projects do not support this kind of feature. However, larger projects often do. In the cases of Apache and Nginx, this support comes via Name-based virtual hosts and server blocks, respectively. Both of these projects also support Server Name Indication (SNI) for TLS (HTTPS) connections as well.
How will it handle internal links in the case (es.
x.x.x.x/one/foo/page.html)?
Typically, you would set the full path to your one folder as the document root in e.g. your virtual host or server block configuration (i.e. where the "main" domain starts). A page that referenced e.g. example.com/foo/page.html would then be referencing e.g. x.x.x.x/one/foo/page.html. If you wanted to use just e.g. example.com/page.html, you would set your document root to the full path of foo.
WordPress
WordPress has its own methods of dealing with domains. In your example case, assuming you wanted WordPress to handle both domains, you would:
Specify two domains in DNS.
Create two e.g. virtual hosts (in Apache) corresponding to those domains.
Set each document root to point your WordPress installation.
Configure WordPress to service both those domains.
Otherwise, you would simply point one document root to your WordPress installation (and configure only one domain in WordPress) and point the other document root to your non-WordPress files.
Notes
For the explanation above, I assuming that you have your web server set up at
x.x.x.xandoneandfooare directories below the default document root you have already set up for the server.It's worth mentioning that DNS points only to IP addresses (e.g.
1.2.3.4) or, in the case of CNAME records, whole domains (e.g.example.com). You cannot point DNS to e.g.http://1.2.3.4/one.There are some Domain Providers that may offer web redirects (e.g. to
http://1.2.3.4/one), but these are not part of DNS. How requests for pages would be handled in this situation would (again) entirely depend on your server.
Minimal Apache Virtual Host Examples
ex. Regular Domains
<VirtualHost *:80>
ServerName example1.com
# ServerAlias www.example1.com, *.example1.com
DocumentRoot "/path/to/www/Wordpress_Site"
</VirtualHost>
<VirtualHost *:80>
ServerName example2.com
# ServerAlias www.example2.com, *.example2.com
DocumentRoot "/path/to/www/Non-Wordpress_Site"
</VirtualHost>
ex. Sub-Domains
<VirtualHost *:80>
ServerName sub1.example.com
# ServerAlias www.sub1.example.com, *.sub1.example.com
DocumentRoot "/path/to/www/Wordpress_Site"
</VirtualHost>
<VirtualHost *:80>
ServerName sub2.example.com
# ServerAlias www.sub2.example2.com, *.sub2.example.com
DocumentRoot "/path/to/www/Non-Wordpress_Site"
</VirtualHost>
It's possible, the exact configuration depending on your web server. E.g. for Apache see here.
You will need to have the DNS for both domains to point to your server's IP address -- only one of them can be set as the reverse address (IP to domain name resolution), though.
Something to keep in mind if you're using HTTPS (HTTP+TLS): There is a specific order of operations at the start of the transaction:
- The incoming connection is made using the server's IP address.
- The TLS session is negotiated.
- With TLS set up, the HTTP request is passed to the HTTP server.
If you have several DNS hostnames pointing to the same IP address, then you need to make sure that the TLS certificate for your site covers all hostnames served by your server. The client doesn't tell the server the hostname it's trying to get until the HTTP request comes through (step 3), but the client knows the desired hostname prior to step 1, and expects the server certificate sent to it in step 2 to have a matching hostname, or the browser will likely put up a "this server might be impersonated" warning screen.
This is pretty straightforward if you have a wildcard certificate and all the hostnames are in the domain covered by that certificate. It gets trickier if you need to provide a list of hostnames (a.k.a. "subject alternative names") to your certificate provider so they all get included.
There is a TLS renegotiation mechanism that might be able to serve different certificates based on hostname, prior to step 3, but it's spotty and most servers don't configure it. It's much easier to configure a web server to serve one certificate.