抢补货/盯降价不求人：changedetection.io 自托管监控实测

2026-08-16 · DevCraft Studio

用一台几美元的 VPS 就能自建网页变更监控：紧盯显卡补货、电商降价、政策页更新，再靠 Telegram 和 ntfy 免费推送。本文手把手教你在便宜机器上用 Docker 部署 changedetection.io，并分享中文圈教程常漏的避坑点。

延伸阅读

更多相关攻略推荐：【知识库自托管 02】2026 实测：VPS 自托管 Anythin、【知识库自托管 03】2026 实测：搬瓦工/RackNerd 上自、不写代码也能跑 AI：Flowise 自托管 + Ollama 搭建、老牌但能打：Huginn 自托管自动化代理，RSS 聚合+网页监控实、为什么你的 VPS 账号会被突然封禁？避开 TOS 违规陷阱与退款坑。

为什么要在自己的 VPS 上跑 changedetection.io

很多人第一次听说 changedetection.io，是因为想盯某个商品什么时候降价、某个显卡什么时候补货，或者某个政府/合规页面什么时候悄悄改了字。商业监控服务（Visualping、Distill 之类）免费额度少得可怜，一般就五六个页面、每月几十次检查，真要盯一批 URL 就得月付十几美元。而 changedetection.io 是开源项目，自己托管就能监控无限个 URL、不限检查频率，唯一的成本就是你那台 VPS 的电费（其实也不用电费，是月租）。

到 2026 年这个项目在 GitHub 上已经 32k+ stars，功能早已不只是"对比文本差异"。它支持 Playwright 无头浏览器去抓需要 JS 渲染的动态页面，支持用 CSS 选择器/XPath/JSONPath 只盯页面里你关心的那一块，还支持用 LLM 对变更做摘要，让你推送到手机上的不是一大坨 diff，而是一句话"价格从 899 降到 799"。配合 Telegram、ntfy、Discord 等 90 多种通知渠道，体验完全不输商业服务。最妙的是：它和本站之前介绍过的 Uptime Kuma（盯服务在线状态）是天生互补的一对——一个管"活没活"，一个管"变了没"。

选机器：5 美元小机到底够不够

先说结论：只看静态页面，128MB 内存的机器都能跑；要抓 JS 动态页面，给到 1GB 内存比较稳。官方文档给出的底线是：纯 HTTP 抓取最低约 256MB 内存、1 核 CPU；开了 Playwright 无头 Chrome 后，建议 1GB 内存、2 核。存储也很轻，基础占用约 100MB，加上每个被监控页面每月约 1MB 的历史快照。

所以你要找的，就是那种"便宜、内存还凑合"的入门机。像 RackNerd、Cloudcone 常年有年付十几二十美元、含 1GB 左右内存的小鸡；Bandwagon（搬瓦工）的 CN2 线路机型网络稳，适合监控国内访问友好的站点；预算稍宽一点、想要更稳的 IP 和更高可用性，可以上 Vultr 按小时计费机型，随用随删。这几家里挑一台 1GB 内存的，常年挂着一个监控服务绰绰有余，算下来每天不到一毛钱。

一个实用建议：监控服务最好和你真正在用的业务隔开。拿一台专门的小机挂 changedetection.io，既不会被业务流量影响，IP 被某些电商风控了也不影响主站。多开一台机器的钱，远小于错过一次显卡补货或合规页变更的损失。

一行 Docker 先跑起来

最省事的方式是 Docker 一行命令。先确保机器上装好了 Docker（Debian/Ubuntu 上用官方一键脚本即可），然后：

docker run -d --restart always -p "127.0.0.1:5000:5000" -v changedetection-data:/datastore --name changedetection dgtlmoon/changedetection.io

这条命令做了几件事：-d 后台运行，--restart always 机器重启后自动拉起，-p 127.0.0.1:5000:5000 只监听本机回环地址（强烈建议别直接暴露到公网 0.0.0.0，后面讲安全时再说），-v changedetection-data:/datastore 用命名卷把监控数据持久化。镜像用 dgtlmoon/changedetection.io，也可以换成 ghcr.io/dgtlmoon/changedetection.io:latest。

跑起来后访问 http://你的服务器IP:5000 就能看到控制台。第一件事是去 Settings 里设一个登录密码——默认它是没有任何鉴权的，谁都能进。如果你像上面那样只绑了 127.0.0.1，至少外网进不来；但同机上的其他服务、或者你没设密码就反代到公网，都会出事。设密码是必做的第一步。

用 docker-compose 加 Playwright 抓 JS 页面

很多电商和 SPA（React/Vue 那种）页面，纯 HTTP 抓下来是一堆空壳，价格、库存都是 JS 跑完才填进去的。这时候就要上 Playwright 无头浏览器。官方推荐做法是在 compose 里再起一个浏览器容器，通过 WebSocket 连过去：

version: "3.8" services: changedetection: image: ghcr.io/dgtlmoon/changedetection.io:latest container_name: changedetection ports: - "127.0.0.1:5000:5000" volumes: - changedetection-data:/datastore environment: PLAYWRIGHT_DRIVER_URL: "ws://playwright-chrome:3000" BASE_URL: "http://localhost:5000" depends_on: - playwright-chrome restart: always playwright-chrome: image: dgtlmoon/sockpuppetbrowser:latest container_name: playwright-chrome restart: always environment: SCREEN_WIDTH: 1920 SCREEN_HEIGHT: 1080 MAX_CONCURRENT_SESSIONS: 5 volumes: changedetection-data:

