Nginx 502 Bad Gateway報錯原因解析與解決方案
摘要
作為一名在生產環(huán)境中摸爬滾打多年的運維工程師,我深知 502 Bad Gateway 錯誤對業(yè)務的致命影響。就在上周,我們的電商平臺在高峰期突然出現(xiàn)大量 502 錯誤,用戶投訴如雪花般飛來,業(yè)務損失不可估量。這次事故讓我深刻認識到,僅僅知道 502 是"網(wǎng)關錯誤"是遠遠不夠的,必須深入理解其背后的技術原理和排查方法。
在這次復盤中,我將從最基礎的 Nginx upstream 機制開始,逐步深入到 FastCGI 協(xié)議細節(jié),再到超時參數(shù)的精確調優(yōu)。我發(fā)現(xiàn)很多開發(fā)者對 502 錯誤的理解停留在表面,認為只是簡單的服務不可用,但實際上它涉及到網(wǎng)絡層、應用層、進程管理等多個維度的復雜交互。通過這次深度分析,我不僅找到了問題的根本原因,更重要的是建立了一套完整的 502 錯誤診斷和預防體系。

本文將帶你走過我的完整排查過程:從日志分析的蛛絲馬跡,到網(wǎng)絡抓包的技術細節(jié),從配置參數(shù)的精確調優(yōu),到監(jiān)控告警的體系建設。我會分享那些在官方文檔中找不到的實戰(zhàn)經驗,那些只有在生產環(huán)境中才能遇到的邊緣案例,以及那些能夠在關鍵時刻救命的調試技巧。無論你是剛接觸 Nginx 的新手,還是有一定經驗的運維工程師,這篇文章都將為你提供寶貴的實戰(zhàn)指導。

圖1:Nginx 502 錯誤產生流程圖
1. 502 錯誤的本質理解
1.1 HTTP 狀態(tài)碼深度解析
502 Bad Gateway 屬于 5xx 服務器錯誤類別,具體含義是網(wǎng)關或代理服務器從上游服務器接收到無效響應。在 Nginx 作為反向代理的場景中,這意味著 Nginx 無法從后端服務器獲得有效的 HTTP 響應。
# Nginx 配置示例:基礎 upstream 配置
upstream backend {
# 服務器權重配置
server 127.0.0.1:9000 weight=3 max_fails=2 fail_timeout=30s;
server 127.0.0.1:9001 weight=2 max_fails=2 fail_timeout=30s;
server 127.0.0.1:9002 weight=1 max_fails=2 fail_timeout=30s backup;
# 負載均衡算法
least_conn;
# 健康檢查配置
keepalive 32;
keepalive_requests 100;
keepalive_timeout 60s;
}
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://backend;
# 關鍵超時參數(shù)
proxy_connect_timeout 5s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;
# 錯誤處理
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
proxy_next_upstream_tries 3;
proxy_next_upstream_timeout 10s;
}
}這個配置展示了 Nginx upstream 的核心參數(shù)。max_fails 和 fail_timeout 控制服務器健康檢查,proxy_next_upstream 系列參數(shù)決定了遇到錯誤時的重試策略。
1.2 502 錯誤的常見觸發(fā)場景

