最近我們用python開發了一套SSO、然后權限系統一起的一次大更新上線，上線后發現SSO無法正常工作，但測試環境一直無問題。

問題描述

問題URL
http://sso.a.com/signin?redirect_uri=http://tomcat
正常URL
http://sso.a.com/signin?redirect_uri=http://b.c.com

排查

檢查代碼啥的發現沒問題，把動態獲取的host改成靜態的域名，單啟進程后正常，問題定位在nginx的負載上.

nginx domain配置文件

upstream tomcat {server 10.143.88.240:10086; } server {listen 80 ;server_name xxxx;gzip on;gzip_static on;gzip_vary on;gzip_proxied any;gzip_min_length 1000;gzip_buffers 4 8k;gzip_disable "msie6";gzip_http_version 1.1;gzip_comp_level 5;gzip_types text/plain text/css text/javascript application/javascript application/x-javascript;location / {proxy_pass http://tomcat;}}

稍微思考一下，upstream中的name是一個變量，而做為變量即可得到后端地址，而不是直接給后端地址。

處理

將upstream中的name改成實際的域名，在這里即是b.c.com即可以獲取，然后工作正常。

查看官主解釋

默認情況下，nginx按加權輪轉的方式將請求分發到各服務器。 在上面的例子中，每7個請求會通過以下方式分發： 5個請求分到backend1.example.com， 一個請求分到第二個服務器，一個請求分到第三個服務器。 與服務器通信的時候，如果出現錯誤，請求會被傳給下一個服務器，直到所有可用的服務器都被嘗試過。 如果所有服務器都返回失敗，客戶端將會得到最后通信的那個服務器的（失敗）響應結果。

總結

以上是生活随笔為你收集整理的nginx的upstream问题记录的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。