nginx配置反向代理或跳转出现400问题处理记录 - AllEmpty - 博客园

标签: | 发表时间:2022-01-25 14:59 | 作者:
出处:https://www.cnblogs.com

  午休完上班后,同事说测试站点访问接口出现400 Bad Request  Request Header Or Cookie Too Large提示,心想还好是测试服务器出现问题,影响不大,不过也赶紧上服务器进行测试查看,打开nginx与ugwsi日志与配置,发现后端服务日志记录正常,而测试站点的访问日志有7百多M(才运行两三天没几个访问,几M的话才是正常现象),在浏览器里直接访问后端服务接口也正常没有问题(我们的服务器软件架构是微服务架构,将很多模块分拆后分别部署,前端是一个纯HTML站点,通过AJAX访问后端各个服务,由于访问量不大,所以前端站点的nginx配置时,做了反向代理访问后端其他服务,这样就不会出现跨域和需要处理多子域名事情——即访问不同的服务时,只需要使用当前域名就可以了,这样前端开发人员不必要知道后端挂载了多少服务需要使用什么对应的域名访问)。访问这台服务器上的其他站点都能正常访问,而问题站点的html页面也能正常打开......在测试过程中发现,每访问一下问题接口,访问日志就增加30多M,刷了几次,nginx日志大小直线上升......

  由于日志比较大,只能使用tail -n 5000 xxx_access.log >> xxx.log截取一下最新的日志记录下载下来,打开一看发现同一时间一个访问,生产了2000多条重复循环的访问记录,而日志尾部$http_x_forwarded_for部分,有规律的存储了相同的由多到少的IP字串,即:最后一条有一个IP字串(真实IP),倒数第二条有两个IP字串(真实IP + 服务器本地IP),倒数第三条有三个IP字串(真实IP + 两个服务器本地IP),以至类推

  百度了一下“400 Bad Request  Request Header Or Cookie Too Large”,查找出来的几乎都是说“nginx 400 Bad request是request header过大所引起,request过大,通常是由于cookie中写入了较大的值所引起。在nginx.conf中,将client_header_buffer_size和large_client_header_buffers都调大后可解决”,一看就知道这肯定不是我这种情况的解决办法,这是由于不知道什么原因引起的死循环将IP地址串写入请求头,直到缓存爆了才返回400,如果将缓存设置更大,只会造成日志增加速度变大而已。从分析来看应该是nginx出现的问题。

  没有办法只能在打开nginx配置文件分析,问题站点的配置文件,如下图,并没有发现什么问题

  打开nginx.conf进行慢慢研究,发现多了几行代码

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

  这是用来将当前访问用户的IP传给后端服务器用的,将它们删除重新启动一下服务器nginx后测试了一下,发现能正常访问了...o my god,再将它放回去,重启,访问,挂了,去掉,重启,访问,正常......重试了好几次,终于确定就是突然多出来的几行代码引起的。(后来问了一下同事才知道是他进服务器添加的)

  难道真的是不能使用吗?记得以前用过还是正常的。尝试访问预生产环境接口,正常。打开预生产环境的nginx配置,包函有这三行代码,如下图

  全面对比后发现,生产环境用的nginx配置是域名,而预生产环境用的是IP+端口,除此之外没有任何区别,使用跳转方式与反向代码方式测试,结果都是一样,添加port_in_redirect、server_name_in_redirect配置也没能解决

  综合分析,应该是nginx在使用proxy_pass做跳转时,如果直接使用域名,且需要向后端提交当前访问的IP地址时,引发nginx的bug造成死循环,不知道大家有没有遇到过这种情况。

# 使用反向代理方式        
# 正常的配置 upstream xxx{ server127.0.0.1:23456; } upstream yyy { server127.0.0.1:123455; } # 异常配置 upstream xxx1{ server xx.xxx.com; } upstream yyy2 { server yyy.xxx.com; }
# 使用跳转方式
# 正常配置
proxy_pass   http://127.0.0.1:23456;# 异常配置
proxy_pass   http://xx.xxx.com;

 

 

相关 [nginx 反向代理 问题] 推荐:

nginx配置反向代理或跳转出现400问题处理记录 - AllEmpty - 博客园

