企业官网建设流程全解析

1. 从“能上网”到“会排查”，差的是一套分层的脑子

今天抽空把最近整理的网络排查笔记重新捋了一遍，标题就叫“记一下”，因为它确实不是什么体系化的教程，更多是我在实际工作中踩坑、试错、查资料之后留下的记录。但整理完发现，这些散落的知识点串起来之后，恰恰能回答一个很核心的问题：为什么明明“能上网”，出问题的时候却连问题出在哪都不知道。

先说我能做什么。这篇文章覆盖的内容包括：网络分层的底层逻辑、日常排查工具的详细用法、IP地址与子网的快速计算、Wireshark抓包看TCP握手、以及几类最常见的断网故障的完整排查实录。适合谁看？如果你平时的工作要碰网络——不管是运维、开发、测试，还是经常被亲戚朋友喊去修路由器的“IT热心人”，这篇都能给你一套可以照着做的排查思路。别说你都会，真正遇到“微信能发但网页打不开”这种问题时，很多人第一反应是清缓存，而不是先判断是DNS、MTU还是代理的锅。

网络这东西，表面上是“插根网线就能用”，但一旦出问题，入口其实只有两三条：物理链路、地址解析、数据转发。只要把这几个环节的排查逻辑理顺了，绝大多数问题都能在十分钟内定位到根因。这也是我写这篇笔记的初衷——把无序的经验变成有序的方法。

我自己的体会是，搞网络最忌讳一上来就“猜”。哪怕你经验再丰富，没有证据链的猜测都是玄学。真正靠谱的排查，一定是自下而上、逐层验证的，每一步都有命令输出做依据，每一步都能排除一类可能。下面我就把这套完整的方法论拆开讲。

2. 排查网络的底层逻辑：先定位，再动手

2.1 网络是分层协作的，不是一根线从头通到尾

很多非科班出身的朋友学网络，第一个卡住的概念就是“分层”。我打个比方：网络传数据就像寄快递。你写好了包裹（应用层），贴上地址（IP层），交给快递公司（传输层），快递公司开车走公路（链路层和物理层）。每一层只负责自己的事，但任何一层出了问题，包裹都到不了。

这个类比放在排查里非常重要。因为绝大多数故障，本质上是“某一层坏了”，而不同层坏掉的表现形式完全不同。比如物理层断了，表现是“完全没网”；IP层配错了，表现是“内网通外网不通”；DNS出问题，表现是“能上QQ但打不开网页”；TCP端口被封，表现是“能ping通但连不上服务”。你只有知道每一层负责什么，才能通过现象反推问题在哪一层。

具体的分层模型大家背过，OSI七层、TCP/IP四层，但我更建议你直接用TCP/IP四层来思考问题，因为实际排查看的就是这四层：链路层（网线、Wi-Fi、交换机）、网络层（IP、路由）、传输层（TCP/UDP端口）、应用层（HTTP、DNS、DHCP）。四层之间是严格的依赖关系：下层不通，上层一定不通；但下层通了，上层也未必通。

2.2 排查顺序为什么必须是“从底到顶”

知道了分层，排查顺序就呼之欲出了：从底层开始，逐层往上验证。很多新手喜欢直接抓包看应用层报文，折腾半天发现是网线松了，这就是顺序错了。先确认物理层和链路层通不通，再谈IP和端口，最后才看应用。

我总结了一个五步定位法，实测下来非常稳：第一步看物理链路状态，网线灯亮不亮、Wi-Fi信号强不强；第二步验证本机IP配置，IP、掩码、网关有没有问题；第三步ping网关和公网地址，确认网络层是否通；第四步查DNS解析，看域名能不能正确解析成IP；第五步验证端口和服务状态，确认传输层和应用层是否正常。

每一步的命令几乎都是固定的：ipconfig、ping、nslookup、telnet、tracert。把这些命令的输出读明白，你就能像医生看化验单一样，一项项排除病因。我见过最典型的案例是：某台服务器从外地迁回来后，应用一直报超时，所有人都在调应用配置，最后我用tracert一看，数据包到运营商骨干网就断了，纯粹是路由绕路的问题，跟应用半毛钱关系没有。

3. 高频排查工具：ping、tracert、DNS解析的进阶用法

3.1 ping不只是“通不通”，延迟和丢包才是关键

ping可能是大家用得最多的命令，但大多数人只会在“通”和“不通”之间判断，浪费了大量信息。实际上，ping输出里的延迟（time）和丢包率（loss）才是真正有价值的指标。

