写这篇总结之前，我先随手翻了翻之前的几篇笔记。基础概念系列连起来看，前面已经把分层模型、以太网、交换机转发这些底子打过了，这一篇正好接上：IP地址是怎么在网络里被"用"起来的。说白了，就是回答一个很实际的问题——当你点开一个网页、连上一个服务，数据包是怎么靠IP地址一步步找到目标的。适合刚学网络的在校同学，也适合工作里经常跟网络打交道但有些细节始终没捋清楚的从业者。这一篇尽量把关键机制讲透，后面排查问题的时候能直接派上用场。

1. 先把IP地址放在整个网络体系里的位置搞清楚

1.1 IP地址解决的本质问题：端到端寻址

我们把网络通信想象成寄快递。你寄包裹的时候，快递单上要有收件人的地址。这个地址必须足够"全局可读"，邮局系统才能一级一级把包裹送过去。IP地址扮演的就是这个角色：它是网络层为每一台设备分配的逻辑地址，解决的核心问题是"这个数据包应该送到哪里"。

这里有两个字要特别注意："逻辑"。与MAC地址烧录在网卡上不同，IP地址不是硬件自带的，而是由管理员或DHCP服务器分配后写入操作系统的网络配置里的。这意味着它可以随时变更、重新规划，不受物理位置限制。你在公司里换一个工位，网线一插，可能就换了一个IP；但你网卡的MAC地址从来没有变过。所以网络层的寻址是逻辑寻址，链路层的寻址是物理寻址，二者配合才构成了完整的通信链路。

有了这个"逻辑地址"，网络设备（主要是路由器）才能做一件关键的事情：路由决策。路由器维护一张路由表，里面记录着"哪个IP段走哪个接口、下一跳是谁"。当一个数据包到达路由器时，它会提取目的IP地址，查表，然后把包转发到正确的出口。这个过程在网络世界里每时每刻都在发生，而IP地址正是路由查找的关键索引。

1.2 从组网角度看IP地址的静态配置与动态分配

实际组网时，IP地址怎么落到设备上？主要有两种方式：静态配置和动态获取。

静态配置就是管理员手动在设备的网络设置里填IP、掩码、网关。适用于服务器、网络打印机、路由器互联接口这类地址需要保持固定的场景。好处是可控性强，坏处是规模一大就非常费手，而且容易因为手误造成冲突。

动态获取靠的是DHCP（动态主机配置协议）。设备开机后发一个DHCP Discover广播，DHCP服务器收到后从地址池里挑一个空闲IP，连同掩码、网关、DNS一起发给设备，这就是所谓的DHCP Offer。整个流程走的是四次握手：Discover、Offer、Request、Ack。租约默认一般是24小时，到了续租时间设备会再发Request去更新。对终端用户来说完全无感知，但对排障来说，DHCP这条线是非常关键的排查对象。

家用的无线路由器之所以能插上就能上网，就是因为它在出厂时默认开启了DHCP服务，给你的手机电脑自动下发了一个192.168.x.x的地址。你手动改成"静态IP"反而容易出问题，这个后面在第5章会专门提。

2. IP地址的分类逻辑与地址空间划分

2.1 早期分类编址（Classful Addressing）时代的A/B/C类

在比较早的互联网设计阶段，IP地址被分成了固定几类，最常用的就是A、B、C三类。划分依据是地址的最前面几位二进制：

• A类：首位为0，网络号占8位，主机号占24位。范围从1.0.0.0到126.255.255.255，适合超大型网络，每个A类网络理论上可以容纳约1677万台主机。
• B类：前两位为10，网络号占16位，主机号占16位。范围从128.0.0.0到191.255.255.255，适合中型网络，每个网络最多约6.5万台主机。
• C类：前三位为110，网络号占24位，主机号占8位。范围从192.0.0.0到223.255.255.255，适合小型网络，每个网络最多254台主机。

这套分类在教科书里讲得非常清楚，但实际用起来问题特别明显。最典型的就是"一刀切"导致的空间浪费：一个公司可能只需要500个IP地址，但你得申请一个B类地址段，一给就是6万多，剩下的大半都闲置了。反过来，如果只有几百台设备却拿到一个C类地址段，那又根本不够用。为了解决这个供需错配，90年代业界转向了CIDR。

