Nginx is a web server and mail proxy server that has been publicly available since 2004. The development of the project began in 2002, in Russian the name sounds like engin-ex. The creation of the hands of the famous programmer Igor Sysoev, Nginx was originally intended for Rambler. It is designed for operating systems belonging to the Unix-like group. The assembly was successfully tested on OpenBSD, FreeBSD, Linux, Mac OS X, Solaris. On the platform Microsoft Windows Nginx started working with the release of the 0.7.52 binary build.

Statistics for March 2011 show that the number of sites served by Nginx has already crossed the 22 million mark. Today Nginx is used by such well-known projects as Rambler, Begun, Yandex, SourceForge.net, WordPress.com, vkontakte.ru and others. Along with lighttpd, Nginx is used to serve static content generated by an "inconvenient" web application running under another web server.
But before delving into the jungle of functional features of Nginx - it is useful to remember what a web server in general and a proxy server in particular is.

Web server and proxy server

Web server is a server that accepts HTTP requests from web browsers and other clients and issues HTTP responses to them. The latter are usually represented by an HTML page, media stream, image, file, and other data. A web server is understood as software that implements web server functions, as well as hardware. The exchange of data and requested information is carried out via the HTTP protocol.

The list additional functions web servers includes: authorization and authentication of users, logging of their requests to resources, HTTPS support for secure switching with clients and others. The most commonly used web server in Unix-like operating systems is Apache. The third line in the list of client preferences is currently occupied by Nginx.

Proxy server allows customers to handle search queries To network services in an indirect form. That is, it is a server that specializes in forwarding client requests to other servers. By connecting to a proxy server and requesting a resource located on another server, the client has the ability to maintain anonymity and protect the computer from network attacks... The proxy server issues the requested data to the client either from its own cache (if any) or receiving it from the specified server. In some cases (to achieve the above goals), the server's response, like the client's request, can be changed by the proxy server.

The simplest proxy server is considered to be the Network Address Translator or NAT. In 2000, proxy NAT was built into the Windows distribution. Proxy servers, like any phenomenon, have two sides of the coin, that is, they can be used both for good and for evil. For example, with their help those who fear sanctions for their unseemly actions on the network hide their IP addresses ...

Functional range of Nginx:

• server maintenance of index files, static queries, generation of cache descriptors open files, file list;
• accelerated proxying, elementary load distribution, fault tolerance;
• support for caching during accelerated proxying and FastCGI;
• support for FastCGI (accelerated) and memcached servers;
• modularity, filters, including "resume" (byte-ranges) and compression (gzip);
• HTTP authentication, chunked responses, SSI filter;
• parallel execution of several subrequests on the page processed through FastCGI or proxy in the SSI filter;
• StartTLS and SSL support;
• the ability to support embedded Perl;
• simple authentication (USER / PASS, LOGIN);
• server redirection (IMAP / POP3 proxy) of the user to the IMAP / POP3 backend using an external authentication server (HTTP).

For those who are not familiar with this terminology, the description of the functionality of Nginx may seem rather vague. But when it comes to ways of concrete use of this web server - it will begin to fade little by little.

Architecture and configuration

Nginx worker processes serve multiple connections simultaneously, providing them with OS (operating system) calls epoll (Linux), select, and kqueue (FreeBSD). The data received from the client is parsed by a state machine. The parsed request is handled by the configuration-specified module chain. Formation of a response to the client occurs in buffers, which can point to a section of a file or store data in memory. The sequence of data transmission to the client is determined by the chains in which the buffers are grouped.

Structurally, the Nginx HTTP server is divided into virtual servers, which in turn are divided into locations. Virtual server or the directive can be used to specify ports and addresses for accepting connections. Location can be specified with an exact URI, part of a URI, or a regular expression. For on-the-fly memory management, pools are a sequence of pre-selected blocks of memory. One block initially allocated for the pool has a length of 1 to 16 kilobytes. It is divided into areas - occupied and unoccupied. As the latter is filled, the selection of a new object is provided by the formation of a new block.

Geographic classification of clients by their IP address is done in Nginx using special module... The Radix tree system allows you to quickly work with IP addresses, taking up a minimum of memory.

Benefits of Nginx

Nginx is considered to be very fast HTTP server... Instead of or in conjunction with Apache, Nginx is used to speed up request processing and reduce the load on the server. The fact is that the vast capabilities provided by the modular Apache architecture are not required by most users. Paying for this unclaimed functionality is a significant waste of system resources. For ordinary sites, as a rule, there is a clear dominance of static files (images, style files, JavaScript), and not scripts. No special functionality is required to transfer these files to the resource visitor, since the task is very simple. This means that the web server for processing such requests must be simple and lightweight, like Nginx.

Ways to Use Nginx

On a separate port / IP. If the resource is full of images or files for downloading, Nginx can be configured on a separate port or IP and serve static content through it. To do this, however, you have to tinker a bit with changing links on the site. With a large number of requests to static files, it makes sense to create a separate server and install Nginx on it.

Accelerated proxying... With this option, all visitor requests go to Nginx first. Nginx handles requests for static files (such as an image, plain HTML, JavaScript, or CSS file) on its own. If the user contacts a particular script, he forwards the request to the Apache department. You don't need to make any transformations with the site code.

