高防IP接入后网站延迟上升，如何从回源日志增长和磁盘I/O排查？

网站接入高防 IP 后，用户反馈页面变慢，但源站监控未必马上显示 CPU 或内存异常。此时常见的矛盾是：外部请求的首字节时间变长，源站回源日志却明显增加，甚至同时出现磁盘空间下降、I/O 等待升高。日志增长可能是延迟的结果，也可能是重复记录、错误重试或轮转失效造成的存储压力，不能仅凭“日志变大”认定线路或磁盘就是根因。

因此，网站接入高防 IP 后延迟增加，应该检查线路还是回源配置？应先按请求耗时阶段判断：如果 DNS、TCP 连接或 TLS 握手阶段变慢，而源站本机请求和磁盘指标正常，优先核对访问链路及高防接入配置；如果连接已建立，但首字节等待变长，同时回源日志增长、磁盘 I/O 等待和日志写入高峰重合，应优先检查回源配置、源站日志策略和文件系统。两类证据都不明显时，不能把问题强行归因于线路或磁盘。

先固定测试条件，再建立故障范围

高防接入前后的性能比较，必须尽量保持以下条件一致：

• 使用相同测试节点，或至少记录测试节点所在网络环境。
• 使用相近时间段、相同域名、相同请求路径和相同协议。
• 分别测试具有代表性的静态资源和动态页面。
• 记录测试时间、请求方式、HTTP 状态码、样本次数和测试环境。
• 将外部请求耗时与源站同一时间窗口内的回源日志、服务日志和系统指标对齐。

如果没有保存接入前的基线，也不要补造“接入前后下降了多少”的结论。可以在当前业务稳定时建立一段基线，再与故障时段比较。不同测试节点、不同请求类型或不同时间段的结果，不能直接作为线路性能前后对比，也不能据此承诺所有用户都会获得相同延迟。

可以先按下表建立判断入口：

这张表只能用于确定下一步检查顺序，不能替代多次采样。一次请求、一个日志文件大小或一次 iostat 输出，都不足以单独证明根因。

第一步：用分阶段耗时判断线路还是回源

在外部测试端对网站正常域名发起请求，记录 DNS、TCP 连接、TLS 握手、首字节和总耗时。以下命令适用于安装了 curl 的 Linux、macOS 等环境；命令只发起一次普通 GET 请求，不会修改服务端状态。请将域名和路径替换为实际测试对象：

curl -sS -o /dev/null \
  -w 'http_code=%{http_code} dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s total=%{time_total}s\n' \
  'https://www.example.com/health'

建议在相同条件下连续采样，并保存每次输出及时间。重点不是只看 total，而是比较各阶段的变化：

• time_namelookup 上升时，先确认测试端解析结果是否稳定，以及解析是否指向预期的高防接入地址。
• time_connect 或 time_appconnect 上升，而首字节阶段没有额外恶化，说明耗时更多发生在连接或 TLS 握手阶段。此时应优先核对接入配置和访问链路，不要先把问题归到磁盘。
• 连接阶段接近原有水平，但 time_starttransfer 上升，说明请求建立后到收到首字节的等待变长。此时要继续核对回源是否及时到达、源站处理时间、日志写入和存储等待。
• total 上升但首字节变化不大，可能是响应传输阶段变慢。应进一步比较响应体大小和请求类型，不能仅凭总耗时判断源站磁盘异常。

time_starttransfer 是从请求开始到收到首字节的累计时间，不等于纯粹的源站处理时间。要分析阶段差异，应结合 time_connect、time_appconnect 和源站日志时间共同判断，而不是把某个字段直接当成线路延迟或磁盘延迟。

如需确认源站本机的应用处理能力，可以在源站上请求一个仅供本机访问的健康检查地址：

curl -sS -o /dev/null \
  -w 'connect=%{time_connect}s ttfb=%{time_starttransfer}s total=%{time_total}s\n' \
  'http://127.0.0.1:8080/health'

该示例仅适用于应用确实监听本机 8080 端口，且存在对应健康检查路径的情况。端口和路径必须以实际配置为准，不要因为示例而新增监听端口。

结果可以这样理解：

