背景與問題

Nginx 是高性能 HTTP 服務器和反向代理服務器，默認配置適合低流量場景。當 QPS（每秒請求數(shù)）達到數(shù)千甚至數(shù)萬時，默認配置會成為性能瓶頸。表現(xiàn)為：服務器 CPU 使用率不高但請求開始排隊、響應時間隨并發(fā)增加急劇上升、連接數(shù)達到上限后開始拒絕服務。

本文以 Nginx 1.27.x 版本為基準，系統(tǒng)講解高并發(fā)場景下必須調整的核心參數(shù)，以及每個參數(shù)調整背后的原理。內容包括：工作進程配置、連接管理、緩沖區(qū)優(yōu)化、緩存策略、 upstream 負載均衡調優(yōu)、HTTP 協(xié)議優(yōu)化、以及內核參數(shù)調整。文章覆蓋的參數(shù)都經(jīng)過生產(chǎn)環(huán)境驗證，調整思路按優(yōu)先級排序，讀者可以根據(jù)實際場景按圖索驥。

1. 參數(shù)調整總覽與優(yōu)先級

Nginx 參數(shù)調整有明確的優(yōu)先級順序。錯誤地調整低優(yōu)先級參數(shù)可能無效，而正確地調整高優(yōu)先級參數(shù)能立即見效。優(yōu)先級從高到低：

第一層是操作系統(tǒng)內核參數(shù)，影響 Nginx 能處理的最大連接數(shù)和文件描述符上限。第二層是 Nginx 進程模型配置，即 worker 進程數(shù)和連接處理方式。第三層是每個連接的內存緩沖區(qū)配置。第四層是 upstream 負載均衡和 keepalive 配置。第五層是 HTTP 協(xié)議層面的優(yōu)化，如 gzip、chunked 編碼等。

按這個順序逐層調整，每調整一層后觀察效果，避免盲目修改。

2. 內核參數(shù)調整

2.1 文件描述符上限

Nginx 每個連接需要占用一個文件描述符（FD），同時還需要額外的文件描述符用于打開日志文件、連接 upstream、打開緩存文件等。默認系統(tǒng)限制通常為 1024，遠不夠高并發(fā)使用。

檢查當前限制：

# 查看系統(tǒng)級別的最大文件描述符
cat /proc/sys/fs/file-max

# 查看當前已使用的文件描述符數(shù)量
cat /proc/sys/fs/file-nr

# 查看 nginx 進程允許的最大 FD（soft limit）
cat /proc/$(cat /var/run/nginx.pid)/limits | grep"Max open files"

調整系統(tǒng)級限制：

# 在 /etc/sysctl.conf 中添加
fs.file-max = 1000000

# 使配置生效
sysctl -p

調整用戶級限制（在/etc/security/limits.conf中）：

nginx soft nofile 100000
nginx hard nofile 100000

在 Nginx 配置中設置：

worker_rlimit_nofile 100000;

這個參數(shù)設置了 Nginx worker 進程能打開的最大文件描述符數(shù)量。應設置為與用戶級限制一致。計算公式：理論最大連接數(shù) = worker_rlimit_nofile / 2（因為每個連接需要 1 個 FD，還要留一些給日志、upstream、緩存等）。

2.2 網(wǎng)絡內核參數(shù)

高并發(fā)場景下，網(wǎng)絡積壓隊列和連接復用相關的內核參數(shù)必須調整：

# 在 /etc/sysctl.conf 中添加
# 調整 SOMAXCONN（Socket 監(jiān)聽隊列最大長度）
net.core.somaxconn = 65535

# 調整 tcp 連接隊列大小
net.ipv4.tcp_max_syn_backlog = 65535

# 允許 TIME_WAIT 狀態(tài)的 socket 重用
net.ipv4.tcp_tw_reuse = 1

# 調整 TIME_WAIT 超時時間（毫秒）
net.ipv4.tcp_fin_timeout = 15000

# 調整 TCP keepalive 探測間隔
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 3

# 調整本地端口范圍
net.ipv4.ip_local_port_range = 1024 65535