If the channel from the server to the visitor and vice versa is slow, this use of Nginx can give an additional effect. The request received from the visitor is passed to Nginx for processing by Apache. After processing the request, Apache directs the Nginx page and terminates the connection with a sense of accomplishment. Nginx can now send a page to a user for as long as necessary, practically without consuming system resources. Apache running in its place would be accompanied by an unreasonably high memory load when it was almost idle. By the way, this use case for Nginx has another name: "Frontend to Apache".

Nginx plus FastCGI. Apache may not be needed at all if the interpreter of the language in which the site scripts are written supports FastCGI technology. Such languages ​​include, for example, PHP, Perl and a number of others. However, in this case, you may have to modify the script codes.

There are many detailed materials on how to install and configure Nginx on the network. You can learn more about Nginx on the website of its developer Igor Sysoev.

A dedicated nginx-based web server is a great way to improve the performance of your web sites. In the processing speed of static content, it simply has no equal: it easily withstands several thousand simultaneous connections and can be easily optimized and adjusted for any configuration. But? As a front-end for Apache, nginx turns out to be the most vulnerable point of the entire Web infrastructure, therefore, special attention must be paid to the security of nginx.

This article is a kind of educational program, or, if you like, a summary of all the techniques for increasing the security of nginx. There will be no theory, no description of the basics of setting up a Web server, or anything else. Instead, you get exhaustive practical material, which outlines all the basic steps you need to take to get a truly secure Web server.

Installation

The nginx package is available precompiled for any distribution. However, by building the server yourself, you can make it more compact and reliable, and you can also change the Web server's greeting line to discourage unintelligent script kiddies.

Change the welcome line of the web server

Download the nginx sources, open the src / http / ngx_http_header_filter_module.c file and find the following two lines:

static char ngx_http_server_string = "Server: nginx" CRLF;
static char ngx_http_server_full_string = "Server:" NGINX_VER CRLF;

Replace them with something like this:

static char ngx_http_server_string = "Server:] [ Web Server"CRLF;
static char ngx_http_server_full_string = "Server:] [Web Server" CRLF;

Remove all nginx modules you are not using

Some nginx modules connect to the web server right at compile time, and any of them is potentially dangerous. Perhaps, in the future, a vulnerability will be found in one of them, and your server will be at risk. By disabling unnecessary modules, you can significantly reduce the risk of such a situation.

Build with the following commands:

# ./configure --without-http_autoindex_module --without-http_ssi_module
# make
# make install

This will give you nginx with the SSI (Server Side Includes) and Autoindex modules disabled (and in most cases useless). To find out which modules can be safely thrown out of the Web server, run the configure script with the ‘-help’ flag.

Dissecting nginx.conf

After installation, nginx should be configured. On the pages of the magazine there was already material describing this process, but we will stick to the topic of the article and talk about ways to improve server security.

Disable showing server version on all error pages

Add the line “server_tokens off” to the nginx.conf file. This will cause nginx to hide the type and version of the Web server on pages generated in response to an erroneous client request.

Set up protection against stack breaks

Add to the server section following lines:

# vi /etc/nginx/nginx.conf

# Maximum size a buffer for storing the body of the client's request
client_body_buffer_size 1K;
# Maximum buffer size for storing client request headers
client_header_buffer_size 1k;
# The maximum size of the client's request body, as specified in the Content-Length field of the header. If the server needs to support file uploads, this value must be increased
client_max_body_size 1k;
# Number and size of buffers for reading large client request header
large_client_header_buffers 2 1k;

Pay attention to the directive large_client_header_buffers. By default, nginx allocates four buffers to store the URI string, each of which is equal to size memory pages (for x86 it is 4 KB). The buffers are released every time the connection enters the keep-alive state after the request is processed. Two 1KB buffers can store only 2KB URIs, which allows you to fight bots and DoS attacks.

Add the following lines to improve performance:

# vi /etc/nginx/nginx.conf

# Timeout while reading client request body
client_body_timeout 10;
# Timeout while reading client request header
client_header_timeout 10;
# Timeout after which the keep-alive connection with the client will not be closed by the server
keepalive_timeout 5 5;
# Timeout when sending a response to the client
send_timeout 10;

Control the number of simultaneous connections

To protect the Web server from overload and DoS attempts, add the following lines to the config:

# vi /etc/nginx/nginx.conf

# Describe the (slimits) zone where the session states will be stored. A 1 MB zone can store about 32000 states, we set it to 5 MB
limit_zone slimits $ binary_remote_addr 5m;
# Set the maximum number of simultaneous connections for one session. In fact, this number sets the maximum number of connections from one IP
limit_conn slimits 5;

The first directive should be in the HTTP section, the second in the location section. When the number of connections exceeds the limits, the client will receive a "Service unavailable" message with a 503 code.

Allow connections only to your own domain

Hackers can use bots to scan subnets and find vulnerable Web servers. Typically, bots simply go through IP ranges looking for 80 open ports and send a HEAD request to get information about the web server (or home page). You can easily prevent such a scan by disallowing access to the server by IP address (add to the location subsection):

# vi /etc/nginx/nginx.conf

if ($ host! ~ ^ (host.com | www.host.com) $) (
return 444;
}

Limit the number of available methods for accessing the web server

Some bots use different methods calls to the server to try to determine its type and / or penetration, however RFC 2616 clearly states that the web server does not have to implement all of them, and unsupported methods may simply not be processed. Today, only the GET (document request), HEAD (server header request) and POST (document publication request) methods remain in use, so all others can be painlessly disabled by placing the following lines in the server section of the configuration file:

# vi /etc/nginx/nginx.conf

if ($ request_method! ~ ^ (GET | HEAD | POST) $) (
return 444;
}

