Wi-Fi连接过程全拆解：从扫描、认证到四次握手与DHCP的排查指南

1. 按下去之后，连接过程并不是你想象的那个顺序

很多人把 Wi-Fi 连接过程理解成“打开设置、找到网络、输密码、连上”，实际真相要绕一个弯：密码验证并不是在关联之前做的，而是在关联之后才开始的。手机或电脑屏幕上的“正在连接”转圈，往往经历了扫描、认证、关联、四次握手、DHCP 分配 IP 五段完全不同的流程。每一段的失败都会表现为“连不上”，但卡住的位置和解决方式完全不一样。

我自己调试过好几次这种问题：一台设备能扫描到 SSID，点连接后一两秒直接提示“无法加入”，但换一台设备在同一位置却正常。很多人第一反应是“密码不对”，可密码明明是对的。真正原因经常是关联阶段协商的加密套件不匹配，或者 802.11w 管理帧保护（PMF）策略不一致，连四次握手还没走到就直接被 AP 拒绝了。所以要排查 Wi-Fi 连接问题，第一步不是怀疑密码，而是把连接过程拆开，搞清楚现在到底卡在哪一步。

这一章我从链路层视角把 Wi-Fi 连接过程完整讲一遍：客户端如何发现网络、如何完成认证与关联、如何通过四次握手建立加密链路、最后怎么从链路状态进入 IP 层。涵盖 WPA2/WPA3、隐藏网络、漫游断线、DHCP 卡顿等常见场景，也会单独讲一下 Wi-Fi Direct 这类点对点连接在流程上和传统连 AP 模式的区别。无论你是做嵌入式、做无线测试、做网络运维，还是单纯想搞懂家里路由器为什么偶尔“假死”，这段内容都能直接用。

1.1 连接成功不代表关联成功：先分清三个状态

IEEE 802.11 标准里，一个无线客户端与 AP 之间其实有明确的状态机约束，一共三个状态：未认证未关联、已认证未关联、已认证已关联。客户端只有走到第三个状态，才有资格去协商密钥并转发数据。但我们日常说的“连上了”，在网络层视角看还差得很远。

• 状态一：客户端刚开启无线网卡，或者刚进入某个 AP 的信号范围，这时既没有认证帧交互，也没有关联帧交互。
• 状态二：客户端向 AP 发送认证请求，AP 返回认证响应，客户端进入“已认证未关联”。注意，这个“认证”和用户名密码认证是两回事，它只是 802.11 管理帧层面的一个握手，绝大多数情况下是开放系统认证，本身一点安全作用都没有。
• 状态三：客户端发送关联请求，AP 返回关联响应，双方进入“已认证已关联”。此时链路层才真正打通，但如果没有配置加密，数据帧就能通过明文传输了；配置了 WPA2/WPA3，则还需要补上密钥握手环节。

判断一台设备是否真的完成关联，不能看手机顶部状态栏那个 Wi-Fi 图标，因为很多操作系统在关联刚完成、还没拿到 IP 时就把图标点亮了。更可靠的判断方式是抓管理帧看 Association Response 的 status code，或者看 DHCP 是否拿到地址。

1.2 从按下连接按钮开始，帧是这样一路按顺序走的

假设一台手机从未连接过某个 AP，用户手动选择 SSID 并输入密码，正常流程是这样的：

1. 无线网卡先做一次扫描，可能同时以主动扫描和被动扫描方式探测周围 AP。
2. 客户端根据扫描结果确定目标 BSSID 和信道，切换到对应信道，然后发 Authentication Request。
3. AP 回 Authentication Response，状态成功。
4. 客户端发 Association Request，里面携带本端支持的速率集、HT/VHT/HE 能力、加密套件信息等。
5. AP 根据自身配置决定是否接受，返回 Association Response。如果密码加密配置是 WPA2-PSK，此时会继续触发 EAPOL 四次握手；如果回到密码/预约之外配置开放的未加密网络，那么连接在此步就算完全建立了。
6. 四次握手成功后，客户端按 RSN 信息元素（RSNIE）约定安装 PTK/GTK，数据链路开始加密/解密。
7. 客户端通过新建立的加密链路发送 DHCP Discover，拿到 IP 地址，应用层才真正可用。

