做了這么多年后端和運維我越來越覺得Nginx就是一套行走的架構(gòu)課。不管是剛?cè)腴T的新人還是帶過線上集群的老手最終都會繞回同一件事把 Nginx 的核心功能吃透。它不只是“一個 Web 服務(wù)器”更是靜態(tài)資源托管、反向代理、負(fù)載均衡、網(wǎng)關(guān)限流、HTTPS 接入的樞紐。這篇文章不打算照著官方文檔念一遍我會從實際場景出發(fā)把 Nginx 真正值錢的核心功能拆開講清楚包括每一段配置背后的原理以及我踩過的坑。如果你是剛準(zhǔn)備用 Nginx 的讀者或者已經(jīng)在生產(chǎn)環(huán)境維護它但有些概念還模糊這篇都可以當(dāng)作一份能直接落地的參考。1. 先搞清楚 Nginx 到底解決了什么問題1.1 高并發(fā)能力來自哪里事件驅(qū)動模型Nginx 之所以能扛住高并發(fā)根源在于它的進程模型和事件處理機制。傳統(tǒng)服務(wù)器比如 Apache 的 prefork 模式每個連接通常對應(yīng)一個進程或線程并發(fā)一高內(nèi)存和上下文切換開銷立刻爆炸。Nginx 采用 master 進程加多個 worker 進程的結(jié)構(gòu)每個 worker 內(nèi)部用事件驅(qū)動方式同時處理成千上萬個連接誰有數(shù)據(jù)來了就處理誰沒事件就閑著并不需要為每個連接單獨開線程。你可以把它想象成一個餐廳服務(wù)員Apache 像一個客人配一個專人服務(wù)員客人多了就得雇一堆人Nginx 則是一個服務(wù)員同時照看許多桌哪桌舉手就過去沒舉手的不用管。這種模型下單個 worker 進程能承擔(dān)的并發(fā)連接數(shù)遠高于線程模型機器配置不變吞吐量卻上了一個量級。實際部署時worker 進程數(shù)一般設(shè)為 CPU 核心數(shù)或稍多一些。我習(xí)慣用auto讓 Nginx 自己探測然后通過worker_cpu_affinity把進程綁定到物理核上能減少進程切換帶來的損耗。這些細節(jié)看著不起眼但在 4 核以下的小機器上差異很明顯。在壓測場景里同配置的機器用 Nginx 做靜態(tài)文件服務(wù)QPS 經(jīng)常是其他方案的好幾倍靠的正是這個底子。1.2 與 Apache、Tomcat 的分工差異很多剛接觸的人會問Nginx 能代替 Tomcat 嗎答案是不能它們壓根不在一個層面。Nginx 擅長處理靜態(tài)請求、轉(zhuǎn)發(fā)、負(fù)載均衡而 Tomcat 是 Java Servlet 容器本質(zhì)上是把動態(tài)業(yè)務(wù)跑起來的應(yīng)用服務(wù)器。常見的組合是 Nginx 在最前面接流量靜態(tài)資源自己直接吐給客戶端動態(tài)請求用proxy_pass轉(zhuǎn)發(fā)給后端的 Tomcat再由 Tomcat 返回結(jié)果。Nginx 與 Apache 相比內(nèi)存占用更低、并發(fā)能力強、配置更靈活而且 Nginx 的異步非阻塞模型在長連接、反向代理場景優(yōu)勢更明顯。Apache 的.htaccess目錄級配置雖然方便但每次請求都要檢查目錄規(guī)則性能代價不小Nginx 不支持.htaccess所有配置集中管理反而更利于規(guī)范團隊配置和維護?，F(xiàn)在很多新項目直接跳過 Apache 選 Nginx我并不意外。1.3 一張圖看清 Nginx 的六個核心功能在深入配置之前先把 Nginx 的能力邊界畫清楚。它不只是處理 HTTP 請求還可以靜態(tài)資源服務(wù)直接返回 HTML、CSS、JS、圖片等文件支持autoindex目錄列表。反向代理接收客戶端請求轉(zhuǎn)發(fā)給后端應(yīng)用服務(wù)器并把響應(yīng)返回給客戶端。負(fù)載均衡在多個上游服務(wù)器之間按策略分發(fā)請求提高整體吞吐和可用性。HTTP 層高級處理URL 重寫、重定向、跨域、緩存、壓縮、限流。SSL/TLS 終結(jié)統(tǒng)一處理 HTTPS 證書解密后的明文請求再轉(zhuǎn)發(fā)給后端后端不用各自處理證書。四層負(fù)載均衡Stream不只看 HTTP 協(xié)議還能直接代理 TCP/UDP 流量。后面幾個部分我會圍繞這些能力展開每個場景都會給出可直接套用的配置和取舍理由。2. 靜態(tài)資源服務(wù)與目錄瀏覽初始配置里的大學(xué)問2.1 root 和 alias 的經(jīng)典區(qū)別配置靜態(tài)站點時root和alias是最容易用錯的一組指令。root會完整拼接 URL 路徑和 root 指定的目錄而alias則是把 URL 中的匹配部分直接替換成指定路徑。看兩個例子server { listen 80; server_name example.com; # 訪問 /static/logo.png 時實際查找文件/data/public/static/logo.png location /static/ { root /data/public; } # 訪問 /img/logo.png 時實際查找文件/data/icons/logo.png location /img/ { alias /data/icons/; } }我遇到過一個項目開發(fā)人員把alias寫成了root導(dǎo)致圖片路徑里多了一層目錄頁面上的資源全部 404。排查方法也很簡單打開 Nginx 的 error.log看到open() /xxx/xxx/static/static/logo.png failed這種路徑重復(fù)拼接的報錯基本就是root和alias用混了。結(jié)論很簡單location是前綴匹配、且希望文件目錄和 URL 路徑不一致時用alias大多數(shù)整站靜態(tài)托管場景直接用root語義更好理解。2.2 autoindex 在文件分享場景的正確姿勢Nginx 自帶目錄列表功能autoindex on打開后訪問目錄 URL 時會生成一個簡單的文件索引頁面。很多團隊拿它當(dāng)臨時文件分享工具用比起搭建專門的網(wǎng)盤系統(tǒng)輕量且零成本。我的常用配置是這樣location /files/ { alias /data/share_files/; autoindex on; autoindex_exact_size off; # 文件大小顯示為可讀格式K、M、G autoindex_localtime on; # 顯示服務(wù)器本地時間方便跨時區(qū)同事判斷 charset utf-8; # 中文文件名不亂碼 add_header Cache-Control no-cache; }有幾個坑需要提醒第一autoindex只對以/結(jié)尾的目錄請求生效直接訪問目錄不帶斜杠會 301 跳轉(zhuǎn)由 Nginx 自動完成但如果你自定義了return規(guī)則可能把這個隱式跳轉(zhuǎn)覆蓋掉第二中文文件名必須配charset utf-8否則瀏覽器里看到的是一堆亂碼第三文件分享目錄不要放在 Web 根目錄之外還需要特殊權(quán)限的地方盡量統(tǒng)一權(quán)限管理避免權(quán)限錯亂引起的 403。不過autoindex的頁面樣式比較樸素功能也有限沒有搜索和上傳能力。如果是團隊正式使用的共享盤還是建議用專門的工具處理。但“快速臨時共享一個包”這種需求Nginx 的 autoindex 完全夠用。2.3 動靜分離到底怎么設(shè)計動態(tài)請求和靜態(tài)資源的處理路徑不同性能表現(xiàn)差異很大。動靜分離的核心思路是靜態(tài)資源直接由 Nginx 讀取磁盤或內(nèi)存緩存返回動態(tài)請求才轉(zhuǎn)發(fā)給應(yīng)用服務(wù)器。這樣既能緩解后端壓力又能利用 Nginx 的高并發(fā)能力加速靜態(tài)資源訪問。我的典型配置長這樣server { listen 80; server_name www.example.com; # 靜態(tài)資源直接返回并帶上傳過期時間 location ~* \.(html|css|js|png|jpg|jpeg|gif|ico|svg|webp|woff2?)$ { root /data/www; expires 30d; access_log off; add_header Cache-Control public, max-age2592000; } # 動態(tài)請求反代給后端 location / { proxy_pass http://backend_server; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }這里有一個值得說的細節(jié)靜態(tài)資源的expires緩存時間不是越長越好如果項目發(fā)布頻繁而文件名不帶 hash瀏覽器強緩存了舊資源用戶就會看到舊頁面。常見的做法是文件名帶上版本號或內(nèi)容 hash例如app.20250101.js這種情況下可以把緩存時間設(shè)得長一些。如果文件名固定不變緩存建議控制在 5 到 10 分鐘避免上線后需要用戶手動強刷。3. 反向代理與負(fù)載均衡日常使用率最高的功能3.1 proxy_pass 的路徑拼接規(guī)則反向代理是 Nginx 日常存在感最強的功能但也是配置歧義最多的地方。proxy_pass后面的 URI 寫不寫結(jié)果完全不同。規(guī)則只有一條proxy_pass不帶 URI路徑Nginx 會將完整請求 URI 原樣傳給后端帶 URI匹配location的部分會被替換。舉兩個例子# 場景一不帶 URI訪問 /api/user 轉(zhuǎn)發(fā)到后端同樣是 /api/user location /api/ { proxy_pass http://192.168.1.10:8080; } # 場景二帶 URI訪問 /api/user 會轉(zhuǎn)發(fā)到 http://192.168.1.10:8080/user location /api/ { proxy_pass http://192.168.1.10:8080/; }場景二里proxy_pass的結(jié)尾有一個/整條路徑被替換成后端根路徑。因為后端服務(wù)通常沒有/api這個前綴需要把前綴剝掉所以很多人會這么用。但如果你理解錯了這個規(guī)則把該帶/的地方漏掉后端接口全部 404不該帶的時候加了/路由又對不上。排查這類問題最快的辦法是看后端的 access log確認(rèn)實際收到的 URI 是什么。還需要注意的是location的匹配方式會影響替換行為。location /api/ {}是前綴匹配proxy_pass帶 URI 時匹配到的那一截會被替換。如果用了正則形式的location ~ ^/api/(.*)$想保留部分路徑就需要用$1手工拼接麻煩得多。能用前綴匹配解決的問題不要輕易上正則。3.2 負(fù)載均衡策略與權(quán)重分配Nginx 的 upstream 模塊提供了多種負(fù)載均衡算法默認(rèn)是輪詢。下面是我常寫的一個后端集群配置upstream backend_servers { server 192.168.1.11:8080 weight3; server 192.168.1.12:8080 weight2; server 192.168.1.13:8080 backup; keepalive 32; } server { listen 80; server_name api.example.com; location / { proxy_pass http://backend_servers; proxy_http_version 1.1; proxy_set_header Connection ; } }這個配置里第一臺和第二臺按 3:2 的比例接收請求第三臺作為備份機平時不接流量前兩臺掛了才頂上。backup的語義在做容災(zāi)時很有用它不會參與正常負(fù)載但能兜底。關(guān)于不同策略的使用場景我整理了一張表策略指令適用場景注意事項輪詢默認(rèn)后端無狀態(tài)、配置相近請求平均分配不考慮機器性能差異加權(quán)輪詢weight機器配置不同權(quán)重按處理能力設(shè)置別憑感覺IP 哈希ip_hash;需要會話保持的舊系統(tǒng)同一 IP 固定到同一后端但可能分布不均最少連接least_conn;請求耗時不穩(wěn)定的場景把新請求交給當(dāng)前連接數(shù)最少的后端一致性哈希hash $request_uri;緩存類、粘性路由通過consistent參數(shù)減少節(jié)點變化影響如果后端有登錄態(tài)且依賴 Session 而不用分布式會話ip_hash或hash能避免用戶頻繁掉線。但線上系統(tǒng)盡量還是把會話集中到 Redis讓負(fù)載均衡算法保持簡單后續(xù)擴縮容才靈活。3.3 開啟 keepalive 的收益與必須注意的坑upstream里那段keepalive 32很多人不理解容易漏配。它表示 Nginx 和后端之間保持 32 個空閑的長連接反復(fù)復(fù)用而不是每次請求都重新建立 TCP 連接。HTTP 短連接每次都要經(jīng)歷 TCP 三次握手高并發(fā)下時間開銷和資源開銷都不小。但要真正生效還需要兩個配套條件proxy_http_version 1.1和proxy_set_header Connection 。因為 HTTP/1.0 默認(rèn)不支持 keepalive而 Nginx 向后端發(fā)請求默認(rèn)用的是 HTTP/1.0。如果不設(shè)置這兩行keepalive配置就是空中樓閣連接根本復(fù)用了。代價是每個 worker 進程會占住一定數(shù)量的空閑連接keepalive數(shù)值不宜過大。后端是 Tomcat 這類 Java 應(yīng)用時連接數(shù)本身受容器線程池限制keepalive設(shè)得太高會讓后端連接堆積建議控制在 16 到 64 之間。這些參數(shù)我在壓力測試環(huán)境下對比過業(yè)務(wù)高峰期的 P99 延遲可以下降 20% 左右值得重視。4. 性能調(diào)優(yōu)讓 Nginx 在最省資源的情況下跑得更快4.1 worker 進程、連接數(shù)和文件描述符的關(guān)系很多人以為worker_processes越大越好其實不是。每個 worker 都是獨立進程進程多了上下文切換和內(nèi)存占用都會上升。常規(guī)建議是設(shè)為 CPU 核心數(shù)例如worker_processes autoNginx 會自動探測。如果服務(wù)器還承擔(dān)其他業(yè)務(wù)可以適當(dāng)減少不要讓 Nginx 獨占所有核。worker_connections決定單個 worker 能同時打開的最大連接數(shù)這個值受系統(tǒng)最大文件描述符限制。Linux 默認(rèn)單進程能打開的文件數(shù)通常是 1024如果不調(diào)Nginx 的并發(fā)能力會被死死卡住。需要同時調(diào)整幾個地方Nginx 配置里設(shè)置worker_rlimit_nofile 65535;修改/etc/security/limits.conf中的nofile使用 systemd 管理時還要檢查服務(wù)的LimitNOFILE理論上最大并發(fā)連接數(shù)約等于worker_processes * worker_connections但實際受內(nèi)存、帶寬、后端處理能力制約。這些參數(shù)沒有萬能配置需要結(jié)合壓測調(diào)整。4.2 gzip、緩存和 HTTP/2 能帶來的真實提升Nginx 開啟 gzip 壓縮對文本類資源效果非常顯著JS、CSS、HTML 這類文件體積能壓縮到原來的三分之一。我常用的壓縮配置gzip on; gzip_comp_level 5; # 1-9越高越耗 CPU gzip_min_length 1k; # 小于 1KB 的文件不壓縮壓了反而更大 gzip_types text/plain text/css application/javascript application/json application/xml image/svgxml; gzip_vary on;有幾個細節(jié)不能漏第一圖片和視頻不要開 gzip它們本身已經(jīng)壓縮過再壓浪費時間第二gzip_comp_level不是越高越好超過 6 以后 CPU 開銷上升明顯而體積下降有限第三如果前面還有一層 CDN需要在 CDN 上同步開啟 gzip 相關(guān)配置否則可能返回雙重編碼的亂碼。HTTP/2 開啟很簡單一行l(wèi)isten 443 ssl http2;它能通過多路復(fù)用避免瀏覽器對同域名的并發(fā)連接限制靜態(tài)資源加載速度會有明顯改善。開啟后可以直接用 Chrome 的開發(fā)者工具查看加載瀑布圖原本排隊等待的連接會變成并行傳輸。4.3 高并發(fā)下的基本攻擊防護與限流Nginx 本身可以作為第一層安全屏障。限制請求速率是保護后端應(yīng)用的重要手段# 定義限流區(qū)域每個 IP 每秒 5 個請求突發(fā)允許 10 個 limit_req_zone $binary_remote_addr zoneapi_limit:10m rate5r/s; server { location /api/ { limit_req zoneapi_limit burst10 nodelay; proxy_pass http://backend_servers; } }burst10允許短時突發(fā)超過速率限制nodelay表示突發(fā)請求不排隊直接放行但如果連突發(fā)量也超過Nginx 會直接返回 503。個人經(jīng)驗是限流值不能拍腦袋定需要結(jié)合壓測和后端實際處理能力。限得太緊正常用戶的請求被誤傷限得太松又起不到保護作用。除了限流還可以在 http 塊層面限制請求體大小、設(shè)置超時時間降低惡意請求對后端的壓力。5. HTTPS 接入與安全加固實踐5.1 證書配置與 HTTP 強制跳轉(zhuǎn)HTTPS 是現(xiàn)在線上服務(wù)的底線沒有證書的網(wǎng)站基本見不了人。Nginx 接入 SSL 的配置很成熟server { listen 443 ssl; server_name www.example.com; ssl_certificate /etc/nginx/ssl/example.com.pem; ssl_certificate_key /etc/nginx/ssl/example.com.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; } # HTTP 全部跳轉(zhuǎn)到 HTTPS server { listen 80; server_name www.example.com; return 301 https://$host$request_uri; }這里有一個常見坑某些安全掃描工具會報 SSL 證書鏈不完整問題往往出在只配置了域名證書而沒配置中間證書。正確的做法是把中間證書和域名證書合并在一個.pem文件里順序是域名證書在前、中間證書在后。另外HTTP 跳轉(zhuǎn)用301還是308有些講究。301會把 POST 請求改成 GET可能造成接口調(diào)用異常如果業(yè)務(wù)中存在表單提交且需要保留請求方法應(yīng)使用308 Permanent Redirect。我一般看業(yè)務(wù)性質(zhì)純前端展示站用301沒問題涉及接口回調(diào)用308更穩(wěn)。5.2 隱藏版本號與基礎(chǔ)安全響應(yīng)頭Nginx 默認(rèn)會在錯誤頁面和響應(yīng)頭里暴露版本號例如Server: nginx/1.24.0。攻擊者拿到精確版本后可以直接匹配已知漏洞進行定向攻擊。隱藏版本號很簡單server_tokens off;除了隱藏版本號我建議在 server 塊統(tǒng)一加上幾個安全響應(yīng)頭add_header X-Content-Type-Options nosniff always; add_header X-Frame-Options SAMEORIGIN always; add_header Referrer-Policy strict-origin-when-cross-origin always;X-Frame-Options可以防止頁面被惡意網(wǎng)站用 iframe 嵌套降低點擊劫持風(fēng)險。add_header指令有個繼承坑需要注意如果在某個location里重新定義了add_header它會覆蓋整個 server 塊里定義的所有add_header而不會合并。所以要么把安全頭集中在每個需要的 location 里要么確認(rèn) location 中沒有單獨設(shè)置add_header。5.3 常見漏洞的防護思路最近幾年 Nginx 相關(guān)的漏洞通報不少比如某些版本存在請求走私風(fēng)險、越界讀取漏洞等修復(fù)方式通常聚焦在兩點升級版本和調(diào)整配置。如果你用的是發(fā)行版自帶源里的 Nginx建議關(guān)注官方倉庫的安全公告如果是編譯安裝的版本更要留意版本號是否過舊。還有一個經(jīng)常被忽視的點Nginx 后面的業(yè)務(wù)接口如果沒有做權(quán)限校驗任何人都可以直接訪問內(nèi)網(wǎng)接口。代理層能做的是用allow和deny控制來源 IPlocation /admin/ { allow 10.0.0.0/8; allow 192.168.1.0/24; deny all; proxy_pass http://backend_servers; }這種基于來源 IP 的訪問控制不能替代業(yè)務(wù)鑒權(quán)但它能把管理后臺的暴露面縮小到可信網(wǎng)段安全性高一個層次。6. Rewrite 重寫、多站點與四層代理6.1 Rewrite 的常見使用場景URL 重寫是遷移網(wǎng)站、整理鏈接結(jié)構(gòu)時的高頻需求。rewrite指令放在server塊和location塊里的行為不同放在server塊會在進入location匹配前執(zhí)行放在location塊則在該塊內(nèi)部匹配后執(zhí)行。例如舊接口路徑遷移server { listen 80; server_name old.example.com; rewrite ^/api/(.*)$ http://new.example.com/api/$1 permanent; }這里用permanent返回 301對搜索引擎友好會把舊鏈接的權(quán)重傳導(dǎo)到新鏈接。如果是臨時遷移則用redirect返回 302。但我不建議在 Nginx 層做太復(fù)雜的重寫邏輯。重寫規(guī)則一多可讀性和可維護性都會直線下降。能用應(yīng)用層完成的跳轉(zhuǎn)盡量交給應(yīng)用Nginx 只負(fù)責(zé)那些非做不可的路徑規(guī)則、協(xié)議跳轉(zhuǎn)和泛域名支持。6.2 一個服務(wù)器部署多個網(wǎng)站利用server_name區(qū)分域名Nginx 可以在同一臺服務(wù)器、同一個 80/443 端口上托管多個站點。下面是一個典型的多站點結(jié)構(gòu)server { listen 80; server_name a.example.com; root /data/www/a; } server { listen 80; server_name b.example.com; root /data/www/b; }如果還想要c.example.com等任意子域名都指向同一個入口可以用通配符server { listen 80; server_name ~^(?sub.)\.example\.com$; root /data/www/$sub; }這種配置很適合快速搭建多租戶演示環(huán)境。需要注意通配符server_name的正則支持有限并且多個 server 塊匹配時Nginx 會優(yōu)先選擇精確匹配、再選擇通配符和正則。生產(chǎn)環(huán)境如果站點規(guī)模大建議把每個站點的server塊拆成獨立配置文件放在/etc/nginx/conf.d/下并統(tǒng)一加前綴區(qū)分比全部堆在主配置里好維護得多。6.3 基于 Stream 的 TCP/UDP 四層代理Nginx 不只是七層代理它的stream模塊可以直接代理 TCP 和 UDP 流量。比如把 MySQL 3306 或 Redis 6379 端口轉(zhuǎn)發(fā)到后端或者做數(shù)據(jù)庫連接的負(fù)載均衡。stream { upstream mysql_backends { server 192.168.1.21:3306; server 192.168.1.22:3306; } server { listen 3306; proxy_pass mysql_backends; proxy_timeout 60s; } }使用stream時要注意它和http模塊是平級的不能寫在http塊里面。常見的錯誤是把stream配置塞到http塊然后 Nginx 直接報錯無法啟動。不過四層代理只做流量轉(zhuǎn)發(fā)看不到 HTTP 層的信息沒法做基于域名的路由或請求頭修改。如果業(yè)務(wù)需要精細控制還是得用七層反向代理。四層代理更適合底層數(shù)據(jù)庫、消息隊列等組件的流量分發(fā)。7. 日常運維與高頻排障7.1 編譯安裝還是包管理器安裝新手最容易糾結(jié)的問題用包管理器裝還是源碼編譯裝。我的建議是能用系統(tǒng)源安裝就用系統(tǒng)源發(fā)行版會持續(xù)推送安全更新省心。但如果你需要特定模塊例如第三方模塊或新版特性系統(tǒng)源版本不夠新就要考慮編譯安裝。編譯安裝的完整流程不算復(fù)雜但有一個容易失敗的點依賴庫不完整。常見的報錯是缺pcre、zlib、openssl開發(fā)包所以編譯前先把依賴裝齊yum install -y gcc pcre-devel zlib-devel openssl-devel # 或 apt install -y build-essential libpcre3-dev zlib1g-dev libssl-dev然后下載源碼并編譯記得帶上需要的模塊。--prefix指定安裝目錄--with-http_ssl_module開啟 SSL 核心模塊。如果一開始忘了加 SSL 模塊后面再想升級版本時可以直接重新編譯或者用動態(tài)模塊加載方式補上。7.2 平滑升級與優(yōu)雅重啟Nginx 最被人稱道的一點就是可以在不中斷服務(wù)的情況下完成升級或配置重載。修改配置文件后執(zhí)行nginx -t # 先檢查配置語法 nginx -s reload # 平滑重載reload的過程是 master 進程重新讀取配置并啟動新的 worker處理完當(dāng)前請求的舊 worker 會逐漸退出不會出現(xiàn)連接中斷。升級二進制文件時也能做到平滑整體思路是把新二進制文件替換后發(fā)送USR2信號讓 master 啟動新進程再逐步退出舊進程。不過這個過程細節(jié)較多我建議在測試環(huán)境先演練一遍不要直接在生產(chǎn)上臨場操作。日常排查時最常用的命令就這么幾條nginx -t # 語法檢查 nginx -s stop / quit # 立即停止 / 優(yōu)雅停止 nginx -V # 查看編譯參數(shù)和模塊信息 ps -ef | grep nginx # 查看 master 和 worker 進程7.3 高頻報錯的經(jīng)驗速查表把我在群里和工作中遇到最多的 Nginx 報錯整理成一張表覆蓋原因和方向排查時對照著來效率很高報錯或現(xiàn)象常見原因排查方向403 Forbidden目錄權(quán)限不足或索引文件不存在檢查root目錄權(quán)限、index指令配置404 Not Found 但文件存在root/alias 路徑拼接錯誤查看 error.log 中實際 open 的路徑502 Bad Gateway后端服務(wù)未啟動或防火墻攔截檢查后端端口連通性504 Gateway Timeout后端處理太慢超過 proxy_read_timeout調(diào)大proxy_read_timeout或優(yōu)化后端worker_connections are not enough連接數(shù)超過配置調(diào)大worker_connections和系統(tǒng)文件描述符upstream prematurely closed connection后端主動斷開連接檢查后端日志排查超時或線程池滿[emerg] bind() to 0.0.0.0:80 failed端口被占用檢查是否有其他進程占用端口to upstream ... while reading response header后端響應(yīng)頭超時結(jié)合upstream日志定位慢業(yè)務(wù)出現(xiàn) 502 時我的排查順序是先確認(rèn)后端端口通不通再確認(rèn) Nginx 能否解析 upstream 域名最后看后端的健康檢查接口是否正常。很多 502 不是 Nginx 的問題而是后端進程沒起來。關(guān)于日志我習(xí)慣在http塊里開啟 access_log 和 error_log并按天切割。定位問題時日志里的request_time、upstream_response_time這兩個字段最有價值前者能看出整體耗時后者能看出后端處理耗時兩者差值就是 Nginx 層自身和網(wǎng)絡(luò)開銷。把日志格式加兩個字段很多問題會變得一眼就能定位。7.4 自動檢查配置和守護進程的小技巧最后分享一個我在多臺服務(wù)器上養(yǎng)成的習(xí)慣每次修改完配置寫一個簡單的檢查腳本流程把nginx -t放在提交之前強制跑一遍。尤其是在多管理員協(xié)作環(huán)境下一個人改了配置忘記檢查reload 時搞掛所有站點的情況并不罕見。還可以用 crontab 寫一個最簡易的健康檢查定時 curl 本機健康檢查接口連續(xù)失敗則觸發(fā)重啟或告警。不要把重啟寫得太激進至少連續(xù)失敗三次以上才動作避免后端偶發(fā)抖動導(dǎo)致 Nginx 被反復(fù)重啟。根據(jù)我個人經(jīng)驗Nginx 的很多問題不是配置不會寫而是對每一行指令背后的語義理解不夠透徹。proxy_pass帶不帶斜杠、add_header的覆蓋規(guī)則、keepalive是否真正生效這些細節(jié)測試環(huán)境里可能看不出來線上流量一大就全部暴露。所以我會建議每個團隊維護一份屬于自己的 Nginx 配置清單和 check-list新同學(xué)入職先過一遍能少踩太多坑。Nginx 的能力邊界遠不止上面這些比如mirror流量鏡像、js模塊做復(fù)雜路由、njs腳本擴展等都是更高階的玩法。但核心功能就這七塊靜態(tài)服務(wù)、反向代理、負(fù)載均衡、性能調(diào)優(yōu)、HTTPS、重寫與多站點、四層代理。把這些搞透線上絕大多數(shù)問題都能應(yīng)對。后續(xù)如果你想深入我會再單獨拆一下 Nginx 的模塊化體系和 Lua 擴展。