可靠网络连通性检测必须通过轻量HTTP交互验证，首选HEAD请求https://connectivitycheck.gstatic.com/generate_204并校验204状态码，配合超时控制、HttpClient复用及双因子缓存策略。
别用 NetworkInterface.GetIsNetworkAvailable() 判断“能不能上网”——它只告诉你网卡有没有插线或开 Wi-Fi，不保证能访问互联网。
为什么 InternetGetConnectedState 也不靠谱
这个 WinINet API 看起来很“系统级”，但实际行为和 GetIsNetworkAvailable() 类似：它返回 true 只表示系统认为“当前配置下应该能连”，比如检测到代理设置、LAN 配置完成、甚至只是注册表里写了“已连接”。它不发任何网络包，不验证 DNS、不检查路由、不绕过防火墙。实测中，即使电脑被公司策略强制离线、DNS 被劫持、或仅连着一个没上外网的交换机，它照样返回 true。
更麻烦的是，它在 .NET Core/.NET 5+ 上默认不可用（WinINet 已被弃用），跨平台项目直接编译失败。即便在 Windows Desktop 上用，也拿不到真实连通性反馈。
常见错误现象：
- 调用后返回
true，但后续HttpClient请求超时或抛HttpRequestException - 用户反馈“显示已联网，但头像加载不出来”，日志里却看到
GetIsNetworkAvailable() == true和InternetGetConnectedState() == true并存
用 HttpClient 发 HEAD 请求才是唯一可靠方式
真实连通性必须靠一次轻量、可控、可超时的网络交互来验证。首选 Google 的连通性端点：https://connectivitycheck.gstatic.com/generate_204（国内可用性高、无重定向、响应体为空、HTTP 204 状态码明确）。
实操建议：
- 用
HttpClient实例发HEAD，不是GET——避免下载 HTML 或图片导致延迟和误判 - 显式设置
client.Timeout = TimeSpan.FromSeconds(3)，默认 100 秒会卡死 UI 或阻塞后台任务 - 检查
response.StatusCode == HttpStatusCode.NoContent，不能只捕获异常——中间设备可能返回 403、302 或空响应而不抛异常 - 加备用地址，如
https://msftconnecttest.com/redirect，防单点失效
示例关键片段：
var client = _httpClient; // 复用 static readonly 或 DI 注入的实例
try {
var response = await client.SendAsync(new HttpRequestMessage(HttpMethod.Head, "https://connectivitycheck.gstatic.com/generate_204"), cancellationToken);
return response.StatusCode == HttpStatusCode.NoContent;
}
catch (OperationCanceledException) { return false; }
catch (HttpRequestException) { return false; }
别每次 new HttpClient，也别用 using 包裹
新手最常踩的坑是把 HttpClient 当成一次性对象：方法里 using var c = new HttpClient()，高频调用（比如每秒检测）会导致端口耗尽、DNS 缓存失效、TCP 连接不复用，最终出现 SocketException: Too many open files 或 HttpRequestException: Connection refused。
正确做法：
- .NET 5+ 项目：通过
IHttpClientFactory获取客户端，它自动管理连接池、DNS 刷新和瞬态错误恢复 - 简单场景：声明
private static readonly HttpClient _client = new() { Timeout = TimeSpan.FromSeconds(3) }; - 绝对不要在异步检测方法内部 new、dispose、或用
using
注意：如果项目需支持 HTTP/2 或自定义证书验证，IHttpClientFactory 的配置比手动 new 更可控。
离线状态要缓存，但别缓存太久
连通性检测本身有成本，不能每次点击按钮都发请求。建议用“状态 + 时间戳”双因子缓存：比如最近 15 秒内成功过，就直接返回 true；若失败，则最多每 5 秒重试一次，避免轮询压垮本地网络栈。
容易被忽略的点：
- UI 线程里做同步检测会卡界面，必须用
await+async，且超时时间要短（≤3 秒） - 某些企业环境会拦截或重定向
generate_204，此时应 fallback 到 DNS 解析测试（如Dns.GetHostAddressesAsync("one.one.one.one")），但它不能替代 HTTP 测试——能解析 DNS 不代表能建 TLS 连接 - 移动端（尤其是 iOS）对后台网络请求有限制，
generate_204在后台可能被系统静默丢弃，需结合平台生命周期事件判断
