每次有人讓我?guī)兔ε挪椤癗ginx 反向代理配置”的問題我基本不用看代碼就能猜到一半的坑要么是proxy_pass的路徑?jīng)]寫明白要么是前端拿到 502 后一群人干瞪眼。Nginx 這個名字在服務(wù)端幾乎無人不曉高性能、高并發(fā)、輕量這些詞被聊爛了但真正能一次把反向代理配妥的人其實不多。這篇文章我不想按官方文檔的順序啰嗦一遍而是從我這些年踩過的坑、改過的配置、背過的面試題里挑出最實用的一條線講清楚什么是反向代理Nginx 在什么場景下可以做什么安裝時有哪些選擇核心配置怎么拆負載均衡怎么做SSL 和 WebSocket 這些進階玩法怎么接最后再給你一份常見問題排查表。這套內(nèi)容適合兩類人一是剛接觸服務(wù)器、準備把自己寫的項目部署上線的新手二是已經(jīng)會裝 Nginx 但每次配置都靠復(fù)制粘貼、出了問題就要搜半天的初級運維。看完之后至少你能獨立寫出一份能上生產(chǎn)的反向代理配置也能在面試時把“反向代理和正向代理的區(qū)別”講得讓面試官點頭。1. 反向代理不是玄學(xué)先搞清楚它解決什么問題1.1 所謂“反向”到底反在哪里代理這個詞大家不陌生正向代理最常見的就是公司內(nèi)網(wǎng)里那臺“上網(wǎng)代理服務(wù)器”。你在瀏覽器里配置代理所有請求先發(fā)給代理服務(wù)器由它替你訪問外網(wǎng)再拿回來。這個模式下真正訪問資源的服務(wù)器并不知道是你發(fā)起的請求它只認識代理服務(wù)器的地址。這里面的關(guān)鍵點是正向代理是站在客戶端側(cè)的為客戶端服務(wù)的。反向代理剛好掉了個頭?？蛻舳税l(fā)請求時根本不知道內(nèi)部有多少臺真實服務(wù)器它把所有請求統(tǒng)一打給對外暴露的那臺機器——也就是 Nginx。Nginx 再按照配置規(guī)則把請求轉(zhuǎn)發(fā)給一臺或多臺內(nèi)部的應(yīng)用服務(wù)器?？蛻舳酥徽J Nginx對內(nèi)實際由誰處理客戶端完全不感知。所以反向代理是站在服務(wù)端側(cè)的為后端服務(wù)器服務(wù)的。用生活里的例子打比方正向代理就像是幫你代購的熟人你告訴他想要什么他去買回來給你賣家看到的是這位熟人在采購。反向代理則像公司前臺訪客說“我要找技術(shù)部”前臺核實后把訪客領(lǐng)到對應(yīng)的工位訪客全程不需要知道技術(shù)部到底在三樓還是五樓。這個“領(lǐng)路”動作就是反向代理最核心的職責(zé)。1.2 有了它開發(fā)運維能省下哪些時間反向代理解決的問題不是我第一個想到的而是實際被逼出來的。舉一個最常見的場景公司買了多臺服務(wù)器分別跑著訂單服務(wù)、支付服務(wù)、用戶服務(wù)端口不一有的 8080有的 8081還有的 9090。你總不能讓用戶去記這些端口也不可能給每個服務(wù)單獨買一個域名。這時候在服務(wù)器最前面放一臺 Nginx監(jiān)聽 80/443 端口然后把不同路徑分別轉(zhuǎn)發(fā)到對應(yīng)服務(wù)。對外只有一個域名一種訪問方式內(nèi)部的服務(wù)怎么編排完全由后端決定調(diào)整起來也不影響用戶。再比如運維層面經(jīng)常需要做灰度發(fā)布或負載均衡。今天新增一臺實例想在老集群里先放少量流量觀察一下直接改 Nginx 的 upstream 配置把新實例權(quán)重調(diào)低秒級生效。服務(wù)掛了需要摘除也是改一行配置的事不用動業(yè)務(wù)代碼。從安全角度講反向代理還能藏住內(nèi)網(wǎng)的真實結(jié)構(gòu)。外部掃描只能看到 Nginx 這臺“入口機”后端應(yīng)用端口不對公網(wǎng)開放攻擊面立刻小了很多。加上我們后文要說的限流、IP 白名單、SSL 終止Nginx 實際上充當(dāng)了應(yīng)用防火墻和數(shù)據(jù)加密邊緣的雙重角色。1.3 我要去哪里看即可但有人困惑它和 Tomcat 沖突嗎這是個在技術(shù)社區(qū)里反復(fù)出現(xiàn)的誤會。很多 Java 開發(fā)者裝了 Tomcat也裝了 Nginx然后發(fā)現(xiàn)防火墻只開了 80 端口Tomcat 的 8080 從外面訪問不了就以為是配置對撞了。其實兩者根本不沖突。Tomcat 是應(yīng)用容器負責(zé)跑 Servlet、JSP 或者 Spring Boot 打出的包Nginx 是 Web 服務(wù)器和反向代理負責(zé)接收 HTTP 請求并決定把請求交到誰手里。生產(chǎn)環(huán)境里最常見的組合就是“Nginx80→ Tomcat8080”根本不會端口打架。你把 Tomcat 的端口改成 8080、8081 多個實例再把 Nginx 指向這些地址就搭建起了一套最原始的負載均衡集群。這個結(jié)構(gòu)在任何 Java 項目中都能直接復(fù)用和 Spring Cloud 這種微服務(wù)體系也不沖突Nginx 在七層做流量入口注冊中心在應(yīng)用內(nèi)部做服務(wù)發(fā)現(xiàn)各干各的一點都不矛盾。2. 動手前的第一件事Nginx 安裝的幾種姿勢2.1 從官網(wǎng)下載還是國內(nèi)鏡像差別在哪如果你只是想在本地 Windows 開發(fā)環(huán)境里快速體驗一把直接從官網(wǎng)nginx.org/en/download.html下載 Windows 版本即可。官網(wǎng)同時提供主線版本Mainline、穩(wěn)定版本Stable和歷史版本Legacy。我的建議是生產(chǎn)環(huán)境優(yōu)先選穩(wěn)定版因為主線版迭代快新功能多但相對的穩(wěn)定性驗證時間短測試環(huán)境則可以用主線版提前感受新特性。但國內(nèi)網(wǎng)絡(luò)環(huán)境大家都懂官網(wǎng)下載偶爾會慢到讓人懷疑人生。備選方案是使用國內(nèi)云廠商提供的開源鏡像站像阿里云鏡像、華為云鏡像都有 Nginx 的軟件包同步下載速度和穩(wěn)定性都有保障。裝完之后可以順手校驗一下版本和校驗和防止下載到不完整的文件。在 Linux 上我更推薦包管理器安裝省心、干凈、易卸載。這里有個小經(jīng)驗雖然包管理器裝出來的版本可能不是最新但系統(tǒng)集成度極高systemd 服務(wù)腳本、默認目錄結(jié)構(gòu)、日志輪轉(zhuǎn)全都幫你配好了對大多數(shù)人來說這才是“開箱即用”的正解。2.2 Windows 下的 Nginx解壓就能跑的輕量方案Windows 版本的 Nginx 不需要安裝程序它就是一個壓縮包解壓即用。我建議你把目錄放到一個不含中文和空格的路徑比如D:\nginx-1.26.2否則某些模塊在解析路徑時可能出現(xiàn)奇怪的問題。目錄結(jié)構(gòu)里最重要的就是conf/nginx.conf它是唯一的主配置文件。啟動方式是在命令行里切換到 Nginx 目錄執(zhí)行start nginx注意這里不要直接雙擊nginx.exe否則彈出的黑窗口會一直掛著而且關(guān)掉窗口后進程經(jīng)常殘留。使用start命令可以讓它在后臺運行。停止和重載指令分別是nginx -s stop nginx -s reload日常改完配置文件驗證語法用nginx -t它只做檢查不生效等確認無誤后再 reload。想確認進程是否真的起來了用tasklist /fi imagename eq nginx.exe如果看到兩個 nginx 進程那是正常的一個 master 一個 worker。Windows 下 Nginx 的性能表現(xiàn)弱于 Linux但拿來做本地開發(fā)調(diào)試、測試反向代理配置完全沒有問題。2.3 Linux 安裝AlmaLinux 9 和 Ubuntu 都能一條命令搞定在生產(chǎn)環(huán)境我強烈建議用 Linux。以 AlmaLinux 9 這種 RHEL 系發(fā)行版為例直接用 dnf 安裝sudo dnf install -y nginx sudo systemctl enable --now nginx nginx -vUbuntu 或 Debian 系則是sudo apt update sudo apt install -y nginx sudo systemctl enable --now nginx安裝完成后用systemctl status nginx可以看到服務(wù)處于 active (running) 狀態(tài)。默認的站點根目錄在/usr/share/nginx/html配置文件在/etc/nginx/nginx.conf子站點配置目錄是/etc/nginx/conf.d/。記住這幾個路徑后面修改配置時不會迷路。AlmaLinux 9 有一點點特殊。RHEL 9 的 AppStream 倉庫默認提供的 Nginx 版本往往不是最新的如果你有硬性版本要求比如需要 1.25 之后的特性那么建議到官網(wǎng)下載源碼包編譯或者使用 EPEL 源看有沒有更高版本可裝。生產(chǎn)環(huán)境未必需要最新版穩(wěn)定壓倒一切但如果你在編譯安裝平滑升級時正好卡在版本問題上這就是你能排查的方向之一。2.4 編譯安裝和高階注意事項源碼編譯安裝 Nginx 是一些大型互聯(lián)網(wǎng)公司的傳統(tǒng)做法。它可以自由控制模塊、安裝路徑和編譯參數(shù)可以把不需要的模塊剔掉以減少體積和攻擊面。編譯安裝的大致流程是sudo dnf install -y gcc pcre-devel zlib-devel openssl-devel wget https://nginx.org/download/nginx-1.26.2.tar.gz tar -zxvf nginx-1.26.2.tar.gz cd nginx-1.26.2 ./configure --prefix/usr/local/nginx \ --with-http_ssl_module \ --with-http_stub_status_module \ --with-http_realip_module make -j$(nproc) sudo make install這里有幾個關(guān)鍵依賴包pcre用于支持正則表達式重寫zlib用于 gzip 壓縮openssl用于 HTTPS。缺了哪個編譯階段就會直接報錯。我記得第一次編譯時因為沒裝 pcre-develconfigure 階段就卡住了查了半天才反應(yīng)過來是少了頭文件。編譯安裝的路徑和包管理器安裝差異很大Nginx 主程序在/usr/local/nginx/sbin/nginx配置文件在/usr/local/nginx/conf/nginx.conf。這時候沒有 systemd 管理腳本啟動、重啟得手動執(zhí)行nginx和nginx -s reload建議自己寫一份 systemd service 文件否則服務(wù)器一重啟 Nginx 是不會自動起來的。順帶提一句和本文主題有點關(guān)系但不屬于 Nginx 的題外話每次部署前后端項目新手往往會同時安裝 MySQL、Git、Node.js、Java 這些環(huán)境并且偶爾因為環(huán)境變量配置錯誤而折騰半天。這類環(huán)境變量問題和 Nginx 沒有直接依賴但如果你的 Java 項目需要讀取環(huán)境變量來啟動后端服務(wù)而環(huán)境變量沒配好那 Nginx 即使把請求轉(zhuǎn)發(fā)到 8080 端口也會因為后端根本沒起來而返回 502。排查連接問題的時候先確認后端進程在不在別把所有問題都甩給 Nginx。3. 核心配置拆解寫一份能直接上生產(chǎn)的反向代理3.1 最小可用的 server 塊Nginx 的主配置本質(zhì)就是一個層級結(jié)構(gòu)每個server {}代表一個虛擬主機每個location {}代表一種路徑匹配規(guī)則。一個最簡單但功能完整的反向代理配置如下server { listen 80; server_name api.example.com; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }listen指定 Nginx 監(jiān)聽的端口server_name是虛擬主機的識別名。當(dāng)外部請求攜帶的 Host 頭是api.example.com時Nginx 就會走進這個 server 塊處理請求。proxy_pass是靈魂指令它把請求轉(zhuǎn)發(fā)給http://127.0.0.1:8080。這里有幾個細節(jié)值得死磕。第一proxy_set_header Host $host;這行非常關(guān)鍵。如果不設(shè)置后端應(yīng)用收到的 Host 可能是 Nginx 的 IP 或者端口很多框架在生成絕對鏈接、校驗 CSRF、判斷域名時就會出錯。設(shè)置成$host可以讓后端感覺請求就是直接發(fā)給它自己的。第二X-Real-IP和X-Forwarded-For用于記錄真實客戶端 IP。后端拿不到用戶真實 IP 的時候十有八九是這兩行沒配。第三像 Spring Boot 這類框架如果想正確識別 HTTPS還需要看X-Forwarded-Proto上面的配置里也帶了。3.2 proxy_pass 的斜杠陷阱面試和實戰(zhàn)都愛考先看兩個配置location /api/ { proxy_pass http://backend:8080/; }和location /api/ { proxy_pass http://backend:8080; }區(qū)別在于proxy_pass后面是否帶路徑。不帶路徑時Nginx 會將location匹配到的完整 URI 原樣轉(zhuǎn)發(fā)給后端。也就是說請求/api/user/list后端最終收到的還是/api/user/list。帶路徑時情況完全不同Nginx 會把location中匹配到的那一段前綴“吃掉”再拼接上剩余路徑。還是請求/api/user/list因為匹配前綴是/api/后端最終收到的是/user/list。這個特性用好了可以做接口前綴隱藏用壞了就是“為什么前端明明請求/api/user后端卻說 404”的經(jīng)典事故。我建議大家在寫配置時統(tǒng)一一個習(xí)慣要么后端明確要求不帶前綴要么就全都帶上斜杠別今天寫一種明天寫另一種時間一長自己都記不住。3.3 把多個站點拆到獨立文件管理不要把所有 server 塊都堆在nginx.conf一個文件里那會讓幾千行配置擠在一起改一個站點都要小心翼翼。標準做法是利用 include 機制。Linux 安裝的 Nginx 默認會在主配置末尾包含include /etc/nginx/conf.d/*.conf;所以你可以在/etc/nginx/conf.d/下為每個業(yè)務(wù)建一個獨立文件比如api.conf、admin.conf、map.conf。每個文件里只寫自己的 server 塊。這樣做的好處是互不污染、便于 git 管理、出問題時能快速定位到具體文件壞處是如果文件命名太隨意過段時間你會發(fā)現(xiàn)它變成了“無人認領(lǐng)的配置垃圾場”。Windows 版的conf/nginx.conf默認只配置了一個示例 server沒有自動 include 子目錄。你可以手動在 http 塊里加一行指定加載conf/sites/*.conf下的文件然后自行創(chuàng)建這個目錄。改完目錄結(jié)構(gòu)后記得執(zhí)行nginx -t檢查語法然后 reload 生效。3.4 實際場景內(nèi)網(wǎng)地圖服務(wù)是怎么做反向代理的這是我從熱搜詞里看到的一個挺有意思的問題內(nèi)網(wǎng)要反向代理地圖供內(nèi)網(wǎng)使用以百度地圖為例應(yīng)該怎么做。這個需求我見過很多次企業(yè)內(nèi)部開發(fā)的系統(tǒng)比如物流管理、工地監(jiān)控需要在地圖上展示設(shè)備和車輛位置但前端直接訪問公網(wǎng)地圖服務(wù)既慢又不可控還容易遇到跨域限制。做法并不復(fù)雜。首先確認企業(yè)內(nèi)部使用的地圖服務(wù)是否有合法授權(quán)無論是百度地圖還是其他商業(yè)地圖服務(wù)都要求開發(fā)者賬號、AK/SK 之類的認證。接下來在 Nginx 上新建一個專門的地圖入口例如把/map/路徑反向代理到后端地圖地址同時在代理過程中統(tǒng)一追加認證參數(shù)location /map/ { proxy_pass https://map-backend.internal.example.com/; proxy_set_header Host map-backend.internal.example.com; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # 統(tǒng)一追加授權(quán)AK避免每個前端都暴露密鑰 set $full_uri $request_uri; if ($args !~* ak) { rewrite ^ $request_uri?akYOUR_AK last; } }當(dāng)然上面的 rewrite 寫法只是一個粗略示意生產(chǎn)環(huán)境更推薦在應(yīng)用層維護一個服務(wù)端代理接口由后端去拼接密鑰。但你已經(jīng)能看出關(guān)鍵思路了Nginx 可以做內(nèi)網(wǎng)流量的統(tǒng)一入口把需要外部訪問的地址收斂成一個內(nèi)網(wǎng)域名前端應(yīng)用只對接這個內(nèi)網(wǎng)域名網(wǎng)絡(luò)拓撲簡單密鑰也不容易泄露。順帶一提把 Nginx 當(dāng)作共享文件服務(wù)器也是一個高頻需求也就是熱搜里提到的“nginx 共享文件”。只需在 location 里打開目錄索引location /files/ { alias /data/files/; autoindex on; autoindex_exact_size off; autoindex_localtime on; }autoindex on會讓訪問者看到文件列表網(wǎng)頁可以像瀏覽下載站一樣點擊下載。不過公網(wǎng)環(huán)境建議別開autoindex加了認證和限速再考慮。4. 從單點走向集群反向代理和負載均衡4.1 upstream 塊與常用負載均衡策略反向代理一次只能轉(zhuǎn)發(fā)到一個后端地址負載均衡則是同時管理多個后端地址并分配流量。Nginx 用upstream塊來定義一組后端服務(wù)器然后在proxy_pass里引用這組的名字upstream backend_pool { server 127.0.0.1:8080 weight3; server 127.0.0.1:8081 weight1; server 127.0.0.1:8082 down; keepalive 32; } server { listen 80; server_name app.example.com; location / { proxy_pass http://backend_pool; proxy_http_version 1.1; proxy_set_header Connection ; } }Nginx 默認使用輪詢Round Robin策略請求依次打到 8080、8081、8080、8081……加weight3之后8080 被選中的概率是 8081 的三倍適合新服務(wù)器剛開始灰度、想多送點流量過去觀察情況的場景。down標記表示這臺服務(wù)器不參與負載比如它正在維護。如果業(yè)務(wù)依賴用戶會話比如用戶登錄狀態(tài)存在本地 Session不能隨便換節(jié)點那就得用ip_hashupstream backend_pool { ip_hash; server 127.0.0.1:8080; server 127.0.0.1:8081; }ip_hash會基于客戶端 IP 計算哈希保證同一個 IP 的請求每次都落到同一臺后端從根本上解決 Session 漂移問題。它也有缺點如果某一臺后端掛了哈希到該節(jié)點的用戶會短暫受影響直到后續(xù)請求被重新分配。另一種更平滑的方案是least_conn它會讓新請求優(yōu)先分配給當(dāng)前并發(fā)連接數(shù)最少的后端適合后端處理能力差異較大的場景。4.2 被動健康檢查與故障轉(zhuǎn)移很多人以為 Nginx 的反向代理天然具備健康檢查能力其實“開箱即用”的是被動健康檢查。Nginx 默認在請求轉(zhuǎn)發(fā)失敗后會嘗試把請求轉(zhuǎn)發(fā)給 upstream 里的下一臺服務(wù)器這個行為由以下參數(shù)控制upstream backend_pool { server 127.0.0.1:8080 max_fails3 fail_timeout10s; server 127.0.0.1:8081 max_fails3 fail_timeout10s; }意思是 10 秒內(nèi)如果這臺后端失敗次數(shù)達到 3 次Nginx 就把它標記為不可用并且在這 10 秒內(nèi)不再把新請求轉(zhuǎn)發(fā)給它。這種機制不需要額外的模塊配置簡單但它是“出事之后才知道”的被動模式。如果你需要周期性主動探測后端健康狀態(tài)就需要 Nginx Plus 的商業(yè)模塊或者使用官方開源的nginx_upstream_check_module補丁包。考慮到生產(chǎn)環(huán)境的可用性要求我個人的經(jīng)驗是Nginx 做基礎(chǔ)故障轉(zhuǎn)移就夠了真正的精細化健康檢查交給上層的服務(wù)治理框架比如 Spring Cloud 的注冊中心、Kubernetes 的探針。不要試圖讓 Nginx 承擔(dān)它不擅長的事層級清晰故障排查才不混亂。4.3 不止 HTTPstream 模塊做四層反向代理Nginx 不僅支持 HTTP/HTTPS 反向代理還能通過stream模塊做 TCP/UDP 的四層轉(zhuǎn)發(fā)。常見的場景是 MySQL 集群、Redis 集群、MongoDB 數(shù)據(jù)庫的訪問入口統(tǒng)一收斂。什么意思呢假設(shè)你有三臺 Redis分別跑在 10.0.0.3、10.0.0.4、10.0.0.5 上直接讓業(yè)務(wù)方記住 IP 列表不現(xiàn)實改成讓業(yè)務(wù)方統(tǒng)一連 Nginx 的 16379 端口Nginx 再把 TCP 流量轉(zhuǎn)發(fā)到這三臺 Redis。配置寫在stream塊中它和http塊平級不能嵌套在 http 塊里。示例stream { upstream redis_backend { server 10.0.0.3:6379; server 10.0.0.4:6379; server 10.0.0.5:6379; } server { listen 16379; proxy_pass redis_backend; proxy_timeout 30s; } }默認編譯的 Nginx 可能沒有stream模塊確認方法很簡單執(zhí)行nginx -V查看編譯參數(shù)里是否包含--with-stream。如果沒有編譯安裝時就加上這個參數(shù)。要注意四層代理無法讀取 HTTP 層信息所以做不了 URL 級別的路由也無法做 WebSocket 的 HTTP 升級它的優(yōu)勢是透明、高效適用于任意 TCP 協(xié)議。5. 進階玩法SSL、WebSocket、緩存與安全加固5.1 配置 HTTPS 和 HTTP/2給反向代理入口加上 HTTPS是保護數(shù)據(jù)鏈路的第一道門檻。證書文件放在 Nginx 可讀取的路徑下一個帶 SSL 的 server 塊大致長這樣server { listen 443 ssl http2; server_name api.example.com; ssl_certificate /etc/nginx/certs/api.example.com.crt; ssl_certificate_key /etc/nginx/certs/api.example.com.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Forwarded-Proto https; } }這里有兩個關(guān)鍵點第一X-Forwarded-Proto必須設(shè)置為https后端框架才會正確識別用戶是通過 HTTPS 訪問的否則重定向生成 http 鏈接頁面加載時瀏覽器會報不安全。第二listen 443 ssl后面追加http2現(xiàn)代瀏覽器就能啟用 HTTP/2 多路復(fù)用實際體驗是并發(fā)請求性能明顯提升。如果你使用的是較新的 Nginx 版本http2指令已經(jīng)并入listen參數(shù)這種寫法是兼容的。5.2 WebSocket 反向代理升級頭是關(guān)鍵WebSocket 比普通 HTTP 多了一次協(xié)議升級的過程。Nginx 默認情況下會剝離Upgrade和Connection頭導(dǎo)致 WebSocket 握手失敗。處理方式是在 location 里顯式聲明location /ws/ { proxy_pass http://websocket_backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_read_timeout 3600s; proxy_send_timeout 3600s; }三行必配項是proxy_http_version 1.1、proxy_set_header Upgrade $http_upgrade;、proxy_set_header Connection upgrade;。$http_upgrade是 Nginx 內(nèi)置變量它會原樣透傳客戶端發(fā)來的 Upgrade 頭。proxy_read_timeout 3600s是很多新手忽略的點WebSocket 連接建立后會長時間保持空閑如果超時時間還是默認的 60 秒一分鐘后連接就被斷開了前端會頻繁重連表現(xiàn)就是“消息時不時丟了”。這套配置在聊天系統(tǒng)、協(xié)同編輯、實時通知項目里都能直接復(fù)用。如果你用了 uni-app 的 video 組件或者 WebSocket 類的應(yīng)用部署到生產(chǎn)環(huán)境時記得檢查這一步否則測試環(huán)境好好的一上服務(wù)器就走不通。5.3 靜態(tài)資源緩存和訪問控制反向代理經(jīng)常也承擔(dān)緩存功能。Nginx 可以把后端返回的靜態(tài)資源緩存到本地磁盤減少后端壓力。先定義緩存區(qū)proxy_cache_path /data/nginx/cache levels1:2 keys_zonestatic_cache:50m inactive7d max_size5g;再在 location 中使用location ~* \.(png|jpg|css|js|woff2)$ { proxy_cache static_cache; proxy_cache_valid 200 302 24h; proxy_cache_valid 404 1m; proxy_set_header Host $host; proxy_pass http://accessed; add_header X-Cache-Status $upstream_cache_status; }響應(yīng)頭里的X-Cache-Status可以看到命中情況HIT 表示緩存命中MISS 表示未命中這個調(diào)試信息非常有用。但緩存的坑也很明顯后端更新了圖片或 JS前端還是舊內(nèi)容排障時首先確認proxy_cache_bypass和proxy_no_cache有沒有配合設(shè)置以及版本號是否變化。一般我會對帶版本號的靜態(tài)文件開長緩存對 API 響應(yīng)完全不開緩存避免數(shù)據(jù)不一致。5.4 限流、IP 白名單與安全頭安全加固這塊很多人容易到最后才想起來。Nginx 內(nèi)置了limit_req模塊可以針對單位時間內(nèi)的請求頻率做限制limit_req_zone $binary_remote_addr zoneapi_limit:10m rate5r/s; server { location /api/ { limit_req zoneapi_limit burst10 nodelay; proxy_pass http://backend_pool; } }rate5r/s表示每秒只能放行 5 個請求burst10表示允許瞬時最多 10 個請求排隊nodelay則讓排隊請求不延遲。把限流配在登錄接口、短信驗證碼接口前能擋住很大一部分暴力請求。IP 白名單則簡單粗暴location /admin/ { allow 10.0.0.0/8; allow 192.168.1.100; deny all; proxy_pass http://admin_backend; }allow和deny按從上到下的順序匹配命中allow就不再繼續(xù)往下檢查。這里要格外注意deny all必須放在最后否則會攔截所有來源。再加上常見的安全響應(yīng)頭比如X-Content-Type-Options、X-Frame-Options就能給整體安全加分。網(wǎng)絡(luò)上常把這套機制稱為“安全配置管理器”其實就是把各種防護用 Nginx 組合起來思路比工具本身更重要。6. 配置過程中最常踩的坑與排查方法6.1 端口占用導(dǎo)致啟動失敗Nginx 啟動時報bind() to 0.0.0.0:80 failed (98: Address already in use)幾乎每個新手都遇到過。原因要么是 Nginx 已經(jīng)有一個 master 進程在運行要么是 Apache、Tomcat 或者其他 Web 程序占用了 80 端口。排查手段是先看進程再找端口ps -ef | grep nginx sudo lsof -i :80如果確實是 Nginx 自己殘留的進程執(zhí)行nginx -s stop或者sudo systemctl stop nginx再啟動。如果是別的程序占用兩種選擇殺掉別的程序或者修改 Nginx 監(jiān)聽端口。Windows 下排查命令是netstat -ano | findstr :80看到 LISTENING 狀態(tài)的 PID 后到任務(wù)管理器里核對進程身份。6.2 配置改了不生效先 test 再 reload很多人改完配置不執(zhí)行任何命令直接刷新頁面發(fā)現(xiàn)沒變化就一臉霧水。Nginx 的配置只有在reload之后才會加載生效而且加載前一定要先做語法檢查nginx -t如果輸出syntax is ok和test is successful再執(zhí)行 reload。如果配置有問題nginx -t會明確告訴你錯誤在第幾行比瀏覽器里一片空白好排查得多。在include多文件場景下配置文件名有錯、目錄權(quán)限不對、末尾少了分號都會導(dǎo)致nginx -t報錯。分號這一點特別常見一行配置忘記結(jié)尾分號后面的所有配置都會被解析成同一行報錯位置可能離真實出錯點很遠。平時我建議養(yǎng)成一個固定習(xí)慣任何配置改動三步走——備份、nginx -t、nginx -s reload。到大型架構(gòu)里會先從灰度環(huán)境驗證再動生產(chǎn)環(huán)境道理一樣只是規(guī)模放大。6.3 502 與 504 的排查路徑502 Bad Gateway 很常見值就是 Nginx 已經(jīng)啟動但它找不到能轉(zhuǎn)發(fā)的后端。排查順序我固定如下先看后端進程是否存活再看后端端口是否監(jiān)聽成功然后用 curl 模擬請求看后端響應(yīng)。例如curl -I http://127.0.0.1:8080/health如果 curl 能通Nginx 卻 502問題多半出在 Nginx 配置文件里的proxy_pass地址寫錯了或者后端的 Host 校驗不通過。如果 curl 不通那就是后端服務(wù)本身的問題去查應(yīng)用日志。另一種情況是 504 Gateway Timeout意思是 Nginx 把請求轉(zhuǎn)過去了但后端在規(guī)定時間內(nèi)沒返回。這時候調(diào)整proxy_read_timeout、proxy_connect_timeout時間同時排查后端是否有慢查詢、死鎖或者線程池耗盡的問題后者才是根因。6.4 日志是排障的第一現(xiàn)場“日志在手天下我有”這句話放在 Nginx 排障里再合適不過。默認錯誤日志在/var/log/nginx/error.log訪問日志在/var/log/nginx/access.log。遇到問題先別急著猜打開錯誤日志看看sudo tail -n 100 /var/log/nginx/error.log sudo tail -n 100 /var/log/nginx/access.log錯誤日志里會記錄啟動失敗的詳細原因、SSL 證書路徑問題、upstream 連接失敗等。訪問日志配合awk命令可以快速統(tǒng)計請求量、狀態(tài)碼分布awk {print $9} /var/log/nginx/access.log | sort | uniq -c | sort -rn把日志按天切割、定期歸檔是生產(chǎn)環(huán)境的基本要求否則日志文件越滾越大磁盤空間被占滿時 Nginx 會拒絕寫入新請求日志表現(xiàn)也是詭異的“不響應(yīng)”。6.5 關(guān)于平滑升級的細節(jié)Nginx 的平滑升級是我見過最多人搞混的概念。很多人把nginx -s reload當(dāng)成平滑升級其實 reload 只是重載配置二進制程序版本并沒有變。真正的平滑升級是要替換 Nginx 可執(zhí)行文件本身同時保證正在處理的請求不中斷。常規(guī)做法是編譯新版本到新路徑然后通過發(fā)送信號讓舊 master 優(yōu)雅退出、新 master 接管。這個操作在生產(chǎn)環(huán)境可以做但風(fēng)險也不小尤其是編譯參數(shù)沒保持一致時模塊丟失的情況時有發(fā)生。我的建議是如果你的 Nginx 是系統(tǒng)包管理器安裝的優(yōu)先用系統(tǒng)的升級命令比如dnf update nginx或者apt upgrade nginx發(fā)行版已經(jīng)把平滑升級的細節(jié)處理好風(fēng)險低得多。只有當(dāng)你必須使用自定義編譯參數(shù)時才去手動做二進制替換并且一定要先在同樣配置的測試機上演練一遍。7. 面試和晉升答辯里最常被問到的 Nginx 話題7.1 反向代理與正向代理的區(qū)別這是 Nginx 面試題的“必考項”。核心差異從流量方向就能講清楚正向代理代理的是客戶端隱藏客戶端身份訪問外部資源反向代理代理的是服務(wù)端隱藏服務(wù)端真實地址對外提供統(tǒng)一入口。兩者都是代理但服務(wù)對象完全不同。舉例說明最有說服力。員工通過公司正向代理訪問外網(wǎng)外網(wǎng)網(wǎng)站看到的是代理服務(wù)器 IP不是員工本地 IP用戶訪問電商網(wǎng)站請求先進 Nginx 再進后端用戶看到的只是 Nginx 的 IP內(nèi)部服務(wù)器 IP 對外完全不可見。凡是想表達“我理解架構(gòu)抽象層次”的時候用這個例子都能加分。7.2 Nginx 為什么能扛住高并發(fā)一個經(jīng)常被問到的問題是“Nginx 高并發(fā)的原理是什么”。答案集中在事件驅(qū)動模型和多進程架構(gòu)上。Nginx 啟動后有一個 master 進程管理全局多個 worker 進程并行處理請求。每個 worker 采用基于 epoll 的事件驅(qū)動機制管理大量連接而不是像傳統(tǒng) Apache 那樣每個連接派生一個進程或者線程。epoll 能夠在大量連接中快速找出哪些是活躍事件讓 Nginx 用相對很少的線程數(shù)支撐幾十萬并發(fā)連接。我還喜歡用食堂打飯類比傳統(tǒng)模型是每個窗口有一個人專門服務(wù)一個學(xué)生人多就得開一堆窗口Nginx 的模式是一個窗口的服務(wù)員同時看著所有排隊的學(xué)生誰有動靜就先服務(wù)誰。同樣的食堂面積能服務(wù)的人完全不同。7.3 Nginx 和 Apache 的核心差異互聯(lián)網(wǎng)老前輩都知道 Apache 曾經(jīng)統(tǒng)治 Web 服務(wù)器很多年但面對高并發(fā)場景Apache 的同步阻塞模型逐漸吃力Nginx 才以黑馬姿態(tài)崛起。Nginx 的優(yōu)勢主要體現(xiàn)在內(nèi)存占用低、靜態(tài)文件處理性能強、反向代理和負載均衡的天然優(yōu)勢Apache 的優(yōu)勢則是模塊生態(tài)極其豐富配置文件對開發(fā)者友好有大量.htaccess級別的目錄級配置能力。今天很多項目其實兩者并存Apache 負責(zé)內(nèi)部傳統(tǒng)業(yè)務(wù)Nginx 做統(tǒng)一入口各取所長。如果是面試里讓我一句話回答我會說“Nginx 勝在高并發(fā)和反向代理上的優(yōu)雅Apache 勝在功能和模塊的全面。選型上如果追求性能和靈活度Nginx 幾乎是更優(yōu)解?！?.4 順手寫幾個高頻配置片段除了理論面試也經(jīng)常讓手寫配置。最經(jīng)典的就是“請配置一個反向代理把/api請求轉(zhuǎn)發(fā)到http://127.0.0.1:8080”。我會順手把 Host 頭、真實 IP、超時時間一并寫出來先把 80 端口監(jiān)聽好再配一個帶 SSL 的 443 端口。其次是“如何配置負載均衡”直接寫出帶weight和ip_hash的 upstream 塊。面試官看完基本就能判斷你是不是真的敲過配置。這幾個片段覆蓋了日常大半需求寫熟它們比背一堆理論有用。8. 最后分享一點我的實操體會我自己在多個項目里用過 Nginx從單機部署到多節(jié)點負載均衡從 HTTP 到 HTTPS 再到 WebSocket踩過的坑數(shù)都數(shù)不過來。要說最有價值的經(jīng)驗就是“配置能小則小”。很多教程給你一大段完整配置看得人頭暈其實生產(chǎn)環(huán)境真正必需的指令就那么十幾條。每加一條指令往前排查問題的復(fù)雜度就增加一分所以不要盲目復(fù)制別人有歷史包袱的配置每多一個if多一個 rewrite都要想清楚它到底解決什么問題。另外建議大家學(xué)著把 Nginx 配置納入版本管理從一個空目錄開始每個業(yè)務(wù)一個文件文件名帶清晰前綴改動前先備份改完先nginx -t。這套習(xí)慣比任何花哨工具都管用。遇到后端返回異常時記得第一時間看 Nginx 和后端兩邊的日志大多數(shù)“玄學(xué)問題”在日志面前都是紙老虎。希望這篇內(nèi)容能幫你少走幾步彎路把 Nginx 反向代理真正變成你順手順心的工具。