企业官网建设流程全解析

简介：《计算机网络故障诊断与排除》第1讲课件《网络故障和网络诊断测试工具》由黎连业主编，配套清华大学出版社同名教材，面向网络管理员、IT运维人员和高校网络专业学习者。课件详细讲解网络故障的七层分布与十类诱因，包括物理层硬件损坏、数据链路层配置错误、路由协议故障、DDoS攻击、管理员差错及海量存储问题等，同时介绍ipconfig、ping、tracert、netstat、nslookup等常用测试命令，并梳理网络故障管理、诊断、定位及测试工具的整体框架。资源为单份pptx演示文稿，压缩包427KB，体量轻巧、重点突出，适合用于课前预习、课堂讲解或自学复习。已有133人学习，可用于快速建立网络故障排查的完整知识脉络。

1. 网络故障诊断与排除：先分清“是设备坏了还是链路疯了”

做运维和网络管理的人，最怕听到的一句话不是“网络慢了”，而是“没网了”。所谓计算机网络故障诊断与排除，本质上就是在一堆“不通”“卡顿”“丢包”的反馈里，用一套可靠的方法和称手的网络诊断测试工具，把故障点从“整个网络”缩小到“某一台设备”“某一条链路”甚至“某一个报文”。很多新手碰到断网第一反应是重启路由器，老手则会先问：只有一个人断还是所有人断？有线断还是无线也断？这个故障是突然出现还是改过配置之后出现？这些信息比任何命令都值钱。这篇文章不讲玄学，直接从常见的网络故障现象出发，给出分层排查思路、命令行工具的实操参数，以及我这些年踩过的坑。适合刚从计算机网络基础走向实际维护的人，也适合考试前想理解故障诊断本质的学生。

2. 分层的故障诊断思路：从物理层到应用层的排查顺序

2.1 为什么二层通了三层不通：先看物理，再看逻辑

网络故障诊断的起点不是“找命令”，而是“定层”。计算机网络体系结构里，OSI七层模型和TCP/IP四层模型是我们定位故障的基础。绝大多数断网问题，都可以按照“物理层→链路层→网络层→传输层→应用层”的顺序一路往上排查。如果物理层的网线都断了，后面Ping一百遍也没有意义。

我见过太多新手，电脑显示“网络电缆被拔出”，却还在那敲ipconfig。这就是没分层。正确的做法是：先确认网口状态灯亮不亮，再确认线缆、交换机端口、无线信号强度，这些都正常了，才轮到检查IP地址、网关、路由和DNS。二层通了三层不通的典型场景是：电脑能ping通同一台交换机的其他设备，却ping不通跨网段的网关。这种问题往往出在三层路由、ACL或VLAN配置上，而不是物理链路。所以第一步先把物理层和链路层排除掉，后面才谈得上“网络层故障诊断”。

2.2 一套可以直接抄的分层排查顺序（从下往上）

我在处理故障时，习惯按下面这个顺序走。它不是标准答案，但能避免你像无头苍蝇一样乱试。

1. 物理层：看设备指示灯、网线水晶头、光模块收发光功率，无线环境看信号强度。
2. 链路层：看本机ARP能不能解析到网关MAC，交换机端口有没有CRC错误包、up/down翻动。
3. 网络层：Ping网关是否通，Ping远端IP是否通，检查路由表和ACL。
4. 传输层：用telnet或nc测端口是否通，确认TCP三次握手是否完成。
5. 应用层：用nslookup解析域名，用curl或浏览器试访问，确认应用服务本身是否健康。

这套顺序对应的就是“从下往上排除法”。每一层都有一到两个关键命令。比如物理层看网卡状态用ethtool，链路层看ARP缓存，网络层用ping和tracert，传输层用Test-NetConnection（Windows）或nc（Linux），应用层用nslookup和curl。只要某一层通了，就把故障定位在上层；某一层不通，就把故障定位在这一层或下层。

2.3 记录故障信息：时间、范围、变化，比命令更重要

在动手敲命令之前，先花两分钟把故障信息记录清楚。这看起来不起眼，实际上能省掉大量重复排查。记录四件事：故障开始的时间点、影响范围（多少用户或哪些网段）、故障类型（完全不通/间歇性丢包/延迟高/只能上内网）、最近有没有做过变更（升级、换设备、改配置）。这四件事决定了你后面的排查方向。

