结论： 服务器自己连不上外网，按四层排查：网卡链路（ip a 是否 UP、有无 IP）→ 路由网关（ip route、ip route get）→ DNS 解析（resolv.conf、resolvectl）→ 出方向策略（安全组、iptables、NAT、代理）。先 ping -c 4 223.5.5.5 测纯 IP 连通，再 ping -c 4 www.baidu.com 测 DNS，两步即可把范围缩小一半；两条都不通则故障落在网卡、路由或出方向策略层，需逐层深入。
服务器上不了网，是比"网站打不开"更底层也更让人慌的故障——apt update 卡住、curl 超时、NTP 时间同步失败、监控心跳中断，一连串依赖网络的服务同时报警。此时最忌讳的是上来就重启网卡或重启机器，因为盲操作可能把本来可恢复的配置错误变成彻底失联。
排查的关键在于先分方向。"服务器连不上网"指的是这台机器主动访问外部失败，即出方向（Egress）故障；而"别人 ping 不通这台服务器"是入方向（Ingress）故障，两者的根因完全不同。本文只讲出方向，按网卡、路由、DNS、策略四层逐层收窄，命令基于 Ubuntu 24.04 LTS。
先分方向：出方向故障 ≠ 别人 ping 不通我
结论：先确认故障发生在哪个方向，否则会查错整套体系。 出方向是"我访问别人"，瓶颈在网关、路由、DNS 和安全组出规则；入方向是"别人访问我"，瓶颈在监听端口、入规则、防火墙和运营商封禁。
| 对比项 | 出方向故障（本文） | 入方向故障（ping 不通） |
|---|---|---|
| 典型现象 | apt update 卡住、curl https://... 超时、ping 外网IP 不通 | 外部 ping 服务器公网IP 超时、nc -zv 端口不通 |
| 用户感知 | 服务器自己干不了活，但网站可能仍能被访问 | 网站/SSH 全部不可达，服务器自己可能一切正常 |
| 常见根因 | 网关错、DNS 配错、安全组出方向被封、NAT/代理失效、网卡 down | 安全组入规则未放行、服务未监听、云平台封 ICMP、带宽跑满 |
| 核心命令 | ip a、ip route、ping、mtr、resolvectl | ss -lntp、iptables -L -n、控制台安全组、tcpdump |
| 测试基准 | 从服务器内向外 ping 阿里 DNS 223.5.5.5 | 从外部向服务器公网 IP 发起测试 |
一条判据：如果能 SSH 登录到这台机器但机器上不了网，99% 是出方向问题；如果连 SSH 都进不去，优先查入方向。
五类根因速查表
结论：出方向故障逃不出五类根因，先用两条 ping 命令把候选缩到一类，再针对性处理。
| 根因 | 关键判据 | 典型报错 | 定位命令 |
|---|---|---|---|
| 网卡 down / 链路断开 | ip a 中网卡无 state UP，或无 inet 地址 | connect: Network is unreachable | ip link、ethtool eth0 |
| IP 地址丢失 | 有 UP 但无 IPv4 地址或为 169.254.x.x | ping: sendmsg: Operation not permitted | ip a、journalctl -u systemd-networkd |
| 网关/路由错误 | 能 ping 同网段，ping 不通外网 IP | Network is unreachable、全丢包 | ip route、ip route get 223.5.5.5 |
| DNS 解析错误 | ping 223.5.5.5 通，但 ping www.baidu.com 不通 | Temporary failure in name resolution | cat /etc/resolv.conf、resolvectl status |
| 出方向被封 | 本机 IP 通、DNS 通，但特定端口/目标不通 | Connection timed out、部分站点可访问 | 控制台安全组、iptables -L -n、mtr |
第 1 层：网卡与链路状态排查
结论：先看网卡是不是 UP、有没有拿到 IP，这是所有网络故障的起点。 链路层不通，后面三层查得再细也没意义。
# 1. 查看所有网卡状态与地址（重点关注 state 与 inet 行）
ip a
# 正常示例：2: ens33: ... inet 192.168.1.10/24
# 异常示例：2: ens33: ...（没有 inet）
# 2. 只看链路层状态
ip link show
# state DOWN 表示网卡被关闭或未被管理；NO-CARRIER 表示物理链路/虚拟交换机未接上
# 3. 拉起网卡
ip link set eth0 up # 接口名可能是 ens33 / ens160 / enp0s3，以 ip a 实际输出为准
# 4. 查看物理链路与速率协商（云服务器重点看 Link detected）
ethtool eth0 | grep -E "Speed|Duplex|Link detected"
# Link detected: no 说明虚拟网卡未挂载或宿主机侧异常，需联系云厂商 如果 ip a 里看到 inet 169.254.x.x/16，说明 DHCP 没能拿到地址，这是链路层自动私有地址（APIPA），常见于云服务器 DHCP 租约失败或 NETPLAN 配置错误。
# 重新申请 DHCP 租约
dhclient -r eth0 && dhclient eth0 # 传统方式
# Ubuntu 24.04 使用 netplan + systemd-networkd 时：
netplan apply
networkctl status eth0第 2 层：IP 地址与路由排查
结论：路由决定了数据包往哪走，网关错一台机器上不了网，这是出方向故障的第二高发区。 判据是"同网段能通、跨网段不通"。
# 1. 查看主路由表
ip route
# 正常应有一条：default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.10 metric 100
# 2. 精确测试到某个目标会走哪条路由、从哪个源 IP 出
ip route get 223.5.5.5
# 正常：223.5.5.5 via 192.168.1.1 dev eth0 src 192.168.1.10 uid 0
# 异常：RTNETLINK answers: Network is unreachable（无默认路由）
# 3. 缺省路由缺失时临时补一条（重启失效，正式修复要改 netplan）
ip route add default via 192.168.1.1 dev eth0
# 4. 查 ARP / 邻居表，确认网关 MAC 能否解析到
ip neigh show
# 网关显示 FAILED 或一直 INCOMPLETE，说明二层到网关就不通# /etc/netplan/00-installer-config.yaml（Ubuntu 24.04 LTS 标准写法）
network:
version: 2
renderer: networkd
ethernets:
eth0:
dhcp4: no
addresses: [192.168.1.10/24]
routes:
- to: default
via: 192.168.1.1
metric: 100
nameservers:
addresses: [223.5.5.5, 119.29.29.29]改完执行 netplan try（会等待确认，配错可自动回滚），确认无误再用 netplan apply。远程操作时务必用 netplan try，直接 apply 一旦配错就永久失联。
第 3 层：DNS 解析排查
结论：先分清"网络不通"还是"只是名字解析不了"。 ping -c 4 223.5.5.5 能通而 ping -c 4 www.baidu.com 不通，就说明网络层没问题，故障 100% 在 DNS。
# 1. 测纯 IP 连通（绕过 DNS，阿里公共 DNS）
ping -c 4 223.5.5.5
# 2. 测域名解析 + 连通（走完整 DNS 流程）
ping -c 4 www.baidu.com
# 若报 Temporary failure in name resolution → DNS 问题
# 若能解析出 IP 但全丢包 → 网络层问题
# 3. 查当前生效的 DNS 配置
cat /etc/resolv.conf
resolvectl status # systemd-resolved（Ubuntu 24.04 默认）
# 4. 指定 DNS 服务器直接解析，判断是不是本地 DNS 的锅
dig @223.5.5.5 www.baidu.com +short
nslookup www.baidu.com 119.29.29.29Ubuntu 24.04 LTS 默认由 systemd-resolved 管理 DNS，/etc/resolv.conf 通常是指向 ../run/systemd/resolve/stub-resolv.conf 的软链接，nameserver 显示为 127.0.0.53。不要直接改这个文件，正确做法是改 netplan 的 nameservers，或通过 resolvectl：
# 临时为指定网卡设置 DNS（重启失效）
resolvectl dns eth0 223.5.5.5 119.29.29.29
resolvectl domain eth0 ~.
resolvectl status eth0
# 刷新缓存并重测
resolvectl flush-caches
systemd-resolve --statistics # 查看解析成功/失败计数
# 检查 systemd-resolved 是否在运行
systemctl status systemd-resolved
journalctl -u systemd-resolved --since "10 min ago"第 4 层：出方向策略排查（安全组 / NAT / 代理）
结论：本机网络配置全对却仍上不了网，八成是出方向被策略拦了。 云服务器这一层最常见，因为它不看机器内的配置，只在云平台控制台生效。
# 1. 查看本机 iptables 出方向规则
iptables -L OUTPUT -n -v --line-numbers
iptables -t nat -L POSTROUTING -n -v # 做网关/NAT 的机器必查
# 2. 查 nftables（Ubuntu 24.04 默认后端）
nft list ruleset | head -60
# 3. 检查是否配置了代理环境变量（配错代理是高频隐形故障）
env | grep -i proxy
cat /etc/environment | grep -i proxy
# 若 http_proxy 指向已失效的地址，apt/curl 会全部超时
# 4. 绕过代理直连测试
curl -I --noproxy '*' https://www.baidu.com
curl -I -x http://代理IP:端口 https://www.baidu.com # 指定代理测试云厂商侧需要检查的三项（以控制台为准，截至 2026 年各家命名略有差异）：
- 安全组出方向规则：默认多为"允许全部出方向"，若被改成白名单，需放行 TCP 80/443、UDP 53 与 ICMP。
- 弹性公网 IP / NAT 网关：未绑定 EIP 或未配置 SNAT 的私有子网机器，天生没有出网能力。
- 网络 ACL 与带宽：出方向带宽跑满或 ACL 拒绝，表现为间歇性超时。
# 5. 用 mtr 定位丢包发生在哪一跳
mtr -r -c 30 -n 223.5.5.5
# 看 Loss% 列：本机网关那跳就丢 → 网关/安全组问题；中间跳丢 → 运营商链路问题
# 6. 分端口测试，判断是"全封"还是"只封特定端口"
nc -zv -w 3 223.5.5.5 53
nc -zv -w 3 1.1.1.1 443网络管理服务：NetworkManager 与 systemd-networkd
结论：Ubuntu 24.04 LTS 上两套网络管理服务不能同时管同一张网卡，冲突会导致配置反复被覆盖。 服务器场景推荐 systemd-networkd，桌面或需要 Wi-Fi 的场景用 NetworkManager。
# 查看谁在管理网络
networkctl status
systemctl status systemd-networkd NetworkManager
# NetworkManager 侧的常用命令
nmcli device status
nmcli connection show
nmcli connection up eth0
nmcli device reapply eth0
# 查网络服务日志（定位 DHCP 失败、配置未加载等问题）
journalctl -u systemd-networkd --since "30 min ago" | tail -40
journalctl -u NetworkManager --since "30 min ago" | tail -40# 一条命令跑完基础体检，建议直接保存为脚本
echo "=== ip a ==="; ip -br a
echo "=== ip route ==="; ip route
echo "=== resolv.conf ==="; cat /etc/resolv.conf
echo "=== ping IP ==="; ping -c 2 -W 2 223.5.5.5 | tail -2
echo "=== ping 域名 ==="; ping -c 2 -W 2 www.baidu.com | tail -2
企业QQ咨询