• 本机请求正常、外部请求首字节变长：问题更偏向接入链路、回源路径或相关配置，继续核对源站是否在预期时间收到请求。
• 本机请求也变慢，且磁盘等待或日志写入同时升高：优先排查源站系统、日志写入和存储争用。
• 本机请求和外部请求都正常，但部分页面变慢：应按请求路径区分静态资源、动态页面和特定接口，不能用健康检查结果代表所有业务请求。

高防接入前后如需对比回源表现，应使用已获准的管理方式，并保持源站访问控制不变。不要为了测试临时公开源站，也不要绕过既有安全策略直接暴露源站地址。

第二步：检查容量和 inode，确认是否已经写入受限

在源站使用以下只读命令查看文件系统类型、空间和 inode：

df -hT
df -i

先确认网站数据目录、系统日志目录、应用日志目录和临时目录分别位于哪个挂载点。df -hT 用于查看文件系统类型及空间使用情况，df -i 用于查看 inode 使用情况。

空间充足不代表文件系统一定没有写入风险。大量小文件可能先耗尽 inode，导致日志、临时文件或运行状态文件无法创建。应分别判断：

• 某个相关挂载点空间接近耗尽，且日志持续增长：日志写入可能失败，服务还可能因无法创建临时文件、缓存或状态文件而异常。
• inode 使用率很高，但容量仍有余量：优先检查大量小日志、临时文件、拆分文件或异常生成的文件。
• 空间和 inode 都正常：不能据此排除磁盘问题，还需要继续观察 I/O 等待和文件系统状态。
• 日志文件很大但请求量并未同步增加：检查单条日志是否变长、日志级别是否调整、是否存在重复记录或轮转失效。

可先统计常见日志目录和其下一级目录的占用。请根据实际路径调整命令：

sudo du -xhd1 /var/log 2>/dev/null | sort -h
sudo du -xhd1 /var 2>/dev/null | sort -h

-x 会限制在当前文件系统内统计，避免把其他挂载点混在结果中。目录特别大或业务正在受影响时，不要一开始就对整个根目录执行耗时的递归扫描，应从已确认的日志目录逐层定位。

还要排查“文件已经删除，但进程仍保持打开”的情况。此时 du 可能看不到这部分空间，而 df 仍显示空间没有释放：

sudo lsof +L1

如果输出中有体积较大的已删除文件，先确认所属进程、日志用途和影响范围，再按该服务支持的日志重开机制处理，或安排有序重启。不要直接结束未知进程。涉及重启时，应先备份配置、确认业务恢复方式，并在维护窗口内操作；如果服务支持重新打开日志，优先使用该服务规定的方式，避免影响正在处理的请求。

第三步：把磁盘 I/O 与延迟时间线对齐

当容量和 inode 没有明显异常时，继续观察设备层 I/O。以下命令需要系统已安装 sysstat：

iostat -xz 1 5

如果系统没有 iostat，应按发行版支持的方式安装，或使用现有监控平台查看，不要把“命令不存在”误判为磁盘正常。输出结果要结合设备名称及其挂载关系判断，不能把所有设备混为一谈。

重点关注：

• await：I/O 请求的平均等待时间。如果它在用户延迟升高的同一时间段持续上升，说明存储响应等待可能增加；单次读数不足以定因。
• aqu-sz：平均队列长度。它与等待时间同步升高时，可以作为设备排队的线索。
• %util：设备忙碌比例。持续接近饱和且应用等待增多时值得关注，但不能脱离设备类型、并发负载和其他指标单独下结论。
• 读写吞吐和请求量：日志写入突然增加时，写请求可能与业务数据读取或其他写入争用同一存储资源。

可以配合查看系统运行队列、内存和 I/O 等待：

vmstat 1 5

重点观察 wa 是否在延迟发生时持续升高，同时结合运行队列和可用内存分析。一次采样异常、异常时段与用户反馈不重合，或者只有单一指标变化，都不能直接证明磁盘是根因。

若 iostat 显示存储等待明显，可进一步查看进程级读写。系统已安装 pidstat 时，可以使用：

pidstat -d 1 5

如果没有该工具，应使用现有监控平台查看进程读写，不要因工具缺失而跳过判断。进程写入量大不等于它必然是根因，还要核对：

