企业官网建设流程全解析

1. 先把需求掰开：DuckDNS 在家庭网络里到底干什么活

用 Docker 搭 DuckDNS 这件事，表面上看只是跑一个几十兆的小容器，实际上它解决的是一类很常见的家庭网络痛点：你家里那台 NAS、软路由、监控录像机、自建的小服务，想从外面访问，可运营商给你的公网地址每隔一段时间就变一次，今天记下来的地址明天就失效。动态 DNS 就是拿来对付这个问题的。DuckDNS 是一个免费的动态 DNS 服务商，给你一个xxx.duckdns.org的子域名，并提供一套极其简单的 HTTP 接口，让设备在地址变化时主动去更新解析记录。用 Docker 跑它，就是把"定期查自己的公网地址、发现变了就调接口更新"这个动作打包进一个长期运行的容器里，不用碰宿主机的系统服务，也不用担心脚本被系统升级冲掉。

这篇文章面向的是手上有家庭服务器、NAS、软路由或者闲置小主机，想给自己搭一个稳定可访问入口的人。你可能已经试过手动改解析、用过路由器自带的 DDNS 功能但发现它只支持那几家固定的服务商，也可能压根没接触过动态 DNS，只是听说"把域名指到家里 IP 就能远程访问"。不管属于哪一种，下面这套东西都能直接抄。我会把镜像选型、参数计算、IPv6 的特殊处理、日志验证和一堆实际踩过的坑都摊开讲，重点不在"命令怎么写"，而在"每个参数为什么这么填"。

需要先说明一点：DuckDNS 在这里的角色只是"把域名和你的公网地址绑定起来"，它本身不提供任何隧道或中转能力，能不能从外面访问到，最终取决于你的网络环境是否具备可被外部访问的地址。这一点在动手之前必须想清楚，否则容器跑得再漂亮，外面照样连不上。

1.1 动态 IP 的麻烦与 DDNS 的本质

家里的宽带地址是"租"来的，租期到了或者光猫重启，运营商就可能换一个给你。对普通上网毫无影响，但如果你在外面想连回家里，就得知道那个地址是多少。手动记、手动改，一次两次还行，长期这么干必然崩盘——你可能正在外地出差，需要连回家里取一份文件，结果发现地址早变了，人在千里之外毫无办法。

DDNS 的思路朴素得不能再朴素：让家里一台常开的设备，每隔几分钟去问一句"我现在的公网地址是多少"，拿到结果后跟域名服务商那边记录的旧值比一比，不一样就调接口改掉。整个过程是设备主动往外发请求，不需要任何入站端口，也不需要外部服务器反过来探测你。这就决定了它天然适合跑在资源极小的环境里：一次请求几十字节，一天下来也就几百次，对 CPU 和带宽的消耗可以忽略不计。

理解了这个本质，后面所有参数的意义就都清楚了。更新间隔决定了"地址变了之后多久能被发现"，太长会出现一段时间的访问空窗，太短则是对服务商接口的无谓骚扰；检测地址的方式决定了在双栈环境下到底更新的是 IPv4 记录还是 IPv6 记录；日志和验证手段决定了你能否在出问题时第一时间判断是"地址没变"还是"请求失败了"。

还有一点容易被忽略：DDNS 只负责"名字到地址"的映射，它不解决"地址能不能被访问"的问题。如果你拿到的是运营商大内网地址，域名解析得再准，外面也连不进来。所以正确的顺序是先确认网络条件，再谈部署，这个顺序我在第二节会展开。

1.2 为什么是 DuckDNS：免费、接口简单、支持 AAAA

市面上做动态 DNS 的服务不算少，路由器固件里内置的那几家、各家域名注册商自带的、还有一些开源方案。选 DuckDNS 主要看重三点。

第一是接口简单到极致。它不需要你装任何客户端，不需要复杂的鉴权握手，就一个 GET 请求，把子域名、令牌和地址拼在查询串里发过去，返回OK或KO两个单词。这意味着你可以用 curl、用 wget、用 Python、用 shell，甚至用浏览器地址栏都能完成更新。对于容器化部署来说这是巨大的优势——镜像可以做得很小，逻辑可以做得很薄，出问题时排查路径极短。

