1. 问题现象与根源剖析

“无法连接到 xxx.xxx.x.xx:5555: 由于目标计算机积极拒绝，无法连接。 (10061)”，这个错误弹窗对于任何一个需要通过 ADB 调试 Android 设备的开发者或测试人员来说，都太熟悉了。它就像一个不请自来的访客，总是在你最需要稳定连接的时候出现，打断你的调试流程。这个错误的核心信息非常明确：你的电脑（客户端）试图向目标 IP 地址的 5555 端口发起 TCP 连接，但对方（通常是你的手机或模拟器）的 5555 端口根本没有在监听，或者明确拒绝了这次连接请求。用更通俗的话说，你敲了门，但屋里没人，或者主人把门锁死了，不让你进。

错误码 10061 是 Windows 系统网络层面的一个标准错误，对应WSAECONNREFUSED。它和 ADB 本身关系不大，更多是底层 TCP 协议栈返回的结果。所以，当你看到这个错误时，首先要明白，问题大概率出在“服务端”——也就是你的 Android 设备——的 ADB 调试服务没有正常启动或网络不可达，而不是你电脑上的 ADB 客户端命令敲错了。

这个问题的诱因可以归结为几个典型场景：最常见的是无线调试时，手机的 ADB 调试监听端口（默认 5555）没有打开；其次是有线连接时，虽然 USB 已连通，但设备的 ADB 守护进程（adbd）可能因为系统休眠、权限变更或冲突而异常；再者，电脑和手机不在同一个局域网网段，或者防火墙（包括 Windows Defender 防火墙、第三方安全软件、甚至路由器的安全策略）阻断了 5555 端口的通信。每一次连接失败，都是一次对开发者网络基础、ADB 工作原理和排查耐心的综合考验。

2. ADB 连接模式与通信原理深度解析

要彻底解决连接问题，必须理解 ADB 是如何工作的。ADB 采用客户端-服务器架构，这个“服务器”运行在你的开发电脑上，称为 ADB Server（进程名为adb.exe）。它负责管理所有连接到电脑的 Android 设备（无论是通过 USB 还是 TCP/IP），并处理来自客户端（如 Android Studio、命令行输入的adb命令）的请求。

设备连接主要有两种模式：

2.1 USB 调试模式这是最传统、最稳定的方式。当你用数据线连接手机并开启“开发者选项”中的“USB 调试”后，手机会启动一个 adbd 守护进程。电脑端的 ADB Server 会通过 USB 驱动与手机的 adbd 建立连接。此时，在命令行输入adb devices，你会看到设备序列号后面跟着device状态。这种模式下，通信完全走 USB 总线，不依赖网络，所以一般不会出现 10061 错误，除非驱动异常、USB 线仅支持充电、或手机端的 adbd 进程崩溃。

2.2 网络（TCP/IP）调试模式这是出现 10061 错误的“重灾区”。该模式又分为两种子情况：

• 无线调试（Wireless Debugging）：这是 Android 11 及以上版本官方推荐的方式。在开发者选项中开启“无线调试”后，手机会随机开启一个端口（如 3xxxx）用于配对和调试。你需要先在手机上通过配对码与电脑配对，之后 ADB 才会通过一个固定的端口（通常是 5555）进行常规通信。很多人在配对成功后，直接使用adb connect <手机IP>:5555，如果此时手机的 5555 端口监听未就绪，就会立刻触发 10061。
• 从 USB 切换到无线：这是一种经典的无线连接方法。先通过 USB 线正常连接设备，然后执行adb tcpip 5555命令。这个命令会重启手机上的 adbd，并让其监听 5555 端口。拔掉 USB 线后，再执行adb connect <手机IP>:5555。如果切换不成功，或者手机 IP 地址发生变化，连接时就会报错。

关键在于，5555 端口必须在设备的 adbd 进程上处于监听状态。你可以通过在已连接设备的 ADB Shell 中执行netstat -tlnp | grep 5555或getprop service.adb.tcp.port来验证。如果看不到 5555 端口的监听，那么任何来自网络的连接尝试都必然失败。

3. 系统性排查与解决方案实战

面对 10061 错误，不要盲目尝试。遵循一个系统性的排查路径，可以高效地定位问题。

3.1 基础环境检查首先，确认最基本的前提条件是否满足：

