背景與問題

日常運(yùn)維工作中，日志分析是排查問題最直接的手段。Nginx 作為入口層代理，幾乎所有請(qǐng)求都要經(jīng)過它。當(dāng)網(wǎng)站出現(xiàn)響應(yīng)慢、500 錯(cuò)誤、502 網(wǎng)關(guān)超時(shí)、限流失效等問題時(shí)，第一反應(yīng)應(yīng)該是查 Nginx 日志。但很多運(yùn)維人員面對(duì)一堆文本日志，不知道從哪下手，看不懂關(guān)鍵字段的含義，導(dǎo)致排查方向錯(cuò)誤，白白浪費(fèi)時(shí)間。

本文以 2026 年最新的 Nginx 1.27.x 版本為基準(zhǔn)，系統(tǒng)講解 Nginx 訪問日志和錯(cuò)誤日志的完整字段含義、日志格式配置、日志分析命令實(shí)踐、常見問題排查思路，以及生產(chǎn)環(huán)境最佳配置建議。讀完本文，你能夠獨(dú)立完成日志分析、定位故障根因、輸出可執(zhí)行的優(yōu)化方案。

1. Nginx 日志基礎(chǔ)架構(gòu)

1.1 日志寫入原理

Nginx 采用異步寫入機(jī)制，日志數(shù)據(jù)先寫入內(nèi)存緩沖區(qū)，等緩沖區(qū)寫滿或者達(dá)到刷新時(shí)間閾值時(shí)才寫入磁盤文件。這種設(shè)計(jì)避免了對(duì)每個(gè)請(qǐng)求都執(zhí)行磁盤 I/O，顯著提升了性能。但這也帶來一個(gè)風(fēng)險(xiǎn)：如果 Nginx 異常崩潰，緩沖區(qū)中尚未寫入磁盤的日志會(huì)丟失，這在故障復(fù)盤時(shí)會(huì)造成困擾。

Nginx 日志模塊的核心組件包括：

ngx_http_log_module：負(fù)責(zé)處理訪問日志的寫入

ngx_errlog_module：負(fù)責(zé)處理錯(cuò)誤日志的寫入

log_file：日志寫入的目標(biāo)文件路徑

open_log_file_cache：日志文件描述符緩存，避免頻繁打開關(guān)閉文件

配置文件中的access_log指令和error_log指令分別控制兩類日志的輸出目標(biāo)。

1.2 訪問日志與錯(cuò)誤日志的區(qū)別

訪問日志記錄每一個(gè)請(qǐng)求的詳細(xì)信息，包括請(qǐng)求來源、請(qǐng)求路徑、響應(yīng)狀態(tài)碼、響應(yīng)大小、響應(yīng)時(shí)間等。訪問日志是分析流量、排查業(yè)務(wù)異常的基石。

錯(cuò)誤日志記錄 Nginx 自身運(yùn)行時(shí)的異常情況，包括配置文件語法錯(cuò)誤、 upstream 連接失敗、權(quán)限問題、文件描述符耗盡等。錯(cuò)誤日志是排查 Nginx 自身故障的唯一入口。

兩個(gè)日志文件路徑通過不同指令分開配置，職責(zé)清晰。在生產(chǎn)環(huán)境中，必須確保這兩個(gè)日志文件都正常寫入，且磁盤空間充足。

1.3 默認(rèn)日志路徑

主流 Linux 發(fā)行版的 Nginx 默認(rèn)日志路徑如下：

Debian/Ubuntu：/var/log/nginx/access.log和/var/log/nginx/error.log

RHEL/CentOS/ AlmaLinux：/var/log/nginx/access.log和/var/log/nginx/error.log

Alpine：/var/log/nginx/access.log和/var/log/nginx/error.log

源碼編譯安裝的 Nginx 默認(rèn)在$prefix/logs/目錄。如果通過 Docker 容器運(yùn)行，日志通常掛載到宿主機(jī)目錄，需要特別確認(rèn)路徑。

2. 訪問日志完整字段解析

2.1 默認(rèn)日志格式

Nginx 默認(rèn)的 access_log 格式使用預(yù)定義的combined格式，字段如下：

log_format combined'$remote_addr - $remote_user [$time_local] '
         '"$request" $status $body_bytes_sent '
         '"$http_referer" "$http_user_agent"';

這個(gè)格式輸出類似下面的內(nèi)容：

192.168.1.100 - - [14/Apr/202630:45 +0800]"GET /api/users HTTP/1.1"200 1234"https://example.com/index.html""Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"

逐個(gè)字段解析如下。

2.2 核心必懂字段

$remote_addr

客戶端真實(shí) IP 地址。如果客戶端沒有使用代理，這個(gè)地址就是真實(shí)的來源 IP。如果請(qǐng)求經(jīng)過七層負(fù)載均衡或 CDN 到達(dá) Nginx，這個(gè)字段顯示的是上一跳的 IP 地址，而不是客戶端真實(shí) IP。這時(shí)需要通過$http_x_forwarded_for獲取真實(shí)來源。

在有代理鏈路的場(chǎng)景中，$remote_addr可能顯示的是 SLB/Nginx 層地址，造成所有請(qǐng)求都看起來來自同一個(gè) IP 的假象。這對(duì)于基于 IP 的限流和訪問控制是致命問題，必須通過set_real_ip_from指令配合$remote_addr修正，或者直接使用$http_x_forwarded_for的第一個(gè) IP。

$remote_user

Basic 認(rèn)證的用戶名。如果請(qǐng)求沒有經(jīng)過認(rèn)證，這個(gè)字段為空，用短橫線占位。在企業(yè)內(nèi)部系統(tǒng)使用 Basic Auth 時(shí)，這個(gè)字段才有實(shí)際意義。

[$time_local]