第二是免费且支持 AAAA 记录。很多免费 DDNS 服务只给你更新 IPv4 的 A 记录，而现在不少家庭宽带已经能拿到 IPv6 前缀，把 AAAA 记录一起维护起来，远程访问的体验会好很多。DuckDNS 的接口允许你在一次请求里同时带上 IPv4 和 IPv6 地址，也允许只更新其中一个。

第三是域名格式固定、够短。xxx.duckdns.org这种结构没有花哨的层级，记忆成本低，配置到各种客户端里也不容易出错。缺点是域名不属于你，服务方哪天调整策略你只能跟着走，所以它更适合做"家庭内部访问入口"这类用途，不适合承载关键业务。

需要提醒的是，DuckDNS 对更新频率是有约束的。它没有明面上写死一个硬性频率上限，但接口层面的滥用检测是存在的，短时间内高频刷请求可能触发限制，导致更新失败。这就引出后面关于更新间隔的讨论——不是越勤越好。

1.3 为什么用容器跑，而不是装在路由器或宿主机

路由器自带的 DDNS 功能是最省事的选择，但限制也很明显：支持的服商名单是固件写死的，DuckDNS 不一定在里面；就算支持，更新间隔、IPv6 处理、日志输出基本都不可调，出问题只能干瞪眼。更麻烦的是路由器资源紧张，某些固件的 DDNS 组件在地址频繁变化时会漏更新，你还查不到原因。

直接装在宿主机上写个 cron 脚本也行，但会带来另外一些问题。脚本分散在系统各处，换机器要重新配一遍；依赖系统的 curl 版本和 cron 实现；系统升级时可能被覆盖或者因为 PATH 变化失效；日志混在 syslog 里，排查时翻半天。

容器的好处在于把"这一件事"完整地封起来了。镜像里带什么工具、脚本怎么写、多久跑一次、日志往哪输出，全在编排文件里写清楚，换台机器把 compose 文件拷过去就能复现。容器重启策略可以设成 always，宿主机断电恢复后自动拉起来，不需要额外配置。日志用docker logs一条命令就能看，也可以直接接到统一的日志收集里。资源限制也好办，给它 64M 内存、0.1 个 CPU 都嫌多，实际上它绝大部分时间在睡觉。

还有一层考虑是可替换性。今天用 DuckDNS，明天想换成别家，只要接口逻辑类似，改几行环境变量或者换个镜像就行，宿主机上不会留下任何残留文件。这种"随时能推倒重来"的清爽感，是我后来把家里所有常驻小服务都容器化的主要原因。

2. 开工前的三件事：账号、Token、网络前提

很多人一上来就复制粘贴docker run，跑完发现日志里全是KO，然后开始怀疑镜像有问题。实际上大部分失败都发生在容器启动之前——要么令牌拿错了，要么根本没搞清楚自己有没有可用的公网地址。这一节把动手前必须确认的东西列清楚，能省掉后面一大半的排查时间。

2.1 域名与 Token 的获取

先去服务方站点注册账号，登录方式支持几种常见的第三方账号，也可以直接用邮箱。登录之后在页面上创建一个子域名，比如填myhome，那你最终拿到的完整域名就是myhome.duckdns.org。同一个账号下可以建多个子域名，免费额度够普通家庭用，但别指望拿它做批量业务。

页面上会显示一串 Token，这就是你的凭证，作用等同于密码。容器里配置的就是这个 Token，请求接口时带上它，服务端才知道是你在更新自己的域名。Token 泄露的后果是别人可以把你的域名指向任意地址，所以别把它提交到公开的代码仓库里。我的做法是把 Token 写进.env文件，.gitignore里排除掉，仓库里只放一个.env.example说明需要填哪些字段。

