聊到 Nginx很多剛接觸服務端的朋友第一反應是“這不就是個 Web 服務器嘛”等真正把它丟進生產(chǎn)環(huán)境才發(fā)現(xiàn)Nginx 的作用和應用場景比想象中大得多靜態(tài)資源服務、反向代理、負載均衡、HTTPS 證書卸載、緩存加速、限流防刷……幾乎每一層都能看到它的身影。這篇文章我想從一個“普通問題”聊起把 Nginx 的核心作用一條條拆開再結合我這些年實際踩過的坑從安裝配置到平滑升級、問題排查給你一份可以直接抄作業(yè)的完整參考。整套內(nèi)容適合剛入門的人也適合已經(jīng)部署過 Nginx 但沒系統(tǒng)梳理過的同學。我盡量不說廢話全部以實際場景和可復現(xiàn)的配置為準。1. Nginx 到底在解決什么問題先說一個最容易被忽略的事實Nginx 最初解決的是 C10K 問題也就是單機能不能扛住一萬個并發(fā)連接。2004 年它剛出來的時候市面上的主流做法還是“每個請求一個進程”的 Apache 模型。連接一多內(nèi)存和 CPU 就被進程調度吃干凈機器直接卡死。Nginx 的思路完全不同它用事件驅動、異步非阻塞的模型用少量 worker 進程就能撐住海量連接。一個進程可以同時處理成千上萬個請求就像餐廳里一個優(yōu)秀的排號員同時在服務幾十桌客人而不是每個客人配一個專屬服務員。放到今天Nginx 的核心功能已經(jīng)發(fā)展成四塊靜態(tài)資源服務圖片、CSS、JS、HTML、音視頻交給它又穩(wěn)又快。反向代理把請求轉發(fā)到后端的應用服務器比如 Java 的 Spring Boot、Node.js、PHP-FPM。負載均衡把流量分攤到多臺后端機器避免一臺被壓垮。安全與加速SSL/TLS 證書卸載、HTTP/2、HTTP/3QUIC、限流、緩存、訪問控制。所以你看很多團隊把 Nginx 放在所有流量的最前面它不是簡單的“網(wǎng)頁服務器”而是整個系統(tǒng)的入口網(wǎng)關。我個人的理解是Nginx 是“連接用戶和后端服務之間的那雙手”。用戶請求進來它決定把人帶到哪個頁面、哪個后端接口、哪臺服務器如果后端掛了它還能幫忙擋一下。這個角色決定了它的配置方式五花八門但底層邏輯始終只有一條——把請求處理到正確的地方。下面我就逐個拆開講。2. 拆開 Nginx 的四個核心作用2.1 靜態(tài)資源服務最基礎也最容易被忽視靜態(tài)資源服務是 Nginx 的基本功也是很多人第一次接觸它的原因。你本地跑了一個 Vue 或 React 項目執(zhí)行pnpm run build之后生成一個 dist 目錄想讓別人能訪問最簡單的辦法就是讓 Nginx 直接托管這個目錄。配合熱詞里看到的“pnpm run build 的包怎么 nginx 啟動”其實就是把構建產(chǎn)物丟到 Nginx 的 root 路徑下。一個最簡單的托管配置server { listen 80; server_name example.com; root /data/www; index index.html; location / { try_files $uri $uri/ /index.html; } }注意最后那個try_filesSPA 項目基本都靠它。前端路由是 history 模式時比如/user/123服務器上根本不存在這個物理文件如果不加try_files直接刷新頁面會 404。try_files $uri $uri/ /index.html的含義是先找這個路徑有沒有對應文件沒有再找有沒有對應目錄都沒有就統(tǒng)一返回index.html讓前端路由自己去處理。靜態(tài)資源這塊有幾個關鍵性能參數(shù)值得單獨說sendfile on; tcp_nopush on; keepalive_timeout 65; gzip on; gzip_types text/plain text/css application/javascript application/json image/svgxml; gzip_min_length 1k; location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2?)$ { expires 30d; add_header Cache-Control public, immutable; }sendfile讓文件從磁盤到網(wǎng)卡的拷貝過程由內(nèi)核直接完成減少用戶態(tài)切換。gzip壓縮文本類文件實測靜態(tài)資源體積能減少 60% 以上。expires 30d給靜態(tài)資源設置瀏覽器緩存二次訪問幾乎無延遲。我見過很多團隊花大價錢優(yōu)化后端接口結果前端靜態(tài)資源一個 gzip 都沒開首屏加載能慢三倍。靜態(tài)資源托管是最簡單的優(yōu)化起點。2.2 反向代理讓請求去它該去的地方反向代理是 Nginx 使用頻率最高的功能。所謂反向代理就是用戶請求先到 NginxNginx 再按照規(guī)則轉發(fā)到后端的應用服務器。用戶可以感知到的只有 Nginx后端服務器具體在哪、有多少臺對用戶是透明的。對應的還有正向代理那是替客戶端轉發(fā)請求的常用于內(nèi)網(wǎng)訪問外網(wǎng)。Nginx 做的是反過來的事替服務器收請求所以叫反向代理。一個典型的 API 轉發(fā)配置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; } }這里有幾個容易忽略的點第一proxy_set_header Host $host非常重要。后端很多框架會根據(jù) Host 頭生成跳轉鏈接或判斷域名如果不帶上后端拿到的一律是 Nginx 的內(nèi)網(wǎng)地址簽名校驗、單點登錄、跨域這些全都會出問題。第二X-Real-IP和X-Forwarded-For是為了讓后端拿到用戶真實 IP。如果沒有這兩個配置后端日志里看到的所有請求 IP 都是 Nginx 的地址一旦要做封禁、限流、審計完全沒法搞。第三proxy_pass后面有沒有子路徑行為完全不一樣。比如location /api/ { proxy_pass http://backend/; }這種寫法會把/api/前綴去掉再轉發(fā)。而location /api/ { proxy_pass http://backend; }這種不帶尾部/的會把完整的/api/...路徑直接拼到后端地址后面。這個細節(jié)是大坑我見過不下五次因為這里多一個斜杠少一個斜杠導致接口 404。熱詞里有一條“nginx 限制只轉發(fā)帶參數(shù)的 url”這個需求本質就是按照查詢參數(shù)決定要不要轉發(fā)。常見做法是在 location 里判斷$arg_或$query_stringlocation /api/ { if ($args ~ token.) { proxy_pass http://backend; break; } return 404; }意思很直白請求里帶了 token 參數(shù)才轉發(fā)否則直接返回 404。break的作用是命中 if 之后不再繼續(xù)走后續(xù) rewrite 規(guī)則。需要注意的是Nginx 的if指令在很多場景下有坑官方文檔只建議在 return、rewrite 這類場景用整體轉發(fā)邏輯盡量謹慎能用location或map實現(xiàn)就不要硬寫一堆 if。2.3 負載均衡把流量攤到多臺機器上當單臺后端扛不住并發(fā)你就需要橫向擴容前面放一個 Nginx 做負載均衡。Nginx 的upstream模塊就是干這個的配合請求量把流量分發(fā)到不同后端。最小的負載均衡配置upstream backend_cluster { server 192.168.1.10:8080 weight3; server 192.168.1.11:8080 weight1; server 192.168.1.12:8080 backup; } server { listen 80; server_name app.example.com; location / { proxy_pass http://backend_cluster; proxy_set_header Host $host; } }這里我用了三個節(jié)點前兩臺權重是 3:1意思是每 4 個請求里約 3 個打到 10 這臺1 個打到 11 這臺。權重適合兩臺機器配置不一樣的場景配置高的多加一點流量。第三臺打了backup標記平時不參與服務只有前面兩臺都掛了才啟用。這相當于一個災備節(jié)點自動化切換。除了權重輪詢Nginx 還支持ip_hash按用戶 IP 的哈希結果分配同一 IP 固定打到同一臺后端。適合需要 session 保持的老項目。least_conn優(yōu)先發(fā)給當前連接數(shù)最少的后端適合請求處理時長差異較大的場景。負載均衡不是單純“把請求發(fā)出去”還要考慮后端健康狀態(tài)。Nginx 有被動健康檢查即請求轉發(fā)后如果連續(xù)失敗max_fails次就把這臺服務器臨時標記為不可用等fail_timeout時間后再重試。常用配置upstream backend_cluster { server 192.168.1.10:8080 max_fails2 fail_timeout30s; server 192.168.1.11:8080 max_fails2 fail_timeout30s; }意思是 30 秒內(nèi)失敗 2 次就摘掉這個節(jié)點30 秒后再試探。這種機制應對日常宕機足夠了但它屬于“事后發(fā)現(xiàn)”請求已經(jīng)轉發(fā)過去并失敗了。如果要求更主動的健康探測得用商業(yè)版 Plus 或者配合第三方模塊也可以用腳本定時探測后動態(tài)修改 upstream。關于高可用線上一般會再加一層 keepalived把 Nginx 本身做成雙機熱備用虛擬 IPVIP對外提供服務。一臺 Nginx 掛了VIP 自動漂移到另一臺對用戶完全無感知。這里不展開講 keepalived 的配置但方向是明確的Nginx 做流量入口keepalived 做入口的 “保險絲”。2.4 SSL/TLS 終端證書卸載與安全加速現(xiàn)在大部分網(wǎng)站都是 HTTPS證書配置是每個 Nginx 用戶繞不開的活。Nginx 在 SSL 這塊的位置也非常特殊它通常是 TLS 連接的“終點站”外網(wǎng)客戶端和 Nginx 之間走 HTTPSNginx 和后端之間可以走內(nèi)網(wǎng) HTTP。這樣做的原因很實際TLS 握手和加解密都是 CPU 密集操作把這事集中在 Nginx 這一層做后端應用就能省出大量 CPU 去處理業(yè)務邏輯。一段常規(guī) HTTPS 配置server { listen 443 ssl; http2 on; server_name www.example.com; ssl_certificate /etc/nginx/certs/example.com.pem; ssl_certificate_key /etc/nginx/certs/example.com.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; location / { proxy_pass http://backend; } } server { listen 80; server_name www.example.com; return 301 https://$host$request_uri; }第一個server塊監(jiān)聽 443 端口加載證書處理加密流量第二個server塊把 80 端口的 HTTP 請求全部 301 跳轉到 HTTPS。很多小項目直接用這一套就完成了 HTTPS 改造。ssl_protocols建議只保留 TLSv1.2 和 TLSv1.3老舊的 TLSv1.0、TLSv1.1 都有已知漏洞沒必要為了兼容十幾年前的瀏覽器留著。順帶說一下熱詞里的 “docker pull nginx quic 協(xié)議”。QUIC 是 HTTP/3 的底層傳輸協(xié)議Nginx 從 1.25.0 開始對 HTTP/3 的支持逐漸成熟。要啟用 HTTP/3Nginx 編譯時需要加--with-http_v3_module參數(shù)然后在 listen 指令里加上http3listen 443 quic reuseport; listen 443 ssl; http3 on;如果你的 Nginx 是官方通過 yum/apt 安裝的版本先確認版本和編譯參數(shù)是否帶了 HTTP/3 模塊可以用nginx -V看。Docker 鏡像docker pull nginx拉下來之后官方主線版鏡像是否包含 v3 模塊取決于鏡像構建參數(shù)需要先nginx -V 21 | grep http_v3驗證。如果沒帶就考慮用源碼編譯或換成帶模塊的鏡像。QUIC 確實能顯著改善弱網(wǎng)環(huán)境下的連接成功率但部署復雜度也更高不是所有項目都急著上。3. 應用場景與選型什么時候該用 Nginx3.1 前端接入層統(tǒng)一入口大多數(shù) Web 項目的第一層入口就是 Nginx。它的作用相當于一個“前臺接待”所有外部請求先到這里再根據(jù)域名、路徑、請求頭分發(fā)到不同服務按域名區(qū)分api.example.com走 API 服務admin.example.com走管理后臺。按路徑區(qū)分/api/*走后端接口/static/*走靜態(tài)資源/websocket走長連接服務。按請求方法區(qū)分讀接口和寫接口分到不同的上游。有了這一層后端的任何服務都不需要直接暴露公網(wǎng) IP只需要監(jiān)聽內(nèi)網(wǎng)端口整個入口的收口和安全控制都變得很輕松。限流也是入口層常見的需求。比如給登錄接口加限制limit_req_zone $binary_remote_addr zonelogin_limit:10m rate10r/m; location /api/login { limit_req zonelogin_limit burst5 nodelay; proxy_pass http://backend; }這里rate10r/m表示每分鐘最多 10 個請求burst5表示允許突發(fā) 5 個進入排隊隊列。對登錄、短信驗證碼這類高風險接口限流是必須的。3.2 動靜分離前端靜態(tài)資源與后端動態(tài)接口解耦傳統(tǒng)后端渲染的項目尤其是 PHP、Java 單體應用靜態(tài)資源和動態(tài)接口都混在一起。用戶訪問一個頁面服務器既要讀模板文件又要查數(shù)據(jù)庫全部串行處理慢且耗資源。用 Nginx 做動靜分離之后靜態(tài)資源直接走 Nginx 文件系統(tǒng)動態(tài)請求才轉發(fā)給后端location ~* \.(html|css|js|png|jpg|gif|ico|svg|woff2?)$ { root /data/static; expires 7d; } location / { proxy_pass http://backend; }動靜分離對混合架構特別有用。比如前端用 React 構建靜態(tài)頁面后端用 Java 提供 API整體結構就是Nginx 托管前端靜態(tài)文件同時把/api/請求轉發(fā)到 Java 服務。這也是現(xiàn)在最常見的前后端分離部署形態(tài)。3.3 微服務與 API 網(wǎng)關場景微服務架構里每個服務可能單獨部署在一組機器上客戶端不可能記住每個服務的地址。Nginx 可以作為輕量 API 網(wǎng)關按路徑把請求分發(fā)到不同的微服務upstream order_service { server 10.0.0.11:8080; server 10.0.0.12:8080; } upstream user_service { server 10.0.1.11:8080; server 10.0.1.12:8080; } server { listen 80; server_name gateway.example.com; location /api/order/ { proxy_pass http://order_service/; } location /api/user/ { proxy_pass http://user_service/; } }服務規(guī)模不大時這種輕量網(wǎng)關方案比引入全套微服務網(wǎng)關框架要簡單得多。它沒有臃腫的依賴規(guī)則就是純文本配置文件Git 管理、版本回滾都方便。只有當你需要復雜的服務發(fā)現(xiàn)、動態(tài)路由、熔斷、灰度發(fā)布時才應該考慮更重的網(wǎng)關方案。3.4 Nginx、Apache、HAProxy 怎么選這是一個被問爛了但又必須回答的問題。我習慣用下面這張表總結對比項NginxApacheHAProxyEnvoy并發(fā)模型事件驅動異步非阻塞進程/線程模型事件驅動事件驅動靜態(tài)資源處理強一般不支持一般七層路由能力強強較弱強四層轉發(fā)TCP/UDP支持stream較弱非常強支持動態(tài)配置需 reload需 reload需 reload支持 API 熱更新上手成本低低中高生態(tài)成熟度極高高高快速增長簡單說需要同時處理靜態(tài)文件和動態(tài)反代首選 Nginx純四層高并發(fā)流量轉發(fā)HAProxy 更專業(yè)在 Kubernetes 里做 Ingress Controller常見的 nginx-ingress 或 Envoy 都比較合適需要動態(tài)路由和灰度發(fā)布Envoy 這類云原生網(wǎng)關更應景。我這幾年線上項目基本都跑 Nginx只有在一臺機器上要對大量 TCP 端口做負載均衡時才考慮 HAProxy。Nginx 的最大優(yōu)勢是“中庸且全面”大部分場景一個它就能全包。4. 親手搭一套安裝、配置與實操細節(jié)4.1 安裝 Nginx從包管理到 Docker 到源碼不同的部署環(huán)境安裝方式不一樣。我這里列三種最常用的。包管理器安裝是最快的# Debian / Ubuntu apt update apt install -y nginx # CentOS / RedHat / Rocky yum install -y nginx # 或者 dnf install -y nginx包管理器安裝的好處是省事版本隨系統(tǒng)源走能用 systemd 管理。缺點是版本通常偏舊可能缺少新特性比如 HTTP/3 模塊。如果是內(nèi)網(wǎng)環(huán)境沒有外網(wǎng)訪問就需要離線安裝。思路是找一臺同系統(tǒng)版本的機器可以聯(lián)網(wǎng)裝好 Nginx 和依賴用 rpm 或 deb 包導出再拷貝。CentOS 下# 能聯(lián)網(wǎng)的機器上 mkdir nginx-packages yum install --downloadonly --downloaddirnginx-packages nginx然后把整個目錄拷到內(nèi)網(wǎng)機器rpm -ivh nginx-packages/*.rpm即可。這里容易踩依賴坑Nginx 依賴的 pcre、openssl、zlib 可能也被裝到下載目錄里了拷過去一起裝通常沒問題。離線安裝前最好先確認系統(tǒng)版本完全一致我遇到過開發(fā)機是 CentOS 7.9、生產(chǎn)機是 Rocky 9rpm 包互相不兼容白折騰一小時。Docker 方式適合容器化部署docker pull nginx:stable docker run -d --name my-nginx \ -p 80:80 -p 443:443 \ -v /data/www:/usr/share/nginx/html \ -v /data/nginx/conf/nginx.conf:/etc/nginx/nginx.conf:ro \ nginx:stableDocker 鏡像的好處是環(huán)境隔離升級和回滾都方便。但要注意容器里的 Nginx 配置文件是短路徑和宿主機不一定完全對應日志最好也掛載出來不然docker logs看起來費勁。另外如果想用 QUIC/HTTP/3得先確認鏡像里的 Nginx 是否帶http_v3_module。源碼編譯安裝是自由度最高的方式也是平滑升級的前提wget https://nginx.org/download/nginx-1.26.2.tar.gz tar xzf nginx-1.26.2.tar.gz cd nginx-1.26.2 ./configure \ --prefix/usr/local/nginx \ --with-http_ssl_module \ --with-http_v2_module \ --with-http_v3_module \ --with-stream \ --with-stream_ssl_module make make install--prefix決定安裝路徑后續(xù)升級、回滾都要依賴這個路徑一定要記住。--with-http_ssl_module是 HTTPS 必需的--with-stream是四層 TCP/UDP 轉發(fā)用的--with-http_v3_module是為了 HTTP/3。裝完之后先驗證版本nginx -v nginx -Vnginx -V會輸出完整的編譯參數(shù)這個信息在升級時必須保留后面講平滑升級時會用到。4.2 配置文件結構與關鍵參數(shù)Nginx 主配置文件默認在/etc/nginx/nginx.conf源碼安裝則在--prefix下的conf/nginx.conf。核心結構如下user nginx; worker_processes auto; worker_rlimit_nofile 65535; events { worker_connections 4096; } http { include /etc/nginx/mime.types; include /etc/nginx/conf.d/*.conf; sendfile on; keepalive_timeout 65; server { listen 80; server_name localhost; } }幾個關鍵參數(shù)worker_processes auto通常設置為 CPU 核數(shù)Nginx 每個 worker 進程可以充分利用一個核。設多了反而引起上下文切換開銷。worker_connections 4096每個 worker 進程最多同時處理的連接數(shù)。最大并發(fā)連接數(shù)約等于worker_processes * worker_connections。如果這個值太小高并發(fā)時日志里會出現(xiàn) worker_connections are not enough。worker_rlimit_nofile單個進程可以打開的最大文件數(shù)。因為每一條 TCP 連接都對應一個文件描述符這個值太小并發(fā)一高就報 too many open files。include把主配置拆分成多個子配置文件方便管理。推薦每個站點或每個應用單獨建一個 conf 文件放在/etc/nginx/conf.d/下而不是全部堆在一個文件里。4.3 反向代理 負載均衡完整示例我把兩個功能合在一起給一份可以直接用的完整配置upstream app_backend { least_conn; server 10.0.0.10:8080 max_fails2 fail_timeout30s; server 10.0.0.11:8080 max_fails2 fail_timeout30s; } server { listen 80; server_name app.example.com; access_log /var/log/nginx/app.access.log; error_log /var/log/nginx/app.error.log; location / { proxy_pass http://app_backend; 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; proxy_connect_timeout 5s; proxy_read_timeout 30s; } location /static/ { alias /data/static/; expires 7d; } }這里把/static/請求直接交給 Nginx 讀文件系統(tǒng)其他請求全部負載均衡到后端。alias和root的區(qū)別值得單獨強調root會把 location 的路徑拼接在根目錄后面比如root /data/static; location /static/時請求/static/a.png會找/data/static/static/a.pngalias /data/static/時則找/data/static/a.png。用錯這兩個指令靜態(tài)資源會全部 404這是新手最容易踩的坑之一。proxy_connect_timeout 5s是 Nginx 與后端建立 TCP 連接的超時時間設太短后端偶爾忙一下就會 502。proxy_read_timeout 30s是讀取后端響應的超時時間如果后端有長任務接口比如導出報表要跑一分鐘這里得對應調大。4.4 HTTPS 證書配置實戰(zhàn)這里以已有證書文件為前提不展開怎么申請證書直接說配置server { listen 443 ssl; http2 on; server_name www.example.com; ssl_certificate /etc/nginx/certs/www.example.com.pem; ssl_certificate_key /etc/nginx/certs/www.example.com.key; ssl_session_timeout 1d; ssl_session_cache shared:SSL:10m; # 安全協(xié)議配置 ssl_protocols TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers on; location / { proxy_pass http://backend; proxy_set_header Host $host; proxy_set_header X-Forwarded-Proto $scheme; } }ssl_session_cache shared:SSL:10m是很多團隊容易漏的配置。TLS 握手是乘法運算每次建立新連接都要重新跑一次代價很高。開了 session cache 之后同一臺客戶端一段時間內(nèi)可以復用會話密鑰握手開銷大幅下降。10m 大概能緩存幾萬個 session足夠日常使用。證書到期是一個高頻事故。建議配一個 crontab 定時任務檢查證書有效期0 0 * * * /usr/bin/openssl x509 -enddate -noout -in /etc/nginx/certs/www.example.com.pem每個月跑一次看到快到期就提前換。我見過太多次證書過期導致線上全站報錯起因就是大家都不記得證書是去年哪一天配的。4.5 前端構建產(chǎn)物的部署與“401 驗證身份”配置熱詞里的 “pnpm run build 的包怎么 nginx 啟動”我再展開一下。前端項目構建完得到 dist 目錄部署到服務器/data/wwwNginx 配置server { listen 80; server_name front.example.com; root /data/www; index index.html; location / { try_files $uri $uri/ /index.html; } }前端路由如果是 hash 模式try_files那行其實不加也能跑。但 history 模式必須加否則用戶點擊瀏覽器刷新、或直接訪問二級路由時會 404。有些后臺頁面需要訪問控制Nginx 自帶最簡單的 HTTP Basic Auth配置兩個指令就行l(wèi)ocation /admin/ { alias /data/www/admin/; auth_basic Restricted Area; auth_basic_user_file /etc/nginx/.htpasswd; }然后用工具生成密碼文件htpasswd -c /etc/nginx/.htpasswd admin這個命令會提示輸入密碼生成的文件里存的是用戶名和密碼哈希。之后訪問/admin/就會彈瀏覽器原生認證框輸入賬號密碼才能訪問。熱詞里提到的 “index.php 401 驗證身份” 和這個類似如果后端是 PHP 并且接口返回 401要么是auth_basic導致的安全攔截要么是后端代碼里自己做了登錄校驗。先用curl -I看 401 來自哪個響應頭如果響應頭里有WWW-Authenticate: Basic realm...基本就是 Nginx 的auth_basic在攔。5. 平滑升級、版本管理與踩坑記錄5.1 Nginx 平滑升級到底怎么操作為什么要單獨講平滑升級因為很多人直接用包管理yum update nginx版本是升了但線上連接會被切斷運氣不好配置項兼容性還會出問題。尤其熱詞里提到“Nginx 升級到新版本要注意什么”這絕對是運維里一個高風險動作。源碼編譯的 Nginx 平滑升級標準步驟如下第一步查看當前版本和編譯參數(shù)nginx -V把輸出的 configure arguments 完整記錄下來新版本編譯時參數(shù)要和原來一致不然升級完某些模塊就沒了。第二步下載新版源碼用同樣的 prefix 和 configure 參數(shù)編譯wget https://nginx.org/download/nginx-1.26.2.tar.gz tar xzf nginx-1.26.2.tar.gz cd nginx-1.26.2 ./configure \ --prefix/usr/local/nginx \ --with-http_ssl_module \ --with-http_v2_module \ --with-http_v3_module \ --with-stream make注意這里只執(zhí)行make不要執(zhí)行make install否則會直接覆蓋老版本少了回滾機會。第三步備份舊二進制并替換mv /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.old cp objs/nginx /usr/local/nginx/sbin/nginx第四步向舊 master 進程發(fā)送 USR2 信號啟動新 masterkill -USR2 $(cat /usr/local/nginx/logs/nginx.pid)這時新舊 master 會同時存在新 worker 進程已接管配置。再發(fā)送 WINCH 信號給舊 master讓它優(yōu)雅關閉舊 workerkill -WINCH $(cat /usr/local/nginx/logs/nginx.pid.oldbin)升級完成后新版本就用原 pid 文件舊進程信息在nginx.pid.oldbin里。確認一切正常后可以把舊的二進制文件收起來避免誤用。如果新版本有問題想回滾mv /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.new mv /usr/local/nginx/sbin/nginx.old /usr/local/nginx/sbin/nginx kill -USR2 $(cat /usr/local/nginx/logs/nginx.pid.oldbin) kill -QUIT $(cat /usr/local/nginx/logs/nginx.pid)這套流程在熱詞里對應“nginx 平滑升級指南”是線上升級的必修課。核心原則是能熱切換就不要冷重啟能回滾就不要硬著頭皮修。5.2 日常運維reload、stop、日志切割日常管理命令不多但每一條都要記清楚命令作用nginx -t檢查配置語法并顯示測試結果nginx -s reload平滑重載配置不中斷服務nginx -s stop快速停止服務nginx -s quit優(yōu)雅停止處理完當前請求再退出systemctl status nginx查看服務狀態(tài)和最近日志nginx -V查看編譯參數(shù)和版本W(wǎng)indows 下關閉 Nginx 是nginx.exe -s stop或nginx.exe -s quit對應熱詞里的 “cmd 關閉 nginx”。注意 Windows 下 nginx 不推薦二進制的生產(chǎn)部署但本地調試完全沒問題。日志切割也經(jīng)常踩坑。Nginx 默認把日志寫在一個文件里時間一長就是幾十 GB。標準做法是用 logrotate/var/log/nginx/*.log { daily missingok rotate 14 compress delaycompress notifempty create 640 nginx adm sharedscripts postrotate [ -f /var/run/nginx.pid ] kill -USR1 cat /var/run/nginx.pid endscript }關鍵是postrotate里的kill -USR1這個信號會讓 Nginx 重新打開日志文件。如果不發(fā)這個信號你就算把舊日志改名了Nginx 還在往舊文件里寫等于沒切割。5.3 上線前我必做的“三查”配置上線前我給自己定了一個固定流程到今天還在用第一查nginx -t。這步不用多說語法錯誤必須在這層攔掉。但我見過有人配完忘了跑直接 reload結果 reload 失敗線上老配置還在跑新配置根本沒生效排查半天。第二查檢查權限和端口。Nginx 報Permission denied時多半是靜態(tài)文件目錄沒有讀權限或者 SELinux 沒放行。檢查端口占用ss -lntp | grep :80如果端口被其他進程占了Nginx 會報bind() to 0.0.0.0:80 failed。第三查做一次真實請求驗證。用 curl 測curl -I http://127.0.0.1:80 curl -I -k https://127.0.0.1:443加上-I只看響應頭能快速判斷 HTTP 狀態(tài)碼是不是預期。如果 502去看 Nginx error.log 和后端服務狀態(tài)如果 403去看目錄權限和 index 文件如果 404先確認 root/alias 路徑對不對。6. 常見問題與排查技巧6.1 Nginx 狀態(tài)碼速查表排查問題時狀態(tài)碼是第一手信號。我把最常見的整理成一張表狀態(tài)碼含義常見原因301永久重定向http 跳 https 配置302臨時重定向登錄跳轉、鑒權跳轉304未修改命中本地緩存Nginx 返回 not modified400請求錯誤請求頭格式異常、參數(shù)非法401未認證auth_basic 或后端登錄校驗失敗403禁止訪問目錄權限不足、無 index 文件、IP 被封404未找到root/alias 路徑錯誤、SPA try_files 缺失405方法不允許靜態(tài)文件上 POST 請求未處理413請求體過大client_max_body_size 設置過小429請求過多l(xiāng)imit_req 限流觸發(fā)500服務器內(nèi)部錯誤后端應用異常502網(wǎng)關錯誤后端服務未啟動、端口不通、超時503服務不可用后端無可用節(jié)點、正在維護504網(wǎng)關超時后端處理超時proxy_read_timeout 太小6.2 高頻故障排查實錄502 Bad Gateway 是最常見的故障。排查順序systemctl status nginx確認 Nginx 本身活著。檢查后端服務是否啟動ss -lntp | grep 8080。在后端機器上直接curl http://127.0.0.1:8080/health確認后端本身能不能訪問。如果后端正常但 Nginx 還是 502看 Nginx error.logtail -f /var/log/nginx/error.log常見報錯是connect() failed (111: Connection refused)或connect() failed (110: Connection timed out)。前者說明端口沒開或者 IP 不通后者說明防火墻或網(wǎng)絡策略攔了。504 是另一個高發(fā)問題。典型場景是后端接口本身要跑很久比如導出大量數(shù)據(jù)Nginx 默認proxy_read_timeout 60s后端 60 秒內(nèi)沒返回Nginx 就主動斷開返回 504。解決辦法是給長任務接口單獨配一個 location調大超時時間location /api/export/ { proxy_pass http://backend; proxy_read_timeout 300s; }403 往往不是權限問題就是索引問題。我遇到最多次的是兩種一是 root 目錄下的文件權限不是 nginx 用戶可讀二是autoindex off且目錄下沒有 index.html。先ls -l看權限再確認目錄下有沒有 index 文件。另外 CentOS 系統(tǒng)還要注意 SELinuxgetenforce一下如果是 Enforcing試試setsebool -P httpd_can_network_connect 1放行。404 分清是 Nginx 的還是后端的。如果請求打到后端接口返回 404那是后端路由問題如果是 Nginx 直接返回 404 的頁面多半是 root 或 alias 配錯。判斷方法是看錯誤日志tail -f /var/log/nginx/error.log日志里會寫清楚 “open() “/data/www/xxx” failed (2: No such file or directory)”告訴你 Nginx 實際在找哪個文件對照一下就明白了。413 Request Entity Too Large是老生常談。上傳文件時報這個錯就是client_max_body_size沒配或太小client_max_body_size 20m;放在http、server或location塊里都行l(wèi)ocation里的優(yōu)先級最高。6.3 我踩過的一些坑先說一個關于if的大坑。Nginx 的if指令被官方稱為 “evil”因為它在location里和proxy_pass同時出現(xiàn)時行為很容易不符合直覺。不是不能用而是只用它做改路徑或 return不要在里面寫復雜邏輯。有一次我在if里設置變量再proxy_pass結果每次 reload 都報錯最后改成用map做變量映射才解決。再說 reload 不是“不會斷”。nginx -s reload理論上不會中斷現(xiàn)有連接但如果你的配置里改動了 upstream 地址正在處理的長連接會被切掉。所以我建議不要在業(yè)務高峰期做這種改動盡量安排在凌晨低峰期。還有一個大家都容易忽略的點改了配置一定要先nginx -t再 reload。這個習慣我強調過無數(shù)次但每個月依然能遇到?jīng)]跑測試直接 reload 導致線上配置狀態(tài)混亂的情況。反正就一條命令多敲一下不虧。最后是日志。排查問題第一件事永遠是看日志很多人習慣先猜。Nginx 的 access_log 和 error_log 分開看error.log記錄錯誤比如連接失敗、權限不足、配置文件報錯。access.log記錄每次請求狀態(tài)碼、耗時、來源 IP 都在里面。分析慢請求時在 Nginx 配置里加上$request_time字段就能從 access log 里看出哪些接口響應慢log_format main $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for rt$request_time urt$upstream_response_time;這里$request_time是 Nginx 處理請求的總時間$upstream_response_time是后端響應時間。兩者差值大說明瓶頸在 Nginx 到后端這一段或網(wǎng)絡兩者都大基本就是后端接口本身慢。7. 最后分享一點個人心得Nginx 這個工具文檔寫得很全配置語法也不算難真正的難度在于你對自己系統(tǒng)的請求鏈路有沒有想清楚。我在生產(chǎn)環(huán)境折騰 Nginx 這幾年最大的體會是配置之前先畫清楚“用戶請求從哪進來、經(jīng)過哪些層、最后到哪臺機器哪個接口”再動手寫配置文件基本不會出大錯。每次上線前我會強制自己做三件事備份當前配置、執(zhí)行nginx -t、把 access log 打開看兩分鐘真實請求。這套流程看起來土但比任何花哨的監(jiān)控面板都好使。另外雖然我前面講了不少進階功能但如果不是業(yè)務需要不要為了炫技硬加功能。配置每多一層故障面就大一分保持“夠用且可維護”才是最好的狀態(tài)。如果后面有機會我打算再單獨寫一篇關于 Nginx 與 keepalived 高可用、以及 HTTP/3 QUIC 實戰(zhàn)部署的內(nèi)容。你們在配置 Nginx 時遇到過最詭異的問題是什么歡迎留言交流說不定下一篇文章就是專門為你排坑寫的。