AutoJsPro自建服务器：多设备自动化协同与集中调度实践指南

简介：AutoJsPro自建服务器完整资料，面向需要为AutoJsPro或AutoX配置专属远程服务器的安卓自动化用户，解决脚本远程控制与任务调度时过度依赖公共服务器的问题。资源包共含九个文件，内有四个安卓安装包、一份视频教程、一份文本教程、一个配置文件、一个桌面辅助工具及一个主机映射文件，压缩后总大小约三百四十四兆字节。目前已有超过一万三千人浏览学习，许多自动化爱好者借此入门自建服务端。教程采用视频与文本双线讲解，重点示范基于Node.js与Python两种方案完成服务器搭建，并引入代理配置与主机映射来打通远程通信，使客户端与服务器之间更加稳定。附带安装包与服务端工具可直接使用，显著降低环境配置复杂度。适合对数据安全或定制功能有要求的AutoJsPro用户，按教程操作即可实现从安装到联调的全流程，从而增强自动化脚本的灵活性与可维护性。

1. AutoJsPro自建服务器：为什么脚本控最该先搭这一层

AutoJsPro跑在安卓设备上做自动化确实方便，但一个人维护十几台设备的脚本同步、任务下发、日志回传，很快就会变成体力活。AutoJsPro自建服务器的思路，就是把脚本存储、设备授权、任务调度从本地搬到你自己控制的服务器上，让每台设备开机后自动连上来，按既定计划跑。这个方案解决的不只是“不用反复插数据线”的问题，更是把自动化从“单个设备上的临时脚本”变成“一组设备协同的可靠生产体系”。适合手里有三台以上设备、或者脚本已经跑进业务流程的开发者。

2. 搭建前先选型：PC模式还是Web模式，服务器怎么配

自建服务器的第一步不是装软件，而是想清楚这套东西跑在什么网络环境里。AutoJsPro的设备端和服务端之间走的是长连接，服务端把脚本、任务推给设备，设备把截图、日志、执行结果推回服务端。整个链路里最影响使用体验的不是脚本本身，而是网络是否顺畅、服务端是否一直在线。

常见做法有两种。第一种是PC模式：服务端装在自己日常用的电脑上，设备连同一个路由器下的Wi-Fi，适合在家维护三五台设备。第二种是Web模式：服务端装在有公网IP的云主机上，设备不管在家还是在外，都能连回来，适合设备分散、无人值守的场景。选型之前把这两条路的利弊看清楚，后面能少走很多弯路。

2.1 两种连接架构的差别：局域网直连和公网访问各适合谁

PC模式的好处是零额外成本，电脑上跑一个服务端进程就行。局限也明显：电脑休眠、断电、换Wi-Fi，设备就全断了。所以我一般建议，如果脚本是给自己做点日常提醒、跑个签到任务，PC模式够用；如果脚本涉及业务流程、数据回传，或者设备分布在多个地点，直接上Web模式。

Web模式多出来的成本就是一台低配云主机。AutoJsPro服务端本身很轻，CPU、内存需求都不高，真正吃资源的是设备多时的并发连接和日志存储。这里有一个很多新手会踩的坑：以为设备少就随便买最低配，结果设备数量一加，日志涨起来，服务端开始频繁卡顿。

两种模式还有一个本质差别：PC模式下服务端和设备端的网络延迟极低，截图回传、实时调试都很跟手；Web模式下如果设备走4G/5G网络，单次截图回传可能慢几百毫秒。所以做界面自动化调试的时候，我习惯先在局域网模式下调通，再切到公网模式跑生产任务。

2.2 服务器配置怎么估：设备数、脚本体积与带宽的真实关系

先给一个可以参考的估算表，单位是“同时在线设备数”。

这个表基于常见做法的经验值：每台设备每小时的日志和截图回传量在2-5MB左右，脚本体积一般几KB到几百KB，但如果你的脚本里大量使用截图对比、OCR识别，回传图片会显著放大带宽需求。图片类回传比文本类回传消耗大一个量级，规划时按脚本内容折算。

