投研帮新装好的Linux系统，第一件事永远是确认网络是通的。但往往就是这一步，让很多人卡了整整一天。装好系统发现ping不通外网、域名解析失败、或者配了个静态IP结果重启后又回到原点，这些情况我几乎每周都会遇到。上一篇讲了Linux网络的基础概念，这篇"初始网络（下）"就纯讲实操：怎么查看网络状态、怎么把配置写进文件里让它永久生效、遇到不通的时候按照什么顺序排查。适合那些已经会装系统、但对配网还不太熟的读者，也适合工作中偶尔要碰Linux服务器的运维和开发。
1. 先别急着敲命令：理解Linux网络配置的"临时"与"永久"
很多人第一次接触Linux配网，拿到的教程五花八门。有的让人敲ifconfig eth0 192.168.1.100，有的让人改/etc/network/interfaces，还有的让用nmtui。结果跟着做完，当时确实生效了，重启之后又变回原样，于是开始怀疑自己操作错了，甚至重装系统。其实问题不在操作，在于没搞清楚Linux网络配置的两套机制：临时配置和永久配置。
1.1 临时配置与永久配置分别管什么
临时配置是用命令直接修改内核里的网络参数。比如ip addr add 192.168.1.100/24 dev eth0，这条命令执行后，网卡立刻会绑上这个IP地址，数据包也能正常收发。但这个改动只存在于内存里，没有写入任何文件。只要重启系统、重启网络服务、或者网卡down掉再up，这个地址就会消失。
永久配置则是把参数写进配置文件里。系统启动时或者网络服务启动时，会去读这些文件，把里面的配置加载到内核里。这才是真正"一劳永逸"的地方。
所以关键在于：你用命令改过的东西，如果想让它重启后还在，必须同时改配置文件。这不是Linux设计得麻烦，而是它的设计哲学——命令行是给人临时调试用的，配置文件才是给系统长期使用的。类比一下就是：命令行相当于你在路由器管理页面里临时改了个IP，但没点"保存"；配置文件相当于你把改好的配置存进了路由器的配置文件里，下次重启路由器它还会按这个配置来。
1.2 新装系统最容易踩的"改完就生效"误区
最容易踩的坑是这样：很多人拿到一台新装的CentOS或Ubuntu，发现DHCP拿到的地址不是自己想要的，于是直接敲命令改了个静态IP。当时看着是生效了，SSH也没断，就觉得"搞定了"。等下次机房断电重启，发现服务器起不来了——IP地址丢了，远程连不上，只能去机房接显示器和键盘。
还有一个常见误区是把ping通当成"网络配置没问题"。ping通只能说明链路层和网络层是通的，但不代表DNS配置、网关配置、路由表都是对的。我见过有人DNS写错了，ping IP地址全通，但一访问域名就超时，还以为是防火墙拦了，排查了半天。
所以在动手配网之前，先确认两件事：第一，你是要临时调试还是长期使用？第二，你的修改有没有同步到配置文件里？带着这两个问题去看后面的内容，思路会清晰很多。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 查看网络状态的几个高频命令：从ip到ss的切换
确认网络环境和配置状态，靠的是命令。但很多老教程里的命令已经被新工具替代了，照着敲会提示"command not found"。这里统一过一遍我日常最常用的查看命令，以及为什么现在都用它们。
2.1 为什么现在的教程都在用ip命令而不是ifconfig
ifconfig是好工具，但已经属于上一个时代了。它属于net-tools包，很多新装的发行版默认不装。而ip命令属于iproute2包，几乎是系统自带的。
ip命令的用法也很直观：
bash复制# 查看所有网卡的IP地址和状态
ip addr
# 只看某个网卡的信息
ip addr show eth0
# 查看路由表，确认默认网关
ip route
# 查看网卡链路状态，有没有插网线
ip link show eth0
ip route的输出里，default via 192.168.1.1 dev eth0这一行最关键。它告诉你系统的默认网关是192.168.1.1，出口网卡是eth0。如果这台设备要访问外网，这行必须在。没有默认路由，就算IP地址配得再好，包也不知道往哪儿发。
2.2 除了ip addr，还要会用的几个查询命令
IP地址只是网络配置的一部分。端口监听、ARP缓存、DNS解析，这些都要用到不同的命令。
bash复制# 查看本机监听的TCP和UDP端口
ss -tulnp
# 查看ARP缓存，确认局域网内IP和MAC的对应关系
ip neigh
# 测试DNS域名解析是否正常
nslookup example.com
# 或者看用了哪个服务器的解析结果
dig example.com # 如果没装，用 apt install dnsutils 或 yum install bind-utils
ss -tulnp输出里，LISTEN状态表示这个端口有服务在监听。比如ss -tulnp | grep :22能看到SSH服务是否在监听。State列是ESTAB的，说明有外部连接已经建立。-n参数表示不反解域名，-p显示进程号，-u看UDP，-l只看监听的端口，加上-t表示TCP。组合起来就是"查看本机所有处于监听状态的TCP和UDP端口以及对应的进程"。
这里补充一点：很多教程还在让人用netstat -tulnp，但netstat也已经属于net-tools包，新系统不一定装。ss是iproute2自带的，性能更好，信息更全。不用纠结用哪个，时代在往前走，工具也跟着换，这是正常的事。
3. 三种主流发行版的网络配置文件与持久化写法
临时命令讲完了，现在说重点：把网络配置永久写进系统里。不同发行版的配置体系不太一样，我分三类讲清楚，不然混着看容易晕。
3.1 RHEL系（CentOS / Rocky / AlmaLinux）的ifcfg文件
RHEL系的网络配置核心是/etc/sysconfig/network-scripts/ifcfg-<网卡名>文件。每张网卡对应一个文件，网卡名叫eth0就对应ifcfg-eth0，叫ens33就对应ifcfg-ens33。
配静态IP的经典写法如下：
bash复制# 文件：/etc/sysconfig/network-scripts/ifcfg-ens33
TYPE=Ethernet
BOOTPROTO=none # none表示静态，dhcp表示自动获取
NAME=ens33
DEVICE=ens33
ONBOOT=yes # 开机自动启用这张网卡
IPADDR=192.168.1.100
PREFIX=24 # 相当于子网掩码255.255.255.0
GATEWAY=192.168.1.1
DNS1=192.168.1.1
DNS2=114.114.114.114
有几个参数值得专门说。ONBOOT=yes非常重要，我之前见过好几个人把ONBOOT漏了或者写成no，结果配置看着没问题，但重启后网卡压根没启用。BOOTPROTO=none和dhcp的区别在于：dhcp会自动获取IP、网关和DNS，适合临时环境；生产环境建议用none或static，地址稳定可控。PREFIX=24表示子网掩码是255.255.255.0，如果你用的是老式掩码写法，也可以写NETMASK=255.255.255.0，效果一样，建议用PREFIX，更简洁直观。
改完文件后，重启网络服务使其生效。不同版本的RHEL系用的命令不一样：
bash复制# RHEL/CentOS 7及以前
systemctl restart network
# RHEL/CentOS 8及以后（含Rocky、Alma）
nmcli c reload
nmcli c up ens33
3.2 Debian/Ubuntu的netplan和interfaces文件
Debian系现在的配置方式分两派：老一代用/etc/network/interfaces，新版本Ubuntu默认用netplan。
netplan的配置是YAML格式，核心文件在/etc/netplan/目录下，比如/etc/netplan/01-netcfg.yaml。一段静态IP的配置大致长这样：
yaml复制network:
version: 2
ethernets:
eth0:
dhcp4: false
addresses:
- 192.168.1.100/24
routes:
- to: default
via: 192.168.1.1
nameservers:
addresses:
- 192.168.1.1
- 114.114.114.114
这里要特别提醒：YAML对缩进极其敏感。同样的配置，空格差一个就可能报错或静默失败。如果是在Windows里用记事本编辑过再传上去，还要注意换行符的问题，可能直接导致解析失败。
改完netplan，生效命令是：
bash复制sudo netplan apply
老一点的Debian/Ubuntu版本还在用/etc/network/interfaces，配置长这样：
bash复制auto eth0
iface eth0 inet static
address 192.168.1.100
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameservers 192.168.1.1 114.114.114.114
生效方式：
bash复制sudo systemctl restart networking
3.3 修改DNS的常见误区
DNS这块，很多人会直接改/etc/resolv.conf。这个文件确实能改，但现代系统里它经常被NetworkManager、systemd-resolved或DHCP客户端接管。你改了它，过一会儿它又会被覆盖成原来的内容。
真正要改的是网络配置文件里DNS相关的字段。上面写的DNS1=192.168.1.1、netplan的nameservers段落，这些才是DNS配置的"根"。改完这些再重启网络服务，/etc/resolv.conf里自然就是你要的DNS服务器。手动改resolv.conf只适合临时测试，不建议作为长期方案。
另外，systemd-resolved在Ubuntu系统上默认也在跑，它会管理/run/systemd/resolve/下的实际DNS配置。如果发现自己的DNS没问题却解析失败，可以先systemd-resolve --status看一眼当前生效的DNS到底是哪个，避免排查绕远路。
4. 实战：一台新装Linux服务器接入内网的完整配置过程
理论讲完，必须来一个从头到尾的完整过程。我以一个最常见的场景为例：机房新装了一台Ubuntu Server 22.04，自动获取到了IP，但需要改成固定IP以便后续部署服务。整个过程分四步。
4.1 场景设定
假设网卡名是ens33（虚拟机里常见），当前自动获取的IP是192.168.1.150，需要改成192.168.1.100，网关192.168.1.1，DNS用内网的和公共的个一个。
4.2 具体操作步骤
先确认当前状态：
bash复制ip addr show ens33
记下当前网卡名和IP。然后编辑netplan配置文件：
bash复制sudo vim /etc/netplan/01-netcfg.yaml
删掉或注释掉原来的dhcp配置，写入前面给的静态IP配置。这里我先用sudo netplan try而不是sudo netplan apply，因为try会在120秒内等待用户确认配置有效，如果配置有问题导致网络断了，它会自动回滚，不会把自己关在门外。这个习惯我建议所有远程操作的人都要养成，能救命。
确认没问题后，按回车生效。然后验证：
bash复制ip addr show ens33
ip route
ping -c 3 192.168.1.1
ping -c 3 114.114.114.114
如果前三个都通了，再测试域名解析：
bash复制nslookup baidu.com
nslookup能返回IP地址，就说明DNS也是通的。到这里，这台服务器的网络配置就算彻底完成了。
4.3 验证阶段容易忽略的细节
ping通了不代表万事大吉，还要测试重启后配置是否依然生效。我的习惯是：
bash复制sudo reboot
重启完成后再登录，执行ip addr确认IP还是192.168.1.100。这一步能验证配置是否真的"永久"了。如果重启后IP变了，多半是配置文件没写对，或者DHCP客户端还在跟静态配置打架。
另外一个容易忽略的点：如果这台机器上跑着Docker、KVM之类的虚拟化服务，重启后它们会自动创建虚拟网卡（比如docker0、virbr0）。这些虚拟网卡会占用独立网段，不影响物理网卡的配置。但如果路由表里default被某个虚拟网卡抢走了，就可能导致外网不通。遇到这种情况，检查ip route里的默认路由走的是哪张网卡，必要时手动调ip route add default via 192.168.1.1 dev ens33。
5. 网络不通时，我通常按这个顺序排查
配置已经写对了，但就是不通。这种情况最折磨人。我按亲身经验整理了一条排查链路，按照这个顺序走，90%的问题能在五分钟内定位。
5.1 每层看什么、用什么命令
第一步，看网卡状态是不是UP。命令是ip link show。如果状态是DOWN，说明网卡还没启用，用sudo ip link set ens33 up拉起来。如果是UP但下面的state UNKNOWN，可能是网线或交换机端口的问题，但更多时候是没插线或者对端端口被关了。
第二步，看IP地址和路由。ip addr确认网卡上有IP，ip route确认默认路由存在。这两个都正常了，网络层以上的问题基本排除了。
第三步，从近到远ping。先ping自己:
bash复制ping -c 3 192.168.1.100 # ping自己的IP
ping -c 3 192.168.1.1 # ping网关
ping -c 3 114.114.114.114 # ping公网IP
哪一步断了，问题就在哪一段。ping不通自己，问题在网卡配置或驱动；ping不通网关，问题在链路或网关交换机的配置；网关通但公网IP不通，问题在NAT、路由或者上游防火墙。这里有个细节：ping网关用的是局域网地址，如果交换机启用了端口隔离，网关可能ping不通，但不代表外网上不了。所以要多测一步真实业务，比如curl或telnet。
第四步，ping公网IP通了但ping域名不通，那是DNS问题。改DNS配置，不是手动改/etc/resolv.conf，而是按第三节的说法改真正的配置来源。如果确认DNS配置没问题还是解析不了，可以试试nslookup指定一个公共DNS服务器来对比，比如:
bash复制nslookup baidu.com 223.5.5.5
如果能解析，说明你系统里配的DNS服务器有问题，换一个就好。
5.2 几个"看似合理实则误导"的典型场景
排查时最怕被表象带偏。举几个例子。
第一个典型的误导场景：防火墙。有人习惯一上来就systemctl stop firewalld或者ufw disable来排除问题。虽然能快速验证，但副作用很大。我见过有人排除了半天，最后发现根本不是防火墙的事，但防火墙已经关了，服务器裸奔了一个下午。我的习惯是先看防火墙规则里有没有放通相关端口，而不是直接关闭。看规则用：
bash复制sudo firewall-cmd --list-all # RHEL系
sudo ufw status numbered # Debian/Ubuntu
第二个典型的误导场景："网卡明明是UP的"不等于"数据能出去"。有的网卡虽然状态UP，但是没有IP地址，或者IP和网段不匹配。ip addr输出里如果inet那行是空的，网卡再UP也上不了网。
第三个典型的误导场景：curl不通就判断网络不通。curl走的是HTTP协议，如果目标服务器的80/443端口被防火墙挡了，或者目标服务本身挂了，curl当然不通。但这时候ping可能是通的。所以判断网络通不通，首先要确认你测的是哪一层。TCP层用telnet或nc测端口;HTTP层用curl -v看具体报错;ICMP用ping。分层测，才不会被表象带偏。
6. 几个我踩过的坑和总结下来的习惯
最后把我这些年配Linux网络踩过的坑集中说一遍。这些都是常规文档里不会写的，但对实际工作很有帮助。
6.1 远程操作时改了网络配置导致SSH断连
这是每个运维都经历过的噩梦。远程登录着服务器，改了网卡IP或者网关，执行了网络重启命令，然后连接瞬间断开，再也连不上了。原因很简单：你的SSH连接是走老IP的，网络配置一改，连接自然断了。
解决方法是前面提过的永远先配置再apply，并且优先用会回滚的命令。netplan的sudo netplan try就是为这个场景设计的。RHEL系的NetworkManager也有类似机制：
bash复制nmcli c modify ens33 ipv4.addresses 192.168.1.100/24 ipv4.gateway 192.168.1.1 ipv4.method manual
nmcli c up ens33
但nmcli c up也是即时生效的，同样有断连风险。更保险的做法是在screen或tmux里执行配置命令，哪怕SSH断了，会话还在服务器上跑着，重新登录后还能看到输出。这个习惯我强烈建议所有人养成。顺便说一句，tmux还能防止你改配置改到一半网络断了，命令没执行完整，导致系统进入一种中间状态。
6.2 多网卡顺序导致的路由表异常
服务器插了两张网卡，一张接内网，一张接外网。结果发现内网能ping通，外网上不去。ip route一看，默认路由走到了内网网卡上。这是因为系统对多张网卡都有DHCP时，启动顺序决定了哪张网卡先拿到默认路由。
解决方法有两个：一是给不需要做默认出口的网卡禁用DHCP的默认路由，比如在netplan里设置dhcp4: true时同时加dhcp4-overrides: { use-routes: false };二是启动后手动调整默认路由，删掉错误的、加上正确的：
bash复制sudo ip route del default
sudo ip route add default via 192.168.1.1 dev ens33
不过手动调整重启后又会丢，所以在生产环境最好还是从配置层面固定路由。RHEL系的ifcfg文件里可以加DEFROUTE=no来控制哪张网卡承担默认路由，Ubuntu的netplan用routes段落配合metric数值也可以精确控制。metric值越小优先级越高，把外网网卡的默认路由metric调成100，内网网卡调成200，系统自然会优先走外网。
6.3 配置文件的"最后修改时间"也会害人
还有个不起眼的坑：有时候配置文件明明改了，也reload了，但网络行为没变。排查到最后发现是NetworkManager在管理这张网卡，它自己有一份配置，直接编辑ifcfg文件后，NetworkManager不一定立刻读取，需要用nmcli重新加载连接配置文件：
bash复制sudo nmcli c reload
sudo nmcli c up ens33
之前在最小化安装的CentOS上就遇到过，ifcfg文件改了不下三次，网络纹丝不动，后来才发现是NetworkManager在"抢管理权"。了解了这套机制之后，我现在遇到网络相关的问题，第一反应都是先确认系统里到底是谁在管网络——是NetworkManager、netplan、还是systemd-networkd。搞清楚了这一点，后面才会顺利。这个排查顺序看起来慢，实际上才是最快的方式。