用户在使用 WorkBuddy 软件及本教程涉及的任何操作前，应自行审阅并同意腾讯官方发布的《腾讯云 WorkBuddy 软件许可及服务协议》（EULA）及《隐私保护指引》。用户需自行承担因安装、配置、使用本教程所涉软件、工具及服务而产生的一切风险、责任及后果，包括但不限于数据丢失、隐私泄露、系统故障、账号封禁或违反相关法律法规及平台规则等。

第三方工具

本教程中可能提及的宝塔面板、Cloudflare 等均为独立的第三方服务，其使用受各自服务条款约束，与本教程作者无关。用户应自行判断其安全性与合规性。

禁止行为

本教程不鼓励且明确反对任何违反 WorkBuddy 用户协议、侵犯腾讯公司合法权益（包括但不限于使用“开心版”、“破解版”等非官方版本）或违反国家法律法规的行为。因用户从事上述行为而产生的一切法律后果，由用户自行承担。

无担保声明

本教程按“现状”提供，作者不对教程内容的准确性、完整性、及时性、可靠性或适用性作任何明示或暗示的担保。作者不对用户因使用本教程而遭受的任何直接或间接损失（包括但不限于经济损失、数据损失、业务中断等）承担任何责任。

权利归属

WorkBuddy 为腾讯公司（Tencent）的产品，其所有权利归腾讯公司所有。本教程与腾讯公司无任何关联，并非官方教程。

关于免费资源（“白嫖”）的特别提醒

本教程可能涉及利用 WorkBuddy 的免费试用额度、积分或实例等资源。用户应知悉，此类免费资源受腾讯官方使用政策约束，通常禁止用于商业用途、高负载运算、挖矿、违法违规内容等。用户自行承担因滥用免费资源（包括但不限于超额使用、违规操作、账号多开等）而导致的一切后果，如资源回收、账号封禁、法律追责等。作者不对此类后果承担任何责任。

使用本教程即视为您已阅读、理解并同意本免责声明的全部内容。
续：
https://linux.sb/topic/13711
（有人估计没看见这个链接，这是领取的方式）
可以把这个发给ai，它应该会按照这个保活

服务自动保活体系：实现原理与搭建指南

目标：在"休眠/重启会清空进程"的环境中，让常驻服务在无人干预下自动恢复。
本文只讲保活机制的实现原理与通用做法，不涉及任何具体业务数据。

一、为什么需要保活？

这类环境（沙箱/容器/按需恢复的服务器）有一个关键特性：

休眠或重启后：文件系统完整保留，但进程全部丢失
环境内自带的定时任务服务（cron）可能也会停止，不能作为唯一依赖

所以"装好服务就完事"是不够的——必须有一套不依赖单一组件的自动恢复机制，这就是保活体系。

二、保活体系的核心架构：三层互为兜底

┌─────────────────────────────────────────────────────┐
│  第一层：平台托管（环境启动时自动拉起）              │
│  → 解决"休眠/重启恢复"                              │
├─────────────────────────────────────────────────────┤
│  第二层：自愈脚本（运行期崩溃 30 秒内自愈）          │
│  → 解决"进程意外退出"                              │
├─────────────────────────────────────────────────────┤
│  第三层：定时任务兜底（每 5 分钟汇总检查）           │
│  → 解决"前两层都失效"的极端情况                     │
└─────────────────────────────────────────────────────┘

为什么是三层？ 因为任何单一手段都有失效场景：

手段	失效场景
平台托管	仅覆盖环境启动时刻，运行中崩溃不负责
自愈脚本	脚本进程本身也可能被杀
定时任务	服务可能自行停止；休眠恢复后不一定自动运行

三层叠加后，任意一层失效，其余两层仍能兜住。

三、每一层是怎么实现的？

第一层：平台托管（最关键的一层）

原理：运行环境通常提供一个"应用自启动清单"机制——把应用的启动命令注册进去后，环境每次启动时都会自动执行清单里的应用。它跟随环境的生命周期，所以能解决"休眠恢复后服务不再"这个最棘手的问题。

实现方式（以通用 autostart 接口为例）：

# 注册两个服务到平台托管清单
curl -s -X POST "http://127.0.0.1:65310/replaceCloudStudioConfig" \
  -H "Content-Type: application/json" \
  -d '{
    "app": [
      {"name": "service_a", "port": 9000, "cmd": "bash /opt/keepalive/service_a.sh"},
      {"name": "service_b", "port": 9001, "cmd": "bash /opt/keepalive/service_b.sh"}
    ],
    "restart": false
  }'

name：应用名；port：健康检查端口（探测服务是否活着）
cmd：启动命令——必须指向一个保持前台运行的脚本（见第二层）
平台按端口探测健康；进程退出时可按配置重启托管应用

没有平台托管的替代方案：注册为系统服务（systemd 的 enable / init.d 的 update-rc.d），实现开机自启。效果类似，但取决于环境对 init 系统的支持。

第二层：自愈脚本（运行期 30 秒自愈）