1. 该进程是否负责网站回源日志或应用日志；
2. 写入增加是否与延迟高峰重合；
3. 写入增加是请求量增加导致，还是单条日志变大、重复记录或错误重试导致；
4. 该进程和日志文件是否位于发生等待的同一挂载点。

只有当日志增量、进程写入、设备等待和外部首字节变慢在时间上相互对应，才适合把日志写入或存储争用作为主要处理方向。

第四步：从回源日志增长中找出增长来源

“回源日志文件变大”至少包含两个问题：文件增长速度是否异常，以及为什么会增长。可能原因包括请求量增加、单条记录变大、日志级别调整、多个组件重复记录，以及失败重试造成同一请求被多次记录。

先观察文件大小随时间的变化。路径必须替换为实际日志文件：

stat /var/log/nginx/access.log
sleep 60
stat /var/log/nginx/access.log

该命令等待一分钟后再次读取文件信息，不会修改日志。连续记录多次文件大小、时间和请求量，才能判断增长是否持续。若要估算增长速度，应使用同一文件在两个时刻的大小差除以时间间隔，单位可以记录为字节每秒；不要把一次文件总大小直接当成每秒写入量。

同一时间窗口内，至少核对以下内容：

• 请求数是否同步增长，是否集中在某些路径、状态码或请求类型；
• 单条日志是否变长，例如新增较多请求头、字段或错误详情；
• 同一请求是否在多个组件中各写了一份日志；
• 是否存在错误重试，导致请求量或日志条数重复增加；
• 日志级别、采集方式或轮转配置是否近期发生变化；
• 日志中的客户端地址、请求时间、状态码和请求标识，能否与应用侧记录对应。

高防接入后，源站看到的连接来源和日志中的客户端地址，可能取决于接入及回源配置。不要只根据日志里的来源地址判断请求来自哪里，应结合实际配置核对地址传递方式，并用请求时间、状态码和请求标识交叉验证。客户端地址解析不正确，会导致日志分类和请求统计失真，但这本身不能证明它造成了延迟。

还应确认“回源日志是否按预期出现”：

• 外部请求已发出，但源站在对应时间没有记录：检查回源是否到达预期源站，以及相关接入、回源配置和访问控制。
• 源站及时收到请求，但从收到请求到写入响应之间等待很长：继续看应用处理、日志写入和磁盘 I/O。
• 一个外部请求对应多条相似回源记录：核对重试、重复记录和多层日志配置，不要直接按日志条数判断真实请求量。
• 回源日志增长与外部请求量同步，且 I/O 平稳：日志变大可能只是业务请求增多，不宜直接清理或调整线路。

如果使用 Nginx，可以先通过只读命令检查配置是否有效，并查看展开后的配置：

sudo nginx -t
sudo nginx -T

nginx -T 可能输出较多内容，也可能包含不应公开的域名、路径或其他配置，应仅在受控终端查看。若服务不是 Nginx，应使用对应服务自身的配置检查方法，不要套用此命令。

如果确认日志轮转失效、文件长期未轮转，或轮转后服务仍继续写入旧文件，应先备份相关配置，记录原始内容和适用服务版本，再根据该服务支持的日志重开机制修复。不要在服务仍持有文件句柄时直接删除正在写入的日志，也不要用清空文件的方式简单“释放空间”。这可能造成日志丢失，而且不一定释放仍被进程占用的磁盘空间。

第五步：检查文件系统和内核报错

如果 I/O 等待持续升高，或者出现读写失败、文件无法创建、服务报错，应查看挂载状态和内核日志：

findmnt
dmesg -T | tail -n 100

使用 systemd 管理日志的系统，也可以查看最近一段时间的内核日志：

sudo journalctl -k --since "30 minutes ago"

重点留意与以下事项相关的记录：

• 文件系统错误；
• 块设备或 I/O 错误；
• 挂载点被切换为只读；
• 文件无法创建或写入失败；
• 日志写入进程反复报错。

