Turnstile 时期，默认推荐在自己的电脑上跑：签到被拦时脚本会自动拉起你本机的真实 Chrome/Edge 打开官方签到页，由页面自身完成人机验证并点击签到（实测约 15 秒；维护者账号已连续两天入账：11-14 +10、11-15 +19）。

第 1 步 · 环境（一台自己的电脑，装有 Chrome 或 Edge）：

pip install -r requirements.txt
# 无 Chrome/Edge 时再执行: python -m playwright install chromium

第 2 步 · 配置并运行：把 GLaDOS Cookie（须含 gld:sess 与 gld:sess.sig，获取方法见下方快速部署）设为环境变量 GLADOS_COOKIE，然后：

python checkin.py

挂系统计划任务即可每天自动跑（如 Windows 任务计划程序每天 09:30 调用；脚本幂等，重复运行只会提示"今日已签到"）。运行时短暂弹出浏览器窗口属正常流程，勿手动关闭。

• 只想核对状态不弹浏览器：CHECKIN_NOTIFY_STATUS_ONLY=true
• 云端 Actions 用户：定时/外部触发的运行默认已降级为只读状态推送（不试签到、不报失败）；手动 Run workflow 选 dispatch_source=manual 可试完整签到（机房 IP 大概率仍被拦）
• Cookie 过期（日志出现 401 / 请登录 / device-mismatch）才需要重新复制，参考下方说明

已观察到的问题：维护者运行及部分社区反馈出现 code=5, reason=turnstile（Cloudflare verification failed）；部分 GitHub Actions 无头浏览器尝试也未通过。这些记录不足以认定所有纯 API 请求或所有机房环境都必然失败。

本地实测记录：现有 browser_checkin.py 在接口明确返回 reason=turnstile 时，尝试用本机 Chrome（Edge → Chromium 回退）打开官方签到页，由页面处理验证并点击签到。北京时间 11 月 14 日 19:35，维护者单一账号返回 Got 10，余额从此前 15 变为 25，已读流水观察到当日 +10；没有交易标识将流水与请求严格关联。20:30 返回重复签到，不是再次增加 10 分。11 月 15 日 09:32 同账号再次成功（Got 19，25→44，当日 12:30 定时补签确认为幂等空跑），为连续第二天。以上仍是单一账号/单一环境记录，不证明其他账号、运行环境或后续日期必然可用。

• 适用范围与 Actions 行为：仅限自己的电脑 + 真实浏览器。检测到 GITHUB_ACTIONS 时不启用浏览器兜底（显式 GLADOS_BROWSER_CHECKIN=1 才尝试）；定时与外部触发（cron-job.org 等）的 Actions 运行自 2fd0803 起自动降级为只读状态推送——不再尝试签到、不再产生必然的失败通知；手动运行（dispatch_source=manual）仍可选完整签到。官方若撤下 Turnstile，把仓库变量 ALLOW_SCHEDULED_CHECKIN 设为 true 即恢复定时完整签到。
• 不是"绕过"：人机验证仍由 Cloudflare 官方组件在真实浏览器中完成并放行；本仓库不提供打码或绕过方案。
• 本地使用：本机需有 Chrome 或 Edge（或执行 python -m playwright install chromium）→ pip install -r requirements.txt → 配置 GLADOS_COOKIE → 运行 checkin.py（或挂计划任务）。运行时会短暂弹出浏览器窗口，属正常流程，勿手动关闭。Cookie、UA、浏览器与运行环境需分别核对，失败时优先官网手动签到，不要为验证脚本而反复提交。
• 当前 main 的已知风险：浏览器使用共享持久化 profile，多账号场景存在残留会话混用风险（并非已证实发生混用）；点击后丢失响应等模糊结果可能触发换域名或外层重试——未收到成功响应不等于没有提交成功，不应据此反复补签。
• 待验收方案：Draft PR #38 拟加入会话隔离、身份核对、模糊结果停止重试和并发防护；尚未合并 main、未部署到现有本地调度、未完成真实浏览器/真实签到验收。离线测试通过不代表线上已解决。
• 付费边界：已有自述付费账号仍遇到低分或验证失败的反馈；付款不保证固定积分或免除 Turnstile，但不能外推为所有付费账号均无效。请勿仅为排查而购买套餐（见 #37）。