延迟高意味着链路质量差。比如内网ping网关延迟在1ms左右是正常的，如果到了10ms甚至更高，说明链路存在拥塞或者无线干扰。丢包则更严重，丢包率超过1%就值得警惕，超过5%基本可以断定链路不稳定。我在排查网络卡顿问题时，第一件事就是在服务器上持续ping网关和公网IP各100个包，对比两者的延迟和丢包率，就能快速区分是内网问题还是运营商问题。

ping的命令参数也值得记一下，Windows和Linux略有差异。Windows下ping -t是持续ping，ping -n 100是发100个包；Linux下对应的是ping -c 100。还有个大坑：默认ping包很小，测不出带宽瓶颈，真要测大流量下的稳定性，用ping -l 1400（Windows）或ping -s 1400（Linux）来模拟接近MTU上限的包，这样才能暴露出分片或者MTU不匹配的问题。

注意：ping通不代表服务正常。ICMP协议和业务端口是两回事，很多服务器禁ping但服务完全正常。判断服务是否可用，必须验证具体端口，后面会细说。

3.2 tracert/traceroute：定位“断在哪一跳”

当ping公网IP不通时，下一步就该用tracert（Windows）或traceroute（Linux）了。它的原理是利用IP包的TTL（生存时间）字段，每经过一个路由器TTL减一，当TTL减为0时路由器会返回一个ICMP超时消息，这样就能逐跳记录路径。

tracert的作用非常直接：如果数据包在内网就断了（比如卡在网关那一跳），问题在自己这边；如果前几跳正常、到运营商骨干网断了，很可能就是运营商线路问题；如果全部超时，则要考虑防火墙封了ICMP或者路由黑洞。我遇到过一种很有意思的情况：tracert到了第10跳开始全是*，但最终目的地其实是通的，这就是因为中间路由器不响应ICMP，属于正常现象，别被吓到。

tracert还有一个冷门但实用的功能：看路由绕路。正常情况从国内访问某地，10跳左右能到；如果发现路径绕了二三十跳甚至出国再回来，延迟一定会高。做跨地域应用优化时，我经常先用tracert对比不同机房的线路质量，绕路少的那个，延迟和稳定性都会更好。

3.3 DNS解析：前端排障中最容易被忽略的环节

DNS可以说是“看起来简单、坑最多”的服务。它解决的问题只有一个：把域名翻译成IP地址。翻译失败或者翻译错误，表现非常迷惑——你以为网络不通，其实网络好好的，是“地址本”出了问题。

查DNS最基础的命令是nslookup。在Windows下输入nslookup 域名，会返回域名解析到的IP；nslookup 域名 8.8.8.8则可以指定DNS服务器来查询。这里有个关键技巧：如果本机解析不了，但用8.8.8.8能解析，说明问题出在你配置的DNS服务器上，而不是网络本身。

我遇到过最典型的DNS坑是缓存污染。某用户反馈“网站打不开”，但我用手机流量访问一切正常。一看他电脑，nslookup解析出来一个陌生的IP，明显是之前中过病毒或者手动配过错误的DNS。这种问题，清DNS缓存（ipconfig /flushdns）只是治标，要把DNS服务器改成可信的地址才治本。还有一类更隐蔽：路由器强行下发错误的DNS给所有设备，导致全家所有设备都上不了网，排查时经常被忽略。

4. IP配置与子网计算：手算比看教程快得多

4.1 为什么“/24”比“255.255.255.0”更直观

很多人配置IP时看到子网掩码是255.255.255.0，但换成/24就懵了。其实/24就是子网掩码的简化写法，它表示IP地址前24位是网络位，后8位是主机位。记住一个公式：2^(32-前缀长度) - 2就是可用IP数。比如/24，主机位是8位，可用IP是2^8-2=254个，减去的2个是网络地址和广播地址。

我在配置服务器静态IP时，最常用的三段是/24（254个IP）、/25（126个）、/30（2个）。/30在点对点链路里非常常用，刚好够一条线路两端用的IP。很多人不理解为什么不用/24省事，非要抠那点地址——在公网IP紧缺的场景下，一个/30和/24的差价可能就是几千块一个月，这不是小事。

4.2 手算子网：靠“256-掩码值”解决90%的场景

有个土办法，我用了很多年，比任何子网计算器都快：用256减去掩码的最后一个非零字节，就能得到这个子网的“块大小”。比如掩码是255.255.255.192，256-192=64，说明这个子网是每64个IP一段。0到63是一个网段，64到127是一个网段，以此类推。

举例来说，IP是192.168.1.100，掩码是255.255.255.192，那么100落在64到127这一段，网络地址就是192.168.1.64，广播地址是192.168.1.127，可用IP是65到126。整个过程30秒心算完成。这个方法在排查“IP冲突”“网段划分错误”时特别好使，因为很多配置错误都是因为网段算错了导致的。

