NGINX as a Reverse Proxy

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 are cached per worker process. When used with HTTPconnections, proxy_http_version should be set to 1.1andproxy_set_headertoConnection "".
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: weight: It sets the preference for one server overanother max_fails: It is the maximum number ofunsuccessful communication attempts to a serverwithin fail_timeout before the server is markedas down fail_timeout: It is the length of time a serverhas to respond to a request and the length of timea server will be marked as down backup: It will only receive requests once theother servers are down down: It marks a server as not able toprocess requests

Keepalive connections 

值得特别关注： 保持了一个工作进程与上游服务器的连接数量   要求HTTP 1.1

upstream apache {
  server 127.0.0.1:8080;
  keepalive 32;

}
location / {

proxy_http_version 1.1;

proxy_set_header Connection "";

proxy_pass http://apache;

} 

也可用于非HTTP的连接： 两个memcached 实例

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;

}