企业官网建设流程全解析

不知不觉这个系列已经写到第十篇了。前面聊了文件系统、用户权限、进程管理，今天来啃一块很多人一开始容易绕晕的内容——管理网络。老实说，Linux的网络管理确实有点“历史包袱”，老的SysV配置和新出的systemd风格混在一起，不同发行版默认的网络栈也不一样，刚开始看的时候容易觉得乱。但网络这块其实没那么玄乎，核心就那几条主线：网卡与IP地址怎么配、路由怎么走、DNS怎么解析、连通性怎么查。把这些主线捋顺了，不管是修一台异常服务器，还是从零配置一台机器，心里都有底。这篇就按我平时实际干活的顺序写，把踩过的坑和常用命令一并放进来。

1. 网卡与IP地址：先把家底摸清楚

1.1 先看看机器上到底有几块网卡

不管是接手别人的机器还是自己新装的系统，第一步永远是把现状看清楚。Linux下查看网卡的命令有好几条，各自的信息维度不一样，我会搭配起来用。

ip addr是最常用的，它会把所有网卡和每个网卡上配置的IP地址一起列出来。输出里能看到网卡名、MAC地址、IPv4/IPv6地址、UP或DOWN状态，还能看到多播和广播地址信息。建议刚接触的朋友先跑一条ip addr感受一下，比ifconfig的信息全得多。

ifconfig是在老系统上很常见的命令，现代发行版默认可能没有这个命令了（需要装net-tools包）。如果你用的是较老的系统或习惯了老命令，也可以继续用，但它的输出不如ip addr直观，特别是IPv6相关的信息显示得比较零散。我在新机器上基本只用ip系列命令了。

还要注意一下网卡命名的规律。老系统里网卡通常叫eth0、eth1，新版本的Linux则可能是ens33、enp0s3、eno1之类的名字。en代表Ethernet，后面跟的p是总线编号，s是插槽编号，o是板载设备编号。还有一类常见的eth0这种名字，可能是老内核或简化配置的产物。一般来说，云服务器或虚拟机里默认的网卡名往往是eth0（很多云厂商刻意保持了命名习惯），而你本地装实体机或虚拟机跑新版系统，大概率会看到enXxx的形式。这不是故障，是命名规则变了。

1.2 网卡配置文件和现代网络管理栈

搞清楚网卡叫什么名字之后，下一步是弄明白这台机器是谁在管网络配置。目前主要是三大流派：一个是ifupdown风格，即/etc/network/interfaces，Debian系的老牌配置方式；一个是NetworkManager，桌面环境下几乎都是它；还有一个是systemd-networkd，作为systemd体系内的网络管理服务，在服务器精简环境里越来越多见。

判断方式很简单：看看服务状态就知道了。systemctl status NetworkManager能起来且是运行状态，那说明是NetworkManager在管。systemctl status systemd-networkd同理。如果你看到一个/etc/network/interfaces文件里写好了配置，那就是ifupdown的天下。这三个栈的特性差异很关键：NetworkManager适合经常变网络环境的机器（笔记本、桌面），因为它支持动态切换；systemd-networkd和ifupdown更适合固定配置的服务器，因为它们配置简单、稳定、开销小。

配置文件的位置也因发行版而异。RedHat系（比如CentOS、Fedora）的网卡配置文件放在/etc/sysconfig/network-scripts/，在NetworkManager管网络的时候，这些文件同样是生效的。Debian系和Ubuntu传统上是/etc/network/interfaces配合/etc/network/interfaces.d/目录使用；现在Ubuntu的桌面版已经全面转向NetworkManager，其配置保存在/etc/NetworkManager/system-connections/下，文件格式是类似INI的键值对。在这里面，每个连接有一个连接名，里面写着IP、网关、DNS等参数。

初次接触这个概念的时候，可能会觉得有点乱：怎么这个发行版用这个文件，那个发行版用那个文件？其实不是Linux本身混乱，而是“网络配置”这件事在不同的历史阶段出现过不同的解决方案，发行版各自选了一部分，后来一部分发行版又切换了默认管理栈。做运维和开发的朋友，我的建议是：认准你当前系统上默认的那一套方案，并且知道其他方案的存在即可。真正碰到问题的时候，你先确认“这台机器现在是谁在管网络”，再谈怎么改配置，这一条原则能解决大半困惑。

1.3 临时IP配置：验证IP能不能用

