两次 Wi-Fi 故障排查：DNS 无响应、AP 去认证与端口扫描告警

发布于 | 分类于 网络|本文包含AIGC内容

先后遇到过两次表面相似的 Wi-Fi 故障：

  • 第一次是在酒店。Mac 显示 Wi-Fi 已连接，但网站无法访问，改用公共 DNS 后恢复。
  • 第二次是在公司。网络间歇性中断，系统日志同时出现 DNS 无响应、无线 AP 去认证和 DHCP 失效；公司的安全系统还把本机标记为端口扫描攻击来源。

两次问题都表现为“连着 Wi-Fi 但无法正常上网”，实际故障层次并不相同。第一次主要位于 DNS 解析链路；第二次同时涉及 DNS、无线链路和可能的网络安全策略。

先区分无线链路、DHCP 和 DNS ​

设备访问网站通常要经过以下环节：

text
连接无线 AP
  ↓
通过 DHCP 获取 IP、网关和 DNS
  ↓
DNS 将域名解析为服务器 IP
  ↓
通过网关访问目标服务器

三个环节异常时，用户看到的现象可能相近：

故障层次常见现象主要验证对象
无线链路Wi-Fi 图标断开、重新关联 AP、日志出现 deauth/disassocSSID、BSSID、信号、断开原因码
DHCP/IP已连接 AP，但没有有效 IP 或网关IP、子网掩码、网关、DHCP 租约
DNSIP 和网关可用，但域名无法解析默认 DNS 与指定 DNS 的查询结果

“续租 DHCP 租约”会让设备向 DHCP 服务器重新申请网络配置。它可以处理租约异常、地址冲突或错误配置，但不能修复 AP 主动断开客户端，也不能保证 DNS 服务器恢复响应。

第一次排查：酒店默认 DNS 无响应 ​

现象 ​

Mac 已连接酒店 Wi-Fi，重新连接后仍无法打开网站。手动添加 223.5.5.5 和 1.1.1.1 后，访问立即恢复。

这说明当时无线关联、IP 配置和互联网出口大概率可用，异常集中在酒店下发的默认 DNS 或其转发路径。

修改前后的查询路径如下：

text
修改前：Mac → 酒店下发的 DNS → 查询超时
修改后：Mac → 公共 DNS → 正常返回结果

公共 DNS 恢复访问是定位依据，但不能单独证明酒店 DNS 服务器宕机。酒店网关、上游运营商、认证系统、错误的 DHCP 配置和不完整的 IPv6 配置，都可能导致相同现象。

验证方法 ​

分别使用系统默认 DNS 和指定 DNS 查询同一域名：

bash
dig www.baidu.com
dig @1.1.1.1 www.baidu.com
dig @223.5.5.5 www.baidu.com

也可以查看 macOS 当前实际使用的 DNS：

bash
scutil --dns
networksetup -getdnsservers Wi-Fi

如果默认查询持续超时，而指定公共 DNS 能立即返回结果，可以把范围缩小到默认 DNS 链路。部分网络禁止 ICMP，因此 ping 不通不能单独证明互联网出口故障。

处理顺序 ​

  1. 暂时关闭 VPN、代理和 Clash、Surge 等网络软件，排除本机转发链路影响。
  2. 访问 http://neverssl.com，检查酒店登录认证页面是否需要重新认证。
  3. 忽略该 Wi-Fi 后重新连接，重新获取 DHCP 配置和认证状态。
  4. 必要时续租 DHCP 租约。
  5. 对比默认 DNS 和指定公共 DNS 的查询结果。
  6. 确认默认 DNS 异常后，临时使用可用的公共 DNS。

酒店、机场等网络可能要求先通过指定 DNS 完成认证，所以不适合在连接前长期固定公共 DNS。公司网络也可能依赖内部 DNS；改用公共 DNS 后，内部域名可能无法解析。

第二次排查：公司 Wi-Fi 间歇断线 ​

第二次问题发生在公司 Wi-Fi，具体 SSID 已隐去。同一时段内存在两类不同故障，需要按时间线分别分析。

第一类：无线保持连接，但 DNS 无响应 ​

下午某时段，无线仍关联到 AP，信号约为 -41 至 -43 dBm，但系统重复记录：

text
wifi-trigger-disconnect triggered by If all DNS servers are unresponsive
DNSImp:1

当时 DHCP 只下发了一个 DNS：

text
DNS：<公司 DNS 地址>
DHCP 服务器：<公司 DHCP 服务器地址>
本机 IP：<公司内网地址>
网关：<公司网关地址>
子网掩码：<公司子网掩码>
租期：2 小时

