nginx反向代理导致session失效的问题解决

nginx反向代理导致session失效的问题解决

详细介绍了nginx反向代理导致会话无效问题的解决方案。原文根据示例代码非常详细，对大家的学习培训或者工作都有一定的参考价值。有必要的朋友陪我去了解一下。

朋友求助:后台系统登录成功，但无法成功登录系统软件。它仍然会自动跳转到登录页面，但是在另一个自然环境中使用同一套代码没有问题。

情况

掌握之后，他将tomcat应用到同一个新项目中，部署了两个自然环境，一个在开发设计网络服务器上，另一个在其他设备上。两个自然环境的代码完全相同。根据双方相同的nginx进行反向代理，nginx大约配备了以下、

location/health/{ proxy_passhttp://192.168.40.159:8081/health/;#无难题的配备 } location/health-dev/{ proxy_passhttp://192.168.40.202:8080/health/;#有什么问题的配备 }

开发工具的反向代理和设备服务项目的反向代理。

精确定位

就是如果编码设备完全一致，那么问题就很大，很可能出现在nginx的反向代理上。

因为两边的位置路径不一样(也就是浏览器路径不一样)，反向代理的服务器路径是一样的，集成了session的基本概念，如下图所示。

浏览器第一次打开网页时，服务器会为这次对话建立一个会话，并根据响应的头将会话id发送给浏览器，一般是Set-Set-Cookie:JSESSIONID=xxxxx；路径=xxxx

浏览器收到响应后，如果标题Set-Cookie中的path值与浏览器的详细地址路径匹配，则标题值将存储在浏览器的Cookie中。

浏览器下次请求远程服务器时，会根据请求的头向服务器上报Cookie中的jssessionid值，一般是Cookie:jssessionid=xxxx；

根据JSESSIONID，服务器可以准确定位匹配的会话

当nginx反向代理配备了这种方法时

location/health-dev/{ proxy_passhttp://192.168.40.202:8080/health/; }

浏览器浏览http://www.domian.com/health-dev,时服务器返回的Set-Cookie的路径值/健康(因为中间有反向代理，所以服务器不知道代理之前的路径是什么，是根据最后一个请求服务器的路径设置的)，如图。

因为浏览详细地址的浏览器的path/health-dev与Set-Cookie的path/health不匹配，所以浏览器不会将其值存储在Cookie中，如图所示。

因此，在下一个对远程服务器的请求中，浏览器无法设置请求Cookie头的jssessionid值，web服务器也无法定位匹配的会话，因此它将是第一个请求并建立新的会话，以此类推。所以，即使你有登录验证基础，缺乏对象登录凭证(jssessionid)的浏览器也不容易存储，会在下一次请求中带在身边，导致web服务器认为你是新请求，很自然的再次跳转。

处理

Nginx有一个指令proxy_cookie_path(引用:proxy_cookie_path)，可以用缺失对象改变Set-Cookie中的路径。文件格式为proxy_cookie_path原始路径全局目标路径，我们在设备中添加如下proxy_cookie_path。

location/health-dev/{ proxy_passhttp://192.168.40.202:8080/health/; proxy_cookie_path/health/health-dev; }

重启nginx，问题就解决了。

到目前为止，本文已经详细介绍了nginx反向代理导致的会话失效问题的解决方案。关于nginx反向代理导致会话失效的大量内容，请搜索您之前文章的内容或者再次访问下面的相关文章。期待你以后的申请！