服务器出现内部错误怎么办

服务器返回500 Internal Server Error，服务页面白屏，器出日志刷出一串看不懂的现内堆栈。这事儿我处理过不下几十次，部错大部分时候问题并不在代码本身，误办而是服务环境配置在捣乱。

先别急着翻代码。器出第一步永远是现内看日志——不是看错误信息那一行，而是部错看错误发生前最后几条正常的记录。有一次线上故障，误办日志里全是服务数据库连接超时，查了半天SQL慢查询，器出最后发现是现内隔壁团队半夜上了个定时任务，把连接池打满了。部错你盯着自己的误办代码看，永远找不到这种问题。

如果日志里什么都没留下，那就去查系统资源。`free -h`看一眼内存，`df -h`看一眼磁盘，`top`看一眼CPU。我碰到过最离谱的一次，服务器内部错误是因为日志文件把磁盘撑爆了——不是业务日志，是系统自带的cron任务每天往/var/log里写东西，写了大半年，没人清。磁盘满了，进程连临时文件都写不了，自然什么都报错。

资源没问题的话，检查一下依赖服务。数据库、缓存、消息队列，任何一个挂了，你的应用都可能报500。但这里有个坑：很多框架默认不会把下游服务的连接失败直接抛出来，而是吞掉异常返回个空值，然后你的业务代码拿着空值一顿操作，最后抛个NPE——表面上看起来是你代码的错，实际根因在别处。

还有一种情况，代码压根没跑到。请求进来，框架层就拦截了。比如Nginx配置的proxy_pass指向了一个不存在的upstream，或者负载均衡的健康检查把后端节点摘了。这种问题最气人，因为你的应用日志里干干净净，什么都没记，但用户就是看到500。这时候别犹豫，去查接入层日志，去查网关日志。

真的排查到最后，发现是代码问题——那多半是并发场景下的资源竞争。单线程测试全过，一上生产就挂。典型的像静态变量被多线程同时读写，或者SimpleDateFormat不是线程安全的。这类bug有个特征：间歇性出现，重启就好，过一阵又犯。

处理完问题，别急着收工。把当时的错误信息、排查路径、最终根因写进文档。不是为了应付考核，是下次再遇到类似情况能少走弯路。我自己的经验是，服务器内部错误有一半以上是重复踩坑——不同项目，同一个原因。

最后说句实在话，如果上面这些你都查过了还是没头绪，那就把服务重启一下。不是开玩笑，很多时候进程内部状态已经乱了，重启能清掉所有内存里的脏数据。这不算优雅，但确实管用。等业务恢复了，再慢慢深挖也不迟。