有些时候，你只是想快速验证一个新IP是否有效，并不想立刻动配置文件。那就用ip addr add命令临时加上去。举个例子：

sudo ip addr add 192.168.1.100/24 dev eth0

这里/24是子网掩码，表示前24位是网络号，也就是掩码是255.255.255.0，可用地址范围是192.168.1.1到192.168.1.254。加完之后用ip addr show eth0确认。如果发现加错了，删除也很快：

sudo ip addr del 192.168.1.100/24 dev eth0

这样做有一个很明显的好处：不用动配置文件，风险非常小，可以用来快速排查网络问题。比如你怀疑是IP和别的机器冲突了，或者网管给你分配了一个IP但你不太确定子网掩码和网关，那就先临时配上去试试，通了再考虑写进配置文件。

不过要记住，这种临时配置重启之后就会消失。如果你只是想临时拿这台机器做点测试，临时配置完全够用；如果你要的是服务器重启后仍然保持固定IP，那必须去改配置文件或重新配置连接。经常有朋友在测试环境临时配好了IP，过了几天重启机器上不来了，然后才发现当时只是临时配置，白忙活一场。

2. 动手配置静态IP：三种场景全覆盖

2.1 使用nmcli配置：推荐指数最高的方式

如果你的系统是NetworkManager在管，我强烈建议你学会用nmcli这个命令行工具配IP。虽然初次接触会觉得命令有点长，但用熟了之后比编辑配置文件更快、更不容易出错，也更符合现代Linux的运维习惯。

先看一下当前的连接情况：

nmcli connection show

输出会列出连接名、UUID、类型和设备。比如你在虚拟机里看到ens160这块网卡，它绑定的连接名可能也叫ens160。接下来要改配置时，就基于这个连接名操作，修改IP、掩码、网关、DNS：

sudo nmcli connection modify ens160 ipv4.method manual \ ipv4.addresses 192.168.1.100/24 \ ipv4.gateway 192.168.1.1 \ ipv4.dns "8.8.8.8 114.114.114.114"

这里有几个参数要注意。ipv4.method manual表示关闭DHCP自动获取，改成静态配置。如果希望恢复自动获取，就改成auto。ipv4.addresses后面的/24一定不能漏掉，这个前缀长度决定了你的可用IP范围，写错的话即使本机配置对了，和别人通信也很可能不通。ipv4.dns支持填多个DNS，用空格分隔，需要用引号包住整个内容，这个细节很容易被忽略。

改完配置之后必须让连接重新生效。可以用nmcli connection up ens160来激活一次，或者nmcli connection reload把配置重载进来。一般情况下，up命令更可靠，因为它会让NetworkManager重新应用该连接的完整配置，包括IP、路由、DNS等。然后你可以用ip addr show ens160验证一下IP是否变成了新地址。

需要提醒的是，很多朋友改完nmcli配置后，发现系统依然是旧IP，原因大多数是没执行up或reload。NetworkManager的机制是把配置先存下来，能不能立即生效是另一回事，你必须给连接的“应用状态”做个刷新。

2.2 编辑配置文件：ifupdown和networkd的典型写法

如果你接手的是没有NetworkManager的干净服务器，比如一个精简版Debian或Ubuntu Server，那么很大概率是ifupdown或systemd-networkd在管网络。

对于ifupdown，核心文件是/etc/network/interfaces。典型的静态配置长这样：

auto eth0 iface eth0 inet static address 192.168.1.100 netmask 255.255.255.0 gateway 192.168.1.1 dns-nameservers 8.8.8.8 114.114.114.114

注意这里使用的是netmask 255.255.255.0而不是/24，虽然表达的是同一个意思，但不同配置文件语法不一样，需要区分开。这里的auto eth0表示开机自动启用这块网卡，少了这一行的后果就是系统启动后不会自动配置这块网卡。改完文件后用sudo ifdown eth0 && sudo ifup eth0重新加载配置，或者直接重启机器。

对于systemd-networkd，配置文件一般放在/etc/systemd/network/目录下，文件名需要以.network结尾，比如10-static.network。文件内容是标准的INI格式：

[Match] Name=eth0 [Network] Address=192.168.1.100/24 Gateway=192.168.1.1 DNS=8.8.8.8 DNS=114.114.114.114

