Main configuration file (nginx.conf) - Commands & Configuration

Introduction

When you want to serve websites or apps, you need a server that listens to requests and sends back responses. Nginx is a popular server software that uses a main configuration file called nginx.conf to control how it works and handles traffic.

When you want to host a simple website on your own server or computer.

When you need to reverse proxy requests to another app running on a different port.

When you want to set up caching or compression to speed up your website.

When you want to control access to your site with security rules.

When you want to serve multiple websites from the same server using different domain names.

Config File - nginx.conf

nginx.conf

user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

events {
    worker_connections 1024;
}

http {
    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for"';

    access_log /var/log/nginx/access.log main;

    sendfile on;
    keepalive_timeout 65;

    server {
        listen 80;
        server_name localhost;

        location / {
            root /usr/share/nginx/html;
            index index.html index.htm;
        }

        error_page 404 /404.html;
        location = /404.html {
            root /usr/share/nginx/html;
        }
    }
}

user nginx; sets the user running the worker processes.
worker_processes auto; lets nginx decide how many worker processes to run based on CPU cores.
events block controls connection handling.
http block contains settings for web traffic, including MIME types, logging, and server blocks.
server block defines how to handle requests on port 80 for the localhost domain.
location / serves files from the default web folder.
error_page defines a custom 404 error page.

Commands

This command tests the nginx configuration file for syntax errors before applying it. It helps catch mistakes early.

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

This command restarts the nginx service to apply any changes made in the configuration file.

Terminal

sudo systemctl restart nginx

Expected Output

No output (command runs silently)

This command checks if the nginx service is running properly after restart.

Terminal

sudo systemctl status nginx

Expected Output

● nginx.service - A high performance web server and a reverse proxy server

   Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)

   Active: active (running) since Fri 2024-06-07 10:00:00 UTC; 5s ago

 Main PID: 1234 (nginx)

    Tasks: 2 (limit: 1152)

   Memory: 3.5M

   CGroup: /system.slice/nginx.service

           ├─1234 nginx: master process /usr/sbin/nginx

           └─1235 nginx: worker process

This command sends a simple HTTP request to the local nginx server to check if it responds correctly.

Terminal

curl -I http://localhost

Expected Output

HTTP/1.1 200 OK

Server: nginx/1.24.0

Date: Fri, 07 Jun 2024 10:00:05 GMT

Content-Type: text/html

Content-Length: 612

Last-Modified: Wed, 01 May 2024 12:00:00 GMT

Connection: keep-alive

ETag: "607d-5a1c9f4e4a000"

Accept-Ranges: bytes

Key Concept

If you remember nothing else from this pattern, remember: nginx.conf controls how nginx listens, serves files, and handles web requests.

Common Mistakes

Editing nginx.conf without testing syntax using 'nginx -t' before restarting.

This can cause nginx to fail restarting due to syntax errors, making your website unavailable.

Always run 'sudo nginx -t' to check for errors before restarting nginx.

Not restarting nginx after changing the configuration file.

Changes won't take effect until nginx reloads or restarts, so your updates won't work.

Run 'sudo systemctl restart nginx' or 'sudo nginx -s reload' after changes.

Setting incorrect file paths in the root directive inside the server block.

Nginx won't find your website files and will return errors or blank pages.

Use the correct absolute path to your website files, like '/usr/share/nginx/html'.

Summary

The nginx.conf file sets global and server-specific settings for nginx web server.

Use 'nginx -t' to test configuration syntax before restarting nginx.

Restart nginx with 'systemctl restart nginx' to apply changes and verify with 'systemctl status nginx'.

Test the server response using 'curl -I http://localhost' to confirm nginx serves requests.

Practice

1. What is the primary purpose of the nginx.conf file in NGINX?

easy

A. To manage user accounts and permissions

B. To store website content like HTML and images

C. To log errors and access information

D. To configure how NGINX handles web requests and server behavior

Solution

1. Step 1: Understand the role of nginx.conf

   The nginx.conf file is the main configuration file that controls how NGINX behaves and processes requests.

2. Step 2: Differentiate from other files

   Files like logs store errors or access info, and website content files hold HTML/images, but nginx.conf sets server rules.

3. Final Answer:

   To configure how NGINX handles web requests and server behavior -> Option D

4. Quick Check:

   Main config file = server behavior [OK]

Hint: Remember: nginx.conf sets server rules, not content or logs [OK]

Common Mistakes:

• Confusing nginx.conf with website files
• Thinking nginx.conf stores logs
• Assuming nginx.conf manages users

2. Which of the following is the correct syntax to include another configuration file inside nginx.conf?

easy