本地時(shí)間，格式為[14/Apr/202630:45 +0800]。這個(gè)時(shí)間是 Nginx 服務(wù)器的本地時(shí)間，與客戶端時(shí)間可能存在時(shí)區(qū)差異。括號(hào)必須保留，日志解析工具通常依賴這個(gè)時(shí)間戳格式做切分。

注意：time_iso8601不同。$time_iso8601輸出 ISO 8601 格式如2026-04-14T1045+08:00`，適合對(duì)接結(jié)構(gòu)化日志系統(tǒng)如 ELK。

"$request"

完整的請(qǐng)求行，包含方法、URI、協(xié)議版本。格式為"GET /api/users HTTP/1.1"。這個(gè)字段是分析請(qǐng)求路徑的核心，可以統(tǒng)計(jì)熱門頁(yè)面、發(fā)現(xiàn)異常請(qǐng)求模式。

需要注意的是，如果請(qǐng)求包含查詢參數(shù)，參數(shù)會(huì)包含在 URI 中，如GET /search?q=nginx HTTP/1.1。但某些敏感參數(shù)值可能被$http_authorization過濾。請(qǐng)求方法通過這個(gè)字段的第一個(gè)單詞提取。

$status

HTTP 響應(yīng)狀態(tài)碼。常見狀態(tài)碼含義如下：

200：請(qǐng)求成功

206：部分內(nèi)容，用于斷點(diǎn)續(xù)傳或大文件分片下載

301/302：重定向，301 是永久重定向，302 是臨時(shí)重定向

304：Not Modified，瀏覽器緩存未更新

400：Bad Request，客戶端請(qǐng)求語法錯(cuò)誤

401：Unauthorized，需要認(rèn)證

403：Forbidden，權(quán)限不足或資源被禁止訪問

404：Not Found，資源不存在

499：Client Closed Request，客戶端在服務(wù)端響應(yīng)前關(guān)閉連接，常見于 PHP-FPM 處理超時(shí)場(chǎng)景

500：Internal Server Error，服務(wù)端代碼異常

502：Bad Gateway，upstream 錯(cuò)誤，上游服務(wù)不可用

503：Service Unavailable，服務(wù)過載或正在維護(hù)

504：Gateway Timeout，upstream 超時(shí)，上游響應(yīng)過慢

在故障排查時(shí)，$status 是首要關(guān)注指標(biāo)。出現(xiàn)大量 502/504 說明 upstream 有問題；大量 499 說明客戶端等待不及開始關(guān)閉連接；大量 400/403 可能是攻擊或配置錯(cuò)誤。

$body_bytes_sent

發(fā)送給客戶端的響應(yīng)體字節(jié)數(shù)，不包含 HTTP 頭部。這個(gè)數(shù)值不包括 SSL 加密產(chǎn)生的額外字節(jié)，對(duì)于下載服務(wù)，這個(gè)字段直接反映實(shí)際傳輸量。結(jié)合 $status 可以分析帶寬消耗和錯(cuò)誤分布。

注意：如果使用 gzip 壓縮，gzip_ratio`。

"$http_referer"

Referer 請(qǐng)求頭的值，表示當(dāng)前請(qǐng)求的來源頁(yè)面。如果用戶直接在瀏覽器輸入 URL 訪問，則 Referer 為空或短橫線。通過搜索引擎訪問時(shí)，Referer 顯示搜索引擎地址。通過外鏈點(diǎn)擊訪問時(shí)，Referer 顯示來源站點(diǎn)。

這個(gè)字段對(duì)于分析流量來源、追蹤推廣效果、發(fā)現(xiàn)異常外鏈非常有價(jià)值。但 Referer 頭可以被客戶端偽造或清除，因此僅作為參考，不能作為權(quán)威數(shù)據(jù)源。

"$http_user_agent"

User-Agent 請(qǐng)求頭的值，表示客戶端類型信息。這個(gè)字段內(nèi)容非常豐富，包括瀏覽器名稱和版本、操作系統(tǒng)、設(shè)備類型等。對(duì)于 API 請(qǐng)求或非瀏覽器客戶端，這里顯示的是調(diào)用方的標(biāo)識(shí)信息。

通過分析 $http_user_agent 可以發(fā)現(xiàn)惡意爬蟲、異?？蛻舳税姹痉植肌PP 兼容性等問題。但 User-Agent 同樣可以被客戶端任意修改，不能作為安全控制的唯一依據(jù)。

2.3 進(jìn)階分析字段

$http_x_forwarded_for

當(dāng)請(qǐng)求經(jīng)過代理或負(fù)載均衡時(shí)，真實(shí)客戶端 IP 會(huì)被放在X-Forwarded-For請(qǐng)求頭中傳遞。格式為client_ip, proxy1_ip, proxy2_ip，第一個(gè) IP 是真實(shí)來源。如果 Nginx 前面有多級(jí)代理，這個(gè)字段會(huì)包含整條鏈路的所有 IP。

使用 CDN 或高防 IP 時(shí)，這個(gè)字段可能被客戶端偽造，需要結(jié)合$remote_addr和 CDN 提供的真實(shí) IP 回源功能做綜合判斷。

$http_x_real_ip

部分代理（如 Nginx ngx_http_realip_module）在轉(zhuǎn)發(fā)請(qǐng)求時(shí)，會(huì)將真實(shí) IP 放在X-Real-IP請(qǐng)求頭中。這個(gè)字段比 X-Forwarded-For 更簡(jiǎn)潔，但需要 upstream 服務(wù)明確支持。

$request_time

請(qǐng)求處理時(shí)間，從接收到請(qǐng)求頭到完整響應(yīng)發(fā)送完成的總時(shí)間，單位是秒，精確到毫秒。這個(gè)時(shí)間是 Nginx 內(nèi)部處理時(shí)間與 upstream 響應(yīng)時(shí)間的總和，不包含網(wǎng)絡(luò)傳輸時(shí)間。

