👉 這是一個或許對你有用的社群
《專案實戰（影片）》：從書中學，往事上“練” 《網際網路高頻面試題》：面朝簡歷學習，春暖花開 《架構 x 系統設計》：摧枯拉朽，掌控面試高頻場景題 《精進 Java 學習指南》：系統學習，網際網路主流技術棧 《必讀 Java 原始碼專欄》：知其然，知其所以然
👉這是一個或許對你有用的開源專案國產 Star 破 10w+ 的開源專案，前端包括管理後臺 + 微信小程式，後端支援單體和微服務架構。功能涵蓋 RBAC 許可權、SaaS 多租戶、資料許可權、商城、支付、工作流、大屏報表、微信公眾號、ERP、CRM、AI 大模型等等功能：
Boot 多模組架構：https://gitee.com/zhijiantianya/ruoyi-vue-pro Cloud 微服務架構：https://gitee.com/zhijiantianya/yudao-cloud 影片教程：https://doc.iocoder.cn 【國內首批】支援 JDK 17/21 + SpringBoot 3.3、JDK 8/11 + Spring Boot 2.7 雙版本
小夥伴們平時使用 Nginx 是否有進行過效能最佳化呢？還是軟體裝好了就直接使用呢？
今天和大夥分享幾個常見的 Nginx 最佳化配置。
整體上來說，Nginx 的最佳化可以從多個層面進行：
-
系統層面 -
配置層面 -
快取利用 -
壓縮策略 -
負載均衡策略
接下來我們就來看看具體該如何做。
一 Nginx 配置最佳化
-
調整 worker_processes引數，通常設定為等於伺服器的 CPU 核心數。 -
調整 worker_connections引數，以增加每個 Worker 程序可以開啟的連線數。
events {
worker_connections 1024;
}
worker_processes auto;
-
使用 HTTP/2 協議，利用多路複用和頭部壓縮等特性，提高頁面載入速度。
server {
listen 80;
listen [::]:80;
listen 443 ssl http2;
listen [::]:443 ssl http2;
}
-
最佳化 SSL/TLS 配置，如關閉不安全的加密演算法、使用 TLS 1.3 等，提高安全性和效能。
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
基於 Spring Boot + MyBatis Plus + Vue & Element 實現的後臺管理系統 + 使用者小程式，支援 RBAC 動態許可權、多租戶、資料許可權、工作流、三方登入、支付、簡訊、商城等功能
專案地址：https://github.com/YunaiV/ruoyi-vue-pro 影片教程：https://doc.iocoder.cn/video/
二 快取利用
-
啟用檔案快取，減少磁碟 I/O 操作。 -
使用代理快取，快取後端伺服器的響應內容。 -
設定合理的快取過期策略，透過 Cache-Control和Expires頭控制瀏覽器快取的有效期，減少請求次數。
proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off;
server {
location / {
proxy_cache my_cache;
proxy_pass http://backend;
}
}
在上面這段配置中，
proxy_cache_path 指令用於配置一個快取區域，該區域用於儲存代理請求的響應內容。這個指令通常在 http 塊中使用，並且是 ngx_cache_purge 模組和 ngx_http_proxy_module 模組的一部分。這項配置中的各引數含義如下：
-
/data/nginx/cache：這是快取檔案儲存的物理路徑。Nginx 將在該目錄下儲存快取資料。 -
levels=1:2：這定義了快取檔案的目錄結構。在這個例子中，1:2意味著 Nginx 將快取檔案儲存在/data/nginx/cache下的一級目錄和二級目錄中。1代表第一級目錄的數量（通常是 3 個，如data、tmp、html），2代表第二級目錄的數量（通常是 64 個，基於 0 到 63 的數字或字母）。 -
keys_zone=my_cache:10m：這定義了一個共享記憶體區域，用於儲存快取鍵和元資料。my_cache是該區域的名稱，10m表示分配的共享記憶體大小為 10MB。這個區域用於儲存快取的鍵和相關資訊，以便快速檢索和驗證快取的有效性。 -
max_size=10g：這指定了快取區域的最大大小，單位是位元組。在這個例子中，快取區域的最大大小為 10GB。當快取資料達到這個大小時，Nginx 將使用一種策略（通常是最近最少使用 LRU 演算法）來移除舊的快取資料，為新的快取資料騰出空間。 -
inactive=60m：這定義了快取物件在多久沒有被訪問後會被認為“非活躍”並可能被移除。在這個例子中，如果一個快取物件在 60 分鐘內沒有被訪問，它將被認為是非活躍的。這個引數有助於控制快取中舊資料的生命週期。 -
use_temp_path=off：這指定了是否使用臨時路徑來儲存快取檔案。off表示不使用臨時路徑，所有的快取檔案都直接儲存在指定的/data/nginx/cache路徑下。如果設定為on，則 Nginx 會使用一個臨時目錄來儲存快取檔案，在檔案被訪問後，它們會被移動到永久的快取目錄中。
基於 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現的後臺管理系統 + 使用者小程式，支援 RBAC 動態許可權、多租戶、資料許可權、工作流、三方登入、支付、簡訊、商城等功能
專案地址：https://github.com/YunaiV/yudao-cloud 影片教程：https://doc.iocoder.cn/video/
三 壓縮策略
-
啟用 Gzip 壓縮，減少資料傳輸量，提高響應速度。 -
根據伺服器的 CPU 能力和網路條件平衡壓縮級別和最小壓縮大小，以達到最佳的效能。
gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 5;
gzip_min_length 256;
gzip_types text/plain application/xml application/json application/javascript text/css;
各項配置的含義分別如下：
-
gzip on;：啟用 Gzip 壓縮。當這個指令被設定為on時，Nginx 會嘗試壓縮響應體併發送給客戶端。 -
gzip_vary on;：這個指令告訴 Nginx 在響應頭中新增Vary: Accept-Encoding。這允許快取系統（如代理或 CDN）根據客戶端是否支援壓縮來儲存不同的響應版本。 -
gzip_proxied any;：這個指令允許 Nginx 對從任何代理伺服器接收的響應進行壓縮，無論響應是否已經被壓縮。any表示無論原始響應是否被壓縮，Nginx 都會嘗試再次壓縮它。其他選項包括off（不壓縮任何代理的響應）和expired（只壓縮那些已經過期的代理響應）。 -
gzip_comp_level 5;：這個指令設定 Gzip 壓縮級別。壓縮級別範圍從 1（最快，壓縮比最低）到 9（最慢，壓縮比最高）。5 是一個在速度和壓縮比之間取得平衡的常用值。 -
gzip_min_length 256;：這個指令設定響應體的最小長度，只有當響應體大於或等於這個值時，Nginx 才會對其進行壓縮。這裡設定為 256 位元組，意味著只有當響應體大於或等於 256 位元組時，才會進行壓縮。 -
gzip_types text/plain application/xml application/json application/javascript text/css;：這個指令指定了哪些 MIME 型別的響應應該被壓縮。在這個例子中，文字、XML、JSON、JavaScript 和 CSS 型別的響應將被壓縮。
四 安全性最佳化
-
隱藏 Nginx 版本號資訊，更改原始碼隱藏 Nginx 軟體名及版本號。 -
修改 Nginx 服務的預設使用者，提高安全性。 -
配置 OCSP stapling、ssl_stapling、ssl_stapling_verify 等以增強 SSL/TLS 的安全性。
隱藏版本資訊可以提高伺服器的安全性，使攻擊者難以透過版本資訊推斷出伺服器可能存在的安全漏洞。
要隱藏 Nginx 版本號，有三個辦法，一般來說我們使用第一種方式就可以了。
修改配置檔案
在 Nginx 的配置檔案中，在
http 塊中新增以下配置：
server_tokens off;
這樣設定後，Nginx 將不會在錯誤頁面上顯示版本號。
配置完成之後，儲存配置檔案並重新載入 Nginx 以應用更改：
nginx -t
# 測試配置檔案是否正確
nginx -s reload
# 重新載入Nginx配置
這種方法可以隱藏錯誤頁面上的版本資訊，但可能無法完全隱藏所有響應頭中的版本資訊 。
修改 Nginx 原始碼
如果想要從根源上修改 Nginx 版本資訊，需要重新編譯 Nginx，步驟如下：
-
修改 src/core/nginx.h檔案中的版本定義。 -
修改 src/http/ngx_http_header_filter_module.c檔案中的伺服器字串。 -
修改 src/http/ngx_http_special_response.c檔案中的錯誤頁面底部資訊。
修改完這些檔案後，需要重新編譯 Nginx。這樣編譯安裝後，Nginx 的版本資訊將被徹底修改 。
使用第三方模組
如果需要動態修改響應頭中的版本資訊，可以使用如
headers-more-nginx-module 模組。這個模組允許你動態地新增、修改或刪除 Nginx 的響應頭。透過這個模組，可以完全控制 Server 響應頭的內容 。選擇哪種方法取決於你的具體需求和環境。
如果你只是想簡單地隱藏版本資訊，修改配置檔案可能是最簡單的方法。如果你需要更徹底地控制版本資訊，可能需要考慮修改原始碼並重新編譯 Nginx。
五 監控和日誌最佳化
-
使用日誌分析工具（如 ELK Stack、Graylog 等）來分析和視覺化 Nginx 的日誌資料。 -
定期維護策略，如更新 Nginx、審查配置檔案、備份配置檔案等。 -
使用定時任務工具（如 cron）定期清理快取，使用 Nginx 的 proxy_cache_path指令中的inactive引數設定快取的過期時間。
日誌配置如下：
access_log /var/
log
/nginx/access.log;
error_log /var/
log
/nginx/error.log;
六 系統層面最佳化
-
調整檔案描述符限制（在 /etc/sysctl.conf中設定）：
fs.file-max = 65535
-
調整 TCP 連線佇列大小（在 /etc/sysctl.conf中設定）：
net.core.somaxconn = 1024
七 故障轉移最佳化
-
最佳化健康檢查，調整健康檢查的頻率、超時時間、檢查的內容等引數，以更準確地檢測伺服器的故障。 -
結合監控系統，即時監控伺服器的健康狀況、請求流量、響應時間等指標，及時發現潛在的問題，並進行預警和處理。
配置健康檢查（使用第三方模組
nginx_upstream_check_module）：
upstream backend {
server backend1.example.com check;
server backend2.example.com check;
}
小夥伴們還做過哪些 Nginx 效能最佳化配置呢？歡迎留言討論。
歡迎加入我的知識星球，全面提升技術能力。
👉 加入方式，“長按”或“掃描”下方二維碼噢：
星球的內容包括：專案實戰、面試招聘、原始碼解析、學習路線。
文章有幫助的話，在看，轉發吧。
謝謝支援喲 (*^__^*）