积分口径：通知将"接口声称加分"与"积分流水观察"分开显示、不强行关联归属——同日同额不能证明是本次入账，历史流水也不代表本次奖励（相关讨论见 #28、#37）。

隐私：任何反馈都不要公开 Cookie、Token、密码、验证码、nonce/proof、完整请求头、HAR 或含邮箱/账号信息的截图。

┌─────────────────────────────────────────────────────────────┐
│                                                             │
│   ① Fork 项目    ──→  点一下右上角 Fork 按钮                 │
│                                                             │
│   ② 配置 Cookie  ──→  浏览器复制一下，贴到 GitHub Secrets    │
│                                                             │
│   ③ 启用 Actions  ──→  手动测试一次，之后每天自动运行         │
│                                                             │
│   ✅ 完成！每天状态/积分推送 + 微信通知（签到需本地模式）      │
│                                                             │
└─────────────────────────────────────────────────────────────┘

本项目为非官方社区辅助工具。使用前请阅读以下说明，并确认自己的部署方式符合所用平台的要求。

• 账号与平台规则：仅用于本人或已获明确授权的账号，遵守适用法律法规以及 GLaDOS、GitHub 和所选推送服务的服务条款。请自行确认平台是否允许相应的自动化使用方式。
• 运行与奖励限制：接口、验证流程、积分规则、服务额度和访问策略可能发生变化。测试通过或维护者账号运行成功，不构成持续可用、固定积分、补发差额、兑换成功或账号权益不受影响的保证；签到和奖励以平台实际记录为准。
• 凭据与通知隐私：请妥善保管 Cookie、Token、SendKey 等凭据，GitHub 部署时使用 Secrets，不要提交到代码、公开日志或 Issue。通知触发时，签到摘要可能包含邮箱、积分和剩余天数，并会发送给你配置的推送服务；配置前请了解该服务的数据处理规则。
• 风险与责任范围：本项目按“现状”提供。在适用法律允许的范围内，维护者和贡献者不对使用本项目产生的服务中断、数据或凭据泄露、积分及账号权益损失等承担赔偿责任。本说明不排除依法不得免除的责任。

默认只使用仓库内置的 GitHub Actions 定时任务，无需创建外部 cron。

本项目每月自动提交一次保活时间戳，避免公开仓库因 60 天无活动而停用计划任务。

cron-job.org 仅作为可选备用方案。内置 schedule 与外部 cron 二选一，同时启用会重复签到和重复通知。

已经 Fork 很久的用户需要先点击 Sync fork → Update branch，再重新启用 Actions。

⚠️ 重要：如果你使用其他签到脚本失败，显示 "please checkin via https://glados.cloud"，请使用本项目！

GLaDOS 在 2026 年初进行了 API 更新，绝大多数旧签到脚本已失效。我们通过抓包分析发现了问题：

# 失败 ❌
{'token': 'glados.one'}  → "please checkin via https://glados.cloud"

# 成功 ✅
{'token': 'glados.cloud'} → "Checkin Repeats! Please Try Tomorrow"

📢 重要提示

• GLaDOS 官网已迁移至 glados.cloud（不再是 glados.rocks）
• 本项目专为 2026 积分制度优化，每天自动签到一次
• 完全免费，使用 GitHub Actions，无需自己的服务器
• 不会的话可以提 Issue，作者很乐意帮助技术新手！

本项目支持以下环境变量配置：

PushPlus、Server酱和 Telegram 均为可选，可单独使用，也可同时配置；多个渠道配置后会分别发送同一份多账号汇总，并遵循同一个 PUSH_LEVEL 设置。只读诊断（diagnose_only）不发送推送。

2026 年 9 月的新认证新增了 gld:sess 与 gld:sess.sig。旧的两项 koa:sess 即使尚未过期，也可能只能维持网页兼容状态，调用新版 API 时会返回“没有权限”。请在 Chrome 开发者工具的 Network 中选中一次成功的 /api/user/status 请求，从 Request Headers → Cookie 复制完整值，并确认其中同时存在 gld:sess 和 gld:sess.sig。__stripe_mid 属于支付组件 Cookie，不是签到认证的必要字段，保留也 不会影响请求。请勿在 Issue、日志或聊天中公开任何 Cookie 内容。

