远程投屏隧道scrcpy 连接远程 Android 设备的 ADB 隧道实战基于 doc/tunnels.md【免费下载链接】scrcpyDisplay and control your Android device项目地址: https://gitcode.com/GitHub_Trending/sc/scrcpyScrcpy 默认面向 USB 直连的本地 Android 设备而 doc/tunnels.md 解决了另一个高频场景当 Android 设备连接在远程计算机上时如何从本机投屏并控制它。本文基于该文档完整覆盖「远程 ADB server」与「SSH 隧道」两种方案的操作步骤并结合 app/src/adb/adb_tunnel.c、app/src/server.c 的源码实现讲清--tunnel-host、--tunnel-port、--force-adb-forward三个参数的底层作用机制读完后你可以独立完成跨网络的 scrcpy 部署并理解隧道建立失败时的回退逻辑。方案总览为什么隧道能通向远程设备scrcpy 的通信链路是「客户端进程 → adb → 设备内嵌的 scrcpy server」。当设备挂在远程机器上时本机 scrcpy 无法直接找到 adb文档给出的思路是复用 adb 本身的客户端/服务端分离能力在远程机器上运行一个监听所有网卡的adb serveradb -a nodaemon server start本机 scrcpy 通过环境变量ADB_SERVER_SOCKET把adb 客户端指向远程的 adb serveradb 协议要求两端版本兼容scrcpy 再借助adb forward/adb reverse在设备与本机或远程机之间建立视频/音频/控制数据通道。因此涉及两个独立的「通道」adb 控制通道本机 → 远程 5037 端口和媒体数据隧道经 adb 转发到设备。下面按文档的两条路线分别展开。方案一远程 ADB server明文直连1. 在远程机器上启动 adb serveradb kill-server adb -a nodaemon server start # keep this open-a让 server 监听所有网卡而非仅 localhostnodaemon使其以前台进程方式运行以便观察日志。文档在此明确警告客户端与 adb server 之间的所有通信均不加密因此该方案仅适用于可信内网跨公网应使用下面的 SSH 隧道。2. 本机指定远程 adb server以远程 server 位于192.168.1.2为例在另一个终端设置ADB_SERVER_SOCKET后运行 scrcpy三种 shell 写法# in bash export ADB_SERVER_SOCKETtcp:192.168.1.2:5037 scrcpy --tunnel-host192.168.1.2:: in cmd set ADB_SERVER_SOCKETtcp:192.168.1.2:5037 scrcpy --tunnel-host192.168.1.2# in PowerShell $env:ADB_SERVER_SOCKET tcp:192.168.1.2:5037 scrcpy --tunnel-host192.168.1.23. 强制指定隧道端口可选默认情况下 scrcpy 使用建立adb forward隧道时分配到的本地端口通常是27183见--port。当链路中涉及更多重定向例如中间再套一层 SSH 转发时可以强制一个固定端口scrcpy --tunnel-port12344. 源码印证--tunnel-host/--tunnel-port为什么自动开启--force-adb-forward参数在 app/src/cli.c 中的注册帮助文本就写明这两个选项会自动启用--force-adb-forward默认值分别为localhost和0即「不强制」。实际的自动开启逻辑在 app/src/cli.c#L3068-L3072if ((opts-tunnel_host || opts-tunnel_port) !opts-force_adb_forward) { LOGI(Tunnel host/port is set, --force-adb-forward automatically enabled.); opts-force_adb_forward true; }背后的原因在 app/src/adb/adb_tunnel.c 中一目了然。scrcpy 优先尝试adb reverse设备侧作为发起方回连本机监听端口enable_tunnel_reverse_any_port()先在--port指定的端口区间默认27183:27199由 app/meson.build#L167-L168 配置内逐端口尝试调用sc_adb_reverse建立反向映射同时在本地listen对应端口源码注释解释了方向选择的巧妙之处——「应用层上设备是服务端但网络层上客户端监听、服务端连接」这样客户端可以先监听好再启动 server 应用无需轮询等待若端口被占用则移除该映射、端口 1 重试超出区间才报错。而adb reverse在远程场景下行不通它意味着设备主动回连「配置它的那台计算机」也就是远程机器而非跑 scrcpy 的本机。所以在 sc_adb_tunnel_open() 中当force_adb_forward为真时直接走enable_tunnel_forward_any_port()即用adb forward让本机主动发起连接。这也是文档中--tunnel-host192.168.1.2的语义——数据隧道的对端不是 localhost而是远程机器的 IP。连接阶段的细节可参考 app/src/server.c#L629-L645forward 模式下tunnel_host为 0 时回落到IPV4_LOCALHOSTtunnel_port为 0 时使用tunnel-local_port即adb forward实际占用的端口随后最多 100 次、每次间隔 100ms 的重连循环中connect_and_read_byte()还会额外读取 1 字节来确认隧道后端的 server 真正在监听——因为「连接成功」与「对端已就绪」是两回事。方案二SSH 隧道加密推荐跨公网使用与远程 adb server 直接通信是不加密的文档给出的安全做法是远程机器只跑普通adb start-server用 SSH 的端口转发同时打通「控制通道」和「媒体隧道」两条路。1. 准备与建链# 远程机器上确认 adb server 在运行 adb start-server# local 5038 -- remote 5037 # local 27183 -- remote 27183 ssh -CN -L5038:localhost:5037 -R27183:localhost:27183 your_remote_computer # keep this open两条转发的含义-L5038:localhost:5037本机 5038 端口 → 远程机器的 5037adb server供 adb 客户端通信-R27183:localhost:27183反向转发——远程机器的 27183 回连到本机的 27183。这正是为adb reverse准备的设备回连的目标端口落在远程机器上经由 SSH 转回本机 scrcpy 的监听端口。-C开启压缩、-N不执行远程命令纯转发。2. 本机运行 scrcpy# in bash export ADB_SERVER_SOCKETtcp:localhost:5038 scrcpy:: in cmd set ADB_SERVER_SOCKETtcp:localhost:5038 scrcpy# in PowerShell $env:ADB_SERVER_SOCKET tcp:localhost:5038 scrcpy注意这里不需要--tunnel-host/--force-adb-forward媒体隧道的入口就在本机通过-R反向转发可达adb reverse是首选路径。3. 变体只用本地转发强制adb forward若不希望开启 SSH 的远程端口转发-R可能被安全策略限制文档提供了纯-L的替代方案# local 5038 -- remote 5037 # local 27183 -- remote 27183 ssh -CN -L5038:localhost:5037 -L27183:localhost:27183 your_remote_computer # keep this open此时远程机器的 27183 可经由 SSH 到达scrcpy 则改用adb forward让连接从本机主动出发穿过隧道到达远程机器上的 27183 再进入设备。因此命令需要显式加上--force-adb-forward否则 scrcpy 会先尝试adb reverse并白白消耗重试时间# in bash export ADB_SERVER_SOCKETtcp:localhost:5038 scrcpy --force-adb-forward:: in cmd set ADB_SERVER_SOCKETtcp:localhost:5038 scrcpy --force-adb-forward# in PowerShell $env:ADB_SERVER_SOCKET tcp:localhost:5038 scrcpy --force-adb-forward--force-adb-forward的官方释义见 app/src/cli.c#L430-L434「不尝试使用adb reverse连接设备」。从源码看adb reverse失败时本来就会回退到adb forwardadb_tunnel.c#L137-L141 中的adb reverse failed, fallback to adb forward警告日志所以显式强制只是跳过注定失败的第一阶段——这一点在旧版 Android 或adb connectTCP/IP 接入的设备上尤其典型adb_tunnel.h 的注释也说明了这一回退的适用场景。关键参数速查参数 / 环境变量作用默认值 / 说明ADB_SERVER_SOCKETadb 环境变量指定 adb 客户端连接的 adb server 地址例tcp:192.168.1.2:5037远程 server或tcp:localhost:5038SSH 转发后--tunnel-hostip媒体隧道对端 IPadb forward的出站目标默认localhost设置后自动启用--force-adb-forwardapp/src/cli.c#L3068-L3072--tunnel-portport强制媒体隧道端口默认0不强制使用adb forward实际占用的本地端口设置后同样自动启用--force-adb-forward--force-adb-forward跳过adb reverse直接使用adb forward默认关闭适用于反向转发不可用的网络拓扑--port端口区间adb forward/reverse尝试使用的本地端口范围默认27183:27199app/meson.build#L167-L168逐端口重试直至成功排障要点「连接成功但 scrcpy 卡住/重连」connect_and_read_byte() 的存在说明连接建立不等于 server 就绪远程 server 启动慢、或adb版本在两端不一致时优先检查ADB_SERVER_SOCKET指向与 adb 版本兼容性文档强调两端必须使用相同版本的 adb 协议。adb reverse失败回退日志终端若出现adb reverse failed, fallback to adb forward属于预期的回退行为在远程拓扑下可提前用--force-adb-forward避免。端口冲突隧道端口在 27183 起的区间内逐个尝试日志会打印Could not listen on port N, retrying on N1固定端口场景--tunnel-port需自行确认端口未被占用。明文警告方案一中「客户端 ↔ adb server」全程无加密公网环境请改用 SSH 隧道方案。小结远程投屏的本质是把adb 客户端/服务端解耦ADB_SERVER_SOCKET负责把控制面指向远程 adb serveradb forward/adb reverse负责把媒体面穿过网络可信内网用「远程 adb server --tunnel-host」最省事跨公网用 SSH 的-L/-R组合更安全是否出现--force-adb-forward取决于媒体隧道的发起方向adb reverse设备回连需要-R反向转发优先adb forward本机主动连接-L即可作为强制选项或自动回退。【免费下载链接】scrcpyDisplay and control your Android device项目地址: https://gitcode.com/GitHub_Trending/sc/scrcpy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考