场景：您在一个Kubernetes环境中将Nginx作为API网关运行。随着时间的推移，您发现延迟增加，偶尔出现502错误。API服务本身是健康的，问题指向中间件层。
症状：P95响应时间从200ms增加到2s，间歇性出现502 Bad Gateway错误，Nginx错误日志显示“upstream timed out”或“connect() failed”。
诊断：
1. 检查Nginx错误日志：tail -f /var/log/nginx/error.log
2. 检查访问日志中的上游响应时间：tail -f /var/log/nginx/access.log | awk '{print $NF}'（最后一个字段是上游响应时间）
3. 检查Nginx worker连接数：curl http://localhost/nginx_status（需要stub_status模块）
4. 检查系统资源使用：top、vmstat、netstat
5. 分析配置：检查proxy_connect_timeout、proxy_read_timeout、worker_connections、keepalive设置
诊断命令：
- nginx -T：转储完整配置
- ab -n 1000 -c 100 http://your-api-gateway/：进行负载测试
- curl -w "@curl-format.txt" -o /dev/null -s http://your-api-gateway/endpoint：使用计时文件
风险控制：
- 在更改前备份配置文件：cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak
- 在预发环境中测试更改
- 如果涉及重载，使用nginx -s reload而不是重启
- 对于Kubernetes，更新ConfigMap并逐步重启
具体优化：
- 增加worker_connections（例如从1024到4096）如果并发连接数高
- 调整上游的keepalive：proxy_http_version 1.1; proxy_set_header Connection "";
- 增加proxy缓冲区：proxy_buffer_size 4k; proxy_buffers 8 4k;
- 考虑使用upstream的least_conn或ip_hash进行负载均衡
- 如果适用，启用缓存或压缩
回滚：
- 如果更改后性能下降，回退配置：cp /etc/nginx/nginx.conf.bak /etc/nginx/nginx.conf && nginx -s reload
- 在Kubernetes中，回退ConfigMap并应用之前的版本
验证： - 使用合成监控工具（如Prometheus/Grafana）监控响应时间，或重复执行curl - 检查错误日志中超时错误的减少 - 比较更改前后的P95延迟
何时提交OpsGlobal工单： - 如果调优未能解决问题 - 如果您怀疑Nginx之外的网络问题（例如上游服务延迟、DNS问题） - 如果您需要专家审查架构或高级调优（例如SSL终止、WebSocket支持、限流） - 如果问题间歇性且需要深度包检测或多个指标的关联分析
适用场景
适合正在处理 Performance、Kubernetes, SRE 相关问题的团队，用于快速建立排查路径和交付标准。
问题背景
为SRE提供一份实用指南，用于诊断和解决Nginx作为API网关中间件时的性能问题，包含可操作的步骤和安全预防措施。
排查步骤
先确认影响范围和最近变更，再收集日志、配置、指标和链路数据，最后按风险从低到高执行修复。
命令示例
示例命令请替换为你的真实资源名，并使用环境变量保存账号、密码、token 等敏感信息。
风险说明
生产环境操作前需要确认备份、权限边界、变更窗口和回滚路径，避免扩大故障影响。
回滚方案
保留原配置和发布版本；如修复后指标异常，立即回退配置、镜像或数据库变更并复核日志。
交付清单
问题定位记录、关键命令、修复步骤、验证结果、后续优化建议。
遇到类似技术问题？
如果你的服务器、K8s、Docker、CI/CD、数据库或监控系统出现类似问题，可以提交日志和配置文件，我们帮你远程诊断。