A reverse proxy is a web server that terminates connections with clients andmakes new ones to upstream servers on their behalf.
An upstream server is defined as a server that NGINX makes a connection with in order to ful ll theclient's request
These upstream servers can take various forms, and NGINXcan be con gured differently to handle each of them.
At times, an upstream server may not be able to ful ll a request. NGINX has thecapability to deliver an error message to the client, either directly from this upstreamserver, from its local disk, or as a redirect to a page on a completely different server.
-
Introduction to reverse proxying
The most important directive when proxying to an upstream server is the proxy_pass directive. This directive takes one parameter—the URL to which the requestshould be transferred. Using proxy_pass with a URI part will replace the request_uri with this part. For example, /uri in the following example will be transformedto /newuri when the request is passed on to the upstream:
location /uri {
proxy_pass http://localhost:8080/newuri; }
There are two exceptions to this rule, however. First, if the location is defined with a regular expression, no transformation of the URI occurs. In this example,the URI /local will be passed directly to the upstream, and not be transformedto /foreign as intended:
location ~ ^/local {
proxy_pass http://localhost:8080/foreign; }
The second exception is that if within the location a rewrite rule changes the URI,and then NGINX uses this URI to process the request, no transformation occurs.
In this example, the URI passed to the upstream will be /index.php?page=<match>,with <match> being whatever was captured in the parentheses, and not /index, asindicated by the URI part of the proxy_pass directive:location / {
rewrite /(.*)$ /index.php?page=$1 break;
proxy_pass http://localhost:8080/index; }
The break flag to the rewrite directive is used here to immediatelystop all processing of rewrite module directives.
The proxy module
Proxy module directives
Directive
Explanation
proxy_connect_timeout
The maximum amount of time NGINXwill wait for its connection to beaccepted when making a request to anupstream server.
proxy_cookie_domain
Replaces the domain attribute of theSet-Cookie header from the upstreamserver; the domain to be replaced caneither be a string or a regular expression,or reference a variable.
proxy_cookie_path
Replaces the path attribute of the Set-Cookie header from the upstreamserver; the path to be replaced can eitherbe a string or a regular expression, orreference a variable.
proxy_headers_hash_bucket_size
The maximum size of header names.
proxy_headers_hash_max_size
The total size of headers received fromthe upstream server.
proxy_hide_header
A list of header fields that should not be passed on to the client.
Explanation
proxy_http_version
The HTTP protocol version used tocommunicate with upstream servers(use 1.1 for keepalive connections).
proxy_ignore_client_abort
If set to on, NGINX will not abort theconnection to an upstream server if theclient aborts the connection.
proxy_ignore_headers
Sets which headers can be disregardedwhen processing the response from theupstream server.
proxy_intercept_errors
If enabled, NGINX will display aconfigured error_page error instead ofthe response directly from the upstreamserver.
proxy_max_temp_file_size
The maximum size of the overflow file,written when the response doesn't fitinto memory buffers.
proxy_pass
Specifies the upstream server to which therequest is passed, in the form of a URL.
proxy_pass_header
Overrides the disabled headers set inproxy_hide_header, allowing themto be sent to the client.
proxy_pass_request_body
Prevents sending the body of the requestto the upstream server if set to off.
proxy_pass_request_headers
Prevents sending the headers of therequest to the upstream server if set tooff.
proxy_read_timeout
Specifies the length of time that needsto elapse between two successive readoperations from an upstream server,before the connection is closed. Shouldbe set to a higher value if the upstreamserver processes requests slowly.
proxy_redirect
Rewrites the Location and Refreshheaders received from the upstreamservers; useful for working aroundassumptions made by an applicationframework.
Directive
Explanation
proxy_send_timeout
The length of time that needs to elapsebetween two successive write operationsto an upstream server, before theconnection is closed.
proxy_set_body
The body of a request sent to anupstream server may be altered bysetting this directive.
proxy_set_header
Rewrites the contents of headers sent toan upstream server; may also be used tonot send certain headers by setting itsvalue to the empty string.
proxy_temp_file_write_size
Limits the amount of data buffered toa temporary file at one time, so thatNGINX will not block too long on asingle request.
proxy_temp_path
A directory where temporary filesmay be buffered as they are proxiedfrom the upstream server, optionallymulti-level deep.
-
Types of upstream servers
-
Converting an "if"-fy con guration to a more modern interpretation
-
Using error documents to handle upstream problems
-
Determining the client's real IP address
The upstream module
Closely paired with the proxy module is the upstream module. The upstreamdirective starts a new context, in which a group of upstream servers is de ned.These servers may be given different weights (the higher the weight, the greaterthe number of connections NGINX will pass to that particular upstream server),may be of different types (TCP versus UNIX domain), and may even be markedas down for maintenance reasons.
Table: Upstream module directives
Chapter 4
Directive |
Explanation |
ip_hash |
Ensures the distribution of connecting clients evenly overall servers by hashing the IP address, keying on its class-Cnetwork. |
keepalive |
The number of connections to upstream servers that |
least_conn |
Activates the load-balancing algorithm where the serverwith the least number of active connections is chosen forthe next new connection. |
server |
Defines an address (domain name or IP address with anoptional TCP port, or path to a UNIX-domain socket)and optional parameters for an upstream server. Theparameters are:
|
Keepalive connections
upstream apache {
server 127.0.0.1:8080;
keepalive 32;
}
location / {
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_pass http://apache;
}
upstream memcaches {
server 10.0.100.10:11211;
server 10.0.100.20:11211;
keepalive 64;
}
If we were to switch load-balancing algorithms from the default round-robin to either ip_hash or least_conn, we would need to specify this before using thekeepalive directive:
upstream apaches {
least_conn;
server 10.0.200.10:80;
server 10.0.200.20:80;
keepalive 32;
}
Load-balancing algorithms
The upstream module can select which upstream server to connect to in the nextstep by using one of three load-balancing algorithms—round-robin, IP hash, or leastconnections. The round-robin algorithm is selected by default, and doesn't need acon guration directive to activate it. This algorithm selects the next server, based onwhich server was selected previously, which server is next in the con guration block,and what weight each server carries. The round-robin algorithm tries to ensure a fairdistribution of traf c, based on a concept of who's turn it is next.
The IP hash algorithm, activated by the ip_hash directive, instead takes the view thatcertain IP addresses should always be mapped to the same upstream server. NGINXdoes this by using the rst three octets of an IPv4 address or the entire IPv6 address, asa hashing key. The same pool of IP addresses are therefore always mapped to the sameupstream server. So, this mechanism isn't designed to ensure a fair distribution, butrather a consistent mapping between the client and upstream server.
The third load-balancing algorithm supported by the default upstream module,least connections, is activated by the least_conn directive. This algorithm isdesigned to distribute the load evenly among upstream servers, by selecting theone with the fewest number of active connections. If the upstream servers do notall have the same processing power, this can be indicated using the weightparameter to the server directive. The algorithm will take into account thedifferently-weighted servers when calculating the number of least connections.
上游服务器的类型
可以是虚拟机或物理机
It maybe an Apache server, with multiple modules to handle different kinds of requests,
or a Rack middleware server, providing an HTTP interface to Ruby applications.NGINX can be configured to proxy to each of them.
一台服务器
server { location / {
proxy_pass http://localhost:8080; }
}
A con guration such as this is typically extended so that NGINX will serve any static les directly, and then proxy the remaining requests to Apache:
server {
location / {
try_files $uri @apache;
}
location @apache {
proxy_pass http://127.0.0.1:8080;
}}
多台服务器
upstream app {
server 127.0.0.1:9000;
server 127.0.0.1:9001;
server 127.0.0.1:9002;
}
server {
location / {
proxy_pass http://app;
}
}
try_files simply doesn't work when anif directive is present in the same location
Using error documents to handle upstream problems
There are situations in which the upstream server cannot respond to a request. Inthese cases, NGINX can be con gured to supply a document from its local disk:
server {
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root share/examples/nginx/html;
}
}
Or from an external site:
server {
error_page 500 http://www.example.com/maintenance.html;
}