注意：配置WAN口（连接光猫）和LAN口（连接内网）的网段时，务必让两端不在同一个子网。我见过有人把WAN口和LAN口都配成192.168.1.x，结果内网数据包的下一跳直接走错接口，造成整个网络瘫痪。这是新手配置路由器时最高频的坑，没有之一。

4.3 DHCP到底怎么选地址：从客户端视角看IP分配

静态IP适合服务器和打印机，普通设备还是交给DHCP省心。但DHCP出问题时的表现是挺迷惑的：设备显示“已连接但无法访问互联网”，或者IP地址变成了169.254.x.x。这个169.254.x.x是APIPA（自动私有IP地址），只有一种含义：设备发出DHCP请求后，没有得到服务器的响应。

排查DHCP问题时，我通常分三步：第一步确认设备能不能拿到IP，用ipconfig /release然后ipconfig /renew重新获取一次；第二步看DHCP服务器的地址池是否耗尽，很多路由器默认就分配100个IP，设备一多就遭殃；第三步检查是不是有人手动配了静态IP，和DHCP地址池冲突了。这个“静态IP和DHCP打架”的情况，在企业里天天发生，靠的是做一个规范的IP地址分配表，而不是出了问题才去查。

5. 抓包与协议分析：把看不见的流量拉到明面上

5.1 Wireshark三大过滤器，掌握这三个就能干活

抓包听起来很高大上，其实日常工作用到的功能就那么几个。Wireshark的复杂度在于它给的信息太多，反而让人不知道看什么。我的建议是先掌握三个过滤器，就能解决九成的分析需求。

第一个是IP过滤器，在过滤栏输入ip.addr == 192.168.1.100，只看指定IP的流量，适合排查单台设备的通信问题。第二个是端口过滤器，tcp.port == 443，只看某个端口的流量，适合排查服务连接问题。第三个是协议过滤器，直接输入dns、http、arp，只看对应协议的报文，适合排查DNS劫持、ARP攻击这类问题。

我举个例子。实际分析“网页很慢”的问题时，用http过滤器抓包，如果发现大量TCP重传（TCP Retransmission），基本可以判定链路丢包严重，不是服务器慢。如果看到“TCP Dup ACK”频繁出现，则说明网络存在乱序或者丢包。这些特征不看包是根本没法判断的，全靠猜的话，永远找不到真相。

5.2 三次握手到底长什么样：从抓包里认识TCP

TCP三次握手是面试必考，但只有真正在Wireshark里看过一遍，你才算学会。三次握手的过程是：客户端发SYN包，服务器回SYN+ACK包，客户端再回ACK包。在Wireshark里，这个顺序清晰可见，正常连接的标志是这三个包之间有明确的前后关系，并且源端口和目标端口正确对应。

排查连接问题时，最有效的办法就是看握手的完成度。如果只看到SYN包没有回应，说明服务器根本没收到，或者被防火墙拦了；如果看到SYN和SYN+ACK都正常，但最后的ACK没发出，问题多半出在客户端。有一次我排查两台服务器之间连接超时，抓包看到服务器回了SYN+ACK，但客户端一直没有响应，后来发现是客户端的防火墙把入站连接给拦了，典型的“单通”问题。

提示：抓包时最好使用抓包过滤器而不是显示过滤器。抓包过滤器在抓包前就生效，可以减少无用数据；显示过滤器只是暂时隐藏，数据还是占内存。比如host 192.168.1.100 and port 8080就是抓包过滤器的语法。

5.3 TCP重传与RST：两种最常见的异常信号

抓包经验多了之后，你会发现TCP异常其实就两类：重传（Retransmission）和连接重置（RST）。重传意味着包发出去了但对方没确认，可能丢了，也可能延迟太大超时了。频繁重传会带来一个直观后果：页面加载慢、文件传输效率低。判断重传严重程度有个简单标准：看抓包文件里重传包占总包数的比例，如果超过1%就要认真查链路质量了。

RST则代表连接被强制终止。两种情况最多：一是端口没服务，目标机器直接回RST表示“这里没人听电话”；二是防火墙主动干预，比如安全组规则禁止了该端口的访问。我曾经排查过一个诡异问题：内网访问某服务偶尔成功偶尔失败，抓包后发现失败时服务器回了RST，往上查发现在服务前面挂了台负载均衡，它的健康检查把异常后端的连接直接重置了。这是典型的“不是网络问题是应用架构问题”的案例，抓包一锤定音。