- -
访问这台服务器上的其他站点都能正常访问,而问题站点的html页面也能正常打开......在测试过程中发现,每访问一下问题接口,访问日志就增加30多M,刷了几次,nginx日志大小直线上升.......   百度了一下“400 Bad Request  Request Header Or Cookie Too Large”,查找出来的几乎都是说“nginx 400 Bad request是request header过大所引起,request过大,通常是由于cookie中写入了较大的值所引起.

squid,nginx,lighttpd反向代理的区别

- - 企业架构 - ITeye博客
[转载自]http://www.cnblogs.com/yihang/archive/2010/12/19/1910363.html. squid,nginx,lighttpd反向代理的区别. 反向代理从传输上分可以分为2种:. 1:同步模式(apache-mod_proxy和squid). 2:异步模式(lighttpd 和 nginx).

Nginx多Server反向代理配置

- - 企业架构 - ITeye博客
Nginx强大的正则表达式支持,可以使server_name的配置变得很灵活,如果你要做多用户博客,那么每个用户拥有自己的二级域名也就很容易实现了. 下面我就来说说server_name的使用吧:. server_name的匹配顺序. nginx中的server_name指令主要用于配置基于名称虚拟主机,server_name指令在接到请求后的匹配顺序分别为:.

Nginx反向代理以及配置优化

- - CSDN博客推荐文章
下面配置包含了,nginx配置的一个比较全面的反向代理的例子:. #允许客户端请求的最大单个文件字节数. #后端返回502,504,执行超时等错误,自动将请求转发到upstream负载池中另一台服务器. 作者:liuzhoulong 发表于2013-5-5 13:48:26 原文链接. 阅读:0 评论:0 查看评论.

nginx反向代理访问带referer的后端

- - 开心平淡对待每一天。热爱生活
nginx反向代理访问带referer的后端 . 作者:ADMIN 发布时间:SEPTEMBER 16, 2011 分类: LINUX. 防外链大都是通过检查请求中的http referer来实现的. 如果通过反向代理来动态指定http referer是不是可以解决问题. 用nginx搭一个反向代理.

使用 Nginx 实现 TCP 反向代理 - 运维之美

- -
Nginx 在1.9.0版本发布以前如果要想做到基于TCP的代理及负载均衡需要通过打名为  nginx_tcp_proxy_module 的第三方patch来实现,该模块的代码托管在github上网址: https://github.com/yaoweibin/nginx_tcp_proxy_module/.

nginx缓存html静态文件,解析php及反向代理IIS的配置

- - 开源软件 - ITeye博客
       Nginx缓存html静态文件 解析php及反向代理IIS的配置,供初学的朋友参考. server_name k; #碰到域名为k的 就交给iis来运行. proxy_pass http://k:8080/;#我的IIS上面的站点即为http://k:8080. location ~ .*\.(gif|jpg|jpeg|png|bmp|swf|js|html|htm|css)$ { #指定缓存文件类型.

反向代理服务器Nginx获得300万美元投资,将推出商业版本

- 幻幽 or A書 - 36氪
Nginx是10年前俄国工程师Igor Sysoev为俄国访问量第二大的网站Rambler.ru开发的高性能HTTP和反向代理服务器软件,今天他们宣布获得了来自包括Dell公司CEO Michael Dll私人投资公司等的300万美元投资. Nginx联合创始人Andrew Alexeev表示,通过这次融资,年底前他们将在旧金山开设办事处,并且在2012年会推出一个商业版本.

更新nginx版本upstream升级http1.1解决多TIME_WAIT问题

- - 五四陈科学院
以下内容由 [五四陈科学院]提供. 在使用java web container的时候,我们都在前面挡一层nginx,方便使用各种nginx的功能,设置成代理. 访问特别多的时候发现,服务器上存在大量的TIME_WAIT状态的连接. 经分析,可能是nginx早期版本的upstream还是使用的1.0的短连接代理,java container老是以1.0的方式主动断开进入TIME_WAIT状态,浪费了大量的连接.

开启nginx cache后导致内存几乎100%问题

- - 开涛的博客
1、前些日子某服务被刷,每分钟达到上几百万请求;当时采用了nginx cache来解决的;但是因为某服务不能缓存太久,当时设置了5s,那么带来的问题就是产生大量小文件,而且很快就删除了. 会发现used是27G;但是通过top查看进程占的内存并没有那么多. SReclaimable: 16474128 kB (这些是内核保持的但是可以释放的inode和dentry的缓存).