-W在 Debian Buster 上，根据标志 to的描述来判断ping，我认为我可以使用如下内容：
ping -i 10 -W 5 8.8.8.8
持续监控互联网连接。如果连接中断，我预计每次 ping 后 5 秒（间隔 10 秒）ping会报告没有响应。相反，会发生输出暂停（至少 60 秒，可能无限期）直到连接恢复，然后在该暂停期间发送的所有 ping 完成并仅显示很长的 pong 时间。所以输出看起来像这样：
64 bytes from 8.8.8.8: icmp_seq=36 ttl=117 time=11.705 ms
64 bytes from 8.8.8.8: icmp_seq=37 ttl=117 time=11.963 ms
64 bytes from 8.8.8.8: icmp_seq=38 ttl=117 time=11.900 ms
64 bytes from 8.8.8.8: icmp_seq=39 ttl=117 time=11.288 ms <-- connection interrupted after this line
64 bytes from 8.8.8.8: icmp_seq=40 ttl=117 time=65697 ms <-- this line takes ~65s to appear
64 bytes from 8.8.8.8: icmp_seq=41 ttl=117 time=55880 ms
64 bytes from 8.8.8.8: icmp_seq=42 ttl=117 time=45116 ms
64 bytes from 8.8.8.8: icmp_seq=43 ttl=117 time=35949 ms
64 bytes from 8.8.8.8: icmp_seq=44 ttl=117 time=25266 ms
64 bytes from 8.8.8.8: icmp_seq=45 ttl=117 time=15943 ms
64 bytes from 8.8.8.8: icmp_seq=46 ttl=117 time=5818 ms
64 bytes from 8.8.8.8: icmp_seq=47 ttl=117 time=11.578 ms <--- connection restored before this ping
64 bytes from 8.8.8.8: icmp_seq=48 ttl=117 time=11.382 ms
64 bytes from 8.8.8.8: icmp_seq=49 ttl=117 time=11.624 ms
64 bytes from 8.8.8.8: icmp_seq=50 ttl=117 time=11.407 ms
64 bytes from 8.8.8.8: icmp_seq=51 ttl=117 time=11.864 ms
64 bytes from 8.8.8.8: icmp_seq=52 ttl=117 time=11.716 ms
正如我所期望的那样：
64 bytes from 8.8.8.8: icmp_seq=36 ttl=117 time=11.705 ms
64 bytes from 8.8.8.8: icmp_seq=37 ttl=117 time=11.963 ms
64 bytes from 8.8.8.8: icmp_seq=38 ttl=117 time=11.900 ms
64 bytes from 8.8.8.8: icmp_seq=39 ttl=117 time=11.288 ms <-- connection interrupted after this line
ping is down: no route to host
ping is down: no route to host
ping is down: no route to host
ping is down: no route to host
ping is down: no route to host
ping is down: no route to host
ping is down: no route to host
64 bytes from 8.8.8.8: icmp_seq=47 ttl=117 time=11.578 ms <--- connection restored before this ping
64 bytes from 8.8.8.8: icmp_seq=48 ttl=117 time=11.382 ms
64 bytes from 8.8.8.8: icmp_seq=49 ttl=117 time=11.624 ms
64 bytes from 8.8.8.8: icmp_seq=50 ttl=117 time=11.407 ms
64 bytes from 8.8.8.8: icmp_seq=51 ttl=117 time=11.864 ms
64 bytes from 8.8.8.8: icmp_seq=52 ttl=117 time=11.716 ms
根据这些问题，这是一个没有明确答案的常见问题：
- https://stackoverflow.com/questions/20359487/why-does-ping-not-timeout-in-linux
- https://stackoverflow.com/questions/18228886/ping-timeout-issues
- https://stackoverflow.com/questions/17951182/ping-timeout-command-w-not-working-for-android
- https://stackoverflow.com/questions/32976579/how-long-is-the-interval-for-a-ping-that-results-in-destination-host-unreachabl
- https://stackoverflow.com/questions/21639576/php-ping-on-linux-timeout-not-working
- https://serverfault.com/questions/570336/android-linux-ping-sends-another-packet-before-packet-timeout
所以总结两个问题：
- 有没有办法让 ping 报告超时后连接失败？
-W如果不是为了解决 (1)，那么设计的目的是什么？
答案1
问题的答案：
ping据我所知，没有任何内置内容。有两种解决方法：- 将单个 ping （例如
ping -c1 -W 5 8.8.8.8）包装在一个bash循环中，该循环会 grep 输出或检查返回标志并回显一些有用的输出。这是一个很好的例子：https://superuser.com/a/668124 - 该
-O标志立即显示失败消息。它与它无关-W并且没有与之相关的超时，因此它不完全相同，但至少连接问题应该是明显的。
- 将单个 ping （例如
-W除非也指定，否则似乎没有任何目的来-c限制数据包的数量。如果-c指定，则-W类似于，-w只不过超时是针对每个 ping 而不是整体。