比如“今天早上10点开始，财务部所有电脑能ping通网关但打不开网页”，这几乎已经告诉你故障在DNS或HTTP代理上，而不是链路断了。反之，“昨天晚上开始，整个办公室偶尔丢包，高峰更明显”，那多半是广播风暴、环路或者设备性能问题。没有这些背景，你拿着一堆测试工具输出也无法定位。

提示：每次排查前先问自己一句——“如果这条链路完全断了，现象应该是什么样？”带着预期去看输出，而不是看到一串乱码再猜。

3. 网络诊断测试工具怎么用才不白用：ping、tracert、arp、nslookup

3.1 ping：不只是测通断，还能测延迟、丢包和MTU

ping是网络诊断测试工具里最基础、也最容易被用歪的工具。很多人只把它当成“能不能通”的开关，实际上ping的响应时间、TTL变化、丢包率都藏着信息。先看Windows下的基础用法：

ping -t 192.168.1.1

持续ping网关，直到你按Ctrl+C停止。这是排查间歇性丢包的首选命令，因为你不知道故障什么时候触发，一直ping着才能捕捉到丢包窗口。

参数方面，Windows下常用的有：

• -n：指定发送次数，比如ping -n 100 192.168.1.1，用于快速判断丢包率
• -l：指定包大小，比如ping -l 1472 192.168.1.1，用来测MTU
• -S：指定源地址，适用于多网卡的机器
• -f：设置DF位（不分片），配合-l可以探测路径MTU

Linux下则是ping -c 100 -s 1472 -M do 192.168.1.1，M do表示禁止分片。我最常用的是探测MTU的场景。如果ping -l 1472不通，但ping -l 1400通，说明路径上某一跳MTU低于1500，这就是典型的“大包不通、小包通”故障。这种故障用普通ping（默认32字节）永远测不出来。

ping不通的时候，注意看回显区别：Request timed out表示没有回应；Destination host unreachable表示本地没有路由到达目标；TTL expired in transit表示数据包在中间某跳被丢弃。三种信息对应的排查方向完全不同。

3.2 tracert：定位路径上哪一跳在丢包

ping能告诉你“通不通”，tracert能告诉你“过了哪几跳、每跳延迟多少”。当ping百度通，ping公司服务器也通，但访问体验就是卡时，问题往往出在路径上的某一跳。

Windows命令：

tracert -d -h 15 8.8.8.8

参数说明：-d表示不解析IP为域名，速度快很多；-h 15限制最大跳数，防止路径有环路时无限跳。Linux下对应的是traceroute -n -m 15。

看输出时，关注的是每一跳的延迟和星号。如果某跳连续出现三个超时（星号），后面几跳还能通，那这一跳大概率是禁ping的防火墙设备，并不代表断链。如果某跳超时后全盘超时，那么故障大概率在这一跳。如果某跳延迟突然从10ms飙到100ms，后面的跳都跟着高，说明瓶颈在这一跳。还有一个细节：第一跳延迟高的位置，通常是你的内网有问题，先不要怪运营商。

3.3 arp与ipconfig：本地二层解析和IP配置的照妖镜

IP配置错了，网络一定不健康。排查的第一步永远是确认本机IP、掩码、网关是否正确。

ipconfig /all

看几个关键项：IPv4地址、子网掩码、默认网关、DHCP是否启用、DNS服务器。常见毛病有：IP是169.254开头的自动私有地址（说明DHCP没拿到地址），网关写错导致只能同网段内通信，DNS写成不存在的地址导致域名解析失败。

再看ARP表：

arp -a

这条命令会把本机ARP缓存的所有条目列出来。排查思路：ping一下网关，然后立刻执行arp -a，看网关IP对应的MAC地址是否在列表里，以及这个MAC地址是否符合预期。如果你发现网关IP对应的MAC地址一直在变，或者和正常时候不一样，那多半是ARP欺骗。如果是静态IP且频繁掉线，检查有没有人和你抢IP，比如一台设备的MAC被另一个IP替代。arp -d可以清空缓存，强制重新解析。

3.4 nslookup：DNS故障的独立判断

很多“上不了网”其实是“域名解析不了”。把DNS独立出来测，用nslookup就能判断。

nslookup www.example.com

看输出里的服务器和地址。如果解析失败，先确认你用的哪个DNS服务器，然后手动指定一个公共DNS再试：

nslookup www.example.com 223.5.5.5