2.2 CIDR与VLSM：不再按类别划分，按前缀长度划分

CIDR（无类域间路由）彻底打破了A/B/C的框框。它的表示法很直接：IP地址后面加一个斜杠，斜杠后面是前缀长度，即网络部分占多少位。比如172.16.4.0/22，表示前22位是网络号，后10位是主机号。

这个写法的好处是，你可以按需“切分”地址空间。比如你向某机构申请到一段203.0.113.0/24的地址，内部就可以自行切成多个子网：/25切出2个子网，每个126台可用主机；/26切出4个子网，每个62台可用主机。这就是VLSM（可变长子网掩码）的核心思想：不搞固定大小的桶，按实际需求灵活分配。

在路由器层面，CIDR也带来了一个额外福利：路由聚合。以前要通告相邻的几个C类段，得写好几条路由；现在如果有连续的地址块，比如192.168.4.0/24、192.168.5.0/24、192.168.6.0/24、192.168.7.0/24，只要这四段的上游路由行为一致，就可以聚合通告为192.168.4.0/22。这样核心路由器的路由表数量大幅减少，转发效率明显提升。这也是我排障时喜欢把路由表"show ip route summary"看一眼的原因之一：聚合得好不好，直接影响网络的收敛速度。

2.3 公网地址与私网地址的划分逻辑

聊到IP地址就不能不提公网和私网。RFC 1918规定了三段始终不会被公网路由的私有地址范围：

这些地址可以在任何人的内网里重复使用。你家路由器用192.168.1.1，别人家路由器也可以，互相不影响，因为它们在各自的局域网里"私有"运转。问题是：访问互联网时，私网地址不能直接使用，必须经过NAT（网络地址转换）映射成公网地址。最典型的就是家用路由器做的端口多路复用——局域网里几十台设备共用一个公网IP，路由器靠端口号区分是哪个内网设备的流量。

理解这层关系，有助于以后排查很多"内网能通、外网不通"的问题：先看地址是不是私网段，再看NAT是否生效，最后查公网侧的出入方向，基本就能定位到问题点。

3. 子网掩码与网段计算

3.1 掩码的二进制本质：它其实是一把尺子

很多人对子网掩码的理解停留在"255.255.255.0就代表一个网段"，这没错，但不够。掩码真正的意义在于它定义了IP地址中哪些位属于网络号、哪些位属于主机号。掩码写成二进制，高位全是连续的1，低位全是连续的0。比如255.255.255.0写成二进制就是24个1后面跟8个0。

要判断两个IP是否在同一个网段，方法很简单：把IP地址和掩码做逐位的"与"运算，得到网络号；如果两个IP的网络号相同，它们就在同一个二层范围内，直接通信不需要经过路由器。

举个例子。IP是192.168.1.100，掩码是255.255.255.0。192.168.1.100的二进制是两组八位拼接起来，与掩码做与运算后，主机号部分清零，结果就是192.168.1.0，也就是网络号。而192.168.1.255是子网广播地址。一台主机可以用的地址范围是192.168.1.1到192.168.1.254，共254个。

这里有一个值得记住的公式：一个前缀长度为n的子网里，可用主机数等于2的(32-n)次方减去2。减去的两个地址，一个是网络号，一个是广播地址。这是配置地址和规划地址池时最基础的计算。

3.2 按需划分子网的实例：从/24切出两个子网

我们拿最常见的192.168.1.0/24来演示。假设你公司有行政和研发两个部门，想让他们各自独立、互不干扰，就需要把这个网段切成两个子网。

从/24往后借一位，变成/25，得到两个子网：

• 子网A：192.168.1.0/25，掩码255.255.255.128，可用地址1.1~1.126，广播地址1.127。
• 子网B：192.168.1.128/25，掩码255.255.255.128，可用地址1.129~1.254，广播地址1.255。

每段可用主机数从254变成126。如果你的设备数不到120台，这样切完全够用。如果还不够，就继续往后借位：/26可以切4段，每段62台主机；/27切8段，每段30台主机；/28切16段，每段14台主机。

