因此，令我怀疑的关键症状是，当我在 Ubuntu 上运行 ping 时，它需要大约一秒钟左右的时间才能开始打印，而在 OSX 笔记本电脑上几乎立即启动（我的笔记本电脑上没有 ubuntu，所以操作系统可能是巧合）。
通常我会怀疑 DNS，但这是我的 Ubuntu DNS 测试：
dig +trace www.stackoverflow.com
; <<>> DiG 9.16.1-Ubuntu <<>> +trace www.stackoverflow.com
;; global options: +cmd
;; Received 40 bytes from 10.0.0.1#53(10.0.0.1) in 7 ms
mtr、ping 和速度测试的指标都很好。例如，这是 Ubuntu 桌面上的 ping：
ping www.stackoverflow.com
PING stackoverflow.com (151.101.1.69) 56(84) bytes of data.
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=1 ttl=57 time=9.87 ms
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=2 ttl=57 time=8.95 ms
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=3 ttl=57 time=9.17 ms
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=4 ttl=57 time=8.83 ms
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=5 ttl=57 time=9.14 ms
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=6 ttl=57 time=9.08 ms
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=7 ttl=57 time=9.16 ms
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=8 ttl=57 time=9.03 ms
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=9 ttl=57 time=8.91 ms
但关键是它花了将近两秒钟才开始打印 ping 时间。
我意识到了这一点可能与 Ubuntu 完全无关，但我猜测这里可能有一些 Linux 内部知识或调试知识可能会有所帮助。
我可以查看 ping 的 strace 输出，但不太确定我在寻找什么。strace 打印了一些内容，然后在执行任何操作时挂起两秒钟。这是我在此时将其杀死时的输出
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_mdns4_minimal.so.2", O_RDONLY|O_CLOEXEC) = 5
read(5, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240\23\0\0\0\0\0\0"..., 832) = 832
fstat(5, {st_mode=S_IFREG|0644, st_size=18504, ...}) = 0
mmap(NULL, 20496, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 0x7f565ae48000
mmap(0x7f565ae49000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x1000) = 0x7f565ae49000
mmap(0x7f565ae4b000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x3000) = 0x7f565ae4b000
mmap(0x7f565ae4c000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x3000) = 0x7f565ae4c000
close(5) = 0
mprotect(0x7f565ae4c000, 4096, PROT_READ) = 0
munmap(0x7f565ae4e000, 155550) = 0
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 5
fstat(5, {st_mode=S_IFREG|0644, st_size=155550, ...}) = 0
mmap(NULL, 155550, PROT_READ, MAP_PRIVATE, 5, 0) = 0x7f565ae4e000
close(5) = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_dns.so.2", O_RDONLY|O_CLOEXEC) = 5
read(5, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 #\0\0\0\0\0\0"..., 832) = 832
fstat(5, {st_mode=S_IFREG|0644, st_size=31176, ...}) = 0
mmap(NULL, 32984, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 0x7f565ae3f000
mmap(0x7f565ae41000, 16384, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x2000) = 0x7f565ae41000
mmap(0x7f565ae45000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x6000) = 0x7f565ae45000
mmap(0x7f565ae46000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x6000) = 0x7f565ae46000
close(5) = 0
mprotect(0x7f565ae46000, 4096, PROT_READ) = 0
munmap(0x7f565ae4e000, 155550) = 0
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 5
setsockopt(5, SOL_IP, IP_RECVERR, [1], 4) = 0
connect(5, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.1.1")}, 16) = 0
poll([{fd=5, events=POLLOUT}], 1, 0) = 1 ([{fd=5, revents=POLLOUT}])
sendmmsg(5, [{msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base=">\326\1\0\0\1\0\0\0\0\0\0\3www\rstackoverflow\3c"..., iov_len=39}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=39}, {msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="w\256\1\0\0\1\0\0\0\0\0\0\3www\rstackoverflow\3c"..., iov_len=39}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=39}], 2, MSG_NOSIGNAL) = 2
poll([{fd=5, events=POLLIN}], 1, 5000^C) = ? ERESTART_RESTARTBLOCK (Interrupted by signal)
strace: Process 1242328 detached
欢迎任何想法。
更新：
我现在怀疑是路由器/调制解调器的连接问题。但非常奇怪的是，接下来是慢的在我的 Ubuntu 桌面上，但在笔记本电脑（OSX）上正常。
ping dsldevice.lan
PING dsldevice.lan (192.168.1.254) 56(84) bytes of data.
64 bytes from dsldevice.lan (192.168.1.254): icmp_seq=1 ttl=63 time=2.08 ms
64 bytes from dsldevice.lan (192.168.1.254): icmp_seq=2 ttl=63 time=1.89 ms
更新：
经过一番折腾，运行了 apt update 并重启后，似乎已经恢复正常了。我查看了之前（问题发生时）和之后的 tcpdump，没有发现什么异常。
仍然不知道，但现在问题暂时消失了。如果再次出现，将更新。这似乎是一个很好的学习练习。
更新：（这篇文章越来越长了）
关于 MTU 问题的参考，我正在从 Ubuntu 无线连接到有线连接到 plusnet 光纤连接的 netgear 路由器（使用来自场所的 ADSL）。
更新：测试 mtu 大小，如下https://mike632t.wordpress.com/2019/03/03/determine-mtu-size-using-ping/
当我针对 8.8.8.8 测试 mtu 时，我觉得有些地方出了问题？对于较大的尺寸，我收到“消息太长”错误，但当我减小尺寸时，该消息不再出现，但直到尺寸为 68=96-28 时，我才会出现 100% 的数据包丢失。也许出于某种原因，这是意料之中的？
ping -c 4 -M do -s 1472 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1472(1500) bytes of data.
From 192.168.1.254 icmp_seq=1 Frag needed and DF set (mtu = 1488)
ping: local error: message too long, mtu=1488
ping: local error: message too long, mtu=1488
ping -s $((97 - 28)) -D 8.8.8.8 -c 1
PING 8.8.8.8 (8.8.8.8) 69(97) bytes of data.
--- 8.8.8.8 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
ping -s $((96 - 28)) -D 8.8.8.8 -c 1
PING 8.8.8.8 (8.8.8.8) 68(96) bytes of data.
[1620817285.571725] 76 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=10.7 ms
--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 10.680/10.680/10.680/0.000 ms
更新：另一个数据点。
我怀疑这更像是一个网络论坛，因为我会发现这与 Ubuntu 驱动程序方面的事情无关，正如我之前所怀疑的那样，但目前还不确定
ping -c 3 -s $((1489 - 28)) -M do bbc.co.uk
PING bbc.co.uk (151.101.0.81) 1461(1489) bytes of data.
ping: local error: message too long, mtu=1488
ping: local error: message too long, mtu=1488
ping: local error: message too long, mtu=1488
--- bbc.co.uk ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2037ms
ping -c 3 -s $((1488 - 28)) -M do bbc.co.uk
PING bbc.co.uk (151.101.0.81) 1460(1488) bytes of data.
1468 bytes from 151.101.0.81 (151.101.0.81): icmp_seq=1 ttl=58 time=11.8 ms
1468 bytes from 151.101.0.81 (151.101.0.81): icmp_seq=2 ttl=58 time=12.0 ms
1468 bytes from 151.101.0.81 (151.101.0.81): icmp_seq=3 ttl=58 time=10.7 ms
--- bbc.co.uk ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 10.702/11.519/12.029/0.583 ms
更新：
请求的 tracepath 查询结果。这是在 mtu 1500 设置下。请注意，常规 mtr 测试显示速度和延迟良好，并且数据包较少。
tracepath www.ebay.com
1?: [LOCALHOST] pmtu 1488
1: www.routerlogin.com 1.048ms
1: www.routerlogin.com 1.003ms
2: dsldevice.lan 2.037ms
3: no reply
4: no reply
5: 128.hiper04.sheff.dial.plus.net.uk 10.954ms asymm 7
6: peer3-et3-1-1.slough.ukcore.bt.net 85.034ms asymm 7
7: peer2-xe8-0-2.telehouse.ukcore.bt.net 25.399ms asymm 8
8: no reply
9: no reply
10: no reply
11: no reply
更新：
只是为了确认，mtu 设置为 1500。
ip link | grep wlxa09f10b9ff56
3: wlxa09f10b9ff56: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
更新：针对 8.8.8.8 的 ping 测试完整日志
$ ping -c 4 -M do -s 1472 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1472(1500) bytes of data.
From 192.168.1.254 icmp_seq=1 Frag needed and DF set (mtu = 1488)
ping: local error: message too long, mtu=1488
ping: local error: message too long, mtu=1488
ping: local error: message too long, mtu=1488
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3028ms
$ ping -c 4 -M do -s 1462 8.8.8.8 # may show fragmentation
PING 8.8.8.8 (8.8.8.8) 1462(1490) bytes of data.
ping: local error: message too long, mtu=1488
ping: local error: message too long, mtu=1488
ping: local error: message too long, mtu=1488
ping: local error: message too long, mtu=1488
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3049ms
$ ping -c 4 -M do -s 1452 8.8.8.8 # no fragmentation?
PING 8.8.8.8 (8.8.8.8) 1452(1480) bytes of data.
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3003ms
$ ping -c 4 -M do -s 1453 8.8.8.8 # still no fragmentation?
PING 8.8.8.8 (8.8.8.8) 1453(1481) bytes of data.
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3005ms
$ ping -c 4 -M do -s 69 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 69(97) bytes of data.
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3004ms
$ ping -c 4 -M do -s 68 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 68(96) bytes of data.
76 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=60.2 ms
76 bytes from 8.8.8.8: icmp_seq=2 ttl=116 time=9.07 ms
76 bytes from 8.8.8.8: icmp_seq=3 ttl=116 time=8.89 ms
76 bytes from 8.8.8.8: icmp_seq=4 ttl=116 time=9.04 ms
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 8.887/21.802/60.215/22.177 ms
更新：
不管怎样，我在 Plusnet 上“使用光纤”，但 ADSL 连接较短（反正他们就是这么告诉我的）。根据此线程，这意味着 Plusnet 路由器默认为 1500，并且我已将所有上游设备（netgear 路由器、ubuntu 桌面）也设置为 1500。
答案1
您的问题在于 DSL 连接的 MTU 设置。
Ubuntu 的网络配置中有一个 MTU 设置，而路由器中有一个 WAN MTU 设置。
对于 DSL，常见的 MTU 设置是 1492。请先尝试此值，然后查看您的网站现在是否可以访问。
要确定正确的设置，请从所有 MTU 设置 = 1500 和 VPN = 关闭开始。（VPN 需要不同的测试）。
在里面terminal：
ping [-c 计数] [-M 执行] [-s 数据包大小] [主机]
使用的选项是：
c count：ping 次数M hint：选择路径 MTU 发现策略。可以是do（禁止碎片，即使是本地碎片），want（进行 PMTU 发现，当数据包大小较大时在本地进行碎片），或dont（不设置 DF 标志）。s packet_size：指定要发送的数据字节数。
您应该始终从 1472 开始，然后每次减少 10。一旦收到回复，就增加 1，直到收到碎片数据包。取该值（最后一个好值）并将 28 添加到该值以考虑各种 TCP/IP 标头。例如，假设 1452 是合适的数据包大小（您第一次收到对 ping 的 ICMP 回复）。实际的 MTU 大小将是 1480，这是我们正在使用的网络的最佳值。
ping -c 4 -M do -s 1472 8.8.8.8# 这可能会显示碎片
ping -c 4 -M do -s 1462 8.8.8.8# 可能会显示碎片
ping -c 4 -M do -s 1452 8.8.8.8# 没有碎片？
ping -c 4 -M do -s 1453 8.8.8.8# 仍然没有碎片？