创建完域名之后，页面上通常会立刻显示当前的解析结果，这时候还没配置任何更新，记录可能是空的或者指向一个占位地址，属于正常现象。等你把容器跑起来、第一次更新成功后，这里才会显示你真实的公网地址。

另外要留意子域名的写法。有些镜像的环境变量要求填裸名字（不带.duckdns.org后缀），有些允许填完整域名，混着填会导致请求参数错误，返回KO。这一点在选镜像的时候要看清说明，我下面给的示例统一用裸名字。

2.2 先别急着敲命令：确认你手上是不是公网地址

这是最关键的一步，也是最容易被跳过的一步。判断方法很直接：登录光猫或者路由器的管理页面，看 WAN 口拿到的地址是什么。如果这个地址落在几个常见的私有网段里（比如10.开头、172.16到172.31开头、192.168.开头），或者落在一百开头的运营商级 NAT 保留段里，那说明你拿到的是内网地址，外面根本无法直接访问。

这种情况下把 DuckDNS 配好，域名能正常解析到那个内网地址，但从外网访问一定是失败的。你会看到解析没问题、ping 不通、端口连不上，然后误以为是防火墙的问题，实际方向从一开始就错了。

遇到这种网络条件，思路要转向别的方向：要么联系运营商申请可用的公网地址（部分地区对家庭宽带提供这项服务，具体政策各地不同，需要自行咨询），要么放弃"直接连回家"的路径，改用中转或者内网穿透类的方案。这些方案超出了本文的范围，但要明确一点：DDNS 在这类场景里只能解决"名字"的问题，解决不了"可达性"的问题。

如果你确认 WAN 口拿到的是公网地址，那还有第二道关卡：光猫是不是做了路由模式。很多家庭是光猫拨号、路由器二级路由，这时候路由器 WAN 口拿到的是光猫下发的内网地址，真正有公网地址的是光猫。需要把光猫改成桥接、由路由器拨号，或者在光猫上做端口映射，具体怎么操作取决于设备型号。这一步不做，DDNS 更新上去的地址是路由器的内网地址，同样没用。

2.3 IPv6 场景的前置检查

如果你的网络支持 IPv6，情况会稍微复杂一点，但同时也更有价值——每个设备都能拿到独立的地址，不需要做端口映射，理论上减少了一层转发。

先在宿主机上执行ip -6 addr看看有没有拿到全局地址（scope global开头的，2001:、240e:、2408:之类的前缀）。如果只有fe80::开头的链路本地地址，说明 IPv6 没通，需要检查光猫和路由器的相关设置是否开启。

拿到地址之后还要确认一件事：这个地址是"稳定"的还是"临时"的。现在主流系统默认启用隐私扩展，会生成一个定期变化的临时地址用于对外连接，同时保留一个基于 MAC 或者稳定标识的固定地址。你需要更新到 DNS 里的应该是那个固定的，不是临时的，否则记录会跟着临时地址一直变，等于白折腾。判断方法是看地址后面的标记，带temporary或dynamic字样的要留意。

宿主机上可以用curl -6类的命令测试一下出站 IPv6 是否可用。如果容器所在的网络没有配置 IPv6，容器内部拿不到 IPv6 出口，那么自动检测出来的地址会是空的，更新请求里 IPv6 字段也就填不上。这种情况要么给容器网络开启 IPv6 支持，要么改成手动指定地址的方式，后者在地址变化时需要额外机制去触发更新，不如前者省心。

3. 容器方案落地：两条路线任选

准备工作做完，可以开始动手了。这里给两条路线：一条是用现成镜像，配置几个环境变量就能跑；另一条是自己写一个极简的循环脚本，塞进基础镜像里。前者胜在省事，后者胜在完全可控、没有任何黑盒。两条路线我都长期用过，各有适用场景。

3.1 路线一：开箱即用的现成镜像

社区里有维护得比较成熟的 DuckDNS 镜像，最常被提到的是linuxserver/duckdns。它的做法是容器启动后按设定的间隔循环调用接口，环境变量控制子域名、令牌和间隔。一条命令就能拉起来：

