1. 为什么要专门写一篇iw工具的使用总结
1.1 从iwconfig到iw：一次被迫的迁移
做Linux无线网络调试的人，应该都经历过这样的场景：拿到一台新机器，无线网卡连不上AP，第一反应是敲iwconfig wlan0，然后发现输出的内容越来越少，很多参数显示为"unavailable"，甚至某些芯片的驱动直接不理会Wireless Extensions接口。我最早遇到这个问题是在一台采用新内核驱动的笔记本上，iwconfig连SSID都读不出来，那一刻我意识到，属于iwconfig的时代确实过去了，必须切换到基于nl80211的iw工具。
iw是Linux下新一代的无线设备配置工具，它通过netlink接口与内核的cfg80211/nl80211子系统通信，而iwconfig走的是老一代的Wireless Extensions（无线扩展）接口。现代内核里，Wireless Extensions被视为遗留机制，很多新特性——比如802.11ac/ax的VHT/HE参数、多接口并发、更精细的信道与频宽控制、Station信息统计——只有走nl80211才能拿到。换句话说，只要你用的网卡驱动还活跃，iw就是你真正能"管得住"这块网卡的工具。
这篇总结面向的读者是：Linux系统管理员、嵌入式开发者、无线网络调试人员，以及所有需要在命令行下完成无线网卡配置和排查的人。我会按照实际使用的频次来组织内容，先讲怎么摸清网卡底细，再讲日常的扫描、连接、断开操作，然后讲监听模式、AP模式这类进阶用法，最后是参数调优和常见报错的排查。每条命令我都会给出执行场景、输出解读和踩坑提醒，希望能成为一篇可以直接摆在手边参考的实操笔记。
1.2 iw和iwconfig到底差在哪里
很多人觉得iw和iwconfig只是命令格式不同，实际上它们是两代技术的差异。
第一，底层接口不同。iwconfig使用的Wireless Extensions是建立在ioctl上的旧接口，内核里的对应代码路径基本已经冻结；iw使用的是nl80211 netlink协议，支持带外事件、多属性传递、异步操作，是现代cfg80211架构对外的主要控制通道。这个差异不是实现细节，它决定了你能查询和控制的参数范围。
第二，能力边界不同。举几个iw能做但iwconfig做不到或做不好的例子：查看网卡支持的完整能力集（频段、信道、带宽、接口模式、HT/VHT/HE特性）；在同一个物理射频设备上创建多个虚拟接口；查询每个关联站点的信号强度、速率、TX/RX字节数；触发扫描并拿到包含802.11n/ac/ax元素的完整BSS列表；把发射功率配置到具体的dBm值。这些能力在iwconfig里要么没有对应项，要么只能看到一个笼统的数字。
第三，交互方式不同。iw的很多操作是异步的，比如扫描命令发出后，内核和驱动根据自己的节奏完成扫描，然后通过事件通知结果。这不只是风格差异，它意味着调试方式也要跟着变，iw event这种实时事件监听机制在iwconfig时代基本没有对应物。
我并不是说iwconfig已经完全没用了，在内核版本很老、或者面对某些只实现了Wireless Extensions的极简驱动时，iwconfig仍然是最后的退路。但在现代Linux环境里，绝大多数场景iwconfig已经"有心无力"，早换早省心。下面我把常用命令整理成一个速查表，然后在后续章节逐个展开。
| 功能 | iwconfig时代 | iw时代 |
|---|---|---|
| 查看接口 | iwconfig | iw dev |
| 查看能力 | iwlist | iw list / iw phy info |
| 扫描 | iwlist wlan0 scan | iw dev wlan0 scan |
| 连接开放网络 | iwconfig wlan0 essid "SSID" | iw dev wlan0 connect "SSID" |
| 查看链路 | iwconfig wlan0 | iw dev wlan0 link |
| 切监听模式 | iwconfig wlan0 mode monitor | iw dev wlan0 set type monitor |
| 设置频点 | iwconfig wlan0 channel 6 | iw dev wlan0 set channel 6 HT20 |
| 设置功率 | iwconfig wlan0 txpower 20 | iw dev wlan0 set txpower fixed 20 |
| 查看站点 | iwconfig无对应 | iw dev wlan0 station dump |
2. 上手第一步：摸清网卡和驱动的家底
2.1 先执行 iw dev 和 iw list 这两条命令
我调试无线网卡的习惯动作永远是先执行两条命令：iw dev和iw list。这就像修车先打开引擎盖，你总得知道里面是什么结构。
iw dev输出的是当前系统里所有无线接口的概况，包括接口名、所属物理射频设备（phy）、接口类型、MAC地址。执行结果大致长这样：
$ iw dev phy#0 Interface wlan0 ifindex 6 wdev 0x1 addr xx:xx:xx:xx:xx:xx type managed txpower 20.00 dBm这里最值得看的是几个字段：phy#0表示这个接口挂在哪一个物理射频设备上；type表示当前接口模式，常见的有managed（普通客户端）、AP（接入点）、monitor（监听）、mesh point（无线网格节点）等；txpower是当前发射功率目标值。注意，这个txpower只是软件层面的目标值，实际功率还会受驱动、固件和法规域限制，后面我会单独讲。
iw list（等价于iw phy info）是一份更详细的报告，输出非常长，内容包括：支持的接口模式列表、Band 1/Band 2频段信息、每个频段支持的信道与带宽、HT/VHT/HE能力、最大关联站点数、支持的特性列表等。这是判断一块网卡"能干什么、不能干什么"的最权威依据，后面排查"为什么命令报错"时也会反复用到它。
2.2 看懂 iw list 里最关键的信息
iw list输出很长，第一次看可能直接劝退，我一般只看几个重点段落。
第一是"Supported interface modes"。如果这里没有AP，那你无论如何也开不了热点；没有monitor，抓包方案就得换。注意，这个列表由驱动和固件共同决定，不完全是硬件的绝对能力，有时换固件后能力会变化。
第二是"Band 1"和"Band 2"里的Frequencies字段，也就是信道列表。每一行代表一个信道，括号里是信道编号，后面可能跟着限制信息。比如某些5GHz信道标注了(DFS)，意味着这个信道属于雷达跳频检测信道，使用前需要通过CAC（Channel Availability Check，信道可用性检查），在监听或开AP之前要先等待一段时间；某些信道标注No-IR，意思是不能用于主动发起辐射，只能被动接收。
第三是"HT capabilities"、"VHT capabilities"、以及新固件里的"HE capabilities"（802.11ax）和"EHT capabilities"（802.11be）字段。这决定了网卡支持最高多大带宽、多少条空间流。比如支持VHT且最大MCS为9，说明理论上能跑到很高的物理速率，但实际吞吐还要看驱动、固件和环境干扰。
第四是支持的命令或特性列表。这个列表对排查"命令报错"非常有用：如果某个功能在列表里根本找不到，基本可以判定是驱动或固件不支持，而不是你命令写错了。我见过不少人在不支持的硬件上反复重试同一条命令，纯属浪费时间。
提示：
iw list和iw phy phy0 info输出基本一致。如果你有多个phy，记得区分编号。很多操作命令里可以指定phy0或wlan0，两者作用范围不一样。
3. 日常使用频率最高的扫描与连接操作
3.1 扫描的正确姿势：直接扫和分离式扫描
连接无线网络之前，先扫描一遍周围环境，这是最基本的操作。iw dev wlan0 scan会触发一次主动扫描并等待结果，输出会列出所有能收到的AP信息，比如：
$ iw dev wlan0 scan BSS xx:xx:xx:xx:xx:xx (on wlan0) last seen: 12.345s ago beacon interval: 100 TUs capability: ESS Privacy ShortSlotTime RadioMeasure (0x0431) SSID: MyTestAP Supported rates: 1.0 2.0 5.5 11.0 18.0 24.0 36.0 54.0 DS Parameter set: channel 6, center 2437 MHz HT capabilities: ... WPA: * Version: 1如果执行后卡住或返回空列表，常见原因依次有：不是root权限（扫描需要特权）；网卡没有处于managed模式；周围确实没有可扫描的AP；驱动不支持主动扫描。还有一点容易被忽视：扫描过程中网卡会暂时离开当前工作信道，如果你正连着网络，扫描会造成短暂的传输中断，在业务环境里要小心，尽量避开高峰期。
iw dev wlan0 scan trigger和iw dev wlan0 scan dump是分离式扫描的用法：trigger让内核启动异步扫描，dump在扫描完成后获取结果。这种方式在脚本里很有用，可以先把扫描摇起来，干完别的事再回来取结果。我自己的经验是，临时看一眼直接用scan；反复扫描的脚本用trigger加dump更可控，也方便加超时处理。
3.2 连接开放网络，以及为什么WPA网络不能只靠iw
对于开放网络（无加密），iw可以一条命令直接连上：
iw dev wlan0 connect "MyTestAP"然后配合iw dev wlan0 link查看连接状态。如果成功，输出会显示Connected to、SSID、频率、信号强度、TX/RX比特率等信息。
WEP网络可以用key参数，虽然现在很少见了：
iw dev wlan0 connect "MyTestAP" key 0:1234567890但这里必须说清楚一个关键点：iw本身不处理WPA/WPA2/WPA3的认证流程。也就是说，对于大多数现代家用和办公网络，你没法只用iw命令完成连接。标准做法是先用ip link set wlan0 up把接口拉起来，再用wpa_supplicant完成认证。iw在这里的角色更像是提供接口管理和状态查看，认证由wpa_supplicant负责。
不少初次接触的人会在这里卡住：明明用iw dev wlan0 connect "SSID"执行成功了，iw link也显示connected，但就是没有网络访问。原因通常是这个SSID用的是WPA2加密，iw虽然能完成底层的关联（associate），但802.1X的四次握手没人做，数据面自然不通。如果再碰上WPA3，还会有SAE握手，更不是iw能管的。所以别指望iw搞定一切，协议栈的分工本来就是这样，认清边界反而省时间。
3.3 断开、重连和状态确认的实操细节
iw dev wlan0 disconnect会主动断开当前连接。这个命令在驱动状态异常、MAC层卡死时非常有用：先disconnect再重新connect，往往比直接重启网络服务更快。断开后执行iw dev wlan0 link，输出会显示Not connected。
查看当前链路状态的命令就是iw dev wlan0 link，它给出的信息已经比较全：连接BSS的MAC、SSID、当前频点、信号强度、rx/tx比特率等。不过要注意，iw link显示的是内核里保存的统计信息，不是实时采样，想看实时变化，配合watch -n 1 iw dev wlan0 link滚动刷新最方便。
如果是AP模式下面挂的客户端，想看它们的状况，用iw dev wlan0 station dump，输出每个station的MAC、信号、速率、累计流量。这个命令在做无线网桥或热点的运维时非常常用，比在hostapd日志里翻信息直观得多。结合iw dev wlan0 station get <mac>还能只看单个客户端的详细统计，排查某个终端掉线时很有用。
4. 模式切换：监听模式与AP模式不再神秘
4.1 进入监听模式后，网卡到底发生了什么
做无线抓包、排查非法AP、分析空中接口帧，第一件事就是把网卡切到监听模式。命令序列是：
iw dev wlan0 set type monitor ip link set wlan0 up执行后iw dev wlan0 info里type会变成monitor。此时网卡不再作为客户端参与连接，而是把经过的所有无线帧都交给上层，配合抓包工具就能看到空中飞行的数据帧。
切换模式时最容易踩的坑是：接口处于up状态时切类型会失败，报Device or resource busy。所以规范做法是严格的顺序：
ip link set wlan0 down iw dev wlan0 set type monitor ip link set wlan0 up另一个坑是网络管理服务（比如NetworkManager）的干预。你刚把模式设为monitor，网络管理服务发现"这个网卡没在被管理"，就可能把接口重置回managed，或者尝试自动连接，导致模式反复横跳。调试时最好先停掉网络管理服务，或者把这个接口在配置里设为"未管理"，不然你在一个终端切模式，另一个终端的日志里全是它被重置的记录。
还需要知道的是，不是所有网卡的驱动都能在监听模式下拿到完整帧流。部分芯片的固件会过滤掉控制帧，或者只上报部分频段的帧，这类属于驱动和固件的限制，换工具也解决不了。所以如果你发现监听模式下抓不到beacon，先不要怀疑自己操作错了，查一下这块网卡在社区里的口碑。
4.2 用iw配置AP模式的关键命令和顺序
把无线网卡变成热点，常见方案是hostapd配合DHCP服务，iw在其中负责两件事：把接口模式切成AP，以及在部分场景下预设信道。
典型命令如下：
ip link set wlan0 down iw dev wlan0 set type ap iw dev wlan0 set channel 6 HT20 ip link set wlan0 up顺序很重要。我习惯先把接口down掉，切模式，再设信道，最后把接口up。如果先up再设信道，有些驱动会报错或者设置不生效。其实hostapd自己也会设置信道，所以iw set channel在某些流程里可以省略，但手动先设的好处是能提前暴露频段或DFS方面的问题，避免hostapd启动到一半才发现信道不可用。
切到AP模式后，iw dev wlan0 info里type会显示AP。接下来hostapd配置里指定这张接口并启动，AP就能工作了。有人会问，能不能靠iw开一个"裸AP"？理论上你切到AP模式后手动构造beacon帧数据，可以做出最原始的AP，但正常业务没人这么干，协议层面的associate、authentication、密钥协商都需要一个完整的用户空间程序来完成，hostapd就是这个角色。iw更像是帮你准备好舞台，真正的演出还是hostapd。
注意：AP模式下，5GHz频段如果落在DFS信道，开机会有一段CAC等待时间，从几十秒到几分钟不等。这段时间看起来像是卡住了，其实是法规要求在确认雷达不存在之前不允许发送信号。别上来就
systemctl restart hostapd，先看日志。
5. 调优与排错：信道、频宽、发射功率和常见失败
5.1 信道、频宽和发射功率的设置逻辑
无线调优的基础是选对信道、设好频宽。iw dev wlan0 set channel 6 HT20表示把接口固定到2.4GHz的6信道，带宽20MHz。如果你用5GHz的36信道，就是iw dev wlan0 set channel 36 HT80之类。这里有个知识点：2.4GHz建议用HT20，因为信道只有14个，互相重叠是常态，开40MHz在2.4GHz下很容易跟邻居互相踩；5GHz空间大，用HT80甚至HT160能跑出更高吞吐，但要先确认网卡和驱动支持，以及当前法规域是否允许。
发射功率命令是：
iw dev wlan0 set txpower fixed 20 iw dev wlan0 set txpower autofixed后面跟的数值单位是dBm。需要强调，这个"固定20"只是设置一个目标上限，最终功率还会被硬件能力、固件限制和法规域三重夹击。比如某块网卡最高只能21dBm，你设30也没用；法规域限制了某个频段最大17dBm，固件会在内部截到17。所以查询实际生效功率，还是以iw dev或iw phy的输出为准，不要拿自己设置的数字去对预期。
法规域（regulatory domain）是另一个经常被忽略的参数。iw reg get可以查看当前系统使用的法规域规则，输出会列出每个频段允许的信道和功率。iw reg set配合对应的地区代码可以临时切换法规域，但重启后通常恢复默认。这里有个实际经验：如果你发现5GHz某些信道在扫描结果里永远看不到，或者开AP时报DFS相关错误，先检查一下当前法规域是否允许这些信道，别急着怀疑网卡坏了。
5.2 几个高频报错的完整排查链路
实际调试中遇到最多的报错可以归成三类，我把每类的排查链路写出来。
第一类，command failed: Operation not permitted (-1)。这个最直白，多数情况是权限不够，sudo一下就好。但我也遇到过sudo之后还报的，那就要看是不是安全策略或容器限制，比如某些容器环境对netlink操作做了约束，这种情况下iw命令在容器里基本不可用，得回到宿主机执行。
第二类，command failed: Device or resource busy (-16)。通常是接口已经在使用中，比如网络管理服务正在管理这张卡。先ip link set wlan0 down，或者停掉网络管理服务再试。还有一种情况是驱动不支持在接口up状态切换模式，必须严格遵守"down、切模式、up"的顺序。我建议把这三个命令写成一个小的shell函数，避免每次手敲漏掉中间步骤。
第三类，command failed: Operation not supported (-95)。这个最需要动脑子。它说明驱动或固件对当前操作没有实现。比如在老驱动上执行iw dev wlan0 scan trigger，可能就不支持；在一些基础驱动上，set txpower fixed也可能不支持。排查思路是回到iw list看支持的命令列表，如果里面根本没有对应条目，那就不是命令写法问题，而是功能缺失。想解决，要么换驱动、换固件版本，要么换硬件，靠命令绕是绕不过去的。
还有一种让人头大的现象：扫描输出为空，但周围明明有AP。这时先检查接口模式是不是managed，再检查当前法规域是否限制了被动扫描，最后试试换一个信道，或者用scan trigger加scan dump的组合。有些网卡的驱动对主动扫描支持不好，改成被动方式反而能出结果。这类问题在笔记本上尤其多，因为它们经常受到省电策略和固件功耗管理的影响。
6. 一些实战后的经验沉淀
6.1 把iw命令写进脚本之前，先想清楚三件事
我在写自动化脚本时踩过几次坑，总结下来有三件事必须提前想清楚。
第一，命令的幂等性。iw dev wlan0 set type monitor在已经是monitor时再执行一次，很多驱动不会报错，但有些会。所以脚本里最好先检查当前类型，用条件判断决定是否切换，别盲目执行。第二，状态的可见性。iw很多操作是异步的，连接、扫描、模式切换都是，命令执行完不等于操作完成。脚本里要轮询iw dev wlan0 link或者借助iw event确认状态，否则下一步操作可能在错误的时间点发起。第三，root权限。iw几乎所有写操作都要root，如果脚本是以服务账户运行的，记得配置好sudo权限，别在脚本里硬塞明文密码。
6.2 善用iw event这个调试利器
iw event可能是最被低估的功能。打开一个终端运行iw event，然后在另一个终端里执行扫描、连接、断开操作，你会实时看到内核发出的无线事件，比如扫描开始、扫描完成、连接成功、认证失败、信道变化等。我排查"为什么连不上"这类问题时，一半的答案是从iw event的输出里找到的。比如它能看见连接过程中驱动层是否报错、是否触发了漫游、信标是否丢失，这些信息是iw link给不了的。
有一个典型场景：客户端连接AP后频繁掉线。iw link只能看到当前状态，看不出掉线原因。用iw event挂一会儿，就能看到内核是不是报告了beacon loss、deauth reason或者disconnect事件。如果是beacon loss，方向就很明确：要么距离太远，要么AP侧信道干扰严重，要么网卡省电模式设置太激进。
6.3 学会把iw和ip、ethtool、wpa_supplicant搭配使用
iw不是孤立存在的工具。接口的up/down、IP地址配置属于ip命令的职责；物理链路状态和协商速率可以看ethtool；WPA认证交给wpa_supplicant；iw的角色是无线参数的管家。整个调试链路通常是这样的：先ip link确认接口存在，再iw dev确认无线状态，需要连接就配合wpa_supplicant，连接后用iw dev wlan0 link确认关联，再用ip命令配地址。把工具边界搞清楚，排查效率会高很多，这也是我对新人最常说的一条建议。
以连接一个WPA2网络为例，完整的命令链路是这样的：
ip link set wlan0 up wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant.conf # 等待几秒，wpa_supplicant完成认证 iw dev wlan0 link dhclient wlan0 # 或者用 dhcpcd、NetworkManager 分配地址每一步都有对应的检查手段，不要跳过确认直接往下走。尤其是iw dev wlan0 link这一步，经常能发现认证虽然成功、但速率或者信号异常的情况，比到应用层才发现网络不通要省事得多。
6.4 一些小众但关键的命令备忘
最后整理几个不常用但关键时刻救命的命令。
查看wdev编号和接口细节用iw dev wlan0 info；查看某个phy的完整能力用iw phy phy0 info；查看当前网络环境的信道占用情况，用iw dev wlan0 survey dump，可以看到每个信道的繁忙时间占比，这比盲目换信道靠谱得多。做无线站点密度评估时，这条命令的价值非常大，它直接反映空中信道的拥堵程度。
多接口场景下，iw phy phy0 interface add wlan1 type managed可以让你在一个物理网卡上创建第二个虚拟接口，某些支持多BSS的驱动还能同时跑AP和客户端。删除接口的对应命令是iw phy phy0 interface del wlan1。不过要提醒一句，虚拟接口数量多了之后，驱动和固件压力不小，性能会下降，不要贪多。
还有iw dev wlan0 get power_save和iw dev wlan0 set power_save off，可以查询和关闭无线网卡的省电模式。在需要稳定低延迟的场景（比如长时间长ping、无线投屏测试）关闭省电模式，能明显减少延迟抖动。这也是很多人不知道的小开关，默认开启的省电模式在弱信号环境下的表现经常让人误判成网卡故障。
我在实际使用中发现，iw这个工具虽然看起来命令不少，但真正高频的也就十来条。把iw dev、iw list、iw link、iw scan、iw station dump、iw event这六条吃透，解决八成以上的无线网络排查问题都不难。剩下的set type和set channel、set txpower属于模式切换和调优范畴，配合本篇文章里的顺序和报错排查思路，多试几次自然就熟了。
最后再分享一个小技巧：在确认无线问题之前，先看dmesg尾部有没有无线驱动相关的报错。很多iw命令执行失败，根源在驱动或者固件已经崩了，这时候你反复敲iw命令是没有意义的，不如先解决驱动层面的问题。我习惯的顺序是：dmesg看内核、iw dev看状态、iw event看事件、再决定要不要动配置。这套流程走下来，大部分无线网络问题都能定位到具体环节，剩下的就交给耐心和抓包工具了。