圖2:502 錯誤原因分布餅圖
根據(jù)我的生產環(huán)境統(tǒng)計,F(xiàn)astCGI 超時是導致 502 錯誤的主要原因,占比達到 35%。這也是本文重點關注的問題。
2. upstream 日志分析實戰(zhàn)
2.1 日志格式配置與關鍵信息提取
# 自定義日志格式,包含 upstream 詳細信息
log_format upstream_log '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'rt=$request_time uct="$upstream_connect_time" '
'uht="$upstream_header_time" urt="$upstream_response_time" '
'uaddr="$upstream_addr" ustatus="$upstream_status"';
server {
access_log /var/log/nginx/upstream.log upstream_log;
error_log /var/log/nginx/error.log debug;
}關鍵參數(shù)解釋:
$upstream_connect_time: 與后端建立連接的時間
$upstream_header_time: 接收后端響應頭的時間
$upstream_response_time: 接收完整響應的時間
$upstream_addr: 實際處理請求的后端服務器地址
$upstream_status: 后端服務器返回的狀態(tài)碼
2.2 日志分析腳本
#!/bin/bash
# upstream_analyzer.sh - Nginx upstream 日志分析腳本
LOG_FILE="/var/log/nginx/upstream.log"
ANALYSIS_PERIOD="1h" # 分析最近1小時的日志
echo "=== Nginx Upstream 502 錯誤分析報告 ==="
echo "分析時間段: 最近 $ANALYSIS_PERIOD"
echo "日志文件: $LOG_FILE"
echo
# 統(tǒng)計 502 錯誤總數(shù)
error_502_count=$(grep " 502 " "$LOG_FILE" | wc -l)
echo "502 錯誤總數(shù): $error_502_count"
# 分析 502 錯誤的 upstream 響應時間分布
echo -e "\n=== 502 錯誤響應時間分析 ==="
grep " 502 " "$LOG_FILE" | \
awk '{
# 提取 upstream_response_time
match($0, /urt="([^"]*)"/, arr)
if (arr[1] != "-") {
time = arr[1]
if (time < 1) bucket="<1s"
else if (time < 5) bucket="1-5s"
else if (time < 10) bucket="5-10s"
else if (time < 30) bucket="10-30s"
else bucket=">30s"
count[bucket]++
}
}
END {
for (b in count) {
printf "%-8s: %d 次\n", b, count[b]
}
}'
# 分析最頻繁出現(xiàn) 502 的后端服務器
echo -e "\n=== 502 錯誤后端服務器分布 ==="
grep " 502 " "$LOG_FILE" | \
awk '{
match($0, /uaddr="([^"]*)"/, arr)
if (arr[1] != "-") {
servers[arr[1]]++
}
}
END {
for (server in servers) {
printf "%-20s: %d 次\n", server, servers[server]
}
}' | sort -k2 -nr
# 分析 502 錯誤的時間分布
echo -e "\n=== 502 錯誤時間分布(按小時) ==="
grep " 502 " "$LOG_FILE" | \
awk '{
# 提取時間戳中的小時
match($0, /\[([^\]]+)\]/, arr)
split(arr[1], datetime, ":")
hour = datetime[2]
hours[hour]++
}
END {
for (h in hours) {
printf "%s:00 - %d 次\n", h, hours[h]
}
}' | sort這個腳本能夠快速分析 upstream 日志,識別 502 錯誤的模式和趨勢,為問題定位提供數(shù)據(jù)支撐。
3. FastCGI 協(xié)議深度剖析
3.1 FastCGI 通信機制

圖3:FastCGI 協(xié)議通信時序圖
3.2 PHP-FPM 配置優(yōu)化
; /etc/php/8.1/fpm/pool.d/www.conf ; PHP-FPM 進程池配置優(yōu)化 [www] ; 進程管理器類型 pm = dynamic ; 進程數(shù)量配置 pm.max_children = 50 ; 最大子進程數(shù) pm.start_servers = 10 ; 啟動時的進程數(shù) pm.min_spare_servers = 5 ; 最小空閑進程數(shù) pm.max_spare_servers = 15 ; 最大空閑進程數(shù) ; 進程生命周期管理 pm.max_requests = 1000 ; 每個進程處理的最大請求數(shù) pm.process_idle_timeout = 60s ; 空閑進程超時時間 ; 超時配置 - 關鍵參數(shù) request_timeout = 300s ; 單個請求超時時間 request_terminate_timeout = 300s ; 強制終止超時時間 ; 慢日志配置 slowlog = /var/log/php8.1-fpm-slow.log request_slowlog_timeout = 10s ; 慢查詢閾值 ; 狀態(tài)監(jiān)控 pm.status_path = /fpm-status ping.path = /fpm-ping ping.response = pong ; 安全配置 security.limit_extensions = .php .php3 .php4 .php5 .php7 .php8 ; 環(huán)境變量 env[HOSTNAME] = $HOSTNAME env[PATH] = /usr/local/bin:/usr/bin:/bin env[TMP] = /tmp env[TMPDIR] = /tmp env[TEMP] = /tmp
關鍵配置說明:
request_timeout: 控制單個請求的最大執(zhí)行時間pm.max_children: 影響并發(fā)處理能力request_slowlog_timeout: 幫助識別慢查詢
3.3 Nginx FastCGI 參數(shù)調優(yōu)
location ~ \.php$ {
fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
fastcgi_index index.php;
# FastCGI 超時參數(shù) - 核心配置
fastcgi_connect_timeout 60s; # 連接超時
fastcgi_send_timeout 300s; # 發(fā)送超時
fastcgi_read_timeout 300s; # 讀取超時
# 緩沖區(qū)配置
fastcgi_buffer_size 64k; # 響應頭緩沖區(qū)
fastcgi_buffers 4 64k; # 響應體緩沖區(qū)
fastcgi_busy_buffers_size 128k; # 忙碌緩沖區(qū)大小
# 臨時文件配置
fastcgi_temp_file_write_size 128k;
fastcgi_max_temp_file_size 256m;
# 錯誤處理
fastcgi_intercept_errors on;
fastcgi_ignore_client_abort off;
# 參數(shù)傳遞
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
# 自定義參數(shù)
fastcgi_param HTTP_X_REAL_IP $remote_addr;
fastcgi_param HTTP_X_FORWARDED_FOR $proxy_add_x_forwarded_for;
fastcgi_param HTTP_X_FORWARDED_PROTO $scheme;
}4. 超時參數(shù)精確調優(yōu)
4.1 超時參數(shù)層級關系