这里的[Match]用来匹配网卡名，Name=eth0表示这个配置只对eth0生效。改完文件后执行sudo systemctl restart systemd-networkd，配置就会加载。注意：如果你改了[Match]匹配的网卡名或者配置里的Address，小概率会遇到“配置没生效”的情况，这时候先检查文件权限和文件名后缀，再检查服务状态。

2.3 配置完成后的生效与验证

无论用哪种方式修改配置，都不代表改完就万事大吉。我给自己固定了一套验证流程，基本能覆盖绝大多数的配置疏漏。

第一步看网卡地址：ip addr show <网卡名>，确认IP和掩码是否正确。第二步看网关和默认路由：ip route show，确认default route指向的网关对不对。第三步ping网关：ping -c 3 <网关IP>，这一步能确认二层链路和IP配置是否正常。第四步ping外网：ping -c 3 223.5.5.5，用来判断路由和公网出口是否通畅。第五步再试DNS解析：nslookup www.example.com或dig。

如果网关ping不通，先怀疑IP冲突、掩码错误、网关本身不可达；如果外部IP能ping通但域名解析不出结果，问题基本就锁定在DNS配置上。这套验证逻辑基本成了职业习惯，每台机器配置完网络后我都会从头到尾跑一遍。

还有一个非常容易被忽略的细节：如果这台机器上配置了多个网卡多个IP，要特别小心默认网关的归属。Linux会选择一个最合适的路由作为默认路由，不是你写了网关它就一定按你写的走。我用过的很多机器都曾在多网卡场景下出现问题，后面会单独展开讲。

3. 路由管理：让数据包走对路

3.1 路由表查看与基础概念

IP配置好了之后，数据包怎么从这台机器送到目标机器，就是路由决定的了。你可以把路由表想象成一个城市交通指示牌：每个目的地对应一个出口方向。Linux的路由表也是这个思路，它维护着一组规则，内核在发送数据包时会查询这张表，找到一条最合适的路径。

查看路由表的命令很简单：

ip route show

它的输出里，最典型的是默认路由：

default via 192.168.1.1 dev eth0

这行表示：所有不知道该走哪条路的数据包，都交给网关192.168.1.1，从eth0网卡发出去。除了默认路由，你还会看到一些直连路由，比如192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100。这种路由表示当目标地址属于192.168.1.0/24这个网段时，直接从eth0发出去即可，不需要经过网关。

以前用route -n命令看路由表的朋友，可能习惯看到的是另一种格式。两个命令信息量基本一致，但ip route的可读性更好，也更推荐。route -n在部署了新版内核和工具链的机器上可能不再预装，如果非要看传统格式，安装net-tools也行。

3.2 添加与删除路由的实操

查看路由是基础，真正需要动手的场景是添加或删除路由。比如你的机器有双网卡，一个网卡连着办公网，另一块网卡连着机房内部网络，那你很可能需要手动添加一条静态路由，让发往某个内部网段的数据走第二块网卡。

添加一条普通静态路由的方式：

sudo ip route add 10.10.0.0/16 via 10.0.0.1 dev eth1

这里的目标网段是10.10.0.0/16，下一跳地址10.0.0.1，出口网卡eth1。要注意，下一跳地址必须和你的某块网卡在同一个网段，否则内核会提示“Network is unreachable”之类的错误，因为它在路由表里找不到能够到达这个下一跳的路径。

删除路由则是对应的：

sudo ip route del 10.10.0.0/16

默认的话，这条命令会把完全匹配这条目标网段的路由都删除。如果你想更精确地删除，可以加上via和dev参数：

sudo ip route del 10.10.0.0/16 via 10.0.0.1 dev eth1

类似临时IP配置，ip route add/del也是立即生效但重启丢失。如果要把静态路由永久固化，就得写进配置文件里，不同网络管理栈的写法也是不一样的。NetworkManager可以用nmcli connection modify <连接名> +ipv4.routes "10.10.0.0/16 10.0.0.1"来追加；systemd-networkd直接在一段[Route]配置里写；ifupdown则在接口配置块下加上up ip route add ...这样的行。

3.3 多网卡网关冲突的经典坑

多网卡的机器上，有一个极易踩的坑就是多个网卡都配置了默认网关。很多人会想：我两块网卡分别配一个网关，是不是所有网络都能连通？实际结果往往是一块网卡通了，另一块网卡完全不行，甚至两块都不稳定。

