企业官网建设流程全解析

1. 排障之前先想清楚：为什么是这10个命令

干网络运维这行十几年，我越来越觉得，排障这件事本质上不是比谁命令记得多，而是比谁的排查路径最短、最快定位到故障域。你手里攥着几十条命令，真到了客户机房或者远程跳板机上，能条件反射敲出来的，来来回回就那么十来条。这不是偷懒，是经验收敛的结果——高频命令之所以高频，是因为它们覆盖了从物理层到应用层最常见的故障面。

我见过不少刚入行的兄弟，遇到“网络不通”四个字就懵，要么上来就重启设备，要么把能敲的命令全敲一遍，输出刷了一屏，最后自己都不知道在看什么。问题出在没有建立“分层排查”的思维模型。网络排障最忌讳的就是无头苍蝇式乱撞，你得先判断故障大概落在哪一层，再选对应的命令去验证或排除。

这篇文章我打算把网络工程师运维排障里最常用的10个命令掰开揉碎讲一遍。不是那种“命令大全”式的罗列，而是结合我实际踩过的坑，讲清楚每个命令什么时候用、怎么读输出、输出异常说明什么、下一步该往哪查。涉及到的命令包括 ping、tracert/traceroute、ipconfig/ifconfig、netstat/ss、nslookup/dig、arp、route、telnet/nc、tcpdump、curl。这些命令在 Windows、Linux、macOS 上略有差异，我会分别说明。

适合谁看？刚入行的网络运维、系统管理员、技术支持，以及需要经常处理“连不上”“时通时断”“访问慢”这类问题的开发同学。如果你已经是有经验的老手，也可以看看我在“输出解读”和“避坑经验”部分有没有你还没注意到的细节。

提示：本文所有命令示例均在合法授权的自有实验环境中执行，请勿在未授权的网络环境中进行扫描或探测。

2. 第一梯队：连通性验证三件套

2.1 ping：最基础也最容易被误读的命令

ping 排第一没有任何争议。它基于 ICMP 协议，向目标发送 Echo Request，等待对方回 Echo Reply，从而判断IP 层是否可达以及往返时延。很多人以为 ping 通就代表网络没问题，ping 不通就代表网络断了，这两种理解都不准确。

先说 ping 通的情况。ping 通只能说明你的机器到目标 IP 的 ICMP 报文能来回，不代表目标服务在监听、不代表端口开放、不代表应用层正常。我遇到过太多次“ping 得通但网站打不开”的案例，最后查出来是目标服务器 80 端口没起、防火墙拦了 TCP、或者 DNS 解析错了。所以 ping 通只是排除了“IP 层完全不可达”这一种可能，别把它当成万能通行证。

再说 ping 不通。ping 不通的原因太多了：目标主机宕机、中间路由不可达、防火墙丢弃了 ICMP、目标禁 ping、源地址选错、甚至你自己网卡没配好。ping 不通不等于网络断，只等于“ICMP 这条路走不通”。这时候你要做的不是反复 ping，而是换工具、换源地址、换目标去缩小范围。

几个我常用的 ping 参数，值得记牢：

# Linux/macOS ping -c 4 192.168.1.1 # 发4个包就停，避免无限刷屏 ping -i 0.2 192.168.1.1 # 间隔0.2秒，快速探测 ping -s 1472 192.168.1.1 # 指定payload大小，配合MTU排查分片问题 ping -I eth0 192.168.1.1 # 指定源接口，多网卡环境必用 ping -M do -s 1472 目标IP # 禁止分片，探测路径MTU

:: Windows ping -n 4 192.168.1.1 ping -l 1472 192.168.1.1 ping -S 192.168.1.100 目标IP :: 指定源地址 ping -t 192.168.1.1 :: 持续ping，Ctrl+C停止

关于 MTU 探测，这里有个计算过程值得说清楚。以太网默认 MTU 是 1500 字节，其中 IP 头 20 字节、ICMP 头 8 字节，所以 payload 最大是 1500 - 20 - 8 = 1472 字节。如果你ping -s 1472能通，说明路径 MTU 至少 1500；如果提示“需要分片但设置了 DF 标志”，说明路径上某段 MTU 小于 1500，通常是 PPPoE 环境（1492）或者隧道环境。这个技巧在排查“小包能通、大包卡死”的问题时特别管用。