原理：一个常驻的前台 while 循环，每隔固定间隔检查服务的健康状态（端口是否监听、进程是否存在），发现异常立即执行拉起命令。

#!/bin/bash
# 自愈脚本模板：/opt/keepalive/service_a.sh
LOG=/opt/keepalive/keepalive.log
PORT=9000                        # 服务监听端口
START_CMD="/opt/bin/service_a start"   # 拉起命令

while true; do
  if ! ss -tln 2>/dev/null | grep -q ":${PORT}"; then
    eval "$START_CMD" >> "$LOG" 2>&1
    echo "[$(date '+%F %T')] 服务已拉起" >> "$LOG"
  fi
  sleep 30
done

关键设计点：

设计点	原因
`while true` 保持前台	脚本不能退出；平台按端口探测时，脚本进程就是"应用本体"
间隔 30 秒	崩溃后恢复足够快，又不至于频繁探测
幂等	服务在跑时什么都不做——三层可能同时触发，重复拉起会产生多个实例
全量日志	每次动作写时间戳，方便事后排查"谁拉起了什么"
`ss` 探测端口	端口监听是比"进程存在"更可靠的健康信号（进程在但端口没起来也算失败）

无固定端口的服务（如隧道类），改用进程名探测：

if ! pgrep -x service_name > /dev/null 2>&1; then
  service service_name start >> "$LOG" 2>&1
fi

第三层：定时任务兜底（每 5 分钟）

原理：一个汇总检查脚本，覆盖所有服务 + 端到端链路自检，注册进 cron 每 5 分钟执行一次。即使前两层都失效，这里也会兜底恢复，并记录异常。

#!/bin/bash
# 汇总保活：/opt/keepalive/keepalive.sh
LOG=/opt/keepalive/keepalive.log

# 逐个检查服务，缺失即拉起（每个服务一段，结构同第二层）
if ! ss -tln 2>/dev/null | grep -q ":9000"; then
  /opt/bin/service_a start >> "$LOG" 2>&1
fi

# 链路自检：模拟一次真实请求，期望返回 200
code=$(curl -s -m 8 -o /dev/null -w "%{http_code}" "http://127.0.0.1:9000/health" 2>/dev/null)
if [ "$code" != "200" ]; then
  echo "[$(date '+%F %T')] 链路异常: HTTP $code" >> "$LOG"
fi

注册定时任务并确保其运行：

chmod +x /opt/keepalive/keepalive.sh
service cron start                      # 先确保 cron 在跑
(crontab -l 2>/dev/null; echo "*/5 * * * * /opt/keepalive/keepalive.sh") | crontab -

注意：cron 的启动命令因发行版而异（service cron start / systemctl start cron）。

四、验收标准（必须实测）

只写脚本不算完成，必须做破坏性测试验证每一层：

测试	预期结果
杀掉服务进程	30 秒内自动恢复，端口重新监听
杀掉自愈脚本进程	定时任务（最迟 5 分钟）将其重新拉起
重启/休眠环境	平台托管清单生效，服务自动全部拉起
端到端请求	公网访问路径返回 200

五、实践中的坑

pkill -f 会误杀自己

pkill -f "关键字" 会匹配包含该关键字的整条命令行——如果当前 shell 的命令行里恰好有同样的关键字（比如测试脚本本身），会把自己杀掉。
✅ 正确做法：用 ss -tlnp 提取端口对应的 PID，或用 pgrep -x（精确匹配进程名）。

脚本必须幂等

三层保活可能同时触发（例如自愈脚本刚拉起，cron 又检查了一遍）。不幂等的脚本会拉起多个实例，造成端口冲突。

只更新配置、不重启应用

平台托管的接口若带"立即重启所有应用"参数（restart:true），在服务较多时可能卡住或误杀正在运行的服务。稳妥做法：用 restart:false 只更新清单，再手动启动自愈脚本，让它们自己接管。

先备份再动配置

修改任何系统配置前 cp -a 备份，出问题可秒级回滚。

六、一图总结实现链路

环境休眠/重启
      │
      ▼
平台托管清单被读取 ──► 自动执行自愈脚本（前台常驻）
                              │
                    ┌─────────┼──────────┐
                    ▼         ▼          ▼
              检查面板端口  检查隧道进程  检查反代端口
                    │         │          │
                    └──── 缺失即拉起 + 记日志 ────┘
                              │
                              ▼
                        cron 每 5 分钟汇总兜底 + 链路自检

三层各自独立、职责互补：平台托管管"环境启动"，自愈脚本管"运行崩溃"，定时任务管"极端兜底"——这就是整套保活体系的实现逻辑。
（deepseek生成）

最后由 staff 编辑于 2026-08-18 19:30

免费32核128g内存256g存储的vps（非试用，腾讯的，理论永久）

#0 · staff

发帖 2026-08-18 17:12:43 · 快照 2026-08-18 21:02:47

免责声明

教程性质

