作者回复: 如果方便直接操作应用层协议的话,我推荐在应用层协议中完成。比如HTTP协议或者Websocket协议,可以在http header中通过forwarded-for头部,传递client IP;Protobuf、Json等都可以这么做。 如果只是作为中间件,无法修改应用层协议格式,那么只能通过修改IP header中的source IP了,这是个非常麻烦的解决方案,需要解决报文的路由,具体可以参见我的这篇文章:http://taohui.pub/2018/04/08/udp%e7%9a%84%e5%8f%8d%e5%90%91%e4%bb%a3%e7%90%86%ef%bc%9anginx/
作者回复: 2步查下: 1、如果不能复现,看下error.log有什么日志; 2、如果可以复现,抓包看下,TCP是操作系统实现的,客户端应用很可能没有真实反映报文传输,tcpdump或者wireshark很容易定位的。 从原理上讲,Nginx stream proxy是复用同一块内存,在2个TCP连接上转发数据,逻辑极其简单,不太会出错。
作者回复: 你的配置是不是在http {}中?注意,stream不是http模块哈,你要把这些配置放在stream {}中才行
作者回复: reload后,老连接不会到新的backend上,但新连接会根据新的负载均衡算法,到恰当的backend上。比如你是根据client ip来做hash,或者least connection算法,那么有机会到新的backend上
作者回复: 是Nginx所在机器上抓到包了,但Nginx没有转发吗?你在Nginx机器上抓取了上游的包,以及向下游转发的包了吗?我的邮箱是russelltao@foxmail.com
作者回复: 1、看几个指标,网络是否达到最大值,有丢包没,CPU是否还有空闲,IO高不高。再判断Nginx性能能否提高。 2、不要用hash,你只有一个压测客户端,还基于IP地址,自然都落到一台上游了。比如least conn可以平分连接。 另外,对上游如果可以的话,建议打开keepalive
作者回复: 非HTTP协议的反向代理