version: '3.9'
services:
qiandao:
container_name: Qian-Dao
network_mode: bridge
ports:
- '9898:80'
restart: unless-stopped
volumes:
- '/share/Container/Qian-Dao/config:/usr/src/app/config'
image: a76yyyy/qiandao
2026 补充：这篇原文写的是最基础的部署流程，下面补齐“装完之后能不能稳定跑”的部分。如果你已经按上面的 compose 把容器跑起来了，可以直接从第三段开始看。
一、先说结论：2026 年 QD 框架还值得装吗
只让一两个站点每日自动签到，QD 框架依然是最省事的自建方案：一个 Docker 容器、一份 Cookie、一条定时任务就能跑起来，资源占用比青龙面板低一个量级。但 2026 年的网络环境比三年前严格得多，直接照老教程装，通常会卡在三个地方：面板暴露公网被扫描、Cookie 三天失效、站点接口改版后任务静默失败。
判断标准很简单：你愿意为一件事花两小时，并且能接受偶尔自己修，就值得装。想要“装完再也不管”的，无论 QD 还是青龙都做不到，因为签到失败的原因九成在站点侧，不在面板侧。
二、部署前要准备好的三样东西
- 一台长期在线的机器：NAS、软路由或云服务器都行。容器本身很轻，真正吃资源的是同时跑的站点数量，五十个站点以内 1 核 1G 完全够用。
- 一个能反向代理的子域名：面板默认走 HTTP，登录密码是明文提交的。要么只在内网用 IP 访问，要么用 Nginx 反代加 HTTPS，不要两者都不做。
- 一台你平时登录这些网站的电脑：Cookie 必须从真实浏览器导出，不能靠脚本模拟登录。这一步决定了后面签到成功率。
三、2026 修订版部署要点
原文的 compose 可以直接用，但建议补四个参数，能省掉后面 80% 的排障时间：
environment: - TZ=Asia/Shanghai # 不设的话容器是 UTC，定时任务会差 8 小时 - PYTHONUNBUFFERED=1 # 日志实时输出，方便看任务到底跑没跑 ports: - "127.0.0.1:9898:80" # 只绑本机，公网访问一律走反代 volumes: - ./config:/usr/src/app/config
三个细节别忽略：
- 时区：定时任务按容器时区计算，UTC 下你设的“每天 8 点”实际是北京时间 16 点。
- 端口绑本机：写成
127.0.0.1:9898:80后，外网即使扫到 IP 也打不开面板，只能经反代访问。 - 数据目录属主：NAS 上常见的问题是宿主机目录属主与容器内用户不一致，表现为容器起来但配置存不住、重启后任务全丢。进容器
id看一下 UID，再把宿主机目录chown成同一个。
反代只需要转发一个 location，注意保留 WebSocket 头，否则面板会有部分功能点了没反应：
location / {
proxy_pass http://127.0.0.1:9898;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
四、Cookie 能撑多久，取决于三件事
很多人以为 Cookie 是“一次导出永久有效”，实际不是。它能在容器里活多久，主要看三个变量：
- User-Agent 是否一致：导出 Cookie 的浏览器和请求时用的 UA 必须对得上。UA 变了，部分站点会直接判定会话异常并作废 Cookie。
- 登录地是否稳定：家里宽带导出、云服务器发起请求，两地 IP 差异过大时，站点会要求重新验证。这也是为什么把面板放在常用网络环境里成功率更高。
- 站点自身的会话策略：有的站点 Cookie 有效期是 7 天，有的是 30 天，还有的每次登录都会顶掉旧会话——这类站点不适合用固定 Cookie，只能人工签到。
实操建议：把 Cookie 的到期时间记在备注里，按站点分别设置；每周固定一天巡检一次失败任务，比每天盯着看更有效。
五、签到失败：六类原因与排查顺序
| 现象 | 最可能的原因 | 怎么查 |
|---|---|---|
| 日志显示成功，积分没变 | 接口返回 200，但正文是“未登录”或活动已结束 | 把返回内容打印出来看关键字，别只看状态码 |
| 一次全部任务同时失败 | Cookie 过期，或 UA 被改动 | 换新 Cookie 并固定 UA，再单跑一个任务验证 |
| 只有某个站点一直失败 | 该站加了滑块、设备校验或改版 | 浏览器里手动走一遍，看是否有验证码 |
| 容器重启后任务全没了 | 数据目录没持久化或权限不对 | 检查 volumes 映射与目录属主 |
| 到了设定时间没触发 | 容器时区是 UTC | 进容器 date 看时间 |
| 面板打不开或部分按钮无反应 | 反代没转发 WebSocket | 补 Upgrade 与 Connection 头 |
六、QD 框架和青龙面板怎么选
| 维度 | QD 框架 | 青龙面板 |
|---|---|---|
| 上手难度 | 低，网页里填 Cookie 即可 | 中，要拉脚本、装依赖 |
| 能跑什么 | 以内置签到模板为主 | 任意 Python/JS 脚本 |
| 资源占用 | 低 | 中，脚本多时明显 |
| 适合谁 | 只想签到的普通用户 | 要跑自定义任务的折腾型用户 |
如果后面想跑自定义脚本，青龙面板更合适，部署思路可以看 青龙面板部署与云服务器管理；需要网页端抓取、自动化操作的场景，可以配合 browseract 这类 AI 抓取工具 或 MuleRun 自动化实测 的思路，先用 Python 爬虫取数的看 Python 爬虫实战案例。
七、三条安全底线
- 只签自己的账号：帮别人代签等于把他人凭据集中存在自己机器上，一旦泄露责任在你。
- 面板不放公网裸奔：签到面板被扫到后，攻击者能直接拿到里面的全部 Cookie。
- 不开高频重试：失败后一分钟重试十次，只会更快被站点风控，建议失败后间隔几小时再说。
八、常见问题
QD 框架和青龙面板有什么区别？
QD 框架偏“签到专用”，网页里填 Cookie 就能用；青龙面板是通用定时任务容器，能跑任意脚本，但要自己维护脚本和依赖。只要签到，选 QD 更省心。
必须用 NAS 吗？云服务器能不能装？
都能装，本质就是一个 Docker 容器。区别在于网络：云服务器的 IP 与家里不同，部分站点对异地登录敏感，成功率可能低于放在家里的设备。
Cookie 多久需要更换一次？
没有统一答案，取决于站点会话策略，从几天到一个月都有。实用做法是按站点记录，任务开始连续失败就是该换了。
自动签到会不会导致账号被封？
正常频率的每日签到风险很低，风险主要来自三件事：高频重试、多账号同 IP 批量操作、绕过了站点的验证码机制。守住这三条基本没问题。
面板能不能直接暴露在公网？
不建议。面板里存着全部 Cookie，等于一把万能钥匙。要么只在内网用，要么加 HTTPS 和强密码，并且只对自己开放。
支持多少个签到站点？
取决于模板覆盖情况，常见站点基本都有现成模板。数量上 1 核 1G 跑几十个任务没问题，真正的瓶颈是站点风控而不是硬件。
延伸工具：签到只是自动化的入门场景。如果你还想把“查资料、整理表格、批量处理网页”一起自动化，可以先用一套现成的 AI 工具入口试水——
相关推荐：
📦 附：夸克网盘资源库 · 持续更新
我做资源库的标准很苛刻：分类清晰、链接有效、持续更新——这份夸克网盘资源导航表三点都占：直到这篇发布前都还在更新，失效链接会被及时清理，新资源持续入库，找资源不用再到处碰运气。
- 📚 资源库入口：夸克网盘资源导航表（在线表格，收藏即用）
- 💾 建议先收藏本文或保存表格，需要时随时回来取用；表格会持续更新，值得定期逛一逛。
- 📢 觉得有用，欢迎转载分享给需要的朋友（转载注明出处即可）。
