初冬拾月的笔记

Linux 5分钟网络排错

2026/11/8 Linux

5 分钟内判断一台陌生 Linux 的网络到底是谁在管、配置写在哪、当前状态是什么，不依赖发行版经验，纯靠命令自证。

# 第一阶段：30 秒确认 init 体系（决定后续所有路径）

向内核查询 PID 为 1 的进程，只输出它的可执行文件名，不打印列标题。

ps -p 1 -o comm=
1

ps : 报告当前进程快照（process status）

参数解读：

  • -p 1

    • -p（或 -q）：按 PID 筛选进程

    • 1 ： 指定 PID 为 1

      PID 1 是内核启动的第一个用户态进程，所有其他进程的祖先。它决定了这台机器的 init 系统 是什么。

  • -o comm=

    • -o ： 自定义输出格式（output format），只打印你指定的字段

    • comm： 字段名，含义是 command name（可执行文件名，不含路径、不含参数）

    • = （等号后无内容）= 去掉列标题

      -o comm：输出带表头 COMMAND

      -o comm=：只输出值本身，无表头

输出 含义 后续方向
systemd systemd 系发行版，现代主流 进入第二阶段
init SysV init（Debian 6-/RHEL 6-/CentOS 6-），老派 直接跳到第五阶段
runit / openrc / s6 轻量/容器/嵌入式 跳到第五阶段

# 第二阶段：2 分钟判断网络后端（systemd 系）

# 2.1 NetworkManager 是否活跃

在主流 Linux 发行版（如 CentOS 7/8、Ubuntu 等）中，NetworkManager（常简称为 NM）是默认的网络管理服务。排查网络问题时，首要步骤是确认该服务是否正在运行并接管设备。

执行检查命令：

systemctl is-active NetworkManager 2>/dev/null
nmcli device status 2>/dev/null
1
2
  • 第一条命令用于查询 NM 服务的运行状态（返回 active 或 inactive）。
  • 第二条命令通过 nmcli 工具列出当前网络设备的状态（如以太网、Wi-Fi 等）。
  • 2>/dev/null 用于屏蔽错误输出（例如命令不存在时），保持终端整洁。

结果判定与后续操作：

  • NM 在管（正常情况）

    若服务状态返回 active，且 nmcli 成功输出设备列表，说明 NetworkManager 正在运行并管理网络。

    👉 配置路径：后续网络配置应优先使用 nmcli 命令行工具，或直接修改 /etc/NetworkManager/ 目录下的配置文件，避免手动修改传统配置文件（如 /etc/sysconfig/network-scripts/ifcfg-*）导致冲突。

  • inactive / 命令不存在 → 继续

# 2.2 systemd-networkd 是否活跃

在 systemd 体系中，systemd-networkd 是负责网络接口生命周期、IP 地址、路由、DNS等配置的守护进程。

但“服务在运行” ≠ “它正在管理你关心的那块网卡”，因此需要两步确认。

✅ 第一步：确认 systemd-networkd 服务本身是否活跃

systemctl is-active systemd-networkd 2>/dev/null
networkctl list 2>/dev/null
1
2

结果判定与后续操作：

  • systemctl 返回 active，且 networkctl list 能列出接口：systemd-networkd 正在运行，并可能正在管理部分或全部接口
  • 两者都无输出或显示 inactive：systemd-networkd 未启用或未运行，通常由其他网络管理器 → 继续

⚠️ 即使 networkd 在运行，也不代表它一定管理所有网卡。

是否接管某块网卡，取决于 .link / .network 文件的匹配结果。

✅ 第二步：确认具体网卡是否被 networkd 接管

当第一步确认 networkd 活跃后，需要进一步查看指定接口的状态：

networkctl status <接口名，如 eth0>
1

该命令会显示：

  • 接口当前是否 UP / DOWN
  • 是否由 systemd-networkd 管理
  • 使用了哪些配置文件（.link / .network）
  • IP、路由、DNS 等运行时信息

📘 官方文档说明来源：

  • networkctl 命令与 status 输出含义 👉 https://www.freedesktop.org/software/systemd/man/latest/networkctl.html
  • systemd-networkd 总体工作机制 👉 https://www.freedesktop.org/software/systemd/man/systemd-networkd.service.html

