青龙面板+Docker自动签到脚本：定时任务、环境变量与日志通知工程实践-北京尧图网络

折腾自动化这件事很多人都是从“每天手动点一次签到”开始的。我自己最早也是这样手机里躺着十几个 App每天醒来第一件事是挨个点开、找入口、领积分点完还要担心漏了哪个。后来把这套活交给青龙面板QingLong才算真正把自己从重复劳动里解放出来。青龙面板本质上是一个带 Web 界面的定时任务管理器它把脚本、依赖、环境变量、运行日志、通知推送这几件原本散落在服务器各处的东西塞进一个容器里统一管起来。你不需要记 crontab 语法不需要 SSH 上去改文件也不需要为了一个脚本专门配 Python 环境浏览器打开就能改任务、看日志、装依赖。这套“青龙面板自动签到脚本”的组合做的事情很具体按你自己设定的时间自动带着账号凭证去目标站点完成每日签到动作把结果汇总后推给你失败了几秒钟内就能知道。它适合三类人手上有若干需要每日签到的账号、又不想天天手动点的普通用户想借一个真实小项目入门自动化脚本和容器部署的新手以及已经在跑一堆脚本、但日志和凭证管理一团乱、想认真做一次工程化整理的老玩家。下面我按“为什么这么设计、脚本怎么写、任务怎么排、出问题怎么查”这个顺序把我自己跑这套东西积累的东西摊开讲。1. 整体方案设计与选型思路在动手之前先把方案想清楚比上来就复制粘贴脚本重要得多。我见过太多人一开始兴致勃勃抄了一堆脚本扔进去跑了两周某天发现全挂了然后因为没有日志、没有通知、凭证也不知道是哪天过期的最后整批放弃。这不是脚本本身的问题是方案没设计。1.1 为什么选青龙面板而不是本机 crontab用本机 crontab 当然也能跑签到成本最低一条0 8 * * * python3 /home/me/checkin.py就完事。但我实际用下来它在三个地方会让人难受。第一是环境隔离。你服务器上的 Python 可能是 3.8脚本依赖的某个库要求 3.10 以上你为了这一个脚本升级 Python可能把别的服务搞挂。青龙面板跑在容器里Python 和 Node 的版本、装的库都是面板内部的事跟宿主机完全隔开装坏了删掉依赖重装就行不影响别的服务。第二是日志可读性。crontab 的输出去哪了要么重定向到文件自己tail要么配邮件。青龙面板每个任务的每次执行都有独立日志点开就能看到从第几行开始报错还带时间戳和执行耗时排查效率完全不是一个量级。第三是凭证管理。签到脚本最麻烦的不是逻辑是 Cookie 会过期。用 crontab 时代Cookie 是写死在脚本里的过期了要 SSH 上去改文件、存盘、确认没改错缩进。青龙面板把凭证抽到“环境变量”里脚本只负责读变量换 Cookie 就在网页上改一个输入框改完立刻生效脚本文件一个字都不用动。这个设计看起来只是个便利性优化实际用起来是质变因为它把“代码”和“数据”彻底分开了。代价也要说清楚多了一层容器出问题时你需要会看docker logs需要理解挂载目录的权限需要知道面板重启后数据还在不在。这些都是一次性学习成本学会了后面全是收益。1.2 把任务拆成三层而不是一个大脚本我最初的写法是一个大脚本从头干到尾读环境变量、登录、签到、解析结果、拼通知文本、发通知。跑是能跑但改起来很痛苦——我想给通知加个字段得翻两百行某个站点接口变了得在一大坨代码里找位置。后来我改成了三层结构逻辑清楚很多凭证层负责拿到可用的 Cookie/Token并且判断它还有没有效。这一层可以是一个独立脚本也可以是主脚本开头的一个函数但要独立成模块。执行层拿着凭证去做签到动作只关心“发请求、拿响应”不关心结果怎么展示。汇总层收集执行层的返回值生成一条人能看懂的消息推送到我手机上。这么拆的好处是某一层出问题定位范围立刻缩小一半。凭证失效看第一层请求报错看第二层收到通知但内容不对看第三层。而且汇总层是通用的——我后面新加站点只要新脚本按约定返回{name, ok, msg}这样的结构汇总逻辑一行都不用改。提示分层不等于要拆成多个文件。青龙面板里一个脚本文件内用几个函数实现分层同样能达到隔离效果反而少了一次文件间传参的麻烦。别为了“架构感”把简单的事做复杂。1.3 一条容易被忽略的边界只对自己负责写签到脚本这件事技术上没有门槛但用法上有边界我把它写在最前面因为它决定了你后面所有设计。脚本能做的事本质是“用你本人的账号凭证替你完成一次你本来也要手动做的操作”。所以前提很明确只对你自己的账号跑只做你手动也会做的那一次动作。具体落到实现上就是三条签到频率一天一次不要几秒一次地轮询不去绕过站点的人机验证遇到验证码就停下来让脚本报告失败而不是想办法硬闯Cookie 和 Token 属于账号凭证不分享、不外传、不进公开仓库。我见过有人把带 Cookie 的配置直接贴到公开的脚本仓库里那等于把家门钥匙挂在门上。频率控制这件事还有技术意义。很多站点对同一 IP 的请求有频率限制你一秒一次地打换来的不是签到成功而是429 Too Many Requests甚至短时封禁。一天一次、加个随机延迟成功率高得多也更省心。2. 青龙面板部署与基础配置面板本身不难装但装完之后的几个配置项如果没设对后面会持续给你制造小麻烦。这一节按部署、目录、依赖、变量的顺序讲每一步都说清楚为什么要这么做。2.1 容器部署与关键参数主流做法是用 Docker 起容器。下面这条是我在用的命令参数说明跟在后面docker run -dit \ --name qinglong \ --hostname qinglong \ --restart unless-stopped \ -p 5700:5700 \ -e TZAsia/Shanghai \ -v /opt/ql/data:/ql/data \ mwhahaha/qinglong:latest-p 5700:5700是面板的 Web 端口映射出来后浏览器访问http://你的IP:5700就能进。--restart unless-stopped很关键服务器重启后容器会自动起来否则某次意外重启之后你的签到就静默停了而你毫不知情。-e TZAsia/Shanghai更不能省容器的默认时区通常是 UTC如果你不设cron 里写的“早上 8 点”实际会在北京时间下午 4 点执行这种错位特别隐蔽日志时间戳看着也对但对不上你的预期。-v /opt/ql/data:/ql/data是数据挂载。面板的数据库、脚本、日志、配置全在/ql/data下挂到宿主机上容器删了重建数据还在。我踩过的坑是挂载目录权限不对容器里以非 root 用户运行写不进数据库表现为面板能打开但保存设置一直失败。解决办法是先建目录再赋权mkdir -p /opt/ql/data chown -R 1000:1000 /opt/ql/data第一次进面板会让你设账号密码设完记得把地址和密码记进你自己的密码管理器别用默认的弱口令如果这台机器有公网 IP更要注意别把 5700 端口直接暴露在外。2.2 依赖管理装什么、装在哪青龙面板的“依赖管理”页面里可以给 Python 和 Node 分别装库。新手最容易犯的错是本地测试跑通了扔进面板报ModuleNotFoundError。原因就是那些库装在本地环境容器里没有。按签到脚本的常见需求Python 侧我一般装这些依赖用途备注requests发 HTTP 请求最核心必装pycryptodome部分站点需要加密参数不做加密可以跳过python-dateutil时间处理处理签到日期判断时方便pytz时区换算涉及跨时区站点才需要Node 侧常见的是axios、node-fetch、dotenv、crypto-js。这里有个版本坑要提醒Node 18 之后内置了全局fetch如果你的脚本用了全局fetch在 Node 16 的镜像里会直接报未定义。要么把镜像里的 Node 版本确认清楚要么保守一点统一用axios它在各版本行为一致。装依赖时如果下载很慢或者超时可以在面板设置里把源换成国内镜像。Python 用清华源Node 用 npmmirror这个改动很小但能把一次装依赖从十分钟缩到几十秒。2.3 环境变量的组织方式这是影响长期可维护性最大的一环。我的命名规则是“站点前缀用途”比如SITEA_COOKIE、SITEB_TOKEN、SITEB_UID。前缀统一后面加站点时一眼能看出哪个变量属于哪个脚本。多账号怎么存两种做法我都用过。一种是一个变量存多行账号之间用换行或者分隔脚本里先 split 再循环raw os.getenv(SITEA_COOKIE, ) cookies [x.strip() for x in raw.replace(\n, ).split() if x.strip()]另一种是一个账号一个变量SITEA_COOKIE_1、SITEA_COOKIE_2。前者改起来快后者在某个账号失效时更容易定位是谁。账号数量在五个以内我推荐后者因为青龙面板的变量列表里能直接看到哪一行是哪个号删改都直观。如果一个站点的凭证不止一个字段比如既有token又有uid还有refresh_token别拆成一堆零散变量直接存一段 JSON{token: xxxx, uid: 12345, refresh: yyyy}脚本里json.loads一下就用结构清晰也不容易漏字段。注意环境变量在面板里是明文存储的任何能登录面板的人都能看到。所以面板的账号密码强度、是否需要限制访问来源这两件事的优先级要高于你脚本写得多漂亮。3. 签到脚本的核心写法与实操脚本这一块我按“拿凭证、验凭证、发签到、解结果”四个动作来写每个动作都能独立调试。下面给的代码是通用骨架你可以照着填自己站点的接口地址和字段名。3.1 凭证获取与有效性预检抓 Cookie 的方法不复杂浏览器登录目标站点按 F12 打开开发者工具切到 Network 面板随便点一个页面内的按钮触发请求在请求头里找Cookie那一行整段复制。有些站点用的是请求头里的Authorization: Bearer xxx那就复制 token 部分。复制完别急着往脚本里塞先做一次有效性预检。判断标准是找一个“查询当前用户信息”的接口带上凭证请求一次看返回里的用户 ID 或昵称对不对得上import os, requests COOKIE os.getenv(SITEA_COOKIE, ).strip() def check_cookie(cookie: str) - bool: if not cookie: return False try: r requests.get( https://example.com/api/user/info, headers{Cookie: cookie, User-Agent: Mozilla/5.0 ...}, timeout10, ) data r.json() return data.get(code) 0 and bool(data.get(data, {}).get(uid)) except Exception as e: print(f预检异常: {e}) return False这一步的价值在于把“凭证失效”和“签到逻辑出错”区分开。没有预检凭证过期时你看到的是一堆签到接口返回登录页 HTML解析报JSONDecodeError你会以为是解析代码写错了往错误的方向查半天。预检的另一个好处是能提前发现“接口地址变了”。站点改版后/api/user/info可能变成/api/v2/user/info预检会立刻报 404而不是等到签到那一步才莫名其妙地失败。3.2 用 Python 写一个可复用的签到骨架下面这段是我一直在用的结构几个要点在代码里标了注释import os, time, random, json, requests HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Accept: application/json, text/plain, */*, Referer: https://example.com/, } def do_checkin(cookie: str) - dict: 执行签到返回结构化结果 try: r requests.post( https://example.com/api/checkin, headers{**HEADERS, Cookie: cookie}, timeout15, ) # 不要只看 HTTP 状态码业务码在 body 里 data r.json() code data.get(code) if code 0: return {ok: True, msg: data.get(msg, 签到成功)} if code in (401, 403): return {ok: False, msg: 凭证已失效, need_refresh: True} if code 429: return {ok: False, msg: 触发频率限制} return {ok: False, msg: f业务码 {code}: {data.get(msg, 未知错误)}} except json.JSONDecodeError: # 返回了 HTML通常是登录页说明凭证失效 return {ok: False, msg: 返回非 JSON疑似凭证失效, need_refresh: True} except requests.Timeout: return {ok: False, msg: 请求超时} except Exception as e: return {ok: False, msg: f异常: {type(e).__name__}} def main(): raw os.getenv(SITEA_COOKIE, ) cookies [x.strip() for x in raw.replace(\n, ).split() if x.strip()] if not cookies: print(未配置 SITEA_COOKIE) return results [] for idx, ck in enumerate(cookies, 1): res do_checkin(ck) res[account] f账号{idx} results.append(res) print(f[账号{idx}] {成功 if res[ok] else 失败} - {res[msg]}) # 多账号之间加随机间隔别让请求排成一队 if idx len(cookies): time.sleep(random.uniform(2, 5)) ok sum(1 for r in results if r[ok]) print(f汇总: {ok}/{len(results)} 成功) # 这里可以调用通知函数把 results 拼成消息发出去 if __name__ __main__: main()几个细节值得单独说。超时一定要设timeout15这个参数省了某次接口卡住你的任务会一直挂着青龙面板那边显示“运行中”你看着进度条怀疑人生。异常要分类捕获超时、JSON 解析失败、其他异常三类对应的处理方式完全不同混成一个except Exception会把关键信息吃掉。多账号之间加间隔这个在账号多的时候尤其重要连续几十个请求打过去很容易被判定为异常流量。还有一个返参加工的技巧有些站点签到成功后返回的msg里带积分数字比如“签到成功获得 5 积分”。如果你的通知想展示积分可以用正则从msg里抠出来而不是再请求一次积分接口省一个请求也少一次失败的可能。3.3 Node 版本的对照写法有些现成脚本是 Node 写的你得能看懂、能改。核心逻辑和 Python 版一一对应区别主要在异步处理上const axios require(axios); const HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Referer: https://example.com/, }; async function doCheckin(cookie, index) { try { const { data } await axios.post( https://example.com/api/checkin, {}, { headers: { ...HEADERS, Cookie: cookie }, timeout: 15000 } ); if (data.code 0) return { account: 账号${index}, ok: true, msg: data.msg }; if ([401, 403].includes(data.code)) return { account: 账号${index}, ok: false, msg: 凭证失效 }; return { account: 账号${index}, ok: false, msg: 业务码 ${data.code} }; } catch (e) { return { account: 账号${index}, ok: false, msg: e.message }; } } (async () { const raw process.env.SITEA_COOKIE || ; const cookies raw.replace(/\n/g, ).split().map(s s.trim()).filter(Boolean); const results []; for (let i 0; i cookies.length; i) { results.push(await doCheckin(cookies[i], i 1)); await new Promise(r setTimeout(r, 2000 Math.random() * 3000)); } console.log(JSON.stringify(results, null, 2)); })();这里最容易出问题的是异步没等。如果你写成cookies.forEach(async ck { ... })主线程不等子任务结束就退出了青龙面板记录的状态是“成功”但实际上一个请求都没发出去。稳妥的做法就是用for循环加await顺序执行虽然慢一点但结果确定。3.4 结果解析的三条判断原则判断签到成没成功我总结了三条原则能避开绝大多数误判。第一条HTTP 200 不等于成功。很多站点的业务错误也是 200错误信息藏在 body 的code里。所以必须解析 body。第二条失败要能区分“该重试”和“不该重试”。网络超时、502这类重试一两次大概率能过凭证失效、业务码明确拒绝重试一百次也没用反而可能触发风控。我的做法是给结果加一个need_retry标记只有这个标记为真才进重试队列最多两次每次间隔翻倍。第三条日志要能复现问题。打印日志的时候不要只打“签到失败”要打上账号序号、HTTP 状态码、业务码、返回的前 200 个字符。我第一次排查失效问题时日志里只有一句“失败”只能一个个手动去试浪费了一个多小时。4. 定时任务编排与通知推送脚本能跑通只是第一步把它排进定时任务、并且让失败能被你及时知道才算真正交付。4.1 cron 表达式与错峰策略青龙面板的任务用标准五位 cron分、时、日、月、周。0 8 * * *就是每天 8 点整。看着简单但有两个坑。第一个坑是时区。前面提过容器没设TZ的话你写的 8 点会变成别的时间。除了设环境变量青龙面板的设置页里也有时区选项两处都对一遍别嫌麻烦。第二个坑是整点拥堵。如果你有好几个站点都要早上 8 点跑加上别人的机器也是这个时间目标站点的服务器在整点承受的请求量会陡增你的请求更容易超时或被限流。我的做法是给每个任务错开几分钟并在脚本开头加一段随机延迟import time, random time.sleep(random.randint(30, 300)) # 随机等 30 秒到 5 分钟这段延迟放在脚本最开头比改 cron 更灵活因为你不用为了错峰把任务时间改得七零八落日志时间戳也能看出实际执行时刻。如果某个站点的签到有“必须是当天”的限制注意别把任务排在 23:50 这种时间点。一次网络抖动导致任务跨天签到的就是第二天而前一天漏了。我一般把签到放在上午 8 点到 10 点之间留足重试余量。4.2 青龙面板的任务配置项在面板的任务编辑页里除了 cron还有几个字段值得认真填。任务名称要用能一眼看懂的中文比如“站点A-每日签到”别用task1。等你手上二十个任务的时候命名规范救的是你自己的时间。定时类型默认是 cron面板还提供了“每天”“每周”这类快捷选项效果一样看习惯。运行前操作和运行后操作这两个字段很多人不用其实挺有用运行前可以用来拉取脚本更新如果你的脚本放在自己的私有仓库里运行后可以触发一次汇总通知。自动删除日志建议开启。日志文件攒着不删几个月后占满磁盘容器直接起不来。我设的是保留 7 天够排查用也不会撑爆。4.3 通知推送的消息怎么组织通知的价值不在“告诉我跑了”而在“失败时让我三秒内知道该干什么”。所以我发出来的消息模板是这样的【每日签到】2025-01-15 站点A3/4 成功 ✗ 账号2 凭证已失效站点B1/1 成功站点C0/1 失败 - 请求超时已重试2次关键信息有三个哪一天、哪个站点哪几个账号失败了、失败原因属于哪一类。“凭证已失效”和“请求超时”对应的动作完全不同前者要你手动去更新 Cookie后者大概率第二天自己就好了。如果把所有失败都写成“签到失败”你收到通知后还得登面板翻日志通知就失去意义了。实现上我在脚本最后定义一个send_notify(title, content)函数内部用 HTTP POST 把内容推给面板自带的通知渠道或者直接调你自己的推送服务。函数要包在try/except里通知发不出去不能影响主流程的退出码——我遇到过一次推送服务临时不可用脚本抛异常退出面板记为失败第二天我看到一堆失败记录实际签到全成功了。从那以后通知调用一律降级处理。提示通知内容里有账号信息的话别把完整 Cookie 打出来。用“账号1”“账号2”这种序号代替既够定位也不泄露凭证。前八位加省略号的脱敏写法也可以但那串字符本身也不该出现在推送通道里。5. 常见问题与排查实录这一节是我这两年里真正踩过的坑按出现频率排序。每个问题都给出“现象、原因、怎么查、怎么修”四段你可以当成速查表用。5.1 Cookie 失效的三种典型表现这是出现频率最高的问题没有之一。Cookie 有效期从几天到几个月不等站点改版、异地登录、修改密码都可能让它提前失效。它有三种典型表现识别方式不一样。表现一返回 HTML 登录页。日志里出现JSONDecodeError或者一堆!DOCTYPE html。这是最直接的一种说明请求被重定向到了登录页。修法就是重新抓 Cookie替换环境变量。表现二业务码变成未登录。HTTP 200body 里code是401或-1msg写着“请先登录”。这种情况请求没有跳转只是接口层拒绝了处理逻辑同上。表现三签到接口返回“今天已签到”。这个最容易误判成失败实际上是成功的。有些站点同一账号重复签到返回的不是幂等成功而是一个单独的提示码。遇到这种情况要在脚本里把它归到成功范畴if 已签到 in msg: return okTrue。排查的时候我有个省事的办法拿 Cookie 在本地用 curl 手动请求一次比在面板里改脚本、点运行、看日志快得多curl -s https://example.com/api/user/info \ -H Cookie: 你的cookie \ -H User-Agent: Mozilla/5.0 | head -c 300返回里有你的用户 ID说明 Cookie 是好的问题出在别处返回登录页那就是 Cookie 的事不用再往下查了。5.2 依赖与运行环境类故障这类问题的现象很统一任务状态是失败日志最后一行是ModuleNotFoundError: No module named xxx或者Cannot find module xxx。原因通常有三个。一是面板依赖没装去依赖管理里补上注意区分 Python 和 Node 两栏装错栏的情况我见过不止一次。二是装在了别的 Python 版本下容器里可能有多个 Python你pip install用的是系统那个脚本运行时用的是面板自带那个路径不一致。判断方法是看日志开头的解释器路径跟依赖管理页显示的对比一下。三是依赖装了但版本不对某个库的大版本升级后接口变了老脚本调不通。这种情况锁定版本号requests2.28.0这样写别用latest。还有一种不那么明显的脚本编码问题。脚本里如果有中文文件保存成 GBK容器里按 UTF-8 读运行时会报SyntaxError或者乱码。统一存 UTF-8这个习惯要养成。5.3 问题速查表现象大概率原因快速验证处理方式返回 HTML 登录页Cookie 失效curl 手动请求重新抓 Cookie 更新变量业务码 401/-1凭证过期或被踢下线同上同上注意是否有异地登录429 / 频繁失败请求过快或任务撞车看日志时间戳是否密集加随机延迟降低频率ModuleNotFoundError依赖未装或版本不符看日志解释器路径依赖管理补齐锁版本任务显示运行中不结束请求无超时日志停在某个请求所有请求加 timeout通知没收到但任务成功推送异常被吞或渠道配置错手动点一次测试推送通知包 try/except检查渠道每天重复签到时区不对对比日志时间与本地时间设置 TZAsia/Shanghai日志占满磁盘未开启自动清理du -sh看 /ql/data/log开启日志自动删除5.4 几条用时间换来的经验别在周五晚上改脚本。我有两次教训周五晚上顺手改了个逻辑周末两天没看周一发现全挂了白白损失两天签到。改动尽量放在工作日早上改完当天能看到执行结果。凭证更新的动作要固化。Cookie 什么时候过期是不确定的靠记忆维护迟早出事。我的做法是预检失败时通知里除了“凭证失效”还附带一句“请更新 SITEA_COOKIE”看到就知道要干什么。更进一步可以在面板里给每个站点记一个“上次更新日期”超过一个月就主动检查一次。脚本要能空跑。每个新脚本上线前我会先加一个DRY_RUN环境变量值为true时只打印将要发的请求不真发。确认请求地址、请求头、参数都对再关掉空跑。这个习惯帮我避免了好几次“参数写错但请求发出去了”的尴尬。写下来的东西比记在脑子里的可靠。我给每个站点建了一条笔记记着接口地址、需要的凭证字段、cron 时间、最后一次成功日期、改版历史。半年后回来维护看一眼笔记就能上手不用重新抓包分析一遍。接受“有些站点就是会挂”。站点改版、接口加签名、上验证码这些都不是你能控制的。我的策略是签到脚本只管签到遇到验证码就明确报“需要人工介入”不折腾绕过方案。毕竟这件事的初衷是省时间为了它搭进去一整天去破解验证就本末倒置了。最后分享一个我自己用了很久的小技巧给所有签到任务建一个“总开关”。做法很简单在面板里建一个环境变量CHECKIN_ENABLED值为1或0每个脚本开头读一下不是1就直接退出。出门旅行、或者某段时间不想跑的时候改一个变量全部停下回来再改成1全部恢复不用挨个去禁用任务。这个小设计在一次我要临时停掉全部任务的时候省了我至少十分钟。

青龙面板+Docker自动签到脚本：定时任务、环境变量与日志通知工程实践

相关推荐

滑动窗口与单调队列：高效算法实战解析

零基础自学PCB设计：建库、抄图与DRC查错一条线

代码自动补全技术：原理、优化与实战应用

更多资讯

reverse-skill：反向拆解已有能力的方法论与实操指南

家庭清洁清单的分区与交接记录

OpenAI与微软的算力博弈：云计算市场新格局

漏洞挖掘实战：从扫描器依赖到攻击面建模

paperclip 实战：Node.js + React 构建 AI agent 可观测面板

链表反转：程序员必会的基础算法与工程实践

今日更新

淘宝商品详情API开发实战与性能优化指南

Unity Package Manager刷新错误排查与解决方案

Java record 规范构造器能否被反序列化或反射绕过

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？