在 2026 年的 Nginx 版本中，默認(rèn)精度為毫秒級(jí)，格式如0.120。對(duì)于 PHP-FPM 或 uwsgi 等動(dòng)態(tài)服務(wù)，這個(gè)時(shí)間包含 PHP/ Python 腳本執(zhí)行時(shí)間；對(duì)于靜態(tài)文件，這個(gè)時(shí)間主要是磁盤 I/O 和傳輸時(shí)間。

如果 $request_time 異常大，如超過 30 秒，說明 upstream 處理過慢，需要進(jìn)一步分析慢請(qǐng)求根因。

$upstream_response_time

upstream 服務(wù)響應(yīng)時(shí)間，即 Nginx 向后端 upstream 發(fā)起請(qǐng)求到收到完整響應(yīng)的時(shí)間。如果請(qǐng)求沒有經(jīng)過 upstream（如直接處理靜態(tài)文件），這個(gè)值為空。

這個(gè)字段與 $request_time 的差值，就是 Nginx 自身的處理開銷（如等待連接、SSL 握手、過濾處理等）。如果差值過大，說明 Nginx 層存在瓶頸。

$upstream_status

upstream 返回的 HTTP 狀態(tài)碼。如果 Nginx 訪問多個(gè) upstream（如 backup 服務(wù)器），這個(gè)字段記錄最后一個(gè)成功響應(yīng)的狀態(tài)碼。通過對(duì)比upstream_status，可以判斷錯(cuò)誤是發(fā)生在 Nginx 層還是 upstream 層。

$upstream_addr

實(shí)際處理請(qǐng)求的 upstream 服務(wù)器地址，格式為IP:port。如果是負(fù)載均衡場(chǎng)景，這個(gè)字段顯示實(shí)際選中的 upstream 節(jié)點(diǎn)。結(jié)合upstream_response_time，可以定位到具體是哪臺(tái) upstream 出了問題。

$pipe

如果請(qǐng)求使用了 HTTP pipeline，這個(gè)字段為p，否則為點(diǎn)。HTTP pipeline 在現(xiàn)代 Nginx 中已很少使用，這個(gè)字段通常為點(diǎn)。

$request_length

請(qǐng)求的總長(zhǎng)度，包括請(qǐng)求行、請(qǐng)求頭、請(qǐng)求體。這個(gè)指標(biāo)對(duì)于分析上傳文件大小、檢測(cè)異常大請(qǐng)求很有價(jià)值。

$msec

Unix 時(shí)間戳，精確到毫秒。格式為1744612245.123。這個(gè)時(shí)間戳是絕對(duì)時(shí)間，適合做日志聚合和時(shí)間校準(zhǔn)，特別是在多臺(tái)服務(wù)器日志匯總分析時(shí)，比 $time_local 更可靠。

$connection

連接的序列號(hào)，每個(gè)連接唯一遞增。在排查連接問題時(shí)，這個(gè)編號(hào)用于關(guān)聯(lián)同一連接上的多個(gè)請(qǐng)求（同一連接上的多請(qǐng)求會(huì)有相同的 connection 編號(hào)）。

$connection_requests

當(dāng)前連接的請(qǐng)求數(shù)。HTTP/1.1 協(xié)議支持 keep-alive 復(fù)用連接，這個(gè)數(shù)字記錄該連接上已處理的請(qǐng)求總數(shù)。如果這個(gè)數(shù)字異常大，可能存在連接泄漏或 keep-alive 配置不當(dāng)。

$ssl_protocol

SSL/TLS 協(xié)議版本，如TLSv1.2、TLSv1.3。如果連接未使用 SSL，這個(gè)字段為空。在 2026 年，TLSv1.2 正在逐步淘汰，主流網(wǎng)站已全面遷移到 TLSv1.3。TLSv1.3 在握手速度和安全性上有顯著提升。

$ssl_cipher

當(dāng)前連接使用的加密套件名稱，如TLS_AES_256_GCM_SHA384。這個(gè)字段反映當(dāng)前 SSL 配置的安全強(qiáng)度。使用弱加密套件會(huì)被安全掃描工具標(biāo)記為漏洞。

$ssl_curves（Nginx 1.27+ 新增）

TLSv1.3 場(chǎng)景下使用的橢圓曲線算法。Nginx 1.27 版本開始在日志中支持記錄這個(gè)字段，用于分析客戶端與服務(wù)器協(xié)商的加密參數(shù)。

$http_cookie

完整的 Cookie 請(qǐng)求頭內(nèi)容。由于 Cookie 通常包含敏感信息，生產(chǎn)環(huán)境中不建議將這個(gè)字段直接寫入日志，除非有明確的脫敏處理流程。

$cookie_*

Nginx 允許通過$cookie_*變量提取特定名稱的 Cookie 值，如$cookie_session_id。這種方式比直接記錄完整 Cookie 更安全，只記錄業(yè)務(wù)需要的特定字段。

$arg_*

Nginx 允許通過$arg_*變量提取 URL 查詢參數(shù)的值，如$arg_q。但查詢參數(shù)中的敏感信息不應(yīng)寫入日志，存在信息泄露風(fēng)險(xiǎn)。

3. 錯(cuò)誤日志完整字段解析

3.1 錯(cuò)誤日志級(jí)別

Nginx 錯(cuò)誤日志通過error_log指令配置，支持以下級(jí)別，按嚴(yán)重程度從低到高排列：

debug：調(diào)試信息，僅在編譯時(shí)加入--with-debug參數(shù)時(shí)可用

info：一般信息

notice：通知

warn：警告，可能存在問題但不影響運(yùn)行