📌 关键结论（非常重要）

systemd-networkd 是否管理某块网卡，不是由服务状态决定的，而是由配置文件是否匹配该接口决定。

相关配置文件分为三类：

1️⃣ .link 文件 —— 网卡底层属性（命名、MAC、驱动等）

  • 由 systemd-udevd 处理
  • 决定：
    • 接口名称
    • MAC 地址
    • 是否交由 systemd-networkd 管理（ID_NET_MANAGED_BY）

📌 https://www.freedesktop.org/software/systemd/man/systemd.link.html

2️⃣ .network 文件 —— IP / DHCP / 路由 / DNS

  • 由 systemd-networkd 处理
  • 决定：
    • IPv4 / IPv6 地址
    • DHCP 行为
    • 路由、DNS、NTP 等

📌 https://www.freedesktop.org/software/systemd/man/systemd.network.html

3️⃣ .netdev 文件 —— 虚拟网络设备（bridge / vlan / vxlan 等）

  • 仅在你显式创建虚拟接口时才需要
  • 普通物理网卡排查时通常不涉及

📌 https://www.freedesktop.org/software/systemd/man/systemd.netdev.html

🛠 离线查阅方式（无需联网）

所有上述内容都可以通过本地 man 手册查看：

man networkctl
man systemd.network
man systemd.link
man systemd-networkd.service
1
2
3
4

# 2.3 netplan（Ubuntu 系常见中间层）

在 Ubuntu 18.04 及以后版本中，netplan 成为默认的网络配置中间层。它允许管理员用统一的 YAML 格式编写配置，底层再“渲染”给具体的网络守护进程（如 NetworkManager 或 systemd-networkd）去执行。

执行检查命令：

