Linux 服务器能通过公网SSH连接并 Ping 公网 IP，却无法访问公网域名

Linux 服务器能 Ping 公网 IP，却无法访问域名：DNS 故障排查记录

-------------------------------------------------

声明：本文由人工智能辅助写作

-------------------------------------------------

在维护一台远程 Linux 服务器时，我遇到了一个比较典型的网络问题：

服务器可以正常通过 SSH 从公网访问，服务器本身也能够 ping 通公网 IP，但执行：

ping www.baidu.com

或者：

curl https://www.baidu.com

却提示：

ping: www.baidu.com: 域名解析暂时失败

以及：

curl: (6) Could not resolve host: www.baidu.com

最终排查发现，问题并不在公网链路、默认网关或者 SSH 端口映射，而是：

服务器使用静态 IPv4 配置，但 NetworkManager 中没有配置 DNS，导致 systemd-resolved 没有可用的上游 DNS 服务器。

本文记录完整的定位思路、临时修复方法，以及比较安全的永久修复方案。

---

一、问题现象

服务器可以通过公网地址正常 SSH 登录，但服务器内部执行：

ping www.baidu.com

失败：

域名解析暂时失败

执行：

curl https://www.baidu.com

同样失败：

curl: (6) Could not resolve host: www.baidu.com

这种情况下，不要一看到 Could not resolve host 就立即修改 /etc/resolv.conf。

首先需要判断：

是服务器根本不能访问公网，还是仅仅 DNS 解析失败？

这是两个完全不同的问题。

---

二、第一步：判断公网链路是否正常

1. 查看服务器 IP

执行：

ip addr

例如服务器主业务网卡为：

eno1
192.168.1.100/24

另外可能还有 Docker 网桥、虚拟网卡、管理网卡等：

docker0
br-xxxxxxxx
eth0
vethxxxx

不要看到多张网卡就急着修改。

接下来查看真正的默认出口。

2. 查看默认路由

ip route

例如：

default via 192.168.1.1 dev eno1
192.168.1.0/24 dev eno1 proto kernel scope link src 192.168.1.100

这说明：

服务器
192.168.1.100
      │
      ▼
默认网关
192.168.1.1
      │
      ▼
Internet

此时真正承担公网出口的是 eno1。

---

三、依次测试三层网络

这是整个排查过程中非常实用的一组测试。

1. 测试默认网关

ping -c 4 192.168.1.1

如果成功，至少说明：

服务器到本地网关之间的网络是正常的。

2. 绕过 DNS，直接测试公网 IP

例如：

ping -c 4 223.5.5.5

也可以使用其他确定可访问的公网 IP。

如果公网 IP 能正常访问，那么：

服务器
 ↓
网关
 ↓
公网

这条链路基本没有问题。

3. 再测试域名

ping -c 4 www.baidu.com

如果最终呈现的是：

默认网关：        通
公网 IP：         通
www.baidu.com：   域名解析失败

那么故障范围已经可以大幅缩小：

IP 网络正常，DNS 解析异常。

---

四、检查 /etc/resolv.conf

执行：

cat /etc/resolv.conf

在 Ubuntu 等使用 systemd-resolved 的系统中，可能看到：

nameserver 127.0.0.53
options edns0 trust-ad

同时：

ls -l /etc/resolv.conf

可能得到：

/etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

很多人看到：

nameserver 127.0.0.53

第一反应会认为：

DNS 为什么是本机地址？是不是这里配置错了？

其实不是。

127.0.0.53 是 systemd-resolved 提供的本地 DNS Stub Resolver。

结构实际上是：

curl / ping / apt 等应用
          │
          ▼
      127.0.0.53
          │
          ▼
   systemd-resolved
          │
          ▼
      上游 DNS

因此关键不是：

127.0.0.53

而是：

systemd-resolved 有没有获得真正的上游 DNS？

---

五、检查 systemd-resolved

执行：

resolvectl status

本次故障中，主网卡出现了类似：

Link 2 (eno1)
Current Scopes: none
DefaultRoute setting: no

并且没有：

DNS Servers:

这就是一个非常重要的信号。

正常情况下，联网接口通常应该能够看到类似：

Current Scopes: DNS
Current DNS Server: x.x.x.x
DNS Servers: x.x.x.x

而现在实际上变成了：

应用
 │
 ▼
127.0.0.53
 │
 ▼
systemd-resolved
 │
 ▼
？

也就是：

systemd-resolved 正常运行，但根本不知道应该向哪个上游 DNS 查询。

所以域名当然无法解析。

---

六、安全的临时修复

如果服务器位于远程机房，而且当前只能通过 SSH 管理，修改网络配置一定要保守。

相比直接重启 NetworkManager 或重新激活网卡，一个风险比较低的临时方案是：

sudo resolvectl dns eno1 223.5.5.5 119.29.29.29

这里：

• eno1：需要联网的网卡；

• 223.5.5.5：公共 DNS；

• 119.29.29.29：另一个公共 DNS。

需要强调：