Chuck bots

Another way to block bots, scanners and other evil spirits is based on determining the type of client (user-agent). It is not very effective, because most bots mimic completely legitimate browsers, but in some cases it remains useful:

# vi /etc/nginx/nginx.conf

# Block download managers
if ($ http_user_agent ~ * LWP :: Simple | BBBike | wget) (
return 403;
}
# Block some types of bots
if ($ http_user_agent ~ * msnbot | scrapbot) (
return 403;
}

Block Referrer Spam

If your site publishes Web logs in the public domain, you can easily become a victim of Referrer spam (when spam bots contact your server, specifying the address of the advertised site in the referrer header). This type of spam can easily spoil the SEO rankings of a web page, so it is imperative to block it. One way to do this is to blacklist the most common words found in the URLs of advertised sites.

# vi /etc/nginx/nginx.conf

# Server section
if ($ http_referer ~ * (babes | forsale | girl | jewelry | love | nudit | organic | poker | porn | sex | teen))
{
return 403;
}

Block hotlink

Hotlink is the inclusion of an image (or other content) from another site into a page. In fact, this is theft, because the image on which you spent more than one hour of your free time is not only freely used by others, but also creates a load on your Web server without bringing visitors to it. To combat hotlinks, it is enough to make sure that the images are given to the client only if he requested them while already on the site (in other words, the referrer request header must contain the name of your site). Add the following lines to the server section of the nginx.conf configuration file (host.com is your site address):

# vi /etc/nginx/nginx.conf

location / images / (
valid_referers none blocked www.host.com host.com;
if ($ invalid_referer) (
return 403;
}
}

Alternatively, you can configure the server to serve special banner with a theft message instead of the requested image. To do this, replace the line "return 403" with the line:

rewrite ^ / images / uploads. * \. (gif | jpg | jpeg | png) $ http://www.host.com/banned.jpg last

Protect important directories from strangers

Like any other Web server, nginx allows you to regulate directory access based on IP addresses and passwords. This feature can be used to close some parts of the site from prying eyes... For example, to strip a URI from the outside world:

# vi /etc/nginx/nginx.conf

location / uploads / (
# Allow access only to machines on the local network
allow 192.168.1.0/24;
# Sewing off everyone else
deny all;
}