输出解读方面，重点看几个指标：丢包率、时延抖动、是否有 dup。丢包率持续大于 0 就要警惕，偶尔一个丢包可能是正常拥塞。时延突然从 5ms 跳到 200ms，说明路径上出现了拥塞或绕行。至于dup!这个提示，意思是收到了重复的 Echo Reply，通常意味着网络里存在环路或者重复的响应，比如有人做了 ARP 欺骗、或者链路层出现了广播风暴。我遇到过一次 dup 泛滥，最后查出来是两台交换机之间网线接成了环路，STP 没生效。

注意：有些云服务器默认禁 ping，你 ping 不通不代表机器挂了，去控制台看监控或者用 telnet 测端口更靠谱。

2.2 tracert / traceroute：看清数据包走了哪条路

ping 告诉你“通不通”，tracert 告诉你“怎么通的”。它利用 IP 头的 TTL 字段，逐跳递增 TTL，让路径上每一跳路由器回一个 ICMP 超时报文，从而画出完整路径。Windows 叫tracert，Linux/macOS 叫traceroute。

# Linux traceroute -n 8.8.8.8 # -n 不解析域名，速度快 traceroute -T -p 443 目标IP # 用TCP探测443端口，绕过ICMP封锁 traceroute -I 目标IP # 用ICMP探测

:: Windows tracert -d 8.8.8.8 :: -d 不解析域名 tracert -h 10 8.8.8.8 :: 最多10跳

读 tracert 输出，重点看三件事。第一，在哪一跳开始出现超时或延迟骤增。如果前几跳正常，第 5 跳开始全是*，说明问题大概率出在第 5 跳附近。第二，路径是否符合预期。比如你访问同城服务器，结果路径绕到了外省甚至境外，那延迟高就有解释了。第三，是否有环路。如果 IP 地址反复出现，说明路由配置有问题。

这里有个常见误区：tracert 中间某几跳显示*不代表故障。很多路由器出于安全策略不回应 ICMP 超时，但会正常转发数据。所以判断标准是最终能否到达目标，而不是中间每一跳都有响应。我一般会结合-T参数用 TCP 探测，因为很多网络对 ICMP 限速甚至丢弃，但对 TCP 443 放行。

还有一个实战技巧：带源地址 tracert。多网卡或者有多个出口的机器，默认走的路由可能不是你想要的。用traceroute -s 源IP 目标IP指定源地址，能验证特定出口的路径质量。这个在排查“走专线慢、走公网快”这类问题时非常有用。

2.3 ipconfig / ifconfig / ip：先确认自己站在哪

排障第一步永远是确认本机网络配置。你连自己 IP、网关、DNS 是什么都不知道，后面全是瞎猜。Windows 用ipconfig，Linux 老版本用ifconfig，新版本推荐ip命令。

:: Windows ipconfig /all :: 看全部网卡详情，包括MAC、DHCP、DNS ipconfig /release :: 释放DHCP ipconfig /renew :: 重新获取 ipconfig /flushdns :: 清DNS缓存，改hosts后必做

# Linux ip addr show # 看IP和网卡状态 ip route show # 看路由表 ip -s link show eth0 # 看网卡收发包统计和错误计数 ifconfig eth0 # 老命令，看RX/TX errors

我特别想强调ip -s link这个命令。它输出的RX errors、TX errors、dropped计数，能直接告诉你物理层和链路层有没有问题。如果 errors 持续增长，大概率是网线质量差、光模块故障、双工不匹配。有一次客户反馈“时通时断”，我上去一看ip -s link里 errors 每秒都在涨，换了根网线立马好了。这种问题你用 ping 和 tracert 是看不出来的，因为丢包是间歇性的。

另外，ipconfig /all里的DHCP 租约时间和DNS 服务器也值得关注。如果租约快到期且续租失败，IP 可能会变，导致连接中断。DNS 配错则会出现“能 ping 通 IP 但域名解析不了”的经典问题，也就是热搜里那个temporary failure in name resolution。

3. 第二梯队：端口与服务层排查

