DDNS 与 IPv6 外网访问

公网地址的最后红利

IPv4 公网地址越来越难得，但 IPv6 的公网地址几乎是无限量发放的——绝大多数家庭宽带现在都能拿到一个 IPv6 前缀，每个设备都能分到全球唯一地址。配合 DDNS（动态域名解析），即使前缀每天变化，也能用域名稳定访问家里的设备。这套方案不需要任何中转服务器，直连延迟最低，手机 5G 直连家里 NAS 的体验远好于任何穿透。

确认运营商是否给了 IPv6：光猫直连电脑，或登路由器看 WAN 接口的 IPv6 地址，有公网前缀（不是 fe80 开头的本地地址）就是有。没有的话先别折腾，打运营商客服申请，很多地区是默认开通或可以开通的。注意有些地区只在拨号路由模式下才下发 IPv6 前缀，光猫改桥接自己拨号通常更顺。

前缀下发与内网配置

家里有了 IPv6 前缀，路由器有两个任务：把前缀继续下发给内网设备（SLAAC），以及决定自己的防火墙规则。OpenWrt 默认的 odhcpcd 就能做前缀下发，内网设备会自动拿到地址。问题通常出在两个地方：一些设备（尤其安卓旧版与部分 IoT 固件）对 RA 通告处理不完整，需要把路由器通告的模式调成类 DHCP 的方式；二是部分 ISP 每次拨号都换前缀，地址一变 DNS 记录就过期。

稳定的第一步是让路由器自己跑 DDNS 客户端，前缀一变立刻更新解析。OpenWrt 上常见的方案是 ddns-scripts 配域名服务商的 API（阿里云、DNSPod 都支持），脚本定期检测地址变化并调用 API 更新记录。把域名指向家里的路由器或服务器之后，外网访问就直接落在对应端口上。纯 IPv6 记录要记得只设 AAAA 记录、不要混 A 记录，否则没有 IPv6 的客户端解析到错误记录。

前缀下发还有个稳定性技巧：软路由可以把 WAN 收到的委托前缀委派（PD）分发给下级路由或交换机，让内网每一层都自动得到正确前缀，不用手动写死。前缀换的时候所有设备重新 SLAAC 即可，配合 DDNS 秒级更新解析，整条链路对用户完全透明。家里的固定服务器也可以用 IPv6 后缀（EUI-64 或手工指定后 64 位）来稳定标识——前缀会变，但后缀不变，DDNS 更新时只改前半段，脚本写起来非常省事。

DDNS 的域名与 TTL

DDNS 域名建议单独解析，不要与现有网站的记录混用，便于单独控制 TTL。TTL 是 DNS 记录的缓存时间，设短一点（60 至 300 秒）前缀切换后客户端能更快拿到新地址；设太长则地址变了解析还指向旧的。不过 TTL 太短也会增加解析请求量，对家用无伤大雅，60 秒是折中值。域名服务商之间更新速度也有差异，家里之前是 IPv4 DDNS 的老用户迁移到 IPv6 时不用换域名，加一条 AAAA 记录就行。

脚本与服务的可靠性同样要考虑：把 ddns 服务设为开机自启，更新失败的日志要能在路由器页面看到。不少人的 DDNS 是某次升级后悄悄停掉的，直到远程访问失效才发现。更主动的做法是给 DDNS 加心跳：在云服务器上定时解析自己的域名，拿到的地址与家里 WAN 的实际地址不一致就告警，等出到问题再排查，不如让问题在发生的五分钟内就被你知道。另一个常见误区是把 DDNS 放在光猫上做——光猫固件的更新机制与稳定性都不适合承担关键服务，重启一次配置可能就复位，放自己控制的软路由或小主机上才是长期可控的方案。

防火墙与安全

IPv6 时代每个设备都有公网地址，防火墙的地位比 IPv4 时代更重要——以前内网设备天然藏在 NAT 后面，现在是真的暴露在外。路由器的 IPv6 防火墙默认只允许已建立连接的流量回包，但一旦你为了访问 NAS 放行了一段端口，就把这台机器直接亮在公网扫描器面前。操作原则：放行的端口越少越好，能用非标准端口就别用标准端口，服务本身必须 HTTPS 加口令，管理类端口（如 SSH、面板）不要直接放行。

更稳妥的做法是只允许指定来源访问——知道远程设备大致所在的网段，就只放行那些前缀；或者干脆只放给家里人用：手机 5G 的 IPv6 前缀相对稳定，录入一次管几个月。家庭 IoT 设备的 IPv6 流量则建议默认全部出站放行、入站全部拒绝，避免固件漏洞被外部直接利用。记住 IPV6 的暴露面列表要定期 review，每加一个放行都要想清楚理由，权限只会越积越多。

