nginx常用命令(備忘）

一、引言：Nginx 為何成為前端開發必備工具

在前端開發的廣闊領域中，Nginx 已然成為了一個不可或缺的強大工具。它是一款輕量級的 HTTP 服務器和反向代理服務器，采用事件驅動的異步非阻塞處理方式框架，這賦予了它卓越的 I/O 性能。

從靜態資源服務的角度來看，前端項目中包含大量的 HTML、CSS、JavaScript 以及圖片等靜態文件，Nginx 能夠以高效的方式將這些靜態資源快速地傳輸給客戶端。在電商網站中，商品展示頁面的大量圖片和樣式文件，Nginx 可以迅速響應請求，減少用戶等待時間，提升用戶體驗。

反向代理方面，Nginx 可以作為客戶端和后端服務器之間的中間層，將客戶端請求轉發到后端服務器，并將后端服務器的響應返回給客戶端。這樣做不僅隱藏了后端服務器的真實 IP 地址，提高了安全性，還能實現負載均衡，將請求均勻地分配到多個后端服務器上，避免單臺服務器負載過高。像一些大型互聯網公司，每天面對海量的用戶請求，通過 Nginx 的反向代理和負載均衡功能，能夠確保服務的穩定運行。

在處理高并發場景時，Nginx 的表現同樣出色。采用的事件驅動和異步非阻塞模型，使得它能夠在占用極少內存的情況下，同時處理數以萬計的并發連接。在一些熱門直播平臺，直播過程中會有大量觀眾同時在線觀看，Nginx 可以輕松應對這些高并發請求，保證直播的流暢性。

Nginx 對于前端開發的重要性不言而喻，而熟練掌握 Nginx 的常用命令，則是充分發揮其強大功能的關鍵。接下來，讓我們一起深入探索 Nginx 常用命令的奧秘。

二、Nginx 服務管理命令：快速控制服務狀態

在使用 Nginx 的過程中，對其服務進行有效的管理是確保 Web 服務穩定運行的關鍵。下面我們將詳細介紹 Nginx 服務管理的常用命令，這些命令涵蓋了服務的啟動、停止、狀態查看以及配置更新等操作。

（一）基礎啟停與狀態查看

啟動 Nginx 服務

- systemd 方式（推薦）：適用于通過包管理器（yum/apt）安裝的場景。在這種方式下，我們使用sudo systemctl start nginx命令來啟動 Nginx 服務。這種方式的優勢十分明顯，它能夠自動識別配置文件路徑，無需我們手動指定，大大提高了操作的便捷性。systemd 還支持開機自啟管理，我們可以使用sudo systemctl enable nginx命令將 Nginx 設置為開機自啟，確保服務器重啟后 Nginx 服務能夠自動運行。

- 二進制文件啟動：適用于源碼編譯安裝或指定自定義配置的情況。當我們采用這種方式啟動 Nginx 時，需要使用sudo nginx -c /path/to/nginx.conf命令，其中/path/to/nginx.conf是我們實際的 Nginx 配置文件路徑。需要特別注意的是，一定要確保配置文件路徑正確無誤，否則服務將無法正常啟動。如果配置文件路徑錯誤，Nginx 在啟動時會提示找不到配置文件等相關錯誤信息，這時我們就需要仔細檢查路徑是否正確。

停止 Nginx 服務

- 快速停止（暴力終止）：使用sudo nginx -s stop命令可以立即終止所有 Nginx 進程。這種方式雖然能夠快速停止服務，但存在一定風險，它可能會中斷正在處理的請求，導致數據丟失或請求失敗。在一些緊急情況下，如服務器出現嚴重故障需要立即停止 Nginx 服務時，可以使用該命令。

- 優雅停止（推薦）：通過sudo nginx -s quit命令，Nginx 會等待現有請求處理完畢后再退出。這種方式保證了數據的完整性，不會對正在進行的業務造成影響，非常適合在正常維護或更新配置時使用。當我們需要對 Nginx 進行一些不緊急的操作，如更新配置文件并希望在服務停止時不影響用戶體驗，就可以選擇優雅停止方式。

- systemd 統一管理：使用sudo systemctl stop nginx命令，這是基于 systemd 的統一管理方式，同樣能夠停止 Nginx 服務，具有與 systemd 管理相關的一系列優勢，如便于集成到系統服務管理體系中。

查看服務運行狀態：使用sudo systemctl status nginx命令，該命令的輸出包含了豐富的信息，如服務狀態（是否正在運行、已停止還是出現故障）、進程 ID（方便我們在需要時對進程進行操作）、最近日志等。通過這些信息，我們可以快速判斷服務是否正常運行。如果服務狀態顯示為 “active (running)”，則表示 Nginx 服務正在正常運行；如果顯示為 “inactive (dead)”，則說明服務已停止；若出現 “failed”，則表明服務啟動或運行過程中出現了問題，我們可以通過查看日志信息來進一步排查故障原因。

（二）配置更新與重啟策略

重新加載配置（不中斷服務）：當我們修改了nginx.conf或虛擬主機配置后，為了使新配置生效，又不想中斷正在運行的服務，可以使用sudo nginx -s reload命令。其原理是主進程讀取新的配置文件，并生成新的工作進程，然后逐步替換舊進程。在這個過程中，舊進程會繼續處理已有連接，而新進程則開始接管新的請求，直到所有舊進程處理完現有連接后才會退出，從而確保了請求處理的連續性，不會對用戶造成任何影響。當我們調整了反向代理規則、添加了新的虛擬主機或者修改了一些不影響服務運行的配置參數時，就可以使用該命令來使新配置立即生效。

完全重啟服務：在某些情況下，如配置文件結構進行了大幅度調整，或者 Nginx 服務出現異常時，我們就需要使用完全重啟服務的方式。這時可以使用sudo systemctl restart nginx命令，該命令會先停止 Nginx 服務，然后再重新啟動，確保所有配置都能正確加載，服務以全新的狀態運行。如果我們對 Nginx 的核心配置進行了修改，如更改了工作進程數、調整了重要的模塊配置等，為了保證服務的穩定性和正確性，最好采用完全重啟服務的方式。

三、Nginx 配置檢測與調試：確保配置正確無誤

在 Nginx 的使用過程中，配置文件的正確性和有效性至關重要。錯誤的配置可能導致服務無法正常啟動或運行出現異常，因此掌握 Nginx 配置檢測與調試的相關命令是非常必要的。

（一）配置文件語法校驗

在修改 Nginx 配置文件后，進行語法校驗是必不可少的步驟，這可以避免因語法錯誤導致服務啟動失敗或運行異常。我們可以使用sudo nginx -t命令來對配置文件進行語法檢查。

當配置文件語法正確時，終端會顯示syntax is ok和test is successful的提示信息，這表明我們的配置文件沒有語法問題，可以放心地進行后續操作。

如果配置文件存在語法錯誤，Nginx 會直接顯示錯誤行號及原因，幫助我們快速定位和解決問題。如果配置文件中出現括號不匹配的情況，Nginx 會提示類似于nginx: [emerg] unexpected end of file, expecting "}" in /etc/nginx/nginx.conf:XX的錯誤信息，其中XX就是錯誤所在的行號；如果是指令拼寫錯誤，比如將server_name寫成了server_nam，Nginx 則會提示nginx: [emerg] unknown directive "server_nam" in /etc/nginx/nginx.conf:XX。通過這些明確的錯誤提示，我們能夠迅速找到問題所在并進行修正。

（二）查看生效配置與版本信息

打印完整生效配置：在排查配置未生效問題時，sudo nginx -T命令非常有用。它會打印出包括默認值在內的所有最終應用配置，我們可以通過查看這些配置來確認 Nginx 實際使用的配置是否與我們預期的一致。通過該命令，我們可以看到 Nginx 對各個虛擬主機的配置、反向代理規則、緩存設置等詳細信息，從而全面了解 Nginx 的運行狀態。如果我們在配置文件中設置了某個虛擬主機的根目錄，但在實際訪問時卻發現返回的內容不是預期的，這時就可以使用該命令來檢查配置是否正確生效。

查看版本與編譯參數

- 簡潔版本號：使用nginx -v命令可以快速查看 Nginx 的版本號，這在了解 Nginx 的軟件版本以及與其他組件的兼容性時非常方便。比如我們在進行技術文檔撰寫或者與團隊成員溝通時，需要明確當前使用的 Nginx 版本，使用該命令就能輕松獲取。

- 詳細信息（含模塊、編譯選項）：執行nginx -V命令，我們不僅可以看到 Nginx 的版本號，還能獲取到其編譯時包含的模塊和編譯選項等詳細信息。例如nginx version: nginx/1.23.3 built with OpenSSL 1.1.1k，從這個輸出中，我們可以知道 Nginx 的版本是 1.23.3，并且是使用 OpenSSL 1.1.1k 進行編譯的，這對于排查一些與模塊相關的問題或者了解 Nginx 的編譯環境非常有幫助。如果我們在使用某個 Nginx 模塊時出現問題，通過查看編譯選項可以確認該模塊是否已經正確編譯安裝。

（三）虛擬主機管理（前端項目部署關鍵）

在前端項目部署中，虛擬主機管理是一個重要環節，它允許我們在同一臺服務器上部署多個不同的前端項目，通過不同的域名或端口進行訪問。

啟用 / 禁用虛擬主機：在 Nginx 中，我們通常通過軟鏈接來管理虛擬主機的配置文件。當我們想要啟用一個虛擬主機時，可以使用sudo ln -s /etc/nginx/sites-available/your-domain.conf /etc/nginx/sites-enabled/命令，該命令會在/etc/nginx/sites-enabled/目錄下創建一個指向/etc/nginx/sites-available/your-domain.conf配置文件的軟鏈接，從而啟用該虛擬主機。當我們需要對某個前端項目進行維護或者暫時不想讓其對外提供服務時，可以使用sudo unlink /etc/nginx/sites-enabled/your-domain.conf命令，刪除這個軟鏈接，進而禁用該虛擬主機。

這種通過軟鏈接管理虛擬主機的方式，在多域名項目部署的場景中非常適用。比如我們有一個前端項目，同時擁有開發環境和生產環境的不同域名，通過這種方式可以方便地切換不同環境的配置，實現靈活的項目部署和管理。在開發過程中，我們可以啟用開發環境的虛擬主機配置，方便進行調試和測試；而在項目上線時，只需切換到生產環境的虛擬主機配置即可。

四、日志與進程管理：快速定位運行時問題

在 Nginx 的日常運維中，日志與進程管理是非常重要的環節。通過合理運用相關命令，我們可以快速定位和解決運行時出現的各種問題，確保 Nginx 服務的穩定運行。

（一）實時監控日志輸出

錯誤日志（排查異常關鍵）：錯誤日志是排查 Nginx 異常的關鍵依據，我們可以使用tail -f /var/log/nginx/error.log命令來實時監控錯誤日志輸出。在實際應用中，常見的場景包括 404 資源缺失，當用戶請求的資源在服務器上不存在時，Nginx 會在錯誤日志中記錄相關信息，我們可以通過查看錯誤日志來確定具體是哪些資源被請求但未找到，從而及時補充或修復這些資源；500 內部錯誤，這通常表示服務器內部出現了問題，可能是由于代碼錯誤、數據庫連接異常等原因導致的，錯誤日志中會詳細記錄錯誤信息，幫助我們快速定位問題根源；配置參數錯誤，當我們在nginx.conf中配置的參數不正確時，Nginx 啟動或運行過程中會在錯誤日志中提示錯誤，比如端口號被占用、指令拼寫錯誤等，通過查看錯誤日志，我們能夠迅速發現并糾正這些配置問題。

訪問日志（分析用戶行為）：訪問日志對于分析用戶行為非常有幫助，我們使用tail -f /var/log/nginx/access.log命令來實時查看訪問日志。Nginx 的訪問日志可以結合日志格式自定義，記錄客戶端 IP、請求路徑、響應狀態碼等信息。在實際項目中，我們可以根據這些信息進行用戶行為分析。通過分析客戶端 IP，我們可以了解用戶的地域分布情況，從而針對性地進行內容優化和服務器部署；通過分析請求路徑，我們可以知道用戶經常訪問哪些頁面，哪些頁面的訪問量較高，哪些較低，進而對網站的內容布局和導航進行優化；通過查看響應狀態碼，我們可以判斷用戶請求的處理情況，200 表示請求成功，404 表示資源未找到，500 表示服務器內部錯誤等，根據不同的狀態碼，我們可以采取相應的措施來優化服務質量。

（二）進程與端口排查

查看 Nginx 進程樹：使用ps aux | grep nginx命令可以查看 Nginx 進程樹。該命令的輸出包含主進程（master）和工作進程（worker），正常情況下，工作進程數與 CPU 核心數相關，一般為 CPU 核心數的 1 - 2 倍。通過查看進程樹，我們可以了解 Nginx 的進程運行情況，判斷是否有異常進程存在。如果發現有過多的工作進程處于僵死狀態，就需要進一步排查原因，可能是由于服務器資源不足、程序出現死鎖等原因導致的。

端口占用檢查：在啟動 Nginx 服務時，確保其監聽的端口未被其他進程占用至關重要。我們可以使用netstat -tulnp | grep :80或lsof -i :80命令來查看 80 端口是否被占用，對于 443 端口同理，只需將端口號替換即可。如果發現端口被占用，我們需要找出占用該端口的進程，并采取相應措施解決端口沖突問題，確保 Nginx 能正常監聽服務端口。比如，若發現 80 端口被 Apache 服務占用，我們可以根據實際情況選擇停止 Apache 服務，或者修改 Nginx 的監聽端口，以避免端口沖突。在實際操作中，還可以使用fuser -k 80/tcp命令直接終止占用 80 端口的進程，但在執行此操作前，一定要確保該進程不是其他重要服務所必需的，以免影響其他業務的正常運行。

五、實戰案例：前端項目中的 Nginx 典型應用

（一）Docker 環境下的靜態資源實時刷新

在前端開發中，提高開發效率是至關重要的。在 Docker 環境下，通過掛載本地目錄到容器，可以實現修改本地文件后，容器內 Nginx 自動加載更新，這一方法在開發階段具有顯著優勢，無需頻繁重啟容器，修改本地文件即可直接生效。

具體步驟

- 創建本地目錄：首先，在本地創建一個用于存放靜態資源的目錄，比如~/my-frontend-project。在這個目錄下，我們可以按照前端項目的結構，創建html、css、js等子目錄，分別存放對應的文件。

- 拉取 Nginx 鏡像：使用docker pull nginx命令拉取最新的 Nginx 鏡像。這個鏡像包含了運行 Nginx 服務所需的所有文件和配置。

- 運行容器并掛載目錄：執行docker run -d -p 80:80 -v ~/my-frontend-project:/usr/share/nginx/html nginx命令。其中，-d表示以守護式（后臺）模式運行容器；-p 80:80將容器的 80 端口映射到主機的 80 端口，這樣我們就可以通過訪問主機的 80 端口來訪問容器內的 Nginx 服務；-v ~/my-frontend-project:/usr/share/nginx/html將本地的~/my-frontend-project目錄掛載到容器中的/usr/share/nginx/html目錄，Nginx 會從這個掛載的目錄中讀取靜態資源文件。

實際效果

完成上述配置后，當我們在本地~/my-frontend-project目錄中修改html文件的內容，比如更新頁面標題、修改頁面布局，或者修改css文件調整頁面樣式，又或者修改js文件添加新的交互功能時，無需對容器進行任何重啟操作，直接在瀏覽器中刷新頁面，就可以看到修改后的效果立即生效。這大大節省了開發時間，提高了開發效率，使我們能夠更加專注于前端代碼的編寫和優化。

（二）React 項目反向代理配置

當前端項目與 Node.js 后端分離部署時，跨域問題常常會給開發帶來困擾。通過 Nginx 進行反向代理配置，可以有效地解決這一問題，實現前端項目對后端 API 的請求轉發。

配置要點

- 確保 SPA 路由正常：在 React 項目中，通常采用單頁應用（SPA）的架構模式。在進行 Nginx 反向代理配置時，要確保 SPA 的路由能夠正常工作。對于 React Router 等路由庫，需要在 Nginx 配置中進行相應的處理，以保證路由的正確匹配和跳轉。可以通過配置try_files指令，將所有的請求都指向index.html，讓 React Router 在前端進行路由的處理。

- 需匹配后端實際地址：準確地將前端項目中的 API 請求轉發到后端 Node.js 服務器的實際地址是關鍵。在 Nginx 的配置文件中，使用proxy_pass指令指定后端服務器的地址。如果后端服務器部署在不同的主機上，需要填寫正確的 IP 地址和端口號；如果后端服務器與 Nginx 在同一主機上，可以使用本地回環地址127.0.0.1加上對應的端口號。

示例配置

假設我們的 React 項目部署在/var/www/react-app目錄下，后端 Node.js 服務器運行在192.168.1.100:3000地址上，以下是一個簡單的 Nginx 配置示例：

server {listen 80;server_name your-domain.com;location / {root /var/www/react-app;index index.html;try_files $uri $uri/ /index.html;}location /api/ {proxy_pass http://192.168.1.100:3000/;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;}}

在這個配置中，/路徑用于處理 React 項目的靜態資源和頁面請求，try_files指令確保了 SPA 路由的正常工作；/api/路徑用于匹配前端項目中所有以/api/開頭的 API 請求，并將其轉發到后端 Node.js 服務器的192.168.1.100:3000地址上，同時設置了一些代理頭信息，以保證后端服務器能夠獲取到正確的請求信息。

（三）負載均衡基礎配置（多節點部署）

當后端存在多個服務實例時，為了提高系統的性能和可用性，需要通過 Nginx 實現請求分發，即負載均衡。Nginx 提供了多種負載均衡策略，我們需要根據業務場景選擇合適的算法。

常用策略

- 輪詢：這是 Nginx 的默認負載均衡策略。在這種策略下，每個請求按時間順序逐一分配到不同的后端服務器。當后端服務器性能相近，且對會話保持沒有特殊要求時，輪詢策略是一個簡單有效的選擇。比如，一個簡單的 Web 應用，后端有多個相同配置的 Tomcat 服務器實例，使用輪詢策略可以均勻地將用戶請求分配到各個實例上，充分利用服務器資源。

- 加權輪詢：通過為每個后端服務器分配不同的權重，來控制請求的分發比例。權重越高，服務器接收的請求越多。這種策略適用于后端服務器性能不一致的場景。如果后端有一臺配置較高的服務器和幾臺配置較低的服務器，我們可以為配置高的服務器設置較高的權重，使其能夠處理更多的請求，從而提高整體系統的性能。

- IP 哈希：根據客戶端的 IP 地址進行哈希計算，將請求分配到固定的服務器。這一策略適用于需要會話保持的場景，如用戶登錄、購物車等功能。以電商網站為例，當用戶登錄后，后續的請求需要保持在同一臺服務器上，以確保用戶的購物車信息、登錄狀態等不會丟失，IP 哈希策略就能很好地滿足這一需求。

配置示例

假設我們有三個后端服務器實例，地址分別為192.168.1.101:8080、192.168.1.102:8080和192.168.1.103:8080，以下是不同負載均衡策略的配置示例：

- 輪詢策略配置：

upstream backend {server 192.168.1.101:8080;server 192.168.1.102:8080;server 192.168.1.103:8080;}server {listen 80;server_name your-domain.com;location / {proxy_pass http://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;}}

加權輪詢策略配置：

upstream backend {server 192.168.1.101:8080 weight=2;server 192.168.1.102:8080 weight=1;server 192.168.1.103:8080 weight=1;}server {listen 80;server_name your-domain.com;location / {proxy_pass http://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;}}

IP 哈希策略配置：

upstream backend {ip_hash;server 192.168.1.101:8080;server 192.168.1.102:8080;server 192.168.1.103:8080;}server {listen 80;server_name your-domain.com;location / {proxy_pass http://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;}}

通過上述配置，Nginx 能夠根據不同的負載均衡策略，將前端的請求合理地分發到后端的多個服務實例上，從而提高系統的性能和可靠性。