切割过程中最需要小心的是不要把广播地址和网络号当成可用IP分配给设备。很多人配置静态IP时随手填了192.168.1.255或192.168.1.0，结果一部分设备通信异常，还一直找不到原因。这种问题在做地址规划时就要提前避开。

3.3 掩码写错导致的"假通"

掩码不匹配导致的症状非常典型：两台设备IP同段但掩码不同，其中一台认为对方不在同一个网络里，于是把发往对方的数据交给网关处理；如果网关又没有对应的转发规则，通信就直接失败。

举个实例。电脑A配置192.168.1.10/24，电脑B配置192.168.1.20/16（掩码255.255.0.0）。A认为B就在本网段，直接发ARP请求去找B的MAC地址，B收到了会回；但B用/16掩码计算后认为A在同一个大网段（192.168.0.0/16覆盖了1.10），也能直接回。这种情况下两边反而能通。真出问题的往往是更复杂的多网段环境：B认为目的IP 192.168.2.30（另一网段的设备）也在自己的/16范围内，于是直接发ARP，而实际上目的设备在路由器后面，ARP永远得不到响应，流量就卡在B这里。这种"局域网内有一台大掩码设备"造成的路由黑洞，在外派支持时遇到过不止一次。

查这种问题其实很快：在两台设备上分别看ip route或者route print，比对它们对目的地址的判定是"直连"还是"经由网关"，就能看出掩码是否出了偏差。

4. 地址解析与报文的实际流转

4.1 ARP：IP地址怎么找到MAC地址

IP地址是网络层的标识，但数据真正在以太网上传输时，靠的是MAC地址。这就需要一个"翻译"的过程，由ARP（地址解析协议）完成。

当一台主机要向同一网段的另一台主机发包时，它先查看自己的ARP缓存表。如果缓存里没有目的IP对应的MAC地址，就向整个网段发一个广播帧：谁的IP是192.168.1.20？请把你的MAC地址告诉我。对应设备收到后发现自己的IP被点名，就单播回复一个ARP应答，告知自己的MAC地址。之后发送方把这个映射关系缓存下来，后续报文直接封装目的MAC发出。

这个机制平时工作得很安静，但有几个排查要点值得记牢。第一，ARP表是会过期的，Windows默认缓存时间也就几十秒到几分钟不等，所以"ping不通，但缓存里却有对方MAC"这类矛盾时常出现，需要手动清缓存。第二，如果有人伪造ARP应答，就可能实现ARP欺骗，把流量引到错误的设备上。所以在不可信的网络环境里，对关键设备做静态ARP绑定是有必要的。第三，跨网段通信时，数据包里的目的MAC地址是网关的MAC，而不是最终目的主机的MAC。这一点初学容易混淆。

4.2 数据包跨网段时到底发生了什么

两台设备不在同一个网段时，源主机会怎么处理？它把自己的IP和掩码做与运算，得出自己的网络号；再用目的IP和掩码做与运算，得出目的网络号；两者不一致，于是判定目标在远端。此时源主机把数据包的三层目的IP写为最终目标IP，但二层帧的目的MAC写为默认网关的MAC，然后把帧发到网关。

网关路由器解开二层帧，看到三层目的IP，查路由表，确定下一跳或出接口，再做一次二层封装，发给下一跳设备。这个"解封装、查表、再封装"的过程在沿途每一跳路由器上重复执行，直到到达目标网段。到达目标网段后，路由器把数据包发给最终目标主机前，还是要靠ARP解析出目标主机的MAC地址，完成最后一跳交付。

排查跨网段不通时，我一般会分三段来看：源主机到网关通不通、沿途路由器每一跳通不通、最后一跳到目标主机通不通。用tracert（Windows）或traceroute（Linux）就能把这些跳点逐层摸出来，卡在哪一跳，问题基本就集中在哪一跳。

4.3 域名解析与IP地址的配合流程

平时我们几乎不会直接输入IP地址上网，输入的是域名。这里有一个容易被忽视却非常重要的配合关系：DNS把域名解析成IP，应用层拿着IP去建立连接，网络层再按IP寻址转发。如果DNS挂了，浏览器会报"无法解析服务器的DNS地址"，这时候即使IP网络完全正常，你也上不了网。

