changedetection.io 5025端口远程访问排错

先把 changedetection.io 在本机的 5025 端口跑通，再设置访问密码，最后按部署环境选择远程入口：有公网 IP 的 VPS 优先使用 Nginx 反向代理，没有公网 IP 的 NAS 再考虑内网穿透，局域网内则可以直接访问。端口映射要分清：5025 是宿主机端口，容器内部监听的是 5000，两者不能混写。

远程开放前，先确认容器正常运行、端口映射存在、本机请求有 HTTP 响应，再逐层检查防火墙、安全组和远程链路；域名、证书和穿透插件放到后面。监控任务与通知也要分开排查：先确认页面确实产生了差异，再检查 Apprise、SMTP、Telegram 或 Webhook 通道。下面的排查沿用 CSDN 教程中的部署、提醒和公网访问链路，按容器、监控任务、通知通道和远程入口逐层展开。

Docker Compose 先跑通 5025

最小可用编排只需要镜像、重启策略、端口映射、数据卷和时区。./datastore 用来保存监控任务、历史快照等数据，重建容器时不能把它换成临时文件系统；TZ=Asia/Shanghai 则用于让容器时间与本地时间保持一致。

services:
  changedetection:
    image: dgtlmoon/changedetection.io:latest
    container_name: changedetection
    restart: unless-stopped
    ports:
      - "5025:5000"
    volumes:
      - ./datastore:/datastore
    environment:
      - TZ=Asia/Shanghai

这段配置里的 5025:5000 表示“宿主机 5025 端口转发到容器 5000 端口”。浏览器访问的是 http://服务器IP:5025，不是 http://服务器IP:5000。如果宿主机 5025 已被占用，只调整映射左侧的宿主机端口，例如改成 5026:5000，容器内部端口仍保持 5000。

上面的 latest 适合首次验证，正式长期运行时更稳妥的做法是固定经过确认的镜像标签或摘要，避免一次拉取就让运行版本发生漂移。固定版本后也应保留 ./datastore，否则升级镜像和重建容器会成为两件互相干扰的事。

启动与验证按下面顺序执行：

docker version
docker compose version
docker compose config
docker compose up -d
docker compose ps
docker compose logs --tail=200 changedetection
docker port changedetection
curl -I http://127.0.0.1:5025

如果旧环境只提供 docker-compose 命令，需要把上述命令换成对应的旧式写法，并先确认 Compose 文件语法仍能被当前版本解析。

排查按容器状态、端口映射和 HTTP 响应逐层进行。docker compose ps 显示容器退出或不断重启时，先看日志；容器正常运行但 docker port 没有 5025 映射，说明问题在 Compose 配置或端口绑定；映射已经存在但 curl 没有 HTTP 响应，则说明应用尚未在容器内正常监听，需要继续检查容器日志。只有本机请求正常而其他机器访问失败，才进入防火墙、安全组或远程入口的排查。

页面添加完成后，也不等于监控已经有效。URL、检查频率和抓取范围需要一起确认。CSS、XPath、JSONPath 过滤适合只盯页面中的一小块内容，例如商品价格、官网公告或接口中的某个字段；过滤范围写错时，目标内容即使已经变化，差异预览也可能没有结果。先在差异预览里确认新增、删除或修改内容，再去检查通知配置。

普通抓取只拿到页面框架、看不到前端渲染出的内容时，才需要考虑 browserless/Playwright。资料中的组合方式是把 PLAYWRIGHT_DRIVER_URL 指向 Compose 内的渲染服务：

services:
  changedetection:
    image: dgtlmoon/changedetection.io:latest
    container_name: changedetection
    restart: unless-stopped
    ports:
      - "5025:5000"
    volumes:
      - ./datastore:/datastore
    environment:
      - TZ=Asia/Shanghai
      - PLAYWRIGHT_DRIVER_URL=ws://playwright:3000/

  playwright:
    image: browserless/chrome
    restart: unless-stopped

服务名与连接地址必须对应：如果 Compose 服务叫 playwright，地址中的主机名就应当是 playwright；如果改名为 browserless，环境变量也要同步修改。端口还要与渲染服务实际监听端口一致。镜像标签和启动参数可能随版本变化，正式启用前应再按当前官方说明核对，不能只复制示例后默认它一定可用。

开放到远程之前还要先处理鉴权。资料所示版本默认没有登录保护，任何能打开页面的人都可能修改监控配置，并让服务抓取其填写的网址。可以先在 Settings 的 Password 项设置访问口令；另一份资料提到 PASSWORD 环境变量，但入口和变量行为需要按当前版本核对，不能假定所有版本都一致。口令只能解决页面访问控制，不能替代 HTTPS。