这里的223.5.5.5是阿里DNS，国内用的多。如果指定DNS后解析正常，说明本地DNS配置有问题；如果还是失败，可能是域名本身挂了或者网络策略拦截。另一个常用模式是反查：nslookup 8.8.8.8，确认某个IP的PTR记录，用于判断邮件服务器反向解析问题。

3.5 用抓包工具做协议级验证：从“能通”到“看到通”

命令行工具看的是结果，抓包工具才能看到过程。当你怀疑“ping通但业务不通”时，最好用Wireshark抓包。比如访问网站打不开，抓包看TCP握手：如果发了很多SYN但一直没收到SYN-ACK，说明对端或中间防火墙把端口封了；如果握手成功但HTTP请求发出后没有响应，问题可能在应用层代理。

Wireshark虽然不算命令行诊断工具，但是在“网络诊断测试工具”这个标题下绕不开。实际使用中，我通常配合ping来用：先持续ping目标，同时抓包，看ICMP请求和响应是否对称。抓包时注意过滤规则，比如tcp.port == 80、icmp、arp等。不过抓包分析对新手有门槛，日常排查可以先从命令工具入手，抓包作为杀手锏。

4. 三类高频网络故障的完整排查命令串

4.1 办公室一台电脑无法上网：ping通网关但上不了外网

这是最常见的“单点故障”。现象是微信能发消息，但浏览器打不开网页，或者干脆什么都上不去。我按下面的顺序来：

# 1. 查本机IP和网关 ipconfig /all # 2. 持续ping网关，确认内网链路的稳定性 ping -t 192.168.1.1 # 3. ping一个公网IP，比如阿里DNS ping 223.5.5.5 # 4. nslookup解析一个域名 nslookup www.baidu.com

逻辑说明：第1步看配置有没有拿到正确IP；第2步如果网关不通，故障在物理链路或二层；如果网关通但是第3步不通，问题可能出在出口路由/NAT/防火墙；如果第3步通但第4步失败，那就是DNS问题；如果第4步也通了，但浏览器还是打不开，就抓包看TCP 80/443端口会话。

参数说明：ping -t是持续ping，要停就按Ctrl+C；如果想让大包通过测MTU，参考3.1节。这个案例里，我最常遇到的情况是网关通了但223.5.5.5不通，查到最后是出口防火墙把该终端的IP拉进了黑名单。所以别只盯着链路，还要看安全策略。

4.2 全网都慢：排查广播风暴与环路

全网同时变慢，先怀疑二层环路或者广播风暴。现象是ping内网网关延迟忽高忽低，交换机CPU飙升，所有用户都卡。

# 1. 看交换机端口统计，找错误包和广播包 show interface counters errors # 2. 查MAC地址表是否一跳多端口 show mac address-table count # 3. 断开疑似环路端口后，ping延迟是否恢复

不同厂商命令略有差异，但思路一致。如果交换机支持，可以执行：

show spanning-tree summary

这个命令能看当前有没有阻塞端口，如果所有端口都处于转发状态，大概率有环路。

实际排查中，我经常用一条命令快速验证环路：在核心交换机上连续ping一个终端IP，同时拔掉一根疑似成环的网线。如果延迟立刻降下来，那就是这根线造成的环路。还有一种隐蔽情况是网卡故障导致频繁发送广播包，可以用抓包工具统计广播报文占比，占比超过20%就非常可疑。

4.3 能上QQ不能开网页：DNS或TCP会话的典型问题

这个经典问题在校园网和企业网里反复出现。现象是聊天工具正常，但网页打不开，或者有的域名能打开，有的打开不了。

# 1. 直接ping公网IP，确认TCP/IP栈是否正常 ping 223.5.5.5 # 2. 用浏览器访问一个裸IP的HTTP站点（如果存在），排除代理配置问题 # 3. nslookup测试域名解析 nslookup www.example.com # 4. 用telnet测试目标站点80端口 telnet www.example.com 80

逻辑说明：聊天工具一般走自有协议和端口，如果它们正常，说明物理链路和IP连通性没有大问题。网页打不开要么是域名解析失败，要么是80/443端口被拦截，要么是代理设置错误。第2步在命令行里可以用curl -v http://某IP代替，观察能否建立HTTP连接。第3步区分DNS故障，第4步确认端口通不通。

参数说明：telnet测试80端口时，如果连接成功会进入一个空窗口，说明对端在监听；如果连接失败会提示超时或拒绝。Windows 10以上默认没装telnet，可以用Test-NetConnection www.example.com -Port 80代替，输出关键信息是TcpTestSucceeded : True/False。