原因在于路由规则的本质：Linux在同一时间里只认一个默认路由。当你给两个网卡都声明了网关时，内核只会将其中一条作为默认路由，另一条会被忽略或随时被覆盖，最终导致数据包经常走错出口。处理这个问题，通常的做法是保留主要出口网卡的默认网关，其他网卡不设默认网关，只配置静态路由指向特定网段。

举个例子，服务器上eth0连接主网络，网关是192.168.1.1，默认路由走eth0；eth1连接备份存储网络，网段是192.168.100.0/24，网关是192.168.100.1。配置方式应当是eth1不配默认网关，仅在路由表里添加：

sudo ip route add 192.168.100.0/24 via 192.168.100.1 dev eth1

这样去往192.168.100.0/24网络的数据都会走eth1，而其他流量都走eth0默认路由。

还有更复杂的多路由表策略路由玩法，比如基于源IP分流、基于目标端口分流，使用ip rule和ip route table配合实现。这些场景主要出现在网闸、软路由和企业网关设备上，普通服务器运维中用得不多，我一般建议先把基础的策略路由原理看懂，再根据需求扩展。常见的坑是只看add不看rule，以为加了路由就一定会被正确选择，结果流量还是走默认路由，这个点值得记一下。

4. 主机名与DNS解析：解决网络里的“寻址困惑”

4.1 主机名设置与/etc/hosts优先级

网络通了，IP配好了，接着要解决“名字”的问题。一个主机名就是一个标识，像人的名字一样。查看主机名很简单：

hostname

手动临时改主机名：

sudo hostname myserver

这样做只对当前会话生效，重启就丢了。要永久修改主机名，现代系统一般推荐用hostnamectl：

sudo hostnamectl set-hostname myserver

这个方法在systemd体系下会把主机名写入/etc/hostname，重启后依然保留。老式系统可以自己编辑/etc/hostname文件，然后执行hostname -F /etc/hostname手动加载。这里有一个细节：DNS解析时，系统会优先看/etc/hosts文件，然后再查配置的DNS服务器。/etc/hosts里手工指定了某个域名的IP，就会跳过DNS查询。这个特性既是隐患也是便利，有些运维故意用它在内网做“假解析”，让某个域名指向内网负载均衡器或特定节点。

举个例子，/etc/hosts里加一行：

192.168.1.200 mydb.internal

那么随便哪个程序访问mydb.internal都会被解析到192.168.1.200。要注意的是，如果后续这个服务迁移了IP，而hosts里的老映射忘记删掉，故障排查会非常折腾。我有一次排查一个应用无法连接数据库，ping mydb.internal显示的IP是旧地址，而DNS服务器里其实已经更新成新地址了，问题的根源就在hosts文件。后来我的习惯就是：排查这类问题时，先看/etc/hosts，再查DNS，顺序别搞反。

4.2 DNS配置与systemd-resolved的坑

DNS配置的经典做法是写/etc/resolv.conf：

nameserver 8.8.8.8 nameserver 114.114.114.114

但在现代发行版上，这个文件很可能只是一个指向systemd-resolved的软链接或类似生成文件。如果你在Ubuntu 20.04以上的默认配置里直接编辑/etc/resolv.conf，重启后可能就被覆盖了。这个让很多人头疼的“DNS配置不生效”问题，根源就在于你的机器上跑着systemd-resolved服务。

如果是NetworkManager配合systemd-resolved的机器，正确做法应该用nmcli或图形界面配置DNS。比如：

sudo nmcli connection modify ens160 ipv4.dns "8.8.8.8 114.114.114.114" sudo nmcli connection up ens160

如果纯粹禁用systemd-resolved，也可以手动修改：先停掉服务，再把/etc/resolv.conf改回普通文件，内容直接写nameserver配置。不过禁用之前要想清楚，新Linux桌面或某些依赖systemd-resolved的应用，可能因为禁用了它而变得不适用。

测试DNS是否生效，最直接的办法是：

nslookup www.example.com

或者：

dig www.example.com

这两个命令在最小化安装的服务器上未必预装，Ubuntu上需要apt install dnsutils，CentOS系可能要用bind-utils。没装也不慌，可以先简单用ping -c 1 域名看能否解析出IP来大致验证。

4.3 常见解析故障与排查思路

解析故障很典型，大概分几类。一类是“所有域名都解析不出来”，原因大多是/etc/resolv.conf里的nameserver地址写错，或者本机防火墙封了53端口。用ping -c 1 223.5.5.5验证一下外网连通性，如果外网通而域名解析不了，问题基本就锁定在DNS上。