error：錯(cuò)誤，請(qǐng)求處理失敗

crit：嚴(yán)重，僅報(bào)告嚴(yán)重問題

alert：緊急，必須立即處理

emerg：緊急，系統(tǒng)不可用

生產(chǎn)環(huán)境通常設(shè)置為warn或error。設(shè)置info或debug會(huì)產(chǎn)生大量日志，不僅消耗磁盤空間，還會(huì)影響性能。僅在排查問題時(shí)臨時(shí)調(diào)整為debug，問題解決后立即恢復(fù)。

3.2 錯(cuò)誤日志格式

錯(cuò)誤日志沒有固定的格式，但通常包含時(shí)間戳、錯(cuò)誤級(jí)別、進(jìn)程信息、客戶端 IP（如果有）、錯(cuò)誤描述。示例如下：

2026/04/14 1045 [error] 12345#12345: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.1.100, server: example.com, request: "GET /api HTTP/1.1", upstream: "http://127.0.0.1:8080/api", host: "example.com"

這個(gè)錯(cuò)誤信息表明 Nginx 連接 upstream 失敗，原因是 Connection refused。逐段解析：

2026/04/14 1045：錯(cuò)誤發(fā)生時(shí)間

[error]：錯(cuò)誤級(jí)別

12345#12345：進(jìn)程 ID，主進(jìn)程為 12345

*1：連接序列號(hào)

connect() failed (111: Connection refused)：系統(tǒng)調(diào)用失敗及 errno

while connecting to upstream：錯(cuò)誤發(fā)生的上下文

client: 192.168.1.100：客戶端 IP

server: example.com：匹配的 server 配置塊

request: "GET /api HTTP/1.1"：請(qǐng)求詳情

upstream: "http://127.0.0.1:8080/api"：目標(biāo) upstream

host: "example.com"：請(qǐng)求的 Host 頭

理解這些字段對(duì)于定位 upstream 相關(guān)錯(cuò)誤至關(guān)重要。

3.3 常見錯(cuò)誤碼與含義

111: Connection refused

目標(biāo)端口沒有服務(wù)監(jiān)聽。檢查 upstream 服務(wù)是否啟動(dòng)，端口是否正確綁定。

113: No route to host

網(wǎng)絡(luò)不可達(dá)，可能目標(biāo)服務(wù)器宕機(jī)或網(wǎng)絡(luò)配置錯(cuò)誤。

104: Connection reset by peer

對(duì)端關(guān)閉了連接?？赡?upstream 服務(wù)異常重啟或配置了連接限制。

Connection timed out (110)

連接超時(shí)，上游服務(wù)響應(yīng)過慢或網(wǎng)絡(luò)中存在丟包。

1113: No live upstreams

所有 upstream 都不可用，Nginx 無法找到可用的后端服務(wù)器。

2048: Worker process exited with signal 9 (SIGKILL)

工作進(jìn)程被強(qiáng)制殺死，通常是 OOMKiller 導(dǎo)致。內(nèi)存泄漏或配置不當(dāng)是常見原因。

32000: Internal dispatch framework error

Nginx 內(nèi)部分發(fā)框架錯(cuò)誤，通常由配置錯(cuò)誤或模塊沖突引起。

4. 日志格式配置實(shí)戰(zhàn)

4.1 定義適合分析的日志格式

默認(rèn)的 combined 格式對(duì)生產(chǎn)環(huán)境分析而言字段不足夠。以下是一個(gè)更完整的日志格式配置示例：

log_format detailed '$remote_addr - $remote_user [$time_local] '
          '"$request" $status $body_bytes_sent '
          '"$http_referer" "$http_user_agent" '
          '$request_time $upstream_response_time $upstream_status '
          '$upstream_addr $http_x_forwarded_for '
          '$ssl_protocol $ssl_cipher '
          '$connection $connection_requests';

access_log /var/log/nginx/access.log detailed buffer=32k flush=5s;

buffer=32k表示將日志寫入 32KB 的內(nèi)存緩沖區(qū)再批量刷盤，減少磁盤 I/O 次數(shù)。flush=5s表示即使緩沖區(qū)未滿，5 秒后也會(huì)強(qiáng)制刷盤。兩者配合使用兼顧性能和可靠性。

4.2 條件日志記錄

Nginx 支持根據(jù)變量條件選擇性記錄日志。使用map指令配合access_log的if參數(shù)，可以排除健康檢查請(qǐng)求、靜態(tài)資源請(qǐng)求，或者只記錄慢請(qǐng)求：

map $request_uri $log_request {
  ~*^/health$ 0;
  ~*.png$ 0;
  ~*.jpg$ 0;
  default 1;
}

map $request_time $log_slow {
  ~^[0-9]{1,3}.[0-9]{3}$ 0;
  default 1;
}

access_log /var/log/nginx/access.log detailed if=$log_request;

這個(gè)配置排除了健康檢查和圖片請(qǐng)求的日志記錄，減少無效日志干擾。

4.3 結(jié)構(gòu)化 JSON 日志格式

對(duì)接 ELK（Elasticsearch、Logstash、Kibana）或 Loki 等日志收集系統(tǒng)時(shí)，JSON 格式日志更易于解析。配置如下：

log_format json_log escape=json '{'
  '"time":"$time_iso8601",'
  '"remote_addr":"$remote_addr",'
  '"remote_user":"$remote_user",'
  '"request":"$request",'
  '"status":$status,'
  '"body_bytes_sent":$body_bytes_sent,'
  '"request_time":$request_time,'
  '"upstream_response_time":$upstream_response_time,'
  '"upstream_status":$upstream_status,'
  '"upstream_addr":"$upstream_addr",'
  '"http_referer":"$http_referer",'
  '"http_user_agent":"$http_user_agent",'
  '"http_x_forwarded_for":"$http_x_forwarded_for",'
  '"ssl_protocol":"$ssl_protocol",'
  '"ssl_cipher":"$ssl_cipher",'
  '"connection":"$connection",'
  '"connection_requests":"$connection_requests"'
  '}';

