# Strange behaviour with ip\_hash (client redirected to different nodes from upstream) **URL:** \ **Category:** NGINX\ **Created:** [December 3, 2010, 4:47pm UTC](https://www.ruby-forum.com/t/strange-behaviour-with-ip-hash-client-redirected-to-different-nodes-from-upstream/200045 "2010-12-03T16:47:23Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Dobai-Pataky\_BSSSSl](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/77aa72/32.png) [@Dobai-Pataky\_BSSSSl](https://www.ruby-forum.com/u/Dobai-Pataky_BSSSSl)\ **Post date:** [December 3, 2010, 4:47pm UTC](https://www.ruby-forum.com/t/strange-behaviour-with-ip-hash-client-redirected-to-different-nodes-from-upstream/200045/1 "2010-12-03T16:47:23Z")
Today while debugging a strange issue with our PHP application, we have discovered, that some requests from client’s ip were propagated to different nodes from an upstream clausule, inspite of using ip\_hash algorithm Below is the upstream clasule: upstream pula\_partnerzy20 { ip\_hash; server 12.0.0.31:90 max\_fails=2 fail\_timeout=10m down; server 12.0.0.32:90 max\_fails=2 fail\_timeout=10m; server 12.0.0.33:90 max\_fails=2 fail\_timeout=10m; } Vhost configuration below: server { listen 99; server\_name [domain.org](http://domain.org); ``` location / { proxy_set_header Host $http_host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; if ($request_method = POST ) { proxy_pass http://pula_partnerzy20; break; } set $memc_cmd 'get'; set $memc_key $request_uri; memc_pass memcache; memc_flags_to_last_modified on; error_page 404 502 504 500 = /fallback; } error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } location = /fallback { internal; proxy_set_header Host $http_host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://pula_partnerzy20; } ``` } Notice: inspite of sending calls to memcache in the vhost config, our memcache has been turned off some time ago, so there are the 502’s in the access log Here is the access log (with hoaxed client IP): 89.215.266.49 [domain.org](http://domain.org) “02/Dec/2010:21:11:41 +0100” “127.0.0.1:11212, memcache : 12.0.0.33:90” “GET /dbr/images/dot\_external.gif?c=fac52b5f HTTP/1.1” 200 (502, 502 : 200) UP\_RESPONSE 0.000, 0.000 : 0.001 request\_time 0.001 89.215.266.49 [domain.org](http://domain.org) “02/Dec/2010:21:11:41 +0100” “127.0.0.1:11212, memcache : 12.0.0.33:90” “GET /dbr/images/paging-bottom.gif?c=ce034e2f HTTP/1.1” 200 (502, 502 : 200) UP\_RESPONSE 0.000, 0.000 : 0.001 request\_time 0.001 89.215.266.49 [domain.org](http://domain.org) “02/Dec/2010:21:11:41 +0100” “127.0.0.1:11212, memcache : 12.0.0.33:90” “GET /dbr/images/ico-world.gif?c=67011679 HTTP/1.1” 200 (502, 502 : 200) UP\_RESPONSE 0.000, 0.000 : 0.002 request\_time 0.002 89.215.266.49 [domain.org](http://domain.org) “02/Dec/2010:21:11:41 +0100” “127.0.0.1:11212, memcache : 12.0.0.33:90” “GET /dbr/images/dings-top.gif?c=6b47dd44 HTTP/1.1” 200 (502, 502 : 200) UP\_RESPONSE 0.000, 0.000 : 0.013 request\_time 0.013 89.215.266.49 [domain.org](http://domain.org) “02/Dec/2010:21:11:42 +0100” “127.0.0.1:11212, memcache : 12.0.0.33:90” “GET /dbr/images/ico-date.gif?c=126a1a8a HTTP/1.1” 200 (502, 502 : 200) UP\_RESPONSE 0.000, 0.000 : 0.001 request\_time 0.001 89.215.266.49 [domain.org](http://domain.org) “02/Dec/2010:21:12:33 +0100” “127.0.0.1:11212, memcache : 12.0.0.33:90” “GET /dbr/images/ajax-loader.gif?c=ed0e5384 HTTP/1.1” 200 (502, 502 : 200) UP\_RESPONSE 0.000, 0.000 : 0.003 request\_time 0.003 89.215.266.49 [domain.org](http://domain.org) “02/Dec/2010:21:12:33 +0100” “127.0.0.1:11212, memcache : 12.0.0.32:90” “GET /flights/select/0/0//4/1/BTSIbj0RsDHl1S-27Fllkl6GAbOTWOht0ubLlQ0Kx-s?format=html HTTP/1.1” 200 (502, 502 : 200) UP\_RESPONSE 0.000, 0.000 : 0.089 request\_time 0.089 89.215.266.49 [domain.org](http://domain.org) “02/Dec/2010:21:13:17 +0100” “127.0.0.1:11212, memcache : 12.0.0.32:90” “GET /flights/select/2010-12-15/2011-01-04//asc/1/BTSIbj0RsDHl1S-27Fllkl6GAbOTWOht0ubLlQ0Kx-s//format/html HTTP/1.1” 302 (502, 502 : 302) UP\_RESPONSE 0.000, 0.000 : 0.309 request\_time 0.309 89.215.266.49 [domain.org](http://domain.org) “02/Dec/2010:21:13:17 +0100” “127.0.0.1:11212, memcache : 12.0.0.32:90” “GET /flights/searching/msg/search?R= HTTP/1.1” 200 (502, 502 : 200) UP\_RESPONSE 0.000, 0.000 : 0.135 request\_time 0.135 89.215.266.49 [domain.org](http://domain.org) “02/Dec/2010:21:13:31 +0100” “127.0.0.1:11212, memcache : 12.0.0.32:90” “GET /flights/searching2/R/BTSIbj0RsDHl1S-27Fllkl6GAbOTWOht0ubLlQ0Kx-s HTTP/1.1” 200 (502, 502 : 200) UP\_RESPONSE 0.000, 0.000 : 12.115 request\_time 12.115 89.215.266.49 [domain.org](http://domain.org) “02/Dec/2010:21:13:31 +0100” “127.0.0.1:11212, memcache : 12.0.0.32:90” “GET /flights/select/0/0//asc/0/BTSIbj0RsDHl1S-27Fllkl6GAbOTWOht0ubLlQ0Kx-s HTTP/1.1” 200 (502, 502 : 200) UP\_RESPONSE 0.000, 0.000 : 0.259 request\_time 0.259 89.215.266.49 [domain.org](http://domain.org) “02/Dec/2010:21:13:31 +0100” “127.0.0.1:11212, memcache : 12.0.0.32:90” “GET /packed/flights\_i18n-bg-f96c0114.js?c=9f909277 HTTP/1.1” 200 (502, 502 : 200) UP\_RESPONSE 0.000, 0.000 : 0.005 request\_time 0.005 As you can see, client’s IP address has been computed by ip\_hash to use 12.0.0.33 server backend. Everything is OK until suddenly client is directed to 12.0.0.32 backend. I’ve done greping (for 500 status codes which could mark upstream), searching error log for some clues and nothing. What also wonders me is there there is nothing like “12.0.0.33, 12.0.0.32 : 12.0.0.32” in $upstream\_addr in the log above, it looks like ip\_hash has just computed other value than usual Can anyone help me solving this issue? I’m using: nginx version: nginx/0.7.67 built by gcc 4.3.2 (Debian 4.3.2-1.1) TLS SNI support enabled configure arguments: --with-http\_stub\_status\_module –prefix=/usr/local/nginx/ --with-openssl=/root/openssl-0.9.8p –add-module=/root/agentzh-memc-nginx-module-b2aeae2/ --with-debug –add-module=/root/agentzh-headers-more-nginx-module-9508330/ –with-http\_ssl\_module --with-openssl-opt=enable-tlsext Posted at Nginx Forum: > **[strange behaviour with ip\_hash (client redirected to different nodes from...](https://forum.nginx.org/read.php?2,155313,155313#msg-155313)** > > Today while debugging a strange issue with our PHP application, we have discovered, that some requests from client's ip were propagated to different nodes from an upstream clausule, inspite of using ip\_hash algorithm Below is the upstream clasule:... ---
**Author:** ![rsawer](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/dc4da7/32.png) [@rsawer](https://www.ruby-forum.com/u/rsawer)\ **Post date:** [February 24, 2011, 11:01am UTC](https://www.ruby-forum.com/t/strange-behaviour-with-ip-hash-client-redirected-to-different-nodes-from-upstream/200045/2 "2011-02-24T11:01:08Z")
It was a false alarm 🙂 It came that developers have released a buggy app which caused timeouts sorry 😉 Posted at Nginx Forum: > **[Re: strange behaviour with ip\_hash (client redirected to different nodes from...](https://forum.nginx.org/read.php?2,155313,177955#msg-177955)** > > Today while debugging a strange issue with our PHP application, we have discovered, that some requests from client's ip were propagated to different nodes from an upstream clausule, inspite of using ip\_hash algorithm Below is the upstream clasule:...