这一步一步看下来，很多“连上了但上不了网”的问题就有了解释路径：可能 DHCP 被 AP 的防护策略挡住，可能四次握手拿到了网络但组播密钥没装上导致组播不通，也可能 AP 给客户端分配了一个静态路由不可达的地址。后面章节我会逐个场景展开。

1.3 连接过程涉及的关键帧类型：管理帧、控制帧、数据帧

为了后续排查方便，先把帧类型刻在脑子里。802.11 有三类帧：管理帧（Management Frame）、控制帧（Control Frame）、数据帧（Data Frame）。

管理帧负责建立和维护连接，包括 Beacon、Probe Request/Response、Authentication/Deauthentication、Association Request/Response/Disassociation、Action 帧等。连接过程的“前半场”几乎都是管理帧的天下。控制帧负责辅助数据传输，比如 RTS/CTS、ACK、Block ACK，它们保证无线链路上数据帧可靠到达。数据帧则在四次握手完成后承载上层 IP 包。

排错时，第一个要养成的习惯就是看帧类型。如果你抓包只看到 Probe Request 反复发送而没有 Probe Response，大概率是 AP 没有反馈或信道不对；如果看到 Authentication 之后马上 Deauthentication，多半是 AP 拒绝客户端入网；如果看到四次握手断在第 3/4 条消息，问题就在密钥协商或组播密钥安装上。拿 Wireshark 或 omnipeek 过滤wlan.fc.type_subtype，一眼就能看到当前走到哪一步。

2. 扫描与发现：客户端怎么找到目标网络

Wi-Fi 连接的第一步不是“输密码”，而是“找到网络”。但客户端找网络的方式比我们直觉里复杂得多。手机屏幕上那个可滚动列表，其实是无线网卡在一个又一个信道间快速切换、花了几百毫秒到几秒收集信息换来的结果。

2.1 主动扫描与被动扫描，谁更常用、谁更耗电

802.11 定义了两种扫描方式：被动扫描（Passive Scanning）和主动扫描（Active Scanning）。

被动扫描就是客户端把网卡调到某个信道，静静等 AP 周期播发的 Beacon 帧。Beacon 帧一般每 100ms 发一次，里面包含 SSID、BSSID、支持速率、信道带宽、加密能力、802.11k/v 能力等信息。好处是客户端不需要暴露自己，只要“听”就行，省电又隐蔽；坏处是如果 Beacon 间隔长，客户端要等很久才能确定这个信道有没有 AP。而且如果 AP 开启了“隐藏 SSID”，Beacon 帧里可能不广播 SSID 字段，被动扫描根本不知道这个网络叫什么名字。

主动扫描则是客户端主动发 Probe Request，并等待 AP 回 Probe Response 或直接沿用 Beacon 信息响应。手机更常用主动扫描，因为要遍历 2.4GHz 和 5GHz 的所有信道，无源收听太慢了。主动扫描又分两种：广播探测（SSID 字段为空，通配符方式）和定向探测（SSID 字段填写具体网络名）。平时我们打开 Wi-Fi 列表时，手机会先发通配符 Probe Request 把所有 AP 都问出来；指定某个网络连接时，往往也会再做一次定向探测，避免缓存信息过期。

需要提醒的是，主动扫描不是没有代价。同一信道内如果同时有大量客户端做主动扫描，管理帧会占用不少无线介质时间，尤其是 2.4GHz 这种拥挤频段，Probe Request 风暴甚至会让整个空口管理开销明显升高。这也是有些路由器固件里带“Probe Request 过滤”选项的原因。

2.2 Probe Request 里到底藏着多少信息，这条链路上有多少次机会出错

看一个 Probe Request 帧，里面不只是“我想加入某个网络”。它携带的字段非常多，常见包括：

