躬行笔记 » 服务器500错误又来了？别慌！这份排查指南让你秒变故障终结者

前言

说起500错误，我想每个做运维的朋友都有一肚子苦水要倒。昨天晚上11点多，我正准备洗洗睡了，手机突然疯狂震动——客户问题又来了。打开一看，果然是熟悉的HTTP 500错误，用户访问网站直接白屏。

这种时候真的是又爱又恨，爱的是能锻炼自己的技术能力，恨的是为什么总是在最不合适的时候出现。不过经过这么多年的摸爬滚打，我总结出了一套比较实用的排查思路，今天就分享给大家。

500错误其实就是服务器内部错误，说白了就是服务器遇到了意外情况，不知道怎么处理了。但是这个"意外情况"可能的原因太多了，从代码bug到服务器资源不足，从数据库连接问题到配置文件错误，每一个都可能是罪魁祸首。

第一步：快速定位问题范围

遇到500错误，我的第一反应不是立马去翻日志，而是先搞清楚影响范围。这个很重要，因为它决定了你处理问题的优先级和方式。

我一般会快速检查几个点：

是所有页面都500还是只有特定页面（可以通过浏览器f12查看报错接口）
是所有用户都受影响还是部分用户
错误是突然出现的还是逐渐增多的

记得有一次，有个业务网站突然开始报500错误。我当时就先测试了几个不同的页面，发现只有特定页有问题，首页和其他功能页面都正常。这就大大缩小了排查范围，基本可以确定是相关的功能出了问题。

如果你用的是负载均衡，还要检查一下是不是某台服务器的问题。我习惯直接访问每台服务器的IP，看看是不是所有服务器都有问题。有时候可能只是其中一台服务器出了状况。

深入日志分析

确定了影响范围之后，就该看日志了。日志是我们排查问题最重要的线索，但是看日志也有技巧。

Web服务器日志

先看Web服务器的错误日志，比如Nginx的error.log或者Apache的error_log。这里通常能看到最直接的错误信息。

tail -f /var/log/nginx/error.log

我经常看到的错误类型有：

连接超时：upstream timed out
连接被拒绝：connect() failed (111: Connection refused)
文件权限问题：Permission denied
配置语法错误：nginx configuration test failed

有一次我遇到一个很奇怪的问题，Nginx日志显示"upstream timed out"，但是应用服务器看起来运行正常。后来发现是因为某个接口的处理时间突然变长了，超过了Nginx设置的超时时间。调整了一下proxy_read_timeout就解决了。

系统资源检查

有时候500错误不是代码问题，而是服务器资源不够用了。这种情况下，即使代码没问题，服务器也处理不了请求。

内存使用情况

free -h

如果可用内存很少，或者swap使用率很高，那很可能就是内存不足导致的问题。我遇到过好几次因为内存不足导致的500错误，特别是在流量突然增大的时候。

还可以用top或者htop看看哪个进程占用内存最多：

top -o %MEM

CPU使用率

top

CPU使用率持续100%也会导致服务器响应缓慢或者直接返回500错误。我见过有些服务器因为某个进程死循环，CPU占用率一直是100%，导致整个网站都访问不了。

磁盘空间

df -h

磁盘空间不足也是一个常见原因，特别是日志文件增长太快的时候。我就遇到过因为某个日志文件疯狂增长，把磁盘空间占满了，导致应用无法写入临时文件而报500错误。

不同应用类型的专项排查

根据我这些年的经验，不同技术栈的应用出现500错误时，排查重点还是有些区别的。

Java应用排查

Java应用的500错误排查，我一般从这几个方面入手：

JVM内存问题

Java应用最容易出现的就是内存问题，特别是OutOfMemoryError。

jstat -gc <pid>
jmap -histo <pid>

我记得有一次，一个Spring Boot应用突然开始频繁500，通过jstat发现老年代内存使用率一直在99%以上，明显是内存泄漏了。后来用MAT分析heap dump，发现是某个缓存没有设置过期时间，导致对象越积累越多。

线程池状态

jstack <pid>

线程池满了也会导致请求无法处理。我见过有些应用因为某个接口响应特别慢，把线程池都占满了，新的请求进来就直接500了。

GC问题

jstat -gc <pid> 1s

如果Full GC频繁或者GC时间过长，也会影响应用响应。我遇到过一次，应用每隔几分钟就会卡顿几秒钟，用户访问就会超时报500，原因就是Full GC时间太长了。

应用日志

Java应用的日志通常在logs目录下，或者通过logback、log4j配置的路径：

tail -f /app/logs/application.log
grep "ERROR" /app/logs/application.log | tail -20

常见的错误类型：

数据库连接池耗尽
空指针异常
类加载失败
配置文件读取失败

PHP应用排查

PHP应用的排查相对简单一些，但也有自己的特点。

PHP-FPM进程状态