排障时有一个很基础但很实用的技巧：当域名解析有问题时，先ping域名看看解析出的IP是什么，再用nslookup或dig去独立验证。如果nslookup能返回正确IP但浏览器就是打不开，那问题往往在本地DNS缓存或应用层，而不在网络本身。Windows下可以用ipconfig /flushdns清空本地缓存，Linux下一般是重启systemd-resolved或nscd服务。

DNS属于应用层范畴，但它直接决定了"IP地址工作方式"这整条链路能不能跑起来。所以做网络排查时，把DNS解析放进检查清单，能省掉很多弯路。

5. 实战排查：IP地址相关的典型问题与速查方案

5.1 IP地址冲突：最经典的"翻车"现场

IP冲突几乎是内网静态IP环境里最容易碰到的问题。两台设备用了同一个IP，表现非常有趣：时通时断，或者一台能上另一台完全上不了。原因在于ARP缓存——网络里的交换机或其它主机的ARP表一会儿指向这台设备，一会儿指向那台设备，数据包自然就跟着"飘忽不定"。

排查冲突的快捷办法是在出问题的设备上执行arp -a，找到冲突IP对应的MAC地址，再逐一比对实际设备。更彻底的办法是上交换机查看接入端口的MAC地址表，找到这个IP对应的所有MAC，逐端口去定位。Windows系统碰到IP冲突时会在右下角弹窗提示，但很多精简版系统或Linux环境没有这个提示，所以还是得靠主动排查。

5.2 配置了静态IP但上不了网？先查这三项

很多人把IP从"自动获取"改成"手动填写"之后发现上不了网，而后台又看不出什么明显报错。这种场景下优先检查三个点：掩码、网关、DNS。

第一，掩码对不对。如果掩码和网关的掩码不一致，系统可能判定网关在“远端”，直接把包发给一个不存在的下一跳。第二，网关地址对不对。家用路由器一般是192.168.1.1或192.168.0.1，但也可能是别的段，比如有些定制固件是192.168.31.1。填错网关时，系统能获取到IP但出不去。第三，DNS写没写。很多手工配置只填了IP和掩码，DNS留空或者填错，结果QQ这类直连IP的软件能上，浏览器就是打不开网页。

每次看到这类问题，我的第一建议都是：如果不能明确知道自己要配什么内容，就先用回DHCP自动获取，让设备自己拿地址。这样往往能瞬间消除一多半的人为配置错误。

5.3 DHCP获取不到地址，从哪里看起

设备连上网络后拿不到IP，可能的原因很多，由浅入深排下来基本是：网线或无线信号问题、交换机端口VLAN配置问题、DHCP服务器故障、地址池耗尽、中继配置错误。

优先查看系统日志和DHCP客户端状态。Windows下用ipconfig /release再ipconfig /renew，注意观察返回信息，如果一直停留在"无法联系DHCP服务器"，大概率是二层链路或DHCP服务本身有问题。Linux下可以查看dhclient或NetworkManager的日志。另一个常见坑是：网络中如果有多个DHCP服务器且分配策略冲突，会出现"IP拿到了但时好时坏"的诡异现象。排查时可以用抓包工具过滤dhcp或bootp协议，看看设备发出的Discover有没有收到Offer，就能快速定位是哪一侧的问题。

5.4 快速自查命令速查表

把这张表贴在工位附近，遇到日常网络问题可以先按表自查一遍，很多"故障"其实都是配置层面的小问题。真正要抓包的场景，再上Wireshark去过滤arp、icmp、dhcp这些协议也不迟。

在最后多提一嘴：IP地址本身只是一个标识，真正让网络跑起来的是围绕它的整套解析、寻址、转发机制。很多看似玄学的网络故障，归根结底都是掩码算错、路由缺失、ARP混乱或者地址冲突这老几样。把这篇里的细节吃透，再配合命令行去验证，遇到问题至少心里会有一个清晰的排查顺序。我觉得对刚接触网络的同学来说，与其死背概念，不如自己在家里用两台设备搭一个最小网络，亲手配一次静态IP、看一次ARP缓存的变化，比看十遍书都印象深。