Server block structure in Nginx - Commands & Configuration

Introduction

When you want to host websites or web apps on a server, you need to tell the server how to handle different website addresses. Server blocks in nginx let you set rules for each website or app separately on the same server.

When you want to host multiple websites on one server with different domain names.

When you need to serve different content based on the website address visitors use.

When you want to set custom settings like SSL or redirects for a specific website.

When you want to separate logs for different websites on the same server.

When you want to run different web apps on different ports or paths but under one server.

Config File - example-site.conf

example-site.conf

server {
    listen 80;
    server_name example.com www.example.com;

    root /var/www/example.com/html;
    index index.html index.htm;

    location / {
        try_files $uri $uri/ =404;
    }

    error_page 404 /404.html;
    location = /404.html {
        internal;
    }

    access_log /var/log/nginx/example.com.access.log;
    error_log /var/log/nginx/example.com.error.log;
}

server { ... } defines a server block for one website.

listen 80; tells nginx to listen on port 80 (standard web traffic).

server_name lists the domain names this block handles.

root sets the folder where website files are stored.

index lists default files to serve when a folder is requested.

location / { ... } defines how to handle requests to the root path.

error_page 404 sets a custom page for not found errors.

access_log and error_log set log file locations for this site.

Commands

Copy the server block config file to nginx's sites-available directory to prepare for enabling it.

Terminal

sudo cp example-site.conf /etc/nginx/sites-available/

Expected Output

No output (command runs silently)

Create a symbolic link in sites-enabled to activate the server block configuration.

Terminal

sudo ln -s /etc/nginx/sites-available/example-site.conf /etc/nginx/sites-enabled/

Expected Output

No output (command runs silently)

Test nginx configuration files for syntax errors before reloading to avoid downtime.

Terminal

sudo nginx -t

Expected Output

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

Reload nginx to apply the new server block configuration without stopping the server.

Terminal

sudo systemctl reload nginx

Expected Output

No output (command runs silently)

Check the HTTP response headers from the server to verify the site is responding correctly.

Terminal

curl -I http://example.com

Expected Output

HTTP/1.1 200 OK

Server: nginx

Date: Wed, 01 Jan 2025 12:00:00 GMT

Content-Type: text/html

Content-Length: 612

Connection: keep-alive

Key Concept

If you remember nothing else from this pattern, remember: each server block tells nginx how to handle requests for one website or domain.

Common Mistakes

Not creating a symbolic link in sites-enabled after adding the config file to sites-available.

nginx only loads configs from sites-enabled, so your server block won't be active.

Always create a symbolic link in sites-enabled using ln -s after placing your config in sites-available.

Forgetting to test nginx configuration with nginx -t before reloading.

Syntax errors can cause nginx to fail to reload, leading to downtime.

Run sudo nginx -t to check for errors before reloading nginx.

Setting the wrong root path or server_name in the server block.

Requests won't find the correct files or won't match the server block, causing errors or default site to show.

Double-check root and server_name values to match your website files and domain.

Summary

Create a server block config file defining how nginx handles a website's requests.

Enable the server block by linking it from sites-available to sites-enabled.

Test the configuration syntax with nginx -t before reloading nginx to apply changes.

Reload nginx to activate the new server block without downtime.

Verify the website responds correctly using curl or a browser.

Practice

1. What is the main purpose of a server block in an Nginx configuration?

easy

A. To define how Nginx handles requests for a specific website or domain

B. To set the operating system user for Nginx processes

C. To configure the firewall rules for Nginx

D. To specify the database connection details

Solution

1. Step 1: Understand the role of server blocks

   A server block tells Nginx how to respond to requests for a particular domain or site.

2. Step 2: Compare options with server block purpose

   Only To define how Nginx handles requests for a specific website or domain describes handling requests for a website, which matches the server block's role.

3. Final Answer:

   To define how Nginx handles requests for a specific website or domain -> Option A

4. Quick Check:

   Server block = website request handling [OK]

Hint: Server blocks map domains to settings in Nginx [OK]

Common Mistakes:

• Confusing server block with user or firewall settings
• Thinking server block manages database connections
• Mixing server block with global Nginx settings

2. Which of the following is the correct syntax to start a server block in Nginx?

easy

A. server {

B. block server {

C. site {

D. server-block {

Solution

1. Step 1: Recall Nginx server block syntax

   The correct syntax to start a server block is the keyword server followed by curly braces.

2. Step 2: Check each option

   Only server { uses the exact keyword server with braces, which is valid syntax.

3. Final Answer:

   server { -> Option A

4. Quick Check:

   Server block starts with 'server {' [OK]

Hint: Server blocks always start with 'server {' [OK]

Common Mistakes:

• Using incorrect keywords like 'block' or 'site'
• Adding extra hyphens or misspelling 'server'
• Omitting the opening brace

3. Given this server block snippet, what port will Nginx listen on?

server {
    listen 8080;
    server_name example.com;
}

medium

A. 443

B. 8080

C. 80

D. None, it will cause an error

Solution

1. Step 1: Identify the listen directive

   The line listen 8080; tells Nginx to listen on port 8080.

2. Step 2: Understand default ports

   Since port 8080 is explicitly set, Nginx will listen on 8080, not the default 80 or 443.

3. Final Answer:

   8080 -> Option B

4. Quick Check:

   listen port = 8080 [OK]

Hint: Check the listen directive for port number [OK]

Common Mistakes:

• Assuming default port 80 without checking listen
• Confusing port 443 (HTTPS) with 8080
• Thinking missing listen causes error (it defaults to 80)

4. Identify the error in this server block configuration:

server {
    listen 80
    server_name mysite.com;
}

medium

A. listen directive should be 'listen port 80;'

B. server_name directive is incorrect

C. Curly braces are missing

D. Missing semicolon after listen directive

Solution

1. Step 1: Check syntax of directives

   Each directive in Nginx must end with a semicolon. The listen 80 line is missing a semicolon.

2. Step 2: Verify other parts

   The server_name directive and braces are correct. The listen directive syntax does not require the word 'port'.

3. Final Answer:

   Missing semicolon after listen directive -> Option D

4. Quick Check:

   Directives end with ';' [OK]

Hint: Every directive line ends with a semicolon [OK]

Common Mistakes:

• Forgetting semicolons after directives
• Adding unnecessary words like 'port' in listen
• Misplacing or missing braces

5. You want to serve two websites on the same Nginx server: site1.com on port 80 and site2.com on port 8080. Which configuration correctly sets up the server blocks?

hard

A. server {
listen 80 8080;
server_name site1.com site2.com;
}

B. server {
listen 80;
server_name site1.com site2.com;
}

C. server {
listen 80;
server_name site1.com;
}
server {
listen 8080;
server_name site2.com;
}

D. server {
listen 80;
server_name site1.com;
listen 8080;
server_name site2.com;
}

Solution

1. Step 1: Understand separate server blocks for different ports

   Each site on a different port needs its own server block with its own listen and server_name directives.

2. Step 2: Analyze each option

   server { listen 80; server_name site1.com; } server { listen 8080; server_name site2.com; } correctly defines two separate server blocks, one for port 80 and site1.com, another for port 8080 and site2.com. Other options either combine ports or server_names incorrectly.

3. Final Answer:

   Separate server blocks for each site and port -> Option C

4. Quick Check:

   One server block per port/site [OK]

Hint: Use separate server blocks for different ports/sites [OK]

Common Mistakes:

• Combining multiple ports in one listen directive incorrectly
• Listing multiple server_names in one block for different ports
• Trying to put two listen directives in one server block for different sites