另一类是“某些域名解析不出来但其他域名正常”，这可能是运营商DNS对某些域名解析响应异常，或者该域名只在特定企业内网的DNS服务器上有记录。解决方法是换DNS或者检查内网解析记录。还有一种常见情况是“解析结果和预期不一致”，这时要检查/etc/hosts有没有设置过这个域名，以及缓存问题。系统自带的nscd或systemd-resolved都会有DNS缓存，偶尔会出现缓存了旧IP的现象。重启systemd-resolved或者刷新缓存可以解决。

这里要特别提醒一句：生产环境改DNS一定要谨慎，尤其是同时运行着多个依赖域名解析的服务的机器，改完最好马上检查所有关键服务的日志，确认没有出现大范围解析异常。DNS看似小事，出问题往往是连锁性质的。

5. 连通性排查：从ping到抓包的四层递进

5.1 基础连通性与链路层排查

拿到一台“网络不通”的机器，很多人第一反应就是ping。这个思路是对的，但ping不通不等于真的不通。正确姿势是先把链路层状态查清楚，再一层层往上排查。

先看网卡是否处于UP状态：

ip link show

如果输出里没有UP状态，说明这块网卡被禁用了，可以执行sudo ip link set eth0 up开启。这里有个细节：虚拟机里网卡如果没接虚拟交换机，或者实体机网线没插好，驱动可能显示“state DOWN carrier 0”，这种情况再怎么配IP都是白搭。继续往下看ARP表：

ip neigh show

ARP表保存着同一二层网络内IP和MAC地址的对应关系。如果ping网关能通但ARP表里看不到网关的记录，那很可能是源IP和目标IP不在同一个广播域，网关不可达或者网关设备上的ARP表出了问题。

链路正常之后，ping网关就是第二步验证。ping的时候注意观察延迟和丢包率。延迟如果是几个毫秒突然跳到几百毫秒，或者有规律地丢包，大概率存在二层环路、网线质量差、交换机端口异常等问题。假如网关也能通，再ping一个外网IP来验证路由和出口防火墙策略。

5.2 端口与服务状态排查

IP层通了不代表应用层就通了。日常排查里，最经典的场景是“服务器能ping通，但浏览器访问不了端口”。这种情况通常需要检查端口是否在监听、防火墙是否放行。

查看端口监听状态用：

ss -lntp

这个命令会列出所有处于LISTEN状态的TCP端口和对应进程。-l表示listening，-n表示不解析域名，-t表示只显示TCP，-p表示显示进程信息。如果某个端口没出现在LISTEN列表中，说明服务进程根本没监听在这个端口上，先检查服务状态和配置文件监听地址。如果端口已经在监听，但外部无法访问，那就是防火墙或云安全组的问题。本机查看防火墙规则：

sudo iptables -L -n -v

现代系统如果没有iptables，也可能用的是nftables，或者干脆由firewalld管理。凭经验，云主机还有一层安全组外部防护，这一点在云环境下尤其重要。无论你是用iptables -I INPUT -p tcp --dport 8080 -j ACCEPT放行端口，还是在云控制台添加入方向规则，都别忘了测试一下规则本身是否生效。

实在没有权限或者命令行工具不好用，还有个简单办法就是curl -v http://IP:端口，看输出的连接过程。curl -v会打印TCP握手、SSL握手等详细信息，出错时能看出来问题出在哪一步。

5.3 中间链路与DNS问题：traceroute与dig

如果两台机器之间连通性时好时坏，用traceroute或mtr能看到数据包经过哪些中间节点，定位出卡在哪一跳。traceroute基本每个系统都有：

traceroute -n 8.8.8.8

-n参数表示不做反向域名解析，只显示IP，速度会快很多。输出的每一行是一跳，从本机出口网关开始，逐步到达目标。如果连续几跳都是* * *，说明这些节点没有返回ICMP包或丢弃了探测包。很多网络环境故意禁ICMP，所以* * *不代表一定不通，要结合整体路径判断问题是否出现在某一段。

mtr是traceroute的加强版，相当于不断刷新的traceroute，可以持续显示每一跳的丢包率和延迟。这个工具排查网络不稳的时候特别好用，比如丢包集中在某一跳，基本就能断定瓶颈在那一带的链路。装mtr的方法很简单：Debian系是apt install mtr-tiny，RedHat系是yum install mtr。

