用 changedetection.io 盯公告变化：Docker 部署、局部比较与通知降噪

有些页面没有 RSS，也不发邮件，但里面的一句话变了就值得注意：软件维护日期、活动报名时间、服务条款或项目发布说明。每天手动打开容易忘，整页监控又会被日期、推荐内容和页脚干扰。changedetection.io 可以保存页面变化，重点是让它比较自己真正关心的那一部分。

开始前写下收到通知后准备做什么。只想知道报名是否开放，就保留状态和时间；关心套餐价格，还应一起保留规格、地区和优惠条件。单独截一个数字，比较结果可能很醒目，含义却已经变化。

部署前先确认 VPS 的磁盘、内存和公网访问条件，也可以查看雨云云服务器；注册时填写优惠码 KuZhuJi。

先判断是否真的需要网页抓取

项目已有正式订阅、邮件公告或 GitHub Release 时，优先使用这些入口。网页监控更适合没有订阅机制，或者只关心页面某一段内容的情况。它需要维护抓取规则，页面改版、登录到期、访问限制都会影响结果。

changedetection.io 官方差异对比界面示例

这张官方仓库保留的早期示例图，用颜色标出删除和新增内容。判断通知时仍要结合原页面条件：标题、按钮和日期变化都可能影响含义，不能只看“有变化”便认定业务事件发生了。

只监控自己有权访问的页面，频率与用途相称。不通过工具绕过目标网站的访问限制，也不把个人账号登录态随意放进公开监控实例。需要登录的页面涉及额外凭据和浏览器会话，最好等普通抓取和通知已验证后再做。

普通 HTML 页面先用一个容器

示例从普通请求抓取开始，不安装额外浏览器。已有 Docker Compose 的 VPS 可以准备一个独立目录：

mkdir -p ~/services/changedetection/datastore
cd ~/services/changedetection

保存 compose.yaml：

services:
  changedetection:
    image: ghcr.io/dgtlmoon/changedetection.io:latest
    ports:
      - "127.0.0.1:5001:5000"
    volumes:
      - ./datastore:/datastore
    environment:
      TZ: Asia/Shanghai
      FETCH_WORKERS: "2"
      LLM_FEATURES_DISABLED: "true"
    restart: unless-stopped

这里限制初始抓取并发，先验证少量任务。没有配置外部模型密钥，比较流程不依赖 AI 摘要。latest 会随发行更新，正式长期使用前记录镜像版本或摘要，并固定已验证的版本。

docker compose config --quiet
docker compose up -d
docker compose logs --tail=80 changedetection

管理入口通过 SSH 转发：

ssh -L 15001:127.0.0.1:5001 user@your-server

本机访问 http://127.0.0.1:15001。启用管理密码并检查实际登录行为；监控历史、目标地址和通知凭据都可能包含私人信息，不要把实例当公开演示站直接开放。

第一条规则用自己能修改的页面测试

准备一个普通测试页面，写“本周六维护，预计两小时”，抓取一次作为基准。然后只把“两小时”改成“三小时”，运行下一次检查，观察差异。再仅修改页脚日期，确认它是否造成不需要的通知。

如果不能控制目标页，就很难知道“没有变化”究竟是内容未变，还是抓取没有拿到正确内容。自有测试页可以把抓取、比较和通知逐步拆开验证，等链路正常后再监控真实目标。

遇到结果只包含“请启用 JavaScript”时，普通请求并没有读到页面正文。此时再考虑浏览器抓取，而不是把这种提示当作正常基准。也不要因为页面在自己电脑能打开，就默认 VPS 上的网络、Cookie 和语言设置会得到完全相同的内容。

网页监控的抓取、过滤、比较和通知流程

先缩小目标区域，再比较历史，最后决定是否通知。错误页和登录页也需要识别，否则一次访问失败可能被误报成内容重大更新。

准备独立实例时，可在雨云选择适合的云服务器配置，优惠码 KuZhuJi。配置按实际任务选择，数据库和附件另做备份。

局部筛选时保留决定含义的条件