• 请求的 SSID：定向扫描时填目标网络名，广播扫描时为空或通配符。
• 支持的速率集：告诉 AP 我能支持哪些基础速率，比如 6、12、24Mbps 等。
• HT Capabilities / VHT Capabilities / HE Capabilities：分别表示 802.11n / 802.11ac / 802.11ax 能力，包含信道宽度、MCS 支持范围、空间流数量等。
• Extended Capabilities：像 802.11k、802.11v 和 BSS 过渡管理等功能就是通过这个字段上报的。
• DSSS Parameter Set / 当前信道：告诉 AP 此刻这个 Probe Request 是在哪个信道发出来的。

正因为 Probe Request 里面带了这么多能力集，AP 在回 Probe Response 时也会带上自己的能力集，客户端通过对比双方能力来决定后续关联时选择什么速率、带宽和加密方式。如果 AP 配置成只允许关联支持 WPA3 的客户端，而 Probe Request 里没有把 PMF Capable 置为 1，就可能直接收不到响应或者被拒绝关联。

2.3 “隐藏网络”的真相：设置里的不可见到底隐藏了什么

很多家用路由器后台都有“隐藏 SSID”选项，号称能防止别人搜到。从技术上说，这个选项只是让 AP 不在 Beacon 帧里广播 SSID，Probe Response 也可能把 SSID 字段置空。但问题在于，客户端主动扫描时如果发的是通配符 Probe Request，隐藏网络仍可能响应；就算不响应，只要终端曾经连接过这个网络，它就会时不时做定向探测，直接暴露这个 SSID 的存在。手机上的 Wi-Fi 列表如果勾选了“总是扫描”之类的选项，隐藏网络一样可以被发现。

从连接流程来看，隐藏网络并没有让链路更安全，反而增加了一次意外的失败点：客户端在后台重新扫描时，如果 AP 对隐藏 SSID 响应策略严格，客户端只能依赖本地缓存的上次连接配置去定位信道。一旦 AP 信道切换或者客户端记忆丢失，就可能出现“之前连着好好的，重启后搜不到”的情况。

我个人的建议是，除非有特定合规场景，否则没必要用隐藏 SSID 来“防盗”。真正决定安全的是加密和密码强度，不是 SSID 广播与否。隐藏 SSID 只会给正常终端增加不必要的漫游延迟和故障排查难度。

3. 认证与关联：名字带“认证”，其实一点都不认证

如果只看字面意思，很多人会以为 Authentication 阶段是验证用户身份的。很抱歉，802.11 标准里的“认证”并不是安全认证，它更像是建立链路前的握手礼仪。

3.1 开放系统认证为什么是“开放”的

目前几乎所有家用 AP 都支持开放式系统认证（Open System Authentication），流程非常简单：客户端发送 Authentication Request，Algorithms 字段填 0，AP 直接回一个 Authentication Response，status code 为 0 表示成功。中间没有任何口令、证书、挑战值，这就是“开放”二字的含义。

在 WEP 时代还有过共享密钥认证（Shared Key Authentication），AP 会返回一个 challenge 文本，客户端用 WEP 密钥加密后回传，AP 解密验证。但 WEP 本身已经被淘汰，共享密钥认证也早已退出主流。现在即使你是 WPA2/WPA3 网络，在管理帧层面的“认证”依然走开放系统。真正的用户身份验证发生在之后的四步握手或者 802.1X 认证流程里。

很多人抓包时看到一个奇怪现象：密码明明输错了，但抓包居然有 Authentication Request/Response 成功，甚至 Association 也成功了。这是因为客户端和 AP 在关联前都不知道密码是否正确，密码校验发生在四次握手阶段。所以不要看到“认证成功”就以为密码是对的，要看到四次握手完整结束，才能说密钥一致。

3.2 关联请求与响应：客户端能和 AP 达成哪些共识

关联过程是连接中信息最密集的一个阶段。Association Request 帧里包含了一个终端几乎所有的无线能力画像，AP 拿到后要逐项比对，给出决策。

一个典型的 Association Request 会协商出这些关键内容：