systemctl status php-fpm
ps aux | grep php-fpm

PHP-FPM进程数不够或者进程死掉了，都会导致500错误。我遇到过好几次因为php-fpm配置的max_children太小，高并发时进程不够用的情况。

PHP错误日志

tail -f /var/log/php/error.log

PHP的错误日志通常能直接告诉你问题所在：

Fatal error: 致命错误，比如内存不足、语法错误
Parse error: 语法解析错误
Warning: 警告，可能导致功能异常

内存限制

PHP有memory_limit限制，如果脚本占用内存超过这个值就会报Fatal error：

php -i | grep memory_limit

我见过有些数据导入脚本，处理大文件时内存不够用，直接就500了。

文件权限

PHP应用对文件权限比较敏感，特别是上传目录、缓存目录等：

ls -la /var/www/html/

Python应用排查

Python应用的排查重点又不太一样。

WSGI服务器状态

如果用的是Gunicorn或者uWSGI：

ps aux | grep gunicorn
systemctl status gunicorn

Python进程内存

Python应用也容易出现内存泄漏，特别是使用了某些C扩展的时候：

ps -o pid,ppid,cmd,%mem,%cpu --sort=-%mem | head

Django/Flask应用日志

tail -f /var/log/django/error.log
tail -f /var/log/flask/app.log

Python应用常见的500错误：

模块导入失败
数据库连接问题
模板渲染错误
第三方库版本冲突

我遇到过一次很坑的情况，服务器上同时跑着Python 2和Python 3的应用，结果某次系统更新后，Python 2的一些依赖包出问题了，导致应用启动失败。

Go应用排查

Go应用相对来说比较稳定，但也有自己的问题。

Goroutine泄漏

curl http://localhost:6060/debug/pprof/goroutine?debug=1

如果开启了pprof，可以通过这个接口查看goroutine数量。goroutine泄漏会导致内存占用越来越高。

应用日志

Go应用的日志格式比较自由，通常在应用目录或者系统日志里：

journalctl -u your-go-app -f
tail -f /var/log/your-app.log

panic恢复

Go应用如果没有正确处理panic，就会导致整个程序崩溃：

defer func() {
    if r := recover(); r != nil {
        log.Printf("Recovered from panic: %v", r)
    }
}()

Node.js应用排查

Node.js应用的排查也有自己的特点。

进程管理器状态

如果用的是PM2：

pm2 status
pm2 logs

内存泄漏检查

Node.js应用容易出现内存泄漏，特别是事件监听器没有正确移除的时候：

node --inspect your-app.js

然后用Chrome DevTools连接进行内存分析。

事件循环阻塞

const blocked = require('blocked-at');
blocked((time, stack) => {
  console.log(`Blocked for ${time}ms, operation started here:`, stack);
});

数据库连接问题排查

数据库问题是导致500错误的一个大头。我遇到的数据库相关的500错误主要有几种：

连接数耗尽

SHOW PROCESSLIST;
SHOW STATUS LIKE 'Threads_connected';
SHOW VARIABLES LIKE 'max_connections';

如果连接数接近max_connections的值，就说明数据库连接池满了。这时候新的请求就会因为无法获取数据库连接而报500错误。

我记得有一次双11活动，流量突然暴增，数据库连接数瞬间就满了。当时紧急调整了max_connections的值，同时优化了应用的连接池配置，才解决了问题。

慢查询

SHOW PROCESSLIST;

如果看到很多查询处于"Sending data"或者"Copying to tmp table"状态，说明有慢查询在拖累整个数据库性能。

可以开启慢查询日志来定位具体是哪些SQL语句有问题：

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 2;

锁等待

SHOW ENGINE INNODB STATUS;

这个命令可以看到InnoDB的详细状态，包括是否有死锁或者锁等待的情况。

配置文件和环境问题

配置文件的问题也经常导致500错误，而且这种问题通常比较隐蔽。

Web服务器配置

检查Nginx或Apache的配置文件语法：

nginx -t
apache2ctl configtest

我见过有人修改配置文件后忘记检查语法，重启服务后直接就500了。还有一种情况是配置文件的路径写错了，或者权限设置不对。

应用配置

应用程序的配置文件也要检查，比如数据库连接配置、缓存配置等。有时候可能是配置文件被意外修改了，或者环境变量没有正确设置。

我遇到过一次很坑的情况，开发同事在测试环境修改了数据库配置，结果不小心把生产环境的配置也改了，导致应用连不上数据库，全站500。

环境变量

很多现代应用都依赖环境变量来配置：

env | grep APP_
printenv

特别是容器化部署的应用，环境变量配置错误是常见的500错误原因。

网络和依赖服务问题

有时候500错误不是应用本身的问题，而是依赖的外部服务出了问题。

第三方API

现在的应用很少是完全独立的，通常都会调用各种第三方API。如果这些API出问题了，也可能导致应用报500错误。