docker run -d \ --name=duckdns \ --restart=always \ -e PUID=1000 \ -e PGID=1000 \ -e TZ=Asia/Shanghai \ -e SUBDOMAINS=myhome \ -e TOKEN=你的令牌 \ -e UPDATE_INTERVAL=5m \ -e LOG_FILE=false \ linuxserver/duckdns:latest

几个参数逐一解释。SUBDOMAINS填裸子域名，多个用逗号分隔，注意不要带空格，也不要在末尾带duckdns.org。TOKEN就是页面上那串凭证。UPDATE_INTERVAL控制循环间隔，支持5m、1h这种带单位的写法，具体支持哪些单位以镜像文档为准，保险起见用分钟级写法。LOG_FILE设成false表示日志只输出到标准输出，这样docker logs能直接看到，不需要额外挂载日志卷。

PUID和PGID是这类镜像的通用参数，用于指定容器内进程的运行用户，避免以 root 身份跑。这个镜像本身不做文件写入的话，这两个参数的实际影响不大，但保持习惯填上没坏处。TZ设成你所在时区，日志时间戳才对得上，排查时不用心算时差。

这里必须强调--restart=always。DDNS 容器的价值在于"永远在线"，宿主机重启、Docker 服务重启、容器因为某种原因退出，都需要它自动回来。少了这个参数，某次意外之后你可能几周都没意识到更新已经停了，直到某天在外面连不上才发现。

3.2 路线二：自己写循环脚本，完全可控

现成镜像虽然方便，但它的行为对你来说是个黑盒：什么时候检测、检测到多个地址怎么选、失败了重试几次、日志打得多细，都不由你决定。如果你对更新逻辑有特殊要求，比如"只在地址真的变化时才发请求"，或者想在更新成功后触发别的动作，自己写一个更踏实。

思路是找一个带 curl 的极简基础镜像，把脚本挂进去，用while循环加sleep实现定时。脚本大概长这样：

#!/bin/sh set -u DOMAIN="myhome" TOKEN="你的令牌" INTERVAL=300 LAST_V4="" LAST_V6="" while true; do V4=$(curl -4 -s --max-time 10 https://api.ipify.org || true) V6=$(curl -6 -s --max-time 10 https://api64.ipify.org || true) if [ "$V4" = "$LAST_V4" ] && [ "$V6" = "$LAST_V6" ]; then echo "$(date '+%F %T') 地址未变化，跳过" else RESP=$(curl -s --max-time 15 \ "https://www.duckdns.org/update?domains=${DOMAIN}&token=${TOKEN}&ip=${V4}&ipv6=${V6}") echo "$(date '+%F %T') v4=${V4} v6=${V6} resp=${RESP}" if [ "$RESP" = "OK" ]; then LAST_V4="$V4" LAST_V6="$V6" fi fi sleep "$INTERVAL" done

这段脚本有几个设计点值得说。第一，先查地址再决定要不要发更新请求，这是减少接口调用的关键——地址没变的时候一个更新请求都不发，只在本地比对，既省事又不容易触发服务方的频率限制。第二，两个地址查询分别用-4和-6强制走对应协议，避免解析结果不确定导致查出来的地址不符合预期。第三，只有返回OK才更新本地缓存值，失败的话下一轮还会重试，不会因为一次网络抖动就把错误状态记下来。

--max-time参数也別省。默认情况下 curl 可能卡很久，一轮卡住整个循环就停了，下一轮要等到超时结束才开始，中间的空窗期可能很长。给它一个明确的超时上限，失败就快速失败，下一轮重新来。

把脚本挂进容器的 compose 写法：

services: duckdns: image: alpine:3.20 container_name: duckdns restart: always environment: - TZ=Asia/Shanghai volumes: - ./update.sh:/update.sh:ro command: ["/bin/sh", "-c", "apk add --no-cache curl && sh /update.sh"]