ls /etc/netplan/*.yaml 2>/dev/null
1
  • 用于检查系统是否存在 netplan 配置文件。2>/dev/null 用于屏蔽无文件时的报错。

结果判定与后续操作：

  • 有文件（存在 .yaml 配置）

    说明系统使用 netplan。需进一步查看内容，决定底层实际由谁接管：

    grep -E 'renderer|networkd|NetworkManager' /etc/netplan/*.yaml
    1

    • 若显示 renderer: NetworkManager → 配置最终交由 NM 管理（呼应 2.1 节，可用 nmcli）。

    • 若显示 renderer: networkd 或未指定（默认通常为 networkd）→ 由 systemd-networkd 管理。 👉 配置路径：修改 /etc/netplan/*.yaml 后，需执行 netplan apply 生效。

  • 无文件

    说明未使用 netplan，继续向下排查传统工具。

# 2.4 传统 ifupdown

对于更老的系统，或未使用 netplan/NM 的系统，通常依赖传统的 ifupdown 工具集（通过脚本控制网卡启停）。这是 Debian 与 RHEL 两大发行版差异最明显的地方。

执行检查命令：

ls /etc/network/interfaces 2>/dev/null
ls /etc/sysconfig/network-scripts/ifcfg-* 2>/dev/null
1
2
  • 分别检查 Debian 系与 RHEL 系的经典配置文件路径。

结果判定与后续操作：

  • Debian 系（如 Ubuntu 16.04 及更早、Debian） 若存在 /etc/network/interfaces → 说明使用 ifupdown（命令如 ifup eth0 / ifdown eth0）。 👉 配置路径：直接编辑该文件，配置格式为 iface eth0 inet dhcp/static。
  • RHEL 系（如 CentOS 6/7、RHEL） 若存在 /etc/sysconfig/network-scripts/ifcfg-* → 说明使用 network.service（传统网络服务）。 👉 配置路径：编辑对应的 ifcfg-eth0 文件，通过 systemctl restart network 或 service network restart 重启网络。

# 第三阶段：30 秒看当前生效状态（不管谁管的）

在网络排查中，无论底层配置是由 NetworkManager、systemd-networkd 还是手动脚本管理的，内核当前实际运行的网络状态才是决定连通性的关键。本阶段的目标是绕过配置来源，直接在 30 秒内确认“现在到底通不通”。

核心排查命令：

# 查看 IP。检查目标网卡（如 eth0）是否已启用（UP），并核对 IPv4/IPv6 地址、掩码是否符合预期。指定接口名可过滤冗余信息。
ip addr show
ip addr show <接口名，如 eth0>

# 查看路由。查看是否存在 default via <网关IP> 的默认路由，这是访问外网的必要条件；同时检查局域网网段路由。
ip route show

# 查看 DNS。直接读取系统当前使用的 DNS 服务器（如 nameserver 8.8.8.8），判断域名解析配置是否生效。
cat /etc/resolv.conf
1
2
3
4
5
6
7
8
9

快速判断逻辑：

  • IP 有、路由通、DNS 能解析 → 当前配置是好的，只是想知道“谁写的”

    说明内核状态完全正常，网络已连通。此时若需修改或复盘，才去“第二阶段”追溯配置来源（如查 NetworkManager 或 netplan）。

  • IP 没有/不对 → 结合第二阶段定位该改哪

    若 IP 缺失、掩码错误，或无默认路由/DNS，则网络必然异常。需回溯配置管理工具（第二阶段），定位是配置文件写错还是服务未生效。

实际排查中，执行完上述命令后，建议顺手测试：ping -c 2 <网关>（测内网通断）与 ping -c 2 8.8.8.8（测外网通断），配合 nslookup 域名（测 DNS 解析），可瞬间锁定故障层级。

# 第四阶段：1 分钟交叉验证（防止误判）

怀疑 验证命令 看到什么说明对了
NM 管但 networkd 也装了 nmcli con show 有连接配置 → NM 真在管
networkd 管但 NM 也装了 networkctl status <iface> 显示 State: routable configured
容器环境 systemd-detect-virt / cat /proc/1/cgroup 容器通常无网络服务，靠宿主机
云服务器 curl -s http://169.254.169.254/latest/meta-data/ (AWS) 有响应说明是云，可能靠 cloud-init

# 第五阶段：非 systemd / 嵌入式 / 容器

# 看网卡配置脚本
ls /etc/network/ /etc/conf.d/net* /etc/rc.conf 2>/dev/null

# 看启动脚本里有没有 ip 命令
grep -r 'ip addr\|ifconfig\|dhclient' /etc/init.d/ /etc/rc*.d/ 2>/dev/null | head

# 容器检测
cat /proc/1/cgroup | grep -q docker && echo "Docker"
cat /proc/1/cgroup | grep -q kubepod && echo "K8s"
1
2
3
4
5
6
7
8
9

# 附：速查决策树与配置位置

定位与用途：本附录为排错流程的“终极兜底”。当正文五个阶段排查完仍存疑，或面对一台全新机器需快速接管时，可通过下方“速查决策树”一键判定当前系统的网络后端，并配合“配置位置表”直接定位修改文件。

使用逻辑：先执行决策树中的命令链条（从 init 体系到具体后端特征），确定后端名称后，跳转至下方表格获取配置路径与重载命令。

ps -p 1 -o comm=
├── systemd
│   ├── nmcli device status → 有输出且 managed → NetworkManager
│   ├── networkctl list → 有输出且 configured → systemd-networkd
│   ├── ls /etc/netplan/ → 有 yaml → netplan (看 renderer)
│   └── 以上都没有 → 传统 ifupdown 或 network.service
├── init/openrc/runit → 直接查 /etc/network/ 或 /etc/conf.d/
└── 容器 → 网络由宿主机/编排平台管，容器内不配
1
2
3
4
5
6
7
8

速查决策树执行逻辑拆解：

  • 起点判定：以 ps -p 1 -o comm= 确认系统初始化进程。
  • systemd 分支（主流发行版）：
    • 优先检测 NetworkManager（桌面端/常见云主机）：通过 nmcli device status 查看是否有输出且状态为 managed。
    • 其次检测 systemd-networkd（服务端常见）：通过 networkctl list 查看是否有输出且显示 configured。
    • 再检测 netplan（Ubuntu 系常见中间层）：检查 /etc/netplan/ 目录下是否存在 .yaml 文件（需关注其 renderer 指向谁）。
    • 兜底：以上均无特征，则归为传统 ifupdown 或旧版 network.service。
  • 非 systemd 分支：若为 init/openrc/runit，直接检查 /etc/network/ 或 /etc/conf.d/。
  • 容器环境：网络通常由宿主机或编排平台（如 K8s）接管，容器内一般无需单独配置后端。

各后端配置位置与重载速查表：

下表汇总了决策树中涉及的所有后端的“配置文件路径”与“生效重载命令”。排错黄金法则：修改配置后，务必使用对应后端的重载命令（避免混用 systemctl restart network 导致状态错乱），并配合正文第三阶段的“交叉验证”确认生效。

后端 配置路径 重载命令 适用场景备注
NetworkManager /etc/NetworkManager/system-connections/ nmcli con reload 桌面环境、CentOS/RHEL 默认
systemd-networkd /etc/systemd/network/ systemctl restart systemd-networkd 无图形界面服务端、CoreOS
netplan /etc/netplan/*.yaml netplan apply Ubuntu 18.04+ 默认中间层
ifupdown (Debian) /etc/network/interfaces ifdown / ifup 传统 Debian/Ubuntu 旧版
network-scripts (RHEL) /etc/sysconfig/network-scripts/ifcfg-* systemctl restart network RHEL/CentOS 7 及之前旧版

# 附：网络基础与访问流程

定位与用途：本附录为排错提供“底层逻辑支撑”。排错不仅是改配置文件，更需理解数据包如何流转。当遇到“能 ping 通 IP 但打不开网页（DNS 问题）”、“连上 Wi-Fi 但无网（路由/网关问题）”时，可对照此处的概念与流程定位故障域。

阅读建议：前半部分为“核心概念速记”，后半部分将这些概念串联为“打开网页全链路”，建议结合实战反复映射。

6 大核心概念排错映射：

  • IP（寻址规则）：网络世界的“门牌号”，定位设备的唯一标识。
  • IPv4（32位）：当前主流但地址枯竭，排错时最常见（如 192.168.x.x）。
  • IPv6（128位）：未来主力，双栈环境下需额外关注 IPv6 路由与 DNS 解析。
  • DHCP（自动分配）：“别手动配”，客户端接入网络自动获取 IP/网关/DNS。若网络断开，首选检查 DHCP 是否失败。
  • 路由（数据包跳转）：决定数据“怎么走”，排错核心在于默认网关是否正确。
  • DNS（域名翻译官）：域名转 IP。能通 IP 但打不开域名，90% 是 DNS 故障。

打开网页”全链路 6 步拆解（排错视角）：

以下流程模拟了从接入网络到获取数据的完整生命周期，每一步都是潜在的排错检查点：

  1. 接入与获取（DHCP）：设备连网（如 Wi-Fi），DHCP 自动下发 IP、网关、DNS。（排错点：若无 IP/网关，后续全断）
  2. 发起访问（DNS 触发）：输入 www.example.com，本机无缓存则发起 DNS 查询。（排错点：卡在此步通常为 DNS 配置错误或 53 端口被阻）
  3. 域名解析（DNS 结果）：DNS 返回目标服务器 IP（IPv4/IPv6）。（排错点：解析失败则无法建连）
  4. 路由发包（路由表）：系统查路由表，目标不在本地则发给默认网关（路由器）。（排错点：网关不可达，表现为“无外网”）
  5. 网络转发（逐跳）：路由器按路由协议逐跳转发，直至目标服务器。
  6. 数据回传（原路返回）：服务器响应，沿原路径返回本机，页面加载完成。
1. 手机连 Wi-Fi
   └─ DHCP 自动分配 IP、网关、DNS

2. 浏览器输入 www.example.com
   └─ 本机不知道 IP，发起 DNS 查询

3. DNS 解析出目标服务器 IP（IPv4/IPv6）

4. 操作系统按路由表发包
   └─ 先给默认网关（路由器）

5. 路由器逐跳转发，到目标服务器

6. 服务器回数据，原路返回
1
2
3
4
5
6
7
8
9
10
11
12
13
14

硬链接和软连接