我目前正在运行 ubuntu 20.04 LTS
所有软件包都是最新的。
使用Ping 8.8.8.8不起作用。第 {some number} 次 ping 后随机停止，并且出现“数据包丢失”。然而，当我访问实际的服务器 IP（数字）时，它神奇地开始监听返回数据包。
访问服务器杂项网页不起作用。但是当我访问实际的服务器 IP 时，它也神奇地开始响应。
我尝试用书上所有的技巧（我知道的）来解决问题。我重新配置了 netplan 和 DNS。我释放并续订了新 IP，但这并没有解决问题。我在 google DNS 和 Cloudflare DNS 之间切换，但没有成功。
我已经测试过这不是路由器问题，因为我的 Windows 机器ping 8.8.8.8没有“数据包丢失”。而且我确信这不是传输过程中的数据包丢失，因为我已将以太网电缆换成了已知良好的电缆。
以上内容也适用于 apt-get，除非我访问我的服务器 IP 并重试 apt-get 过程，否则由于某种原因，ubuntu 包服务器将无法被识别。
我在这里感到非常绝望，因为我需要维护服务，所以任何帮助都将不胜感激。
- 当前 netplan 配置
- 路由器当前使用 8.8.8.8 和 8.8.4.4 作为 DNS 解析器
应 netbat 的要求提供附加信息：
ip addr回复如下：
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP group default qlen 1000
link/ether b4:2e:99:93:b4:0b brd ff:ff:ff:ff:ff:ff
inet 192.168.0.3/24 brd 192.168.0.255 scope global dynamic enp4s0
valid_lft 85891sec preferred_lft 85891sec
inet6 2002:7076:ae9b:0:b62e:99ff:fe93:b40b/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 2246sec preferred_lft 1646sec
inet6 fe80::b62e:99ff:fe93:b40b/64 scope link
valid_lft forever preferred_lft forever
3: ip_vti0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
link/ipip 0.0.0.0 brd 0.0.0.0
4: br-1f1b9a3082c0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:71:7d:6f:db brd ff:ff:ff:ff:ff:ff
inet 172.22.0.1/16 brd 172.22.255.255 scope global br-1f1b9a3082c0
valid_lft forever preferred_lft forever
inet6 fe80::42:71ff:fe7d:6fdb/64 scope link
valid_lft forever preferred_lft forever
5: br-3c0161ddec68: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:0d:93:4e:af brd ff:ff:ff:ff:ff:ff
inet 172.23.0.1/16 brd 172.23.255.255 scope global br-3c0161ddec68
valid_lft forever preferred_lft forever
inet6 fe80::42:dff:fe93:4eaf/64 scope link
valid_lft forever preferred_lft forever
6: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:d0:b9:75:7a brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
inet6 fe80::42:d0ff:feb9:757a/64 scope link
valid_lft forever preferred_lft forever
7: br-7a5c6f0f89f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:c7:f0:51:bc brd ff:ff:ff:ff:ff:ff
inet 172.18.0.1/16 brd 172.18.255.255 scope global br-7a5c6f0f89f1
valid_lft forever preferred_lft forever
8: br-f34cf0cbdd41: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:6b:10:be:6a brd ff:ff:ff:ff:ff:ff
inet 172.21.0.1/16 brd 172.21.255.255 scope global br-f34cf0cbdd41
valid_lft forever preferred_lft forever
inet6 fe80::42:6bff:fe10:be6a/64 scope link
valid_lft forever preferred_lft forever
9: br-fe65b7ed9ee0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:02:84:1d:1c brd ff:ff:ff:ff:ff:ff
inet 192.168.0.1/20 brd 192.168.15.255 scope global br-fe65b7ed9ee0
valid_lft forever preferred_lft forever
11: veth7153d2c@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
link/ether ea:8b:11:af:8c:33 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 fe80::e88b:11ff:feaf:8c33/64 scope link
valid_lft forever preferred_lft forever
13: veth4c6a7c3@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-f34cf0cbdd41 state UP group default
link/ether 8a:f9:27:2c:e6:c9 brd ff:ff:ff:ff:ff:ff link-netnsid 1
inet6 fe80::88f9:27ff:fe2c:e6c9/64 scope link
valid_lft forever preferred_lft forever
15: veth925bf9a@if14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-1f1b9a3082c0 state UP group default
link/ether c6:3f:61:c2:e4:ad brd ff:ff:ff:ff:ff:ff link-netnsid 2
inet6 fe80::c43f:61ff:fec2:e4ad/64 scope link
valid_lft forever preferred_lft forever
ip route返回以下内容：
default via 192.168.0.1 dev enp4s0 proto dhcp src 192.168.0.3 metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.18.0.0/16 dev br-7a5c6f0f89f1 proto kernel scope link src 172.18.0.1 linkdown
172.21.0.0/16 dev br-f34cf0cbdd41 proto kernel scope link src 172.21.0.1
172.22.0.0/16 dev br-1f1b9a3082c0 proto kernel scope link src 172.22.0.1
172.23.0.0/16 dev br-3c0161ddec68 proto kernel scope link src 172.23.0.1 linkdown
192.168.0.0/24 dev enp4s0 proto kernel scope link src 192.168.0.3
192.168.0.0/20 dev br-fe65b7ed9ee0 proto kernel scope link src 192.168.0.1 linkdown
192.168.0.1 dev enp4s0 proto dhcp scope link src 192.168.0.3 metric 100
ip neigh返回以下内容：
192.168.0.4 dev enp4s0 lladdr ee:8b:8b:69:64:85 STALE
172.22.0.2 dev br-1f1b9a3082c0 lladdr 02:42:ac:16:00:02 STALE
192.168.0.9 dev enp4s0 lladdr b2:e0:62:18:82:a1 STALE
192.168.0.6 dev enp4s0 lladdr 08:66:98:8c:c5:38 STALE
192.168.0.1 dev enp4s0 lladdr 34:98:b5:a0:74:7c REACHABLE
192.168.0.8 dev enp4s0 lladdr f0:18:98:2f:c5:c1 STALE
[REDACTED PUB IP] dev enp4s0 lladdr 34:98:b5:a0:74:7c STALE
192.168.0.2 dev enp4s0 lladdr 2c:f0:5d:e3:b2:28 REACHABLE
172.17.0.2 dev docker0 lladdr 02:42:ac:11:00:02 STALE
192.168.0.5 dev enp4s0 lladdr 9c:32:ce:7f:bf:09 STALE
172.17.0.3 dev docker0 lladdr 02:42:ac:11:00:03 STALE
172.21.0.2 dev br-f34cf0cbdd41 lladdr 02:42:ac:15:00:02 STALE
fe80::3698:b5ff:fea0:747c dev enp4s0 lladdr 34:98:b5:a0:74:7c router REACHABLE
我使用ping 8.8.8.8并让它运行来测试连接。
64 bytes from 8.8.8.8: icmp_seq=36 ttl=118 time=3.56 ms
64 bytes from 8.8.8.8: icmp_seq=37 ttl=118 time=4.09 ms
64 bytes from 8.8.8.8: icmp_seq=38 ttl=118 time=4.17 ms
^C
--- 8.8.8.8 ping statistics ---
46 packets transmitted, 38 received, 17.3913% packet loss, time 45217ms
rtt min/avg/max/mdev = 3.504/25.263/814.588/129.764 ms
当不再并且永远不会再次 ping 时，使用 Control+C 退出。在此特定会话中，ping 数据包在 38 处结束，其余数据包“丢失”。
对路由器网关的 ping192.168.0.1长期稳定，1202 个数据包的丢包率为 0%。我已将路由器配置为将 IP 地址保留192.168.0.3给 MAC 地址，并且不会出现冲突地址。
但是我的其他机器没有这个问题，所以我坚信这是一个 Ubuntu 配置问题，我无法自行解决。
答案1
您提供的信息太少，无法彻底分析问题。我欢迎对这些命令的回复：
ip addr
ip route
ip neigh
当 Google DNS 8.8.8.8.8 响应 ping 时输入命令，当 ping 没有响应时再次输入命令。比较这两个状态会告诉你很多信息。
检查默认网关（即路由器）的 IP 地址是否可用并且长期可靠地响应 ping 也很重要。您可以使用以下命令查找其地址ip route：
ip route | grep "default" | cut -f 3 -d " "
路由器的 ping 响应是否长期稳定？如果不是，那么问题一定出在您的局域网 (LAN) 上。
导致此故障的一个可能原因是您的 Linux PC 与网络上的其他设备存在 IP 地址冲突。也许您的 DHCP 服务器没有提前检查是否有要分配的空闲地址。因此，可能会发生地址分配冲突。但这只是猜测，可能还有其他原因。
编辑
请添加连接已断开时的状态的命令响应即 45 秒后。您只给出了正常状态下的响应。
默认网关（路由器）仍然可用，但接口激活 45 秒后与外部地址的连接断开的情况非常罕见。要么网关丢失，与网络外部的连接同时断开，要么网关可用，与外部的连接仍然存在。
我假设您的网络上或 Ubuntu 系统上存在地址冲突。
查看您的桥接接口 br-fe65b7ed9ee0。它的地址为 192.168.0.1，与路由器地址冲突。在连接正常工作的状态下，桥接接口处于非活动状态。但如果系统在一段时间后尝试激活它，则会发生冲突，您将失去网络连接。您的桥接接口将响应 ping 而不是路由器，因此 ping 默认网关似乎有效。但只是表面上。