网页自动签到引擎

要解决什么问题

纯 HTTP 签到脚本（如 QD 类工具）在遇到滑块、点选、Cloudflare 人机验证，或必须扫码登录的站点时会直接失效。这类站点的风控发生在浏览器环境与服务端的交互中，仅靠携带 cookie 的裸请求会被识别为机器人。此外，许多签到接口带有时间戳或签名校验，手工拼接的请求即使参数正确也会返回"时钟错误""签名错误"。

引擎如何工作

• 核心思路：人机验证只发生在登录环节。首次运行 web_signer.js login 以有头模式打开系统 Edge，人工完成账密/扫码/过验证；引擎将 cookie 与 localStorage 写入该站点独立的持久化 Profile 长期复用，此后定时任务可无头全自动签到。
• 配置驱动：每个站点只需一份 JSON 配置（baseUrl、loginUrl、loginCheck、sign 等），接入新站无需改动引擎代码。
• 四种签到模式：fetch（干净的 XHR 请求）、visit（访问页面即签到）、click（点击按钮触发）、js（多步表单签到，适配 Discuz! 签到插件）。
• 接入流程：写最小配置 → 人工登录一次 → 用 probe.js 抓真实签到行为确定 sign.type → 补全配置后无头实测（首签 + 重复签到）→ 建每日定时任务，各站分钟数错开。
• 验证码兜底：遇到 WAF 图形验证码页，可接百度 OCR 或小笨羊 Provider 自动识别并提交，签到流程继续。

适用边界与注意点

• 强反爬站点（如 itsk）无头模式会返回伪装错误，必须 --head 有头运行，不能承诺全程无人值守。
• 登录轮询期间不要强杀进程，否则会丢失 localStorage 里的 token；脚本退出码 2 表示登录态失效，需重新 login。
• Profile 目录即登录态，同一 Profile 不能被两个进程同时持有，定时任务必须错开时间串行执行。
• fetch 模式仅适用于无签名校验的接口；探测时若返回签名/时钟类错误，应改用 visit 或 click，让网站自身 JS 发请求。