我建议在调用第三方API的时候一定要做好异常处理和超时设置：

import requests
from requests.exceptions import RequestException, Timeout

try:
    response = requests.get(api_url, timeout=5)
    response.raise_for_status()
except Timeout:
    # 处理超时，返回默认值或降级处理
    return default_response
except RequestException as e:
    # 处理其他请求异常
    logger.error(f"API调用失败: {e}")
    return error_response

内部服务依赖

如果是微服务架构，要检查各个服务之间的调用是否正常：

curl -I http://internal-service:8080/health
telnet internal-service 8080

我遇到过一次，用户服务突然开始报500，排查了半天发现是依赖的订单服务挂了。这种情况下，最好是有熔断机制，避免级联故障。

DNS解析

有时候DNS解析出问题也会导致服务调用失败：

nslookup your-service-domain
dig your-service-domain

我见过有些公司内部DNS服务器不稳定，偶尔会解析失败，导致应用无法连接到数据库或者其他服务。

实战案例分享

说了这么多理论，我来分享几个实际遇到的案例，希望能给大家一些启发。

案例一：Java应用内存泄漏

有一次我们的一个Spring Boot应用开始间歇性500错误，刚开始以为是偶发问题，但是随着时间推移，错误频率越来越高。

排查过程是这样的：

检查了应用日志，发现有OutOfMemoryError
用jstat查看GC情况，发现老年代内存使用率持续上升
生成heap dump进行分析，发现某个Map对象占用了大量内存
代码review发现是缓存没有设置过期策略

最后给缓存添加了LRU策略和过期时间，问题就解决了。这个案例告诉我们，缓存虽然能提高性能，但是一定要合理设置过期策略。

案例二：PHP-FPM进程不足

这是一个WordPress网站，在某次营销活动后开始频繁500错误。

排查步骤：

检查Nginx日志，发现大量"upstream timed out"
查看PHP-FPM状态，发现进程数已经达到上限
检查PHP-FPM配置，max_children设置得太小了
调整配置后重启服务，问题解决

这个案例说明容量规划很重要，要根据实际业务量来调整配置。

案例三：Python应用模块导入失败

有一次客户的一个Django应用突然开始500，但是重启后又正常了，过一段时间又开始500。

最后发现是某个Python包的版本有问题，在特定条件下会导入失败。这种间歇性的问题最难排查，需要仔细分析日志中的错误模式。

案例四：Go应用goroutine泄漏

这是一个Go写的API服务，运行一段时间后开始出现500错误。通过pprof发现goroutine数量异常增多，最后定位到某个HTTP客户端没有正确设置超时，导致goroutine一直阻塞。

案例五：Node.js事件循环阻塞

一个Node.js应用，用户反馈页面加载很慢，有时候会500。用blocked模块检测发现事件循环被阻塞，原因是某个同步文件操作阻塞了事件循环。改为异步操作后问题解决。

工具推荐

最后推荐一些我常用的排查工具：

系统监控

htop: 更好用的top
iotop: 磁盘IO监控
nethogs: 网络流量监控
dstat: 综合系统监控

日志分析

ELK Stack: Elasticsearch + Logstash + Kibana
Fluentd: 日志收集
Loki: 轻量级日志系统

应用监控

Prometheus: 指标收集
Grafana: 可视化
Jaeger: 分布式追踪
APM工具: New Relic、DataDog、Skywalking

数据库监控

pt-query-digest: MySQL慢查询分析
pgbadger: PostgreSQL日志分析
Redis监控: redis-cli --latency

这些工具都是我在实际工作中用过的，效果还不错。当然，工具只是辅助，关键还是要有正确的排查思路。

写在最后

500错误虽然让人头疼，但是只要有系统的排查思路，大部分问题都能快速定位和解决。我总结的排查步骤是：

快速定位影响范围
分析各种日志
检查系统资源
根据应用类型进行专项排查
检查数据库连接
排查配置和环境问题
检查网络和依赖服务

不同技术栈的应用有不同的排查重点，Java应用重点关注JVM内存和GC，PHP应用重点关注进程和权限，Python应用重点关注模块导入和WSGI服务器，Go应用重点关注goroutine泄漏，Node.js应用重点关注事件循环阻塞。

记住，排查问题的时候要保持冷静，按照步骤一步步来。不要一上来就乱改配置，那样可能会让问题变得更复杂。最重要的是，要从每次故障中学习，不断完善监控和预防措施。

如果这篇文章对你有帮助，别忘了点赞转发支持一下！想了解更多运维实战经验和技术干货，记得关注微信公众号@运维躬行录，领取学习大礼包！！！我会持续分享更多接地气的运维知识和踩坑经验。让我们一起在运维这条路上互相学习，共同进步！

公众号：运维躬行录

个人博客：躬行笔记

服务器500错误又来了？别慌！这份排查指南让你秒变故障终结者

前言