6. 断网故障排查实录与速查表

6.1 四个最常见场景的快速定位表

把日常工作中遇到的断网问题整理一通，我发现高频率故障基本上就四大类：单台设备无法上网、多台设备同时断网、能上内网不能上外网、能发消息但打不开网页。每种问题对应的排查起点完全不同。

这张表的价值在于它给了你一个最优先的检查项。网络故障的根因成千上万，但现象和根因之间是有强关联的，先处理概率最高的可能性，绝大多数问题可以在两分钟内解决。

6.2 案例一：电脑能上微信但打不开网页

这个案例我处理过不下十次，每次都有新发现。先说最典型的原因：DNS配置错误。微信用的是IP直连和固定的服务器端口，不走域名解析；而浏览器打开网页的第一步就是解析域名，DNS坏了，网页自然打不开。很多人一遇到这种问题就重装系统，其实一条nslookup命令就能查到真相。

排查流程是：先ping一下www.baidu.com看看能不能解析成IP，如果提示找不到主机，再用nslookup指定公共DNS解析试试。能解析就说明是本地DNS服务器问题，改一下DNS地址就好。另外还有一个隐藏原因：系统代理被修改。不少软件安装时会顺手把系统代理改成127.0.0.1:端口，如果端口没有对应服务，浏览器就开不了网页，而微信不走代理，表现就是“微信正常，网页全挂”。这种问题直接在Windows设置里关闭“使用代理服务器”即可。

6.3 案例二：无线网络频繁掉线

无线掉线是个混合型问题，涉及物理层、链路层和射频环境。我遇到最典型的场景是办公区，几十台设备挤在几个AP（无线接入点）上，2.4GHz频段信道全是邻居的路由器信号，互相干扰严重。表现是信号满格但网速很慢，时不时掉线重连。

排查无线问题，第一步是确认信道干扰。手机上装个Wi-Fi分析工具，看看周围哪些信道最拥挤，然后把AP固定到相对空闲的信道。多数人用默认配置，2.4G全挤在1、6、11这三个信道里，完全是互相伤害。第二步是检查AP的带机量。入门级家用路由器带机量可能只有10到20台，企业里一台AP接了50个终端，不卡才怪。第三步看漫游设置，如果办公区有多个AP，终端频繁在不同AP之间切换，掉线率会明显上升，这种情况要调整漫游阈值。

注意：Wi-Fi信号“满格”不等于“质量好”。信号强度和信号质量是两回事，满格可能只是离得近，但同频干扰严重的话照样卡成狗。看质量要看信噪比（SNR），一般要高于25dB才算干净。

6.4 案例三：内网一切正常，外网全部不通

这类故障多数出在网关或者路由上。我的排查顺序是：先ping网关确认内网通；再ping一个公网IP地址（比如114.114.114.114）确认有没有去外网的路由；如果公网IP能通但域名不通，问题在DNS；如果公网IP都不通，就要查NAT和默认路由。

在Windows下用route print看一下默认路由是否存在，很多时候故障原因是默认网关被改掉了——比如手动配置IP时忘了填网关，或者有设备在局域网里“抢”网关IP。在Linux服务器上则要看ip route，确认默认路由指向了正确的网关接口。另外还有一种隐蔽情况：路由器WAN口拨号断了但LAN口还是通的，表现就是“内网互访正常，出不去外网”，登录路由器看一眼拨号状态就知道了。

7. 写在最后：把每次排障都变成自己的笔记

我不是科班网工出身，这些知识全是靠一次次故障“喂”出来的。干了这些年，我最大的体会是：网络排查这个技能，真正值钱的不是背了多少协议，而是有没有一套稳定的方法论。遇到问题不慌、按层排查、用证据说话、记录下来形成自己的知识库——这套流程比任何单点知识都重要。

具体到做笔记这件事，我现在的习惯是：每次处理完一个故障，就按“现象描述、排查过程、根因分析、解决方案、预防措施”五段式记录下来，存在本地笔记里。时间久了，这就是属于你自己的故障排查手册。下次再遇到类似问题，搜一下关键词，十分钟内基本能定位。这个方法我推荐给所有做运维、开发、甚至只是喜欢折腾网络的朋友，刚开始会觉得麻烦，坚持半年后会发现自己排查效率翻了一倍不止。

最后分享一个小技巧：排查网络问题时，永远记得“一变一验”。每做一次修改，就重新验证一次现象，不要连着改三个地方再一起验证。这样即使最终修好了，你也知道到底是哪一步起了作用。这个习惯，能让你的排查记录变成真正有价值的知识积累，而不是一笔糊涂账。