3.1 telnet / nc：测端口通不通的利器

ping 通只证明 IP 可达，要确认某个端口是否开放，得用 telnet 或 nc。这两个命令的本质是尝试建立 TCP 连接，连上了说明端口开放且服务在监听，连不上说明端口关闭或被防火墙拦截。

# telnet 方式 telnet 192.168.1.100 80 # nc 方式（更推荐，功能更强） nc -zv 192.168.1.100 80 # -z 只扫描不发送数据，-v 显示详情 nc -zv 192.168.1.100 20-30 # 扫描端口范围 nc -zv -w 3 192.168.1.100 443 # -w 3 超时3秒

Windows 默认没装 telnet 客户端，需要在“启用或关闭 Windows 功能”里勾选，或者用 PowerShell 的Test-NetConnection：

Test-NetConnection -ComputerName 192.168.1.100 -Port 80

这里有个关键区别要讲清楚：telnet 连不上，可能是端口没开，也可能是防火墙拦了，还可能是服务没起。怎么区分？如果 telnet 提示Connection refused，通常是目标机器可达但端口没监听（服务没起）；如果一直卡住最后Connection timed out，通常是防火墙丢包或者网络不通。这个区别在排障时能帮你快速定位是“服务问题”还是“网络问题”。

我踩过的一个坑：有次排查一个“SSH 连不上”的问题，ping 通、telnet 22 端口超时，我以为是防火墙，查了半天发现是目标机器的 sshd 配置里ListenAddress绑定了错误的网卡。所以 telnet 超时不一定就是网络设备拦的，也可能是服务端配置问题。

注意：部分系统出于安全考虑默认不安装 telnet 客户端，生产环境建议用 nc 或 ssh 替代，避免明文传输。

3.2 netstat / ss：看清本机连接状态

netstat 是老牌命令，ss 是它的现代替代品，速度更快、信息更全。它们能告诉你本机有哪些连接、监听哪些端口、连接处于什么状态。

# ss 常用组合 ss -tulnp # 看所有TCP/UDP监听端口及对应进程 ss -tan state established # 看已建立的连接 ss -tan state time-wait | wc -l # 统计TIME_WAIT数量 ss -s # 连接状态汇总

:: Windows netstat -ano :: 显示所有连接和PID netstat -ano | findstr :80 :: 过滤80端口 netstat -ano | findstr LISTENING

排障时我最常看的是TIME_WAIT 和 CLOSE_WAIT 的数量。TIME_WAIT 多是正常的，主动关闭连接的一方会进入这个状态，持续 2MSL（通常 60 秒）。但如果 TIME_WAIT 数量爆炸到几万，可能会耗尽本地端口，导致新连接建不起来。CLOSE_WAIT 多则是应用层没正确关闭连接的信号，通常是代码 bug，比如没调 close()。我遇到过一次 CLOSE_WAIT 堆积到上千，最后查出来是某个服务处理完请求后忘了关闭 socket。

另一个高频场景是端口被占用。启动服务时报Address already in use，用ss -tulnp | grep 端口号找到占用进程的 PID，再决定是 kill 还是换端口。Windows 上用netstat -ano | findstr :端口找到 PID，再去任务管理器对。

3.3 curl：应用层排障的终极武器

curl 严格来说不算“网络命令”，但在运维排障里它的使用频率极高。它能模拟 HTTP 请求，看到状态码、响应头、响应时间、重定向链路，是判断应用层是否正常的直接手段。

curl -I https://example.com # 只看响应头 curl -v https://example.com # 看完整请求响应过程 curl -o /dev/null -s -w "DNS:%{time_namelookup} 连接:%{time_connect} 首字节:%{time_starttransfer} 总计:%{time_total}\n" https://example.com curl --resolve example.com:443:1.2.3.4 https://example.com # 指定解析IP，绕过DNS

最后那个--resolve参数是我排查 DNS 问题时最常用的技巧。当你不确定是 DNS 解析错了还是服务器本身有问题，用--resolve强制指定 IP，如果通了说明是 DNS 问题，如果不通说明是服务器或网络问题。这一招能省下大量扯皮时间。