新版签到还会校验登录设备。若日志显示 device-mismatch 或 “Automated check-in detected”，请打开同一个浏览器的 chrome://version，复制“用户代理”完整内容，并在 仓库 Settings → Secrets and variables → Actions → Variables 中设置 GLADOS_USER_AGENT。浏览器升级后，应重新登录并同步更新 Cookie 与 User-Agent。

更新后可以先运行只读检查：在 Actions → GLaDOS 2026 Checkin → Run workflow 中， dispatch_source 选 manual，勾选 diagnose_only。只读检查仅请求登录状态，日志不输出 Cookie、邮箱或账号余额，也不会签到、兑换积分或发送推送。所有账号状态查询通过时工作流 成功；查询失败时工作流失败。GitHub 自身仍可能发送工作流失败邮件。 本地使用时设置 CHECKIN_DIAGNOSTIC_ONLY=true 后运行脚本即可。

注意：只读查询成功不代表签到的设备校验也已通过。确认 Cookie 与 User-Agent 对应后， 再取消勾选 diagnose_only 执行一次实际签到；若不希望自动兑换，可先将仓库变量 EXCHANGE_PLAN 设为 off。

完整 Cookie 与 User-Agent 都已配置但仍失败时，请先核对以下信息：

• 普通签到和只读诊断都会显示 浏览器 User-Agent: 已配置 或 未配置，使用默认值， 不输出具体值。Actions 优先读取 Variables 中的 GLADOS_USER_AGENT；Variable 未设置或为空时，兼容读取同名 Secret。两处都配置时以 Variable 为准，更新时请注意 不要留下旧的 Variable。只含空格的 Variable 也会优先于 Secret，随后使用默认值； 请清空或删除它。两处都为空时仍使用默认值。同步工作流后此兼容才会生效。
• 推荐只粘贴完整单行 User-Agent 的值，不要附带说明文字。脚本可自动去掉一对完整的 英文外层双引号及误复制的 User-Agent: 前缀；包含空格的完整浏览器值也兼容一对 英文外层单引号。自定义单个产品标识中的合法单引号会保留，只记录已规范化，不打印内容。 含内嵌换行、无效控制字符、不支持的字符、重复引号或不成对双引号时，会在任何账号请求、 签到、兑换和推送前报配置错误并停止，请重新复制对应浏览器的值。 显示“已配置”只证明配置已传入并通过本地格式检查，不证明它与当前登录会话匹配。
• 提供失败运行的链接（或 commit SHA）、浏览器名称/版本、GitHub Actions 或本地运行、 是否多账号，以及 diagnose_only 是否通过。日志中的 code、已知 reason 和 http_status 可以帮助区分会话拒绝与网络错误。请勿公开 Cookie、Token、完整请求头或 含个人信息的响应体。
• 签到返回设备/认证拒绝，或 HTTP 401/403 时，脚本会停止该账号的重试和后续积分查询、 兑换请求；HTTP 401/403 不会再换域名尝试。其他账号仍继续处理。
• HTTP 5xx、请求超时或响应格式异常属于本次请求失败，不能据此认定 Cookie 失效或当天 未签到。重试耗尽后，脚本会跳过该账号的后续积分查询和兑换，仍发送失败通知并返回失败。 通知标题标明“本次运行失败”，未知的积分和天数显示“未获取”；请结合当天其他成功运行或 官网签到日历核对。日志和推送正文的时间统一使用北京时间（UTC+8）。

Automated check-in detected 是服务端的拒绝结果，仅凭这句文案不能确定具体触发条件， 也不能保证设置 User-Agent 后必然恢复。只读查询通过但实际签到仍被拒绝时，请保留脱敏 结果并联系服务方确认会话或自动化使用策略，不要反复触发签到。

2026-11-06 已核对官网控制台的新流程：签到前会获取一次性 challenge，等待后提交对应的 nonce/proof。旧脚本仅提交 token，缺少这一步；请同步最新 checkin.py。新版本为每次尝试 获取新验证，并在签发验证的同一域名提交；验证失败或过期时会停止本次提交并给出脱敏错误， 不会静默退回旧流程。只读诊断仍只查询状态，不获取验证、不签到。

服务端决定实际入账积分。接口返回 Checkin! Got 1 Points 且流水增加 1，说明已签到但 本次奖励较低；不应把它当作网络失败反复补签。当天已经入账的积分不保证能补差，适配后的 奖励数额需由下一次首次签到的服务端响应和积分流水验证。此项与 User-Agent 配置问题分别排查。