如果发现文件系统报错，不要在业务运行中直接执行修复、卸载或强制重挂载操作。应先确认受影响挂载点、业务影响范围和备份状态，保留当前日志与监控证据，再依据实际文件系统和系统维护流程安排处理。涉及卸载、修复或重启时，需要提前准备恢复和回滚方案，不能照搬与文件系统不匹配的命令。

如果没有文件系统错误，但日志写入高峰与 I/O 等待高度同步，优先处理日志增长来源和不必要的重复写入。如果日志写入平稳而 I/O 仍异常，则继续核对同一设备上的其他业务读写。文件系统检查工具不应直接用于正在承载业务的挂载点，除非已确认工具和操作条件安全相容。

按证据收敛到线路、回源配置或磁盘根因

完成上述检查后，可以按以下分支做决策：

1. 连接或握手阶段变慢，源站本机请求正常，磁盘指标平稳

这类证据更偏向访问链路或高防接入配置。应对照同一测试节点的分阶段耗时、解析结果和接入配置变更，先修正已经确认的配置差异，再重复外部测试。不能因为网站接入高防 IP 后变慢，就直接清理源站日志。

1. 连接阶段正常，首字节时间变长，源站日志到达时间异常或缺少对应记录

这类现象需要优先核对回源是否到达预期源站、回源配置和源站访问控制。由于没有对应日志时，无法仅靠源站 I/O 判断请求是否真正进入应用处理阶段。修复后要重新核对外部请求与源站日志是否能够一一对应。

1. 首字节变长，本机请求也慢，I/O 等待与日志写入同时上升

优先处理日志增长或存储争用。先确认增长来源，再处理日志级别、重复记录、轮转失效或其他已确认的写入问题。变更前备份配置，变更后执行配置检查，观察服务日志，并保留回滚方式。

1. 空间或 inode 接近耗尽，并且服务出现写入失败

先确认占用目录和文件归属，再依据既定保留策略处理历史日志或临时文件。删除操作不可逆，执行前要确认备份、业务保留要求和目标路径；不确定文件用途时不要删除。若只是已删除但仍被进程打开的文件，应优先按服务支持的日志重开或有序重启方式处理。

1. 磁盘空间、inode、I/O 和文件系统都无明显异常

不要继续围绕磁盘反复操作。回到请求时间线，检查回源是否到达、应用处理耗时、服务错误和具体慢请求，必要时依据请求标识追踪单次请求。此时“日志增长”更可能是请求量或记录策略变化，需要重新核对日志内容，而不是直接判断存储故障。

修复后用同一条件验证

验证必须尽量复用排查时的条件：相同测试节点、相近时段、相同域名和请求路径、相同协议及请求方式。外部请求继续记录 DNS、连接、TLS、首字节和总耗时；源站侧同时记录同一时间范围内的：

• 回源日志是否按预期出现；
• 日志文件增量和请求量；
• 相关挂载点空间使用率和 inode 使用率；
• I/O 等待、队列和主要进程读写；
• 应用响应时间及服务错误。

至少进行多次采样，并记录时间段、样本数量和测试环境。不同节点、不同时间或不同请求类型的结果，不能直接作为修复前后的普遍性能承诺。

如果处理的是日志配置问题，成功验证应同时满足：日志增长速度与请求量相匹配、轮转按预期执行、轮转后服务写入新文件、服务不再报告写入错误。若处理的是存储争用，除首字节时间改善外，还应确认 I/O 等待回落到该主机稳定时段的水平。若只有一个指标恢复，其他异常仍然存在，说明原因树中仍有分支没有闭合。

用持续监控降低再次发生的概率

日常监控不应只关注“磁盘还剩多少”。至少应保留以下指标，并能够按时间检索：

• 相关挂载点的空间使用率和 inode 使用率；
• I/O 等待、队列变化和主要读写进程；
• 主要回源日志的文件增长速度；
• 单位时间请求数、状态码和错误数；
• 网站首字节时间及应用响应时间；
• 日志轮转是否执行成功，以及轮转后服务是否继续写入新文件。

网站再次出现延迟时，将外部请求的分阶段耗时与源站同一时间窗口的回源日志、I/O 和文件系统数据对齐。只有当时间能够对应、指标能够互相印证，才能判断问题更接近接入链路、回源配置、源站存储，还是应用处理阶段。