-w参数输出的时间分解也很有价值：time_namelookup是 DNS 解析耗时，time_connect是 TCP 握手耗时，time_starttransfer是首字节时间。如果 DNS 耗时特别长，说明 DNS 服务器慢或配置有问题；如果 connect 耗时长，说明网络延迟高或丢包；如果 starttransfer 耗时长，说明服务端处理慢。

4. 第三梯队：路由、ARP 与 DNS 深挖

4.1 arp：局域网排障绕不开的一环

ARP 负责把 IP 地址解析成 MAC 地址，是局域网通信的基础。很多“同网段不通”的问题，根子就在 ARP。

arp -a # 查看ARP缓存表 arp -d 192.168.1.1 # 删除某条ARP记录 arp -s 192.168.1.1 00:11:22:33:44:55 # 静态绑定

:: Windows arp -a netsh interface ip delete arpcache :: 清空ARP缓存

排障时看 ARP 表，重点确认网关的 MAC 地址是否正确。如果网关 IP 对应的 MAC 地址变了，可能是 ARP 欺骗，也可能是网关设备换了。我遇到过一次内网大面积断网，最后查出来是有人接了台路由器，LAN 口 IP 配成了网关地址，导致 ARP 冲突。用arp -a看到网关 MAC 频繁变化，基本就能锁定问题。

另外，如果arp -a里目标 IP 显示incomplete或全零 MAC，说明 ARP 请求没得到响应，可能是目标不在线、或者中间有隔离。这时候可以配合arping命令进一步确认。

4.2 route：路由表决定数据包往哪走

路由表是数据包转发的“导航地图”。本机路由配错，数据包就会走错出口，表现为“能 ping 通内网、上不了外网”或者“走错网卡导致时通时断”。

ip route show # Linux 查看路由表 route -n # 老命令 ip route get 8.8.8.8 # 查看到某目标走哪条路由，非常实用

:: Windows route print route print -4 # 只看IPv4

ip route get 目标IP这个命令我要重点推荐。它直接告诉你内核会选哪条路由、从哪个源接口出去，比你自己对着路由表算要快得多。多网卡环境下，默认路由可能走了你不期望的网卡，用这个命令一查便知。

路由排障的经典问题是默认路由缺失或冲突。如果ip route show里没有default via 网关这一条，外网肯定不通。如果有两条默认路由且 metric 相同，可能会出现负载不均或时通时断。这时候要检查是不是 DHCP 和静态配置打架了。

4.3 nslookup / dig：DNS 问题一查便知

DNS 是“能上 QQ 但打不开网页”这类问题的头号嫌疑犯。nslookup 和 dig 是排查 DNS 的标准工具。

dig example.com # 完整解析过程 dig @8.8.8.8 example.com # 指定DNS服务器 dig +short example.com # 只看结果 dig -x 1.2.3.4 # 反向解析 nslookup example.com # 交互式查询 nslookup example.com 8.8.8.8

:: Windows nslookup example.com nslookup example.com 8.8.8.8 ipconfig /displaydns :: 查看本地DNS缓存 ipconfig /flushdns :: 清缓存

排障思路是这样的：先用nslookup 域名看默认 DNS 能不能解析。如果解析失败，换nslookup 域名 8.8.8.8用公共 DNS 试。如果公共 DNS 能解析而默认 DNS 不能，说明是你配置的 DNS 服务器有问题。如果都解析不了，说明域名本身有问题或者网络到 DNS 服务器不通。

dig的输出里，重点看status字段。NOERROR是正常，NXDOMAIN是域名不存在，SERVFAIL是 DNS 服务器故障，REFUSED是被拒绝。这几个状态码能帮你快速判断问题性质。另外ANSWER SECTION里的 TTL 值也值得看，TTL 太短会导致频繁解析，影响性能。

5. 第四梯队：抓包与深度分析

5.1 tcpdump：网络排障的“显微镜”

前面所有命令都是“间接推断”，tcpdump 是“直接看包”。当其他命令都无法定位问题时，抓包是最后的手段，也是最有力的手段。

tcpdump -i eth0 -nn # 抓eth0所有包，不解析域名和端口 tcpdump -i eth0 -nn port 80 # 只抓80端口 tcpdump -i eth0 -nn host 192.168.1.100 # 只抓某主机 tcpdump -i eth0 -nn -w capture.pcap # 写入文件，用Wireshark分析 tcpdump -i eth0 -nn -c 100 # 抓100个包就停 tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-syn != 0' # 只抓SYN包

