在进行 Android 自动化脚本编写、App 开发或刷机调试时，许多开发者喜欢在 WSL（Windows 子系统 Linux） 环境下部署运行环境。

然而，在日常使用中，大家经常遇到一个难以绕过的痛点：在 Windows 本地（如 CMD 或 PowerShell）中连接手机一切正常，但在 WSL 终端输入 adb connect 或 adb devices 时，却反复出现 unauthorized（未授权）或 failed to authenticate（认证失败）的报错。哪怕在手机屏幕上多次勾选了“一律允许这台计算机进行调试”，依然无法建立稳定的连接。

本文将为您剖析这一现象的底层原理，并提供两种不同应用场景下的系统化解决方案。

一、 为什么 WSL 与 Windows 的 ADB 密钥会冲突？

Android 系统的 ADB 安全认证基于 RSA 非对称加密机制。

  1. 密钥配对原理：电脑端首次尝试连接手机时，会生成一对密钥——私钥（adbkey）与公钥（adbkey.pub）。公钥会被推送到手机端的白名单数据库（/data/misc/adb/adb_keys）中。后续连接时，双方通过这套密钥在后台进行静默的签名校验。
  2. 多系统沙盒隔离：由于 WSL 是一个独立的 Linux 虚拟化环境，它与 Windows 宿主机物理上处于两个不同的系统环境：
    • Windows 宿主机 的密钥默认存放在：C:\Users\<您的用户名>\.android\
    • WSL 虚拟系统 的密钥默认存放在：~/.android/
  3. 冲突表现：当您用 USB 线或无线网络连接 Windows 时，手机信任并保存的是 Windows 的公钥。当您切换到 WSL 终端运行 ADB 命令时，WSL 会使用它自身的私钥去发起握手。手机发现密钥无法匹配，便会拒绝连接。如果此时连接超时或网络波动，PC 端就会直接显示 failed to authenticate。

要彻底解决这一冲突，我们可以采用以下两种思路。

二、 方案一：密钥同步法（适合纯无线/简单调试场景）

该方法的核心思想是：让 WSL 直接套用 Windows 宿主机已获得授权的密钥对。在手机看来，WSL 客户端与 Windows 本地客户端拥有相同的“身份”。

1. 清理 WSL 内现有的冲突密钥

打开 WSL 终端，备份并移除 WSL 内部原有的密钥对（如果提示目录不存在，可直接跳过）：

mkdir -p ~/.android
mv ~/.android/adbkey ~/.android/adbkey.bak 2>/dev/null
mv ~/.android/adbkey.pub ~/.android/adbkey.pub.bak 2>/dev/null

2. 将 Windows 密钥复制至 WSL

利用 WSL 的物理挂载路径（/mnt/c/），将 Windows 下已获手机授权的密钥对复制过来（请将命令中的 WindowsUsername 替换为您实际的 Windows 用户名）：

cp /mnt/c/Users/WindowsUsername/.android/adbkey ~/.android/adbkey
cp /mnt/c/Users/WindowsUsername/.android/adbkey.pub ~/.android/adbkey.pub

3. 修正 Linux 下的文件权限（关键步骤）

在 Linux（WSL）安全机制下，私钥文件（adbkey）如果权限过高，ADB 服务出于安全考虑会拒绝加载该私钥。因此需要严格限制其权限：

# 将私钥限制为仅当前所有者可读写
chmod 600 ~/.android/adbkey
# 将公钥设置为标准只读权限
chmod 644 ~/.android/adbkey.pub

4. 重启服务并重新连接

在 WSL 终端中清理缓存并重新发起连接：

adb kill-server
adb connect <手机IP>:5555

此时，WSL 将直接使用已被手机信任的 Windows 密钥完成握手，实现无感秒连。

三、 方案二：服务代理法（适合物理 USB/复杂开发场景）

如果您需要经常使用物理数据线连接设备，或者进行 Flutter、React Native 等跨平台复杂开发，频繁在 WSL 和 Windows 之间挂载 USB 设备会非常繁琐。

此时最规范的做法是：关闭 WSL 本地的 ADB 守护进程，将其作为一个纯“客户端”，把所有 ADB 请求转发给 Windows 宿主机的 ADB 服务统一处理。这样，无论是物理连接还是无线连接，两端都共享同一个 ADB 状态。

⚠️ 前提条件：Windows 宿主机和 WSL 内部安装的 ADB 工具主版本号必须完全一致（如：都是 1.0.41），否则两端会因为版本冲突而频繁互相杀掉对方的后台进程。您可以在两端分别输入 adb version 进行核对。

1. 允许 Windows ADB 监听局域网请求

在 Windows 本地（如 CMD 或 PowerShell）中，杀死原有的独立服务，并启动一个允许外部访问的代理服务：

# 杀掉现有服务
adb kill-server

# 启动并监听所有网卡接口上的 5037 端口（ADB 默认端口）
adb -a -P 5037 nodaemon server start

2. 在 Windows 防火墙中放行该端口

由于 WSL 与宿主机之间存在虚拟网络边界，需在 Windows 防火墙中允许 WSL 访问 Windows 的 5037 端口：

  1. 打开 Windows 的“高级安全 Windows Defender 防火墙”。
  2. 在左侧选择 入站规则，右侧点击 新建规则。
  3. 规则类型选择 端口 -> TCP -> 特定本地端口输入 5037。
  4. 操作选择 允许连接。
  5. 配置文件全选，名称命名为 ADB WSL Bridge 并保存。

3. 配置 WSL 环境变量指向宿主机

我们需要告诉 WSL 中的 ADB 客户端，去连接 Windows 的 IP 和端口。

打开 WSL 终端，编辑您的配置文件（以 Bash 为例）：

nano ~/.bashrc

在文件末尾添加以下配置，以便动态获取 Windows 宿主机在虚拟网卡中的 IP 地址并进行重定向：

# 动态获取 WSL 对应的宿主机 IP 并设置 ADB 套接字重定向
export WINDOWS_HOST_IP=$(ip route show default | awk '{print $3}')
export ADB_SERVER_SOCKET=tcp:$WINDOWS_HOST_IP:5037

保存并退出（Nano 编辑器中按 Ctrl+O 写入，Ctrl+X 退出），然后刷新配置：

source ~/.bashrc

4. 验证效果

在 WSL 终端直接输入：

adb devices

此时，您无需在 WSL 中执行任何连接操作，只要 Windows 本地已经连接（无论是物理 USB 还是网络连接）的手机设备，都会同步在 WSL 的列表里呈现为 device 状态。

四、 两种方案如何抉择？

  • 选择方案一（密钥同步）：如果您仅仅是在 WSL 下跑一些轻量的 Python/Go 自动化脚本、或者使用纯无线调试，不想在 Windows 本地常驻一个后台监听进程。此方案配置最为简单、独立。
  • 选择方案二（服务代理）：如果您是专业的 App 开发者，需要频繁使用物理数据线或模拟器，并且需要两端环境保持高度一致。此方案能够从根本上规避设备在两个系统中频繁切换挂载的麻烦。