• 速率：双方支持的最高基础速率和 MCS 组合。
• 信道带宽：20MHz、40MHz、80MHz、160MHz。客户端自称支持 80MHz，AP 端如果只开了 40MHz，最终按 AP 配置走。
• 操作模式：802.11n 的 HT、802.11ac 的 VHT、802.11ax 的 HE，以及 802.11be 的 EHT（Wi-Fi 7）。
• 加密套件：通过 RSNIE 指定 group cipher、pairwise cipher、AKM 方法，比如 TKIP、CCMP、GCMP，以及 PSK、SAE、802.1X。
• 管理帧保护（PMF）能力：这是 WPA3 相关的重要字段，决定后续管理帧是否需要加解密。
• Power Save 模式：客户端是否支持省电，以及监听间隔（Listen Interval）是多少。
• 发射功率与 QoS 能力：决定 AP 是否把该终端纳入 WMM 队列调度。

AP 会在 Association Response 里告诉客户端这些协商结果。这里最关键的是 RSNIE，如果 AP 配置是 WPA2-PSK 但客户端只支持 WPA3-SAE，关联请求里的 AKM 列表对不上，AP 一般会拒绝关联，返回一个 status code 不为 0 的失败。反之亦然，这也是老设备连接新路由器失败的最常见原因之一。

3.3 断线重连时，状态机会怎么走

正常情况下，从已连接状态掉线，客户端会先尝试重新扫描，然后重新认证、重新关联，再重新经历四次握手。但很多操作系统为了提高体验，会保存上次连接的 BSSID、信道、加密参数等，如果检测到该 AP 还在，就跳过扫描直接发起认证。

这就引入了一个常见问题：如果 AP 重启后切换了信道，但客户端缓存里还记录着旧信道，第一次重新连接往往会失败。客户端重试时扫描到新信道后才会恢复。这个现象表现为“路由器重启后手机等了一两分钟才连上”。我见过不少因缓存导致的重连慢问题，处理办法要么是禁用“自动连接”，要么等 AP 重启后给终端一点时间重新扫描。

对于企业级网络，802.11r 快速漫游就是针对这个问题的优化：它在关联阶段提前完成密钥派生所需的 PMK-R0/PMK-R1 信息交换，漫游时省掉重新认证的往返。不过家用场景很少用 802.11r，更多是依赖客户端快速主动扫描来缩短断网时间。

4. WPA2/WPA3 四次握手：真正决定“密码对不对”的阶段

从链路状态看，关联完成之后客户端虽然被接受了，但这时候数据帧还不能正常收发。要让数据真正安全，双方必须确认彼此的加密密钥一致。这就是 EAPOL 四次握手要做的事，也是“输错密码”真正爆雷的位置。

4.1 PMK 是根本密钥，PTK 是本次连接的工牌

为了更好地理解四次握手，先说密钥等级。WPA2-PSK 下，PMK（成对主密钥）就是通过密码算出来的那个固定值：PMK = PBKDF2-HMAC-SHA1(passphrase, SSID, 4096, 256 bits)。密码相同、SSID 相同，任何客户端算出来的 PMK 都相同。它像一把万能根钥匙，不能直接用明文传输，否则任何人拿到都能算出当前连接的加密密钥。

客户端与 AP 真正通信时用的是 PTK（成对瞬态密钥），它是一次性会话密钥，由五个输入联合生成：PMK、AP 随机数 ANonce、客户端随机数 SNonce、AP MAC 地址、客户端 MAC 地址。五个参数中的任一个变化，PTK 都会完全不同。所以即使两个终端密码一样、PMK 一样，因为 MAC 地址不同、随机数不同，各自的 PTK 也不同。四次握手的过程本质上是双方交换随机数、确认双方都能独立算出同一个 PTK 的过程。

你可以这样理解：PMK 是员工的公司总门禁卡，PTK 是你今天领取的访客工牌。门禁卡不能随便给人看，工牌丢了明天可以重新发，但今天必须靠它进出所有会议室。协议要做的，就是确保你手里那张新工牌和会议室的锁能对得上。

4.2 四次握手到底在交换什么，逐条拆开看

四次握手由 AP 发起，客户端响应，总共四条 EAPOL-Key 消息，每一条都不能省，顺序也不能乱。