1. 开发者选项与 USB 调试：确保手机的“开发者选项”已开启，并且“USB 调试”开关是打开的。这是所有 ADB 调试的基石。
2. 电脑端 ADB 状态：在命令行输入adb version，确认 ADB 工具已正确安装且版本不过旧。同时，检查 ADB Server 是否运行：adb start-server。有时杀掉重启一下 Server 能解决玄学问题：adb kill-server&&adb start-server。
3. USB 连接状态（如果使用或有线切换）：使用原装或高质量的数据线。在电脑的“设备管理器”中，检查 Android 设备是否被正确识别为“Android Composite ADB Interface”，而不是带有感叹号的未知设备。如果是后者，需要安装或更新对应的 USB 驱动。

3.2 网络连接专项排查当问题出现在无线连接时，网络是首要怀疑对象。

1. 确认 IP 地址：确保你使用的 IP 地址是手机在当前 Wi-Fi 网络下的内网 IP。在手机的“设置”->“关于手机”->“状态信息”里查看，或者连接 Wi-Fi 后点击网络名称查看详情。一个常见陷阱：手机可能连接了 2.4GHz 和 5GHz 的双频 Wi-Fi，但电脑连接的是另一个频段，虽然 SSID 相同，但在路由器内部可能属于不同虚拟网络，导致无法直连。
2. 验证网络互通性：在电脑的命令行里，使用ping <手机IP>。如果能通，说明基础网络链路是好的。如果不通，问题就在网络配置上，需要检查路由器设置、防火墙规则，或者尝试将电脑和手机都连接到手机的热点上来排除路由器问题。
3. 检查端口监听状态（关键步骤）：这是诊断 10061 的核心。在电脑上使用telnet <手机IP> 5555命令。如果端口开放且 adbd 在监听，你会看到一个空白窗口或者连接后立即断开（因为 adbd 期待的是 ADB 协议数据，不是 Telnet 的）。如果显示“无法打开到主机的连接... 在端口 5555: 连接失败”，那就坐实了 5555 端口未开放。
4. 防火墙规则：临时关闭电脑的 Windows Defender 防火墙以及任何第三方安全软件的防火墙功能，再次尝试连接。如果此时成功，说明需要手动在防火墙入站规则中为adb.exe和端口 5555 添加允许规则。

3.3 设备端服务状态修复如果网络是通的，但端口未开，问题就在手机本身。

1. 重启 adbd 服务：
   • 如果有线可用：用 USB 线连接手机，执行adb usb切换回 USB 模式，再执行adb tcpip 5555重新开启网络监听。仔细观察命令输出是否有错误。
   • 如果无法有线连接：对于 Android 11+，进入“开发者选项”->“无线调试”，先关闭再重新打开。或者使用其提供的“使用配对码配对设备”功能，这是最可靠的方式。
2. 检查系统设置：确保“开发者选项”中的“仅充电模式下允许 ADB 调试”等选项是打开的。有些厂商（如华为、小米）有额外的“USB 调试（安全设置）”需要授权，或者需要在连接时在手机上点击“允许调试”的弹窗。
3. 终极重启：重启手机和电脑。这能解决大量因系统状态缓存、进程死锁导致的疑难杂症。

3.4 进阶与疑难杂症处理当上述方法都失效时，可能需要考虑一些边缘情况。

• 端口占用冲突：极少数情况下，手机上的其他应用可能占用了 5555 端口。可以通过adb shell netstat -tlnp（需要 root 权限）查看，或者尝试在adb tcpip命令中指定另一个端口，如adb tcpip 5556，然后使用adb connect <手机IP>:5556连接。
• 厂商定制系统限制：某些国内手机厂商的深度定制系统（如 MIUI、EMUI）为了“安全”，可能会在后台限制或定时关闭 ADB 网络调试。除了在开发者选项里仔细寻找相关设置（如“MIUI 优化”关闭后可能会影响），可能需要频繁重复激活操作。
• ADB 版本兼容性问题：确保电脑端的 ADB 版本不是太老。从 Android SDK Platform-Tools 官网下载最新版本替换旧版。
• 使用第三方工具辅助：像 Scrcpy、QtScrcpy 这类工具在连接时，其内置的 ADB 逻辑有时比手动操作更稳定，可以作为一个连接状态的测试手段。

4. 标准化操作流程与避坑指南

根据我的经验，建立一套标准的操作流程，能最大程度避免 10061 错误。

4.1 无线调试标准化流程（Android 11+）