注意$status和$body_bytes_sent等數(shù)字類型變量在 JSON 中不能加引號(hào)，否則 Elasticsearch 會(huì)將其識(shí)別為字符串而非數(shù)值，失去聚合計(jì)算能力。使用escape=json參數(shù)確保特殊字符被正確轉(zhuǎn)義。

4.4 錯(cuò)誤日志配置最佳實(shí)踐

error_log /var/log/nginx/error.log warn;

# 將錯(cuò)誤日志同時(shí)輸出到 syslog，便于集中收集
error_log syslog:server=127.0.0.1:514,facility=local7 warn;

將錯(cuò)誤日志發(fā)送到 syslog 有兩個(gè)好處：即使 Nginx 日志文件被誤刪，錯(cuò)誤日志仍然保存在 syslog 中；便于集中收集多臺(tái)服務(wù)器的日志進(jìn)行關(guān)聯(lián)分析。

5. 日志分析命令實(shí)戰(zhàn)

5.1 基礎(chǔ)查看命令

日志文件通常較大，直接用cat或vi打開會(huì)卡死。應(yīng)使用以下方式分頁(yè)查看：

# 分頁(yè)查看最后 100 行
tail -n 100 /var/log/nginx/access.log

# 實(shí)時(shí)追蹤新日志（類似 tail -f）
tail -f /var/log/nginx/access.log

# 分頁(yè)查看從頭開始的 100 行
head -n 100 /var/log/nginx/access.log

# 查看特定時(shí)間范圍的日志
sed -n'/14/Apr/202600/,/14/Apr/202600/p'/var/log/nginx/access.log

5.2 狀態(tài)碼統(tǒng)計(jì)

統(tǒng)計(jì)各狀態(tài)碼的出現(xiàn)次數(shù)，按次數(shù)降序排列：

awk'{print $9}'/var/log/nginx/access.log | sort | uniq -c | sort -rn

輸出示例：

15432 200
3211 304
 1205 404
 312 502
 187 499
  89 500
  12 403

從這個(gè)輸出可以快速判斷網(wǎng)站健康度：正常情況下 200 和 304 應(yīng)占 95% 以上；404 超過 1% 說明存在死鏈；502/504 出現(xiàn)說明 upstream 有問題；499 出現(xiàn)說明客戶端在服務(wù)端響應(yīng)完成前關(guān)閉了連接。

5.3 請(qǐng)求時(shí)間分析

分析響應(yīng)時(shí)間分布，找出慢請(qǐng)求：

# 提取 request_time 并排序，統(tǒng)計(jì)慢請(qǐng)求分布
awk'{print $NF}'/var/log/nginx/access.log | awk -F.'{print $1}'| sort | uniq -c | sort -rn | head -20

# 篩選響應(yīng)時(shí)間超過 5 秒的請(qǐng)求
awk'$NF > 5 {print $0}'/var/log/nginx/access.log

# 計(jì)算平均響應(yīng)時(shí)間
awk -F'"''{sum+=$NF; count++} END {print sum/count}'/var/log/nginx/access.log

響應(yīng)時(shí)間超過 3 秒的請(qǐng)求應(yīng)該引起重視，超過 10 秒的請(qǐng)求必須排查。分位數(shù)統(tǒng)計(jì)比平均值更有意義：如果 P99 是 2 秒，說明 99% 的請(qǐng)求在 2 秒內(nèi)響應(yīng)；但如果 P50 是 0.5 秒而 P99 是 10 秒，說明存在少量極端慢請(qǐng)求拖累了整體體驗(yàn)。

5.4 高頻請(qǐng)求分析

統(tǒng)計(jì)最常訪問的 URL（排除靜態(tài)資源）：

awk -F'"''{print $2}'/var/log/nginx/access.log | awk'{print $2}'| grep -v'.(jpg|png|css|js|ico|gif|woff2)'| sort | uniq -c | sort -rn | head -20

# 統(tǒng)計(jì)接口調(diào)用次數(shù)分布，發(fā)現(xiàn)異常高頻調(diào)用
awk -F'"''{print $2}'/var/log/nginx/access.log | awk'{print $2}'| cut -d'?'-f1 | sort | uniq -c | sort -rn | head -20

如果某個(gè)接口調(diào)用次數(shù)異常高，可能是爬蟲高頻抓取或被人惡意調(diào)用，存在性能和安全隱患。

5.5 來源 IP 分析

統(tǒng)計(jì)請(qǐng)求來源 IP 分布，發(fā)現(xiàn)異常來源：

awk'{print $1}'/var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# 統(tǒng)計(jì)來自同一 IP 的請(qǐng)求次數(shù)，檢測(cè)爬蟲或攻擊
awk'{print $1}'/var/log/nginx/access.log | sort | uniq -c | sort -rn | awk'$1 > 1000 {print "Suspicious IP: " $2 " Count: " $1}'

正常用戶行為下，單個(gè) IP 的請(qǐng)求頻率不會(huì)超過一定閾值。如果某個(gè) IP 每秒發(fā)起數(shù)百次請(qǐng)求，基本可以判斷為爬蟲或攻擊。

5.6 帶寬消耗分析

統(tǒng)計(jì)每個(gè)請(qǐng)求的流量消耗：

# 統(tǒng)計(jì)總帶寬消耗（單位：字節(jié)）
awk -F'"''{sum+=$10} END {print sum}'/var/log/nginx/access.log

