auto-read-liunxdo 多账号并发登录原理分批调度与随机延迟的巧妙设计【免费下载链接】auto-read-liunxdoAuto-scrubbing of articles and auto-likes in discourse项目地址: https://gitcode.com/gh_mirrors/au/auto-read-liunxdoauto-read-liunxdo 是一个面向 Discourse 社区如 linux.do的自动化阅读与点赞工具支持通过油猴脚本、本地 Node.js 进程或 GitHub Action 三种方式运行。当需要同时管理多个账号时它的多账号并发登录机制——分批调度 随机延迟——是保障任务稳定、降低风控风险的关键设计。本文将从源码出发拆解这套机制的完整原理与配置方法。为什么多账号登录不能一拥而上许多用户会同时配置 3 个、5 个甚至 10 个账号来刷阅读量。如果让所有浏览器实例在同一秒内同时发起登录请求会带来两个直接后果触发网站风控短时间大量登录请求会触发限流甚至封禁 IP源码中日志里就出现过429状态码提示资源瞬时占满每个账号需要启动一个独立的浏览器实例默认基于 puppeteer-real-browser并发过多会让服务器内存瞬间吃紧导致启动超时。因此项目在 bypasscf.js 中引入了三层调度策略分批、错峰、随机。分批调度每批最多 3 个账号核心参数MAX_CONCURRENT_ACCOUNTS默认值为 3决定了每批同时运行的账号数量上限const maxConcurrentAccounts parseInt(process.env.MAX_CONCURRENT_ACCOUNTS) || 3;主流程使用一个for循环按批次切分账号列表每批内用Promise.all并行启动浏览器实例等到该批全部完成阅读任务结束、浏览器关闭后再进入下一批第 1 批账号 1 ~ 3 同时登录运行第 2 批账号 4 ~ 6 同时登录运行第 3 批账号 7 ~ 9以此类推这种小批量滚动的方式既保证了吞吐量又把单时间窗口内的并发请求数控制在了安全范围内。核心实现见 bypasscf.js。批次内错峰每个实例间隔 10 秒启动即使在同一批次内三个账号也不会同一毫秒一起启动。源码为批次内的每个账号计算了一个错峰延迟const delay (index % maxConcurrentAccounts) * delayBetweenInstances;其中delayBetweenInstances固定为10000 毫秒10 秒。也就是说同一批次的 3 个账号会以 0 秒、10 秒、20 秒的时间差依次启动浏览器既保留并发的效率又避免浏览器实例同时抢占资源、同时发起握手请求。这个设计在代码注释中被明确称为使得每一组内的浏览器可以分开启动。批次间等待按总运行时间动态分配批次与批次之间的间隔不是写死的而是根据总运行时限动态计算const delayBetweenBatches runTimeLimitMillis / Math.ceil(totalAccounts / maxConcurrentAccounts);即总运行时间 ÷ 总批次数 每批之间的等待时长。例如运行 30 分钟、共 9 个账号、每批 3 个则共 3 批每批结束后等待约 10 分钟再启动下一批。这样可以把整段运行时间均匀铺开避免任务前紧后松也保证了每次阅读都发生在不同的时间点行为更接近真实用户。随机延迟让每一步都像人一样登录和阅读过程中的随机延迟是这套设计的点睛之笔主要体现在三处场景随机策略源码位置登录点击与页面跳转delayClick()统一封装随机等待bypasscf.js自动点赞间隔2~5 秒随机2000 Math.random() * 3000index.js点赞概率每个按钮仅 30% 概率触发点赞index.js尤其是点赞环节脚本不会对每个按钮都点赞而是先通过Math.random() 0.3的概率判断决定是否执行再为每次点击设置 2~5 秒的随机间隔——固定频率的机械操作是风控系统最容易识别的特征而概率 随机间隔的组合让行为曲线与真人高度相似。阅读时的滚动也采用每 50 毫秒滚动 20 像素的缓慢匀速策略见 index.js模拟真实浏览节奏。登录降级与容错Cookie 优先、失败重试多账号登录的另一大难点是账号状态各异。项目设计了优雅的降级策略Cookie 优先在环境变量COOKIES中按逗号分隔配置多个账号的_t开头的 Cookie检测到 Cookie 即跳过表单登录直接注入并刷新页面见 bypasscf.js密码兜底没有 Cookie 的账号走表单登录流程输入用户名密码后自动点击登录按钮失败重试登录超时或页面无响应时自动重试最多 3 次每次重试前额外等待 2 秒见 bypasscf.js结果校验通过查找img.avatar已登录或span.auth-buttons未登录判断登录是否真正成功避免假登录后空跑任务。多账号配置速查3 分钟上手以本地运行为例多账号只需在.env中配置一行Cookie 之间用英文逗号分隔COOKIES_tlnm123,_tabc123,_tdef456 MAX_CONCURRENT_ACCOUNTS3 RUN_TIME_LIMIT_MINUTES30若使用 GitHub Action 运行则将这些变量填入仓库的 Secrets 中即可具体入口见下图需要注意USERNAMES与PASSWORDS、COOKIES必须一一对应全部使用 Cookie 时可不填密码MAX_CONCURRENT_ACCOUNTS建议不要超过 5否则批量启动的浏览器实例会显著拖慢服务器。总结一套兼顾效率与安全的调度哲学auto-read-liunxdo 的多账号并发设计可以浓缩为四句话分批限制瞬时并发默认每批 3 个错峰打散启动时刻批内间隔 10 秒均摊分配批次间隔按运行时长动态计算随机模拟人类行为概率点赞 2~5 秒随机延迟。正是这四层机制的叠加让工具在多账号场景下既能高效完成阅读与点赞任务又能最大程度降低被识别为机器行为、触发登录限制的风险。如果你正在部署多账号自动化不妨从调整MAX_CONCURRENT_ACCOUNTS与COOKIES开始亲身体验这套调度设计的精妙之处。【免费下载链接】auto-read-liunxdoAuto-scrubbing of articles and auto-likes in discourse项目地址: https://gitcode.com/gh_mirrors/au/auto-read-liunxdo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考