消息 1/4：AP → 客户端AP 生成一个随机数 ANonce，通过 EAPOL-Key 帧明文发给客户端。客户端收到后，结合自己的 SNonce、双方 MAC 和 PMK，立刻就能算出 PTK。此时 AP 还没有 PTK，因为它还不知道客户端的 SNonce。

消息 2/4：客户端 → AP客户端生成 SNonce，携带在 EAPOL-Key 帧中发回 AP，同时附上自己的 RSNIE 和用 PTK 计算出的 MIC（消息完整性校验码）。AP 收到 SNonce 后用同样的算法算出 PTK，再校验 MIC，确认客户端确实持有正确的 PMK。如果密码错误，两者算出的 PTK 不一致，MIC 校验就会失败，AP 会中止握手。这是密码错误最早暴露的时刻。

消息 3/4：AP → 客户端AP 确认 MIC 无误后，向客户端下发组播密钥 GTK（加密方法由 group cipher 决定）。这条消息用 PTK 派生的 KEK 加密 GTK，并附带 MIC 保证完整性。客户端收到后解密安装 GTK，同时安装 PTK。发送给 AP 的加密数据从现在开始可以互通。

消息 4/4：客户端 → AP客户端回复一条确认消息，告诉 AP“我已经装好了 PTK 和 GTK”。AP 收到后也把状态切换为已握手完成。此后单播数据帧走 PTK，组播/广播帧走 GTK。

我在实际抓包里经常看到一个现象：密码错误时，AP 会在收到消息 2 后直接回一条 Deauthentication 或者 EAPOL failure，客户端屏幕上一两秒内就弹出“密码错误”。如果你看到握手断在消息 2 之后，那基本可以断定问题出在 PMK 不一致，也就是密码输错或者 SSID 不匹配导致的 PBKDF2 参数不一致。

4.3 WPA3 的连接过程有什么不同：SAE 与 PMF

WPA3 个人版使用 SAE（Simultaneous Authentication of Equals）替代传统 WPA2-PSK。它最大的变化是不再使用固定的 PMK 密码推导关系，而是通过一个类似 Diffie-Hellman 的握手过程，让双方在不直接暴露密码的前提下协商出一个会话 PMK。

SAE 的交互发生在管理帧阶段，而不是 EAPOL 阶段。客户端和 AP 会在 Authentication 帧里完成 commit 和 confirm 两条消息的交换，确认彼此持有相同的密码，并通过 Dragonfly 算法协商出 PMK。这条 PMK 只对当前会话有效，即使抓包抓到握手过程，也无法用离线字典方式暴力反推密码。这也是 WPA3 抗字典攻击的核心能力。

WPA3 还强制开启管理帧保护（PMF）。传统 WPA2 里，Deauthentication/Disassociation 等管理帧都是明文发送的，攻击者可以伪造管理帧把终端踢下线，这也就是常见的“Wi-Fi 干扰”里大量使用空口 Deauth 的原因。启用 PMF 后，管理帧也经过加密和完整性校验，伪造管理帧无法通过验证。但 PMF 的坑也在这里：如果路由器强制开 PMF，而老旧网卡驱动不完全支持，关联阶段新型 Wi-Fi 客户端就稀里糊涂地失败。

4.4 快速漫游与密钥缓存：连接过程在真实网络里的额外开销

很多人会问，既然握手这么复杂，那从 WiFi6 AP 到另一个同品牌 AP 时还重新握手，网络岂不是要卡一下？确实会。为了减少这个中断，相当一部分企业网络启用 802.11r（Fast BSS Transition）。它的核心思想是：在初始关联时就预分发漫游所需的 PMK-R1，漫游目标 AP 不需要再去认证服务器换取密钥，客户端可以直接完成低速次的“快速握手”。家用单 AP 场景用不上这个特性，但 mesh 网络里经常是隐藏开启的。

另一个容易忽略的是 PMKID 缓存。有些网卡驱动在重新连接已连过的 AP 时，会携带之前的 PMKID，AP 如果缓存了对应的 PMK，就可以跳过完整四次握手，直接进入加密数据阶段。这个机制大大加快了重连速度，但如果你手动删除了手机上的网络配置并重新输入密码，不要在抓包里惊讶“怎么没有完整的四次握手”，因为 PMKID 缓存可能还没清除。