这里使用公共 DNS 的目的首先是诊断和临时恢复，并不意味着公用服务器应该永久使用这两个 DNS。

学校、企业、实验室或者数据中心可能有自己的内部 DNS。

---

这条命令会不会把 SSH 搞断？

通常不会。

resolvectl dns eno1 ...

修改的是 systemd-resolved 的运行时 DNS 设置。

它不会主动修改：

服务器 IP
默认网关
IP 路由表
SSH 服务
eno1 的 UP/DOWN 状态

也不会主动重新连接网卡。

因此对于远程服务器，这是一个风险相对较低的临时操作。

如果需要撤销：

sudo resolvectl revert eno1

即可恢复该接口由其他网络管理组件提供的 DNS 设置。

---

七、验证临时修复是否成功

首先：

resolvectl status eno1

修复后可能看到：

Link 2 (eno1)
Current Scopes: DNS
DefaultRoute setting: yes
Current DNS Server: 223.5.5.5
DNS Servers: 223.5.5.5
             119.29.29.29

然后直接测试解析：

resolvectl query www.baidu.com

如果能够返回 IP 地址，说明 systemd-resolved 已经能够正常解析。

再测试：

curl -I https://www.baidu.com

正常返回 HTTP Header 后，就可以确认：

DNS
 ↓
公网 TCP/IP
 ↓
HTTPS

整条链路已经恢复。

---

八、继续追查：DNS 为什么会丢失？

临时解决并不代表问题已经真正解决。

下一步需要确认：

谁在负责管理这张网卡？

执行：

nmcli device status

例如：

DEVICE    TYPE      STATE     CONNECTION
eno1      ethernet  已连接    有线连接 1

说明：

eno1 当前由 NetworkManager 管理，对应连接配置为 有线连接 1。

继续：

nmcli connection show

可以确认当前所有 NetworkManager Connection Profile。

---

九、查看 NetworkManager 的 IPv4 配置

执行：

nmcli -f ipv4.method,ipv4.addresses,ipv4.gateway,ipv4.dns,ipv4.ignore-auto-dns connection show "有线连接 1"

本次故障最终得到类似：

ipv4.method:            manual
ipv4.addresses:         192.168.1.100/24
ipv4.gateway:           192.168.1.1
ipv4.dns:               --
ipv4.ignore-auto-dns:   否

这里已经可以明确看到问题。

服务器配置的是：

IPv4 Method: manual

也就是静态 IPv4。

但配置内容只有：

IP      = 192.168.1.100/24
Gateway = 192.168.1.1
DNS     = 空

换句话说：

静态 IP       ✓
静态网关      ✓
DNS           ✗

这就是故障根源。

---

十、为什么 ignore-auto-dns=no 还是没有 DNS？

这也是一个容易产生误解的地方。

配置中可能显示：

ipv4.ignore-auto-dns: 否

它的意思是：

如果系统自动获得了 DNS，则不要忽略它。

但问题在于：

ipv4.method = manual

也就是说，这个连接使用的是静态 IPv4。

典型 DHCP 模式是：

DHCP
 ├── IP
 ├── Gateway
 └── DNS

而现在是：

manual
 ├── IP      手工填写
 ├── Gateway 手工填写
 └── DNS     没填写

既然没有 DHCP 或其他机制提供 DNS，那么：

ignore-auto-dns = no

也无法凭空产生一个 DNS 地址。

---

十一、为什么 nmcli 看不到 DNS，但 resolvectl 能看到？

临时执行：

resolvectl dns eno1 223.5.5.5 119.29.29.29

之后可能出现这种情况。

NetworkManager：

nmcli device show eno1

仍然没有：

IP4.DNS

但：

resolvectl status eno1

却能够看到：

DNS Servers: 223.5.5.5 119.29.29.29

这并不矛盾。

原因是两者管理的是不同层次。

NetworkManager
    │
    │ 保存持久网络配置
    ▼

systemd-resolved
    │
    │ 当前实际使用的 DNS
    ▼
DNS Resolver

我们使用 resolvectl dns 修改的是：

systemd-resolved 当前运行时状态

而没有修改：

NetworkManager 保存的 Connection Profile

因此：

当前 DNS 可以正常工作

但：

服务器重启 / 网卡重新连接后

临时 DNS 可能消失。

---

十二、公用服务器不建议直接永久写公共 DNS

如果服务器属于：

• 学校；

• 公司；

• 实验室；

• 数据中心；

• 公共计算集群；

永久修改之前最好先向网络管理机构确认：

这个网段按照网络规划应该使用什么 DNS？

因为机构内部 DNS 除了负责公网域名之外，还可能负责：

内部 GitLab
NAS
LDAP
集群节点
内部服务
企业域名
校内资源

如果直接把系统永久改成公共 DNS：

223.5.5.5
119.29.29.29

公网访问可能恢复，但内部域名可能无法解析。

---

十三、如何向管理机构报告这个问题？

可以提供以下信息：

服务器主接口：eno1

IPv4 配置：
manual

