2026-11-09 18:55:54 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

502、配置不生效、日志查不到？这份雷池问题排查指南请收好

专注web防护的
专注web防护的

雷池SafeLine

2026年11月9日 09:00
浙江

去阅读

网站突然返回 502、503、504；

配置明明保存成功了，实际请求却没有变化；

控制台里有访问日志，却找不到攻击日志。

遇到这些问题，很多人的第一反应是：先重启试试。

但如果容器正在反复重启，不要继续反复手工重启，应先保留完整启动日志。开始排查前，可以先回答三个问题：

01 问题发生在哪里？

02 哪一段链路出现了异常？

03 现有日志和状态，能支持什么判断？

这篇文章整理了一套雷池问题定位的通用思路。你不需要一上来读懂所有服务，只要按照“看现象—留现场—查状态—对日志—做验证”的顺序，就能更快缩小范围。

适用对象：能够登录雷池主机，并查看 Docker、Tengine 及上游服务日志的运维人员。文中命令以常见 Docker Compose 部署为例，实际环境请以当前安装目录、Compose 配置和服务状态为准。

STEP 01

先按故障现象，找到排查入口

不同现象，对应的排查入口并不一样。

网站返回 502/503/504

优先看 Tengine 和上游服务，重点确认连接、超时以及上游响应。

配置保存成功，但实际没有生效

优先看 MGT、配置生成和 Tengine，确认新配置是否生成、语法检查是否通过、reload 是否成功。

有访问日志，但没有攻击日志

优先看 Detector 和规则配置，确认请求是否真的命中检测规则，以及当前是否为观察模式。

有攻击日志，但请求没有被拦截

重点核对策略模式、最终动作和例外规则。命中规则，不等于最终一定执行拦截。

控制台没有统计数据

重点看 Luigi、PostgreSQL 和 MGT，同时检查聚合、存储、查询时间、时区和筛选条件。

容器反复重启，或 Tengine 无法启动

先保留完整启动日志，再检查退出码、依赖服务、配置语法、端口占用和 Docker 网络。

注意：这些现象只能帮我们找到排查入口，不能直接代替日志和命令验证。某个关键词出现了，也不代表它已经是最终根因。

STEP 02

别急着重启，先把现场留下来

开始排查前，建议先记录以下信息：

问题第一次出现的时间和时区；
最近一次正常的时间；
最近一次升级、重启或配置变更的时间；
是单个应用异常，还是全部应用异常；
是所有请求失败，还是特定 URL、请求方法或客户端失败；
问题持续发生、偶发出现，还是重启后暂时恢复。

所有应用同时异常：更像公共服务、宿主机或网络问题。

只有一个 URL 异常：优先检查应用匹配、转发规则、请求特征和上游服务。

STEP 03

先看容器和公共资源是否正常

进入雷池安装目录后，可以先查看容器状态：

docker compose ps docker ps --format 'table {{.Names}}\\t{{.Status}}\\t{{.Ports}}'

重点关注这些状态：

：容器进程仍在运行，但不代表内部服务一定可用；
* healthy

：对应的健康检查已经通过；
* Restarting

：进程持续退出，又被 Docker 拉起；
* Exited

：进程已经退出，需要继续查看退出码和日志；
* 重启次数持续增加：不要反复手动重启，先保留启动日志。

再检查宿主机和 Docker 的公共资源：

df -h free -h ss -lntp docker network ls

磁盘已满，可能同时影响日志、数据库和配置生成；端口冲突，可能导致 Tengine 无法启动；容器网段与现有网络冲突，则可能让多个服务之间无法通信。

STEP 04

日志不要只看最后一条 error

收集日志时，要对准故障发生的时间段，并保留上下文。例如，可以按最近 30 分钟收集相关服务日志：

docker compose logs \\   --since 30m \\   --timestamps \\   --no-color \\   mgt tengine postgres detector luigi fvm chaos \\   > safeline-services.log

上述服务名仅为常见示例。实际排查时，请以 docker compose ps 和 docker ps 的结果为准。

不要只截取最后一条 error。建议至少保留：

错误前后的时间戳；
出现异常的服务；
完整错误文本；
可用于关联请求的 Host、URL、状态码和上游地址。

Address already in use

通常指向端口占用或重复监听，下一步应检查 ss -lntp、Tengine 配置和应用监听关系。

connection refused

目标地址通常可以到达，但对应端口没有监听，或者服务还没有就绪。

connection timed out

连接未能在超时前建立，需要继续检查路由、防火墙、目标地址以及容器内外连通性。

no live upstreams

当前没有可用的上游节点，需要核对上游列表、健康状态和生效配置。

host not found in upstream

上游域名无法解析，应检查容器内 DNS、域名解析结果和上游配置。

同一条错误，在不同时间点的含义也可能不同。启动后的几秒内出现一次 connection refused，随后服务恢复，可能只是依赖尚未就绪；运行数小时后持续出现，则要进一步检查服务退出、网络变化或资源故障。

STEP 05

三类高频问题，应该怎么查？

高频问题 01

网站打不开，或返回 502/503/504

先记录状态码、响应头、Host、URL、发生时间和页面特征。自定义错误页可能会掩盖真实来源，不能只看页面文案。

接下来做三组对照：

① 客户端访问雷池入口

↓

② 雷池宿主机访问同一个入口

↓

③ 雷池宿主机直连上游

以 HTTP 为例：

# 客户端访问雷池入口 curl -vk -H 'Host: <域名>' \\   'http://<雷池 IP>:<监听端口>/<路径>'  # 在雷池宿主机访问同一个入口 curl -vk -H 'Host: <域名>' \\   'http://127.0.0.1:<监听端口>/<路径>'  # 在雷池宿主机直连上游 curl -vk -H 'Host: <域名>' \\   'http://<上游地址>:<上游端口>/<路径>'

如果使用 HTTPS，请将 URL 改为 https，并使用 --resolve <域名>:<端口>:<目标 IP> 保留正确的域名和 SNI，避免因为测试方式不同引入新的干扰。