nginx coredump调试--

2019独角兽企业重金招聘Python工程师标准>>>

0.准备打coredump

ulimit -c ，我后面打的nginx的coredump有1.4M，是没有请求队列，无ssl等其他配置的情况

磁盘环境和内存空间够的情况下，

ulimit -c unlimited 一下吧，不限，打完了要用的coredump，记得设置回去，免得其他进程生成了coredump要耗死空间

 

1. 打gcore

gcore -o /var/log/corefile/ng5167 5167
2. 看core

gdb  ./nginx  /var/log/corefile/ng5167.5167

3. gdb

打出当前堆栈信息 bt

进入当前层f1

set print pretty on 显示的好看点

..

要想看到生产上的真实变量，需要复制生产的所有配置文件到本地，打出那个coredump文件，然后，在本地gdb coredump的时候，执行run命令，请求可以模拟着发

 

原本的问题描述：

    链路=C-N1-J-N2-S，C,S分别为客户端和服务端，N1,N2是两个ngnix集群，J是我们自己的代理服务器

当C发出https请求时，N1会强行标记connection=close，这个标记，导致最终返回给N1的response里面的body内容错误（错误表现= chunk数据丢失chunk标志，N1报错说chunk解析错误）

C发出http请求，则无此现象，其他配置一致

 

结论：

1. 关于添加了close，原http和https中配置不同，https中配置可能存在：http使用了1.0版本，或者chunk_encoding=off的设置。。但是，同样的配置reload之后，问题不再现。 消费方咬定之前做过reload

怀疑极少数的master进程没有响应到HUP信号，导致reload其实没有生效

2. chunk数据格式丢失

J,N2,S都有可能干这种事情~~只要标记为connection=close，就会发生这个情况。且，消费方c发出的http还是https的请求，只在链路C-N1时有区别，后端均是一致处理。

怀疑J,S中，某个httpclient在connection=close的情况下，没有组装chunk结构~nginx=N2，使用的版本是1.12.2较新，且适用范围广，且N2不会做加解密，body即便是chunk，也是透传的（还带考证）

重点怀疑J,S中的httpclient存在缺陷

 

/****************************************************************/

下面是不改URI，通过添加请求头，路由到不同服务器的配置方法。

 

转发重写的配置

 location /{
        proxy_http_version 1.1;
            proxy_redirect off;
            proxy_set_header Host $host;
            proxy_set_header X-Forwarded-Proto http;
           if ($http_milina = "zj") {
                proxy_pass http://zj;}

           if ($http_milina = "lf") {
                proxy_pass http://lf;}

         }
 

如此即可，无需rewrite。。。实测有效

实测中还有另外一个诡异问题，后来抓住了，

就是有的页面有代理~比如URL是A，实际展示的是A/index.xml这种情况，在NGINX做双层代理的情况下，

这个index.xml无法自动带出。。。curl或者浏览器直接调用就不会。。

转载于:https://my.oschina.net/u/2874260/blog/1800028