关键就是 PLAYWRIGHT_DRIVER_URL 这个环境变量，告诉主程序去哪找浏览器。容器用 dgtlmoon/sockpuppetbrowser（官方维护的精简版），比第三方 browserless 镜像更省心。compose 起来后，在单个 watch 的"Fetching & Filters"里把 Fetcher 切换成 Playwright，就能抓动态页面了。

注意：开 Playwright 后内存占用会明显上去。1GB 内存的机器，MAX_CONCURRENT_SESSIONS 设小一点（2~5），并用 FETCH_WORKERS 控制并发抓取数，避免 Chrome 把内存吃爆导致 OOM 被系统杀掉。这也是为什么前面强调选 1GB 内存机型而不是 512MB。

还有一个常被忽略的点：监控服务长期运行，系统的 swap 很关键。很多便宜小机默认没开 swap，一旦某个 watch 意外吃内存，没有缓冲就直接触发 OOM。建议给机器加 1GB 左右的 swap 文件，成本为零却能在关键时刻保命。另外，docker-compose 里把数据卷单独挂出来后，记得偶尔备份那个卷——你的监控规则和历史快照都在里面，丢了等于从头再来。这些细节看着琐碎，却是"能不能稳定运行一年"和"跑三天就崩"的分水岭。

配置监控：CSS 选择器盯价格/补货/政策页

不加任何过滤的话，changedetection.io 会对比整页文本，结果就是广告、时间戳、浏览量这些"噪声"天天变，把你淹没在假警报里。正确姿势是用选择器只盯你关心的那一块。

盯商品价格，常见选择器像 .product-price、#price、div.price span.amount；盯库存状态，可以盯那句"有货/缺货"所在的元素，比如 div.stock-status；盯政策页，就只选正文区 article.content 或 #main-content，避开页头页脚。设置入口在每个 watch 的 Filters & Triggers → CSS/JSON/XPath Filter。

不会写选择器？用它的 Visual Selector 工具：在 watch 里点开 Visual Selector，页面加载出来后直接鼠标点你想盯的区域，它会自动生成对应 CSS 选择器，零代码。对电商场景，官方还专门做了"Re-stock & Price detection for single product pages"模式，会去解析页面里的价格/库存元数据，并支持"价格低于 X / 变动超过 Y% / 状态变为有货"才通知，比自己写选择器省事。

检查频率也要讲策略。盯着 flash 补货的显卡可以 5~15 分钟一次；盯政策页一天一次足够。太频繁不仅吃资源，还容易触发对方风控把你的 IP 封了。对那种明显反爬的站点，可以开代理（支持每个 watch 单独配代理）或降到每小时一次。

通知：Telegram 与 ntfy 零成本推送

changedetection.io 用 Apprise 库发通知，支持 90 多种渠道。自托管玩家最爱的两个零成本方案是 Telegram 和 ntfy。

Telegram：先找 @BotFather 建个 bot 拿到 token，再建个频道或私聊拿到 chat_id，然后在 Settings → Notification URLs 里填：

telegram://你的BOT_TOKEN/你的CHAT_ID

变更一发生，bot 就把 diff 推到你 Telegram。想要更干净的体验，可以再接 LLM 摘要，让推送变成自然语言。

ntfy：一个自托管的推送服务，手机装个 ntfy app 订阅某个 topic 就行，完全不用 bot。填法：

ntfy://你的ntfy服务器地址/你的topic名

如果你没自建 ntfy，直接用官方公共服务器 ntfy.sh 也能跑（隐私敏感的场景建议自建）。嫌麻烦也可以只用 Discord webhook 或邮件，但 Telegram/ntfy 在手机上最即时，强烈推荐。

新手最容易踩的坑

  • 不设登录密码：默认无鉴权，直接反代到公网等于把你的监控列表和通知配置拱手送人。务必先在 Settings 设密码。
  • 直接绑 0.0.0.0 暴露公网：上面命令故意写成 127.0.0.1:5000，要外网访问请走反代（Nginx/Caddy）加 HTTPS 和 Basic Auth，别裸奔。
  • 全页对比被噪声刷屏：不加 CSS 选择器，页脚时间戳、随机推荐位天天变，一天几百条假警报。一定先定好"盯哪一块"。
  • JS 页面用错 Fetcher：抓下来是空的还以为是坏了的，其实是没切到 Playwright。动态页面记得开浏览器容器。
  • 频率过高被封 IP：盯着同一站点每分钟刷，IP 很快进黑名单。合理降频或上代理。
  • 数据卷没持久化：忘了挂 /datastore 卷，容器一重建监控配置和历史全没了。compose 里命名卷一定要留。

和 Uptime Kuma 怎么分工

本站之前写过 Uptime Kuma，那是盯"服务在不在、端口通不通、证书快不快过期"的。changedetection.io 管的是另一件事：页面内容变了没。两者互补不冲突。

典型组合：用 Uptime Kuma 盯你的网站、API、各服务存活，用 changedetection.io 盯你关心的外部页面（竞品价格、补货、政策更新）。它们都轻量、都适合塞在同一台便宜小机上，加起来的内存占用也就几百 MB。像 RackNerd、Cloudcone 那种 1GB 内存机型，同时跑 Kuma + changedetection.io + 一个 ntfy，依然游刃有余，真正把"几美元机器"榨出价值。