序言

? ??什么樣的人可以稱之為有智慧的人呢？如果下一個(gè)定義，你會(huì)如何來定義？

????所謂智慧，就是能區(qū)分自己能改變的部分，自己無法改變的部分，努力去做自己能改變的，而不要天天想著那些無法改變的東西，不然的話，就只能越來越消極了，消極的原因大部分也在于總是關(guān)注于自己無法改變的現(xiàn)實(shí)。

nginx返回404問題排查

? ??背景：

????大部分的人在看到nginx返回404的時(shí)候，要么就是請(qǐng)求了一個(gè)不存在的資源或者接口，要么就是location寫的有問題，基本不會(huì)想到是協(xié)議導(dǎo)致的。

????架構(gòu)：

????現(xiàn)在的應(yīng)用程序都講究前后端分離，分離不完整的時(shí)候，就會(huì)進(jìn)行修改架構(gòu)，在修改之前的架構(gòu)如下：

????為了從統(tǒng)一入口進(jìn)來，從而將架構(gòu)修改為如下：

????修改之后的好處主要是能減少客戶端能接觸的東西，從而減少暴露面，當(dāng)有攻擊的時(shí)候，排查或者封殺的面不會(huì)很多。

????1 前端nginx進(jìn)行重新配置

????在前端nginx上面，其實(shí)只要增加一段location的配置即可，從而使用了極簡(jiǎn)的配置：

upstream backend {server???192.168.1.1;server???192.168.1.2;
}
location??/api/{proxy_pass?http://backend;proxy_set_header?X-Real_IP?$remote_addr;proxy_set_header?X-Forwarded-For?$proxy_add_x_forwarded_for;
}

????在添加完成配置之后，將nginx進(jìn)行reaload，讓配置生效，再次進(jìn)行驗(yàn)證請(qǐng)求之后，發(fā)現(xiàn)后端請(qǐng)求的接口全部變成了404.

????此時(shí)的你，該如何去解決這個(gè)問題？

????對(duì)，應(yīng)該第一時(shí)刻進(jìn)行回滾備份的配置，先讓生產(chǎn)跑起來，再來解決問題。

????2 查看前端和后端的日志

????變更導(dǎo)致的問題，要么看配置是不是有問題，要么看日志查查問題出現(xiàn)的點(diǎn)在哪里。

????在查看nginx的accesslog的時(shí)候，重要的看請(qǐng)求發(fā)到了哪個(gè)后端，404是不是后端返回的，如果404是nginx直接返回的，說明還沒到達(dá)后端，如果是后端的返回的，那么就要看后端nginx的日志了。

????在此處的問題中，查看前端nginx日志的時(shí)候，發(fā)現(xiàn)是后端nginx返回的404，因?yàn)閡psteam_status 為404，而且能找到對(duì)應(yīng)的upsteam server的ip，從而到對(duì)應(yīng)的后端nginx上去查看日志。

????但是，非常奇怪的是，在后端nginx上面未看到任何請(qǐng)求日志，在后端nginx上面，使用的是vhost的配置，也就是虛擬主機(jī)。

????那么現(xiàn)在可以得到一個(gè)初步結(jié)論：

1?404?的確是后端nginx返回的
2 后端nginx上面沒找到對(duì)應(yīng)的訪問日志

????3 可能出現(xiàn)問題的地方

????根據(jù)如上的結(jié)論，那么哪些地方可能出現(xiàn)問題呢？

????首先再看了一眼加了location配置的地方，比平時(shí)的配置少一些東西：

proxy_set_header Host $host;
proxy_set_header?Connection?"";
proxy_http_version 1.1;

????在后端的nginx對(duì)應(yīng)的server段的配置的日志路徑上面，沒找到對(duì)應(yīng)的日志信息，但是前端的nginx返回中說明是后端nginx返回的，從而找到對(duì)應(yīng)的默認(rèn)主機(jī)，也就是default server中，發(fā)現(xiàn)默認(rèn)配置沒有，那么就找到在vhost中第一個(gè)主機(jī)段，查看它的日志，發(fā)現(xiàn)了請(qǐng)求。

????從而問題已經(jīng)找到，因?yàn)樵趎ginx的默認(rèn)配置中，如果不指定http協(xié)議版本的話，那么默認(rèn)是1.0版本，而對(duì)于http 1.0版本來說，默認(rèn)是不會(huì)加上host頭部的，從而當(dāng)請(qǐng)求到后端nginx的時(shí)候，找不到對(duì)應(yīng)server name進(jìn)行處理，從而走了默認(rèn)的server段進(jìn)行處理，從而導(dǎo)致了對(duì)應(yīng)的虛擬主機(jī)沒有日志，而在默認(rèn)的虛擬主機(jī)中找到了對(duì)應(yīng)的訪問日志。

????從而再將host頭部進(jìn)行設(shè)置，然后切換，發(fā)現(xiàn)訪問正常。

????那么再嘗試一下第二種方案，不加host后端，而指定http協(xié)議為1.1，因?yàn)閔ttp1.1協(xié)議默認(rèn)會(huì)傳輸host頭部，從而無需顯示指定，發(fā)現(xiàn)也是ok的。

????最后再把這三個(gè)頭部加上，主要是為了讓兩個(gè)nginx之間保持長(zhǎng)連接，從而減少三次握手的時(shí)間，當(dāng)然upsteam之中，也要將keepalive指令打開，不然也是不能激活長(zhǎng)連接的，因?yàn)閚ginx的默認(rèn)值如下：

Syntax:  keepalive connections;
Default:  —
Context:  upstream

風(fēng)言風(fēng)語

? ?一個(gè)東西，使用的多了，就能遇到各種各樣的問題，而在一些資料上看到的東西，你會(huì)發(fā)現(xiàn)那都是基礎(chǔ)中的基礎(chǔ)，解決不了任何問題，但是卻是解決問題的根基，簡(jiǎn)單的報(bào)錯(cuò)，但是中間就充斥著各種可能得組合原因。就像做數(shù)學(xué)，基礎(chǔ)都是1+1，然后來個(gè)3+2，都是同樣的道理。

????知道并不代表能靈活運(yùn)行，能猜到可能的原因和解法，對(duì)比法也是一個(gè)比較好的方法。

????努力的方向也是自己能改變的東西，也是自己能掌控的東西，如果努力的方向都是不能改變的，不可控的，那么這種努力也將是一種徒勞。