# 統(tǒng)計(jì)流量最大的 20 個(gè)請(qǐng)求
awk -F'"''{print $10, $2}'/var/log/nginx/access.log | sort -rn | head -20

注意$body_bytes_sent是壓縮后的大小。如果啟用了 gzip，實(shí)際傳輸量會(huì)小于原始文件大小。如果帶寬消耗異常高，可能是被盜鏈或者被惡意請(qǐng)求大文件。

5.7 upstream 問題分析

針對(duì)代理場(chǎng)景，分析 upstream 健康度：

# 提取 upstream 狀態(tài)碼分布
awk -F'"''{print $14}'/var/log/nginx/access.log | grep -v'-'| sort | uniq -c | sort -rn

# 找出 502/504 錯(cuò)誤的請(qǐng)求，分析是哪臺(tái) upstream
awk -F'"''$14 ~ /502|504/ {print $0}'/var/log/nginx/access.log | head -10

# 分析各 upstream 的響應(yīng)時(shí)間差異
awk -F'"''{print $16, $18}'/var/log/nginx/access.log | grep -v'-'| sort | uniq -c | sort -rn

如果 502/504 錯(cuò)誤的 upstream_addr 都指向同一臺(tái)服務(wù)器，說明該服務(wù)器存在問題。如果 upstream_status 為空但 Nginx 返回了 502，說明 upstream 配置有誤或服務(wù)未啟動(dòng)。

5.8 錯(cuò)誤日志分析

過濾指定級(jí)別的錯(cuò)誤：

# 只看 error 級(jí)別以上的日志
grep'[error]'/var/log/nginx/error.log

# 過濾特定錯(cuò)誤類型
grep'connect() failed'/var/log/nginx/error.log

# 統(tǒng)計(jì)各類錯(cuò)誤出現(xiàn)次數(shù)
grep'[error]'/var/log/nginx/error.log | awk -F': ''{print $NF}'| cut -d'('-f1 | sort | uniq -c | sort -rn

5.9 日志切割配置

Nginx 自身不切割日志，需要通過 logrotate 或內(nèi)置方式實(shí)現(xiàn)：

使用 logrotate：

