大厂男孩的粉丝很多人在 macOS 上第一次尝试 ADB 无线调试，习惯性敲完 adb tcpip 5555 和 adb connect <手机IP>:5555 就等着看 connected，结果等来的是 error: protocol fault (couldn't read status message): no error。如果这时候手机还连着 USB，烦躁感会直接翻倍——明明有线好好的，怎么一到无线就各种幺蛾子。这篇文章就围绕这条报错链路，把 macOS 环境下无线调试从配对、连接到稳定使用的完整排查过程写清楚，尤其是 Protocol Fault 和端口占用这两个让人摸不着头脑的问题。
这篇文章适合谁看？第一类是刚接触 ADB 无线调试的移动开发或测试同学，需要一套能直接照做的排查路径；第二类是被 protocol fault 反复折磨、搜了半天没找到靠谱答案的进阶用户；第三类是想彻底搞懂 ADB over Wi-Fi 底层机制、避免以后再踩坑的折腾党。我会结合自己实际踩坑的经历，把能复现的步骤、能直接执行的命令、能解释清的原理都放进来。
1. 无线调试不是开个开关就行：先搞清楚 ADB over Wi-Fi 的完整链路
排查任何问题之前，得先知道"正常情况应该长什么样"。ADB 无线调试看着就一条 adb connect 的事，但背后至少涉及四层协作：ADB Server、mDNS 服务发现、TCP 连接建立、以及 adbd 的认证和会话管理。
1.1 ADB 工作模式的两个阶段：Pairing 和 Connecting
从 Android 11 开始，官方推荐的方式是"无线调试"面板里的配对码模式，这其实是把无线调试拆成了两个阶段。
第一阶段是配对（Pairing）。手机开启无线调试后，会弹出一个六位配对码，同时开启一个临时的 mDNS 服务。macOS 上的 adb pair 命令通过 mDNS 发现设备，用配对码完成密钥交换。这个阶段走的是 37000 到 39999 之间的随机端口，本质上是 TLS 加密的配对通道。
第二阶段才是真正的连接（Connecting）。配对成功后，adbd 会监听一个固定端口（通常是你用 adb tcpip 指定的端口，或者无线调试面板里显示的端口），macOS 上的 adb client 通过 adb connect IP:端口 建立 TCP 连接。连接建立后，还要经过 RSA 密钥认证——如果电脑的调试授权没有通过，就会卡在 unauthorized 状态。
很多人在 macOS 上遇到的问题，恰恰是第一阶段 mDNS 发现失败，或者第二阶段 RSA 授权缓存出错，导致表面上看是 connect 成功但马上断开，或者直接 cannot connect。Protocol Fault 则是比连接失败更深一层的协议级异常，后面单独说。
1.2 macOS 环境准备：该装的、该开的、该授权的
在排查具体报错之前，我建议先把 macOS 侧的环境整理干净，排除掉基础环境干扰。
code复制brew install android-platform-tools
安装完以后确认版本，adb version 至少是 1.0.41 以上，太老的版本对 Android 12+ 设备支持不好。然后确认 adb 所在的路径在 PATH 里，macOS 上常见路径是 /opt/homebrew/bin（Apple Silicon）或 /usr/local/bin（Intel）。
然后是系统设置里的三个关键授权：
- “隐私与安全性”里的“本地网络”权限，必须允许终端 App 访问本地网络，否则 mDNS 广播和连接请求会被 macOS 直接拦掉。
- “开发者模式”在 macOS 上不是必须的，但如果用了 Xcode 的命令行工具，要确保
adb使用的是 Homebrew 版本，而不是 Xcode 自带的旧版。用which adb检查。 - 手机侧开发者选项里的“USB 调试”和“无线调试”都要保持开启，且 USB 连接状态要正常。
我见过不少案例，排查了半天 Protocol Fault，最后发现是 macOS 的防火墙把 adb 的出站连接拦了。如果你开了第三方防火墙（比如 Little Snitch），第一次跑 adb connect 时务必允许 adbd 相关的连接请求。
1.3 一个小测试：先确认 mDNS 能发现设备
在跑 adb connect 前，先看一眼设备能不能被发现：
code复制adb mdns services
正常会输出类似 _adb-tls-connect._tcp 和 _adb-tls-pairing._tcp 这样的服务记录。如果这里为空，mDNS 这一层就有问题，后面的 Protocol Fault 只是表象。macOS 的 mDNSResponder 偶尔会抽风，可以用 sudo killall mDNSResponder 重置，系统会自动拉起。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Protocol Fault 的根因拆解：为什么好端端的连接会在协议层崩掉
error: protocol fault (couldn't read status message): no error 这句报错的重点在 couldn't read status message。ADB 客户端和 adbd 之间通信走的是 ADB 协议，每条消息都有固定的包头和负载，协议层在读状态消息时失败，意味着连接在消息交互中途被中断了——不是没连上，而是连上了又说断就断。
2.1 这一行报错到底在说什么：ADB 协议的状态机视角
用一个生活化的类比：ADB 客户端和 adbd 就像两个打电话的人，说好每说一句话都要回一声“收到”。protocol fault 就是你说了“你在吗”，对面电话直接挂断了，连“不在”都没说。这通电话不是没打通，而是通话过程中物理链路断了。
在 ADB 协议里，A_SYNC 和 A_CNXN 是连接建立的握手包。连接后，client 发送 A_OPEN 打开某个服务（比如 shell: 或 sync:），adbd 返回 A_OKAY 或 A_FAIL。couldn't read status message 一般发生在 client 发送请求后等待响应时，read 操作返回了空或错误，协议状态机直接判定为 fault。
出现这个错误，我总结过三个高频根因：
- 网络链路不稳定：Wi-Fi 信号弱、路由器开启了 AP 隔离、设备在 5GHz 和 2.4GHz 频段间自动切换导致链路闪断。
- 设备侧资源问题：手机系统内存不足、adbd 进程被杀、系统省电策略在后台限制 adbd 的 socket。
- macOS 和设备的 TCP keepalive 参数不匹配：连接长时间空闲，防火墙或 NAT 设备把连接关掉了。
2.2 一次完整的 Protocol Fault 排查链路（可复现）
这套排查方法我整理成了一个顺序执行的清单，按这个顺序走，能快速定位 90% 的 Protocol Fault 问题。
| 排查层 | 检查内容 | 使用命令/方法 | 预期正常结果 |
|---|---|---|---|
| Transport 层 | 设备是否能被 adb 识别 | adb devices -l |
能看到设备序列号，状态为 device |
| USB 链路 | 有线连接是否正常 | adb usb |
能正常切换回 USB 模式 |
| mDNS 发现 | 无线服务是否被广播 | adb mdns services |
能看到 _adb-tls-connect 服务 |
| 端口连通性 | 手机端口是否可达 | nc -vz <手机IP> <端口> |
open |
| 协议层 | 连接后能否正常执行命令 | adb -s <序列号> shell echo 1 |
输出 1 |
先别急着连无线，把 USB 有线连接的健康状态确认好。很多 Protocol Fault 其实是手机端 adbd 已经半死不活了。如果 USB 模式下 adb shell 都有问题，把手机重启一下，进入开发者模式后重新授权，再继续。
如果 USB 正常，adb devices 能看到设备，但无线连的时候协议错误，重点检查网络环境。
2.3 实测案例：手机 Wi-Fi 频段切换引发的协议中断
有一次我在测试一个 App 的长连接，手机放在客厅，路由器在卧室，中间隔了两堵墙。5GHz 信号只有两格，手机自动切到 2.4GHz，然后 5GHz 信号恢复，又切回去。这个切换过程看起来不影响使用，网页照样刷，但 TCP 连接已经断了。
无线调试对这种"表面连通、实际断裂"的链路特别敏感。因为 ADB 协议没有自动重连机制，TCP 断开后 client 端 read 返回错误，直接报 Protocol Fault。解决方案很粗暴：要么让手机固定用 2.4GHz 频段（信号穿透力强但干扰多），要么让路由器固定信道，关闭 Band Steering。我自己最后是选择坐在路由器旁边测试，让手机稳定连接 5GHz。
另外还有一个隐藏坑：路由器开启了 AP 隔离（又叫客户端隔离）。这个功能会让同一 Wi-Fi 下的设备无法互相访问，手机和电脑虽然在同一个局域网，但实际是“老死不相往来”。adb connect 的结果通常是超时或者 connect refused，偶尔也会表现成 protocol fault。判断方法很简单：手机和电脑互相 ping 一下，ping 不通基本就是 AP 隔离作祟。
提示：在家里调试时如果无线调试怎么都不稳，建议先在手机和电脑之间做一次
ping <手机IP>的持续测试，同时跑adb connect。如果 ping 的延迟忽高忽低，甚至有丢包，说明网络链路本身就不可靠，这个时候 Protocol Fault 只是结果，不是原因。
2.4 协议版本不匹配：platform-tools 和设备系统定制版的兼容问题
Protocol Fault 还有一个容易被忽略的触发条件：adb client 的协议版本和设备端 adbd 的协议版本不一致。Android 系统版本跨度大的时候尤其明显，比如电脑端是新的 platform-tools，但设备是 Android 8 的老系统，或者反过来，设备是最新的 Android 14 或 HarmonyOS，电脑端 adb 还是三年前的。
ADB 协议版本号在 A_CNXN 消息里通过 version 字段协商，如果双方的版本范围不兼容，连接会被直接拒绝。但有些国产系统（比如 MIUI、ColorOS、HarmonyOS）会对 adbd 做定制，行为不完全遵循 AOSP 标准，可能出现“连接成功但后续消息读取失败”的诡异情况。
处理方式：把 platform-tools 升级到最新版，同时如果有多个 Android SDK 版本，注意 ANDROID_HOME 环境变量指向的 platform-tools 是否和 PATH 里的 adb 一致。用 adb version 看版本号，用 which adb 看路径，两个必须对得上。
code复制export ANDROID_HOME=$HOME/Library/Android/sdk
export PATH=$PATH:$ANDROID_HOME/platform-tools
3. 端口占用：不只有 5037，5555 和 37000 段端口一样会卡脖子
端口占用在 Windows 上常见，但在 macOS 上一点都不罕见。而且 macOS 上的排查方式跟 Windows 不太一样，最典型的区别是：netstat -ano 是 Windows 的玩法，macOS 上要习惯用 lsof 和 nettop。
3.1 分清三个端口：5037、5555 与随机配对端口的归属
很多文章一谈端口占用就只盯着 5037，但无线调试场景下，有三个端口都必须关注：
| 端口 | 归属 | 作用 | 被占用时的表现 |
|---|---|---|---|
| 5037 | macOS 上的 adb server | adb client 与 server 的本地通信 | cannot bind to :5037 |
| 5555 | Android 设备上的 adbd | 无线调试连接端口 | cannot connect to <IP>:5555 |
| 37000-39999 | Android 设备上的 mDNS 配对服务 | 无线调试配对 | 配对码无效或配对超时 |
5037 端口是所有 adb 命令的入口。每次执行 adb shell 或 adb connect，client 都会先找 5037 端口上的 adb server，找不到就自己拉一个 server 起来。如果 5037 被其他进程占了，adb server 起不来，所有命令都报错。
5555 端口是设备端的 adbd 监听端口，跟电脑无关。但有一种常见情况：电脑上装了模拟器（比如 Android Studio 的 Emulator），模拟器会占用本机的 5555 端口。如果模拟器先启动了，adb connect <手机IP>:5555 的时候，连接请求可能被模拟器拦截。
3.2 macOS 端口排查命令的正确姿势
macOS 上的 lsof 命令配合 -i 和 -P 参数，比 netstat 好用得多。我常用的组合是：
code复制lsof -nP -iTCP:5037 -sTCP:LISTEN
这条命令返回的是监听 5037 端口的进程。-n 不做 DNS 解析避免慢，-P 不做端口名映射避免干扰，-sTCP:LISTEN 只显示监听状态的连接。
如果你需要更完整的连接状态（包括已经建立的连接、TIME_WAIT 等），去掉 -sTCP:LISTEN 限制：
code复制lsof -nP -iTCP:5037
那如果 5037 被占用了，怎么办？先看占用进程是谁：
code复制ps aux | grep -i adb
如果确认是 adb server 本身，直接 adb kill-server，正常情况下端口会释放。如果 adb kill-server 后端口还是被占用，用 lsof 拿到 PID，然后 kill -9 <PID>。
还有个 macOS 特有的坑：系统自带的 locationd 或其他系统进程不会占用 5037，但 Parallels Desktop 或者 Docker 的端口转发可能会。如果你装了 Parallels，Windows 虚拟机通过 NAT 模式共享网络时，有时候会把宿主机的端口映射占掉。检查方法一样， lsof 看到底是谁。
我在排查一个 Protocol Fault 问题时偶然发现，手机连着 USB 调试，但 5555 端口被本机的某个服务占了，导致 adb tcpip 5555 之后 adb connect <手机IP>:5555 总是连到本地服务上。用 lsof -nP -iTCP:5555 一看，监听进程不是 adb，而是某个开发工具的辅助进程。这种时候光杀 adb 没用，必须处理那个真正占端口的进程。
3.3 一个值得警惕的“伪端口占用”：LISTEN 状态但连接失败
有一种情况特别迷惑：lsof 显示 5037 端口有进程监听，adb devices 也能正常输出设备列表，但 adb connect 就是失败。
排查后我发现，这其实是 adb server 的空连接问题。adb server 在 macOS 上对 TCP 连接的管理有超时机制，某些情况下连接处于 LISTEN 状态，但 server 内部的 socket 已经半关闭。lsof 能看到监听，但实际已无法处理新连接。
遇到这种情况，最简单有效的操作：
code复制adb kill-server
adb start-server
adb devices
如果 kill-server 后 lsof 显示 5037 还是被占用，说明有残留进程。用 lsof -ti :5037 | xargs kill -9 强制清理，然后重新启动 adb server。
提示：macOS 上不要动不动就
sudo killall adb。如果 adb 是通过 Homebrew 装的，可能存在多个 adb 副本（比如 Android Studio 自带的、Homebrew 的、通过 sdkmanager 装的）。你要先确认当前用的是哪个，否则会杀掉一个无关副本，问题依旧。
4. 从连接到稳定：无线调试连上只是开始，链路维护才是关键
当 Protocol Fault 和端口占用问题都解决，adb connect 返回 connected 之后，很多人以为万事大吉。但实际用下来你会发现，无线调试真正考验人的不是“连上”，而是“保持连接”。
4.1 为什么连接会频繁断开：屏幕锁屏、网络切换、DHCP 租约
无线调试的连接是 TCP 链路，TCP 是面向连接的，但连接是否存活依赖两端的网络栈维护。手机锁屏后，系统为了省电，可能限制后台进程的网络访问，adbd 的 socket 处于半开状态，macOS 这边还傻傻地认为连接存活。等你下次跑 adb shell 的时候，read 超时或返回错误，无线调试就断了。
这个问题有几个处理策略：
- 手机开发者选项里开启“不锁定屏幕”（充电时保持唤醒）。
- 路由器 DHCP 租约时间设长一点（比如 24 小时以上），防止 IP 地址中途变化。
- 避免在手机和电脑之间使用 Wi-Fi 中继或 Mesh 网络的多跳节点，延迟和丢包率都会影响 ADB 连接。
- 如果调试任务需要长时间挂机（比如跑自动化测试），优先用 USB 连接，或者准备一条可靠的 Wi-Fi 链路。
4.2 用 adb 命令验证连接稳定性：连续执行命令和传输文件
连接是否稳定，不能只看 adb devices 里是不是 device 状态，要实际传数据验证：
code复制adb -s <设备序列号> shell "for i in $(seq 1 10); do echo test_$i; sleep 1; done"
adb -s <设备序列号> push ~/Desktop/testfile /sdcard/testfile
第一条命令验证持续的命令交互是否稳定，第二条命令验证数据传输是否可靠。如果 push 大文件到一半断开，说明 TCP 链路对大数据包不友好，可能需要检查 MTU（Mac 上有时会有 MTU 不一致导致的包分片问题）。
adb devices -l 的输出里，device 表示已经通过认证且连接正常，unauthorized 表示还没在手机上点“允许 USB 调试”，offline 表示连接已断开或设备端 adbd 异常。无线调试最怕的是 offline，它意味着你重新 adb connect 可能也连不上，必须先 adb disconnect 再重连。
4.3 日常调试时的连接维护习惯
我自己在实际工作中总结了一套 macOS 无线调试的“卫生习惯”，分享出来供参考：
- 每次开始调试前，先
adb kill-server再adb start-server，确保 adb server 状态干净。 - 连接手机前，先
adb usb确认 USB 状态，再adb tcpip 5555切换端口。如果已经连接无线，想切回 USB，先adb disconnect。 - 无线调试连接后，不要在手机上关闭“USB 调试”开关，否则 adbd 会退出。
- 手机和电脑连同一个 Wi-Fi 的同一频段，避免 2.4GHz 和 5GHz 混连。
- 长时间不用的连接，主动
adb disconnect，释放两端资源。
4.4 一个意外收获：无线调试功耗测试的可操作性
无线调试还有一个隐藏优势：它能让你在没有 USB 线的情况下做功耗相关的测试，比如电池续航测试或温度监控。USB 连接本身会为手机充电，干扰电量数据，无线调试则不会。
实际测试功耗时，我常用的命令是：
code复制adb shell dumpsys batterystats --enable full-wake-history
adb shell dumpsys battery
无线连接的状态下，batterystats 的数据会干净很多，不会因为你插着 USB 线导致“一直显示充电中”的尴尬。但要注意，无线调试本身也会消耗一定电量，高频日志输出和长时间的数据传输会让手机发热，进而触发系统降频。实测跑 30 分钟 logcat 后，手机背部温度会明显上升，此时 TCP 连接容易中断——这就是 Protocol Fault 在长时间调试场景下的另一种表现形式。
如果你遇到“连着无线调试，但跑一段时间后设备在 adb devices 里消失”的情况，大概率是设备的 Wi-Fi 被系统断开了。检查手机的 Wi-Fi 设置，把“休眠时保持 Wi-Fi 连接”设为“始终”，这是很多安卓系统的隐藏设置项，默认可能是“仅充电时”。
5. 写在最后的实际操作心得
这套排查路径我前前后后跑了不知道多少遍，总结下来，无线调试不是一条命令解决的事，它牵涉到 macOS 的网络权限、ADB 协议栈、手机端 adbd 行为、路由器的网络策略，每个环节都可能成为断点。
我踩过最深的坑是 mDNS 权限问题。macOS 升级到新版本后，终端第一次跑 adb mdns services 没有任何输出，但 adb connect 却能连上。后来发现是系统把 mDNSResponder 的访问限制改了，导致服务发现静默失败。这种问题不看日志很难察觉。
关于 Protocol Fault，如果让我给一个优先排查顺序，我会这样排：先确认有线连接是否正常，再检查无线网络环境（AP 隔离、频段切换、信号强度），然后看端口配置（5037 是否被占、5555 是否能通），最后检查 adb 版本和设备系统的兼容性。这个顺序能覆盖绝大部分故障场景。
macOS 环境下做开发调试，终端命令的熟练度直接影响排障效率。lsof 和 adb 的组合用熟了，很多问题都能在五分钟内定位。如果你一开始用不惯 lsof，可以先从 netstat -an | grep 5037 开始，但一定要知道它显示的信息不如 lsof 完整——尤其看不到进程归属，这一点在排查端口占用时是致命的。
最后再分享一个小技巧：把下面的别名加到 ~/.zshrc 里，排查时会顺手很多：
code复制alias adb-restart='adb kill-server && adb start-server'
alias adb-kill-port='lsof -ti :5037 | xargs kill -9'
alias adb-wifi='adb tcpip 5555 && adb connect'
无线调试本身是一个效率工具，别让连接问题消耗掉它带来的便利。把网络环境、系统权限、adb 版本这些变量都控好，你在 macOS 上就能像用 USB 一样顺畅地无线调试。