与穿透方案的搭配

IPv6 直连虽好，但有个现实限制：大量移动网络与公司网络还没有 IPv6，纯 IPv6 的服务从这些环境访问不了。成熟做法是双保险：IPv6 直连做主路径（延迟低、无中转），frp 或组网方案做兜底（兼容无 IPv6 的环境）。两者并存只需要在 DNS 层面想清楚：有 A 记录有 AAAA 记录时客户端会自动选择，不用人工干预。具体到落地，可以把 IPv6 直连用于监控、NAS 同步这类自己人长期使用的场景，而把 frp 与反向代理留给临时设备与公开页面，两者各司其职、互不干扰。

IPv6 的运维还有一个隐形收益：内网设备的地址足够多，任何服务都可以直接分配独立公网地址而不必挤在同一个 80 端口后面。/photos 与 /drive 这类子目录共享一台机器端口的做法可以淘汰，每个服务独占一个地址、独占证书，网段规划与权限分配都更清爽。前提是你的 DNS 记录更新足够勤快，地址迁移的频率要低到不影响使用，所以前缀稳定性是这套玩法的前提。

排查 IPv6 连通性有一套标准动作：先 ping6 测链路、再 dig AAAA 测解析、最后用 telnet 或 curl 测端口。两头的顺序很关键，先确认家里前缀没换、记录更新了，再怀疑防火墙。这些排查手段背后的原理见 计算机网络入门。

真实案例：从 IPv4 到 IPv6 的迁移

给一个完整的迁移过程做参考。某家庭原本用 frp 访问 NAS，装了新的 AP 与手机之后决定拥抱 IPv6：第一步在光猫改桥接、软路由拨号，拨上就看到 WAN 拿到 IPv6 前缀；第二步路由器开 RA 通告，内网设备陆续拿到地址，小米与安卓手机立即生效，一台旧网络打印机没反应（RA 模式调整后也拿到了）；第三步在阿里云的域名解析里加了一条 AAAA 记录，软路由上 ddns-scripts 配好更新脚本，观察前缀变化时记录秒级刷新；第四步防火墙只放行了 NAS 与监控的端口，其他的入站默认拒绝。

迁移完成后的体验差异明显：原先 frp 受云服务器 1 兆管子限制，看视频列表可以、看封面图就卡；IPv6 直连后手机 5G 到家里的延迟约 30 毫秒，播放 NAS 里的 1080p 畅顺。家人在外时通过同样的域名访问，IPv6 走直连、IPv4 设备走 frp 兜底，双记录并存由客户端自动选择，全程无人为切换。

迁移留下的两个教训值得记下来：一是旧客户端的兼容性预判不足，两台只有 IPv4 的旧设备访问家庭服务时绕了好几天，最后给 frp 链路保留下来才解决；二是防火墙规则在第一次前缀变化时出现漏洞——旧规则按地址写的，地址变化后规则失效，之后全部改写成按网段与接口匹配，算是把 IPv6 的动态性刻进了规则设计里。

给准备迁移的读者一张 checklist：确认运营商是否下发前缀、确认光猫桥接还是路由模式、确认 DNS 服务商支持 API 更新、确认所有客户端的 IPv6 支持、确认防火墙规则按前缀段而非具体地址写。五项全部打钩再动手，迁移会平稳得像换了条网线。

迁移前的自检清单

迁移与日常运维 IPv6 时记住一个对照原则：把 IPv6 链路当作“第二条独立的家庭宽带”来管理——它有自己的前缀、自己的 DNS 记录、自己的防火墙规则、自己的监控。心理模型清晰了，排错时就不会把两条链路的问题混在一起。所有为 IPv4 建立的运维脚本、监控指标、告警规则，给 IPv6 重复一份，这套基础设施就是完整的。

与运营商打交道的经验

申请 IPv6 或修复线路时，几句准确的描述能让效率翻倍：报障说“网页打不开”不如说“光猫注册灯正常、拨号成功、IPv6 前缀拿不到”；申请 IPv6 直接说“我家路由器支持 IPv6，麻烦开通一下前缀下发”。大部分客服对准确的技术描述响应更快，少数情况会要求你把光猫改桥接后重试——这本来就是你应该做的。把这些沟通要点存在备忘录里，下次张口就有。

延伸阅读

• 计算机网络入门：IPv6 前缀、RA 与防火墙规则的基础概念。
• SSH 远程登录与加固：IPv6 暴露之后 SSH 的加固尤为重要。