估算逻辑其实很简单：带宽看的是“最大并发回传”，不是平均值。三十台设备同时在整点开始跑任务，回传截图时峰值是平均值的四五倍。内存看的是连接数，每一条长连接在服务端大概占用10-30MB内存，包括缓冲区。磁盘看的是日志保留周期，如果保留30天，可以按“设备数乘每日回传量再乘30”粗算。

这里多说一句：公网IP是Web模式的刚需，没有公网IP就老老实实用PC模式，别给自己找麻烦。端口放行和安全组规则也是这个模式下最容易出问题的地方，后面避坑章节会专门讲。

2.3 自建服务器的三个关键概念：长连接、Token认证与设备证书

进入实操前，先理清三个概念，后面配参数时不会晕。

第一条是长连接。设备端启动后不是发起一次请求、拿到响应就断开，而是和服务端保持一条常驻通道，服务端可以随时往通道里推任务，设备也可以随时往回推结果。这决定了自建服务器必须保持在线，电脑休眠这类问题会让所有设备瞬间失联。

第二条是Token认证。设备连上服务端时，需要提交一个连接密钥，也就是Token。服务端用这个Token识别“这是不是被允许接入的设备”。Token相当于门禁卡，泄露了就等于任何人都能往你的设备下发脚本。常见做法是启动服务端时通过参数指定Token，设备端填同一个值才能握手成功。

第三条是设备证书。在AutoJsPro的设备端首次连接自建服务器时，通常会要求导入一个证书文件，用来加密设备与服务端的通信内容。证书过期、服务端时间不准，都会导致连接被拒绝，这也是后面避坑章节里最常见的两个原因。

这三条讲清楚后，再去看安装包里的目录结构就省力多了。一般自建服务器安装包里主要包含一个可执行Jar包或启动脚本、一个存放设备证书的目录、一个存放运行日志的目录，以及一个配置文件。目录名称不同版本可能不一样，但功能分布基本一致。

2.4 目录规划与备份习惯：拿到安装包先做三件事

拿到服务端安装包后，我建议先不要急着启动，先做三件事。第一是确认Java版本，第二是规划目录，第三是确认安装包里的配置项名称。目录规划上，我习惯把日志和证书分开，这样排查问题的时候不用到处翻。

# 创建一个干净的服务端目录，存放程序、证书、日志和备份 mkdir -p /opt/autoserver/{bin,logs,certs,backup}

bin放服务端程序，logs放运行日志，certs放证书文件，backup放每日备份。这个结构看着简单，但到排查问题的时候优势就出来了：日志在固定位置，证书在固定位置，不会出现“文件不知道放哪了”的情况。

备份习惯上，我每天把配置文件和certs目录打包一次，保留最近7天。服务端本身不复杂，配置丢失、证书丢失才是真正让人头疼的事，备份就是后悔药。后面讲避坑时你会发现，很多连接问题最后都归结到证书不一致，有备份就能快速恢复。

3. 从零跑通AutoJsPro服务端：安装、启动与设备接入

上一章定完选型，这一章直接把服务端跑起来。我会按Linux环境来写命令，因为多数人最终会把服务端放在云主机上；如果你本机就是Mac或Windows，思路完全一样，只是启动方式从命令变成双击脚本或终端执行。

3.1 部署前准备：Java环境检查与防火墙策略

AutoJsPro自建服务器的核心程序是在Java环境下运行的，所以第一件事是确认Java版本。常见做法是要求JDK 8以上，过高或过低都可能触发兼容问题。装好之后用两条命令确认：

# 查看当前Java版本 java -version # 确认Java可执行文件在系统路径中 which java

第一行打印版本号，第二行打印Java安装路径。如果第二行是空的，说明Java没有加到环境变量里，启动脚本会找不到命令。这个问题在Linux服务器上尤其常见，缺JAVA_HOME导致的启动失败比版本不对还频繁。

然后是防火墙策略。服务端默认监听一个端口，设备连接和管理界面都走这个端口。在云主机安全组和系统防火墙里都要放行这个端口，协议选TCP。常见翻车原因是只改了云控制台安全组，忘了系统防火墙，或者反过来，两边没对齐。