5. 从加密链路到真正上网：密钥之后到底还差了什么

四次握手完成后，数据帧已经可以加密收发，但这只是链路层通了。手机要真正刷出网页，还需要搞定 IP 层和 DNS 等。这个阶段虽然不如链路握手那么炫，却是最容易“连上但上不了网”的高发区。

5.1 单播与组播数据路径：手机收到“曾经连接”之前/之后信号如何走

密钥安装好后，普通单播数据都走客户端与 AP 之间的加密传输。AP 会把来自有线侧的下行数据帧，加上 802.11 加密头和校验，重新封装发给对应的 STA；手机发给 AP 的上行数据也类似。如果你在 AP 的有线端口抓包，看到的还是完整 IP 包；在无线侧抓包，则会看到带四层地址（RA、TA、SA、DA）的加密 802.11 数据帧。

组播和广播则不同。组播帧一般由 AP 用 GTK 加密后发送，所有持有相同组播密钥的客户端都能解密。这意味着一个客户端如果只装了 PTK、没正确安装 GTK，单播正常、网页也能打开，但一些组播业务，比如 mDNS 发现、 chromecast 投屏设备搜索、部分网络电视的局域网发现，就可能出现“搜不到设备”的诡异现象。

5.2 DHCP 为什么会成为连接体验的瓶颈

四次握手圆满完成后，客户端会马上发起 DHCP 流程，通常是 DHCP Discover。这时候 AP 主要扮演透明桥接角色，把DHCP广播（或中继交给DHCP服务器）转发出去。不少家用路由器上的 AP 功能和 DHCP 服务器是同一个设备，但也可能有无线控制器、合规网关和 DHCP 服务器分开部署。

无线环境下 DHCP 慢有几个常见原因。一个是 DHCP 广播要通过无线介质重传，多一次重传就多几十毫秒；另一个是 AP 开启了“隔离客户端”或“访客网络”隔离策略，DHCP 请求可能被丢弃；还有一个坑是 DHCP 地址池耗尽，路由器没有可用 IP 可分配，客户端一直停在“获取 IP 地址”。

我自己遇到最多的一个场景是：手机能连上 Wi-Fi，信号满格，但打开 App 提示无网络，抓包发现 DHCP 一直拿不到 IP。检查路由器的 DHCP 服务正常，最终定位是 AP 与交换机之间 VLAN 没放通，DHCP 广播被 VLAN 隔离直接丢了。这个阶段排查思路应放在三层网络而不是无线协议上。

5.3 Wi-Fi Direct 连接过程：和连 AP 是两套玩法

这里专门说一下热词里的 Wi-Fi Direct，因为它常用于无线投屏。Wi-Fi Direct 其实不是通过 AP 中转，而是让设备之间建立一条点对点的 802.11 链路。通信双方会通过协商，选出一个设备扮演 Group Owner，相当于软 AP，另一台作为 Group Client，它们之间用 P2P Group 的方式传输数据。

从连接过程看，Wi-Fi Direct 的起步阶段和普通扫描类似，设备在多个信道发送 Probe Request，但带的是 P2P IE，用来寻找附近同样支持 Wi-Fi Direct 的设备。发现之后，两台设备进入 GO Negotiation 阶段，交换意图值和信道信息，决定谁来当 GO。随后还要经过 WPS 或设备密码交换来完成加密参数配置，再走类似四条握手的密钥协商，最后 GO 通常还会扮演简易 DHCP 服务器的角色，给 group client 分配一个局域网 IP。

因为这一套流程比普通连 AP 更重，实际投屏时你会感受到明显的“发现-建立-连接”延迟。这也是为什么很多投屏方案宁愿让你手机和电视连同一台路由器，而不是直接让两者用 Wi-Fi Direct 互联——多一跳路由器，可操作性反而更高、更稳。但 Wi-Fi Direct 在某些没有局域网环境的户外场景，依旧是无线投屏和文件传输的杀手锏。