alpine镜像本身不带 curl，所以启动命令里先装一下。这样每次容器重建都会重新装，稍微慢几秒，但镜像体积小、依赖干净。如果你介意每次装，可以自己基于 alpine 打个镜像，把apk add放进 Dockerfile，构建一次之后启动就是秒级。

3.3 用 compose 固定下来，别用裸 run

不管选哪条路线，都建议用 compose 文件而不是一长串docker run。原因很实际：那串命令你三个月后肯定记不住，参数错了要重新翻文档；compose 文件是文本，可以放进版本管理，可以写注释说明每个参数的来由，换机器时拷过去docker compose up -d就完事。

compose 里还有几个细节值得加上。资源限制可以写mem_limit: 64m，防止某种异常情况下进程吃内存；logging段可以限制日志文件大小，避免长期运行把磁盘写满（这个容器日志不多，但习惯性配上）：

logging: driver: json-file options: max-size: "10m" max-file: "3"

restart: always和container_name都写上，前者保证自动恢复，后者让你敲docker logs duckdns的时候不用先docker ps查名字。这些看起来是小事，但在真正需要排查问题的深夜里，少一步操作就是少一分烦躁。

4. 参数背后的账：更新间隔、TTL 与请求量

容器跑起来只是开始，能不能长期稳定运行，取决于几个参数选得对不对。这部分没有标准答案，得根据自己的网络状况和服务方的约束来算。我把计算过程和取舍逻辑摊开讲，你可以照着套。

4.1 更新间隔到底设多少

先算一笔账。假设间隔设成 5 分钟，一天就是 288 次。但注意，前面脚本的设计是"地址没变就不发请求"，实际发出去的请求数取决于地址变化的频率。普通家庭宽带可能几天甚至几周才变一次，那么实际请求量可能一天就几次。只有在地址频繁变化的场景下（比如某些地区的地址租期很短），请求量才会上去。

那间隔设短有什么坏处？主要是两点。一是无谓的地址查询请求，虽然查 IP 的服务通常不限流，但频繁调用也不礼貌。二是如果脚本设计成"每次都直接调更新接口"（不走本地比对），高频调用确实可能触发服务方的滥用检测，导致一段时间内更新被拒。这就是为什么我坚持在脚本里加本地比对。

反过来，间隔设太长的问题很直接：地址变了之后，域名还指向旧地址，这段时间内外网访问全部失败。如果你正好在这段时间要连回家取东西，那就是纯粹的抓瞎。5 分钟是一个比较平衡的值——最坏情况下有 5 分钟的访问空窗，对绝大多数家庭用途可以接受。

如果你的用途对可用性要求更高，比如家里有需要持续在线的服务，可以缩到 1 到 2 分钟，同时确保脚本做了本地比对，避免真的高频刷接口。如果你的用途很松散，比如只是偶尔看看家里的摄像头，10 分钟甚至 15 分钟也完全够。别为了"看起来更实时"就设成 30 秒，收益极小，风险反而增加。

还有一点：容器刚启动的时候应该立即执行一次检测，而不是先睡一个间隔。否则每次重启都要等 5 分钟才有第一次更新，宿主机重启后这段时间就是空窗。前面那个脚本天然满足这一点（循环体先执行后 sleep），用现成镜像的话留意一下它的启动行为，多数实现是启动即跑一次。

4.2 一次请求里带哪些参数

接口的参数不多，但每个都有讲究。domains是子域名，不带后缀；token是凭证；ip填 IPv4 地址；ipv6填 IPv6 地址。关键在于：这两个地址字段留空和不填是两回事。

如果ip参数留空（即&ip=），服务端会尝试从请求的来源地址推断你的公网 IPv4，然后更新 A 记录。这在容器只有一个出口、且出口就是你想暴露的那个地址时很方便。但容器环境里出口地址不一定等于你想对外发布的地址——比如宿主机有多张网卡、容器走了某条特定路由，推断出来的可能不是你想要的。

ipv6同理，留空时服务端会尝试从来源地址推断，而如果你的容器压根没有 IPv6 出口，这个推断会失败。有些实现会因此把 AAAA 记录清空，这就比较尴尬了——你本来只是想更新 IPv4，结果把好好的 IPv6 记录搞没了。