# 以CentOS为例，放行服务端端口，请把9300替换成实际端口 sudo firewall-cmd --permanent --add-port=9300/tcp sudo firewall-cmd --reload

命令里的9300是服务端默认监听端口。如果你改了端口，这里的数字要跟着改。Windows下的操作路径是控制面板的防火墙入站规则，原理一样。

3.2 启动服务端：最小命令与两个核心参数

拿到服务端安装包后，解压并启动。下面是常见启动方式。

# 解压到前面规划好的目录 unzip auto-server.zip -d /opt/autoserver cd /opt/autoserver # 前台启动，方便首次观察启动日志 java -jar auto-server.jar --server.port=9300

看到日志里出现类似“服务端口已开启”的提示后，说明这一步已经通了。这个Jar包示意名在实际安装包解压后可能不一样，参数名也可能有差异，正确做法是先不加参数启动一次，看启动日志里输出的默认端口和配置项，再按实际情况去配对。

提示：如果启动后进程一闪就退出，先看日志最后几行报错。Java项目启动失败九成是环境问题，不是代码问题。

接下来要做两件事：改Token和放后台运行。

# 使用自定义Token启动，并放入后台 nohup java -jar auto-server.jar \ --server.port=9300 \ --auth.token=你的设备连接密钥 \ > logs/server.log 2>&1 &

nohup让进程不受终端退出影响，&表示放后台，日志重定向到logs/server.log。端口、Token是自建服务器最重要的两个配置项。Token要选足够长的随机字符串，至少16位，不要用123456这类值；端口则要根据防火墙放行情况保持一致。

3.3 设备端连接配置：IP、端口、Token三要素

服务端起来之后，打开手机上的AutoJsPro，进入“连接服务器”设置。需要填三项：服务器IP、端口、Token。端口对应启动参数里的9300，Token对应--auth.token。

如果设备和服务器在同一局域网，IP填服务器的局域网地址，比如192.168.1.20。如果设备在外网，IP填服务器公网IP或已解析到该IP的域名。

// 设备端连接参数的三要素示意 const serverConfig = { host: "192.168.1.20", // 服务器地址，公网场景换成域名或公网IP port: 9300, // 必须与启动参数 --server.port 保持一致 token: "你的设备连接密钥", // 必须与启动参数 --auth.token 保持一致 useTLS: false // 局域网可关闭，公网建议开启证书加密 };

这段代码只是展示三个字段怎么对应，实际配置是在AutoJsPro的图形界面里填，不是写代码。填完保存并连接，如果一切正常，设备会从“未连接”变成“已连接”，同时服务端日志会打印出这台设备的标识。

如果服务端启用了证书加密，首次连接时设备端会提示导入证书。把服务端certs目录里对应设备的证书文件传到手机并导入即可。这一步容易被忽略，但公网模式下强烈建议开启，脚本内容、回传截图都不会明文暴露在网络里。

3.4 验证连通：从设备列表到脚本下发

连接成功后，打开服务端的管理界面，能看到当前在线设备列表。这里建议做一次最小验证：给设备下发一个只输出一行文本的测试脚本，确认服务端到设备端的推送链路是通的，再开始布置真实任务。

// 最小验证脚本：确认服务端能正常下发并拿到执行结果 console.log("hello from server");

在管理界面执行后，回到服务端看这台设备的执行日志，如果出现了这行输出，说明整条链路已经通了。这一步是整个自建服务器从“能连上”到“能干活”的分水岭，没验证之前先别急着多设备接入，否则出了问题你分不清是网络问题还是脚本问题。

4. 自建服务器避坑清单：连不上、掉线、执行超时的排查手册

下面是血泪经验集锦。做过自建服务器的人基本都会遇到下面几个问题，按“现象、原因、解决”整理了最常见的四条，每一条都能对应到真实场景。

4.1 现象一：局域网内能连，公网环境一直超时

现象是同一Wi-Fi下设备秒连，把Wi-Fi关掉用流量，连接一直转圈直到超时。

