NGINX Reverse Proxy

Introduction

Proxying is typically used to distribute the load among several servers, seamlessly show content from different websites, or pass requests for processing to application servers over protocols other than HTTP.

Passing a Request to a Proxied Server

When NGINX proxies a request, it sends the request to a specified proxied server, fetches the response, and sends it back to the client. It is possible to proxy requests to an HTTP server (another NGINX server or any other server) or a non-HTTP server (which can run an application developed with a specific framework, such as PHP or Python) using a specified protocol. Supported protocols include FastCGI, uwsgi, SCGI, and memcached.

To pass a request to an HTTP proxied server, the proxy_pass directive is specified inside a location. For example:

<strong>location</strong> /some/path/ {
    <strong>proxy_pass</strong> http://www.example.com/link/;
}

location /some/path/ {

proxy_pass http://www.example.com/link/;

}

This example configuration results in passing all requests processed in this location to the proxied server at the specified address. This address can be specified as a domain name or an IP address. The address may also include a port:

<strong>location</strong> ~ \.php {
    <strong>proxy_pass</strong> http://127.0.0.1:8000;
}

location ~ \.php {

proxy_pass http://127.0.0.1:8000;

}

Note that in the first example above, the address of the proxied server is followed by a URI, /link/. If the URI is specified along with the address, it replaces the part of the request URI that matches the location parameter. For example, here the request with the /some/path/page.html URI will be proxied to http://www.example.com/link/page.html. If the address is specified without a URI, or it is not possible to determine the part of URI to be replaced, the full request URI is passed (possibly, modified).

To pass a request to a non-HTTP proxied server, the appropriate **_pass directive should be used:

fastcgi_pass passes a request to a FastCGI server
uwsgi_pass passes a request to a uwsgi server
scgi_pass passes a request to an SCGI server
memcached_pass passes a request to a memcached server

Note that in these cases, the rules for specifying addresses may be different. You may also need to pass additional parameters to the server (see the reference documentation for more detail).

The proxy_pass directive can also point to a named group of servers. In this case, requests are distributed among the servers in the group according to the specified method.

Passing Request Headers

By default, NGINX redefines two header fields in proxied requests, “Host” and “Connection”, and eliminates the header fields whose values are empty strings. “Host” is set to the $proxy_host variable, and “Connection” is set to close.

To change these setting, as well as modify other header fields, use the proxy_set_header directive. This directive can be specified in a location or higher. It can also be specified in a particular server context or in the http block. For example:

<strong>location</strong> /some/path/ {
    <strong>proxy_set_header</strong> Host $host;
    <strong>proxy_set_header</strong> X-Real-IP $remote_addr;
    <strong>proxy_pass</strong> http://localhost:8000;
}

location /some/path/ {

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_pass http://localhost:8000;

}

In this configuration the “Host” field is set to the $host variable.

To prevent a header field from being passed to the proxied server, set it to an empty string as follows:

<strong>location</strong> /some/path/ {
    <strong>proxy_set_header</strong> Accept-Encoding "";
    <strong>proxy_pass</strong> http://localhost:8000;
}

location /some/path/ {

proxy_set_header Accept-Encoding "";

proxy_pass http://localhost:8000;

}

Configuring Buffers

By default NGINX buffers responses from proxied servers. A response is stored in the internal buffers and is not sent to the client until the whole response is received. Buffering helps to optimize performance with slow clients, which can waste proxied server time if the response is passed from NGINX to the client synchronously. However, when buffering is enabled NGINX allows the proxied server to process responses quickly, while NGINX stores the responses for as much time as the clients need to download them.

The directive that is responsible for enabling and disabling buffering is proxy_buffering. By default it is set to on and buffering is enabled.

The proxy_buffers directive controls the size and the number of buffers allocated for a request. The first part of the response from a proxied server is stored in a separate buffer, the size of which is set with the proxy_buffer_size directive. This part usually contains a comparatively small response header and can be made smaller than the buffers for the rest of the response.

In the following example, the default number of buffers is increased and the size of the buffer for the first portion of the response is made smaller than the default.

<strong>location</strong> /some/path/ {
    <strong>proxy_buffers</strong> 16 4k;
    <strong>proxy_buffer_size</strong> 2k;
    <strong>proxy_pass</strong> http://localhost:8000;
}

location /some/path/ {

proxy_buffers 16 4k;

proxy_buffer_size 2k;

proxy_pass http://localhost:8000;

}

If buffering is disabled, the response is sent to the client synchronously while it is receiving it from the proxied server. This behavior may be desirable for fast interactive clients that need to start receiving the response as soon as possible.

To disable buffering in a specific location, place the proxy_buffering directive in the location with the off parameter, as follows:

<strong>location</strong> /some/path/ {
    <strong>proxy_buffering</strong> off;
    <strong>proxy_pass</strong> http://localhost:8000;
}

location /some/path/ {

proxy_buffering off;

proxy_pass http://localhost:8000;

}

In this case NGINX uses only the buffer configured by proxy_buffer_size to store the current part of a response.

A common use of a reverse proxy is to provide load balancing. Learn how to improve power, performance, and focus on your apps with rapid deployment in the free Five Reasons to Choose a Software Load Balancer ebook.

Choosing an Outgoing IP Address

If your proxy server has several network interfaces, sometimes you might need to choose a particular source IP address for connecting to a proxied server or an upstream. This may be useful if a proxied server behind NGINX is configured to accept connections from particular IP networks or IP address ranges.

Specify the proxy_bind directive and the IP address of the necessary network interface:

<strong>location</strong> /app1/ {
    <strong>proxy_bind</strong> 127.0.0.1;
    <strong>proxy_pass</strong> http://example.com/app1/;
}

<strong>location</strong> /app2/ {
    <strong>proxy_bind</strong> 127.0.0.2;
    <strong>proxy_pass</strong> http://example.com/app2/;
}

location /app1/ {

proxy_bind 127.0.0.1;

proxy_pass http://example.com/app1/;

}

location /app2/ {

proxy_bind 127.0.0.2;

proxy_pass http://example.com/app2/;

}

The IP address can be also specified with a variable. For example, the $server_addr variable passes the IP address of the network interface that accepted the request:

<strong>location</strong> /app3/ {
    <strong>proxy_bind</strong> $server_addr;
    <strong>proxy_pass</strong> http://example.com/app3/;
}

location /app3/ {

proxy_bind $server_addr;

proxy_pass http://example.com/app3/;

}

NGINX Reverse Proxy

Introduction

Passing a Request to a Proxied Server

Passing Request Headers

Configuring Buffers

Choosing an Outgoing IP Address

Submit a Comment Cancel reply

Contact

Subscribe to Our Newsletter

Main Office

Washington Office

Links