As a second option on Windows, you can use winget. This tool is a package manager that installs the software you want. Just install winget through the Microsoft Store, and then install nginx following its documentation.
My recommended approach is to use Docker. To do this, you can first install Docker and then run nginx using the command below.
docker run --detach --rm --publish 80:80 nginx:stable
If you work as a software engineer or programmer and aren't familiar with Docker, now is a good opportunity to install it and start using it.
If you're on Windows, you can install almost anything using winget. For example, you can install Docker with winget.
To make sure it's installed, just go to localhost or 127.0.0.1 in your browser, and you should see a page like the image below.
The default nginx page
Note: If you're using Windows or macOS, nginx might show the page above on port 8080 by default. In that case, you need to add :8080 at the end of your address. So if the address above doesn't work, you can also try or .
On Windows, also install Make, since we'll use it later on. On macOS and Linux, this tool is available by default. To make sure it's installed, you can run the make -v command, and it should show you the installed version.
GNU make version
Important Files and Paths
/etc/nginx/: By default, nginx's configuration files are located at this path.
/etc/nginx/nginx.conf: This file is, by default, the starting point for loading the rest of the configuration. It contains some initial settings related to HTTP web servers as well as settings related to writing logs, and it then loads the rest of the configuration from /etc/nginx/conf.d/.
/etc/nginx/conf.d/: By default, any file with a conf extension that you create inside this directory is loaded as configuration.
/var/log/nginx/: At this path, we can see two files, access.log and error.log, where access logs and error logs are stored, respectively.
Basic Console Commands
nginx -h: This command acts as a help command. Using it, you can see the list of other commands and how to use them.
nginx -v: This command shows you your nginx version.
nginx -V: In addition to the nginx version, this command gives you more information about nginx's configuration and modules.
nginx -t: This command checks the correctness of your configuration, which is by default at /etc/nginx/, and reports the result to you.
nginx -T: This command is like the previous one, except it prints the checked configuration to the screen.
nginx -s signal: Using this command, you can send certain signals to nginx. The signal can be stop, quit, reload, or reopen.
stop causes nginx to stop immediately.
quit causes nginx to first finish the requests it has received, and then stop.
reload causes nginx to reread the configuration and adjust itself accordingly.
reopen causes nginx to reopen the log files.
In the example below, we've sent each of the signals to nginx separately:
After changing Nginx's configuration, you must run the nginx -s reload command once for the changes to take effect.
What Are Events and the Event Loop?
Before we can explain nginx's architecture, you need to know what an event loop is and how it works. In the world of computers, an event means something that has happened and that needs a reaction.
The event loop acts like a continuous loop that's always listening for events, and as soon as an event occurs, it processes it.
Every event loop has a queue where events are placed in order. The event loop then takes these events out of the queue one by one and processes them.
Simply put, an event loop does the following steps:
It waits to receive an event (for example, receiving a user's request).
When it receives an event, it runs the function that handles it (for example, showing a page of the website).
If the processing requires waiting (for example, reading a file from disk), it does that asynchronously and immediately moves on to the next event.
Once the asynchronous operation finishes, its result goes back into the event queue so processing can continue at the right time.
A Real-World Example for a Better Understanding: Fast Food
To make the concept of the Event Loop easier to understand, imagine you're at a fast-food restaurant:
Customers, like events, join the queue one by one.
There's only one cashier on site, responsible for handling orders. This cashier plays the role of the Event Loop.
The process works as follows:
Every time a customer reaches the front of the line, the cashier records their order.
Without delay, the cashier immediately moves on to the next customer, even if the previous customer's order isn't ready yet.
The key point here is that the cashier never waits for a customer's order to be ready. If preparing the order takes time, they tell the customer: "Please have a seat; we'll call you once the food is ready."
This approach reflects asynchronous behavior; that is, the order-taking process doesn't stop, and the cashier, without waiting, keeps handling other events (customers).
Architecture and How It Works
Put simply, nginx's architecture is event-based and asynchronous, implemented as a master-worker model.
In nginx, there are two main types of processes:
At most one master process
At least one worker process
The Master Process
At most one master process runs, and it has the following responsibilities:
Reading and loading the configuration file (nginx.conf)
Creating and managing worker processes
Performing administrative operations, such as graceful restarts, running signals (reload, stop, etc.), and monitoring the health of workers (if a worker runs into trouble or an error, it restarts it)
The Worker Process's Responsibilities
Usually, several worker processes run, and they have the following responsibilities:
Managing connections (TCP, UDP)
Processing requests
Sending responses to requests
The number of worker processes can be specified in the configuration using the worker_processes directive.
worker_processes 5;
Default Configuration
As we mentioned, /etc/nginx/nginx.conf is the file that Nginx uses by default to load its configuration. By default, this file has settings similar to the following:
In this section, we'll briefly go over each directive so you get an initial understanding of the configuration. In later parts, we'll explain each directive in detail.
On the first line, the user directive specifies the permissions of the worker processes created by nginx. This directive's structure can look like this:
user user [group]
The user parameter refers to the username, and the group parameter refers to the group name. If we don't specify group, the username is also used as the group. [documentation]
On the second line, we specify the number of worker processes; here, auto is used, meaning nginx determines the number of worker processes based on the CPU's capacity and core count. [documentation]
The error_log directive takes two parameters. The first parameter specifies the path where error logs are written, and the second specifies the logs' severity level. Here, it's specified that errors of at least notice level are written to the log.
pid specifies the path of the file that will hold the master process's ID. Using this ID, nginx can receive and handle the signals we send with the nginx -s command.
The events block handles settings related to event loops. We mentioned earlier that every worker process has an internal event loop. Using the worker_connections directive, you can specify the maximum number of simultaneous connections each worker process can accept.
The http block contains settings related to the HTTP protocol.
On the first line, the include directive adds the /etc/nginx/mime.types file into the current configuration. This file contains a list of file extensions along with their content-type. For example, it specifies that if a file's extension is txt, the plain/text header should be used when sending that file to the client.
On the next line, the default_type directive specifies that if a file's type can't be detected, the application/octet-stream header should be used for it by default.
The next two lines relate to the log format and where logs are stored. The log_format directive takes two parameters. The first is the name we give to the format, and the second is the format we want for writing logs. Then, in the access_log directive, the path for storing logs is specified first, followed by the log format, referenced by its name.
The keepalive_timeout directive specifies how long each connection lives. Here, it's specified that each connection lives for at most 65 seconds. This way, a user's browser can make several requests using just one connection, and it doesn't need to open several connections to the server to load a web page's files and images.
On the last line, the include directive loads every file with a conf extension from /etc/nginx/conf.d into the http block. So any configuration you place at this path is treated as configuration for the HTTP protocol.