一、紧急处理：快速止损的3个步骤

当服务器宕机时，首要任务是避免业务损失扩大。建议按照以下顺序操作：

1. 服务切换
   若部署了多节点架构（如主从、集群），立即通过负载均衡器（如HAProxy、Keepalived）将流量切换至备用节点。例如，在Nginx配置中通过upstream模块定义备用服务器：

   upstream backend {
       server 192.168.1.100:80 max_fails=3 fail_timeout=30s;
       server 192.168.1.101:80 backup;  # 备用节点
   }

   通过proxy_next_upstream指令实现故障自动转移：

   location / {
       proxy_pass http://backend;
       proxy_next_upstream error timeout invalid_header;
   }

2. 临时降级
   若无可用备用节点，可快速修改DNS解析（如将域名指向静态页面服务器）或通过CDN回源配置返回维护页。例如，在Nginx中配置紧急页面：

   server {
       listen 80;
       server_name example.com;
       location / {
           return 503 "Service Unavailable";
           error_page 503 /maintenance.html;
       }
       location = /maintenance.html {
           root /var/www/html;
           internal;
       }
   }

3. 通知相关方
   通过邮件、短信或IM工具通知运维、开发及业务团队，同步故障影响范围和预计恢复时间（ETA）。

二、故障排查：定位宕机原因的5个维度

恢复服务后，需系统排查宕机根源，避免问题复发。重点关注以下方向：

1. 系统资源耗尽

   • CPU/内存：通过top、htop或vmstat查看资源占用。若Nginx进程占用过高，可能是并发连接数超限（检查worker_connections参数）或存在慢请求。
   • 磁盘空间：使用df -h检查磁盘使用率，若/var/log/nginx/日志目录占满，会导致服务崩溃。建议配置日志轮转（如logrotate）：

     /var/log/nginx/*.log {
         daily
         missingok
         rotate 14
         compress
         delaycompress
         notifempty
         create 0640 nginx adm
         sharedscripts
         postrotate
             if [ -f /var/run/nginx.pid ]; then
                 kill -USR1 `cat /var/run/nginx.pid`
             fi
         endscript
     }

2. 网络问题

   • 端口冲突：通过netstat -tulnp | grep :80检查80端口是否被其他进程占用。
   • 防火墙拦截：使用iptables -L或firewall-cmd --list-all确认规则是否放行HTTP/HTTPS流量。
   • DNS解析失败：通过dig example.com或nslookup example.com验证域名解析是否正常。

3. 配置错误

   • 语法错误：运行nginx -t检查配置文件语法，常见错误包括重复的server_name、缺失的分号等。
   • 证书过期：若使用HTTPS，检查证书有效期（openssl x509 -in /path/to/cert.pem -noout -dates）。

4. 依赖服务故障

   • 后端服务不可用：通过curl -I http://backend-server测试后端API是否响应。
   • 数据库连接失败：检查Nginx配置中proxy_pass指向的数据库或应用服务是否运行。

5. 硬件故障

   • 磁盘坏道：使用smartctl -a /dev/sda检查磁盘健康状态。
   • 内存错误：通过dmesg | grep -i memory查看内核日志中的内存错误记录。

三、服务恢复：从宕机到正常运行的完整流程

根据故障类型，选择以下恢复方案：

1. 重启服务
   若为临时性故障（如资源瞬时峰值），可通过以下命令重启Nginx：

   systemctl restart nginx  # Systemd系统
   service nginx restart    # SysVinit系统

   重启后检查状态：

   systemctl status nginx

2. 回滚配置
   若最近修改过配置文件导致宕机，可回滚至上一版本：

   cp /etc/nginx/nginx.conf.bak /etc/nginx/nginx.conf
   nginx -t && systemctl restart nginx

3. 扩容资源
   若因资源不足导致频繁宕机，需升级服务器配置（如增加CPU核心数、内存容量）或优化Nginx参数：

   worker_processes auto;  # 自动匹配CPU核心数
   worker_rlimit_nofile 65535;  # 增大文件描述符限制
   events {
       worker_connections 4096;  # 每个工作进程的最大连接数
   }

四、预防措施：构建高可用Nginx架构

为避免未来宕机，建议实施以下措施：

1. 监控告警

   • 基础监控：使用Prometheus+Grafana监控Nginx的请求量、响应时间、错误率等指标。
   • 日志分析：通过ELK（Elasticsearch+Logstash+Kibana）或Fluentd集中分析访问日志，设置异常告警（如502错误突增）。
   • 进程监控：配置Monit或Nagios检查Nginx进程是否存在，若崩溃则自动重启。

2. 自动化运维

   • 配置管理：使用Ansible或Puppet自动化部署Nginx配置，避免手动操作失误。
   • 容器化部署：将Nginx封装为Docker容器，通过Kubernetes实现自动扩缩容和故障自愈。

3. 灾备设计

   • 多地域部署：在不同可用区（AZ）部署Nginx实例，通过DNS负载均衡或Anycast IP实现全局流量分发。
   • 冷备/热备：定期备份Nginx配置和证书文件，存储至云存储（如S3）或异地服务器。

4. 压力测试
   使用wrk或ab（Apache Benchmark）模拟高并发场景，验证Nginx的稳定性：

   wrk -t12 -c400 -d30s http://example.com/

   根据测试结果调整worker_connections、keepalive_timeout等参数。

五、案例分析：某电商平台的宕机复盘

背景：某电商平台在“双11”期间因Nginx宕机导致订单系统瘫痪2小时。
原因：

1. 后端API响应变慢，Nginx工作进程阻塞，连接数耗尽。
2. 未配置proxy_timeout和proxy_connect_timeout，导致长连接堆积。
3. 监控系统未覆盖Nginx的错误日志，未能及时触发告警。

改进措施：

1. 在Nginx配置中增加超时设置：

   location /api/ {
       proxy_pass http://backend;
       proxy_connect_timeout 5s;
       proxy_read_timeout 30s;
       proxy_send_timeout 30s;
   }

2. 部署Prometheus监控Nginx的active connections和request time指标。
3. 实施蓝绿部署，在非高峰期逐步升级后端服务。

六、总结：Nginx宕机处理的黄金法则

1. 快速响应：30分钟内完成服务切换或降级。
2. 系统排查：从资源、网络、配置、依赖服务4个维度定位问题。
3. 数据驱动：依赖监控日志而非主观猜测。
4. 预防优先：通过高可用架构和自动化运维减少人为故障。

通过以上方法，可显著降低Nginx宕机概率，保障业务连续性。