changedetection.io：用 Docker 自托管网页变更监控，及时发现价格与内容更新

盯着一个商品页面等降价，或者反复刷新某个政策公告页看有没有更新，是很多人都做过的无用功。浏览器收藏夹里躺着一堆"需要留意"的链接，但人不可能一天手动点开几十次，重要的变化往往就在没刷新的那几个小时里发生。changedetection.io 要解决的正是这件事：把"人工盯页"变成"机器盯页，有变化再通知你"。

changedetection.io 是一个开源、支持自托管的网页变更监控工具。它的核心机制并不复杂——按你设定的间隔定期抓取目标网页，把这次抓到的内容和上一次保存的快照做对比，一旦检测到差异，就按你配置的方式发出通知，并保留可供查看的差异记录。它适合跟踪商品价格、库存状态、公告与新闻更新、文档或条款变动这类"内容本身会变、但你无法预知何时变"的场景。因为可以部署在自己的服务器、NAS 或树莓派上，数据完全由你掌控，也不依赖第三方服务的额度限制。

需要先说清楚边界：本文只覆盖基础自托管与日常使用。changedetection.io 本质是"抓取 + 对比"，它不是用来绕过登录墙、反爬机制或访问限制的工具，遇到强验证或 Cloudflare 这类防护时，监控同样会受阻，这点后面排查环节会再提到。

环境准备

运行 changedetection.io 的最低要求很低：一台能跑 Docker 的机器即可，普通 VPS、群晖等 NAS，甚至树莓派都能胜任。开始前确认两件事：

• 已安装 Docker，并建议安装 Docker Compose（现在多为 docker compose 子命令形式）。
• 规划好一个数据持久化目录。changedetection.io 的监控列表、历史快照都需要落盘保存，否则容器重建后配置就会丢失。

工具默认监听 5000 端口，Web 界面通过浏览器访问。如果机器上该端口已被占用，可在部署时映射到其他端口。

用 Docker Compose 部署

相比敲一长串 docker run 参数，用 Compose 文件管理更清晰，后续升级、重启也方便。在工作目录新建 docker-compose.yml：

services:
  changedetection:
    image: ghcr.io/dgtlmoon/changedetection.io:latest
    container_name: changedetection
    restart: unless-stopped
    ports:
      - "5000:5000"
    volumes:
      - ./datastore:/datastore
    environment:
      - BASE_URL=http://localhost:5000

这里有几个关键点：镜像来自官方的 ghcr.io/dgtlmoon/changedetection.io；./datastore 挂载到容器内的 /datastore，承担数据持久化；BASE_URL 用于生成通知里的链接，部署到公网或局域网时应填实际可访问的地址。

在该目录执行：

docker compose up -d

首次会拉取镜像并启动容器。启动完成后，浏览器打开 http://服务器IP:5000 就能看到主界面。

需要监控用 JavaScript 动态渲染、内容不在初始 HTML 里的页面时，官方还提供可选的浏览器抓取组件（基于 Playwright/Chrome）配合使用。这属于进阶用法，纯静态或服务端渲染页面用默认抓取方式即可，不必一上来就加这个组件。

首次运行与添加监控

界面核心是一张监控列表（Watch 列表）。添加第一个监控很直接：在顶部输入框粘贴要盯的网页 URL，提交后它会立即抓取一次，建立基准快照。此后它按设定的间隔重新抓取并与基准对比。

点进单个监控项，你能看到几个常用区域：

• 抓取历史与差异视图：每次检测后保留快照，Diff 页面会高亮新增、删除的内容，这是判断"到底变了什么"的主要依据。
• 检查间隔（Time Between Check）：可设为按分钟、小时、天进行，也可以统一在全局设置里配默认值。间隔不是越短越好，太频繁既增加目标站压力，也容易放大噪声。
• 选择器与过滤：决定"页面上哪一块参与对比"。

用规则精确锁定要监控的内容

默认情况下工具会对比整页文本，但整页往往包含大量与你无关的内容。要让监控真正有用，核心就是缩小对比范围。changedetection.io 提供几种方式：

