服务器遭受攻击时，先看流量还是连接数？如何设置告警阈值识别异常前兆

服务器出现异常时，不能只凭“带宽变大”或“连接数变多”就判断遭到攻击。先确认异常发生在网络入口、连接建立阶段，还是应用处理阶段：入站流量突然升高，更需要先排查流量型异常；连接数快速增长、但流量不高，则要关注连接耗尽、慢连接或业务请求异常。两类指标应同时观察，先用变化幅度和持续时间识别异常，再结合系统资源、服务响应和日志判断影响范围。

排查顺序可以按“确认外部现象—看流量与连接的变化—检查系统和应用是否受压—采取低风险处置—复核告警是否恢复”推进。不要一开始就封禁来源地址或调整防火墙：正常用户高峰、任务集中执行、健康检查异常，也可能造成指标突变。

先判断异常出现在哪一层

先确认告警对应的时间段、服务器网卡、业务服务和受影响范围。对照业务访问量、发布或定时任务记录，以及同一时间段的其他服务器指标，区分单机异常和业务整体变化。若多个服务、多个实例同时出现入站流量上升，应优先核对网络入口和流量来源；若只有某个服务连接积压、响应变慢，则进一步看该服务的连接队列、线程或进程资源。

接下来对照入站流量、出站流量、连接数和请求量的变化：

流量和连接数回答的是不同问题。流量衡量单位时间内传输的数据量，连接数反映当前或一段时间内建立的会话规模。大量小连接可能几乎不占带宽，却能耗尽文件描述符、连接队列或应用处理能力；少量大流量请求则可能先把带宽占满，而连接数并不突出。

按优先级检查流量、连接和系统状态

以下命令适用于常见 Linux 系统，主要用于读取状态，不会修改网络配置。将 eth0 替换为实际网卡名；可先用 ip -br link 查看接口名称。

1. 检查网卡收发计数和当前流量趋势。

   ip -s link show dev eth0

输出中的 RX、TX 字节数是累计值，不能单独作为当前速率。连续间隔一段时间采集两次，按字节差值换算速率：每秒字节数乘以 8 得到 bit/s，再除以 1,000,000 得到十进制 Mbps。若有监控平台，应直接看按分钟或更短间隔汇总的入站、出站速率，并与过去同一业务时段比较。

如果入口流量超过线路或服务可承载范围，且业务响应同时恶化，先记录异常时间和方向，联系网络入口或主机服务提供方核对入口侧观测。主机内看到的流量可能已经受到网卡、虚拟化平台或上游限速影响，不能据此认定完整攻击规模。

1. 检查连接总量和状态分布。

   ss -s
   ss -Htan state established | wc -l
   ss -Htan state syn-recv | wc -l

ss -s 给出连接状态汇总；后两条分别统计已建立连接和等待完成握手的连接数。若 SYN-RECV 持续快速上升，且应用请求量没有同步增长，需重点检查新建连接速率、监听队列和服务端错误；如果 ESTABLISHED 很多，还要区分它们是否属于正常长连接、空闲连接或业务活跃连接。连接总数本身不等于异常，必须与服务容量和历史基线比较。

1. 核对系统是否已出现资源压力。

   uptime
   free -h

同时观察服务进程的 CPU、内存、文件描述符使用量及服务日志。若连接数上涨伴随 CPU 负载升高、内存紧张、请求超时或连接拒绝，说明异常已经影响处理能力；若系统资源平稳、业务响应正常，可能只是访问量变化，应继续观察而非立即拦截。

1. 按服务和来源核对日志。

查看同一时间段内请求量、状态码、响应时间、请求路径及来源分布。少数接口或少量来源突然占据大量请求，与全站访问量普遍增长的含义不同。日志采样、脱敏和保留策略应符合业务要求，避免为排查而长期保存不必要的个人信息。

阈值应结合基线设置