Now only users of the local network will have access to the documents of the uploads directory. To set a password, you will have to do more complex steps. First, you need to create a private password file for nginx and add the necessary users to it (as an example, let's add the admin user):

# mkdir /etc/nginx/.htpasswd
# htpasswd -c /etc/nginx/.htpasswd/passwd admin

# vi /etc/nginx/nginx.conf

location / admin / (
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd/passwd;
}

New users can be added using the following command:

# htpasswd -s /etc/nginx/.htpasswd/passwd user

Use SSL

If your site works with private user data, such as numbers credit cards, passwords from other services, or provides access to another important information, which can become a tidbit for third parties, take care of encryption. Nginx works well with SSL and shouldn't be overlooked.

To configure SSL encryption using nginx, you just need to follow a few simple steps. First, you must create a certificate using the following sequence of commands:

# cd / etc / nginx
# openssl genrsa -des3 -out server.key 1024
# openssl req -new -key server.key -out server.csr
# cp server.key server.key.org
# openssl rsa -in server.key.org -out server.key
# openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

Then describe the certificate in the nginx configuration file:

# vi /etc/nginx/nginx.conf

server (
server_name host.com;
listen 443;
ssl on;
ssl_certificate /etc/nginx/server.crt;
ssl_certificate_key /etc/nginx/server.key;
access_log /etc/nginx/logs/ssl.access.log;
error_log /etc/nginx/logs/ssl.error.log;
}

After that, you can restart the web server:

# /etc/init.d/nginx reload

Naturally, without the support of the Web site itself, it makes no sense to do this.

other methods

Set the correct values ​​for system variables

Open the file /etc/sysctl.conf and put the following lines in it:

# vi /etc/sysctl.conf

# Protection against smurf attacks
net.ipv4.icmp_echo_ignore_broadcasts = 1
# Protection against incorrect ICMP messages
net.ipv4.icmp_ignore_bogus_error_responses = 1
# SYN flood protection
net.ipv4.tcp_syncookies = 1
# Disable source routing
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
# Protection against spoofing
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
# We are not a router
net.ipv4.ip_forward = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
# Turn on ExecShield
kernel.exec-shield = 1
kernel.randomize_va_space = 1
# Expand the range of available ports
net.ipv4.ip_local_port_range = 2000 65000
# Increase the maximum size of TCP buffers
net.ipv4.tcp_rmem = 4096 87380 8388608
net.ipv4.tcp_wmem = 4096 87380 8388608
net.core.rmem_max = 8388608
net.core.wmem_max = 8388608
net.core.netdev_max_backlog = 5000
net.ipv4.tcp_window_scaling = 1

Place the root directory of the web server on a dedicated partition

By placing the root directory of the Web server in a dedicated partition and disallowing any executable or device files on it, you can protect the rest of the system from anyone who can access the root of the Web server. In this case, the entry in the / etc / fstab file should look something like this:

/ dev / sda5 / nginx ext4 defaults, nosuid, noexec, nodev 1 2

Put nginx in chroot / jail environment

Any modern * nix-system allows you to lock an application in an isolated execution environment. On Linux, you can use KVM, Xen, OpenVZ and VServer technologies for this, on FreeBSD - Jail, on Solaris - Zones. If none of these technologies are available, you can put nginx in a classic chroot, which, although much more fragile, can be stopped by most crackers.

Set up SELinux rules to protect nginx

A good alternative isolated environments executions are local intrusion detection and prevention systems such as SELinux or AppArmor. When configured correctly, they can prevent attempts to compromise the Web server. By default, none of them is configured to work in conjunction with nginx, but within the project SELinuxNginx(http://sf.net/projects/selinuxnginx/) rules have been created for SELinux that anyone can use. All that remains is to download and install:

# tar -zxvf se-ngix_1_0_10.tar.gz
# cd se-ngix_1_0_10 / nginx
# make
# / usr / sbin / semodule -i nginx.pp

Configure a firewall

Typically, nginx is installed on dedicated machines that are ready for heavy workloads, so it often remains the only network service running on the server. To secure the server, it is enough to create a very small set of rules that will open ports 80, 110 and 143 (if, of course, nginx should also work as an IMAP / POP3 proxy) and close everything else from the outside world.

Limit the number of connections with a firewall

For a lightweight Web site, it's a good idea to limit the number of connection attempts from one IP address per minute. This can save you from some types of DoS attacks and brute-force attacks. On Linux, this can be done using the standard iptables / netfilter state module:

# iptables -A INPUT -p tcp --dport 80 -i eth0 \
-m state --state NEW -m recent --set
# iptables -A INPUT -p tcp --dport 80 -i eth0 \
-m state --state NEW -m recent --update \
--seconds 60 --hitcount 15 -j DROP

The rules cut the limit on the number of connections from one IP per minute to 15. The same can be done using pf:

# vi /etc/pf.conf

webserver_ip = "1.1.1.1"
table persist
block in quick from
pass in on $ ext_if proto tcp to $ webserver_ip \
port www flags S / SA keep state \
(max-src-conn 100, max-src-conn-rate 15/60, \
overload flush)

In addition to the limit on the number of consecutive connections (15 per minute), this rule sets an additional limit on the number of simultaneous connections equal to 100.

PHP setup

If you are using nginx in conjunction with PHP, do not forget to configure it as well. This is how the secure server configuration file /etc/php/php.ini should look like:

# vi /etc/php/php.ini

# Disable dangerous functions
disable_functions = phpinfo, system, mail, exec
# Maximum script execution time
max_execution_time = 30
# The maximum time that a script can spend processing request data
max_input_time = 60
# The maximum amount of memory allocated to each script
memory_limit = 8M
# The maximum size of data sent to the script using the POST method
post_max_size = 8M
# Maximum size of uploaded files
upload_max_filesize = 2M
# Don't show PHP script errors to users
display_errors = Off
# Turn on Safe Mode
safe_mode = On
# Enable SQL Safe Mode
sql.safe_mode = On
# Allow to execute external commands only in this directory
safe_mode_exec_dir = / path / to / protected / directory
# Protecting against PHP information leaks
expose_php = Off
# Keeping logs
log_errors = On
# Prohibit opening remote files
allow_url_fopen = Off

conclusions

By applying the guidelines outlined in this article, you will have a much more secure Web server. But keep in mind that not all techniques will fit your configuration. For example, brute force protection based on cutting the size of buffers allocated by nginx for processing client requests can lead to a performance degradation and, in some cases, to failures in request processing. Limiting the number of connections will have a major impact on the performance of even a moderately loaded Web site, but will be beneficial if the page has a low flow of visitors. Always check how the changes you made have affected the performance and overall health of your Web page.

About the hero of the day

Nginx is one of the most powerful and popular Web servers in the world. According to Netcraft, it is used to power more than 12 million websites worldwide, including the likes of Rambler, Yandex, Begun, WordPress.com, Wrike, vkontakte.ru, megashara.com, Librusek, and Taba.ru. A competent architecture based on multiplexing connections using the select, epoll (Linux), kqueue (FreeBSD) system calls and a memory management mechanism based on pools (small buffers from 1 to 16 KB), allows nginx not to sag even under very high loads, withstanding over 10,000 concurrent connections (so-called C10K problem). Originally written by Igor Sysoev for Rambler and opened in 2004 under a BSD-like license.

In contact with

Nginx? Purpose, features, customization options are things that every web developer should be familiar with in order to test their best practices.

Let's say a word about nginx

This tool has one main and several workflows. The first deals with reading and checking the configuration. He also controls the management of work processes. The task of the latter is to process incoming requests. Nginx uses an event-based model. It also uses operating system-dependent mechanisms to achieve efficient distribution of requests directly between worker processes. Their number is always indicated in the configuration file. The value can be either fixed or set automatically, being guided by the number of processor cores that you can work with. In nginx, the system and modules are configured using a configuration file. Therefore, if it is necessary to change something, then it is necessary to look for it. It is usually found in the / etc / nginx directive (but the path may change when using other systems) and has a .conf extension.

Startup, reboot and logs

To do this, you need to get the executable to work. The nginx server can be configured only when it is running. Control is carried out by calling the executable file with the -s parameter. To do this, use the following entry:

nginx -s signal

V in this case You can substitute the following commands (must come from the user that launched the tool):

1. Stop. Is used for quick completion work.
2. Reload. The command is needed to reload the configuration file. The point is that any changes will not be applied while the file is running. And for them to take effect, a reboot is required. As soon as this signal is received, the main process will begin to check the correctness of the syntax of the configuration file and try to apply the instructions provided there. If unsuccessful, it will rollback the changes and work with the old parameters. If everything went well, then new worker processes will be launched, and a request will be sent to the old ones to complete.
3. Quit. Used for smooth shutdown. It is used if it is necessary to wait until the current requests are finished being serviced.
4. Reopen. Close and open log files.

Using utilities

Processes can also be configured using Unix tools (the kill utility will be considered as an example). They usually use a mechanism to send a signal to a process directly with data. They are linked using ID. This data is stored in the nginx.pid file. Let's say that we are interested in process # 134. Then, for a smooth completion, we need to send the following information:

kill -s QUIT 1628

Let's say we want to view a list of all running files... We use the ps utility for this. The command will look like this:

ps -ax | grep nginx

That is, as you can see, when using additional tools, it is indicated that it is being used. Now let's focus on how the nginx configuration is done.

Configuration file structure

Installing and configuring nginx involves working with modules. They are configured using directives that are specified in the configuration file. They are simple and blocky. The first type of directive consists of a name and parameters, which are separated by spaces, and their end is indicated by a semicolon - (;). The block has a similar structure. But in this directive, instead of the end, the set is placed additional instructions that are placed in curly braces ((directions)). If names and parameters of other processes can be placed in them, then such constructions are called context. Examples include http, location and server.

Serving static content

This is one of the most important tasks facing the nginx configuration. Serving statistical content means images and HTML pages (not dynamic). Let's say that we need a one-time job on setting up a nix nginx cluster. Is it difficult to do it? No, and let's look at an example. Before proceeding with it, it is necessary to detail the conditions of the problem. So, depending on the requests, the files will come from different local directories. So in / data / www we have HTML documents. And the / data / images directory contains images. The optimal configuration of nginx in this case requires editing the configuration file, in which it is necessary to configure the server block inside http. Two locations will also be used for support.

Implementation: server

So, first, we need to create the directories themselves and place files with the necessary extensions in them (content must be added to the html). Then we open the configuration file. By default, it already has several server blocks, which are mostly commented out. To achieve the best result, this process must be done with respect to all default components. Then we add a new server block with the following code:

The configuration file can work with several such blocks. But they should differ in their names and ports through which data is received.

Implementation: location

Defined inside server:

The presence of the "/" sign is necessary to compare the received data and see if there is such an address from the processed request here. If there are no problems, then we indicate the path / data / www to required file what is in this local system... If there is a match with several blocks, then the one with the longest prefix is ​​selected. In the given example, its length is equal to one, that is, it will be used exclusively if there are no "competitors". Now let's improve it:

location / images / (

As you can tell, we are looking for images. Now let's combine all the developments that were earlier, and the configuration at the moment looks like this:

location / images / (

This is a working version, which happens to be a standard one.This server can be accessed without problems on local computer if you go to the address: http: // localhost /. How will this all work?

How the example works

So, when requests come that start with / images, the server will send files from the corresponding directory to the user. If it is absent, information indicating a 404 error will be transmitted. If nginx is configured on the local computer, then upon requesting http: //localhost/images/example.png, we will receive a file whose location is /data/images/example.png. If you specify one character "/", the search will be carried out in the / data / www directory. But we only changed the configuration. In order for it to start working, it needs to be rebooted. To do this, use the nginx -s reload command. In the case when normal work is not possible, then in the error.log and access.log files located in the / usr / local / nginx / logs directive, you can search for the cause of the failure.

Creating a simple proxy server

As far as nginx is concerned, configuring this object is one of the most common uses (and pretty easy, by the way). It uses the principle of a server that accepts a request, and then redirects them to the necessary sites. After that, a response is expected from them, which directs them to the one who set the task. So let's look at an example of creating a base point. It will serve user requests and provide them with images from the local directory. So, add another server to the http block with the following content:

Now let’s decipher for you: a simple server is being created. It will listen Do not specify listen, then the server will work on 80th. All requests within the local area will be displayed. file system that are directed to the / data / up1 directory (of course, it will need to be created before that). To be able to check it, you need to place the index.html file there. By placing the root directive in the server context, we will be able to use the location under any conditions (since this removes access restrictions). Now we are working on creating a proxy server. For it to work, we need the proxy_pass directive, for which the protocol, name, and port of the object will be specified as parameters (if local connection it will look like http: // localhost: 8080). You get the following result:

proxy_pass http: // localhost: 8080;

location / images / (

If you look at the code and analyze it, you will notice that the second location block has been changed. So, in this case, it can work with typical image extensions. A little differently, it could be displayed in this way:

location ~ \. (gif | jpg | png) $ (

root / data / images;

The final proxy configuration looks like this:

proxy_pass http: // localhost: 8080 /;

location ~ \. (gif | jpg | png) $ (

root / data / images;

It will filter out requests that have the specified extensions at the end and send them to whoever asked for the files. Do not forget that if you want to check the configuration file, you will need to reload it. And believe me, this is the simplest nginx setup. If you open the configuration file of the Vkontakte server or another large company, they will have more code than there are words in this article.

One of the most popular web servers

Nginx is very popular among web and proxy server users due to its performance. The server has many advantages, but it can be difficult for a beginner to set up. We want to help you figure out the configuration files, syntax, and basic Nginx settings.

Directory hierarchy

All server configuration files are located in the / etc / nginx directory. In addition, there are several more folders inside the directory, as well as modular configuration files.

cd / etc / nginx
ls -F
conf.d / koi-win naxsi.rules scgi_params uwsgi_params
fastcgi_params mime.types nginx.conf sites-available / win-utf
koi-utf naxsi_core.rules proxy_params sites-enabled /

If you've used Apache, you should be familiar with the sites-enabled and sites-available directories. They determine the configuration of the sites. The generated files are stored in the last directory. The sites-enabled folder is needed to store configurations of only activated pages. To link them, you need a symbolic link between the folders. Configurations can also be stored in the conf.d directory. At the same time, during Nginx startup, each file with the .conf extension will be read over again. When writing configuration files, type the code correctly and follow the syntax. All other files are located in / etc / nginx. The configurator contains information about specific processes as well as additional components.

The main Nginx configuration file is nginx.conf.

It reads all configuration files, merging them into one, which is requested when the server starts. Open the file with:

sudo nano /etc/nginx/nginx.conf

The following lines will appear on the screen:

user www-data;
worker_processes 4;
pid /var/run/nginx.pid;
events (
worker_connections 768;
# multi_accept on;
}
http (
. . .

The first is general information about Nginx. The phrase user www-data refers to the user who starts the server. The pid directive shows where the PID processes are located. internal use... The line worker_processes shows how many processes Nginx can run at the same time. In addition, you can specify logs here (for example, the error log is defined using the error_log directive). Below is the events section. It is needed to handle server connections. After it is the http block.

Nginx configuration file structure

Understanding the file formatting structure will help you better understand your web server configuration. It is divided into structural blocks... The configuration details of the http block are layered using private blocks. They inherit properties from their parent, i.e. the one in which they are located. This block stores most of the server configurations. They are divided into server blocks, inside which the location is located.

When configuring your Nginx server, remember that the lower the configuration block is, the fewer items will inherit properties, and vice versa. The file contains a large number of options that change the operation of the server. You can set the compression of files sent to the client, for example. To do this, write the parameters:

gzip on;
gzip_disable "msie6";

Keep in mind that the same parameter can take different meanings v different blocks... First set it at the top, then override the parameter to the right level... If the last action is not performed, the program will set the values ​​in automatic mode.

The last lines of the nginx.conf file are:

include /etc/nginx/conf.d/*.conf;
include / etc / nginx / sites-enabled / *;

They indicate that the location and server blocks are stored outside of this file. They define the settings for urls and specific files. This structure is necessary to maintain a modular configuration structure. Inside it, you will be able to create new directories, files for various sites. Besides, similar files you will be able to group. After reviewing, you can close the nginx.conf file.

Virtual blocks

They are analogous to virtual hosts in Apache. The server section blocks include the characteristics of individual sites that are located on the server. In the sites-available folder, you will find the default server block file. Inside it, you can find outside the necessary data that may be required when maintaining sites.

cd sites-available
sudo nano default
server (
root / usr / share / nginx / www;
index index.html index.htm;
server_name localhost;
location / (
try_files $ uri $ uri / /index.html;
}
location / doc / (
alias / usr / share / doc /;
autoindex on;
allow 127.0.0.1;
deny all;
}
}

In the above example, commenting was deliberately removed. This was done for readability. Inside the server blocks are the settings enclosed in curly braces:

This block is placed using the include directive at the end of the http specified in the nginx.conf file. The root directive defines the directory where the site content will be located. In it, the program will search for files that the user will request. The default path is / usr / share / nginx / www. Nginx separates lines or directives from one another with semicolons. If you do not put a punctuation mark, several lines will be read as one. To write the rules that will be used as an index, use the index directive. The server will check them in the order they are listed. If none of the available pages were requested by the user, index.html will be returned. If it is not there, the server will look for index.htm.

Server_name rule

It includes a list of domain names to be processed by the server block. You can write any number of them, separating them with spaces. If you put * at the end or beginning of a domain, you will be able to specify a name with a mask. The asterisk matches part of the name. If you register * .com.ua, then all addresses of the specified domain zone... If the address matches the description of several directives, then it will respond with the one that fits completely. If there is no match, the answer will be the longest name that has a mask. Otherwise, regular expressions will be matched. Server names that use regular expressions start with a tilde (~).

Location blocks

Next in line we will have a location block. It is needed to determine the processing method certain requests... If the resources do not correspond to any other location blocks, then the directives specified in brackets will be applied to them. These blocks can include a path like / doc /. To establish a complete correspondence between uri and location, the = sign is used. Applying the tilde will match the regular expressions. You can also set the case sensitivity by putting ~. If you add an asterisk, the case does not matter.

Keep in mind: when the request matches the location block, it will be used and the search will stop. When the match is incomplete, the URI will be compared against the parameters of the location directives. A block with the combination ^ ~ is used to match the URI for the block selection. If this option do not use, the server chooses the best match and also searches using regular expressions. This is necessary to select one of the suitable templates. If a matching expression is found, it will be used. Otherwise, the previous URI match will be applied. However, keep in mind that Nginx likes full matches more. If they are not there, it will start searching for regular expressions, and then by URI. Search parity is specified by the ^ ~ character combination.

Try_files rule

It is very useful tool capable of checking for files in a specified order. It applies the first matching criteria to process the request. you can use Extra options to define how the server will serve requests. The configurator has a default line like this:

try_files $ uri $ uri / /index.html;

What does it mean? If a request comes in that is served by a location block, the server will first try to process the uri as a file. This is provided by the $ uri variable. When there is no match, the uri will be treated as a directory. You can check its existence by adding a slash at the end: $ uri /. There are situations when neither the file nor the directory will be found. In this case, the default file index.html will be loaded. Try_files rule applies last parameter as a fallback. That's why this file must be in the system. However, if no matches are found at all, Nginx will return an error page. To set it, write = and the error code:

Additional options

If you apply the alias rule, you will be able to serve pages in the location block outside the root directory, for example. When files are needed from doc, they will be requested from / usr / share / doc /. In addition, the autoindеx on rule starts listing the server directories for the specified location directive. If you write the lines deny and allow, you will be able to change access to directories.

As a conclusion, it should be said that Nginx is a very powerful multifunctional tool. But getting a good understanding of how it works will take time and effort. If you understand how configurations work, you can fully enjoy all the features of the program.

Other). Current version, 0.6.x is considered stable in terms of reliability, and releases from the 0.7 branch are considered unstable. It is important to note that the functionality of some modules will change, as a result of which the directives may also change, therefore backward compatibility in nginx prior to version 1.0.0 is not guaranteed.

Why is nginx so good and why do administrators of high-load projects love it so much? Why not just use Apache?

Why is Apache bad?

First, you need to explain how network servers generally work. Those familiar with network programming know that there are essentially three models of server operation:

1. Consistent. The server opens a listening socket and waits for a connection to appear (it is in a blocked state while waiting). When a connection arrives, the server processes it in the same context, closes the connection and waits for the connection again. Obviously, this is far from the best way, especially when the client has been working for a long time and there are a lot of connections. In addition, the sequential model has many more disadvantages (for example, the inability to use multiple processors), and in real conditions it is practically not used.
2. Multiprocess (multithreaded). The server opens a listening socket. When a connection arrives, it accepts it, after which it creates (or takes from a pool of previously created ones) new process or a thread that can work with the connection for an arbitrarily long time, and at the end of the work exit or return to the pool. The main thread, meanwhile, is ready to accept a new connection. This is the most popular model because it is relatively easy to implement, allows complex and time-consuming calculations for each client, and uses all available processors... An example of its use - Apache web server... However, this approach also has disadvantages: with a large number of concurrent connections, a lot of threads (or, even worse, processes) are created, and the operating system wastes a lot of resources on context switches. It's especially bad when customers are very slow to accept content. It turns out hundreds of threads or processes, busy only sending data to slow clients, which creates an additional load on the OS scheduler, increases the number of interrupts and consumes a lot of memory.
3. Nonblocking Sockets / State Machine. The server works within a single thread, but uses non-blocking sockets and a polling mechanism. Those. server at each iteration endless loop selects from all sockets the one that is ready to receive / send data using the select () call. After a socket is selected, the server sends data to it or reads it, but does not wait for confirmation, but goes into the initial state and waits for an event on another socket, or processes the next one, in which the event occurred during the processing of the previous one. This model very efficient use of processor and memory, but rather difficult to implement. In addition, within the framework of this model, processing of an event on a socket must be very fast - otherwise, many events will accumulate in the queue, and eventually it will overflow. This is how nginx works. In addition, it allows you to start multiple worker processes (called workers), i.e. can use multiple processors.

So, imagine the following situation: 200 clients with a 256 Kbps channel are connected to an HTTP server with a 1 Gbps channel:

What happens in the case of Apache? 200 threads / processes are created that generate content relatively quickly (this can be like dynamic pages and static files read from disk), but slowly hand it over to clients. Operating system has to deal with a bunch of threads and I / O locks.

In such a situation, Nginx spends an order of magnitude less OS and memory resources on each connection. However, here a limitation of the nginx network model comes to light: it cannot generate dynamic content inside yourself, because this will lead to blocking inside nginx. Naturally, there is a solution: nginx can proxy such requests (for generating content) to any other web server (for example, the same Apache) or to a FastCGI server.

Let's consider the mechanism of operation of the nginx bundle as the "main" server and Apache as the server for generating dynamic content:

Nginx accepts the connection from the client and reads the entire request from it. It should be noted here that until nginx has read the entire request, it does not submit it for "processing". Because of this, almost all progress indicators of file uploads usually "break" - however, it is possible to fix them using the third-party upload_progress module (this will require modification of the application).

After nginx has read the entire response, it opens a connection to Apache. The latter does its job (generates dynamic content), after which it sends its response to nginx, which buffers it in memory, or temporary file... Meanwhile, Apache frees up resources. Further, nginx slowly sends content to the client, while spending orders of magnitude less resources than Apache.

This scheme is called frontend + backend and is used very often.

Installation

Because nginx is just beginning to gain popularity, there are some problems with binary packages, so be prepared to compile it yourself. This is usually not a problem, you just need to carefully read the output of the command. / Configure --help and select the compilation options you need, for example:

./configure \
--Prefix = / opt / nginx-0.6.x \ # installation prefix
--Conf-path = / etc / nginx / nginx.conf \ # configuration file location
-Pid-path = / var / run / nginx.pid \ # ... and pid file
-User = nginx \ # username under which nginx will run
—With-http_ssl_module —with-http_gzip_static_module —with-http_stub_status_module \ # list of required
—Without-http_ssi_module —without-http_userid_module —without-http_autoindex_module —without-http_geo_module —without-http_referer_module —without-http_memcached_module —without-http_limit_zone_module # ... and not required modules

After configuration, you should run the standard make && make install, after which you can use nginx.

Alternatively, in Gentoo you can use the ebuild from the standard ports tree; in RHEL / CentOS the epel repository (where nginx 0.6.x is located) or srpm for version 0.7, which can be downloaded from here: http://blogs.mail.ru/community/nginx; on Debian, you can use the nginx package from the unstable branch.

Config file

The nginx config file is very convenient and intuitive. It is usually called nginx.conf and is located in $ prefix / conf / if the location was not redefined during compilation. I like to put it in / etc / nginx /, and so do the developers of all the packages mentioned above.

The structure of the configuration file is as follows:

user nginx; # username under which nginx will run
worker_processes 1; # number of worker processes
events (
<…># this block specifies the polling mechanism that will be used (see below) and the maximum number of possible connections
}

Http (
<глобальные директивы http-сервера, например настройки таймаутов и т.п.>;
<почти все из них можно переопределить для отдельного виртуального хоста или локейшена>;

# description of servers (this is what apache calls VirtualHost)
server (
# server address and name
listen *: 80;
server_name aaa.bbb;

<Директивы сервера. Здесь обычно указывают расположение докуменов (root), редиректы и переопределяют глобальные настройки>;

# and this is how you can define location, for which you can also override almost all directives specified at more global levels
location / abcd / (
<директивы>;
}
# Besides, you can make location by regular expression, like this:
location ~ \ .php $ (
<директивы>;
}
}

# another server
server (
listen *: 80;
server_name ccc.bbb;

<директивы>
}
}

Please note that each directive must end with a semicolon.
Reverse proxying and FastCGI

So, above we examined the advantages of the frontend + backend scheme, figured out the installation, structure and syntax of the configuration file, consider now how to implement reverse proxying in nginx.

It's very simple! For example like this:

location / (
proxy_pass http://1.2.3.4:8080;
}

In this example, all requests to location / will be proxied to server 1.2.3.4, port 8080. This can be either apache or any other http server.

However, there are several subtleties related to the fact that the application will assume that, firstly, all requests come to it from one IP address (which can be interpreted, for example, as an attempt at a DDoS attack or brute-force attack), and secondly, consider that it is running on host 1.2.3.4 and port 8080 (respectively, generate incorrect redirects and absolute links). To avoid these problems without having to rewrite the application, the following configuration seems to be convenient to me:
Nginx listens on the external interface on port 80.

If the backend (for example, Apache) is located on the same host as nginx, then it "listens" to port 80 at 127.0.0.1 or another internal IP address.

In this case, the nginx configuration looks like this:

server (
listen 4.3.2.1:80;
# set the Host header and X-Real-IP: to each request sent to the backend
proxy_set_header X-Real-IP $ remote_addr;
proxy_set_header Host $ host: $ proxy_port;
# or "proxy_set_header Host $ host;" if the application will append: 80 to all links
}

In order for the application to distinguish the IP addresses of visitors, you need to either install the mod_extract_forwarded module (if it is executed by the Apache server), or modify the application so that it takes information about the user's IP address from the X-Real-IP HTTP header.

Another backend option is using FastCGI. In this case, the nginx configuration will look something like this:

server (
<…>

# location where requests for php-scripts will be sent
location ~ .php $ (
fastcgi_pass 127.0.0.1:8888; # define the address and port of the fastcgi server,
fastcgi_index index.php; # ... index file

# and some parameters that need to be passed to the fastcgi server so that it understands which script and with which parameters to execute:
fastcgi_param SCRIPT_FILENAME / usr / www / html $ fastcgi_script_name; # script name
fastcgi_param QUERY_STRING $ query_string; # query string
# and request parameters:
fastcgi_param REQUEST_METHOD $ request_method;
fastcgi_param CONTENT_TYPE $ content_type;
fastcgi_param CONTENT_LENGTH $ content_length;
}

#due to the fact that the locations with regular expressions have a high "priority", all non-php requests will go here.

location / (
root / var / www / html /
}

Statics

In order to reduce the load on the backend, it is better to serve static files only through nginx - it copes with this task better, because for each request, it spends significantly less resources (no need to spawn a new process, and the nginx process usually consumes less memory, and can serve many connections).

In the config file, it looks like this:

server (
listen *: 80;
server_name myserver.com;

Location / (
proxy_pass


"> Http://127.0.0.1:80;

}

# assume all static files are in / files
location / files / (
root / var / www / html /; # specify the path to fs
expires 14d; # add the Expires header:
error_page 404 = @back; # and if the file is not found, send it to the named location @back
}

# requests from / files, for which no file was found, are sent to the backend, and it can either generate the desired file or show nice message about the error
location @back (
proxy_pass
"Title =" http://127.0.0.1:80;

"> Http://127.0.0.1:80;

}

If all the statics are not placed in a specific directory, then use a regular expression:

location ~ * ^. + \. (jpg | jpeg | gif | png | ico | css | zip | tgz | gz | rar | bz2 | doc | xls | exe | pdf | ppt | txt | tar | wav | bmp | rtf | js) $ (
# similar to the above, only all requests ending in one of the specified suffixes will be sent to this location
root / var / www / html /;
error_page 404 = @back;
}

Unfortunately, nginx does not support asynchronous file handling. In other words, the nginx worker is blocked on I / O operations. So if you have a lot of static files and especially if they are read from different disks, it is better to increase the number of worker processes (up to a number that is 2-3 times more than the total number of heads on the disk). This, of course, leads to an increase in the load on the OS, but overall performance increases. To work with a typical amount of static (not a very large number of relatively small files: CSS, JavaScript, images), one or two workflows are enough.

To be continued

Links

More information about nginx can be found here: