Knock 敲门

外观切换

DDNS 管理 ​

DDNS 适合什么场景 ​

如果你的公网 IP 会变，但你又希望始终通过固定域名访问入口，就适合使用 DDNS。

它解决的问题是：

自动把域名解析更新到当前公网 IPv4 / IPv6。

哪些场景更常用 DDNS ​

子域模式 ​

最常见，也最推荐优先规划。

因为子域模式本质上是：

  • 让域名直接指向你自己的公网 IPv4 / IPv6

只是访问组织方式是：

  • auth.example.com
  • alist.example.com
  • nav.example.com

这类子域。

直连模式 ​

也会用到，但不再建议作为多数新部署的首选。

因为直连模式下，你往往是让域名直接指向自己的公网 IPv4 / IPv6，再由 fknock 负责入口认证和白名单放行。

反代模式 ​

不一定需要。

如果你使用的是：

  • FRP
  • Cloudflared

这类场景通常不是“域名直接指向你家里的公网 IP”，所以反代教程本身一般不把 DDNS 作为前置条件。

页面能做什么 ​

DDNS 管理 页面主要负责：

  1. 选择提供商
  2. 保存提供商配置
  3. 选择更新范围
  4. 指定出站网卡
  5. 手动测试更新
  6. 查看最后一次记录到的 IPv4 / IPv6
  7. 查看更新日志

DDNS 定时任务默认约每 5 分钟 检查一次公网 IP 变化。

支持哪些提供商 ​

已内置多家提供商，包括：

  • Cloudflare
  • 阿里云 DNS
  • 阿里云 ESA DNS
  • 腾讯云 EdgeOne
  • 腾讯云 EdgeOne（CNAME 接入）
  • DNSPod
  • 百度云 DNS
  • 华为云 DNS
  • 腾讯云 DNS
  • GoDaddy
  • NO-IP
  • Porkbun
  • DuckDNS
  • dynv6

也就是说，这页现在已经不是“只给 Cloudflare 准备的附属功能”，而是一套通用 DDNS 管理入口。

最近这 3 类提供商特别值得单独留意 ​

腾讯云 EdgeOne ​

适合：

  • 你的权威 DNS 已经托管到 EdgeOne
  • 你准备让域名直接在 EdgeOne 里完成解析与加速

这一类场景下，fknock 的 DDNS 会直接维护 EdgeOne 站点内的 DNS 记录。

如果你后面还准备把 auth.example.com、alist.example.com 这些子域继续接到 EdgeOne 的代理能力前面，建议配合下面这篇专题页一起看：

腾讯云 EdgeOne（CNAME 接入） ​

适合：

  • 你的权威 DNS 还在其他服务商
  • 你只是把某个业务域名通过 CNAME 接到 EdgeOne 做加速

这类场景和普通 DDNS 有个很大的不同：

  • 它更新的不一定是“公网 DNS 记录”
  • 更常见的是更新 EdgeOne 加速域名背后的源站地址

还要注意一个边界：

  • 腾讯云 EdgeOne（CNAME 接入） 一次只能更新一个源站地址

所以这里更推荐直接把：

  • 更新范围

设成：

  • 仅更新 IPv4
  • 或 仅更新 IPv6

不要继续保留：

  • IPv4 & IPv6

阿里云 ESA DNS ​

适合：

  • 你的域名已经接入 ESA
  • 你希望继续在 ESA 里维护解析记录
  • 你可能还想顺手使用 ESA 的代理能力

如果你准备的不是“只更新解析”，而是“让 ESA 真正站在 fknock 前面做加速与回源”，推荐直接看专题教程：

先理解两个新增选项 ​

更新范围 ​

路径里现在可以直接选：

  • IPv4 & IPv6
  • 仅更新 IPv6
  • 仅更新 IPv4

它控制的是：

  • 本次检测时要不要查 IPv4
  • 本次检测时要不要查 IPv6
  • 最终要不要更新对应的 A / AAAA 记录

最常见的几种用法：

  • 你家宽带是双栈，而且域名希望同时支持两种访问：选 IPv4 & IPv6
  • 你主要靠公网 IPv6 直连：选 仅更新 IPv6
  • 你的提供商或当前链路只想维护 IPv4：选 仅更新 IPv4

如果你把范围切成了 仅更新 IPv6，但机器当前根本没有可用公网 IPv6，那么手动测试会直接报错并终止，这属于正常保护行为。

出站网卡 ​

这也是最近新增的能力。

你现在可以在页面里指定：

  • 自动选择
  • 或明确选某一张实际存在的网卡

它影响的是两件事：

  1. 公网 IP 检测时优先走哪张网卡
  2. 调用 DNS 提供商 API 时优先走哪张网卡

这对下面这些场景尤其有用：

  • 机器上同时有多张物理网卡
  • 既有 IPv4 WAN，又有 IPv6 WAN
  • Docker / 虚拟网卡很多，自动探测容易不符合预期
  • 你明确知道应该从哪条出口链路去更新 DDNS

如果你拿不准，先保持：

  • 自动选择

只有当“检测到的公网地址总是不对”时，再回头指定网卡。

推荐的配置顺序 ​

  1. 先选择提供商
  2. 先决定更新范围
  3. 如有需要，再指定出站网卡
  4. 填完全部字段
  5. 先执行一次测试更新
  6. 成功后再保持自动更新开启

这样做的好处是：

  • 容易分清是配置问题，还是链路问题

子域模式下最常见的一种 DDNS 做法 ​

如果你的域名是：

  • example.com

并且你准备让多个子域都直达公网入口，那么最常见的做法通常是维护：

  • *.example.com

如果你使用的提供商字段名就是：

  • 完整域名

那么也可以直接填写：

  • *.example.com

用来做这一条泛解析记录。

如果你又恰好只有公网 IPv6，那么推荐直接把：

  • 更新范围

改成：

  • 仅更新 IPv6

这样做的好处是：

  1. 不会再为不存在的公网 IPv4 白白做检测
  2. auth.example.com、alist.example.com 这类子域都能统一落到当前 IPv6
  3. 后续申请 *.example.com 证书时，链路也更顺

需要补一句的是：

  • *.example.com 不会覆盖根域 example.com

如果你也要让根域参与访问，通常还需要单独维护根域记录。

使用 DDNS 时最需要理解的 4 件事 ​

1. DDNS 只负责解析，不负责链路是否真的通 ​

即使 DDNS 成功，域名仍然可能打不开，因为后面还有：

  • 7999 是否可达
  • 证书是否正确
  • 模式是否匹配
  • 隧道或映射是否就绪

2. DDNS 可以同时处理 IPv4 和 IPv6 ​

系统会分别检查当前公网 IPv4 和 IPv6，并根据变化决定是否更新对应记录。

3. 手动测试会先做“检测”，再做“更新” ​

测试更新时，系统通常会按这个顺序工作：

  1. 读取当前提供商配置
  2. 根据更新范围决定检测 IPv4、IPv6，还是两者都检测
  3. 按所选网卡去获取当前公网地址
  4. 调用对应提供商 API 更新记录

所以当你在日志里看到：

  • “未检测到 IPv6”
  • “当前配置中的更新范围没有可用地址”
  • “权限不足” 或 “记录更新失败”

它们其实分别对应不同阶段的问题。

4. 日志是排错时最有价值的地方 ​

日志里通常会直接记录：

  • 是否获取到了公网 IP
  • 更新的是 IPv4 还是 IPv6
  • 成功还是失败
  • 错误原因

子域模式里很容易踩的两个误区 ​

误区一：只切了模式，没有把泛解析真的更新出去 ​

子域模式不是只在后台切一下开关就结束了。

如果：

  • auth.example.com
  • alist.example.com

这些子域根本没有正确解析到当前公网入口，那么后面的认证、证书、Passkey 都无从谈起。

误区二：明明只有 IPv6，还保留双栈更新 ​

如果你当前只有公网 IPv6，却还保持：

  • IPv4 & IPv6

那么日志里经常会出现没有必要的 IPv4 探测失败信息，排错时也更容易分神。

手动测试时的排错顺序 ​

如果测试失败，建议这样看：

  1. 有没有获取到公网 IP
  2. 更新范围是否和当前网络能力匹配
  3. 如果机器有多张网卡，出站网卡是否选对
  4. 提供商配置是否完整
  5. Token / Key / Secret 是否填对
  6. 域名是否写成了完整域名

Cloudflare 用户建议先看专题页 ​

如果你使用 Cloudflare，推荐直接配合下面这篇专题页使用：

这页会单独讲清楚：

  • API Token 应该走哪个官方模板
  • Zone ID 该从 Dashboard 的哪个位置复制
  • 完整域名应该怎么填
  • 为什么 7999 直连入口通常应该选 仅解析

相关阅读 ​

QQ群：1081609274

Copyright © fn-knock docs