nginx coredump調試--

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或者瀏覽器直接調用就不會。。