所以我的建议是：明确指定，不依赖推断。脚本里查到的地址直接填进参数，查不到就把对应字段整个省略（注意是省略这个参数，不是传空值）。这样行为完全可预测，不会出现"以为在更新 A 记录，结果把 AAAA 也动了"的情况。

# 只更新 IPv4 curl -s "https://www.duckdns.org/update?domains=${DOMAIN}&token=${TOKEN}&ip=${V4}" # 同时更新 v4 和 v6 curl -s "https://www.duckdns.org/update?domains=${DOMAIN}&token=${TOKEN}&ip=${V4}&ipv6=${V6}"

另外，接口还支持一个清除记录的操作（把地址字段设成特定值），这个平时用不到，但换设备或者迁移的时候可能用得上。具体用法查一下官方文档就行，我不建议在自动化脚本里带这个逻辑，误触的代价太大。

关于 TTL，DuckDNS 那边给的解析记录的 TTL 通常比较短（几十秒到几分钟），这是为了让地址变化后能尽快生效。这个值你不用管，也没法调。但你要知道它的含义：如果 TTL 是 60 秒，意味着各地的递归解析服务器最多缓存 60 秒，之后会重新查询。也就是说，你更新完记录之后，最快几十秒、最慢几分钟，外部访问就会走新地址。做验证的时候要给这个缓存留出时间，别刚更新完就立刻测，测不通就以为失败了。

4.3 日志怎么看才知道真的生效了

日志是唯一可信的验证依据，别靠"感觉应该好了"。容器跑起来之后，先docker logs -f duckdns盯一会儿，正常输出大概是每轮一行，包含时间戳、检测到的地址和接口返回。看到resp=OK才算真的更新成功，看到KO就要查原因。

KO的常见原因就那么几个：令牌错了、子域名写错了（带了后缀或者拼错）、请求格式有问题、服务端那边临时故障。前三个是配置问题，改完重启容器就行；第四个只能等。如果连续多轮都是KO，先手工在浏览器里把完整的请求地址拼出来访问一次，看返回什么，能快速区分是配置问题还是网络问题。

日志里还有一类容易被忽略的信息：地址查询失败。如果查 IP 的服务超时或者返回空，日志里会出现v4=后面是空的，这种行不会有OK，说明这一轮根本没发更新请求。偶尔一次无所谓，但如果连续很多轮都这样，说明容器出网有问题，得查 DNS 或者网络策略。

除了看日志，还要做外部验证。用dig或者nslookup查一下域名解析结果，跟日志里记录的地址对一下：

dig +short myhome.duckdns.org A dig +short myhome.duckdns.org AAAA

如果查出来的地址跟日志里一致，说明整条链路通了。如果不一致，可能是 TTL 还没过、本地 DNS 有缓存，或者更新其实失败了但日志显示成功（这种情况极少，通常是查了不同的记录类型）。验证的时候最好换一个网络环境或者用公共解析服务指定查询，避免被本地缓存误导。

最后是一个长期观察的习惯：每隔一段时间（比如一个月）回来看一眼日志，确认容器还在正常轮转。DDNS 这类服务的可怕之处在于它"平时不出声"，出问题时你可能很久都发现不了，等真正需要远程访问的时候才发现早就挂了。可以在监控系统里加一条检查，比如每隔十分钟解析一次域名，跟预期的地址比对，不一致就告警。这套东西稍微多花点功夫，但能让你对家里的入口有真正的掌控感。

5. 常见问题排查实录

前面讲的都是"顺利情况下的正确做法"，实际动手时几乎不可能一路顺风。这一节整理我从第一次配置到现在积累下来的问题清单，按现象分类，附上排查路径。表格用来快速定位，后面几段展开讲几个特别典型的坑。

5.1 快速对照表

5.2 几个我实际踩过的坑

