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。。。实测有效
实测