# /etc/logrotate.d/nginx
/var/log/nginx/*.log{
  daily
  missingok
  rotate 30
  compress
  delaycompress
  notifempty
  create 0640 nginx nginx
  sharedscripts
  postrotate
    [ -f /var/run/nginx.pid ] &&kill-USR1 `cat /var/run/nginx.pid`
  endscript
}

kill -USR1信號(hào)告訴 Nginx 重新打開日志文件，實(shí)現(xiàn)平滑切換，不丟請(qǐng)求。

使用 Nginx 內(nèi)置日志切割（零停機(jī)）：

mv /var/log/nginx/access.log /var/log/nginx/access.log.$(date +%Y%m%d%H%M%S)
kill-USR1 $(cat /var/run/nginx.pid)

這種手動(dòng)切割方式適合作為備份腳本的一部分，但 logrotate 是更標(biāo)準(zhǔn)的做法。

6. 常見故障排查案例

6.1 案例一：大量 502 Bad Gateway

現(xiàn)象：網(wǎng)站間歇性出現(xiàn) 502 錯(cuò)誤，用戶反饋時(shí)好時(shí)壞。

排查步驟：

第一步，查看錯(cuò)誤日志：

grep'[error]'/var/log/nginx/error.log | grep'connect() failed'| tail -20

第二步，如果 upstream 是 PHP-FPM，檢查 PHP-FPM 進(jìn)程狀態(tài)：

systemctl status php-fpm
ss -lntp | grep php-fpm

第三步，檢查 PHP-FPM 的慢日志：

tail -f /var/log/php-fpm/www-slow.log

第四步，檢查 PHP-FPM 配置的 max_children 和請(qǐng)求超時(shí)時(shí)間：

# php-fpm.conf
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
request_terminate_timeout = 60s

根因：502 通常是 upstream 無響應(yīng)導(dǎo)致。可能原因包括 PHP-FPM 進(jìn)程耗盡、PHP 腳本執(zhí)行超時(shí)、數(shù)據(jù)庫(kù)連接耗盡、PHP-FPM 進(jìn)程 OOM 被殺死等。

解決思路：增加 PHP-FPM 的 max_children、延長(zhǎng)超時(shí)時(shí)間、優(yōu)化 PHP 腳本性能（如增加緩存、減少數(shù)據(jù)庫(kù)查詢）、增加服務(wù)器內(nèi)存。

6.2 案例二：所有請(qǐng)求響應(yīng)時(shí)間突然變長(zhǎng)

現(xiàn)象：服務(wù)器 CPU 和內(nèi)存使用率正常，但所有接口響應(yīng)時(shí)間都增加了 2-3 秒。

排查步驟：

第一步，檢查 upstream 響應(yīng)時(shí)間：

awk -F'"''{print $13}'/var/log/nginx/access.log | awk'NF'| sort | uniq -c | sort -rn | head -10

第二步，檢查 Nginx 與 upstream 之間的網(wǎng)絡(luò)延遲：

ping -c 10 127.0.0.1
ss -s

第三步，檢查是否存在大量 keep-alive 連接等待處理：

netstat -an | grep ESTABLISHED | wc -l

第四步，檢查 upstream 的連接池配置：

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

根因：響應(yīng)時(shí)間全面增加，通常是 Nginx 與 upstream 之間的連接問題。可能是 keepalive 連接未釋放導(dǎo)致連接復(fù)用率低、upstream 的 backlog 隊(duì)列滿了導(dǎo)致請(qǐng)求排隊(duì)、網(wǎng)絡(luò)層面存在丟包或延遲。

解決思路：確保 upstream 配置了足夠的 keepalive 連接數(shù)、檢查網(wǎng)絡(luò)設(shè)備是否存在問題、調(diào)整內(nèi)核網(wǎng)絡(luò)參數(shù)如 net.core.somaxconn 和 net.ipv4.tcp_max_syn_backlog。

6.3 案例三：來自同一 IP 的異常高頻請(qǐng)求

現(xiàn)象：安全監(jiān)控系統(tǒng)告警發(fā)現(xiàn)某個(gè) IP 在短時(shí)間內(nèi)發(fā)起了數(shù)萬次請(qǐng)求。

排查步驟：

第一步，分析該 IP 的請(qǐng)求特征：

grep'^異常IP'/var/log/nginx/access.log | awk'{print $2}'| awk -F'"''{print $2}'| sort | uniq -c | sort -rn | head -20

第二步，檢查該 IP 訪問的路徑是否集中在特定接口：

grep'^異常IP'/var/log/nginx/access.log | awk -F'"''{print $2}'| awk'{print $2}'| sort | uniq -c | sort -rn

第三步，分析 User-Agent 判斷是否為爬蟲：

grep'^異常IP'/var/log/nginx/access.log | awk -F'"''{print $8}'| sort | uniq -c | sort -rn

根因：可能是惡意爬蟲、競(jìng)爭(zhēng)對(duì)手抓取、CC 攻擊的前兆。

解決思路：在 Nginx 層封禁該 IP（但需要注意繞過 CDN 時(shí)真實(shí) IP 可能不同）、接入 WAF 防護(hù)、配置 rate limiting 限流策略、將異常流量打上標(biāo)記上報(bào)安全監(jiān)控系統(tǒng)。

6.4 案例四：CSS/JS 文件返回 404 但文件實(shí)際存在

現(xiàn)象：頁(yè)面樣式錯(cuò)亂，瀏覽器控制臺(tái)顯示 CSS 文件 404，但登錄服務(wù)器確認(rèn)文件存在。

排查步驟：

第一步，確認(rèn) 404 請(qǐng)求的 URL 和 Referer：

grep'404'/var/log/nginx/access.log | grep'.css'| head -10

輸出會(huì)顯示請(qǐng)求的完整 URL 和來源頁(yè)面。

第二步，檢查 alias 路徑配置是否正確：

location /static/css/ {
  alias /data/www/static/css/;
}

注意 alias 路徑尾部斜杠的含義：帶斜杠表示將 URL 中的路徑直接拼接到 alias 路徑后面；不帶斜杠則需要去掉 URI 中對(duì)應(yīng)的前綴。

根因：alias 配置錯(cuò)誤是最常見原因。Nginx 的 location 匹配規(guī)則也會(huì)影響 alias 的解析結(jié)果。

解決思路：修正 alias 配置、使用 root 替代 alias（注意兩者的路徑拼接規(guī)則差異）、確認(rèn) location 塊的匹配優(yōu)先級(jí)。

6.5 案例五：HTTPS 證書配置后部分客戶端無法訪問

現(xiàn)象：新部署了 SSL 證書，部分舊版本客戶端無法建立 HTTPS 連接。

排查步驟：

第一步，查看錯(cuò)誤日志中的 SSL 相關(guān)錯(cuò)誤：

grep'ssl'/var/log/nginx/error.log | tail -50

第二步，檢查 SSL 協(xié)議版本配置：

grep -E'ssl_protocols|ssl_ciphers'/etc/nginx/conf.d/*.conf

第三步，使用 openssl 測(cè)試證書支持的協(xié)議和加密套件：

openssl s_client -connect example.com:443 -tls1_1
openssl s_client -connect example.com:443 -tls1_2
openssl s_client -connect example.com:443 -tls1_3

第四步，查看日志中記錄的 ssl_protocol 和 ssl_cipher：

awk -F'"''{print $25, $26}'/var/log/nginx/access.log | sort | uniq -c | sort -rn

根因：配置了過于嚴(yán)格的 SSL 參數(shù)，導(dǎo)致舊版本客戶端不支持。2026 年 TLSv1.2 的弱加密套件正在被逐步禁用，如果業(yè)務(wù)需要支持老舊客戶端（如舊版 Android APP 或 IE），需要特別配置。

解決思路：根據(jù)業(yè)務(wù)實(shí)際情況選擇合適的 SSL 配置、優(yōu)先使用 TLSv1.3、與客戶端團(tuán)隊(duì)確認(rèn)支持的最低協(xié)議版本。

7. 日志分析與監(jiān)控聯(lián)動(dòng)

7.1 接入 ELK Stack

現(xiàn)代運(yùn)維體系中，日志集中收集和分析是標(biāo)準(zhǔn)配置。Nginx 日志接入 ELK 的架構(gòu)如下：

Filebeat 收集日志 -> Logstash 解析過濾 -> Elasticsearch 存儲(chǔ)索引 -> Kibana 可視化展示

Filebeat 配置示例：

# /etc/filebeat/filebeat.yml
filebeat.inputs:
-type:log
enabled:true
paths:
 -/var/log/nginx/access.log
json.keys_under_root:true
json.add_error_key:true
fields:
 log_type:nginx_access
fields_under_root:true

output.logstash:
hosts:["logstash.example.com:5044"]

7.2 接入 Prometheus + Grafana

結(jié)合nginx_exporter可以將 Nginx 的 metrics 暴露給 Prometheus 采集，然后在 Grafana 中可視化展示：

# 啟動(dòng) nginx_exporter
nginx_exporter -nginx.scrape_uri=http://localhost/status

Nginx 需要啟用 stub_status 模塊：

server {
  listen 127.0.0.1:8080;
  server_name localhost;
  location /status {
    stub_status on;
    access_log off;
    allow 127.0.0.1;
    deny all;
  }
}

關(guān)鍵監(jiān)控指標(biāo)包括：active connections（當(dāng)前活躍連接數(shù)）、accepts（接受的連接總數(shù)）、handled（處理的連接總數(shù)）、requests（處理的請(qǐng)求總數(shù)）、reading/writing/waiting（當(dāng)前讀/寫/等待狀態(tài)的連接數(shù)）。

7.3 告警規(guī)則設(shè)計(jì)

基于日志分析的告警策略示例：

5 分鐘內(nèi) 502/504 錯(cuò)誤超過 100 次：觸發(fā) upstream 告警

5 分鐘內(nèi)來自同一 IP 的請(qǐng)求超過 5000 次：觸發(fā) CC 攻擊告警

P99 響應(yīng)時(shí)間超過 10 秒：觸發(fā)性能告警

error.log 中出現(xiàn) OOM 或 signal 9：觸發(fā)進(jìn)程異常告警

8. 生產(chǎn)環(huán)境最佳實(shí)踐

8.1 日志存儲(chǔ)策略

單個(gè) Nginx 日志文件不宜過大，建議每日切割后保留 30 天，超過 30 天的日志遷移到對(duì)象存儲(chǔ)（如 S3、OSS）做冷存儲(chǔ)。日志文件權(quán)限設(shè)置為 640，所有者為 nginx 運(yùn)行用戶，防止敏感信息泄露。

8.2 磁盤空間監(jiān)控

Nginx 日志目錄應(yīng)該加入磁盤空間監(jiān)控。經(jīng)驗(yàn)閾值：磁盤使用率超過 80% 告警，超過 90% 必須立即處理。可以通過 Prometheus 的 node_filesystem_metrics 或 Zabbix 的磁盤監(jiān)控實(shí)現(xiàn)。

# 快速查看 Nginx 日志目錄大小
du -sh /var/log/nginx/

# 查看日志目錄所在磁盤的使用率
df -h /var/log/nginx

8.3 敏感信息保護(hù)

日志中可能包含敏感信息，需要注意：

禁止將用戶密碼、Token、身份證號(hào)等寫入日志

對(duì) query string 中的敏感參數(shù)做過濾

定期檢查日志內(nèi)容，發(fā)現(xiàn)敏感信息立即處理

日志文件權(quán)限控制，防止非授權(quán)訪問

使用map指令過濾敏感參數(shù)：

map $request_uri $request_filtered {
  ~*(.*)password=(.*) $1password=***$2;
  ~*(.*)token=(.*) $1token=***$2;
  ~*(.*)id_card=(.*) $1id_card=***$2;
  default $request_uri;
}

8.4 性能影響評(píng)估

日志寫入是有性能開銷的，特別是高頻請(qǐng)求場(chǎng)景。測(cè)試數(shù)據(jù)表明：關(guān)閉 access_log 后 QPS 可提升約 5-10%。因此對(duì)于超大流量的 Nginx，日志配置需要特別優(yōu)化：

使用 buffer 和 flush 參數(shù)減少磁盤 I/O

使用異步日志寫入（需要編譯時(shí)啟用）

對(duì)于超大流量場(chǎng)景，考慮采樣日志（只記錄 1/10 的請(qǐng)求）

靜態(tài)資源（圖片、CSS、JS）單獨(dú)配置日志關(guān)閉，減少無效寫入

8.5 規(guī)范化日志字段

團(tuán)隊(duì)內(nèi)統(tǒng)一日志格式非常重要。建議在 Confd 或 Consul 中統(tǒng)一管理日志模板，確保所有 Nginx 節(jié)點(diǎn)使用相同的日志格式，便于后續(xù)日志分析和工具對(duì)接。

日志字段命名規(guī)范：使用下劃線分隔的英文字母，不使用駝峰命名或中文拼音縮寫。時(shí)間統(tǒng)一使用 ISO 8601 格式。數(shù)值類型字段不添加引號(hào)，便于后續(xù)統(tǒng)計(jì)計(jì)算。

9. 自檢清單

完成日志分析配置后，按以下清單逐項(xiàng)檢查：

訪問日志格式包含哪些字段：time、remote_addr、request、status、body_bytes_sent、request_time、upstream_*

錯(cuò)誤日志級(jí)別設(shè)置是否正確（生產(chǎn)環(huán)境應(yīng)為 warn 或 error）

日志切割策略是否配置，保留周期是否符合要求

日志目錄磁盤空間監(jiān)控是否配置

敏感信息過濾規(guī)則是否配置

日志格式是否支持 ELK/Prometheus 等監(jiān)控系統(tǒng)接入

日志文件權(quán)限是否正確（640，nginx 用戶可寫）

是否關(guān)閉了靜態(tài)資源的 access_log（可選但推薦）

測(cè)試日志寫入是否正常：執(zhí)行nginx -t后 reload，驗(yàn)證無報(bào)錯(cuò)

健康檢查機(jī)制是否建立：定期分析日志中的異常指標(biāo)

10. 總結(jié)

Nginx 日志是運(yùn)維工作的第一手資料。理解每個(gè)字段的含義是分析問題的前提，而日志分析方法則是將數(shù)據(jù)轉(zhuǎn)化為洞察的工具。

訪問日志中的request_time、$upstream_* 是排查性能問題和 upstream 故障的核心字段。錯(cuò)誤日志中的 errno 信息是定位 Nginx 自身問題的唯一入口。合理配置日志格式，在保證信息完整性的同時(shí)避免過度記錄。接入 ELK 或 Prometheus 等監(jiān)控系統(tǒng)，將被動(dòng)查詢轉(zhuǎn)化為主動(dòng)告警。

日志分析能力的提升來自實(shí)踐。遇到問題時(shí)，先看日志再查資料，養(yǎng)成這個(gè)習(xí)慣能讓你比大多數(shù)運(yùn)維工程師更快定位根因。