签到攒够积分后自动兑换会员天数，实现无感自动续期：

• 每天签到后检查积分，达到阈值就自动调用 GLaDOS 兑换接口；
• 默认 500 分 → 100 天（plan500），无需任何配置即可生效；
• 想换别的档位或关闭，设置 EXCHANGE_PLAN 环境变量（GitHub 上可配在 Settings → Secrets and variables → Actions → Variables）；
• 兑换成功或失败都会推送通知（积分不足时静默跳过，不打扰）。

点击页面右上角的 Fork 按钮，将项目复制到你的账号下。

⚠️ 注意：GLaDOS 官网已迁移到 https://glados.cloud，请使用新域名！

推荐直接使用 Chrome/Edge 自带的开发者工具；也可以使用 Cookie-Editor：

💡 提示：无论使用哪种方式，都必须取得新版的 gld:sess 和 gld:sess.sig， 不能再只复制旧的两项 koa:sess。

1. 打开 https://glados.cloud，退出后重新登录；
2. 进入 签到页面（Console → Checkin），按 F12 打开开发者工具；
3. 选择 Network，刷新页面，点开一次成功的 /api/user/status 请求；
4. 在 Request Headers 中找到 Cookie，右键复制它的完整值；
5. 确认完整值中同时存在 gld:sess= 和 gld:sess.sig=。

直接使用上一步复制的完整值。它通常包含新旧两组会话 Cookie，例如：

koa:sess=旧会话; koa:sess.sig=旧签名; gld:sess=新会话; gld:sess.sig=新签名

其他 Cookie 可以保留；__stripe_mid 与签到认证无关，但不会造成问题。

也支持将 Cookie-Editor 导出的 JSON 数组整体保存到 GLADOS_COOKIE，可以保留缩进和 换行；整个数组按一个账号处理。多账号请使用上面的 Cookie 请求头格式，每个账号占一行。

常见错误：

• ❌ 仍然只复制 koa:sess 与 koa:sess.sig
• ❌ 漏掉 gld:sess.sig
• ❌ 把 Cookie: 之外的整段请求头一起复制
• ❌ 值两边多了引号
• ❌ 将 Cookie 发布到 Issue、日志或聊天中

运行以下 Python 代码验证格式是否正确：

# 将你的 Cookie 粘贴到下面的引号中
cookie = "gld:sess=你的新会话; gld:sess.sig=你的新签名"

# 验证
if "gld:sess=" in cookie and "gld:sess.sig=" in cookie:
    print("✅ 已包含新版会话 Cookie！")
else:
    print("❌ Cookie 缺少 gld:sess 或 gld:sess.sig")

1. 进入你 Fork 的仓库
2. 点击 Settings（设置）
3. 左侧菜单找到 Secrets and variables → Actions
4. 点击右上角 New repository secret

按需添加以下 Secret：

如果你希望收到微信通知，可选择 Server酱或 PushPlus，也可同时配置。

1. 需要微信通知时，访问 Server酱 Turbo，登录并绑定微信接收渠道。本项目也兼容 Server酱³ 的独立 App 推送，接收方式见官方通道说明。
2. 复制自己的 SendKey，Turbo 通常以 SCT 开头，Server酱³ 以 sctp 开头。
3. 回到仓库 Settings → Secrets and variables → Actions → New repository secret，Name 填 SERVERCHAN_SENDKEY，Secret 填完整 SendKey，然后保存。

只使用 Server酱时，无需配置 PUSHPLUS_TOKEN。推送包含账号、积分、剩余天数、签到结果和兑换信息，正文会转换为 Markdown。

默认 PUSH_LEVEL=fail_only，仅在签到失败或发生兑换时推送。若希望每次签到成功也收到通知，请在 Settings → Secrets and variables → Actions → Variables → New repository variable 中添加 PUSH_LEVEL，值设为 all。这里的 PUSH_LEVEL 应配置为 Variable。

1. 访问 https://www.pushplus.plus
2. 点击右上角 登录，使用微信扫码登录

3. 登录后点击 发送消息 → 一对一消息
4. 复制页面上显示的 Token（类似 05c3****dd36 的字符串）

5. 将 Token 添加到 GitHub Secrets，Name 填 PUSHPLUS_TOKEN

