网页弹出http500错误页面，页面样式一般都很简单，只显示一行文字提示服务器内部错误。不少人看到这个提示第一反应就是刷新页面，还有人会怀疑是自己网络中断，或是电脑中毒。这些猜想都不对。500代表服务器处理请求时遭遇未预期故障，没办法正常返回页面内容，只能返回这条通用错误提示。绝大多数场景下，你的浏览器和网络本身不存在问题。
这个错误码不会附带详细故障信息，设计上就是为了避免外部用户看到服务器内部的运行细节。代码抛出异常没有捕获、数据库连接中断、配置文件书写错误、磁盘空间耗尽无法写入日志，这些情况都会触发500报错。偶尔刷新几次页面又能正常加载，属于偶发故障，大概率是连接池占满，或是后端服务短暂重启。一旦这个问题反复出现，就代表服务存在持续性故障。
普通访问者能采取的处理手段不多。先尝试刷新一次页面，无效就间隔几分钟再访问。如果正在提交表单或是进行付款操作，不要重复点击提交按钮，优先确认上一步操作是否已经提交成功。服务器有可能已经完成业务处理，只是返回响应阶段出错，重复提交会引发异常。更换浏览器或者切换手机流量访问也可以尝试，但多数情况下结果不会改变，根源不在本地设备。如果网站留有联系渠道，把报错页面的链接和发生时间发给站点管理员，远比反复尝试访问有用。
网站维护人员排查500错误，首要操作就是查看日志。Nginx对应的日志文件是error.log，Apache使用error_log，PHP拥有独立错误日志，Java程序会输出堆栈信息。日志记录会标明出错文件、代码行数以及具体异常类型。如果日志仅记录500状态码，缺少详细报错内容，就需要调高日志输出级别，让程序输出完整故障信息。生产环境不对访客展示详细报错是合理做法，但日志侧必须留存完整记录。
排查故障时先判断故障范围。是全站所有页面都返回500，还是仅单个页面报错？全站故障，问题基本集中在Web服务器配置、数据库连接或是公共组件。单页面报错，故障点就在该页面代码或是其依赖的数据。再核对故障发生时间，区分是刚出现还是长期存在。刚爆发的故障，可以回想近期是否改动代码、修改配置、变更数据库密码、迁移服务器。长期存在的报错，大多是部署阶段遗留问题，比如伪静态规则书写错误、缺少必要程序扩展。
故障诱因基本分为几大类。代码层面，空指针异常、数组越界、未定义变量、函数参数传递错误，这类问题在开发环境可能仅触发警告，部署到生产环境直接抛出500。数据库层面，连接数耗尽、查询超时、数据表锁死、账号权限不足都会引发报错。文件权限方面，上传目录无写入权限、缓存目录缺失、配置文件属主配置错误。资源层面，磁盘占满、内存耗尽、句柄数量触达上限。第三方接口也会造成故障，支付、短信、对象存储这类外部服务中断，应用没有做好异常容错机制，就会一同报错。
修复故障不能只盯着应用代码。Web服务器配置错误同样会触发500，例如rewrite规则出现循环重定向、SSL证书路径填写错误、FastCGI进程超时阈值设置过小。反向代理架构下，代理层超时也会向用户返回500，但后端源站还在持续处理请求。排查时要确认请求是否成功抵达应用，从外层组件向内逐层定位。
日常可以做一些防护手段。上线前在测试环境跑完核心业务流程，不要直接修改生产环境。集中采集日志，故障发生后便于检索。数据库连接、外部接口调用这类高风险环节，增加异常捕获与降级逻辑，至少展示可读性强的提示页面，而不是直接抛出500错误。监控系统增加500错误数量告警，异常量上涨及时推送通知，不要等到用户反馈才发现故障。