1. 引子：为什么你必须懂IP
我在日常运维和项目部署里，被问到最多的问题不是"这个服务怎么装"，而是"IP到底怎么配的"、"为什么这台机器连不上那台机器"。游戏公司的后端小哥搞不定跨服通信，嵌入式工程师调不通开发板，大数据团队的作业跑不起来，最后排查到根因往往就是IP地址配错、子网掩码不对、路由表写岔了。Linux下的IP管理，是所有网络应用的基石。
这篇内容不仅讲命令怎么敲，更重要的是把IP地址、子网掩码、路由、网关这些概念的来龙去脉讲清楚，然后教你用ip命令、nmcli工具和配置文件三种方式搞定IP配置，最后我会分享几个实际排查中的经典案例。适合刚入门Linux的新手，也适合那些用了好几年ip命令但对原理含糊其辞的老手。
先停一下，你可能会想：IP基础有什么好讲的，不就是ifconfig改个地址嘛。但实际工作中，恰恰是这些"基础"决定了你能不能在短时间内定位问题。后面我会用一个实际项目的排障过程来验证这一点。
2. IP地址的核心概念与计算逻辑
2.1 IPv4地址构成与分类方式
这一小节不多说理论，你手头有台Linux机器就够了。IPv4地址32位，分成四段，每段8位，用点分十进制书写。比如192.168.1.100，看起来是四个数字，实际上它已经包含了网络部分和主机部分，关键就在这个"分界线"由什么来决定。
看个实际场景。某公司新购入一批服务器，分配给运维的一个网段是172.20.30.0/24。那这里的/24就是关键：它表示前24位是网络位，后8位是主机位。也就是说这个网段里面，可以分配给主机的地址范围是172.20.30.1到172.20.30.254，网络地址172.20.30.0和广播地址172.20.30.255不能分配。
其实在工程实践中，很少去手动换算这些位数，但你要能一眼看明白/16、/24、/28这些前缀对应的掩码和可用地址数量。/28在云厂商分配子网时很常见，它只有16个地址，可用主机地址14个。很多人申请了云服务器的子网，发现IP不够用，其实就是没算清楚这个数。
2.2 子网掩码与CIDR的实用换算
子网掩码和CIDR是一体两面。CIDR（无类别域间路由）用斜杠后跟数字来表示网络位的个数，而子网掩码就是用255.255.255.0这种形式来表达同样的信息。比如/24等同于255.255.255.0，/16等同于255.255.0.0，/29等同于255.255.255.248。
这里分享一个我的经验：在Linux下查看子网掩码，用ip addr show比用ifconfig更直观。
$ ip addr show eth0 3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:0c:29:2a:3b:4c brd ff:ff:ff:ff:ff:ff inet 192.168.10.5/24 brd 192.168.10.255 scope global eth0 valid_lft forever preferred_lft forever注意看第三行的inet 192.168.10.5/24，它直接把掩码用CIDR写法展示了出来。你不需要额外换算就知道这个地址属于192.168.10.0/24这个网段。
为什么会有人在这里踩坑呢？最常见的是两台机器，一台配192.168.10.5/24，另一台配192.168.10.6/16，看起来都在192.168.10.x范围内，但掩码不同导致它们对"网络范围"的认知不一样，路由判断就会出问题。后面排查篇我会详细讲这个案例。
2.3 广播地址、网络地址与网关的关系
网络地址是主机位全为0的地址，广播地址是主机位全为1的地址。以192.168.10.0/24为例，网络地址就是192.168.10.0，广播地址是192.168.10.255。一台机器要把数据发送给本地网段内的所有机器，就会用广播地址作为目的地址。
网关是连接不同网段的那道门。数据包要发到别的网段，必须经网关转发。网关IP通常是一个网段中第一个可用地址或最后一个可用地址，不过这并不是强制要求，只要它是本网段内的合法主机地址就可以。
我记得在老版本的Linux中，路由表里默认网关常常写作default via 192.168.10.1 dev eth0。这里的default指的是"所有不在本网段内的目的地址都走这条路由"。理解这个逻辑，你就能看懂路由表，也能理解为什么网关配置错了会导致"能Ping通同网段但上不了外网"。
3. Linux网络管理的核心命令解析
3.1 ip命令家族概览
Linux下的网络管理命令，我一直推荐ip命令。它是iproute2软件包提供的，取代了老旧的net-tools（ifconfig、route、arp这些）。ip命令的优势在于输出更清晰，而且内核版本更新后对新功能支持更好。比如你需要在网卡上添加多个IP、查看VXLAN等虚拟网络设备，用传统的ifconfig很难实现，但ip命令都能轻松胜任。
先看最基本的查询操作：
# 查看所有网卡及IP信息 ip addr show # 只查看指定网卡（例如eth0） ip addr show eth0 # 查看路由表 ip route show # 查看网卡链路状态 ip link show eth0如果你是第一次接触这些命令，我建议你直接在机器上敲一遍，对照输出内容理解。注意ip addr show eth0中，eth0可以替换成你的实际网卡名，比如ens33、enp0s3等等，不同的发行版或虚拟化环境网卡命名差异很大。
3.2 临时配置IP：ip addr add与ip route add
临时修改IP地址，在测试环境或者实验环境非常常用，重启网络服务后会失效。
# 为eth0配置IP地址和掩码 sudo ip addr add 192.168.20.10/24 dev eth0 # 删除一个IP地址 sudo ip addr del 192.168.20.10/24 dev eth0 # 配置默认网关 sudo ip route add default via 192.168.20.1 dev eth0 # 删除默认网关 sudo ip route del default via 192.168.20.1 dev eth0为什么强调这是临时配置？因为ip命令直接操作内核的网络协议栈，不会写入任何配置文件。重启机器或者重启network服务后，所有改动都会消失。如果在生产环境需要持久化配置，就必须用后面讲到的配置方式。
举一个实际场景：某开发让我帮他在一台测试服务器上加个临时IP做联调，我直接用了ip addr add 10.10.10.2/24 dev eth0，验证完联调后删掉，整个过程不影响服务器原有的网络配置，也不需要重启任何服务。这就是临时配置最大的好处：不中断现有网络连接。
3.3 ifconfig为什么还不该放弃
虽然我推荐ip命令，但不得不承认，很多老运维的心智模型中，ifconfig依然是第一反应。ifconfig eth0 192.168.10.5 netmask 255.255.255.0 up这种写法至今还能在许多旧脚本中看到。
如果你在一个全新的CentOS 8或Ubuntu 22.04环境里执行ifconfig，很可能会得到"command not found"的错误。要用ifconfig得先安装net-tools：
# Debian/Ubuntu sudo apt install net-tools # RHEL/CentOS sudo yum install net-tools我的建议是：新环境优先用ip命令，不需要额外安装任何包。但如果你的工作环境存在大量老脚本，那还是保留ifconfig的兼容知识，关键时候能看懂别人的脚本在干什么。
3.4 路由表与网关的查看及调试
路由表决定了一个数据包从本机出去后该走哪条路。查看路由表，我常用的命令是ip route，输出比route -n更简洁，但两者都能看。完整输出示例：
$ ip route default via 192.168.10.1 dev eth0 proto static metric 100 192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.5 metric 100第一行是默认路由，走eth0，网关是192.168.10.1。第二行是本机所在网段的路由，由于这个网段是直连的，所以不需要网关，标记为scope link。
我在实际排查中，第一件事永远是查看路由表和当前IP地址。如果发现"网关不通"，我会先用ping测试网关IP是否可达，再用traceroute追踪路径来判断是哪一跳出了问题。路由表里最需要注意的是多条默认路由共存的情况，有时由于配置不当，会出现多条default，数据包会选择优先级最高的那条（metric值小的优先），导致流量走向和你预期完全不一样。
4. 静态IP配置的三种可靠方式
4.1 方式一：编辑/etc/network/interfaces（Debian系）
在Debian、Ubuntu这一类系统中，传统的静态IP配置方式是编辑/etc/network/interfaces文件。我个人很推荐这种古老但极其稳定的方式，因为它纯文本，不依赖任何后台服务，出了问题直接改文件然后重启网卡就行。
来看一个完整的配置示例：
source /etc/network/interfaces.d/* auto eth0 iface eth0 inet static address 192.168.10.5 netmask 255.255.255.0 gateway 192.168.10.1 dns-nameservers 8.8.8.8 8.8.4.4配置完成后，执行sudo systemctl restart networking或者sudo ifdown eth0 && sudo ifup eth0让配置生效。
需要注意，在Ubuntu 18.04之后，系统可能默认使用netplan配置网络，此时/etc/network/interfaces的改动不一定生效。你在操作前最好用systemctl status networking确认一下服务状态，避免白改一场。
4.2 方式二：使用nmcli管理连接（NetworkManager）
现在的桌面版和很多服务器版Linux默认使用NetworkManager。nmcli是一个很强大的命令行工具，配置起来非常顺手，它管理的配置会持久化保存。
查看当前所有连接的名称和状态：
nmcli connection show比如你有一个有线连接叫Wired connection 1，你可以把它改名为office，然后配置静态IP：
# 修改连接名为office，方便管理 nmcli connection modify "Wired connection 1" connection.id office # 修改eth0的IP获取方式为手动 nmcli connection modify office ipv4.method manual # 设置IP地址和网关 nmcli connection modify office ipv4.addresses 192.168.10.5/24 nmcli connection modify office ipv4.gateway 192.168.10.1 # 设置DNS nmcli connection modify office ipv4.dns "8.8.8.8 8.8.4.4" # 激活配置 nmcli connection up office这套命令的好处是它的配置会被写入到/etc/sysconfig/network-scripts/（RHEL系）或者/etc/NetworkManager/system-connections/（Debian系）的配置文件里，重启后依然生效。而且nmcli支持从DHCP动态切换到静态，这在调试环境中特别有用。
我自己的一个小技巧是先nmcli connection show列出所有连接，确认连接名后再操作。很多新手不用这个查询命令，直接凭感觉写连接名，结果nmcli提示找不到连接。
4.3 方式三：RHEL/CentOS系配置文件
在RHEL、CentOS、Rocky Linux这些系统里，传统方式是在/etc/sysconfig/network-scripts/ifcfg-eth0文件中配置。
TYPE=Ethernet BOOTPROTO=static NAME=eth0 DEVICE=eth0 ONBOOT=yes IPADDR=192.168.10.5 NETMASK=255.255.255.0 GATEWAY=192.168.10.1 DNS1=8.8.8.8 DNS2=8.8.4.4注意这里用的参数名是IPADDR、NETMASK、GATEWAY，大小写不能错。修改后执行sudo systemctl restart network（老版本）或sudo nmcli connection reload（如果用的是NetworkManager）。
实际工作中，我发现有些云的镜像默认使用的是DHCP，你要改成静态IP一定记得把BOOTPROTO=static和ONBOOT=yes都设置好，ONBOOT=yes的意思是开机启动时自动激活该网卡。
如果是新的安装环境下，/etc/sysconfig/network-scripts/目录可能为团队采用的是NetworkManager的方式。此时直接创建ifcfg文件不一定立刻生效，需要用nmcli connection reload或干脆用nmcli方式管理。这个就需要你根据实际的系统版本灵活处理。
4.4 三种方式的选用场景对比
我在不同项目中用到的场景完全不一样。生产环境的核心服务器，我倾向于用配置文件的方式，因为它们看起来更直观，任何懂Linux的人打开文件就知道这台机器的网络配置。而集成测试环境、临时虚拟机，我更喜欢nmcli，因为修改起来不需要重启整个网络栈，影响范围更小。
有一个实际操作细节值得注意：使用ifdown和ifup重启网卡会断开当前SSH连接。如果你正在远程操作服务器，千万不要直接重启网卡，而是用ip addr add添加新IP，确认新IP可访问后再删除旧IP，这样能保证全程不掉线。
5. 网络连通性排查的实战方法
5.1 从Ping不通开始分析
排查网络问题，我习惯从最底层开始：先确认物理链路通不通，再逐层往上查。
第一步就是ping网关，看本机到网关是否通：
ping -c 3 192.168.10.1如果网关通了，再ping外网地址，比如ping -c 3 114.114.114.114或223.5.5.5。层层递进，问题就会快速收敛。
如果网关ping不通，先从ip addr show看本机是否配置了正确网段的IP，再看网卡是否处于UP状态，看网线或交换机端口灯是否正常。如果是虚拟化环境，还要确认虚拟网卡是否连接到了正确的虚拟交换机。
很多时候"ping不通"的原因其实简单到令人无语：防火墙把ICMP协议拦掉了。尤其是云服务器，安全组策略默认禁止外部ping，你在本地怎么ping都是超时，但服务器本身的服务是完全正常的。所以判断连通性时，除了ping，还要结合TCP端口的连通性测试，比如用telnet或nc去测具体的端口。
5.2 traceroute的路径分析技巧
当我需要确认数据包经过了哪些路由节点时，会用traceroute。Linux下默认使用UDP包，但在某些网络环境下UDP包可能被丢弃。可以加上-T走TCP，或者加-I走ICMP：
# 使用ICMP协议进行traceroute traceroute -I 223.5.5.5 # 使用TCP SYN包进行traceroute traceroute -T -p 80 223.5.5.5输出可能会很冗长，关键是看每一跳分别是哪台路由器。在跨机房或者跨可用区的网络问题排查中，这个命令能帮你判断瓶颈到底出现在哪一段。我曾经处理过一个"部分地区访问慢"的问题，就是用traceroute发现某一条链路的多跳都通过同一个出口，而这个出口的带宽已经跑满，因此定位到是运营商侧带宽问题。
5.3 arp命令与MAC地址学习
数据包到了同一个二层网络，最终投递依靠的是MAC地址而不是IP地址。arp命令（或ip neigh）用来查看本机的ARP缓存表，也就是IP地址与MAC地址的映射关系。
$ ip neigh show 192.168.10.1 dev eth0 lladdr 1c:99:57:aa:bb:cc REACHABLE 192.168.10.100 dev eth0 lladdr 00:1a:2b:3c:4d:5e STALE如果一个同网段的IP地址，你用ping测试通，但在ip neigh表中始终看不到对应的MAC地址（状态为FAILED或INCOMPLETE），那说明二层通信就有问题。这种情况常见于IP地址和某台机器冲突，或者交换机端口做了MAC地址过滤。
遇到ARP问题，可以用ip neigh flush all清空ARP缓存后重新测试，看现象是否变好，这个方法在实际排障时很实用。
5.4 DNS解析不出来的判断方法
很多时候你以为网络不通，其实是域名解析出了问题。排查DNS，先看本机使用的DNS服务器：
cat /etc/resolv.conf然后用nslookup或dig去测试域名解析。比如：
nslookup www.example.com或者：
dig www.example.com如果dig能解析出IP，但业务系统仍然报域名解析失败，可能是应用所在的容器或进程没有读取到正确的DNS配置。例如容器内/etc/resolv.conf不正确导致只能解析到内网域名。
实操中我遇到过最典型的问题是：系统里同时存在/etc/resolv.conf被NetworkManager或resolvconf服务接管的情况，你手动改了文件，过一会儿又被覆盖回去。解决办法是要搞清楚你系统用的是哪种DNS管理方式，再针对性修改。在Ubuntu上，可以通过systemd-resolved管理，设置/etc/systemd/resolved.conf里的DNS参数；在RHEL上，可以在网卡配置文件里写DNS1、DNS2。
6. 常见IP配置问题与排查方式
6.1 IP冲突的识别与处理
IP冲突是内网环境最常见的问题。两台机器用了同一个IP地址，会呈现间歇性网络异常：有时能通，有时突然断流。
排查方法很简单，在Linux机器上用arping去探测：
arping -I eth0 -c 3 192.168.10.5正常只有一台机器响应MAC地址，如果出现两个不同的MAC地址响应同一个IP，那几乎可以断定存在IP冲突。解决方式就是逐台机器排查，修改冲突的IP。
更好的做法是，在部署DHCP服务时做好IP地址绑定，把每台机器的MAC地址与IP固定下来，或者在分配静态IP时维护好一份地址规划表格，不要让多个部门自行随意指定IP。
6.2 掩码配置不一致导致的"假连通"
开场时提到过的掩码不一致问题，这里展开讲。A机器配置的是192.168.10.5/24，B机器配置的是192.168.10.6/16，表面上都是同一个网段内，但A机器的视角里，自己属于192.168.10.0/24，而B机器的视角里，自己属于192.168.0.0/16。
从A机器ping B机器，A会先将目标IP和自己的掩码做与运算，判断B是否在同一个网段内，如果不在就会走默认网关。但B的掩码是/16，B认为A在同一个网段内，于是直接通过二层广播去找A的MAC地址，如果二层可达，流量是能通的，但反向可能就不通。这类问题隐蔽性极高，不对比掩码很难发现。
我建议每个团队都明确网段标准和掩码规范，不使用非标准的可变长子网掩码。如果非要用，做网络变更时必须记录到配置管理文档里。
6.3 路由添加错误导致出网异常
"能ping通网关，也能ping通内网其他机器，但访问不了外网，或者访问外网特别慢"，这是特别常见的出网异常。
我举一个实际案例：某台新上架的服务器，我把它的默认网关配置成了192.168.10.2，但真正的网关是192.168.10.1。由于192.168.10.2这台机器本身可能启用了IP转发，数据包绕了一个弯，流量能出去但延迟明显偏高。后来我通过ip route show检查发现默认路由的网关写错了，改回来后瞬间恢复正常。
查看路由误区时，建议先看是否存在两条默认路由：
ip route show table main如果出现两条default，用ip route replace default via 新网关 dev eth0替换掉错误的。replace操作比先删后加更安全，它在路由不存在时会转为添加操作。
6.4 多网卡绑定与策略路由的坑
多网卡服务器上，配置策略路由是一个深水区。默认情况下，Linux系统只有一个主路由表，数据包根据目的地址决定从哪个网卡发出，但这就出现了问题：如果服务器同时连接了内网和外部网络，内网流量可能也走了默认路由出去。
解决方式是用策略路由（Policy Routing），根据源地址或者防火墙标记来匹配不同的路由表。下面是一个简单的配置示例：
# 创建两个路由表 echo "100 office" >> /etc/iproute2/rt_tables echo "200 idc" >> /etc/iproute2/rt_tables # 为每个表添加默认路由 ip route add default via 192.168.10.1 dev eth0 table office ip route add default via 10.0.0.1 dev eth1 table idc # 规则：源IP为内网段的走idc表，其他的走office表 ip rule add from 10.0.0.0/24 table idc ip rule add from 192.168.10.0/24 table office这个例子把内网来源的流量和办公来源的流量分隔开来。不过要提醒的是，策略路由在重启后会丢失，必须写入系统的路由规则文件里，或通过NetworkManager的dispatcher脚本在每次网卡激活时重新加载。
6.5 网卡命名与udev导致的配置不生效
现代Linux发行版使用可预测的网卡命名规则，网卡名可能是ens33、enp0s3、eno1等等，和传统的eth0完全不同。许多从老版本升级上来的机器，或者手动从其他机器拷贝过来的配置脚本，经常出现网卡名对不上导致配置不生效的情况。
如果你的配置文件里写的是eth0，但实际网卡名是ens33，最简单的办法是修改配置文件使用实际网卡名，或者通过内核启动参数net.ifnames=0 biosdevname=0禁用新命名规则，强制使用eth0这样的传统命名。后者需要修改GRUB配置后重启，生产环境操作时要注意风险评估。
排查这类问题时，我习惯先执行ip link show查看当前有哪些网卡，再对照配置文件。有几次"网卡起不来"的问题，最后都定位到了配置文件里的DEVICE名和实际网卡名不一致，这种低级错误很隐蔽，但排查要快。
7. 我踩过的几个实战大坑与经验总结
7.1 系统重启后配置丢失
有个阶段我在本地开虚拟机做实验，用ip addr add配好了IP，当时测试一切正常，第二天开机发现IP没了，才发现自己只用了临时命令，没写配置文件。这个经历让我的习惯转变为：所有需要靠得住的环境，一律先规划好配置方式再动手。
现在我的准则是：测试环境可以用临时命令，但记录下来操作步骤；生产环境必须用配置文件或nmcli持久化，并做好备份。任何一次网络变更，都先在测试环境验证，再克隆到生产环境做变更，出问题快速回滚。
7.2 修改配置文件时断掉远程连接的尴尬
有一次我在一台远程服务器上改/etc/network/interfaces，为了贪图方便，直接重启了networking服务。结果掉线，因为配置文件中网关写错了，而我已经无法远程连接。
从那以后，我维护了一个"网络变更黄金守则"：
- 编辑配置之前，用
screen或tmux开一个会话，防止断线后无法重新登录。 - 在云服务器上操作时，一般云控制台还提供VNC之类的带外管理入口，万一断线还能救回来。
- 修改完配置先
ip addr add新IP试通，再ip addr del旧IP，保证不中断。 - 更改前保存一份原配置文件备份，比如
cp /etc/network/interfaces /etc/network/interfaces.bak.20250101。
7.3 使用systemd-networkd时踩过的坑
某些现代系统使用systemd-networkd来管理网络。它的配置放在/etc/systemd/network/目录下面，文件后缀通常是.network。
[Match] Name=eth0 [Network] Address=192.168.10.5/24 Gateway=192.168.10.1 DNS=8.8.8.8此类方式配置完毕后，要执行systemctl restart systemd-networkd来生效。不过有一点要特别小心，systemd-networkd和NetworkManager同时存在时可能相互冲突，需要确认哪个服务在管理对应网卡。曾经遇到过一台机器，NetworkManager已经把它接管了，我改了systemd-networkd的配置，结果完全不生效，因为两台服务竞争同一网卡。
查看当前是由哪个服务管理网卡，可以用：
systemctl status NetworkManager systemctl status systemd-networkd或者查看网卡所属的子系统。比如有/run/systemd/netif/目录下的状态，或者networkctl命令输出。如果两个服务都在跑，需要停掉其中一个，避免配置互相覆盖。
7.4 容器网络和宿主机IP的关系
现在很多项目跑在容器里，容器网络的IP管理和物理机有所不同。Docker默认使用桥接网络，容器IP通常是172.17.0.x之类的地址，和宿主机不在同一个网段。这个"IP基础"的知识同样对排查容器网络的"容器之间互访不通"非常重要。
排查容器网络连通性时，先确认容器是否在同一网络（使用docker network ls查看），再进入容器内ip addr查看IP和路由。如果容器要用宿主机IP对外提供访问，就需要端口映射，而不是直接把容器IP暴露给外部。
另外一个坑是，容器内没有ping和ip命令，因为基础镜像做了裁剪。排查时可进入容器后用apt install iputils-ping或利用宿主机nsenter进入容器的网络命名空间排查。
8. 最后分享一个高效排查思路
先说一个我常用的"五层排查法"，它能有效帮助把网络问题收敛到具体层级。
- 第一层：物理层。网线、光模块、交换机端口状态。
- 第二层：链路层。
ip link查看网卡链路状态，ip neigh查看ARP表。 - 第三层：网络层。
ip addr、ping、ip route验证IP和路由。 - 第四层：传输层。用
nc或telnet测试端口连通性。 - 第五层：应用层。用
curl或相关业务工具验证服务的实际协议是否正常。
这套方法最大的好处是，"问题被卡在哪一层"一目了然。比如ping通但telnet xx 80不通，问题大概率在防火墙或服务监听地址上，而不是基础网络不通；ping不通但ip neigh能看到MAC，可能是ICMP被禁，但二层三层链路OK。
另一个实用工具是tcpdump。看包是最直接有效的排查方式，尤其在服务器上做抓包分析，几分钟就能定位到"请求有没有到本机"、"到本机后有没有回包"、"回包走了哪个网卡"等结论。示例：
sudo tcpdump -i eth0 host 192.168.10.5 and port 80 -nn抓包输出里会显示每个包的源、目的IP和端口、TCP标志位等信息。这套组合拳在实践里解决过大量的网络疑难杂症。
也许有读者会问：这些基础知识和一个普通运维、开发到底有多大关系？我可以很负责任地说，在网络链路中任何一环出了问题，如果你能快速定位到是哪一层的问题，你就比大部分人领先很多。那些排查到深夜还找不到原因的痛苦，往往就是因为在基础概念上绕了远路。希望这篇内容能帮你把Linux IP的地基打得再扎实一点。