提醒不响先分辨没变与发不出去

提醒不响时，不要一上来就换邮箱或重建容器。先看差异预览：没有差异说明变更还没有进入通知阶段；已经出现差异，才说明问题位于 Apprise、SMTP、Telegram 或 Webhook 配置及其出站网络。

过滤条件过宽或过窄都可能造成误判。如果监控价格时把整张商品页纳入范围，页面中的库存提示、推荐商品和时间戳可能制造噪声；反过来，只选择价格标签时，如果页面改版导致元素路径失效，监控就会变成“抓取成功但没有目标内容”。出现这种情况，应先检查实际页面结构和选择器，再调整过滤范围。

动态页面没有差异时，还要区分两种情况：页面本来就没有变化，或者浏览器渲染尚未完成。前者只需要等待目标内容真正更新，后者才需要启用 browserless/Playwright，并确认 PLAYWRIGHT_DRIVER_URL 中的服务名和端口与 Compose 一致。

差异已经出现时，再分别检查通知通道。Apprise 可以承接多个通知目标，但每个目标的 URL、凭据和参数必须有效；Telegram 需要核对机器人凭据与目标聊天信息；Webhook 则要核对地址、请求方法和必要的请求头。不要用示例占位符直接发送，也不必在文章中暴露真实 Token。

SMTP 参数必须以邮箱服务商自己的要求为准。资料中的 QQ 邮箱示例使用 smtp.qq.com，端口为 465 或 587，并要求使用 SSL/TLS，同时在邮箱后台开启 POP3/SMTP 服务。这些是 QQ 邮箱的特定参数，不能直接套到其他服务商；其他邮箱的服务器地址、端口、加密方式和授权策略都可能不同。

如果差异存在但通知仍失败，再从宿主机和容器两个层面检查出站网络：域名能否解析，目标端口是否可达，容器日志中是否出现认证、TLS 或连接错误。邮件成功只能证明 SMTP 通道正常，不能证明 Telegram 或 Webhook 也正常；排查时应单独测试每个通道。

远程访问在直连、反代与穿透之间取舍

远程入口可以分成三类：直接映射 5025 适合局域网和临时验证；VPS 上长期使用更适合由 Nginx 监听 80/443，再转发到本机 5025；没有公网 IP 的 NAS 才使用内网穿透。三种方式的成本和故障点不同，不能只比较“哪个地址更短”。

直接映射 5025 的链路最短，适合先确认局域网设备能否访问。但把同一端口暴露到公网意味着绕过 Nginx、证书和更细粒度的访问控制，因此只适合临时测试，并应限制来源范围。正式开放前至少要设置访问口令；条件允许时仍应使用 HTTPS。

VPS 场景下，可以让 Nginx 负责公网入口，Compose 只在本机提供后端服务。下面配置假定 Nginx 与 changedetection.io 位于同一台宿主机：

server {
    server_name monitor.example.com;

    location / {
        proxy_pass http://127.0.0.1:5025;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

应用配置后先验证语法，再重新加载：

sudo nginx -t
sudo systemctl reload nginx

这套结构要求 Nginx 以宿主机进程运行。如果 Nginx 也在 Docker 中，127.0.0.1 指向的是 Nginx 容器自身，此时应改用 Compose 服务名，并让两个容器加入同一网络。正式发布还应按当前 Nginx 与证书工具的官方文档补齐 TLS 配置，而不是直接把示例中的明文 80 端口当成最终入口。

域名访问还需要同时满足三项条件：DNS 正确解析到服务器，云端安全组和主机防火墙允许 80/443，Nginx 能连接后端 5025。只检查其中一层，很容易出现“域名能解析但打不开”或“公网端口已放行但 Nginx 连不上容器”的情况。安全组放行后，主机防火墙仍可能继续拦截。

如果 changedetection.io 与 Nginx 同机运行，还可以把 Compose 映射限制在回环地址：

ports:
  - "127.0.0.1:5025:5000"

这样公网只开放 Nginx 的 80/443，changedetection.io 的宿主机端口不直接暴露。这个写法不适用于放在独立容器中的 Nginx，也不适用于需要从其他宿主机直接连接 5025 的穿透方案。

没有公网 IP 的 NAS 可以使用内网穿透。资料中的飞牛 NAS 示例通过 PassNAT 插件建立隧道，本地端口填写 5025，启动隧道后使用插件给出的公网连接地址。该方案依赖插件登录状态、隧道节点和本地端口是否同时正常；它解决的是网络可达性，不会自动补上 changedetection.io 的访问口令或 HTTPS，因此这些安全配置仍需单独完成。

故障按下面四层定位：