公司网络一出问题现场最容易先听到几个判断带宽不够、无线不稳定、DNS有问题或者出口设备把流量卡住了。这些判断都可能碰巧是对的但企业网络排错最怕凭经验“一开始就认定原因”。尤其是下面几种情况单靠测速或者 ping 网关很容易走偏• 同一个办公室里有人正常、有人明显慢• 同一台电脑有线正常切到无线后某些业务异常• 内网共享、ERP 慢但普通网页基本正常• 大部分网站正常只有少数网站或应用慢、偶发打不开• 某个终端做临时例外测试后马上恢复但其他终端仍然异常• IP 冲突不是一直发生而是隔一段时间突然掉线。我一般不会先换设备也不会先加带宽。第一步是把问题缩小到一段终端、接入、核心/网关、DNS、出口还是目标业务本身。图企业网络分段定位路径一、先判断“影响范围”不要急着判断“根因”排网络故障时我会先问几件很简单的事1. 是一个人有问题还是一批人都有问题2. 是有线、无线都异常还是只有其中一种3. 是内网业务慢还是互联网慢4. 是所有网站都慢还是只有特定网站或应用5. 最近有没有改过 VLAN、DHCP、AP、交换机上联、防火墙策略、DNS 或线路先把范围划出来后面的检查量会小很多。现象先看哪里单台电脑异常其他人正常终端 IP、网关、DNS、网卡、端口/无线接入同一区域多人同时异常接入交换机、AP、上联、VLAN、DHCP内网 ERP/共享慢互联网正常核心、服务器路径、DNS、业务端口内网正常互联网整体慢出口链路、防火墙会话、带宽利用率只有少数网站/应用异常DNS、策略命中、应用识别、HTTPS 安全检测、会话路径偶发掉线并伴随 IP 冲突DHCP 边界、静态地址、ARP/MAC这一步的目的不是得出答案而是先排除一大批不相关的方向。二、先留一份现场数据再开始改配置网络问题最麻烦的一种情况是改了几项以后问题暂时消失但回头已经说不清到底是哪一项起了作用。所以正式处理前我通常会先记录• 故障时间• 受影响用户和位置• 有线还是无线• 当前 IP、掩码、网关、DNS• 目标系统或域名• 最近一次网络或安全策略变更• 正常终端与异常终端的差异。Windows 终端先收这几项通常就够用ipconfig /allarp -aping 网关IP -n 30tracert 目标IP或域名nslookup 域名如果已经知道业务端口也可以补一个端口测试Test-NetConnection 目标IP或域名 -Port 端口我不建议一上来清缓存、重置网卡、重启交换机。先把异常状态保留下来后面才有对比依据。三、IP 冲突先从 DHCP 和静态地址边界查企业里很多 IP 冲突并不是 DHCP 服务本身“坏了”而是地址规划长期没有边界。常见情况包括• DHCP 地址池里混入了手工固定 IP• 打印机、AP、摄像头、门禁、服务器等设备用了静态 IP但没有做排除• 以前给某台设备固定过地址设备换掉后台账没有更新• DHCP 保留地址和其他静态地址重复• 不同网段迁移时旧配置没有清干净。如果怀疑冲突我会同时看三处终端当前 IP、租约时间、默认网关、DHCP Server。DHCP地址池范围、排除地址、保留地址、当前租约。交换机/终端 ARP同一个 IP 对应的 MAC 有没有变化。例如某个地址刚才解析到 MAC A过一会儿又变成 MAC B而且现场没有网关冗余、代理 ARP 等合理原因就应该继续追这个地址到底被谁占用了。arp -d 可以用来做测试但它不是解决 IP 冲突的方法。真正要处理的是地址来源。比较稳妥的做法是把地址规划固定下来• DHCP 用连续、明确的地址池• 网络设备、服务器等固定地址放在独立范围• 需要固定终端地址时优先用 DHCP 保留或统一登记• 地址调整后同步更新 IP 台账。四、ARP/MAC 表主要用来回答“这个 IP 到底在哪”ARP 和 MAC 表非常适合处理“偶发”“时好时坏”这类问题。我一般会看两件事1. 同一个 IP 的 MAC 是否异常变化如果变化没有合理原因优先查 IP 冲突、代理设备或配置错误。2. 同一个 MAC 是否在不同交换机端口间异常漂移如果一个 MAC 在两个不应该同时出现的端口之间频繁切换需要继续排查环路、错误接线、桥接设备或特殊虚拟化/冗余场景。这里不要只凭一条 MAC 漂移日志就认定是环路。无线漫游、堆叠、虚拟化、链路聚合等场景本身就可能看到地址变化必须结合拓扑和时间点判断。五、STP、上联和物理层问题要看“有没有持续证据”网络卡顿经常被归到“交换机性能不够”但现场更常见的是上联异常、物理层错误或者二层拓扑变化。核心和接入交换机建议至少看• 上联端口利用率• CRC、input error、丢包和丢弃计数• 端口速率/双工是否符合预期• STP 状态和拓扑变更次数• 是否存在广播异常• 故障时间点有没有端口 Up/Down、链路抖动。如果某个端口错误计数持续增加同时故障时间和它一致就应该继续检查网线、模块、光纤或对端接口。反过来如果端口计数干净、链路稳定就不要为了“试一下”批量换线、重启设备。这样反而容易把原始故障现场破坏掉。六、DNS 要单独验证不要看到“网站打不开”就全部归到 DNSDNS 有问题时用户看到的现象经常不是完全断网而是• 某些域名解析慢• 同一个域名偶发超时• 业务系统用 IP 能访问用名称不行• 主 DNS 正常辅 DNS 或转发路径不稳定• CNAME 链较长的站点表现更明显。可以先对比nslookup 域名nslookup 域名 内部主DNSnslookup 域名 内部辅DNS如果企业内部 DNS 还有转发器或条件转发还要继续看上游递归链路、UDP/TCP 53、转发超时和缓存状态。有一个判断比较实用IP 访问正常、名称访问异常DNS 的优先级很高但域名解析已经很快网页仍然慢就不要继续只盯着 DNS。七、只有少数网站或应用慢要把防火墙策略链单独拿出来看这一类问题最近在实际网络里比较容易遇到普通网页正常只有少数 HTTPS 网站、客户端或接口慢同一台电脑换一个接入方式、换一个 IP 后表现还不一样。如果对某个测试 IP 做了临时例外/旁路对比访问马上恢复这个结果很有价值。它说明问题更值得往策略链方向查而不是继续猜带宽。我会重点核对• 这条流量实际命中了哪条访问控制策略• 应用识别结果是否一致• URL/内容分类有没有误判或等待• HTTPS 加密流量的安全检查是否存在兼容性影响• 会话是否被重置、超时或反复重建• QoS、策略路由或双出口是否让同一业务走了不同路径• 客户端是否使用 HTTP/3、QUIC 等机制UDP 443 和 TCP 443 的表现是否不同。这里有两个处理习惯我不建议第一不要看到一个网站慢就加一个域名例外。现在一个网页或客户端通常会同时调用主站、登录、API、CDN、静态资源等多个域名。只加主域名可能当时好一点但很快又会遇到下一个依赖域名而且一直加下去也很难维护。第二不要为了验证直接把全网安全检测关闭。正确做法是选一台测试终端、一个测试 IP 或一条最小范围策略做 A/B 对比确认是哪一个模块影响以后再做针对性调整并保留原策略作为回退。临时例外是定位工具不应该变成长期解决方案。八、同一台电脑“有线正常、无线异常”其实是很好的对照条件这种现象不要急着认定是无线信号问题。同一台终端切换有线和无线后通常会同时发生几件变化• IP 地址变了• VLAN 可能变了• 网关或 DNS 可能不同• 防火墙命中的源地址/用户策略可能不同• 出口路径可能不同• 无线侧还多了 AP、射频和漫游这一层。所以我会先把两种接入方式的 ipconfig /all、路由、DNS 和策略命中结果放在一起对比。如果无线信号、时延都正常但无线 IP 做临时例外后特定网站马上恢复那么排查重点就应该向出口策略和会话链路移动而不是继续调 AP 功率。如果同一区域所有无线终端都慢、局域网 ping 也明显抖动再回头重点看 AP 上联、信道、干扰、终端密度和无线控制策略。九、我通常按这个顺序处理尽量一次只改一个变量现场已经比较乱的时候最忌讳 DHCP、交换机、防火墙、DNS 一起改。那样就算恢复也很难知道真正原因。更稳妥的顺序是1. 记录故障时间、用户、接入方式和目标业务2. 分清单终端、单区域、内网、互联网还是单站点3. 先处理明确的 IP 冲突和地址规划问题4. 再看 ARP/MAC、上联错误和 STP5. 单独验证 DNS6. 对特定网站/应用异常再核对防火墙策略命中与会话7. 只有确认出口在故障时段持续饱和才把带宽扩容列为解决方案。这个顺序不是死规定但有一个原则不变用证据缩小范围不要靠不断改配置碰运气。十、处理完以后至少做一次同条件复测网络问题“现在能用了”还不够。我一般会在接近原故障条件的时间段重新验证• 原来异常的终端是否恢复• 有线和无线的结果是否一致• ERP、共享盘、DNS 和互联网是否同时正常• DHCP 租约和 IP 台账是否还有冲突• ARP/MAC 是否稳定• 核心和上联错误计数是否继续增长• 特定网站或应用是否还依赖临时例外• 防火墙日志能不能解释最终流量走了哪条策略。生产环境做任何正式调整也建议留下四样东西改了什么、影响谁、怎么验证、什么情况下回退。网络排错最怕问题暂时消失就收工。真正处理完应该能说清楚故障发生在哪一段、用什么证据确认、改了什么以及复测为什么能证明问题已经关闭。这样下次再遇到类似的卡顿、掉线或 IP 冲突就不用重新从“是不是带宽不够”开始猜一遍。