1. 进入你 Fork 仓库的 Actions 标签页
2. 如果看到黄色提示，点击 I understand my workflows, go ahead and enable them
3. 点击左侧的 GLaDOS 2026 Checkin
4. 点击右侧 Run workflow，选择 dispatch_source: manual 后手动测试一次

只有在你的网络环境或 GitHub 计划任务长期不触发时才需要外部 cron。使用它时，请删除或注释 .github/workflows/checkin.yml 中的 schedule，确保只保留一个调度器。

1. 访问 https://github.com/settings/tokens
2. 推荐点击 Generate new token → Fine-grained personal access token
3. Repository access 只选择你自己的 2026-glados-checkin Fork
4. Repository permissions → Actions: Read and write
5. 生成后立即复制；不要把 Token 发到 Issue、截图或写入仓库

使用 classic PAT 时，此接口需要 repo scope；workflow scope 主要用于修改 workflow 文件，并不是调用 dispatch 接口的替代权限。优先使用权限更小的 fine-grained PAT。

1. 访问 https://cron-job.org 注册账号（免费）
2. 注册后登录，点击 Create Cronjob 创建任务

按照以下配置填写：

基本信息：

⚠️ 重要：把 你的用户名 改成你的 GitHub 用户名！比如 lankerr

执行时间：选择每天 09:30（Asia/Shanghai 时区）

高级配置（点击 Advanced 展开）：

请求头（Headers）：点击 "+ 添加" 添加三行：

Authorization 示例只应写成占位形式：Bearer github_pat_xxx。不要公开真实 Token。

请求体（Request body）：选择 Raw Body，填入：

{ "ref": "main", "inputs": { "dispatch_source": "external" } }

配置完成后点击 Save 保存。

1. 在任务列表点击 Test run 测试
2. 当前 GitHub API 成功时会返回 200；旧 API 版本可能返回 204，两者都代表 dispatch 已接受 ✅

3. 到 GitHub 仓库的 Actions 页面查看，应该有新的运行记录

💡 小贴士：遇到 401/422 错误时，先检查上面三行 Headers 是否完全正确！

🎉 完成！ 外部 cron 会每天 9:30 触发一次。记得关闭内置 schedule，避免重复运行。

如果你有自己的长期运行的电脑（如树莓派、软路由、VPS 等），也可以非常简单地在本地运行：

首先确保你已经安装了 Python 3，然后安装依赖库：

git clone https://github.com/你的用户名/2026-glados-checkin.git
cd 2026-glados-checkin
pip install -r requirements.txt

使用环境变量传递 Cookie 并直接运行 Python 脚本：

# 配置 Cookie
export GLADOS_COOKIE="gld:sess=xxxxxx; gld:sess.sig=yyyyyy"

# 可选：配置推送
export PUSH_LEVEL="all"
export SERVERCHAN_SENDKEY="SCT..."
export TELEGRAM_BOT_TOKEN="xxx"
export TELEGRAM_CHAT_ID="yyy"

# 执行签到
python3 checkin.py

通过 crontab -e 配置每天自动执行（例如每天早上 9:30）：

30 9 * * * export GLADOS_COOKIE="gld:sess=xxx; gld:sess.sig=yyy"; cd /path/to/2026-glados-checkin && python3 checkin.py >> glados.log 2>&1

本项目提供了标准的 Nix Flake，你可以直接作为 inputs 引入，系统会自动管理 Python 环境和依赖包。

在你的 flake.nix 中引入本项目：

{
  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
    glados-checkin.url = "github:lankerr/2026-glados-checkin"; # 若本地测试可改写为 path:/绝对路径
  };

  outputs = { self, nixpkgs, glados-checkin, ... }: {
    nixosConfigurations.my-server = nixpkgs.lib.nixosSystem {
      system = "x86_64-linux";
      modules = [
        # 引入 glados-checkin 的 NixOS 模块
        glados-checkin.nixosModules.default

        ({ config, pkgs, ... }: {
          # 配置服务
          services.glados-checkin = {
            enable = true;
            cookie = "gld:sess=xxx; gld:sess.sig=yyy";

            # 【可选】消息推送配置
            pushLevel = "all"; # 或 "fail_only"
            pushplusToken = "xxx";
            serverchanSendkey = "SCT...";
            telegramBotToken = "yyy";
            telegramChatId = "zzz";
          };
        })
      ];
    };
  };
}