第一个坑是子域名格式。我第一次配置的时候，把完整的myhome.duckdns.org填进了SUBDOMAINS，镜像原样拼进请求，服务端当然不认，返回KO。日志里就那么一个单词，什么提示都没有，我盯着看了半小时才反应过来。后来养成习惯：填之前先在页面上确认一下子域名到底是什么，是裸名字还是完整域名，镜像文档怎么要求的就怎么填，别想当然。这个问题在换镜像时特别容易复发，因为不同实现的约定不一样。

第二个坑是 IPv6 记录被莫名清空。有一段时间我发现 AAAA 记录老是消失，日志里显示更新成功，但查出来就是没有。原因是脚本里把ipv6参数一直带着，而某些时候 IPv6 地址查询失败返回空，请求就变成了&ipv6=，服务端理解为"清空这条记录"。改成"查不到就整个省略这个参数"之后问题消失。这个教训很值钱：在接口调用里，空值和缺省值经常是两种不同的语义，写自动化脚本时必须区分清楚。

第三个坑出在验证环节。有一次更新完之后，我在本地用dig查，结果一直是旧地址，折腾了快一个小时，怀疑是接口坏了。后来换了个网络环境一查，新地址早就生效了，纯粹是本地 DNS 缓存的问题。这件事之后我给自己定了规矩：验证解析结果时一定要指定公共解析服务，或者干脆用手机流量测，不要相信本机的缓存。

第四个坑和容器重启有关。有一回宿主机做系统更新重启，起来之后我没检查，过了两周想连回家才发现连不上，一看容器根本没起来——当初跑的时候忘了加restart参数。从此以后所有需要长期在线的容器，我都在 compose 里写死restart: always，并且定期用一条命令扫一遍所有容器的重启策略，确认没有被漏掉的。

第五个坑比较隐蔽：地址其实变了，容器也检测到了，但更新请求发不出去。查日志发现每隔一段就有一条超时记录。原因是容器所在的网络在某个时间点出了 DNS 解析问题，查 IP 的域名解不出来。这种问题的表现是"偶尔失败"，很容易被当成服务端的锅。排查方法是进容器手动跑一次curl -v，看卡在哪一步。如果是 DNS，给容器配一个稳定的解析服务就能解决。

5.3 长期运行的稳定性维护

容器跑起来之后，维护成本其实很低，但有几个动作值得定期做。

一是检查容器状态和运行时长。docker ps看一眼STATUS列，如果显示的是几分钟而不是几天几周，说明它最近重启过，得看看为什么。频繁重启往往意味着脚本里有未处理的异常，或者基础镜像的某个依赖在特定情况下失败。

二是定期翻日志。不用天天看，一两周扫一眼，确认输出还是规律的、没有突然变成一片错误。日志里如果出现连续多轮的失败，哪怕后来恢复了，也值得查一下当时发生了什么——可能是网络抖动，也可能是服务方那边做了调整。

三是关注地址变化的频率。如果你发现日志里地址几乎每天都在变，那更新间隔就得重新评估，可能需要缩短到 2 到 3 分钟，否则空窗期占比会很高。反过来，如果几个月都不变一次，间隔设长一点也无所谓，甚至可以放宽到 15 分钟，减少无谓请求。

四是把配置纳入版本管理。compose 文件、脚本、.env.example都放进仓库，Token 单独放不进仓库。这样换机器、重装系统、或者若干年后想回顾当初怎么配的，都有据可查。我自己就遇到过一次，隔了一年多要迁移到新设备，翻出仓库里的文件，十分钟就恢复了，不用重新摸索。

最后说一个我个人在实际操作中的体会：这类"基础设施型"的小服务，配置的时候多花二十分钟把参数想清楚、把日志验证做扎实、把重启策略和资源限制配好，后面能省掉大量的救火时间。反过来，图快复制粘贴一条命令跑起来，当时是省事了，但出问题时你连从哪查起都不知道。DDNS 这东西平时完全感觉不到它的存在，只有在你真正需要远程访问的那一刻，它是否可靠才会体现出来——而那一刻，往往是你最没有条件去修它的时候。