Roxi先分清状态提示与真实断网
Windows 使用 NCSI 判断连接能力，其中包括主动 HTTP 探测和被动观察。浏览器可能走自己的代理，而系统探测走另一条路径；所以某个网页打开，不能证明探测成功，也不能证明所有应用都能联网。反过来，图标异常也不等于网络完全中断。
- 记录 Windows 版本、时间、接入网络、代理模式和图标提示。另列一个能打开的公开网页，以及实际失败的应用动作。
- 刷新网页产生新请求，不只看已缓存的页面。如果网页和应用都失败，先按普通联网故障处理。
- 确认是否处于酒店或校园认证网络。认证页尚未完成时，先通过网络提供方的正式入口登录，再回到原应用。
对默认探测地址做一次只读检查
Microsoft 文档说明，Windows 10 1607 及以后默认 HTTP 探测使用下面的地址，正常响应应为 HTTP 200，正文为 Microsoft Connect Test。组织可自定义探测端点，因此默认地址测试不适用于所有受管电脑。Windows 11 使用 HTTP 探测，DNS 查询成功本身不算完成。
curl.exe -q --noproxy "*" --connect-timeout 10 --max-time 20 -i http://www.msftconnecttest.com/connecttest.txt-q 必须紧跟 curl.exe，用于跳过默认 curl 配置；--noproxy "*" 只让本次 curl 不使用显式代理，不能绕过 TUN、企业 VPN 或网关。未加 -L，便于看到认证重定向。此命令使用用户进程和当前路由，不是让 NCSI 本身执行探测；成功仅说明这一请求可达。HTTP 在这里是官方探测协议，不应用来发送账号或其他秘密。
| 观察到的结果 | 下一步 |
|---|---|
| 200 且正文符合预期 | 继续核对系统探测使用的接口、代理与策略 |
| 跳转认证页或返回其他正文 | 先确认接入网络认证和拦截情况 |
| 403、连接拒绝或超时 | 结合错误和时间检查代理、网关及规则 |
| 无法解析主机名 | 检查当前解析路径；不要直接认定为污染 |
一次只改变一个代理条件
- 先记下系统代理、PAC 和客户端当前状态。个人设备在业务允许时做一次代理开启与关闭的对照；切换会中断现有连接，先保存工作。不要停用组织要求的 VPN。
- 结合客户端连接记录查看探测域名命中了什么规则。如果浏览器可用而探测被拒绝，检查是否有自己添加的屏蔽规则，或 PAC 指向了不可达代理。
- 只撤销有证据相关的个人规则，再重复原来的访问。组织网络应将探测域名、错误和时间交给管理员，不自行清空防火墙。
探测服务的地址可能变化。Microsoft 建议不要依赖某个历史 IP 固定放行；规则应按环境采用主机名或相关服务等合适条件。也不应在 hosts 中伪造结果、改写探测正文，或关闭主动探测来“修好图标”。这些做法会损害判断依据。
回到系统状态和原应用验收
- 恢复计划长期使用的网络和代理配置。在可中断连接时重新连接 Wi-Fi，让系统根据网络变化重新判断；不要期待 curl 成功后图标立刻刷新。
- 分别记录图标是否恢复、原应用是否完成联网、普通网页是否仍可访问。只恢复其中一项时，按实际结果报告。
- 仍异常时，在事件查看器的应用程序和服务日志中查找 Microsoft → Windows → NCSI 下已有的 Operational 记录，保留复现时刻的事件；没有该日志或权限时如实注明，不为取证擅自启用策略。
测试无改善就恢复原代理与临时规则。向支持人员提供系统版本、时间、网络、命令结果和应用现象；不发送完整 PAC、内网配置或账号。命令结果与 NCSI 事件不一致，是继续定位路径差异的线索，不是测试失效。