# 調整 tcp 最大包緩沖大小
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 262144
net.core.wmem_default = 262144
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

使配置生效：sysctl -p

參數(shù)原理解析：

net.core.somaxconn是 listen() 系統(tǒng)調用的 backlog 隊列長度。當 Nginx 調用 listen() 時，內核會將未 accept 的連接放入這個隊列。如果隊列滿了，新連接會被拒絕。Nginx 默認的 backlog 為 511，如果上游處理速度跟不上連接到達速度，這個隊列會很快填滿。

net.ipv4.tcp_max_syn_backlog是 SYN 隊列的長度。當客戶端發(fā)送 SYN 包后，服務器回復 SYN-ACK 但還未收到最后的 ACK 時，連接處于半開狀態(tài)，放在 SYN 隊列中。如果 SYN 隊列滿了，新的 SYN 包會被丟棄，導致連接建立失敗。

net.ipv4.tcp_tw_reuse允許將 TIME_WAIT 狀態(tài)的 socket 重用于新的 outbound 連接。這在 Nginx 作為客戶端連接 upstream 時特別有用，減少本地端口耗盡的問題。

net.ipv4.tcp_fin_timeout縮短 TIME_WAIT 持續(xù)時間。默認 60 秒，在高并發(fā)場景下會占用大量端口資源。

3. Nginx 進程模型配置

3.1 worker 進程數(shù)

Nginx 采用多進程模型：一個 master 進程負責管理，多個 worker 進程處理請求。默認配置只有一個 worker 進程，遠不能利用多核 CPU。

檢查 CPU 核心數(shù)：

nproc
# 或者
grep processor /proc/cpuinfo | wc -l

設置 worker 進程數(shù)：

worker_processes auto;

auto表示 Nginx 自動設置為 CPU 核心數(shù)，這是最推薦的配置。如果設置為具體數(shù)字，必須確保與 CPU 核心數(shù)匹配。worker 進程數(shù)不是越多越好：進程數(shù)過多會增加進程切換開銷，每個進程還要占用獨立內存。

3.2 worker 連接數(shù)上限

每個 worker 進程能處理的連接數(shù)受 worker_connections 限制。這個參數(shù)定義了單個 worker 能同時持有的最大連接數(shù)：

events {
  worker_connections 65535;
  use epoll;
  multi_accept on;
}

use epoll：Linux 下使用 epoll 事件模型，這是最高效的 I/O 多路復用機制。FreeBSD 下使用 kqueue，Windows 下使用 select。

multi_accept on：允許一個 worker 進程同時接受多個新連接。默認 off 意味著一次只 accept 一個連接。如果流量集中到達，未 accept 的連接會排隊等待。

worker_connections 65535是理論上限，實際設置需要結合worker_rlimit_nofile的值。計算方式：worker_connections * worker_processes不能超過worker_rlimit_nofile。

3.3 綁定 worker 到特定 CPU

將 worker 進程綁定到特定 CPU 核心，可以避免進程切換帶來的緩存失效：

worker_cpu_affinity auto;

auto會自動將每個 worker 綁定到不同的 CPU 核心。如果需要手動指定：

worker_cpu_affinity 0001 0010 0100 1000; # 4 worker 對應 4 核心
worker_cpu_affinity 0101 1010;       # 2 worker 對應 4 核心（每進程綁定2個）

手動指定在 NUMA 架構服務器上特別有用，可以控制每個 worker 只訪問本地內存，減少跨 NUMA 節(jié)點的內存訪問延遲。

3.4 調整 worker 優(yōu)先級

如果服務器上還運行著其他重要服務，可以適當降低 Nginx worker 的優(yōu)先級，避免 Nginx 搶光 CPU：

worker_priority -10;

負數(shù)表示更高優(yōu)先級（Linux 中 Nice 值）。默認 0，降低到 -10 可以讓 Nginx 在爭搶時獲得更多 CPU 時間。但如果服務器專門跑 Nginx，不需要調整。

4. 緩沖區(qū)配置

4.1 客戶端連接緩沖區(qū)