• CSS 选择器 / XPath：只提取页面中某个区域，比如只盯商品价格所在的那个元素，而不是整张页面。监控电商价格时，这一步几乎是必做的。
• 忽略文本（Ignore Text）：对某些总在变但你不关心的文字行设置忽略规则。
• 文本过滤与关键词触发：只在包含特定关键词时才算一次有效变更。

对只含单个商品的页面，工具还支持从页面结构化数据（如 JSON 格式的产品信息）中提取价格，这类"价格检测"比对整段文字更稳定。

设置选择器的实用做法是：先让它抓一次整页，看 Diff 里哪些内容是你真正在意的，再反推应该用什么选择器把范围收窄到那一块。

减少动态内容造成的误报

误报是网页监控最常见的困扰——明明页面"实质内容"没变，却因为一些动态元素被判定为"有变化"，于是通知轰炸让你逐渐无视它。常见的噪声来源和应对思路：

• 时间戳、当前时间、"最后更新于"：用忽略文本规则排除这些行。
• 广告位、推荐模块、随机轮播：改用 CSS/XPath 只提取目标区域，把这些整块排除在对比之外。
• 购物车数量、在线人数、动态计数器：同样通过缩小选择器范围或忽略规则处理。
• 整页对比噪声太大：优先改为精确选择器，这是最有效的降噪手段。

调整的节奏建议是：先宽后窄，观察几轮通知，看哪些是你不想要的，再逐条加规则，而不是一开始就配一堆复杂过滤。

配置通知

检测到变化后，通知环节决定你能不能"及时"知道。changedetection.io 的通知基于通用通知库，支持邮件、以及大量第三方渠道（如常见的即时通讯和推送服务），通过填写对应格式的通知 URL 来配置。

配置要点：

• 可以在全局设置里配一个默认通知，所有监控共用；也可以给单个监控项单独指定，用于区分重要程度。
• 通知内容支持用占位变量，把"哪个监控""变化摘要""链接"等信息带进消息里，方便一眼判断是否需要立刻处理。
• 配好后务必用界面提供的"发送测试通知"确认链路通畅，不要等真正变化发生时才发现根本没收到。

监控失败时怎么排查

当某个监控长时间没有任何动静，或界面上标红报错，按下面三个方向逐一排查通常能定位问题。

一是网络与访问层面。 先确认容器所在的机器本身能访问目标 URL，可以进容器用命令测试连通性。目标站需要特定地区、代理才能访问，或返回了验证页、人机校验，都会导致抓取失败。前面说过，这类反爬与访问限制不是本工具能"绕过"的，遇到就要考虑该页面是否适合监控。

二是页面与选择器层面。 如果抓取成功但始终"检测不到变化"或"全是变化"，多半是选择器问题：选择器没匹配到元素（提取为空）、或页面内容由 JavaScript 渲染而默认抓取拿到的是空壳。前者回到 Diff 和元素选择重新核对，后者考虑启用浏览器抓取组件。

三是通知层面。 监控本身正常、历史里能看到变化，却收不到提醒，问题就在通知配置：通知 URL 格式写错、凭据失效、或对应服务被限流。用测试通知功能单独验证，把"检测"和"通知"两段分开排查，能快速锁定是哪一环断了。

此外，别忽略数据与版本两个基础项。确认数据卷确实挂载成功，可以检查数据卷状态，避免容器重建后配置丢失。升级则用：

docker compose pull
docker compose up -d

它会拉取新镜像并以保留数据的方式重建容器。

它适合谁，又不适合做什么

对需要长期跟踪有限几个页面的开发者和效率用户，changedetection.io 的价值在于把一件琐碎又容易遗漏的事自动化，并且数据自托管、可按需定制。它上手门槛不高，真正花时间的是打磨选择器和过滤规则——这部分做好了，通知才有信噪比。

同时要有合理预期：它擅长"内容对比 + 变化提醒"，但不负责突破登录、反爬和访问限制；监控频率也应顾及目标站点的承受能力，别把它变成变相压测。把范围放在"公开可访问、你确实关心其变化"的页面上，它就是一个安静、可靠的替身，替你完成那些本来要反复刷新才能发现的更新。