服务器地址：
192.168.1.100/24

默认网关：
192.168.1.1

NetworkManager 持久 DNS：
未配置

测试结果：
1. 默认网关可以 ping 通
2. 公网 IP 可以 ping 通
3. 公网域名无法解析
4. 临时通过 resolvectl 为 eno1 指定公共 DNS 后，
   域名解析立即恢复正常

然后明确询问：

请确认该服务器所在网段按照网络规划应该使用哪些 DNS 服务器，是否存在需要使用的内部 DNS。

这样比简单反馈：

“服务器上不了网。”

更容易让管理员快速定位问题。

---

十四、永久修复

假设管理机构给出的 DNS 为：

192.168.1.10
192.168.1.11

那么可以写入 NetworkManager 的持久 Connection Profile：

sudo nmcli connection modify "有线连接 1" \
    ipv4.dns "192.168.1.10 192.168.1.11"

如果确认允许长期使用公共 DNS，则可以类似设置：

sudo nmcli connection modify "有线连接 1" \
    ipv4.dns "223.5.5.5 119.29.29.29"

然后只读检查：

nmcli -f ipv4.dns connection show "有线连接 1"

应该得到：

ipv4.dns: 192.168.1.10,192.168.1.11

或者对应的公共 DNS。

---

十五、人在异地时，不要急着重新激活连接

这里是远程服务器维护非常重要的一点。

虽然修改：

nmcli connection modify ...

通常只是修改保存的连接配置，本身不会主动关闭网卡。

但不要为了“马上让持久配置生效”就随便执行：

nmcli connection down "有线连接 1"

这会直接关闭正在承担 SSH 的网络连接。

对于只有远程访问权限的服务器，这可能意味着：

SSH 立即断开，并且无法远程恢复。

同样，在没有带外管理、IPMI、iDRAC、iLO 或现场人员协助时，也不建议贸然执行：

systemctl restart NetworkManager

或者直接重新加载所有网络配置。

更稳妥的策略是：

当前运行状态
    │
    ├── 使用 resolvectl 临时 DNS
    │
    └── 网络已经恢复
              │
              ▼
修改 NetworkManager 持久配置
              │
              ▼
不主动重启网卡
              │
              ▼
等正常维护窗口或服务器下次正常重启

这样可以最大程度降低远程断连风险。

---

十六、以后再次出现同类问题时的快速排查流程

如果再次遇到：

Could not resolve host

或者：

域名解析暂时失败

可以快速执行：

ip route

确认默认路由。

然后：

ping -c 4 192.168.1.1

确认网关。

然后：

ping -c 4 223.5.5.5

确认公网 IP。

然后：

resolvectl status eno1

确认当前 DNS。

最后：

nmcli -f ipv4.method,ipv4.addresses,ipv4.gateway,ipv4.dns \
    connection show "有线连接 1"

确认持久 DNS。

如果结果是：

网关        ✓
公网 IP     ✓
域名解析    ✗
DNS Servers 空
ipv4.dns    --

那么基本就是同一类 DNS 配置问题。

---

十七、快速修复速查

临时修复

确认机构允许临时访问公共 DNS 后：

sudo resolvectl dns eno1 223.5.5.5 119.29.29.29

验证：

resolvectl query www.baidu.com

curl -I https://www.baidu.com

---

查看当前 DNS

resolvectl status eno1

---

查看持久 DNS

nmcli -f ipv4.dns connection show "有线连接 1"

---

永久写入 DNS

使用管理员提供的 DNS：

sudo nmcli connection modify "有线连接 1" \
    ipv4.dns "<DNS1> <DNS2>"

---

撤销 resolvectl 临时设置

sudo resolvectl revert eno1

---

十八、远程维护时需要谨慎的命令

如果当前 SSH 正依赖 eno1，不要在没有恢复手段的情况下贸然执行：

nmcli connection down "有线连接 1"

以及：

systemctl restart NetworkManager

对于远程服务器，修改网络配置最重要的原则之一就是：

能只改 DNS，就不要重启网卡；能先临时恢复，就不要立即重载整个网络。

---

总结

这次故障的完整链路实际上非常简单：

服务器静态 IPv4 配置
       │
       ├── IP       ✓
       ├── Gateway  ✓
       └── DNS      ✗
              │
              ▼
systemd-resolved 没有上游 DNS
              │
              ▼
127.0.0.53 无法完成域名解析
              │
              ▼
ping www.baidu.com
curl www.baidu.com
              │
              ▼
Could not resolve host

而公网 IP 本身仍然可以正常访问，所以：

ping 223.5.5.5

并不会受到影响。

最终解决思路可以浓缩成一句话：

先通过“网关 → 公网 IP → 域名”三层测试判断是不是 DNS；临时恢复使用 resolvectl，永久修复则在 NetworkManager Connection Profile 中补齐 ipv4.dns。对于学校、公司或实验室公用服务器，永久 DNS 地址应优先向网络管理机构确认，而不要默认长期使用公共 DNS。