本文档（以下简称“本教程”）仅用于技术交流与学习目的，旨在介绍腾讯 WorkBuddy 软件的基本安装与使用方法。本教程中提及的任何操作步骤、配置建议及第三方工具（如宝塔面板、Cloudflare 隧道等）均仅供参考，不构成任何形式的官方指导或承诺。

用户责任

用户在使用 WorkBuddy 软件及本教程涉及的任何操作前，应自行审阅并同意腾讯官方发布的《腾讯云 WorkBuddy 软件许可及服务协议》（EULA）及《隐私保护指引》。用户需自行承担因安装、配置、使用本教程所涉软件、工具及服务而产生的一切风险、责任及后果，包括但不限于数据丢失、隐私泄露、系统故障、账号封禁或违反相关法律法规及平台规则等。

第三方工具

本教程中可能提及的宝塔面板、Cloudflare 等均为独立的第三方服务，其使用受各自服务条款约束，与本教程作者无关。用户应自行判断其安全性与合规性。

禁止行为

本教程不鼓励且明确反对任何违反 WorkBuddy 用户协议、侵犯腾讯公司合法权益（包括但不限于使用“开心版”、“破解版”等非官方版本）或违反国家法律法规的行为。因用户从事上述行为而产生的一切法律后果，由用户自行承担。

无担保声明

本教程按“现状”提供，作者不对教程内容的准确性、完整性、及时性、可靠性或适用性作任何明示或暗示的担保。作者不对用户因使用本教程而遭受的任何直接或间接损失（包括但不限于经济损失、数据损失、业务中断等）承担任何责任。

权利归属

WorkBuddy 为腾讯公司（Tencent）的产品，其所有权利归腾讯公司所有。本教程与腾讯公司无任何关联，并非官方教程。

关于免费资源（“白嫖”）的特别提醒

本教程可能涉及利用 WorkBuddy 的免费试用额度、积分或实例等资源。用户应知悉，此类免费资源受腾讯官方使用政策约束，通常禁止用于商业用途、高负载运算、挖矿、违法违规内容等。用户自行承担因滥用免费资源（包括但不限于超额使用、违规操作、账号多开等）而导致的一切后果，如资源回收、账号封禁、法律追责等。作者不对此类后果承担任何责任。

使用本教程即视为您已阅读、理解并同意本免责声明的全部内容。

1.下载app:workboddy（腾讯的）
注册登录
模型建议deepseek，便宜+聪明
那个免费的千万不要用，贼傻（个人观点）
这个实例好像不花积分，初始2000积分用ds应该花不完
2.直接说安装xxx就行了，例如安装宝塔面板，不要尝试安装安装开心版，破解版的东西，ai很负责，看到广告就认为有病毒
目前好像还不禁止安装面板、网络穿透等，可以宝塔+cf的隧道建站
这个ai回复很慢，不要着急
面板可能会自动关闭，等第2期，有给ai的教程，有点长（在文章末尾）
最初来自ns，那个人也是我
https://linux.sb/topic/13712?p=1&floor=1

最后由 staff 编辑于 2026-08-18 21:01

关于林可欣

#43 · staff

发帖 2026-08-18 16:50:33 · 快照 2026-08-18 16:50:36

@StellaFortuna林可欣 #42 小心被封号啊，在错误的地方

【XQAPI】DeepSeek 再次低价限时狂欢

#66 · staff

发帖 2026-08-17 19:14:06 · 快照 2026-08-17 20:14:27

已成功兑换虚拟卡「5 Credits」。

L站疑似关掉了禁言用户的outh（授权登录）权限

#0 · staff

发帖 2026-08-16 20:30:46 · 快照 2026-08-17 20:22:32

仅个人经历，不上升到平台层面，其他用户个人联想与我无关
我是上个月开始被禁言的，不是抽奖，说实话感觉有点怨，我的频率从一天几次下降到几天一次，今天正好看见君の公益签到有最高520刀，去了，发现每次登录都提示这个
Bad gateway
The web server reported a bad gateway error.

Ray ID: *********
Your IP address: *********
Error reference number: 502
Cloudflare Location: *********
我换了一堆节点，我那个ji chang（违禁词）所有节点都试了，都是这样
后来，我试了其他的公益站，黑与白，随时跑路，any等，无一例外全是这个界面，甚至富可敌国的站也是这样，应该不是我个人原因了

禁言，授权，这两个词我找不出一丝一毫的关系，outh的界面也可以正常进，不存在想省资源的可能，就想恶心禁言的人？我们好歹也是成员啊，我的邀请码还是从其中一个管理的博客上找的，写了好几次小作文，曾经也是三级，发布过信息差福利内容，因为一时的，甚至疏忽的错误，全盘否定整个人？禁言之前，我还是对恶语相向于L站的言论表示存疑，不信，现在……
这应该不是疏忽导致的，但是还是希望是的，各位正常账号的人，珍惜当下吧

最后由 staff 编辑于 2026-08-16 20:41

我签到呢？

#0 · staff

发帖 2026-08-12 10:44:18 · 快照 2026-08-12 10:47:44

Screenshot_2026_0812_104311
之前还在这里的，不知道现在在哪里