客戶端請求的headers和body需要緩沖區(qū)來存儲。緩沖區(qū)太小會導致 nginx 頻繁讀寫磁盤，太大會占用過多內存：

http {
  # client header buffer size
  client_header_buffer_size 4k;
  large_client_header_buffers 4 32k;

  # client body buffer size（上傳文件大小控制）
  client_body_buffer_size 128k;

  # 最大允許的 request body 大?。ㄔ?server/location 中設置）
  client_max_body_size 100m;
}

client_header_buffer_size：存儲請求頭的緩沖區(qū)大小。普通請求的 headers 通常小于 1KB，4KB 足夠。如果存在大量 cookies 或較大的 headers，可以增大。

large_client_header_buffers：如果請求頭太大超出 client_header_buffer_size，會使用這個緩沖區(qū)。第一個數(shù)字是緩沖區(qū)數(shù)量，第二個是每個緩沖區(qū)大小。如果出現(xiàn)大量 400 Bad Request 錯誤且錯誤日志顯示 "request header is too large"，需要增加這個值。

client_body_buffer_size：存儲請求 body 的緩沖區(qū)大小。如果 body 超過這個大小，會寫入臨時文件。默認是磁盤上的 tmpfs（如果配置了client_body_temp_path）。這個值設置得太小會導致頻繁寫磁盤，設置得太大會占用過多內存。

4.2 upstream 緩沖區(qū)

upstream 響應數(shù)據(jù)也需要緩沖區(qū)。啟用緩沖區(qū)可以讓 Nginx 異步處理 upstream 響應，減少阻塞：

upstream backend {
  server 127.0.0.1:8080;
  keepalive 32;
}

proxy_buffer_size 128k;
proxy_buffers 4 128k;
proxy_buffering on;
proxy_busy_buffers_size 256k;

proxy_buffer_size：存儲 upstream 響應的 headers 部分。這個值應該大于 upstream 可能返回的最大 headers 大小。

proxy_buffers：存儲 upstream 響應的 body 部分。第一個數(shù)字是緩沖區(qū)數(shù)量，第二個是每個緩沖區(qū)大小。如果 upstream 返回大文件，這個值需要足夠大。

proxy_buffering on：啟用響應緩沖。如果關閉，Nginx 同步轉發(fā) upstream 響應，會阻塞 worker 進程直到數(shù)據(jù)傳輸完成。對于靜態(tài)文件和大多數(shù) API 響應，開啟緩沖是最佳選擇。

proxy_busy_buffers_size：當這個大小的緩沖區(qū)被填滿后，開始向客戶端發(fā)送數(shù)據(jù)，同時繼續(xù)從 upstream 讀取數(shù)據(jù)填充緩沖區(qū)。這個值應該是 proxy_buffers 單個緩沖區(qū)的 2-3 倍。

4.3 FastCGI 緩沖區(qū)（PHP-FPM 場景）

如果 Nginx 后端是 PHP-FPM，使用 fastcgi 緩沖區(qū)配置：

fastcgi_buffer_size 64k;
fastcgi_buffers 4 64k;
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 256k;
fastcgi_connect_timeout 60s;
fastcgi_send_timeout 60s;
fastcgi_read_timeout 60s;

fastcgi_connect_timeout：與 FastCGI 服務器建立連接的超時時間。不建議超過 75 秒。

fastcgi_send_timeout：向 FastCGI 服務器發(fā)送請求的超時時間。不是整個響應傳輸時間，而是兩次寫操作之間的超時。

fastcgi_read_timeout：從 FastCGI 服務器讀取響應的超時時間。如果 PHP 腳本執(zhí)行時間很長，需要增大這個值。

5. 超時配置

5.1 客戶端超時

http {
  # 客戶端保持連接的超時（兩次請求之間）
  keepalive_timeout 65;

  # 客戶端發(fā)送請求頭的超時
  client_header_timeout 15s;

  # 客戶端發(fā)送請求體的超時
  client_body_timeout 15s;

  # 響應發(fā)送超時（兩次寫操作之間）
  send_timeout 30s;
}

