Skip to main content

Subdomains

Subdomains​

A. What Is a Subdomain?​

A subdomain is an additional part added before the main domain name.

For example:

example.com

is the main domain.

We can create subdomains such as:

www.example.com
api.example.com
blog.example.com

Breaking it down:

api.example.com
│      │
│      └── Main domain
│
└── Subdomain

Conceptually:

example.com
│
├── www.example.com
├── api.example.com
└── blog.example.com

A subdomain allows us to organize different parts or services of a website under the same main domain.

B. Subdomains Can Point to Different Services​

A subdomain does not have to serve exactly the same application as the main domain.

For example:

example.com
→ Main website

api.example.com
→ Backend API

blog.example.com
→ Blog

Conceptually:

This makes subdomains useful for separating different applications or services.

C. DNS Is Responsible for Resolving the Subdomain​

Before Nginx can handle a request to a subdomain, DNS needs to point that hostname to the correct server.

For example:

The browser first needs to determine:

Which server should api.example.com connect to?

This is handled through DNS records.

Conceptually:

D. Multiple Domains Can Point to the Same Server​

Different domain names or subdomains can resolve to the same IP address.

For example:

This means we do not necessarily need a separate server for every subdomain.

Multiple hostnames can reach the same machine.

The server can then decide how each request should be handled.

E. Nginx Can Distinguish the Hostname​

Once the request reaches the server, Nginx can inspect which hostname the client requested.

For example, both example.com and api.example.com can reach the same server and the same Nginx instance.

Nginx can use different server configurations for different hostnames.

Conceptually:

So DNS answers:

Which server should receive the request?

While Nginx can determine:

What should this server do with the request?

F. server_name​

In an Nginx virtual server configuration, server_name identifies which hostname the configuration should handle.

Conceptually:

# /etc/nginx/sites-enabled/fsfe
server {
    server_name example.com;
}

and another configuration could handle:

# /etc/nginx/sites-enabled/api.example.com
server {
    server_name api.example.com;
}

The idea is:

This allows one Nginx server to host multiple domains or subdomains.

G. DNS + Nginx Together​

The important part is understanding that DNS and Nginx have different responsibilities.

So:

DNS
→ Where is the server?

Nginx
→ What should this server do with the request?

H. Create a Subdomain in Practice​

The course example creates a blog subdomain in three stages:

The A record should point blog.example.com to the public IP address of the server that runs Nginx. Replace example.com with your own domain.

Add the blog virtual host​

The previous setup already enabled the main application virtual host through sites-enabled/fsfe. This section adds one new virtual-host file beside it:

Before:
/etc/nginx/sites-enabled/
└── fsfe → ../sites-available/fsfe

After:
/etc/nginx/sites-enabled/
├── fsfe → ../sites-available/fsfe  # Existing main-domain virtual host
└── blog.example.com             # New blog virtual host

The two server {} blocks are separate rather than nested. The existing fsfe block handles the main domain, while the new file handles the blog hostname.

The blog virtual-host file is:

/etc/nginx/sites-enabled/blog.example.com

The course creates this file directly under sites-enabled. It contains another server {} block, and server_name is what makes it match requests for the blog subdomain:

# /etc/nginx/sites-enabled/blog.example.com
server {
    listen 80;
    listen [::]:80;
    server_name blog.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
    }
}

The slide uses placeholders and localhost; localhost:3000 and 127.0.0.1:3000 refer to the same local application in this example.

Because the course's nginx.conf includes specific virtual-host files instead of every file in sites-enabled, the new blog configuration must also be included explicitly:

# /etc/nginx/nginx.conf
http {
    include /etc/nginx/sites-enabled/fsfe;
    include /etc/nginx/sites-enabled/blog.example.com;
}

Use the actual filenames from your server. After saving the files, validate the configuration and restart Nginx:

sudo nginx -t
sudo service nginx restart

Separate server blocks do not necessarily mean separate applications​

The course keeps the main domain and blog subdomain in different Nginx server blocks, but both point to port 3000 for now:

This demonstrates how Nginx selects a server block by hostname. It does not create a second backend application.

If the blog later runs as a separate application, only its upstream needs to change, for example:

# /etc/nginx/sites-enabled/blog.example.com
location / {
    proxy_pass http://127.0.0.1:4000;
}

The main application can remain on port 3000, while the blog application listens on port 4000.

DNS changes may take time to propagate, so a correct Nginx configuration does not guarantee that the new hostname resolves immediately.

I. The Big Picture​

A subdomain gives us another hostname under the same main domain:

example.com
│
├── api.example.com
├── blog.example.com
└── www.example.com

These subdomains can:

The core idea is:

A subdomain lets us organize different services under the same domain, while DNS routes the hostname to a server and Nginx determines how that hostname should be handled.