部署配置后执行 sudo nixos-rebuild switch --flake .#my-server，签到任务即会自动注册为 systemd timers。

签到成功后，你会在微信收到类似这样的推送：

👤 [email protected]

当前积分: 46 (+20)
剩余天数: 353 天
签到结果: Bindweed! Bindweed!

🎁 兑换选项:
❌ 100分→10天 (差54分)
❌ 200分→30天 (差154分)
❌ 500分→100天 (差454分)

默认使用 GitHub Actions；脚本内部最多尝试三次。外部 cron 是备用方案，不应与内置 schedule 同时启用。

❌ Authorization: github_pat_xxx
✅ Authorization: Bearer github_pat_xxx

{"ref":"main","inputs":{"dispatch_source":"external"}}

cookie1&cookie2&cookie3

GitHub 的 schedule 不是实时调度器：高负载时可能延迟，极端情况下可能丢弃排队任务；公开仓库连续 60 天无活动会自动停用 schedule。为降低风险，本项目采用非整点运行、脚本内三次重试和每月一次保活提交。

这仍不能保证第三方服务 100% 可用：GLaDOS 宕机、Cookie 失效、GitHub 故障或用户自行关闭 Actions 时，签到会失败。新版会让真正失败返回非零退出码，以便 Actions 邮件和可选通知准确报警。

• 📝 提 Issue：遇到问题请提 Issue，作者很乐意帮助技术新手！
• ⭐ Star：如果对你有帮助，请点个 Star 支持一下
• 🍴 Fork：欢迎 Fork 并贡献代码

感谢通过 Pull Request 改进本项目的贡献者。每一项修复和文档改进都让自动签到更可靠，也让新用户更容易完成配置。

同时感谢 @LxFairy 提交上游同步与冲突处理 PR（#8、#9，未合并），以及在 Issues 中提供报错日志、排查线索和复测反馈的用户。

感谢 @chengchang1987-cloud 在 Issue #28 提供积分流水、challenge 排查证据和参考脚本。参考脚本的核心 proof 算法与已合并的 #31 一致；本次进一步采纳日志即时刷新（flush=True）及 2.7 秒等待时间（在 2.5 秒基础上增加 0.2 秒余量）。原有的 nonce/TTL 校验、同域提交、失败时不回退旧签到流程、User-Agent 兼容和推送行为均保留。这两项改进不代表首次签到奖励已恢复，仍需以下一次首次签到返回及实际积分入账核验。

特别感谢 @badpinkman 对 2026 年 9 月认证故障的排查与修复，帮助本项目恢复正常签到。

• 在 README 顶部区分 Turnstile 拒绝实测、历史成功、手动/重复签到及工单反馈。
• 添加来源和脱敏数据征集入口；本次没有修改签到代码或发布验证修复。

• 合并 @badpinkman 的 PR #18，适配 gld:sess / gld:sess.sig 和 GLADOS_USER_AGENT。
• 旧会话导致的“没有权限”需要通过重新登录、更新完整 Cookie 解决；设备校验还要求 User-Agent 与生成会话的浏览器一致。Fork 同步代码不会自动更新个人仓库的 Secrets 和 Variables。
• 维护者仓库在更新配置后完成真实验证：首次签到成功，同日重复签到正常返回。

• 识别 Today's observation logged... 等 2026 正常返回，不再显示“成功 0/1”
• 失败自动重试三次，最终失败返回非零退出码
• 默认仅失败推送，避免多个调度器造成通知轰炸
• 每天一次签到、每月一次保活，替代每天保活提交
• 修正 workflow dispatch 的 PAT 权限、HTTP 状态码和 404 排障说明

问题：签到始终返回 "please checkin via https://glados.cloud"，导致机器人无法签到。

原因：GLaDOS 官方更新了 API，签到 token 必须从 glados.one 改为 glados.cloud。

修复：更新 checkin.py 中的 token 参数。

排查过程：

1. 使用浏览器 DevTools 抓包分析真实签到请求
2. 对比 Python 脚本与浏览器请求的差异
3. 尝试添加 Headers、模拟 TLS 指纹等方案（均无效）
4. 最终通过测试不同 token 值发现问题根源

💡 如果你在使用其他签到项目遇到同样问题，可以参考本项目的修复方案！

• 初始版本发布
• 支持 glados.cloud 域名
• PushPlus 微信推送
• GitHub Actions 自动签到

MIT