只有一个 DNS 会形成单点故障。后续对网关和 DNS 的测试均正常，向公司 DNS 执行 dig 查询也能快速返回。这只能证明测试时已经恢复，不能否定之前的间歇性超时。

对应方案是让网络管理员检查 DNS 服务器在故障时段的查询、丢包和负载日志，并由公司配置允许使用的备用 DNS。不能直接把公共 DNS 作为长期方案，因为公司内部域名可能只能通过内部 DNS 解析。

第二类：AP 主动去认证 ​

上午某时段，特定无线 AP 多次向本机发送 FC_DEAUTH，日志包含：

text
Reason: Deauth
Link down because of disassoc
isDisconnectInVoluntary=1

同时出现 IEEE 原因码 2、4 和厂商扩展码 404。当时信号约为 -42 dBm，并不弱；Mac 每次重新加入同一个 AP 后，又很快被去认证。

下午同一个 AP 再次重复去认证。此时 DHCP 日志中的 no SSID、media inactive 是无线链路已经断开后的结果，不是最初原因。

这类问题需要从 AP 或无线控制器侧处理，重点检查：

  • 是否存在客户端踢除、重复会话或安全隔离策略；
  • 漫游、频段引导、负载均衡是否反复触发；
  • AP 是否存在固件、射频或上联异常；
  • 同一 MAC 在其他 AP 上是否有并发关联记录。

临时规避方法是移动到其他覆盖区域，使设备关联另一个 AP。续租 DHCP、手动修改 DNS 无法阻止 AP 去认证。

一次由 macOS 发起的链路重置 ​

同日下午还出现过一次约 4 秒的链路重置。日志显示：

text
NET_MANAGER_EVENT_LINK_SUPPRESS
WLC_DISASSOC

这次由系统或驱动发起断开，随后重新加入同一个 AP，更接近 macOS 在网络健康异常时执行的恢复动作。它与 AP 主动发送 FC_DEAUTH 的事件应分开统计。

端口扫描告警如何与断线关联 ​

公司的安全系统先后两次将本机标记为“端口扫描攻击”。第二次告警距离随后发生的 AP 去认证约 90 秒，因此存在安全系统触发隔离或踢除的可能。客户端 MAC、AP BSSID 和具体告警时间已隐去。

这一时间关系只能作为排查线索。要确认是否由安全策略断开，需要网络管理员提供告警的处置动作和无线控制器记录。

什么是端口扫描 ​

端口扫描通常是短时间内尝试大量网络连接，用于判断目标主机或服务是否可访问。常见模式包括：

  • 纵向扫描：对同一个目标 IP 访问大量不同端口；
  • 横向扫描：对大量目标 IP 访问相同或少量端口；
  • 高频连接：在较短时间窗口内产生大量连接尝试，被阈值规则归类为扫描。

正常软件也可能产生相似流量。代理节点健康检查、浏览器并发连接、即时通信、音乐软件和 CDN 访问，都可能在短时间连接多个地址。是否属于攻击，不能只看“访问了很多域名”。

本机检查结果 ​

本机未发现正在运行的 nmap、masscan 或 zmap 等扫描工具。历史命令中只有对单一主机、单一端口执行过 nc -vz，与本次告警时间和典型扫描模式不符。

同时确认到以下网络行为：

  • Clash Verge 的核心进程 verge-mihomo 通过 127.0.0.1:7897 提供 HTTP、HTTPS 和 SOCKS 代理；
  • 代理存在大量到 443 端口的外连，也有少量 8443、20605、20998 等端口；
  • 本机开发服务曾在全部网络接口监听多个开发端口，这会扩大局域网暴露面，但监听端口本身不等于主动扫描；
  • macOS 应用防火墙当时处于关闭状态；
  • ecosystemanalyticsd 是 Apple 签名的系统进程，没有证据表明它参与扫描。

第一次告警后数秒内，Clash 日志出现一批集中外连，主要来自音乐应用及其 CDN，目标端口以 80 和 443 为主。这更接近应用并发访问多个服务，但可能命中基于“多目标、高频连接”设置的横向扫描阈值。第二次告警附近只有少量即时通信应用连接，证据不足以确定告警来源。

需要网络管理员提供的字段 ​

应取得以下原始告警数据，再判断是哪一个进程或规则触发：

text
源 IP、源端口
目标 IP、目标端口列表
协议
连接次数与统计时间窗口
单目标多端口，还是多目标同端口
告警后的处置动作：仅记录、限速、隔离或 AP 踢除

