Straight from the Nginx Admin Guide:
Enabling Session Persistence
NGINX Plus supports three session persistence methods. The methods are set with the sticky directive.
The sticky cookie method. With this method, NGINX Plus adds a session cookie to the first response from the upstream group and identifies the server which has sent the response. When a client issues next request, it will contain the cookie value and NGINX Plus will route the request to the same upstream server:
upstream backend {
server backend1.example.com;
server backend2.example.com;
sticky cookie srv_id expires=1h domain=.example.com path=/;
}
In the example, the srv_id
parameter sets the name of the cookie which will be set or inspected. The optional expires
parameter sets the time for the browser to keep the cookie. The optional domain
parameter defines a domain for which the cookie is set. The optional path
parameter defines the path for which the cookie is set. This is the simplest session persistence method.
The sticky route method. With this method, NGINX Plus will assign a “route” to the client when it receives the first request. All subsequent requests will be compared with the route parameter of the server directive to identify the server where requests will be proxied. The route information is taken from either cookie, or URI.
upstream backend {
server backend1.example.com route=a;
server backend2.example.com route=b;
sticky route $route_cookie $route_uri;
}
The cookie learn method. With this method, NGINX Plus first finds session identifiers by inspecting requests and responses. Then NGINX Plus “learns” which upstream server corresponds to which session identifier. Generally, these identifiers are passed in a HTTP cookie. If a request contains a session identifier already “learned”, NGINX Plus will forward the request to the corresponding server:
upstream backend {
server backend1.example.com;
server backend2.example.com;
sticky learn
create=$upstream_cookie_examplecookie
lookup=$cookie_examplecookie
zone=client_sessions:1m
timeout=1h;
}
In the example, one of the upstream servers creates a session by setting the cookie “EXAMPLECOOKIE” in the response.
The obligatory parameter create
specifies a variable that indicates how a new session is created. In our example, new sessions are created from the cookie “EXAMPLECOOKIE” sent by the upstream server.
The obligatory parameter lookup
specifies how to search for existing sessions. In our example, existing sessions are searched in the cookie “EXAMPLECOOKIE” sent by the client.
The obligatory parameter zone
specifies a shared memory zone where all information about sticky sessions is kept. In our example, the zone is named client_sessions
and has the size of 1 megabyte.
This is a more sophisticated session persistence method as it does not require keeping any cookies on the client side: all info is kept server-side in the shared memory zone.
/
versus/wordpress
) and the timestamp is different. If you're expecting the same source to go to the same server, you need something to provide session affinity (which could be based on things like source ip (+ port) or a cookie...