5.4 连接成功后不等于体验好：速率适配与漫游对链路的影响

即便密码正确、关联成功、拿到 IP，也不代表实际体验舒服。无线链路的速率不是固定的，而是随信号强度、干扰、误包率动态调整。连接成功后客户端和 AP 会通过 Rate Adaptation 算法不断探测是否能提高到更高速率或降低到更稳的 MCS。这个动态过程经常被用户感知为“信号满格但网速很慢”。

漫游场景更明显。当一个终端在多个 AP 间移动时，它会周期性扫描并寻找候选 BSSID，切换前必须走完新的关联和握手流程。不同厂商的漫游算法差异巨大，有的在信号跌到 -75dBm 才开始切，有的在 -65dBm 就切。如果 AP 没有开启 802.11k/v/r 辅助漫游，客户端切换的“断点时间”可能达到数百毫秒，实时音视频通话就会卡一下。这个问题不属于单次连接过程，但对“连接是否顺畅”的体感影响极大。

6. 实测中最常见的连接故障，以及我的完整排查思路

技术原理看再多，不如真正踩几个坑。我在调无线网络时遇到过各式各样的问题，这里挑几个有典型意义的场景，把排查链路展开讲，大家以后可以照着走。

6.1 一直卡在“获取 IP 地址”，到底该查哪

故障现象是：手机能连上 Wi-Fi，信号好，但状态栏一直显示“已连接，无互联网”或者一直转圈提示“获取 IP 地址”。这种情况不要再反复试密码，先看 DHCP。我在实测中的排查步骤如下：

1. 查看路由器的 DHCP 客户端列表，看看手机有没有分配到 IP。如果列表里已经有一个最近分配的地址，说明 DHCP 流程已经完成，问题可能在路由、DNS 或互联网侧。如果列表里根本没有，说明 DHCP 广播没到达服务器，或者服务器回包没送达手机。
2. 登录 AP 查看端口的 VLAN 配置。有些 AP 的下联口或者 SSID 绑定了不同的 VLAN，交换机对应 trunk 口如果没放通 DHCP 广播就会被丢弃。这个坑在跨交换机组网时特别常见。
3. 检查路由器的地址池是否耗尽。家里设备多、租期短的情况下，地址池耗尽并不罕见。路由器日志里通常会有“DHCP pool exhausted”之类的记录。
4. 如果一直拿不到 IP，可在电脑上把无线网卡地址设为静态 192.168.x.50，试试能不能 ping 通网关。能通就基本确认 DHCP 服务器问题，不通则说明二层链路还有问题。

6.2 4 次握手反复超时：别再盲目怪密码

另一个常见场景是：设备和 AP 都支持 WPA2/WPA3，但连接时反复出现四次握手失败，或者连接成功后几秒又断开，过一会儿又重连。原因一般有以下几类：

• 密码确实不一致，但只通过 MIC 校验才发现，握手断在消息 2/4 之后的反馈阶段。
• PMF 兼容性问题。AP 强制开启 802.11w，而客户端驱动不支持，关联后 AP 因 PMF 协商不通过而主动断链。日志或抓包里能看到带 PMF 能力字段的关联请求被拒绝。
• 组播密钥更新周期过短，GTK 更新时客户端没有及时响应，导致组播组被踢出。
• 无线干扰导致 EAPOL-Key 帧连续丢包，客户端和 AP 各自超时后主动放弃。

处理这类情况时，不要上来就改密码，而是先看 AP 日志里的拒绝原因、管理帧里的 status code，再核对客户端的 RSNIE 和 PMF 能力。如果确实 PMF 协商不一致，可以先把 AP 的 PMF 策略配成兼容模式，不要强制。

6.3 “能连上但什么都打不开”的三层排错

链路层握手完成后，手机显示已连接，但浏览器打不开任何网页，这种场景的核心问题是三层网络或 DNS。我推荐的定位顺序是：