如果目标表现为大量代理节点、固定探测 URL 和少量相同端口，应优先检查代理健康检查；如果是单一内网 IP 的连续端口序列，则更接近传统纵向扫描。

Clash Verge 健康检查的影响与调整 ​

当时有两个自动代理组：

yaml
- name: ♻️自动选择
  type: url-test
  url: http://www.gstatic.com/generate_204
  interval: 450

- name: 🔯故障转移
  type: fallback
  url: http://www.gstatic.com/generate_204
  interval: 300

url-test 和 fallback 会检查组内多个候选代理节点，不只是当前正在使用的单个节点。节点较多时，每轮检查可能在短时间产生一批到不同代理服务器的连接，从流量形态上接近“多目标探测”。

为了降低自动探测频率，同时保留自动选择和故障转移，最终把两个组的间隔统一调整为 3600 秒：

yaml
- name: ♻️自动选择
  type: url-test
  url: http://www.gstatic.com/generate_204
  interval: 3600

- name: 🔯故障转移
  type: fallback
  url: http://www.gstatic.com/generate_204
  interval: 3600

配置已同步到 Clash Verge 的订阅配置、检查配置和运行配置，并重新加载核心。调整后仍会每小时检查一次候选节点，不等于完全关闭健康检查。

更可靠的验证方式是进行对照观察：记录调整前后的告警时间、目标数量和连接频率。如果告警同步减少，可以进一步检查阈值与健康检查的关系；如果 AP 仍在相同时间主动去认证，则应继续从无线控制器或安全策略侧排查。

两次排查形成的通用方法 ​

1. 先记录准确时间 ​

间歇性故障恢复后，实时测试往往全部正常。记录断线到秒的时间，才能把客户端日志、AP 日志、DNS 日志和安全告警对齐。

2. 不用 Wi-Fi 图标判断故障层次 ​

图标显示已连接，只能说明当前已经关联无线网络。应分别验证：

bash
# 当前网络配置
ipconfig getifaddr en0
route -n get default
scutil --dns

# 网关是否可达
ping -c 5 <网关地址>

# 默认 DNS 与指定 DNS
dig www.baidu.com
dig @<DNS 地址> www.baidu.com

3. 从系统日志区分主动去认证和 DNS 超时 ​

在 macOS“控制台”中可按故障时间搜索 wifi、deauth、disassoc、DNS、DHCP。也可以在终端按时间范围查看统一日志：

bash
log show --last 15m --style compact \
  --predicate 'eventMessage CONTAINS[c] "deauth" OR eventMessage CONTAINS[c] "disassoc" OR eventMessage CONTAINS[c] "DNS" OR eventMessage CONTAINS[c] "DHCP"'

主要判据如下：

  • FC_DEAUTH、Reason: Deauth：AP 或无线控制器主动去认证；
  • WLC_DISASSOC：本机系统或驱动发起断开；
  • all DNS servers are unresponsive：无线可能仍连接，但 DNS 没有响应；
  • media inactive、no SSID：通常是无线断开后 DHCP 层观察到的结果。

4. 将本机日志与网络侧证据对齐 ​

客户端只能证明“何时断、以什么方式断”，无法直接说明 AP 为什么执行去认证。公司网络中的最终判断需要结合：

  • AP 和无线控制器的客户端事件；
  • DHCP 与 DNS 服务器日志；
  • NAC、IDS/IPS 或终端准入系统的告警及处置记录；
  • 代理软件和主要应用在同一秒的连接记录。

总结 ​

第一次酒店 Wi-Fi 故障的核心证据是：无线仍连接，默认 DNS 查询异常，改用公共 DNS 后立即恢复。公共 DNS 适合作为临时验证和恢复手段。

第二次公司 Wi-Fi 故障包含多个事件：一部分是 DNS 单点间歇性无响应；一部分是 AP 明确向客户端发送去认证；另有一次由 macOS 发起的短暂链路重置。端口扫描告警与 AP 去认证在时间上接近，Clash Verge 的多节点健康检查也具备触发阈值告警的流量特征，但现有客户端证据不能确认因果关系。

当前采取的本机措施是把 Clash Verge 两个自动代理组的健康检查间隔从 300/450 秒延长到 3600 秒。网络侧仍需确认安全告警的目标列表、检测阈值、处置动作，以及 AP 去认证的控制器原因。

#DNS #网络排查 #macOS #Wi-Fi #DHCP

你要请我喝一杯奶茶？

版权声明：自由转载-非商用-保持署名和原文链接。

本站文章均为本人原创，参考文章我都会在文中进行声明，也请您转载时附上署名。