5. 网络故障诊断避坑清单：现象-原因-解决对照

5.1 现象：ping不通百度，但ping通内网网关

原因：出口防火墙或路由器没有默认路由，或者NAT配置错误，也可能运营商链路中断。 解决：先ping 223.5.5.5确认公网IP通不通。如果公网IP通但域名不通，是DNS问题；如果公网IP也不通，查本机网关的下一跳和出口设备路由表，再看运营商接入设备状态。

5.2 现象：ping提示“Destination host unreachable”

原因：本地路由表里没有去往目标网段的路由，或默认网关配置错误。 解决：执行route print（Windows）或ip route（Linux）看路由表。重点检查默认路由指向的网关IP是否可达，子网掩码是否正确。如果网关本身不可达，回头查二层。

5.3 现象：tracert显示中间几跳全是星号，但最终能通

原因：中间设备禁ping或限速ICMP，不一定是故障。 解决：用tracert时加-d不要解析域名，观察星号前后的延迟变化。如果最终延迟正常，丢包很少，基本可以忽略这些星号。不要迷信“全程无星号”，很多运营商设备早就关闭ICMP响应了。

5.4 现象：网速突降，ping网关延迟正常，ping外网延迟高

原因：有可能是出口带宽跑满，或者本地有P2P下载占满并发。 解决：先查看出口设备接口流量，确认是不是带宽跑满。如果流量不高，用netstat -ano（Windows）或ss -s（Linux）看当前并发连接数，定位占用连接数的进程。我个人遇到过一次是公司一台打印机疯狂发广播包，ping网关正常，但所有上网请求都被排挤。

5.5 现象：换了新路由器后，部分设备上不了网

原因：新路由器默认网段和旧设备静态IP冲突，或者DHCP地址池不够。 解决：先看无法上网设备的IP地址是不是169.254开头，如果是，说明没拿到DHCP地址。检查路由器的DHCP地址池和旧设备手动配置的IP是否在同一网段、有没有冲突。这个问题在引入新设备时特别常见，所以每次变更前最好记录原有网络规划。

6. 把诊断命令串成可复用脚本：批量探测和结果留存

单独敲命令属于“排查一次”，想要体系化，最好把这些命令串成脚本，批量执行并输出结果。比如想在一台Windows电脑上快速生成一份网络健康状况报告，可以写一个批处理脚本：

@echo off set OUTPUT=%date:~0,4%%date:~5,2%%date:~8,2%_network_diag.txt echo === IP Configuration === >> %OUTPUT% ipconfig /all >> %OUTPUT% echo === Ping Gateway === >> %OUTPUT% ping -n 20 192.168.1.1 >> %OUTPUT% echo === Ping Public IP === >> %OUTPUT% ping -n 20 223.5.5.5 >> %OUTPUT% echo === Tracert === >> %OUTPUT% tracert -d -h 15 223.5.5.5 >> %OUTPUT% echo === DNS Test === >> %OUTPUT% nslookup www.baidu.com >> %OUTPUT% echo === ARP Table === >> %OUTPUT% arp -a >> %OUTPUT% type %OUTPUT%

脚本逻辑很简单：把ipconfig、ping、tracert、nslookup、arp的结果按顺序输出到带日期的文本文件里，方便事后对比。这里的>>是追加写，>是覆盖写，注意区分。日期变量%date:~0,4%等是按字符位置截取，不同系统时间格式可能要调整。

我实际使用时还会加一个循环，连续多次记录网关ping的丢包率：

for /l %%i in (1,1,10) do ping -n 20 192.168.1.1 >> ping_result_%%i.txt

把十轮结果分别保存，再用Excel统计平均延迟和丢包率。虽然原始，但比单次ping一下更接近真实状况。Linux下可以套ping -c 100 -i 0.2，一样能输出。

这个脚本的价值不只是“跑一遍就完事”，而是解决“故障复现时我不能总在现场”的痛点。下次再遇到同样的网络故障，先把脚本跑一遍拿到基线数据，再逐层分析。很多间歇性问题靠肉眼盯屏幕是抓不到的，留下日志才是王道。

我的习惯是每次处理完故障后，把当时的命令行输出和最终结论存成文本，按日期归档。积累半年后，回头翻一翻，你会发现大部分“新问题”不过是旧问题的变体。希望帮到你。

本文还有配套的精品资源，点击获取