固定阈值适合发现明确的资源上限，基线阈值更适合识别异常前兆。先收集覆盖业务高峰、低谷和周期性任务的历史数据，再为每项指标设定“触发值、持续时间、恢复条件”。如果没有历史数据，可先用下表中的参考范围试运行；它们是便于起步的经验值，不是适用于所有服务器的硬标准。

阈值宜分成预警和严重告警两级。预警可以使用“超过基线且持续一段时间”的组合，给运维留下核查窗口；严重告警则应关联业务影响，例如响应超时、错误率上升或资源接近上限。单纯以连接数达到某个绝对值触发，容易在长连接业务上产生误报；仅以带宽达到某个值触发，也可能漏掉低流量但高连接压力的情况。

若使用监控平台，可将网卡字节计数器按时间窗口计算速率，再与同一时间段基线对比。例如，入站速率连续 5 分钟超过近期同一时段常态的 2 倍，同时请求错误率明显上升，触发高优先级告警。连接指标则应按服务或端口拆分，避免不同服务的连接总量相互掩盖。无论采用哪种平台，都要确认指标采样间隔、单位和标签含义一致，否则阈值比较没有意义。

根据分支采取动作

如果流量和连接数都升高：先确认业务访问是否同步增长，并查看异常集中于哪些服务、接口或时间段。如果业务量无法解释增长，保存告警曲线和相关日志，尽快核对入口侧流量与来源特征。不要仅凭某个来源请求多就直接封禁；共享出口、健康检查或正常大客户访问都可能造成来源集中。需要采取限流、过滤或入口侧防护时，应按业务负责人和服务提供方的流程操作，并先确认规则不会误伤正常访问。

如果连接数升高而流量不高：检查连接状态和服务端积压，确认连接是否集中在某个端口、某个应用或少数请求路径。若 SYN-RECV 增加，检查监听队列及握手相关错误；若 ESTABLISHED 增加，检查应用超时、空闲连接回收和连接池配置。调整超时或连接限制会影响现有业务，实施前应记录原配置、明确影响服务并准备恢复方案，避免直接提高上限掩盖资源耗尽。

如果流量升高但连接数变化不明显：检查大请求、文件传输、响应体大小和出站流量。确认是正常业务后，可评估是否需要调整业务调度或限制非关键任务；如果业务无法解释流量变化，保留时间窗口和方向信息，交由入口侧继续核查。不要把网卡累计字节数误当成实时流量，也不要仅凭流量高就认定攻击。

如果核心指标没有明显变化但服务已变慢：转查应用响应时间、错误率和依赖服务。网络攻击不是所有故障的默认解释；CPU、内存、磁盘等待或下游服务异常，都可能使连接滞留并间接推高连接数。根据监控证据定位后再处理，避免对网络规则进行无关调整。

告警降噪与修复后验证

为减少误报，可采用连续采样、分级阈值和恢复阈值：短暂尖峰只记录或低级提醒，持续异常再升级；恢复条件应略低于触发条件，避免指标在阈值附近反复告警。按业务服务、网卡和连接状态拆分告警，并为计划任务、发布窗口等已知变化设置有期限的维护抑制。抑制只影响通知，不应关闭指标采集和数据留存。

处置后至少验证以下项目：

• 入站、出站速率和连接状态是否回落到业务可解释的范围，并保持多个采样周期。
• 请求成功率、响应时间和错误率是否恢复，不能只以连接数下降作为恢复依据。
• CPU、内存、文件描述符和监听队列是否解除压力，服务日志是否仍有超时或拒绝记录。
• 告警是否按预期恢复，规则是否过宽、过窄或被维护抑制遮挡；必要时基于本次事件修订基线。

如果流量与连接同步异常且业务指标恶化，应先确认入口影响并联动处理；如果主要是连接异常，则沿连接状态和应用回收机制排查；如果网络指标正常而服务仍慢，转查应用及其依赖。只有指标恢复、业务验证通过且告警规则仍能识别下一次异常，才算完成处置。