原因有两种。最常见的是服务器没有公网IP，设备在外网根本找不到服务器地址；第二种是云主机安全组或系统防火墙没放行端口。

解决方式：先确认服务器能否被公网访问，用本机网络测试端口是否开放；如果端口不通，去云控制台检查安全组入站规则，再检查系统防火墙。这里有先后顺序：先ping服务器IP，能通再测端口，不能通就查IP本身或网络配置。一台没有公网IP的服务器，无论怎么调设备端都连不上，这个要先排除。

注意：家庭宽带环境下，服务器在局域网里怎么配都行，但公网访问必须依赖公网IP。没有这个前提，Web模式无从谈起，直接转PC模式更实际。

4.2 现象二：设备频繁掉线，日志里全是重连记录

现象是设备连上后过几分钟掉线，又自动重连，循环往复。

原因一般是三个：一是Wi-Fi信号弱，或者路由器开启了AP隔离，导致设备与服务器之间的长连接被中断；二是服务端所在电脑休眠或网络休眠，Socket连接被系统回收；三是设备端的省电策略杀掉了AutoJsPro的后台进程。

解决方式：路由器关闭AP隔离，给设备和服务端分配固定IP；电脑设置成永不休眠，外接电源；设备端在电池优化里把AutoJsPro设为“不受限制”。这三步做完，掉线问题大概率能解决。如果还掉，就去看服务端日志里掉线瞬间有没有报错码，有报错码才能定位到具体原因。

4.3 现象三：脚本回传结果丢失，任务状态一直停在“执行中”

现象是脚本逻辑已跑完，但服务端任务状态不更新，日志里看不到设备回传。

原因在于设备端执行完脚本后，通过长连接把结果推回服务端。如果这个回传因为网络抖动、服务端缓冲区溢出或脚本异常导致回调未执行，服务端就永远等不到结果。

解决方式：在脚本结束位置显式调用结果回传接口，并且做超时兜底，定时上报状态而不是只在最后报一次。常见做法是把回传动作写成一个公共方法，所有脚本结尾统一调用；执行过程中每隔一段时间上报一次心跳，这样即使最后一步失败，服务端也知道脚本跑到了哪。

4.4 现象四：服务端重启后设备全部连接失败

现象是服务端重启完成，设备端一直停在“正在连接”，手动重连也不行。

原因一般是Token或证书不一致。如果服务端重启时重新生成了Token，而设备端填的还是旧Token，握手会直接失败。另外，服务端时间不准会导致证书有效期校验失败，表现也是连不上。

解决方式：重启前备份配置文件和证书目录，确保Token没有变化；同时检查服务器系统时间和设备时间，误差超过几分钟就把服务器时间同步一下。把这两条列进每次重启的操作清单里，能省很多事。这也是上一章强调备份习惯的原因，证书和Token是最容易踩的坑，有备份就能快速回滚。

5. 进阶用法：集中调度、分组管理和脚本灰度更新

服务端跑顺之后，下一个值得投入的方向是“集中调度”。把定时任务统一登记在服务端，由服务端按计划推送给设备执行，而不是让每台设备自己装一个定时器。这样改的好处是任务列表一眼可见、设备掉线了也知道哪个任务没跑、脚本更新一次就能推给所有设备。

具体手法上，有两个习惯值得培养。第一个是脚本更新前先小范围验证，先在单台设备上执行新脚本，确认无误后再推给全组，避免一次翻车拖垮全部设备。第二个是给回传日志加上设备和版本号，出现异常时能定位是哪台设备、跑的是哪个版本脚本。

我自己的习惯是把每天的日志归档到backup目录，保留30天以上，这样脚本行为异常时可以回溯对比。每个月固定做一次连接自检，检查所有设备的最近一次心跳时间，超过一天的设备主动人工确认状态。这个习惯帮我规避过很多次“设备静默离线但没人发现”的尴尬。

AutoJsPro自建服务器本身不算复杂，难点都在细节：Token别泄露、端口要放行、证书别过期、服务器别休眠。把这几条基本盘守住，这套体系就能长期顺畅地替你把重复劳动跑完。希望帮到你。

本文还有配套的精品资源，点击获取