抓包的核心是过滤表达式，不然输出会淹没你。常用过滤维度有：host（主机）、port（端口）、net（网段）、协议（tcp/udp/icmp）。组合起来用and、or、not。

我排查“TCP 连接建立失败”时的标准流程：先抓 SYN 包，看有没有发出去；再看有没有 SYN-ACK 回来；如果 SYN 发出去了但没 SYN-ACK，说明被中间设备拦了或者目标没监听；如果 SYN-ACK 回来了但客户端没回 ACK，说明客户端侧有问题。这一套下来，问题基本就锁定了。

注意：tcpdump 需要 root 权限，生产环境抓包要注意磁盘空间和性能影响，建议加-c限制包数或-w写文件后离线分析。

5.2 命令组合拳：一个真实排障案例

光讲单个命令不够，我拿一个真实案例串一遍。客户反馈：“内网某台服务器访问外网时通时断，访问内网正常。”

第一步，ipconfig /all确认本机 IP、网关、DNS 配置正常。第二步，ping 网关正常，ping 外网IP时通时断，丢包率 30%。第三步，tracert 外网IP，发现第一跳网关正常，第二跳开始丢包。第四步，arp -a看网关 MAC 正常，排除 ARP 问题。第五步，ip route get 外网IP确认走的是正确网卡。第六步，tcpdump -i eth0 -nn host 外网IP抓包，发现发出的包和回来的包数量对不上，回来的少。第七步，检查网卡ip -s link，发现 TX errors 持续增长。

结论：网卡或网线物理层有问题，导致部分包发送失败。换网线后恢复正常。这个案例里，ping 和 tracert 定位了故障域，tcpdump 和 ip -s link 确认了根因。排障不是靠一个命令，而是靠命令之间的逻辑衔接。

6. 常见问题速查与避坑经验

6.1 高频问题速查表

6.2 我踩过的坑与实操心得

坑一：ping 通就以为万事大吉。前面说过，ping 通只代表 ICMP 可达。有次客户说“网络没问题，ping 都通”，结果一测端口全被防火墙拦了。所以排障一定要分层验证，IP 层、传输层、应用层逐层确认。

坑二：忽略源地址选择。多网卡机器上，ping 和 tracert 默认走的源地址可能不是你期望的。用-I（Linux）或-S（Windows）指定源接口，用traceroute -s指定源 IP，能避免很多误判。

坑三：tracert 中间跳超时就慌了。中间路由器不回 ICMP 是常态，只要最终能到达目标就没问题。判断标准是终点，不是中间每一跳。

坑四：DNS 缓存没清。改了 hosts 或者 DNS 记录后，本地缓存可能导致解析结果不对。Windows 用ipconfig /flushdns，Linux 看systemd-resolved或nscd状态，该重启就重启。

坑五：抓包不看时间戳。tcpdump 默认输出时间戳，分析时一定要结合时间看。比如 SYN 发出后 3 秒才收到 SYN-ACK，说明网络延迟高；如果一直没收到，说明被拦了。时间维度是抓包分析的关键。

坑六：生产环境乱敲命令。有些命令有副作用，比如arp -d会清缓存导致短暂中断，ip route del可能直接断网。生产环境操作前一定要确认影响范围，能只读就别写。

6.3 命令速记口诀

最后分享一个我自己总结的排查顺序口诀，方便记忆：先看自己（ipconfig/ip），再探连通（ping），后查路径（tracert），端口服务（telnet/nc），连接状态（ss/netstat），路由 ARP（route/arp），DNS 解析（nslookup/dig），抓包兜底（tcpdump），应用验证（curl）。这个顺序基本覆盖了从底层到应用层的完整排查链路，遇到问题按这个顺序走，大概率能快速定位。

这套命令和思路我在实际工作中用了很多年，从传统机房到云环境都适用。工具会更新，命令会变化，但分层排查、逐层验证的核心逻辑不会变。把这条逻辑刻进脑子里，比背一百条命令都管用。