A. include /etc/nginx/conf.d/*.conf;

B. import /etc/nginx/conf.d/*.conf;

C. load /etc/nginx/conf.d/*.conf;

D. attach /etc/nginx/conf.d/*.conf;

Solution

1. Step 1: Recall the directive for including files

   NGINX uses the include directive to add other config files inside nginx.conf.

2. Step 2: Check syntax correctness

   The correct syntax is include path; with a semicolon. Other words like import, load, attach are invalid in NGINX.

3. Final Answer:

   include /etc/nginx/conf.d/*.conf; -> Option A

4. Quick Check:

   Include directive = include [OK]

Hint: Use 'include' to add files, ends with semicolon [OK]

Common Mistakes:

• Using 'import' or 'load' instead of 'include'
• Forgetting the semicolon at the end
• Wrong directive names

3. Given this snippet from nginx.conf:

http {
    server {
        listen 80;
        server_name example.com;
        location / {
            root /var/www/html;
        }
    }
}

What will happen when a user visits http://example.com/?

medium

A. NGINX serves files from /var/www/html directory

B. NGINX returns a 404 error because root is missing a semicolon

C. NGINX redirects to HTTPS automatically

D. NGINX blocks the request due to missing listen directive

Solution

1. Step 1: Analyze the server block

   The server listens on port 80 and responds to requests for example.com. The location / block sets the root directory to /var/www/html.

2. Step 2: Understand the effect of root directive

   When a user visits the site root, NGINX serves files from /var/www/html. The semicolon is present, so syntax is correct.

3. Final Answer:

   NGINX serves files from /var/www/html directory -> Option A

4. Quick Check:

   Root directive sets file location = serve files [OK]

Hint: Root directive points to file folder served [OK]

Common Mistakes:

• Assuming missing semicolon causes error (it's present)
• Thinking HTTPS redirect happens automatically
• Ignoring listen directive presence

4. Identify the error in this nginx.conf snippet:

http {
    server {
        listen 80
        server_name mysite.com;
        location / {
            root /usr/share/nginx/html;
        }
    }
}

medium

A. root directive path is incorrect

B. server_name directive is invalid

C. Missing semicolon after listen 80

D. location block cannot be inside server block

Solution

1. Step 1: Check syntax of directives

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

2. Step 2: Validate other directives

   The server_name and root directives are correctly written. The location block is correctly nested inside server.

3. Final Answer:

   Missing semicolon after listen 80 -> Option C

4. Quick Check:

   Every directive ends with semicolon [OK]

Hint: Check every directive ends with semicolon [OK]

Common Mistakes:

• Ignoring missing semicolon errors
• Thinking server_name syntax is wrong
• Misunderstanding block nesting rules

5. You want to serve two websites on the same NGINX server using nginx.conf. Which configuration correctly sets up two server blocks for site1.com and site2.com on port 80?

hard

A. http {
server {
listen 80;
server_name site1.com site2.com;
root /var/www/site1;
}
}

B. http {
server {
listen 80;
server_name site1.com;
root /var/www/site1;
}
server {
listen 80;
server_name site2.com;
root /var/www/site2;
}
}

C. http {
server {
listen 80;
server_name site1.com;
root /var/www/site1;
}
location /site2 {
root /var/www/site2;
}
}

D. http {
server {
listen 80;
server_name site1.com;
root /var/www/site1;
}
server {
listen 8080;
server_name site2.com;
root /var/www/site2;
}
}

Solution

1. Step 1: Understand multiple server blocks

   To serve two sites on the same port, create two separate server blocks each with its own server_name and root.

2. Step 2: Evaluate each option

   http {
       server {
           listen 80;
           server_name site1.com;
           root /var/www/site1;
       }
       server {
           listen 80;
           server_name site2.com;
           root /var/www/site2;
       }
   }

   correctly defines two server blocks both listening on port 80 with different server_name and root.

   http {
       server {
           listen 80;
           server_name site1.com site2.com;
           root /var/www/site1;
       }
   }

   combines names in one block, serving only one root.

   http {
       server {
           listen 80;
           server_name site1.com;
           root /var/www/site1;
       }
       location /site2 {
           root /var/www/site2;
       }
   }

   uses location incorrectly for separate site.

   http {
       server {
           listen 80;
           server_name site1.com;
           root /var/www/site1;
       }
       server {
           listen 8080;
           server_name site2.com;
           root /var/www/site2;
       }
   }

   uses different ports, not both on 80.

3. Final Answer:

   Two server blocks on port 80 with separate server_name and root -> Option B

4. Quick Check:

   Separate server blocks = separate sites [OK]

Hint: Use separate server blocks with unique server_name for each site [OK]

Common Mistakes:

• Combining multiple domains in one server block with one root
• Using location blocks instead of server blocks for separate sites
• Assigning different ports when same port is required