近日,国内西南地区以及江苏等地陆续有中国移动宽带用户遇到相似问题:
- 电脑实际上可以访问互联网;
- Windows 却提示“需要操作,没有 Internet”;
- 随后默认浏览器自动打开:
- 部分用户最终被重定向到陌生的博彩网站。
这些现象组合在一起,指向了 Windows 网络连接状态检测与异常 DNS 解析之间的一次连锁反应。攻击者并不需要修改 Windows 注册表,也不需要直接控制浏览器;只要干预 Windows 联网检测域名的解析,就可能借助系统默认开启的主动探测功能触发恶意网页。
本文根据用户侧现象和 Windows 官方公开的 NCSI 工作机制进行分析。截至发文时,如果运营商或有关机构尚未发布完整调查报告,具体影响范围、劫持位置和责任主体仍应以正式调查结果为准。
先说结论
遇到此问题时,建议按以下顺序处理:
- 不要在自动打开的陌生页面中输入账号、密码、银行卡或验证码,也不要下载任何所谓的“网络修复工具”;
- 同时检查并修改 IPv4 DNS 和 IPv6 DNS,不能只修改
114.114.114.114或8.8.8.8这样的 IPv4 地址; - 尽可能启用 Windows 系统级或路由器级 DNS over HTTPS(DoH),避免明文 DNS 被透明拦截;
- 清空 DNS 缓存,重新连接网络,并验证微软探测域名的解析和 HTTP 返回内容;
- 检查路由器、光猫、代理和 Hosts 文件;
- 只有在暂时无法处理底层问题时,才考虑禁用
EnableActiveProbing阻止自动探测和弹窗。
修改 EnableActiveProbing 只能关闭触发自动打开网页的功能,不能修复 DNS 劫持本身。
Windows 为什么会提示“需要操作,没有 Internet”
Windows 10 和 Windows 11 使用 NCSI(Network Connectivity Status Indicator,网络连接状态指示器)判断当前网络是否真正具备 Internet 访问能力。
当网卡连接、断开,网络配置、代理或路由状态发生变化时,NCSI 会进行主动探测。对于较新的 Windows,过程主要包括:
- 解析
www.msftconnecttest.com; - 通过明文 HTTP 请求访问:
- 检查 HTTP 状态和正文,正常响应应为:
- NCSI 还会查询
dns.msftncsi.com,并检查其 DNS 响应是否符合预期; - Windows 会结合主动探测和被动网络状态判断当前连接是“Internet”“仅本地网络”还是“可能需要认证”。
微软文档说明,Windows 会分别进行 IPv4 和 IPv6 主动探测。如果探测未完成、超时、返回错误状态,或者收到的正文不是预期的 Microsoft Connect Test,Windows 就可能显示“无 Internet”或“需要操作”。
这并不一定意味着所有网络流量都已中断。它只表示 Windows 用于判断联网状态的特定探测没有通过,所以有时会出现“网页能打开,但系统仍说没有 Internet”的情况。
Windows 为什么会自动打开 /redirect
酒店、机场和校园网经常使用需要登录的认证页面,也就是 Captive Portal。为了帮助用户完成认证,当 NCSI 怀疑当前网络需要额外操作时,Windows 可能打开:
在正常网络中,这个地址后续可能跳转到微软的 MSN 门户,例如:
这是 Windows 和微软服务设计的正常行为。微软还会利用 MSN 页面是否成功加载,辅助判断电脑能否访问互联网。
因此必须区分两种情况:
| 最终结果 | 含义 |
|---|---|
跳转到 msn.cn 等微软页面 | 通常是 NCSI 的正常后续流程 |
| 跳转到博彩、仿冒登录、软件下载等陌生页面 | 重定向链路已遭到异常干预 |
也就是说,自动打开 /redirect 本身不是攻击证据,最终被导向非微软恶意网站才是关键异常。
DNS 劫持如何利用这套机制
问题的关键在于,NCSI 的 Web 探测和 /redirect 入口都使用明文 HTTP。
如果攻击者让 www.msftconnecttest.com 或 IPv6 探测域名解析到错误地址,就可能控制后续响应:
攻击者不需要“开启”受害者电脑中的 EnableActiveProbing。这个选项在正常 Windows 中默认就是开启的,攻击者只是利用了系统原本会执行的联网检测流程。
严格来说,异常可能发生在多个位置:
- 运营商递归 DNS 返回了错误结果;
- 路由器或光猫使用了异常的上游 DNS;
- 明文 UDP/TCP 53 查询被透明拦截;
- 路由器 DNS 缓存被污染;
- 终端的 Hosts、代理或恶意软件篡改了访问目标;
- DNS 正常,但后续明文 HTTP 请求在传输链路上被劫持。
如果要严格区分“DNS 劫持”和“HTTP 劫持”,需要保存事发时的 DNS 响应、HTTP 响应头或网络抓包。仅凭事后页面截图通常无法确定劫持发生在哪一跳。
为什么其他设备没有提示,只有 Windows 会
不同操作系统使用不同的联网检测域名、返回内容和交互方式:
- Windows 使用
msftconnecttest.com和 NCSI; - Android、iOS、macOS 等系统使用各自的探测地址;
- 有的系统只显示 Wi-Fi 认证提示;
- 有的系统不会主动打开完整浏览器;
- 同一网络中的设备还可能使用不同的 IPv4/IPv6 DNS、缓存、VPN 或加密 DNS。
因此,攻击者如果只干预微软的探测域名,Windows 会最先出现明显症状,其他设备仍可能看起来正常。这并不代表其他设备的 DNS 一定安全,只是它们没有触发同样的系统行为。
为什么已经设置 114 和 8.8.8.8,仍可能受到影响
很多用户只在网卡中修改了 IPv4 DNS,例如:
但 Windows 的 IPv4 和 IPv6 DNS 是两套独立配置。即使 IPv4 DNS 已经手动指定,IPv6 DNS 仍可能由路由器自动下发。
可以使用以下命令查看:
其中:
AddressFamily 2表示 IPv4;AddressFamily 23表示 IPv6。
如果看到类似:
说明 IPv6 DNS 仍然指向路由器。fe80::/10 是链路本地地址,电脑会把 DNS 查询交给局域网中的路由器,再由路由器转发到光猫或运营商上游。
IPv6 桥接模式的影响
如果路由器启用了 IPv6 桥接、透传或 Passthrough 模式,它可能把光猫或运营商下发的 IPv6 前缀、默认路由和 DNS 信息继续传递给局域网设备。
此时的链路可能是:
因此,仅修改 IPv4 DNS 不能覆盖这条 IPv6 解析链路。
还要注意:“IPv6 DNS”指 DNS 服务器通过 IPv6 地址提供服务,它既可以回答 AAAA 记录,也可以回答 IPv4 使用的 A 记录。问题并不局限于 IPv6 网站。
普通公共 DNS 为什么仍不能完全防止劫持
手动填写公共 DNS 可以绕开部分运营商递归 DNS 故障,但传统 DNS 通常仍通过明文 UDP/TCP 53 端口传输。
这意味着,网络中的中间设备理论上仍然可以:
- 拦截发往
8.8.8.8或其他 DNS 的请求; - 伪造一个更快到达的响应;
- 阻断指定 DNS,迫使系统改用其他服务器;
- 对特定域名返回错误地址。
因此,“设置了公共 DNS”不等于“DNS 查询已经加密并验证了服务器身份”。要减少透明劫持,应进一步使用 DoH 或 DoT。
DoH 能否避免这种问题
如果攻击仅发生在 DNS 查询阶段,系统级 DoH 通常可以有效避免。
DoH 使用 HTTPS 传输 DNS 查询,中间设备不容易直接看到和篡改具体查询内容,并且客户端会验证 DoH 服务器的 TLS 证书。
但需要注意:
- 只在浏览器中开启 DoH,不一定覆盖 Windows NCSI。NCSI 使用 Windows 系统 DNS 客户端,而不是浏览器自己的解析器;
- 应使用 Windows 系统级 DoH,或者在路由器上为整个局域网部署 DoH;
- 如果设置允许“加密优先、失败时回退明文”,DoH 被阻断后仍可能回到普通 DNS;
- DoH 只能保护 DNS 查询,无法修复 Hosts、恶意代理、被入侵的路由器或后续 HTTP 链路劫持;
- 如果域名被正确解析,但明文 HTTP 流量仍被中间设备篡改,DoH 也不能单独解决问题。
因此更完整的防护是:
解决方法一:同时设置 IPv4 和 IPv6 DNS
以下为常见公共 DNS:
| 服务 | IPv4 首选 | IPv4 备用 | IPv6 首选 | IPv6 备用 |
|---|---|---|---|---|
| 阿里公共 DNS | 223.5.5.5 | 223.6.6.6 | 2400:3200::1 | 2400:3200:baba::1 |
| Google Public DNS | 8.8.8.8 | 8.8.4.4 | 2001:4860:4860::8888 | 2001:4860:4860::8844 |
| 114DNS | 114.114.114.114 | 114.114.115.115 | — | — |
中国大陆不同地区对各公共 DNS 的可达性和延迟可能不同。可以优先选择连接稳定且支持加密 DNS 的服务。
Windows 11 图形界面
- 打开“设置”;
- 进入“网络和 Internet”;
- 打开当前使用的“以太网”或“Wi-Fi”;
- 找到“DNS 服务器分配”,点击“编辑”;
- 将“自动(DHCP)”改为“手动”;
- 同时打开 IPv4 和 IPv6;
- 填入首选与备用 DNS;
- 如果系统提供“DNS over HTTPS”选项,将其开启;
- 保存并重新连接网络。
如果使用阿里公共 DNS,DoH 地址为:
使用命令设置
以网卡名“以太网”和阿里公共 DNS 为例,以管理员身份打开 PowerShell:
然后清空 DNS 缓存:
再次检查:
如果 IPv6 DNS 仍显示路由器的 fe80::...,说明设置没有应用到当前网卡,或者路由器、组策略、VPN 等正在重新接管 DNS。
解决方法二:在路由器中配置 IPv6 DNS 或 DoH
如果家中多台设备都使用同一条宽带,在路由器中统一配置更方便。
进入路由器管理页面,检查:
- WAN 和 LAN 使用的 IPv4 DNS;
- IPv6 DNS 是否为“自动获取”;
- IPv6 是否处于桥接、透传或 Passthrough 模式;
- 是否支持自定义 IPv6 DNS;
- 是否支持 DoH、DoT 或加密 DNS;
- 是否存在陌生的静态 DNS、端口转发或远程管理配置。
如果桥接模式强制继承光猫或运营商 DNS,可以选择:
- 在每台终端上手动设置 IPv6 DNS 和系统级 DoH;
- 在支持的情况下,让路由器负责获取 IPv6 前缀并指定 DNS;
- 在路由器上部署加密 DNS 转发。
不要在不了解拨号和前缀下发方式时直接修改光猫工作模式,否则可能造成 IPv4 或 IPv6 断网。
解决方法三:验证 DNS 和 NCSI 是否恢复
检查系统 DNS
分别查询 IPv4 和 IPv6 探测域名
不要依赖固定的 msftconnecttest.com IP 判断是否正常,因为微软探测服务由 CDN 承载,合法地址可能随地区和时间变化。更可靠的方法是:
- 与可信 DoH 的结果进行比较;
- 检查 CNAME 是否指向微软使用的正常 CDN;
- 检查 HTTP 返回内容和重定向目标;
- 保存异常发生时的原始响应。
检查探测文件
正常结果应包含:
如果当前网络本身没有公网 IPv6,第二条命令失败并不一定代表劫持。
检查 /redirect,但不要自动跟随
查看响应头中的:
如果目标是微软或 MSN 页面,通常属于正常行为;如果目标是博彩、仿冒登录或陌生下载站,应立即保存响应头和时间,不要在浏览器中继续访问。
为什么更换 DNS 后仍会访问 /redirect,但只跳到 MSN
更换 DNS 只是恢复正确解析,不会关闭 Windows 的 NCSI 功能。
如果 Windows 已经因为前一次探测失败进入“需要操作”状态,或者在网络重新连接后再次评估连接,它仍可能打开:
区别在于:
- DNS 被劫持时,请求可能到达攻击者服务器并跳转到博彩网站;
- DNS 恢复后,请求到达微软服务器并正常跳转到 MSN。
因此,更换 DNS 后看到 MSN 通常说明恶意跳转已经停止,而不是 DNS 修改没有生效。
是否需要检查 Hosts 文件
需要,但它不是运营商级事件中最优先的嫌疑对象。
Windows 在向 DNS 服务器查询前会检查本地 Hosts 文件。如果其中存在相关映射,即使修改 DNS 也不会生效。
Hosts 文件路径:
可以使用 PowerShell 检查:
正常情况下不应存在这些域名的自定义映射。
如果同一宽带下多台设备同时异常,而切换到手机流量后恢复,问题更可能位于路由器、光猫或运营商链路;如果只有一台设备异常,则应优先检查 Hosts、代理、虚拟网卡、恶意软件和浏览器扩展。
还可以检查 WinHTTP 代理:
临时措施:禁用 EnableActiveProbing
如果暂时无法解决底层 DNS 问题,又希望立即阻止 Windows 自动触发探测和网页,可以禁用 NCSI 主动探测。
注册表路径:
将:
设置为:
也可以使用管理员 PowerShell:
恢复时设置为 1:
修改注册表前建议备份。微软不建议把关闭 NCSI 主动探测当作长期修复方案,因为 Windows Update、Outlook 和其他应用可能依赖 NCSI 的联网状态判断。
禁用后的效果是:
但底层问题可能仍然存在:
所以这是一种临时止损措施,不是根治方案。
建议保留哪些证据
如果再次遇到问题,建议在关闭页面前记录:
- 发生时间和所在地区;
- 宽带运营商;
- 当前 IPv4 和 IPv6 DNS;
Resolve-DnsName的完整返回;/redirect的 HTTP 状态和Location;- 恶意页面完整地址和截图;
- 同一网络下其他设备是否异常;
- 切换到手机流量后是否恢复。
如果条件允许,可以使用 Wireshark 抓取:
对于 IPv6 路由器通告,可使用:
重点查看 Router Advertisement 中的 RDNSS 信息,它可以显示局域网设备从哪里获得 IPv6 DNS。
这些证据比事后单独的一张网页截图更有助于判断问题发生在终端、路由器、光猫还是运营商网络。
总结
这次事件的核心不是“Windows 自己打开了博彩网站”,而是:
- Windows 使用 NCSI 主动检测互联网连接;
- NCSI 会访问明文 HTTP 探测地址;
- DNS 劫持让探测请求到达了错误服务器;
- 错误响应使 Windows 判断网络“需要操作”;
- Windows 随后打开
/redirect; - 被劫持的解析再次把浏览器导向恶意网站。
解决问题时,应当分清三个层次:
- 同时修改 IPv4 和 IPv6 DNS,并启用系统级或路由器级 DoH,这是处理 DNS 劫持的核心;
- 检查路由器、光猫、Hosts 和代理,是排除本地篡改的必要步骤;
- 禁用
EnableActiveProbing只能阻止系统自动探测和弹窗,不能修复底层劫持。
最后再次提醒:不要在陌生跳转页面输入任何信息,也不要下载页面推荐的软件。发现异常时,应优先断开页面、保存证据、修改 DNS,并向宽带运营商反馈。