圖4:超時參數(shù)層級關系架構圖
4.2 超時參數(shù)對比表
| 參數(shù)類型 | 配置位置 | 默認值 | 推薦值 | 影響范圍 | 備注 |
| proxy_connect_timeout | Nginx | 60s | 5s | 連接建立 | 過長會影響故障切換 |
| fastcgi_connect_timeout | Nginx | 60s | 10s | FastCGI連接 | 本地連接通常很快 |
| fastcgi_send_timeout | Nginx | 60s | 300s | 數(shù)據(jù)發(fā)送 | 大文件上傳需要更長時間 |
| fastcgi_read_timeout | Nginx | 60s | 300s | 響應讀取 | 復雜業(yè)務邏輯需要更長時間 |
| request_timeout | PHP-FPM | 0 | 300s | 請求處理 | 0表示無限制,生產環(huán)境必須設置 |
| max_execution_time | PHP | 30s | 300s | 腳本執(zhí)行 | 影響所有PHP腳本 |
4.3 動態(tài)超時調整腳本
#!/bin/bash
# timeout_optimizer.sh - 根據(jù)業(yè)務負載動態(tài)調整超時參數(shù)
# 配置文件路徑
NGINX_CONF="/etc/nginx/sites-available/default"
PHP_FPM_CONF="/etc/php/8.1/fpm/pool.d/www.conf"
# 獲取當前系統(tǒng)負載
get_system_load() {
local load_1min=$(uptime | awk -F'load average:' '{print $2}' | awk -F',' '{print $1}' | tr -d ' ')
echo "$load_1min"
}
# 獲取 PHP-FPM 進程狀態(tài)
get_fpm_status() {
local active_processes=$(curl -s http://localhost/fpm-status | grep "active processes" | awk '{print $3}')
local total_processes=$(curl -s http://localhost/fpm-status | grep "total processes" | awk '{print $3}')
echo "$active_processes/$total_processes"
}
# 分析最近的 502 錯誤率
analyze_502_rate() {
local error_count=$(tail -1000 /var/log/nginx/access.log | grep " 502 " | wc -l)
local total_requests=$(tail -1000 /var/log/nginx/access.log | wc -l)
local error_rate=$(echo "scale=4; $error_count / $total_requests * 100" | bc)
echo "$error_rate"
}
# 動態(tài)調整超時參數(shù)
adjust_timeouts() {
local load=$(get_system_load)
local error_rate=$(analyze_502_rate)
echo "當前系統(tǒng)負載: $load"
echo "當前 502 錯誤率: $error_rate%"
# 根據(jù)負載和錯誤率調整參數(shù)
if (( $(echo "$load > 2.0" | bc -l) )) || (( $(echo "$error_rate > 5.0" | bc -l) )); then
echo "檢測到高負載或高錯誤率,增加超時時間..."
# 備份原配置
cp "$NGINX_CONF" "${NGINX_CONF}.backup.$(date +%Y%m%d_%H%M%S)"
# 調整 Nginx 超時參數(shù)
sed -i 's/fastcgi_read_timeout [^;]*/fastcgi_read_timeout 600s/' "$NGINX_CONF"
sed -i 's/fastcgi_send_timeout [^;]*/fastcgi_send_timeout 600s/' "$NGINX_CONF"
# 調整 PHP-FPM 超時參數(shù)
sed -i 's/request_timeout = [^;]*/request_timeout = 600s/' "$PHP_FPM_CONF"
# 重載配置
nginx -s reload
systemctl reload php8.1-fpm
echo "超時參數(shù)已調整為 600s"
elif (( $(echo "$load < 0.5" | bc -l) )) && (( $(echo "$error_rate < 1.0" | bc -l) )); then
echo "系統(tǒng)負載較低,恢復默認超時時間..."
# 恢復默認配置
sed -i 's/fastcgi_read_timeout [^;]*/fastcgi_read_timeout 300s/' "$NGINX_CONF"
sed -i 's/fastcgi_send_timeout [^;]*/fastcgi_send_timeout 300s/' "$NGINX_CONF"
sed -i 's/request_timeout = [^;]*/request_timeout = 300s/' "$PHP_FPM_CONF"
# 重載配置
nginx -s reload
systemctl reload php8.1-fpm
echo "超時參數(shù)已恢復為 300s"
else
echo "系統(tǒng)狀態(tài)正常,保持當前配置"
fi
}
# 主函數(shù)
main() {
echo "=== Nginx FastCGI 超時參數(shù)動態(tài)優(yōu)化 ==="
echo "執(zhí)行時間: $(date)"
echo
adjust_timeouts
echo
echo "優(yōu)化完成,建議繼續(xù)監(jiān)控系統(tǒng)狀態(tài)"
}
# 執(zhí)行主函數(shù)
main5. 監(jiān)控與告警體系
5.1 Prometheus 監(jiān)控配置
# nginx-exporter.yml - Nginx 監(jiān)控配置
global:
scrape_interval: 15s
evaluation_interval: 15s
rule_files:
- "nginx_rules.yml"
scrape_configs:
- job_name: 'nginx'
static_configs:
- targets: ['localhost:9113']
scrape_interval: 5s
metrics_path: /metrics
- job_name: 'php-fpm'
static_configs:
- targets: ['localhost:9253']
scrape_interval: 5s
alerting:
alertmanagers:
- static_configs:
- targets:
- alertmanager:9093# nginx_rules.yml - 告警規(guī)則配置
groups:
- name: nginx_alerts
rules:
- alert: Nginx502ErrorHigh
expr: rate(nginx_http_requests_total{status="502"}[5m]) > 0.1
for: 2m
labels:
severity: critical
annotations:
summary: "Nginx 502 錯誤率過高"
description: "502 錯誤率在過去 5 分鐘內超過 10%"
- alert: FastCGITimeoutHigh
expr: nginx_http_request_duration_seconds{quantile="0.95"} > 30
for: 5m
labels:
severity: warning
annotations:
summary: "FastCGI 響應時間過長"
description: "95% 的請求響應時間超過 30 秒"
- alert: PHPFPMProcessesHigh
expr: phpfpm_active_processes / phpfpm_total_processes > 0.8
for: 3m
labels:
severity: warning
annotations:
summary: "PHP-FPM 進程使用率過高"
description: "活躍進程數(shù)占總進程數(shù)的 80% 以上"5.2 自動化故障恢復腳本
#!/bin/bash
# auto_recovery.sh - 502 錯誤自動恢復腳本
LOG_FILE="/var/log/nginx/access.log"
ERROR_THRESHOLD=10 # 5分鐘內502錯誤超過10次觸發(fā)恢復
TIME_WINDOW=300 # 時間窗口:5分鐘
# 檢查 502 錯誤頻率
check_502_frequency() {
local current_time=$(date +%s)
local start_time=$((current_time - TIME_WINDOW))
# 統(tǒng)計時間窗口內的 502 錯誤
local error_count=$(awk -v start="$start_time" '
{
# 解析時間戳
gsub(/\[|\]/, "", $4)
cmd = "date -d \"" $4 "\" +%s"
cmd | getline timestamp
close(cmd)
if (timestamp >= start && $9 == "502") {
count++
}
}
END {
print count + 0
}' "$LOG_FILE")
echo "$error_count"
}
# 重啟 PHP-FPM 服務
restart_php_fpm() {
echo "[$(date)] 檢測到大量 502 錯誤,重啟 PHP-FPM 服務..."
# 記錄當前進程狀態(tài)
echo "重啟前 PHP-FPM 狀態(tài):" >> /var/log/auto_recovery.log
systemctl status php8.1-fpm >> /var/log/auto_recovery.log
# 優(yōu)雅重啟
systemctl reload php8.1-fpm
# 等待服務穩(wěn)定
sleep 10
# 驗證服務狀態(tài)
if systemctl is-active --quiet php8.1-fpm; then
echo "[$(date)] PHP-FPM 重啟成功" >> /var/log/auto_recovery.log
# 發(fā)送通知
curl -X POST "https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/sendMessage" \
-d chat_id="$TELEGRAM_CHAT_ID" \
-d text="?? 自動恢復:PHP-FPM 服務已重啟,502 錯誤應該得到緩解"
else
echo "[$(date)] PHP-FPM 重啟失敗" >> /var/log/auto_recovery.log
# 發(fā)送緊急通知
curl -X POST "https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/sendMessage" \
-d chat_id="$TELEGRAM_CHAT_ID" \
-d text="?? 緊急:PHP-FPM 自動重啟失敗,需要人工介入"
fi
}
# 清理臨時文件和緩存
cleanup_temp_files() {
echo "[$(date)] 清理臨時文件和緩存..."
# 清理 PHP session 文件
find /var/lib/php/sessions -name "sess_*" -mtime +1 -delete
# 清理 Nginx 臨時文件
find /var/cache/nginx -type f -mtime +1 -delete
# 清理應用緩存(根據(jù)實際情況調整)
if [ -d "/var/www/html/cache" ]; then
find /var/www/html/cache -name "*.cache" -mtime +1 -delete
fi
echo "[$(date)] 臨時文件清理完成" >> /var/log/auto_recovery.log
}
# 主監(jiān)控循環(huán)
main_monitor() {
while true; do
local error_count=$(check_502_frequency)
if [ "$error_count" -gt "$ERROR_THRESHOLD" ]; then
echo "[$(date)] 檢測到 $error_count 個 502 錯誤,啟動自動恢復..."
# 執(zhí)行恢復操作
cleanup_temp_files
restart_php_fpm
# 等待恢復生效
sleep 60
fi
# 每30秒檢查一次
sleep 30
done
}
# 啟動監(jiān)控
echo "[$(date)] 啟動 502 錯誤自動恢復監(jiān)控..."
main_monitor6. 性能優(yōu)化與最佳實踐
6.1 系統(tǒng)級優(yōu)化
#!/bin/bash
# system_optimization.sh - 系統(tǒng)級性能優(yōu)化腳本
# 內核參數(shù)優(yōu)化
optimize_kernel_params() {
echo "優(yōu)化內核參數(shù)..."
cat >> /etc/sysctl.conf << EOF
# 網(wǎng)絡連接優(yōu)化
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 5000
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_keepalive_time = 1200
net.ipv4.tcp_max_tw_buckets = 6000
# 文件描述符限制
fs.file-max = 2097152
fs.nr_open = 2097152
# 內存管理
vm.swappiness = 10
vm.dirty_ratio = 15
vm.dirty_background_ratio = 5
EOF
sysctl -p
}
# 文件描述符限制
optimize_file_limits() {
echo "優(yōu)化文件描述符限制..."
cat >> /etc/security/limits.conf << EOF
* soft nofile 65535
* hard nofile 65535
* soft nproc 65535
* hard nproc 65535
nginx soft nofile 65535
nginx hard nofile 65535
www-data soft nofile 65535
www-data hard nofile 65535
EOF
}
# 執(zhí)行優(yōu)化
optimize_kernel_params
optimize_file_limits
echo "系統(tǒng)優(yōu)化完成,建議重啟系統(tǒng)使所有配置生效"6.2 故障案例深度復盤
"在技術的世界里,每一次故障都是成長的機會,每一次復盤都是智慧的積累。真正的工程師不是從不犯錯的人,而是能從錯誤中學習并建立防護機制的人。"
故障背景:
2023年雙11期間,我們的電商平臺在流量高峰時段(20:00-22:00)出現(xiàn)大規(guī)模 502 錯誤,影響用戶下單和支付功能。
故障時間線:
19:55 - 流量開始激增,QPS從平時的500上升到2000
20:03 - 開始出現(xiàn)零星的 502 錯誤
20:08 - 502 錯誤率達到15%,用戶投訴激增
20:12 - 緊急啟動故障處理流程
20:25 - 問題定位完成,開始執(zhí)行修復方案
20:35 - 服務完全恢復正常
根本原因分析:
- PHP-FPM 進程池配置不當:
pm.max_children = 20無法應對高并發(fā) - 數(shù)據(jù)庫連接池泄漏:應用代碼中存在未正確關閉的數(shù)據(jù)庫連接
- 緩存失效:Redis 緩存在高峰期失效,導致大量數(shù)據(jù)庫查詢
- 超時參數(shù)不匹配:FastCGI 超時時間短于數(shù)據(jù)庫查詢時間
7. 總結與展望
經過這次深度的 502 錯誤復盤,我深刻認識到運維工作的復雜性和系統(tǒng)性。從最初的日志分析,到深入的協(xié)議理解,再到系統(tǒng)級的優(yōu)化配置,每一個環(huán)節(jié)都需要扎實的技術功底和豐富的實戰(zhàn)經驗。
在這個過程中,我最大的收獲是建立了一套完整的故障處理方法 論:觀察 → 分析 → 定位 → 修復 → 預防。這不僅僅是技術層面的提升,更是思維方式的轉變。我們不能滿足于"頭痛醫(yī)頭,腳痛醫(yī)腳"的臨時修復,而要從系統(tǒng)架構的角度思考問題的根本原因。
FastCGI 超時問題看似簡單,實際上涉及到網(wǎng)絡層、應用層、數(shù)據(jù)庫層的復雜交互。通過這次復盤,我建立了從監(jiān)控告警到自動恢復的完整體系,大大提升了系統(tǒng)的穩(wěn)定性和可用性。更重要的是,我學會了如何將技術問題轉化為可量化的業(yè)務指標,讓技術優(yōu)化真正服務于業(yè)務目標。
未來,隨著微服務架構和云原生技術的普及,502 錯誤的排查會變得更加復雜。我們需要掌握更多的工具和方法,比如分布式鏈路追蹤、服務網(wǎng)格監(jiān)控、容器化部署等。但無論技術如何發(fā)展,扎實的基礎知識和系統(tǒng)性的思維方式永遠是我們最寶貴的財富。
技術的路上沒有捷徑,只有不斷的學習和實踐。每一次故障都是成長的機會,每一次優(yōu)化都是能力的提升。讓我們在技術的海洋中繼續(xù)探索,在代碼的世界里追求卓越,用我們的專業(yè)能力為用戶創(chuàng)造更好的體驗,為業(yè)務創(chuàng)造更大的價值。
以上就是Nginx 502 Bad Gateway報錯原因解析與解決方案的詳細內容,更多關于Nginx 502 Bad Gateway錯誤解決的資料請關注腳本之家其它相關文章!
相關文章
Linux 系統(tǒng) nginx 服務器安裝及負載均衡配置詳解
nginx(engine x) 是一個 高性能 的 HTTP 和 反向代理 服務器、郵件代理服務器以及通用的 TCP/UDP 代理服務器。這篇文章主要介紹了Linux 系統(tǒng) nginx 服務器安裝及負載均衡配置詳解,需要的朋友可以參考下2019-07-07
修改nginx服務器類型實現(xiàn)簡單偽裝(隱藏nginx類型與版本等)
這篇文章主要介紹了修改nginx服務器類型實現(xiàn)簡單偽裝(隱藏nginx類型與版本等),需要的朋友可以參考下2016-03-03