keepalive_timeout：HTTP keep-alive 保持連接的時間。設置太短會導致頻繁建立連接增加開銷；設置太長會占用連接資源。65 秒是常見的折中值。

client_header_timeout：客戶端必須在指定時間內發(fā)送完整的請求頭。如果超時，返回 408 Request Timeout。

client_body_timeout：客戶端必須在指定時間內發(fā)送完整的請求體。如果超時，返回 408 Request Timeout。

send_timeout：向客戶端發(fā)送響應時的超時。不是整個響應發(fā)送完成的時間，而是兩次 write 操作之間的超時。如果客戶端接收數(shù)據(jù)慢，Nginx 會在這個時間后關閉連接。

5.2 upstream 超時

upstream backend {
  server 127.0.0.1:8080;
  keepalive 32;
  keepalive_requests 1000;
  keepalive_timeout 60s;
}

keepalive：連接池中保持的空閑連接數(shù)量。這個數(shù)量不是越大越好：每個連接占用文件描述符和內存，過多會造成資源浪費。通常設置為 expected concurrent requests / worker_processes。

keepalive_requests：一個 keepalive 連接最多處理的請求數(shù)。處理完指定數(shù)量后，連接會被關閉并重新建立，防止內存泄漏。

keepalive_timeout：keepalive 連接保持空閑的超時時間。

6. 壓縮與傳輸優(yōu)化

6.1 Gzip 壓縮

啟用 gzip 壓縮可以大幅減少傳輸數(shù)據(jù)量，提升響應速度：

http {
  gzip on;
  gzip_vary on;
  gzip_min_length 1024;
  gzip_proxied any;
  gzip_comp_level 4;
  gzip_types text/plain text/css text/xml application/json application/javascript application/xml application/xml+rss;
  gzip_buffers 16 8k;
  gzip_http_version 1.1;
  gzip_disable "MSIE [1-6].";
}

gzip on：啟用 gzip 壓縮。

gzip_vary on：在響應頭中添加Vary: Accept-Encoding，告訴緩存服務器根據(jù) Accept-Encoding 緩存不同版本。

gzip_min_length 1024：小于 1024 字節(jié)的響應不壓縮。壓縮小文件的壓縮率低且消耗 CPU，不值得。

gzip_proxied any：代理請求也啟用壓縮，不管請求頭是什么。

gzip_comp_level 4：壓縮級別 1-9。級別越高壓縮率越高，但 CPU 開銷也越大。4 是平衡點，大多數(shù)場景下最優(yōu)。

gzip_types：指定要壓縮的 MIME 類型。不在列表中的內容不會被壓縮。

**gzip_disable "MSIE [1-6]."**：禁止 IE6 對 gzip 內容的處理（IE6 對 gzip 支持有 bug）。

6.2 靜態(tài)資源緩存

對于不常變化的靜態(tài)資源，設置長期緩存減少重復請求：

location ~* .(jpg|jpeg|png|gif|ico|css|js|woff|woff2|ttf|eot)$ {
  expires 30d;
  add_header Cache-Control "public, no-transform";
  access_log off;
}

expires 30d：設置緩存時間為 30 天。靜態(tài)資源應該設置較長的緩存時間。

