服务器出现故障时，人很容易先去重启服务。这样有时确实能恢复访问，却也可能把最有价值的现场一起清掉。相比不断尝试命令，我更愿意先看日志：谁在什么时间发起了请求，系统经过了哪些环节，错误最早从哪里出现。日志未必直接告诉我们答案，但通常能帮助我们把问题从“网站坏了”缩小到一个可以验证的范围。
先按时间线还原现场
排查的第一步不是搜索 error，而是确认故障大约发生在什么时候。先核对服务器时区，再从用户反馈、监控告警或自己的操作记录中确定一个时间窗口，例如前后各五分钟。随后把反向代理、应用、数据库和系统日志放到同一条时间线上观察。
单条日志往往只是一张截面。应用在 10:03 报数据库连接超时，原因可能是数据库在 10:02 重启，也可能是网络此前已经抖动。只有把前后事件连起来，才能区分最初的异常与后续的连锁反应。时间戳精确且各服务时钟一致，会让这件事容易很多。
分清级别，也别被级别牵着走
常见日志级别包括 debug、info、warn 和 error。它们能帮助筛选信息，却不代表严重程度的最终判断。某条 error 可能只是一次无效的爬虫请求，而反复出现的 warn 也可能是在提示连接池即将耗尽。
我通常先看错误附近的上下文，再观察它是否持续、是否与故障时间重合、是否影响真实请求。一次偶发超时和一分钟内出现几百次超时，含义完全不同。不要因为看到一行醒目的红色信息，就立刻把它认定为根因。
把请求日志和应用日志串起来
Web 服务器的访问日志适合回答“请求发生了什么”：来源、路径、耗时、响应状态码和返回大小。应用日志则更接近业务内部，能看到参数校验、调用外部接口、数据库查询和异常堆栈。两类日志结合，才容易形成完整路径。
状态码是很好的入口。大量 404 通常要检查链接或扫描请求；502、504 更可能与上游服务不可达或响应超时有关；500 则需要继续进入应用日志。若系统记录了 request ID 或 trace ID，可以用它跨越代理和应用检索同一次请求。没有关联 ID 的小项目，也可以临时结合时间、路径、客户端地址与用户代理进行比对，但准确性会低一些。
先复现，再逐步缩小范围
能够稳定复现的问题，往往已经解决了一半。我会记录触发条件：哪个页面、什么请求方法、是否登录、使用了什么参数，以及问题是每次出现还是偶尔出现。然后一次只改变一个条件，例如换浏览器、绕过 CDN、直接访问本机端口，或使用最小参数重新请求。
每做一步，都对照新增日志判断问题停在哪一层。如果直接访问应用正常，而经过反向代理失败，范围便缩小到代理配置、证书或上游连接；如果静态页面正常，只有涉及数据库的接口超时，就不必继续怀疑整个网络。相反，无法复现时应保留证据，避免凭猜测同时修改多个配置，最终既不知道什么起效，也很难回滚。
留下结论，也保护日志中的隐私
日志可能包含客户端地址、邮箱、会话标识、请求参数，甚至因错误配置而出现密码和令牌。排障时不要把完整日志直接贴到公开平台；分享前应删除或替换敏感字段，并限制日志文件的读取权限与保存期限。代码中也应避免记录认证信息和完整个人数据。
问题解决后，我会留下一段简短记录：现象是什么、影响范围多大、最终原因是什么、依据来自哪些日志、采取了什么修复，以及怎样防止再次发生。尤其要注明哪些异常只是伴随现象。一次排障的价值不只在于恢复服务，也在于下次遇到相似问题时，不必重新从黑暗中摸索。
日志不是判决书，更像现场留下的一串脚印。可靠的结论应当同时得到时间线、复现结果和多处证据的支持。学会慢一点阅读它们，通常比更快地重启服务更接近真正的问题。