Nginx Reverse Proxy envoie la même request à plusieurs servers backend

J'ai NGINX comme proxy inverse et deux Apache en tant que servers en amont.

Chaque fois que je visite example.com (dirigé vers NGINX), les servers Apache obtiennent la request GET. Il semble étrange que NGINX fonctionne par défaut en fonction de la méthode Round Robin

Voici ma configuration: –

upstream apache { server 172.18.0.164; server 172.18.8.18; } location / { proxy_pass http://apache; } 

Connectez-vous à la machine Apache 1: –

192.168.10.236 – – [05 / Oct / 2015: 07: 59: 21 -0400] "GET / HTTP / 1.0" 200

Connectez-vous à la machine Apache 2: –

172.18.8.97 – – [05 / Oct / 2015: 11: 59: 27 +0000] "GET / wordpress / HTTP / 1.0"

One Solution collect form web for “Nginx Reverse Proxy envoie la même request à plusieurs servers backend”

Directement à partir du Guide d'administration de Nginx :


Permettre la persistance de la session

NGINX Plus prend en charge trois methods de persistance de session. Les methods sont définies avec la directive collante .

La méthode des cookies collants . Avec cette méthode, NGINX Plus ajoute un cookie de session à la première réponse du groupe en amont et identifie le server qui a envoyé la réponse. Lorsqu'un client émet une request suivante, il contiendra la valeur de cookie et NGINX Plus apathera la requête vers le même server en amont:

 upstream backend { server backend1.example.com; server backend2.example.com; sticky cookie srv_id expires=1h domain=.example.com path=/; } 

Dans l'exemple, le paramètre srv_id définit le nom du cookie qui sera configuré ou inspecté. Le paramètre optionnel expires définit l'heure pour le browser de conserver le cookie. Le paramètre de domain optionnel définit un domaine pour lequel le cookie est défini. Le paramètre de path optionnel définit le path pour lequel le cookie est défini. C'est la méthode de persistance de la session la plus simple.

La méthode de l' itinéraire collant . Avec cette méthode, NGINX Plus atsortingbuera une "route" au client lorsqu'il reçoit la première requête. Toutes les requests ultérieures seront comparées au paramètre d' itinéraire de la directive du server pour identifier le server où les requests seront mises en évidence. Les informations d'itinéraire sont sockets à partir de cookie ou URI.

 upstream backend { server backend1.example.com route=a; server backend2.example.com route=b; sticky route $route_cookie $route_uri; } 

La méthode d' apprentissage des cookies . Avec cette méthode, NGINX Plus trouve d'abord les identificateurs de session en inspectant les requests et les réponses. Ensuite, NGINX Plus "apprend" quel server en amont correspond à quel identifiant de session. Généralement, ces identifiants sont transmis dans un cookie HTTP. Si une requête contient un identifiant de session déjà "appris", NGINX Plus transmettra la requête au server correspondant:

 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; } 

Dans l'exemple, l'un des servers en amont crée une session en configurant le cookie "EXAMPLECOOKIE" dans la réponse.

Le paramètre obligatoire create spécifie une variable qui indique comment une nouvelle session est créée. Dans notre exemple, de nouvelles sessions sont créées à partir du cookie "EXAMPLECOOKIE" envoyé par le server en amont.

La lookup obligatoire de parameters spécifie comment searchr des sessions existantes. Dans notre exemple, les sessions existantes sont recherchées dans le cookie "EXAMPLECOOKIE" envoyé par le client.

La zone paramètre obligatoire spécifie une zone de memory partagée où toutes les informations sur les sessions collantes sont conservées. Dans notre exemple, la zone est nommée client_sessions et a la taille de 1 mégaoctet.

Il s'agit d'une méthode de persistance de session plus sophistiquée, car il ne nécessite pas de garder les cookies du côté client: toutes les informations sont conservées côté server dans la zone de memory partagée.

  • Nginx ne sert qu'une partie d'un file
  • Forcer les requêtes au server d'application par défaut avec Nginx
  • Alias ​​dans l'logging nginx / apache vs CNAME?
  • nginx: directive inconnue "http"
  • Spécifications pour 15 000 users de sites Web simultanés
  • Exécutez une command shell sur ubuntu / nginx boot
  • Activer l'ouverture d'une erreur sur PHP-FPM 7 avec Nginx?
  • Nginx + uWSGI sur une nouvelle Ubuntu install - bind error port 80
  • Lorsque nginx est configuré comme proxy inverse, peut-il réécrire l'en-tête hôte vers le server en aval, comme ProxyPreserveHost d'Apache?
  • Quel est le scénario possible (le cas échéant) par lequel un pirate peut find plusieurs sites hébergés dans un VPS?
  • Nodejs pour le traitement de js et Nginx pour le traitement de tout le rest
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.