DNS部分的排查在前面已经提过，这里补充一点：如果目标是域名而不是IP，但手边没有dig，优先用getent hosts 域名这个命令，它能同时查询hosts文件和DNS服务器，输出和hosts风格很像。多了一层信息有时就够定位问题。

6. tcpdump抓包：把数据包“调出来看”

6.1 常用过滤语法与实际案例

抓包这件事，听起来像网络工程师才会干，但其实做开发、做运维也经常需要。很多时候服务报错“连接超时”，但到底是谁没回应，看日志根本看不出来，抓包一看便知。

tcpdump是Linux上最主流的命令行抓包工具，基本所有发行版都有或者很容易安装。最基础的用法：

sudo tcpdump -i eth0 -nn

-i eth0指定抓包网卡，-nn表示不解析域名和端口服务名，直接显示IP和端口数字。这样一跑，网卡上的所有流量都会刷出来。但这个输出量一般非常巨大，所以必须用过滤条件缩小范围。

抓指定主机的包：

sudo tcpdump -i eth0 -nn host 192.168.1.200

抓指定端口的包：

sudo tcpdump -i eth0 -nn port 8080

抓指定协议的包：

sudo tcpdump -i eth0 -nn tcp

也可以组合过滤条件。比如抓目标端口是443或源端口是443的包，同时排除某个IP：

sudo tcpdump -i eth0 -nn port 443 and not host 192.168.1.1

这里需要说明一句：tcpdump的过滤语法是它自己的一套关键字体系，常见的有host、port、net、proto（tcp/udp/icmp）、src/dst、and/or/not。跟wireshark的显示过滤器语法有点像但不一样，千万不要把两者混为一谈。

想抓更详细的信息，加上-X或-A参数。-A以ASCII形式显示包内容，适合看HTTP明文请求；-X同时显示十六进制和ASCII，适合分析协议字段。抓包保存到文件用-w参数：

sudo tcpdump -i eth0 -nn port 3306 -w mysql.pcap

生产环境抓包，我个人的习惯是先加-c 100限制抓取数量，比如抓100个包就自动停止，避免日志文件无限膨胀。等分析完包的行为，再决定要不要长时间持续抓。

6.2 抓包分析网络问题的典型思路

抓包不是为了看热闹，重点在于从包的行为判断问题出在哪一层。以“客户端连不上服务器的某某端口”为例，客户端抓包可能看到SYN包发出去了，但服务器没有回SYN-ACK。这时候就要去服务器上抓包，确认SYN包是否真的到达了服务器。如果服务器网卡上根本看不到包，说明包在中间被防火墙或安全组拦截了。如果看到了包但没有响应，那就是服务器本机的防火墙、监听端口或者内核参数的问题。

ARP层面的排查也是一样。两台机器在同一局域网但互相ping不通，抓包就能看到请求发出后有没有ARP应答。有应答说明二层可达，没有应答说明请求根本没送达或对方没回应，再往交换机端口和网卡状态方向排查。

DNS问题的抓包方法也很典型。抓53端口的UDP包可以看到客户端发出DNS查询后是否收到响应，以及响应里的解析结果。如果响应被截断，注意观察响应标志位里是否有TC（Truncated，截断）标志，这意味着响应过大可能需要改用TCP查询。

抓包得到的经验值，远非“看日志”能比。日志都是应用层自己记录的，而抓包是看网络层的真实状态。比如配置了一个奇怪的路由规则，导致数据包发出去之后就消失了，日志里什么都看不到，抓包却能在出口网卡上一眼看出包的走向。所以我建议每个做开发和运维的朋友，即使不专职搞网络，也值得花一晚上把tcpdump的基本操作练熟，关键时候能省一整天的排查时间。

回看这一整篇Linux网络管理的内容，从网卡IP、路由、DNS、连通性排查到抓包，基本就是一套完整的“从配置到排障”思路。说实话，网络管理比文件系统更容易让人觉得繁琐，因为太多知识点之间有隐性的依赖关系。但我的个人体会是，只要把ip addr、ip route、systemctl以及网络管理栈这四件事弄明白，配合对不同配置文件位置的熟悉，绝大多数网络问题都能在半小时内定位，剩下的所谓“玄学”故障，大多只是某一步配置被忽略了。希望这篇能帮你在搭建自己的Linux环境时少走几条弯路。