**add_header Cache-Control "public, no-transform"`**：添加緩存控制頭。public 表示任何緩存都可以存儲；no-transform 表示不允許轉換內容（如禁止 CDN 重新壓縮圖片）。

access_log off：關閉靜態(tài)資源的日志記錄，減少無效日志。

6.3 Sendfile 零拷貝

Linux 的 sendfile 系統(tǒng)調用可以減少內核態(tài)與用戶態(tài)之間的數(shù)據(jù)拷貝：

http {
  sendfile on;
  tcp_nopush on;
  tcp_nodelay on;
}

sendfile on：啟用 sendfile 系統(tǒng)調用。這是 Linux 高效傳輸文件的標準方式，避免了內核緩沖區(qū)到用戶緩沖區(qū)再到網(wǎng)絡緩沖區(qū)的多次拷貝。

tcp_nopush on：在 Linux 上啟用。與 sendfile 配合使用，當發(fā)送 HTTP 響應頭時，先不發(fā)送數(shù)據(jù)包，而是積累數(shù)據(jù)然后一次性發(fā)送。這減少了網(wǎng)絡小包的數(shù)量。

tcp_nodelay on：禁用 Nagle 算法。對于實時性要求高的應用（如 SSH、游戲），應該啟用；對于 HTTP 服務，兩個都應該啟用。

7. 連接處理優(yōu)化

7.1 HTTP/2 配置

HTTP/2 相比 HTTP/1.1 有顯著的性能優(yōu)勢：多路復用減少了連接數(shù)，頭部壓縮減少了傳輸量，服務器推送可以主動發(fā)送資源：

http {
  ssl_protocols TLSv1.2 TLSv1.3;
  ssl_ciphers 'TLS_AES_256_GCM_SHA384TLS_AES_128_GCM_SHA256';
  ssl_prefer_server_ciphers on;
  ssl_session_cache shared10m;
  ssl_session_timeout 1d;
}

server {
  listen 443 ssl http2;
  server_name example.com;
}

listen 443 ssl http2：啟用 HTTP/2。Nginx 1.27 版本已經(jīng)完整支持 HTTP/2。

ssl_session_cache：SSL session 緩存，減少 SSL 握手開銷。10MB 可以緩存約 40000 個 session。

ssl_session_timeout：SSL session 緩存有效期。

ssl_prefer_server_ciphers on：使用服務器端配置的加密套件優(yōu)先級，而不是客戶端的偏好。這確保了使用最安全的配置。

7.2 upstream keepalive 配置

Nginx 與 upstream 之間的連接復用是提升性能的關鍵：

upstream backend {
  server 127.0.0.1:8080;
  keepalive 64;
  keepalive_requests 10000;
  keepalive_timeout 60s;
}

location / {
  proxy_pass http://backend;
  proxy_http_version 1.1;
  proxy_set_header Connection "";
}

proxy_http_version 1.1：HTTP/1.1 才支持 keep-alive。

**proxy_set_header Connection ""**：清除 Connection 頭，避免傳遞 close 指令導致連接被關閉。設置空字符串表示使用持久連接。

keepalive 64：每個 upstream server 保持 64 個空閑連接。如果有 4 個 upstream 進程，則總共有 256 個持久連接。

keepalive_requests 10000：每個連接處理 10000 個請求后關閉，防止內存泄漏。

7.3 連接隊列與限流

在高并發(fā)場景下，需要限制最大并發(fā)數(shù)防止壓垮 upstream：

limit_req_zone $binary_remote_addr zone=req_limit:10m rate=1000r/s;
limit_conn_zone $binary_remote_addr zone=conn_limit:10m;

server {
  location / {
    # 限流：每秒 1000 個請求
    limit_req zone=req_limit burst=2000 nodelay;

    # 連接數(shù)限制：每個 IP 最多 100 個并發(fā)連接
    limit_conn conn_limit 100;

    proxy_pass http://backend;
  }
}

limit_req_zone：定義限流規(guī)則。$binary_remote_addr 是客戶端 IP 的二進制形式，比字符串形式更省內存。

rate=1000r/s：每秒鐘 1000 個請求。burst=2000 表示允許突發(fā)到 2000 個請求。nodelay 表示突發(fā)請求不延遲處理。

limit_conn：限制單個客戶端的并發(fā)連接數(shù)。超過后返回 503 Service Unavailable。

8. 緩存配置

8.1 代理緩存

Nginx 可以緩存 upstream 響應，減少對后端服務器的請求：

proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=api_cache:100m max_size=10g inactive=60m use_temp_path=off;

server {
  location /api/ {
    proxy_pass http://backend;
    proxy_cache api_cache;
    proxy_cache_valid 200 60s;
    proxy_cache_valid 404 10s;
    proxy_cache_use_stale error timeout updating;
    add_header X-Cache-Status $upstream_cache_status;
  }
}

proxy_cache_path：定義緩存存儲路徑和參數(shù)。

levels=1:2：緩存鍵的目錄層級

keys_zone=api_cache:100m：共享內存區(qū)名稱和大小，100m 可以緩存約 100 萬個 key

max_size=10g：緩存最大磁盤占用

inactive=60m：60 分鐘內未被訪問的緩存自動清除

use_temp_path=off：緩存直接寫入最終路徑，不經(jīng)過臨時目錄，減少文件移動

proxy_cache_valid：不同狀態(tài)碼的緩存有效期。200 響應緩存 60 秒，404 緩存 10 秒。

proxy_cache_use_stale：當 upstream 發(fā)生錯誤或超時時，使用舊的緩存響應。這提升了用戶體驗，但需要業(yè)務上接受返回舊數(shù)據(jù)的風險。

$upstream_cache_status：顯示緩存命中狀態(tài)，值為 HIT/MISS/EXPIRED/UPDATING/BYPASS/STALE。這個 header 幫助前端判斷數(shù)據(jù)是否來自緩存。

8.2 緩存清理

當 upstream 數(shù)據(jù)更新時，需要主動清理緩存：

# 需要加載 ngx_cache_purge 模塊
location ~ /purge(/.*) {
  proxy_cache_purge api_cache $1;
}

使用方式：curl -X PURGE http://example.com/purge/api/users/123

這會在數(shù)據(jù)更新后主動清除緩存，確保用戶立即獲取最新數(shù)據(jù)。

9. 負載均衡策略選擇

9.1 輪詢與加權輪詢

默認的負載均衡策略是輪詢，每個 upstream 依次處理請求：

upstream backend {
  server 127.0.0.1:8080 weight=5;
  server 127.0.0.1:8081 weight=3;
  server 127.0.0.1:8082 weight=2;
}

加權輪詢用于 upstream 性能不一致的場景。weight 越大的 server 分到的請求越多。性能好的機器 weight 設置更高。

9.2 最少連接數(shù)

最少連接數(shù)策略將請求發(fā)送到當前連接數(shù)最少的 upstream：

upstream backend {
  least_conn;
  server 127.0.0.1:8080;
  server 127.0.0.1:8081;
}

適合請求處理時間差異較大的場景。長時間占用連接的請求不會讓某臺 upstream 過載。

9.3 IP 哈希

IP 哈希策略保證來自同一 IP 的請求始終打到同一臺 upstream：

upstream backend {
  ip_hash;
  server 127.0.0.1:8080;
  server 127.0.0.1:8081;
  server 127.0.0.1:8082;
}

適合需要會話保持的場景。但當某臺 upstream 下線時，可能導致會話丟失（除非使用 ip_hash 配合 down）。

9.4 最少響應時間

Nginx Plus（商業(yè)版）支持最少響應時間策略，將請求發(fā)送到平均響應時間最短的 upstream。開源版可以通過第三方模塊如 nginx-upsync-module 或 Consul 配合實現(xiàn)動態(tài)負載均衡。

10. 高可用與容災

10.1 upstream 健康檢查

Nginx 開源版沒有內置健康檢查，需要通過配置實現(xiàn)被動健康檢查：

upstream backend {
  server 127.0.0.1:8080 max_fails=3 fail_timeout=30s;
  server 127.0.0.1:8081 max_fails=3 fail_timeout=30s;
  server 127.0.0.1:8082 max_fails=3 fail_timeout=30s;
}

max_fails=3：連續(xù) 3 次失敗后，認為該 server 不可用。

fail_timeout=30s：不可用狀態(tài)持續(xù) 30 秒后，重新嘗試該 server。

這種被動檢查依賴真實請求來判斷 server 健康狀態(tài)。如果某臺 upstream 掛了，在排查完成前會有少量失敗請求。

10.2 backup 與 down

upstream backend {
  server 127.0.0.1:8080 weight=5;
  server 127.0.0.1:8081 weight=3;
  server 127.0.0.1:8082 backup; # 備份 server
}

backup：標記為備份 server。只有在所有非 backup server 都不可用時，才啟用。

down：標記為永久下線，用于臨時維護。

10.3 主備架構

在雙 Nginx 主備場景中，使用 Keepalived 做 VIP 漂移：

# Nginx Master 配置
virtual_server 192.168.1.100 443 {
  delay_loop 6
  lb_algo rr
  lb_kind VRRP
  persistence_timeout 0
  protocol TCP

  real_server 192.168.1.101 443 {
    weight 1
    TCP_CHECK {
      connect_timeout 3
      nb_get_retry 3
      delay_before_retry 3
    }
  }

  real_server 192.168.1.102 443 {
    weight 1
    TCP_CHECK {
      connect_timeout 3
      nb_get_retry 3
      delay_before_retry 3
    }
  }
}

Keepalived 定期探測 real_server 的健康狀態(tài)，當 Master 不可用時，VIP 自動漂移到 Backup。這個架構保證 Nginx 層的 HA。

11. 生產(chǎn)環(huán)境驗證清單

完成參數(shù)調整后，必須逐項驗證：

Nginx 配置語法正確：nginx -t

文件描述符上限已生效：ulimit -n應顯示 100000 或更大

worker 進程數(shù)正確：ps aux | grep nginx應顯示多個 worker

端口監(jiān)聽正常：ss -tlnp | grep nginx應顯示監(jiān)聽端口

upstream 連接池生效：觀察netstat -an | grep ESTABLISHED | grep upstream_port連接數(shù)

限流生效：使用 ab 或 wrk 壓測驗證

緩存生效：檢查 X-Cache-Status 響應頭顯示 HIT

性能提升驗證：對比調整前后的 QPS 和延遲 P99

12. 常見誤區(qū)

12.1 誤區(qū)一：worker_processes 設置越大越好

實際：worker_processes 應該等于 CPU 核心數(shù)。超過 CPU 核心數(shù)后，進程切換開銷反而降低性能。可以用top或htop觀察 CPU 使用率，如果多個 worker 的 CPU 使用率都接近 100% 且總體已無提升空間，說明配置合理。

12.2 誤區(qū)二：worker_connections 設置為系統(tǒng)最大 FD

實際：worker_connections * worker_processes 必須小于 worker_rlimit_nofile。因為除了連接，還有日志文件、upstream 連接、緩存文件描述符等占用。通常 worker_connections 設置為 worker_rlimit_nofile 的 60-70% 較為安全。

12.3 誤區(qū)三：gzip 壓縮級別越高越好

實際：gzip 壓縮級別 1-9，級別越高壓縮率提升有限但 CPU 開銷指數(shù)增長。測試數(shù)據(jù)表明，級別 1 的壓縮速度是級別 9 的 5-10 倍，而壓縮率差異通常不超過 10%。建議使用級別 4 或 5。

12.4 誤區(qū)四：proxy_buffering 永遠應該開啟

實際：對于需要實時推送數(shù)據(jù)的場景（如長輪詢、Server-Sent Events），關閉 proxy_buffering 讓數(shù)據(jù)實時轉發(fā)更合適。判斷標準：如果 upstream 返回的數(shù)據(jù)需要立即到達客戶端，就關閉緩沖；如果可以接受一定延遲，就開啟。

13. 總結

高并發(fā)場景下 Nginx 優(yōu)化的核心是：最大化連接處理能力、最小化每個請求的開銷、合理利用緩存和壓縮減少數(shù)據(jù)傳輸。

參數(shù)調整的優(yōu)先級是：內核參數(shù)大于進程模型大于緩沖區(qū)配置大于協(xié)議優(yōu)化。按這個順序逐層調整，每層調整后觀察效果。

優(yōu)化不是一勞永逸。流量模式變化、upstream 性能變化、業(yè)務邏輯調整都可能讓原有的最優(yōu)配置不再最優(yōu)。建議建立定期 review 機制，結合監(jiān)控數(shù)據(jù)分析配置是否仍然合理。

最終，所有優(yōu)化都應該回歸到業(yè)務指標：QPS、延遲 P99/P95、錯誤率。只有這些指標改善了，優(yōu)化才是有效的。