Ping 默认超时5秒过长，需显式设timeout（如1000ms）；仅ICMP通不等于网络可用，应结合DNS、端口探测或HTTP健康检查；.NET Core+改用系统ping工具，Linux容器需预装iputils-ping；Ping非线程安全且须Dispose。

用 Ping 类发包判断连通性，但默认超时太长

直接 new 一个 ping 实例调 send 或 sendasync 是最常用做法，但默认超时是 5 秒——对 ui 响应或高频探测来说太慢，而且不设超时可能卡死线程。

• 必须显式传入 timeout 参数，比如 ping.Send("8.8.8.8", 1000) 控制在 1 秒内返回
• 别依赖 PingReply.Status == IPStatus.Success 就断定“能上网”，它只说明 ICMP 包通了；防火墙可能放行 ping 却拦截 HTTP
• 本地回环（"127.0.0.1"）或本机网关地址（如 "192.168.1.1"）比公网地址更适合作为“网络就绪”信号

Ping 在 .NET Core / .NET 5+ 上行为有变化

从 .NET Core 2.1 开始，Ping 类底层改用系统原生 ping 工具（Linux/macOS 调 ping 命令，Windows 调 ICMP API），不再依赖旧版 System.Net.NetworkInformation 的托管实现。这意味着：

• Linux 容器里跑 Ping 可能失败——因为默认没装 iputils-ping，得加 RUN apt-get install -y iputils-ping
• 某些精简版 Windows IoT 或无管理员权限的沙箱环境，Ping 会抛 AccessViolationException 或直接返回 IPStatus.Unknown
• PingOptions.Ttl 和 DontFragment 在跨平台时表现不一致，生产环境慎用

别把 Ping 当网络可用性唯一依据

很多业务逻辑误以为 “Ping 通 = 可以发 HTTP 请求”，结果上线后发现 DNS 解析失败、代理没配、端口被封，照样连不上服务。

C函数速查手册（CHM版）

C函数速查手册（CHM版）

下载

• 如果目标是验证 API 可用，不如直接 HttpClient 发个 HEAD 请求到 /health 端点，超时设为 2 秒
• 需要区分“物理层连通”和“应用层可达”，Ping 只管前者；后者得结合 DNS 查询（Dns.GetHostEntry）、端口探测（TcpClient.ConnectAsync）一起看
• 云环境里，安全组常禁止 ICMP，但允许 TCP 流量——这时候 Ping 永远失败，却不代表服务不可用

异步用法容易漏掉异常处理和资源释放

SendAsync 返回 Task<pingreply></pingreply>，但很多人只 await 却忽略 AggregateException 或未检查 PingReply.Status。

• 必须用 try/catch 包住 await 表达式，捕获 InvalidOperationException（如对象已释放）、SocketException（网络不可达）
• Ping 对象不是线程安全的，不要复用同一个实例并发调 SendAsync；每次 new 一个更稳妥
• 用完记得调 Dispose()，尤其在循环探测场景下，否则可能堆积未关闭的 socket 句柄

实际写的时候，最常被跳过的其实是「超时值设多少合适」和「失败后要不要降级探测方式」——这两个点没想清楚，Ping 就容易变成伪健康检查。