1. 在终端上 ping 网关。通，说明链路和基本 IP 配置 OK。
2. 用 nslookup 测试 DNS。如果 DNS 不通，即使通了网关也打不开网页。
3. 再测试公网 IP，比如直接 ping1.1.1.1或某个公网地址。如果 ping 公网 IP 通但 ping 域名不通，就是 DNS 问题；如果连公网 IP 都不通，问题在路由/出口/NAT。
4. 最后检查 AP 和路由器是否有 URL 过滤、MAC 过滤、家长控制等策略。这些策略通常在关联成功之后才生效，所以会表现为“连接正常但特定流量被拦”。

我实际遇到过好几次：终端显示已连接，但访问任何网页都跳到一个认证页面，实际上不是网络故障，而是设备触发了强制门户（Captive Portal）。手机系统会专门发一个检测请求去探活，如果探活被重定向到登录页，就会一直提示“需要登录网络”。

6.4 日志与抓包：怎么快速定位“卡在哪一步”

连接问题的排查最终要落到证据上。日志和抓包是两把刀，配合使用效率最高。

客户端侧，wpa_supplicant 日志非常关键。打开 debug 模式后，能看到关联设备状态、四次握手的每个步骤，包括收到的 ANonce、发送的 SNonce、MIC 校验结果。Android 设备可以抓adb logcat -s wpa_supplicant，Linux 设备可以前台跑wpa_supplicant -dd。AP 侧则看系统日志里有没有 Authentication、Association、Deauthentication 等记录，一般都会带客户端 MAC 和失败原因。

抓包方面，Wireshark 支持监听 802.11 网卡进入监听模式。实测中最常用的过滤方式是wlan.fc.type_subtype == 0x0b看认证帧，wlan.fc.type_subtype == 0x01看关联帧，eapol看四次握手。拿毫秒级时间戳对照，基本几分钟就能定位到断点。

还有一个我习惯用的技巧：把“失败现场的抓包”和“正常连接时的抓包”放在同一个 Wireshark 里对比。对比关联请求中的 RSNIE、PMF 标志、Beacon 里的加密套件，差异项往往就是根因。很多兼容性故障不是哪边完全不支持，而是两边能力集的交集意外很小，导致协商结果和预期不符。

6.5 看清楚到底是哪一边拒绝了：掌握状态码的“潜台词”

802.11 管理帧中有大量 status code 字段，很多状态码在网上不太好搜，因为标准文档写得比较干。这里收集几个我在项目里最常遇到的：

状态码	含义	常见触发场景
0	成功	认证/关联正常完成
1	未指定的失败	大类错误，需结合上下文
12	认证被拒绝	AP 的 MAC 访问控制、终端数量限制
15	关联被拒绝但可以尝试漫游	802.11r 重关联场景
17	AP 忙	AP 达到了关联终端上限或资源不足
31	不支持 RSN 版本	WPA/WPA2/WPA3 版本策略不匹配
43	信道/频率不支持	客户端选了 5GHz 信道但 AP 不在该信道
46	RSN 信息元素不一致	密码套件或 AKM 不匹配

遇到状态码为 15 或 17 时，很多时候不是终端的问题，而是 AP 的接入容量或漫游策略。我有一次在办公室排查“某台电脑连不上 Wi-Fi”时，抓包发现 AP 连续返回 status code 17，最后查出来是那台 AP 的 max-association 值被某次固件升级重置成了 32，而当时已经连了 32 台设备，后面的设备自然进不来。

这些状态码如果配合日志里的具体时间点，基本能判断是客户端主动放弃还是 AP 主动拒绝。比如 AP 日志显示没有收到 Authentication 请求，那就说明终端根本没发出来或消息没到；如果 AP 回了 Association Response 但客户端没继续做四次握手，大概率是客户端侧驱动或安全策略出了岔子。

排查 Wi-Fi 连接问题，我一直强调“分层看、按帧查、看状态码”。无线链路最大的特点就是看不见摸不着，容易让排查变成猜谜。但只要把连接过程拆成“发现、认证、关联、握手、DHCP、三层”这几段，每一段用对应数据和抓包去验证，问题通常很快就会水落石出。这也是为什么我建议所有做网络和设备开发的人，都抽时间把这一章的状态机和帧交互吃透，磨刀不误砍柴工。