简介面向AutoJsPro与Autox用户的自建服务器配套材料聚焦Node.js环境搭建、ProxyPin代理配置、Python脚本辅助等关键环节解决官方服务不稳定或需远程控制、批量调度时的服务器自建问题适合有一定脚本基础、想进阶的初中级自动化用户。资源共9个文件压缩包约344.42MB包含4个APK安装包如AutoJsPro 9.3.11正式版、代理工具APK、txt文本教程与mp4视频教程各1份另有json配置、exe辅助服务端及hosts文件覆盖从服务器程序到客户端连接所需的完整文件链。已有13612人学习/下载。教程以视频文本双形式逐步演示安装Node.js、配置ProxyPin、运行Python辅助脚本和连接设备各文件用途都有说明可帮初学者避开环境路径、端口映射等常见坑较快跑通自建服务器并解锁AutoJsPro远程控制、多设备协同等高级自动化能力。1. AutoJsPro 自建服务器把脚本调度权从云端收回到自己手里AutoJsPro 是我用了好几年的安卓端自动化脚本工具脚本跑在设备本地效率一直没问题真正麻烦的是设备多了以后的管理几十台手机要传脚本、要盯执行状态、要按设备维度翻日志这些靠单机版根本玩不转。官方控制台模式能解决集中管理但按设备数收费脚本和运行日志都要经官方服务器中转想自己定制任务审核流程也没有空间。自建服务器的思路就是把官方那套“控制台通道”换成自己部署的服务端设备注册、心跳维持、脚本下发、定时调度、日志回传全部走自己的 Linux 服务器和数据库。这篇笔记从架构、部署、客户端接入写到避坑和进阶适合手上有多个安卓设备、愿意自己维护一个中小型服务端的开发者或小团队。2. 先看整体架构控制台模式下的设备、服务器、数据库三者怎么分工自建服务器不是把 AutoJsPro 的原生引擎重写一遍而是把原本由官方云端提供的“控制台通道”替换成自己部署的服务端。要理解自建该做什么先得明白控制台模式下设备和服务器之间是怎么配合的。这套配合逻辑不弄清后面部署完连不上设备你都不知道该查哪一层。2.1 控制台模式不是截图投屏而是“指令下发 结果回传”很多第一次接触 AutoJsPro 控制台模式的人容易误解以为控制台像远程桌面一样能在电脑上看到手机画面、直接操作手机。控制台模式的真实机制不是这样。它用一个轻量级长连接把设备和服务端串起来设备端在 AutoJsPro 里配置好服务器地址后启动时向服务端注册拿到会话凭证之后按固定周期发心跳维持在线状态。服务端这边下发“去执行脚本 A”的指令设备收到指令后从服务端拉取脚本内容在本地运行引擎执行再把执行过程中的日志和最终结果回传。这套机制对不熟悉的人像个黑匣子但理解它非常关键脚本是在设备本地执行的服务端不运行 Android 模拟环境所以设备上的屏幕、无障碍服务、界面元素探测这些能力都不受影响。服务端只负责调度和存取。由此可以推出自建服务器的核心工作量——实现一个能听懂 AutoJsPro 客户端通信协议的服务端至少提供设备注册、心跳、任务分发、日志回传这几个基本接口。2.2 服务端三大件Java 服务、MySQL、Redis 各自承担什么服务端选型上官方私有化部署方向一般基于 Java 技术栈部署包就是一个可运行的 Java Web 服务配套 MySQL 和 Redis这三个组件分工非常清楚组件负责的事情选型理由Java 服务端程序设备注册、心跳、脚本存取、任务调度、控制台 Web 界面与官方客户端协议同技术栈部署包可直接运行MySQL持久化数据设备表、脚本表、任务表、日志表结构化数据按设备、脚本、任务维度查询统计方便Redis设备在线状态、心跳时间、短期缓存读写快适合做在线判断和热点缓存部署顺序是先把 MySQL 和 Redis 装好再启动 Java 服务端因为服务端启动时要初始化数据库连接池和 Redis 连接。库里如果没有任何表控制台打开就是一片空白。MySQL 里核心有三张表。设备表记录每台设备的唯一标识、别名、分组、最近心跳时间、在线状态脚本表存脚本名、内容、版本号和最后更新时间任务表存哪台设备在什么时间执行了哪个脚本、上次执行结果是什么。日志表单独放脚本跑多了日志量增长快跟业务表分开好管理。Redis 存的是设备在线状态和心跳时间key 可以设计成device:online:设备idvalue 存心跳时间戳配合 Redis 自带的过期机制比如 90 秒没有新心跳就让 key 自动过期服务端判断设备离线就不需要频繁扫描 MySQL 表。这是控制台在设备多的时候依然流畅的关键。2.3 网络拓扑与安全边界设备在你的内网服务器就该在你的内网常见部署方式是把服务端放在局域网里的一台 Linux 机器上安卓设备连同一个 Wi-Fi通信延迟低脚本下发和日志回传都快。如果设备分散在多个地理位置就得把服务端放到有公网 IP 的云主机上再在服务端做访问控制只允许你登记的 IP 段访问管理端口。这类跨地域场景我一般建议认真评估自建是否必要因为网络抖动带来的掉线和重连排查会耗掉你大量工作日。安全边界上控制台管理界面和业务接口要分开管理界面用单独端口或路径前面套访问控制设备通信用的端口不要对办公网全量开放。服务端配置文件里要设一个通信密钥AutoJsPro 客户端填入的密钥必须和服务端一致否则握手时直接拒绝注册。这个密钥等同于整个设备接入体系的钥匙我后面会专门说怎么生成和保管。3. 从零部署自建服务器Linux 环境下的完整搭建流程假设你手头有一台能访问的 Linux 服务器Ubuntu 20.04 或 CentOS 7 都行内存不低于 2G。下面按 Ubuntu 20.04 为例把每一步写清楚命令可以直接复制。3.1 准备服务器规格建议与基础环境安装先给一个规格参考别一上来就买高配自建服务器的瓶颈通常不在 CPU而在数据库连接和内存。设备规模CPU内存磁盘10 台以内1 核2G40G10-50 台2 核4G80G50 台以上4 核8G160G内存受两个因素制约数据库连接池和 Java 堆内存。设备越多心跳越频繁连接数和线程数都往上涨。磁盘主要花在日志表和脚本版本的累积上我遇到过跑半年日志表占了 20G 的情况所以磁盘稍微给大点定时清理策略后面说。安装基础环境三个命令分别装 JDK 8、MySQL 和 Redis# 更新 apt 索引并安装 OpenJDK 8 sudo apt update sudo apt install openjdk-8-jdk -y java -version # 安装 MySQL 服务端 sudo apt install mysql-server -y # 安装 Redis sudo apt install redis-server -y sudo systemctl enable redis-server三个包安装顺序没有硬性要求但装完要分别确认服务状态。JDK 版本这里特别说一下AutoJsPro 服务端是按 Java 8 构建的用 JDK 11 或 17 启动可能在反射和类加载上报错不是不能跑而是要额外处理兼容参数。我默认就用 8省心。安装完成后确认 MySQL 和 Redis 都在运行sudo systemctl status mysql sudo systemctl status redis-server看到active (running)就说明基础环境就绪了。MySQL 默认只监听 127.0.0.1Redis 也默认监听 127.0.0.1服务端程序如果和它们在同一台机器不需要改监听地址如果你打算把数据库单独放一台机器才需要去改 bind 配置和防火墙否则保持默认反而更安全。3.2 初始化数据库建库建表与账号授权MySQL 装好后登录 root 创建业务库和专用账号。绝不要用 root 账号让服务端连数据库权限最小化是基本素养。-- 登录 MySQL mysql -u root -p -- 创建业务数据库字符集必须用 utf8mb4 CREATE DATABASE autojs DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; -- 创建专用账号并授权密码改成你自己的强密码 CREATE USER autojs_user127.0.0.1 IDENTIFIED BY 这里写强密码; GRANT ALL PRIVILEGES ON autojs.* TO autojs_user127.0.0.1; FLUSH PRIVILEGES;建库时字符集用 utf8mb4 而不是 utf8因为 MySQL 的 utf8 最多存 3 字节脚本路径或设备备注里一旦出现 emoji 字符就会报Incorrect string value整个插入失败。utf8mb4 完整支持 4 字节 Unicode代价只是多占一点磁盘自建场景完全值得。建完库后把官方部署包里自带的初始化 SQL 脚本导入。这个脚本一般在部署包根目录下文件名通常是schema.sql或init.sql它会建好设备表、脚本表、任务表和日志表。导入命令# 导入初始化脚本路径换成你实际部署包里的文件名 mysql -u autojs_user -p autojs /opt/autojs-server/schema.sql如果部署包没有现成的初始化脚本手工建表时可以参考这个简化结构USE autojs; CREATE TABLE device ( id BIGINT PRIMARY KEY AUTO_INCREMENT, device_id VARCHAR(64) NOT NULL UNIQUE, name VARCHAR(64), group_id INT DEFAULT 0, last_heartbeat DATETIME, status TINYINT DEFAULT 0, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_group (group_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE task ( id BIGINT PRIMARY KEY AUTO_INCREMENT, device_id VARCHAR(64) NOT NULL, script_id BIGINT NOT NULL, cron VARCHAR(32), status TINYINT DEFAULT 0, last_run_time DATETIME, last_result TEXT, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_device (device_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;ENGINEInnoDB和CHARSETutf8mb4这两项不要省。InnoDB 支持行锁和事务日志表写并发高的时候不会锁整表utf8mb4 的理由前面已经说过。导入完成后用SHOW TABLES;确认核心表都在数据库这块就算准备好了。3.3 修改服务端配置端口、数据库、Redis 与通信密钥数据库初始化完成接下来配置 Java 服务端。它一般是个可执行的 jar 包旁边带一个application.properties配置文件。核心配置项如下# Web 服务端口 server.port8080 # MySQL 连接配置 spring.datasource.urljdbc:mysql://127.0.0.1:3306/autojs?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai spring.datasource.usernameautojs_user spring.datasource.password你的强密码 # Redis 配置 spring.redis.host127.0.0.1 spring.redis.port6379 spring.redis.password # 设备通信密钥 autojs.server.secret改成随机生成的密钥spring.datasource.url里的characterEncodingutf8和serverTimezoneAsia/Shanghai两个参数都别删。前者保证脚本中文不乱码后者保证数据库时间字段和你本地时区一致不然控制台显示的任务执行时间会和实际差 8 小时。autojs.server.secret就是设备接入凭证。这个值千万别用默认值建议用命令行生成一个随机串# 生成 32 位随机密钥 openssl rand -hex 32把输出的随机串填到配置里。这个密钥一旦泄露拿到的人就能往你的控制台里注册设备、收到下发的脚本内容所以保管级别和数据库密码一样。3.4 启动服务与健康检查验证自建服务器可用配置改好后启动服务端。用 nohup 放后台跑日志重定向到文件里方便排错cd /opt/autojs-server # 启动服务端jar 包名换成你实际的包名 nohup java -jar autojs-server.jar \ --spring.config.location./application.properties \ server.log 21 echo $!命令输出了 PID说明进程已经拉起来。Spring Boot 启动需要 10 到 20 秒检查启动日志有没有报错# 查看启动日志尾部 tail -50 server.log # 确认进程在跑 ps aux | grep autojs-server然后看端口监听状态服务端正常启动后 8080 端口应该处于 LISTEN 状态ss -lntp | grep 8080最后访问一次健康检查接口。不同部署包路径不一样常见的是/health或/api/healthcurl http://127.0.0.1:8080/health返回类似{status:UP}的内容说明服务端已经可用。到这里自建服务器的服务端部分就跑起来了下一章把安卓设备接进来。4. 把设备接进来AutoJsPro 客户端配置与脚本下发实操服务端起来以后接下来的每一步都是和设备交互也是平时使用频率最高的操作。我会从客户端配置开始一路讲到定时任务每一步都给出可复现的路径。4.1 客户端设置填入服务器地址与通信密钥打开手机上的 AutoJsPro进入设置找到“控制台”或“服务器”相关配置项。这里要填两个东西服务器地址和通信密钥。地址格式取决于服务端是否套了 HTTPS。服务端是内网 IP 加 8080 端口就填http://192.168.1.100:8080如果按第 6 章的方法用 Nginx 套了 HTTPS就填https://your.domain.com。密钥填 3.3 节配置的autojs.server.secret值。提示地址里的协议头不能漏。AutoJsPro 判断是否走加密通道看的就是http://或https://这个前缀。填错了会直接导致 TCP 握手成功但协议解析失败页面一直转圈。保存配置后App 会尝试连接服务端并注册设备。如果没有意外控制台设备列表会出现这台设备状态显示在线。如果看不到别急第 5 章第一个坑就是专门讲这个的。4.2 添加设备与分组用别名管理多台设备设备注册成功后控制台里显示的是一串长标识没法一眼认出是哪台手机。我一般先改别名比如“扫码机 01”“客服机 03”再按业务场景分组。分组的作用不只是看着整齐脚本下发时可以按组操作。比如“质检组”有三台设备在控制台选择脚本后勾选整个组服务端会给组内所有在线设备同时下发。批量执行场景里非常常用比如每天早上所有设备统一运行签到脚本勾选“全部设备”一键执行就行。设备离线时控制台会标记为灰色超过设定时间没有心跳服务端会把它标记为离线。这个超时时间在配置文件里可以调默认一般是 90 秒。设备频繁休眠的话90 秒不够需要调大我第 5 章细说。4.3 上传脚本并指定设备执行控制台左侧一般有“脚本管理”入口。新建脚本有两种方式直接在控制台在线编辑或者把本地写好的.js文件上传。不管哪种方式保存后服务端都会把脚本内容存到 MySQL 的脚本表里。指定设备执行的操作很直观在设备列表勾选设备选择一个已上传的脚本点击执行。服务端接到动作后向目标在线设备发送一条执行指令设备端收到后从服务端拉取脚本内容在本地跑起来。整个交互是异步的服务端只管下发和执行状态流转不会同步等待脚本跑完。这个时候可以在设备端屏幕上看到脚本在运行控制台这边设备状态变成“运行中”。脚本跑完控制台收到结束事件和返回值。如果你在脚本里用了console.log输出这些日志也会实时回传到控制台的日志面板排查问题基本靠这个。4.4 配置定时任务cron 表达式的坑定时任务是控制台最高频的功能。比如每天早上 9 点让设备执行一次公告检查脚本就在任务模块里配置一个 cron 表达式# 每天早上 9 点执行 0 0 9 * * ?配置完后服务端按调度周期检查哪些设备需要执行任务。这里有一个非常容易误解的地方cron 表达式在服务端解析但真正执行脚本的是设备。如果服务器和设备之间存在时区差或者唤醒延迟实际执行时间就会偏移。我在第 5 章的第三个坑里详细讲这个问题这里只提醒一点部署服务端时就把时区设成Asia/Shanghai设备端也开启自动校准时间。另外注意定时任务触发那一刻设备如果离线任务会被标记为“未执行”不会自动补跑。如果需要补跑机制要么在脚本里实现“判断上次成功时间、失败则重试”的逻辑要么在控制台配重试策略。我习惯在脚本里多做一层幂等校验这样即使任务重复触发也不会产生重复副作用。5. 自建服务器避坑指南连接失败、中文乱码、任务不触发的五个典型问题自建服务器跑起来只是入场券真正考验人的是各种“玄学”问题。我把这几年维护过程中遇到的翻车现场按频率排序写在这里每条都是现象、原因、解决三步走希望能帮你省掉排查时间。5.1 设备一直显示“连接中”注册不上服务器现象AutoJsPro 客户端填了服务器地址和密钥页面一直转圈显示“连接中”控制台设备列表里始终看不到新设备。原因八成是网络层问题不是协议问题。最常见的有三种第一手机和服务器不在同一个局域网或者服务器防火墙拦了端口第二地址里漏了http://前缀客户端把地址当成了非法值第三通信密钥不一致服务端校验握手时直接拒绝。解决先在手机浏览器里直接访问服务器地址能打开健康检查页面说明网络通。再用客户端重新填写地址和密钥注意协议头不要漏密钥不要带空格。我一般用一台干净设备做最小化验证地址、密钥逐字核对错一个字符都不行。如果浏览器都打不开就回服务器上看防火墙和端口监听别在客户端死磕。5.2 脚本里的中文在设备端变成乱码现象控制台里上传的脚本在设备端执行后输出日志时中文字符全变成锟斤拷或???。原因一是脚本源文件本身不是 UTF-8 编码常见于 Windows 下用记事本或某些编辑器保存成了 GBK二是 MySQL 连接串漏了characterEncodingutf8脚本内容从数据库读出来再转给客户端时编码就错了。解决脚本源文件统一用 UTF-8 无 BOM 保存上传之前先确认编辑器右下角编码格式。已经乱码的历史数据我一般是把脚本内容拷出来用 Linux 的iconv命令转码再重新上传# 把 GBK 编码的脚本转成 UTF-8 iconv -f GBK -t UTF-8 origin.js fixed.js转码后务必打开文件确认没有乱码再上传。同时检查application.properties里 MySQL 连接 URL 是否带了characterEncodingutf8缺了就补上并重启服务端。这个坑排查起来不复杂但一旦等脚本跑起来才发现日志已经全乱了。5.3 定时任务总是慢几分钟才执行现象cron 配的是0 0 9 * * ?设备却 9 点过两三分钟才开始跑任务偶尔还有任务完全没触发的情况。原因两类原因叠加。第一是服务器和设备时间不同步设备开机后走网络校准服务器走硬件时钟两边差一两分钟cron 触发自然错位第二是 AutoJsPro 在设备后台被系统限制了国产 ROM 的后台管理策略比较激进App 在后台被挂起服务端指令根本送不进来。解决服务器端配置时间同步设备端开启自动校准时间两边都对齐。AutoJsPro 的“自启动管理”和“后台运行白名单”必须在系统设置里打开这一步在国产 ROM 上真的能让你怀疑人生。我们曾在一个模拟项目里为适配某款系统的后台策略花掉一半排查时间最后发现就是白名单没加。定时任务相关的设备我建议直接用一台专门跑任务的旧手机关掉多余 App后台纯净很多。5.4 设备超过 30 台以后控制台操作明显变卡现象设备从十几台加到三四十台后控制台设备列表加载变慢批量下发脚本时页面卡顿偶尔超时。原因设备在线状态每次刷新都去查 MySQL心跳频率一高数据库连接池被占满控制台页面的查询请求排队等连接。默认连接池只有 10 个连接小规模够用设备一多就不够分了。解决第一步调大数据库连接池Spring Boot 默认的 HikariPool 可以在配置里显式调大spring.datasource.hikari.maximum-pool-size50 spring.datasource.hikari.minimum-idle10第二步把设备在线状态的读取从 MySQL 挪到 Redis心跳更新走 Redis控制台展示也只读 RedisMySQL 的压力会小很多。这是我在一个模拟项目里验证过比较有效的优化手段设备量翻倍时控制台响应时间基本没有明显变化不夸张值得一试。5.5 客户端一次版本升级后全部设备掉线现象某次批量更新 AutoJsPro 客户端版本后所有设备在控制台全部显示离线但设备本地网络正常其他 App 都能联网。原因新版本客户端和服务端之间的通信协议变了自建的旧服务端不认识新版握手包直接丢弃连接。这是自建服务器模式特有的风险——官方服务端和客户端是配套升级的自建服务器如果跟不上客户端升级节奏就会集体掉线。解决升级客户端之前先确认自建服务端版本是否兼容新版协议。无法确认的情况下我的做法是把客户端的自动更新关掉固定使用已验证过的旧版本等服务端更新包出了再一起升级不要单独追新。自建服务器维护工作里“版本冻结”是个很实用的技巧不追新求稳。6. 进阶HTTPS 反代、执行结果推送与脚本灰度发布自建服务器跑稳以后可以再往上加几层体验优化。这三件事做下来日常维护的舒适度会有明显提升也能在团队协作里减少互相打扰。6.1 用 Nginx 给自建服务器加 HTTPS虽然是内网部署HTTP 也能跑但只要跨网段访问或者你不想让通信密钥在网络里裸奔HTTPS 就值得配。用 Nginx 做反向代理是最省事的方式server { listen 443 ssl; server_name your.domain.com; ssl_certificate /etc/nginx/ssl/fullchain.pem; ssl_certificate_key /etc/nginx/ssl/privkey.pem; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }证书可以用内网自建的 CA 签发但 AutoJsPro 客户端需要提前信任根证书有公网域名就直接申请免费证书客户端不用额外配置。配好以后把客户端里服务器地址改成https://前缀重新注册设备。这个改造不影响已有任务设备重连一次就切过去了。6.2 把执行结果推送到内部群机器人脚本跑完以后一直盯着控制台看结果效率太低我习惯让脚本在执行结束后往内部群机器人推送一条摘要。AutoJsPro 脚本里用自带的http模块就能完成不需要引额外依赖// 脚本执行完成后推送结果到群机器人 function postResult(message) { const webhook https://你的群机器人webhook地址; const body { msgtype: text, text: { content: message } }; http.post(webhook, JSON.stringify(body), { headers: { Content-Type: application/json } }); } // 示例脚本正常结束 postResult(扫码机01 已完成早间签到脚本耗时 32 秒);群机器人 webhook 本身就包含鉴权信息泄露的后果只是群内消息被伪造风险可控但还是建议用单独的 key不要把管理端权限暴露出去。推送频率也别太高一个脚本只推一条摘要不然群消息会被刷屏。6.3 从代码仓库同步脚本实现灰度发布脚本放在控制台在线编辑多人协作时很容易互相覆盖。后来我把脚本源文件全部放到代码仓库托管控制台只做分发。版本变更流程是在仓库里改脚本通过 Webhook 触发服务端拉取拉取后先只推给一台设备验证确认没问题再推给全组。这个灰度链路做起来不复杂但能让回归问题的影响面从全部设备缩小到一台设备非常值得。总结这些年维护自建服务器的经验真正决定这套系统能不能长期跑下去的不是部署那一瞬间的顺利而是你愿不愿意把版本管理、结果通知和发布策略这三件事制度化。我的习惯是每台服务器上留一份部署日期和版本记录每个月对比一次配置差异确认没有漂移。希望这些经验能帮到你祝你的自建服务器一次跑通少踩几个我踩过的坑。本文还有配套的精品资源点击获取