1. 手机和电脑连接到同一个Wi-Fi 网络（最好用 5GHz，干扰少）。
2. 手机开启“开发者选项”->“无线调试”。
3. 点击“使用配对码配对设备”，记下显示的 IP 地址、端口和六位配对码。
4. 在电脑命令行执行：adb pair <手机IP>:<配对端口>，然后根据提示输入配对码。看到“Successfully paired...”表示成功。
5. 配对成功后，“无线调试”页面会显示一个“已配对的设备”及其 IP 地址和端口（通常是:5555）。
6. 此时再执行adb connect <手机IP>:5555。连接成功后，adb devices会列出该设备。

注意：配对（pair）和连接（connect）是两个独立的步骤。配对是建立信任关系，连接是建立通信通道。很多人只做了第二步，所以失败。

4.2 USB切换无线标准化流程（通用）

1. 用 USB 线连接手机和电脑，确保adb devices能识别到设备（状态为device）。
2. 执行adb tcpip 5555。看到“restarting in TCP mode port: 5555”输出。
3. 不要立即拔线。在手机上查看并记录当前的 Wi-Fi IP 地址。
4. 执行adb connect <手机IP>:5555。看到“connected to ...”输出。
5. 此时，adb devices列表里应该会有两个条目：一个是通过 USB 的，一个是通过网络的。现在可以安全地拔掉 USB 线，网络连接会继续保持。

4.3 常见“坑点”实录

• 坑点一：IP地址变更：手机在 Wi-Fi 断开重连或切换网络后，IP 地址会变。之前成功的adb connect命令就会失效。每次重新连接前，务必确认当前 IP。
• 坑点二：电脑多网卡：如果电脑同时连着有线网卡和无线网卡，或者开了 VPN，ADB 连接请求可能会从错误的网卡发出。可以通过adb -H <电脑本机在手机所在网络的IP> connect ...来指定源地址，或者暂时禁用不用的网络适配器。
• 坑点三：省电策略杀进程：手机锁屏或进入深度省电模式后，系统可能会挂起或杀死 adbd 进程。需要在手机的“设置”->“电池”->“省电策略”或“应用启动管理”中，将“开发者选项”或相关系统进程设为“允许后台活动”。
• 坑点四：命令顺序错误：一定要先确保 USB 调试模式下设备在线（adb devices可见），再执行adb tcpip。如果设备不在线，tcpip命令找不到目标，会静默失败。

5. 问题诊断命令速查与脚本化方案

当问题出现时，一系列命令可以帮助你快速定位瓶颈。我将它们整理成一个诊断流程图和对应的命令集。

5.1 诊断命令速查表

5.2 自动化连接脚本对于需要频繁进行无线调试的场景，可以编写一个简单的批处理脚本（Windows）或 Shell 脚本（macOS/Linux）来减少手动操作和错误。

@echo off REM Windows Batch Script: auto_connect_adb.bat echo 正在检查并重启ADB服务... adb kill-server timeout /t 2 /nobreak > nul adb start-server timeout /t 2 /nobreak > nul echo 请确保手机已通过USB连接并授权... adb devices -l pause echo 正在切换设备至TCP模式（端口5555）... adb tcpip 5555 if %errorlevel% neq 0 ( echo 错误：切换TCP模式失败，请检查USB连接和设备授权。 pause exit /b 1 ) echo 请在手机上查看并输入当前的Wi-Fi IP地址： set /p PHONE_IP=请输入IP地址（例如 192.168.1.100）: if "%PHONE_IP%"=="" ( echo 未输入IP地址，脚本退出。 pause exit /b 1 ) echo 正在尝试通过网络连接 %PHONE_IP%:5555 ... adb connect %PHONE_IP%:5555 echo 连接完成，当前设备列表： adb devices -l pause

这个脚本完成了从杀死旧服务、重启、通过 USB 切换模式到最终发起网络连接的全过程，并将关键步骤和状态反馈出来，非常适合在固定开发环境中使用。

5.3 连接稳定性维护即使连接成功，也可能在使用中意外断开。可以设置一个简单的监控循环，在检测到设备离线时自动重连。但更务实的做法是理解其不稳定的原因：Wi-Fi 休眠、路由器 QoS 策略、手机系统清理后台等。因此，对于需要长时间稳定调试的任务，USB 连接仍然是首选。无线调试更适合短期的、需要移动性的调试场景。

解决“adb cannot connect ... 10061”的过程，本质上是对 Android 调试体系、网络基础和操作系统交互的一次深入实践。它没有一成不变的银弹，但通过结构化排查——从验证基础状态、检查网络链路、确认服务端口到调整系统设置——绝大多数问题都可以被定位和解决。最深刻的体会是，耐心和顺序往往比盲目尝试更重要。每次成功连接背后，都是一次对细节的掌控。