思路一 是否为nginx负载的问题。

nginx经过多次转发之后，可能会丢失掉客户端原有的ip，导致后端获取到的ip是本机的回环地址或者内网地址。

这种的多看看配置吧，看看有没有什么错误的地方，先确保nginx每次转发都可以获取到客户端的真实ip，将真实ip携带着发送到后端服务器上面。

排错思路：

  • 开启nginx日志记录，自己配置特定的nginx日志格式，方便自己查看。
  • 一般nginx的日志都在var/log/nginx目录下。
  • 首先确定请求正确到达nginx了。
  • 其次确定请求每次转发都正确，每一次都携带着真实的ip。
  • 最终核实请求真实的发到了后端服务器。

思路二 后台服务器获取真实ip的姿势对吗？

排错思路

  • 确认自己获取ip的方法是正确的
  • 确认自己获取ip的时候，参数写对了。我本次就是这个问题 ....

错误说明

nginx转发的时候，需要配置携带上客户端的ip等信息，携带的时候，是自己配置参数的。

请求头的参数信息，参数名查阅不同的博客，给的结果虽然差不多，但是可能会有大小写区别。

平时出现问题呢，很少有一篇博客解决全部问题的，所以就会出现nginx配置的时候，ip转发的参数名配置是：X-Real-ip，但是去获取真实ip的时候，有一些博客获取的是X-Real-Ip这个参数名。

总结

http请求头嘛，都是可以自己写的。如果你循环出所有的请求头，然后逐一遍历，将所有的参数名统一大小写，也不会出现这种问题，但是如果你要根据参数名精准获取某一个请求头的时候，一定要精准获取，否则即使获取的姿势对，也会和自己想要的结果擦肩而过！ 如果使用正确的姿势，nginx配置也正确的情况下，依然获取不到自己想要的内容，别再犹豫了，干看是没用的，请求进来的时候，将所有的请求头打印出来成日志，然后逐一去比对吧！ 程序猿永远都是一群动手的人。很多东西需要思考，但是思考的东西总归是需要付诸行动去验证的。咱又不是达尔文，思考的也不是进化论，那种印证起来需要付出一辈子的东西。作为程序猿，思考的永远都是解决方案，业务逻辑。这些东西都需要立即去印证才行的哟~

这次错误做个记录，以后我会把我遇到的所有错误都记录下来，我不嫌丢人，犯过的错，一直重复犯才丢人呢！