例如只关心服务维护时间，选择公告标题、正文中的日期和影响范围；价格监控则把币种、周期、地区和规格一起保留。筛选规则越窄，越容易减少噪声，也越容易漏掉页面中新增的重要说明，需要自己权衡。

先观察普通文本结果，再加 CSS 选择器或其他筛选规则。选择器使用稳定区域，避免只依赖页面生成的随机类名。页面改版以后打开历史和最新结果，看筛选区域是否仍有内容；一直抓到空白并不代表一直没有变化。

不要把所有数字、日期都统一忽略。页脚时间可以是噪声，报名截止时间却是重点；相同文字在不同位置有不同意义。先对照几次实际变化，确定某个字段始终与用途无关后，再设置忽略或触发条件。

需要 JavaScript 时再加官方浏览器服务

当前官方 Compose 示例使用 Sockpuppet Chrome 作为 Playwright 浏览器。单独安装这个服务，会增加资源和维护需求。下面给出完整组合，替换前面的文件时保留原来的 datastore。

services:
  changedetection:
    image: ghcr.io/dgtlmoon/changedetection.io:latest
    ports:
      - "127.0.0.1:5001:5000"
    volumes:
      - ./datastore:/datastore
    environment:
      TZ: Asia/Shanghai
      FETCH_WORKERS: "2"
      LLM_FEATURES_DISABLED: "true"
      PLAYWRIGHT_DRIVER_URL: ws://browser-sockpuppet-chrome:3000
    depends_on:
      - browser-sockpuppet-chrome
    restart: unless-stopped
  browser-sockpuppet-chrome:
    image: dgtlmoon/sockpuppetbrowser:latest
    shm_size: 2gb
    restart: unless-stopped

浏览器服务不映射公网端口，只供同一 Compose 网络内的应用访问。shm_size 是共享内存设置，不是浏览器全部内存需求或已经预留好的实际占用。开始时只让确实需要 JavaScript 的任务使用浏览器抓取，观察内存、超时和抓取结果再增加任务。

在任务设置中选对应的浏览器抓取方式，重新建立测试基准。普通抓取与浏览器渲染拿到的页面可能不同，切换后的一次大差异不一定是网站真实改动。涉及额外登录或交互时，逐项验证浏览器步骤，保持凭据和会话私密。

需要增加服务器时，可以打开雨云选购页面，填写优惠码 KuZhuJi；迁移前保留数据与原有部署配置。

通知必须测试到真正接收的一端

按当前版本支持的渠道填写通知地址或凭据。第一次先使用测试通知确认渠道能收到，再让测试页面产生一次真实变化。测试按钮成功只说明消息发送能力可用，不证明监控条件已经匹配真实事件。

如果需要通知里能点回自己的实例，正式域名启用 HTTPS 后再设置 BASE_URL。它是监控实例的外部地址，不是被监控网站地址。管理入口采用哪种认证，就从通知里的链接实际访问一次，确认没有暴露无权限可见的历史内容。

告警频率应当让人愿意看。十分钟一次的重复噪声，很快就会变成无人处理的消息；每天一次抓取也可能错过短时开放的活动。按用途设置频率，并查看目标网页是否允许这样的访问，不承诺监控一定不会漏掉短暂变化。

备份保存的不只是网址列表

datastore 包含监控配置和相关历史数据，可能也保存通知设置或会话。列表导出只适合迁移一部分配置，不等于完整实例备份。暂停服务后复制目录，能够得到边界清楚的恢复材料：

mkdir -p backups
docker compose stop changedetection
tar -czf "backups/changedetection-$(date +%F-%H%M%S).tar.gz" datastore compose.yaml
docker compose start changedetection

浏览器容器在没有应用任务发出时继续运行，不影响这里对应用数据的静止复制。将备份转移到其他存储，限制访问；恢复测试使用独立目录和端口，并先停用真实通知，避免测试副本再次向正式渠道发消息。

恢复后核对目标、筛选规则、历史差异和通知配置，最后只对测试页面触发一次变化。平时也定期检查失败任务，尤其页面改版之后。长期没有消息可能是网页确实没变，也可能是抓取已经失效，监控自身的状态同样需要有人查看。