企业官网建设流程全解析

简介：面向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，这三个组件分工非常清楚：

部署顺序是先把 MySQL 和 Redis 装好，再启动 Java 服务端，因为服务端启动时要初始化数据库连接池和 Redis 连接。库里如果没有任何表，控制台打开就是一片空白。

MySQL 里核心有三张表。设备表记录每台设备的唯一标识、别名、分组、最近心跳时间、在线状态；脚本表存脚本名、内容、版本号和最后更新时间；任务表存哪台设备在什么时间执行了哪个脚本、上次执行结果是什么。日志表单独放，脚本跑多了日志量增长快，跟业务表分开好管理。

Redis 存的是设备在线状态和心跳时间，key 可以设计成device:online:<设备id>，value 存心跳时间戳，配合 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，而在数据库连接和内存。

内存受两个因素制约：数据库连接池和 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.1，Redis 也默认监听 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_user'@'127.0.0.1' IDENTIFIED BY '这里写强密码'; GRANT ALL PRIVILEGES ON autojs.* TO 'autojs_user'@'127.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) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; 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) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

ENGINE=InnoDB和CHARSET=utf8mb4这两项不要省。InnoDB 支持行锁和事务，日志表写并发高的时候不会锁整表；utf8mb4 的理由前面已经说过。导入完成后，用SHOW TABLES;确认核心表都在，数据库这块就算准备好了。

3.3 修改服务端配置：端口、数据库、Redis 与通信密钥

数据库初始化完成，接下来配置 Java 服务端。它一般是个可执行的 jar 包，旁边带一个application.properties配置文件。核心配置项如下：

# Web 服务端口 server.port=8080 # MySQL 连接配置 spring.datasource.url=jdbc:mysql://127.0.0.1:3306/autojs?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai spring.datasource.username=autojs_user spring.datasource.password=你的强密码 # Redis 配置 spring.redis.host=127.0.0.1 spring.redis.port=6379 spring.redis.password= # 设备通信密钥 autojs.server.secret=改成随机生成的密钥

spring.datasource.url里的characterEncoding=utf8和serverTimezone=Asia/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 2>&1 & echo $!

命令输出了 PID，说明进程已经拉起来。Spring Boot 启动需要 10 到 20 秒，检查启动日志有没有报错：

# 查看启动日志尾部 tail -50 server.log # 确认进程在跑 ps aux | grep autojs-server

然后看端口监听状态，服务端正常启动后 8080 端口应该处于 LISTEN 状态：

ss -lntp | grep 8080

最后访问一次健康检查接口。不同部署包路径不一样，常见的是/health或/api/health：

curl 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 连接串漏了characterEncoding=utf8，脚本内容从数据库读出来再转给客户端时编码就错了。

解决：脚本源文件统一用 UTF-8 无 BOM 保存，上传之前先确认编辑器右下角编码格式。已经乱码的历史数据，我一般是把脚本内容拷出来，用 Linux 的iconv命令转码再重新上传：

# 把 GBK 编码的脚本转成 UTF-8 iconv -f GBK -t UTF-8 origin.js > fixed.js

转码后务必打开文件确认没有乱码再上传。同时检查application.properties里 MySQL 连接 URL 是否带了characterEncoding=utf8，缺了就补上并重启服务端。这个坑排查起来不复杂，但一旦等脚本跑起来才发现，日志已经全乱了。

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-size=50 spring.datasource.hikari.minimum-idle=10

第二步把设备在线状态的读取从 MySQL 挪到 Redis，心跳更新走 Redis，控制台展示也只读 Redis，MySQL 的压力会小很多。这是我在一个模拟项目里验证过比较有效的优化手段，设备量翻倍时控制台响应时间基本没有明显变化，不夸张，值得一试。

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 触发服务端拉取，拉取后先只推给一台设备验证，确认没问题再推给全组。这个灰度链路做起来不复杂，但能让回归问题的影响面从全部设备缩小到一台设备，非常值得。

总结这些年维护自建服务器的经验，真正决定这套系统能不能长期跑下去的，不是部署那一瞬间的顺利，而是你愿不愿意把版本管理、结果通知和发布策略这三件事制度化。我的习惯是每台服务器上留一份部署日期和版本记录，每个月对比一次配置差异，确认没有漂移。希望这些经验能帮到你，祝你的自建服务器一次跑通，少踩几个我踩过的坑。

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