Question 1

What is the difference between root and alias in an Nginx configuration?

Accepted Answer

The root directive appends the requested URI to the specified path, whereas the alias directive completely replaces the location part of the URI with the specified path. For example, if you have location /images/ { root /var/www/; } and request /images/logo.png, Nginx looks for /var/www/images/logo.png. If you use location /images/ { alias /var/www/; } and request the same file, Nginx drops the /images/ prefix and looks for /var/www/logo.png. Misusing these two directives is a common cause of 404 errors when serving static media.

Question 2

Why does my Nginx reverse proxy drop custom HTTP headers?

Accepted Answer

By default, Nginx strictly adheres to CGI standards and automatically drops any incoming HTTP headers that contain underscores (_). If your client sends a header like Auth_Token: 12345, Nginx will strip it before passing the request to your backend via proxy_pass. To resolve this, you must explicitly add the directive underscores_in_headers on; to your http or server context. However, the industry best practice is to simply use hyphens in custom headers (e.g., Auth-Token), which Nginx passes through natively without requiring configuration changes.

Question 3

How do I safely test a generated configuration before applying it?

Accepted Answer

You should never reload or restart Nginx without first validating the syntax of your configuration files. You can do this by executing the command nginx -t (or sudo nginx -t) in your terminal. This command instructs Nginx to parse all configuration files, check for missing semicolons, validate curly brace closures, and ensure all referenced files (like SSL certificates) actually exist on the disk. If the test passes, it will output "syntax is ok" and "test is successful," at which point you can safely run nginx -s reload to apply the changes seamlessly.

Question 4

What is the purpose of the try_files directive in Single Page Applications?

Accepted Answer

Single Page Applications (SPAs) like React, Vue, or Angular handle routing entirely within the client's browser using JavaScript. If a user directly accesses a deep link like example.com/profile, the browser asks the Nginx server for a file named "profile". Since this file does not exist on the server, Nginx returns a 404 error. The directive try_files $uri $uri/ /index.html; intercepts this process. It tells Nginx: "First, see if the exact file exists. If not, see if a directory exists. If both fail, do not return a 404; instead, return the main index.html file." This allows the SPA to load and its internal JavaScript router to display the correct "profile" view.

Question 5

How do I redirect all HTTP traffic to HTTPS globally?

Accepted Answer

The most secure and efficient way to handle HTTP to HTTPS redirection is to create a dedicated, default server block that listens strictly on port 80. Within this block, you define listen 80 default_server; and use a single return directive: return 301 https://$host$request_uri;. This catches all unencrypted traffic arriving at the server, regardless of the domain name, and issues a permanent 301 redirect to the exact same URI on the secure HTTPS port. This approach is superior to using if statements or writing individual redirect blocks for every single domain hosted on the server.

Question 6

What does the client_max_body_size directive actually do?

Accepted Answer

This directive defines the maximum allowed size of the client request body, which directly impacts the size of files a user can upload to your server via HTTP POST requests. By default, Nginx sets this limit to a highly restrictive 1 Megabyte (1M). If a user attempts to upload a 5 Megabyte PDF, Nginx will immediately terminate the connection and return a 413 (Payload Too Large) status code, preventing the request from ever reaching your backend application. To allow larger uploads, you must increase this value, for example, client_max_body_size 50M;, within the http, server, or specific location context.

Question 7

How does Nginx handle Let's Encrypt certificate renewals without downtime?

Accepted Answer

Let's Encrypt issues certificates that expire every 90 days, requiring frequent automated renewals via tools like Certbot. The renewal process utilizes the ACME HTTP-01 challenge, which requires the server to host a specific verification file at the path /.well-known/acme-challenge/. A properly generated Nginx configuration includes a dedicated location block for this exact path, serving files directly from a specific directory (e.g., /var/www/certbot). When Certbot successfully renews the certificate, it executes a post-hook script running nginx -s reload. This gracefully reloads the Nginx worker processes, instantly applying the new cryptographic certificates without dropping a single active user connection.

Nginx Config Generator

Command Palette