内网通配符 DNS 服务与 Caddy 反向代理完整笔记

第一部分：nip.io 与 sslip.io 基础

1. 使用背景

在内网环境中，有一台服务器：

Caddy服务器：192.168.10.202

服务器上运行 Caddy，并通过 Caddy 反向代理 Alist：

Caddy
  |
  +-- alist:5244

传统情况下访问 Alist：

http://192.168.10.202:5244

如果希望通过域名访问，例如：

https://192.168.10.202.nip.io

可以使用 nip.io 这种特殊 DNS 服务。

2. nip.io 详解

2.1 基本原理

nip.io 是一个免费的"通配符 DNS"服务，可以把 IP 地址直接写进域名。

例如：

192.168.10.202.nip.io

DNS 会解析到：

192.168.10.202

关系：

192.168.10.202.nip.io
          |
          v
   192.168.10.202

因此可以直接：

ping 192.168.10.202.nip.io

或者：

http://192.168.10.202.nip.io

不需要在 Windows 的 hosts 文件中配置：

192.168.10.202  xxx.example.com

2.2 支持的格式

  • 点号格式：<任何前缀>.<IP地址>.nip.io

    • 例如：app.10.0.0.1.nip.io 会解析到 10.0.0.1

  • 短横线格式：<任何前缀>-<IP地址>.nip.io（此格式尤其适合需要通配符证书的场景）

    • 例如：app-10-0-0-1.nip.io 也会解析到 10.0.0.1

  • 十六进制格式：<任何前缀>-<IP的十六进制>.nip.io

    • 例如：app-0a000001.nip.io 同样解析到 10.0.0.1

2.3 重要说明

nip.io 的原作者已经去世，目前该服务由 sslip.io 托管。

解析规则从左到右读取，例如 1.127.0.0.1.nip.io 会解析到 1.127.0.0，而不是 127.0.0.1。

3. sslip.io 详解

sslip.io 与 nip.io 的核心功能类似。

例如：

192.168.10.202.sslip.io

会解析到：

192.168.10.202

也就是说：

192.168.10.202.sslip.io
          |
          v
   192.168.10.202

常见使用方式：

http://192.168.10.202.sslip.io

sslip.io 是 nip.io 的精神继承者，是目前最直接、最推荐的同类免费服务。它也支持 IPv6，并且可以自建。

4. nip.io 与 sslip.io 对比

项目nip.iosslip.io
核心功能IP → DNSIP → DNS
需要修改 hosts不需要不需要
需要自己搭 DNS不需要不需要
IPv4支持支持
IPv6支持相关形式支持相关形式
内网测试适合适合
Caddy 测试适合适合
HTTPS 测试可以很适合
典型域名192.168.10.202.nip.io192.168.10.202.sslip.io

实际使用中两者都可以。

5. Windows 是否自己支持 nip.io

严格来说，Windows 本身并没有内置 *.nip.io 或 *.sslip.io 的特殊解析规则。

真正提供解析的是 nip.io 和 sslip.io 对应的 DNS 服务。

Windows 只是正常进行 DNS 查询。

例如：

ping 192.168.10.202.nip.io

如果 DNS 查询正常，就会解析成 192.168.10.202。

因此使用起来感觉像 Windows "默认支持"，实际上是 DNS 服务在完成解析。

第二部分：其他内网通配符 DNS 方案

6. traefik.me

一个免费的通配符DNS服务，与 sslip.io 类似，能解析 *.your-ip.traefik.me 到你指定的IP地址。

它最大的亮点是，其网站直接提供了可用于 *.traefik.me 的 Let's Encrypt 通配符证书供下载。这意味着可以在内网部署 HTTPS 服务，而无需像 nip.io + tls internal 那样在每台客户端导入自签名 CA 证书，浏览器会直接信任。

适用场景：希望最快获得浏览器可信任的 HTTPS，同时解决 DNS 和证书信任两个问题。

7. 自建轻量级 DNS 服务器

如果希望彻底摆脱对公网服务的依赖，甚至在内网完全隔离的环境下工作，自建一个 DNS 服务是更彻底的方案。

7.1 sslip.io 自建

sslip.io 本身就是开源的，其源代码和 Docker 镜像都已提供，可以在内网的一台机器上部署自己的 sslip.io 服务。这在完全隔离的环境中尤其有用。

7.2 kissdns

一个用 Rust 编写的轻量级 DNS 服务器，专为开发者设计。它支持通配符解析，而且最大特点是无需 root 权限即可运行，对于权限受限的开发环境非常友好。

7.3 dnsmasq

一个非常流行的轻量级 DNS 转发器和 DHCP 服务器。它可以通过 --address 参数轻松实现泛域名解析，将 *.local 等任意域名的请求都指向一个内网 IP，配置极为简单。是上手最快的自建方案。

8. 其他通用方案

8.1 使用通用 DNS 服务商配置泛解析

如果想为自己的域名实现类似效果，可以利用很多免费 DNS 服务商的功能：

  • Cloudflare：免费计划支持泛解析（即 *.example.com），可以将泛解析记录指向内网或开发 IP。
  • Hurricane Electric DNS、deSEC、ClouDNS 等也提供免费的 DNS 托管服务，可以用来配置泛解析。

8.2 使用动态 DNS (DDNS) 服务

如果需求是让一个变化的公网 IP 始终绑定到一个固定的域名，而不是解析内网 IP，那么 DDNS 服务是更合适的选择，例如 noip.com 等。

9. 内网方案对比

方案内网直接可用是否需要公网是否需要安装客户端 CA配置复杂度
nip.io是是（用于解析）是（使用 tls internal 时）低
sslip.io是是（用于解析）是（使用 tls internal 时）低
traefik.me是是（用于解析）否（证书已受浏览器信任）低
自建 DNS 服务是否取决于是否使用自签名证书中/高
dnsmasq是否取决于是否使用自签名证书低
Cloudflare 泛解析是（需配置）是（需 DNS 服务商）否（可配合 Let's Encrypt）中

第三部分：Caddy 与 HTTPS 配置

10. Caddy 配置 nip.io

当前服务器 IP：192.168.10.202

Alist 容器：alist:5244

如果只是测试 HTTP，可以使用：

http://192.168.10.202.nip.io {
    reverse_proxy alist:5244
}

访问：http://192.168.10.202.nip.io

请求流程：

Windows浏览器
       |
       v
192.168.10.202.nip.io
       |
       | DNS解析
       v
192.168.10.202
       |
       v
     Caddy
       |
       | reverse_proxy
       v
   alist:5244

这个配置本身是正确的。

11. Caddy 与容器网络

Caddy 使用：

reverse_proxy alist:5244

而不是：

reverse_proxy 192.168.10.202:5244

前提是 Caddy 和 Alist 位于同一个 Docker/Podman 网络。

例如：

Podman网络
   |
   +-- caddy
   |
   +-- alist

那么 Caddy 可以通过容器名称 alist:5244 访问 Alist。

12. HTTP 配置

如果只测试 HTTP：

http://192.168.10.202.nip.io {
    reverse_proxy alist:5244
}

浏览器访问：http://192.168.10.202.nip.io

这是最简单的测试方式。

13. HTTPS 配置

如果把 http:// 去掉：

192.168.10.202.nip.io {
    reverse_proxy alist:5244
}

Caddy 会把它当成 HTTPS 站点处理，并可能尝试申请公网证书。

但是对于 192.168.10.202 这种内网 IP，不应该简单认为 Caddy 可以直接获得 Let's Encrypt 公网可信证书。

14. 内网 IP 不能简单申请公网证书的原因

例如 192.168.10.202.nip.io 解析到 192.168.10.202。

虽然 DNS 能正常解析，但 192.168.10.202 是 RFC1918 私有 IPv4 地址。

公网服务器无法直接访问 192.168.10.202:80 或 192.168.10.202:443。

因此 Let's Encrypt 使用 HTTP-01 或 TLS-ALPN-01 验证时，通常无法从公网访问内网 Caddy。

所以 nip.io 能够解析不等于 Let's Encrypt 能够成功验证。这是两个不同的问题。

15. Caddy tls internal

如果目标只是内网 HTTPS，Caddy 自带一个非常方便的方案：tls internal

配置：

192.168.10.202.nip.io {
    tls internal

    reverse_proxy alist:5244
}

这样 Caddy 会使用自己的内部 CA 给这个域名签发证书。

访问：https://192.168.10.202.nip.io 即可使用 HTTPS。

16. 实际测试结果

实际访问后，证书信息中出现 Caddy Local Authority - ECC Intermediate，说明 tls internal 已经正常工作。

链路如下：

浏览器
   |
   v
https://192.168.10.202.nip.io
   |
   v
192.168.10.202
   |
   v
Caddy
   |
   | TLS
   v
Caddy Local Authority
   |
   | reverse_proxy
   v
alist:5244

Alist 可以打开，说明 DNS、Caddy、反向代理基本都已经正常。

17. 浏览器提示"不安全"的原因

虽然 Caddy 已经签发了 HTTPS 证书，但是证书是由 Caddy Local Authority 签发的。

这不是 Let's Encrypt、DigiCert、GlobalSign 等浏览器默认信任的公网 CA。

所以 Windows 浏览器会认为证书链不受信任，因此出现"连接不安全"的提示。

这并不代表 HTTPS 没有工作，而是 HTTPS 工作正常，但 Windows 不信任 Caddy 内部 CA。

18. Caddy 内部证书链

使用 tls internal 之后，证书链通常类似：

192.168.10.202.nip.io
          |
          v
Caddy Local Authority - ECC Intermediate
          |
          v
Caddy Local Authority

其中 Caddy Local Authority 是根 CA，Windows 需要信任这个根 CA。

19. 解决浏览器"不安全"的方法

需要将 Caddy 的 root.crt 导入 Windows。

只需要导入 root.crt，不要导入 root.key，尤其不要把 root.key 复制到普通 Windows 客户端。

20. 从 Caddy 容器获取 root.crt

如果使用 Podman：

podman exec -it caddy sh

查看 Caddy 数据目录：

ls -l /data/caddy/pki/authorities/local/

通常可以看到：

root.crt
root.key

其中 root.crt 是需要安装到 Windows 的证书。

21. 使用 podman cp 导出

可以直接：

podman cp caddy:/data/caddy/pki/authorities/local/root.crt .

执行之后，当前目录应该出现 root.crt。

如果 Caddy 数据目录不是 /data/caddy，需要先确认实际数据目录。

可以使用：

podman inspect caddy

查看容器挂载情况。

也可以检查 Caddy 环境：

podman exec caddy caddy environ

22. Windows 安装 Caddy Root CA

将 root.crt 复制到 Windows。

双击 root.crt，然后选择"安装证书"。

选择"本地计算机"，然后选择"将所有的证书都放入下列存储"，指定"受信任的根证书颁发机构"。

完成安装。

23. 安装后重新打开浏览器

安装完成后，关闭当前浏览器页面，然后重新访问：

https://192.168.10.202.nip.io

如果证书链正确，并且 Windows 已经信任 Caddy Local Authority，浏览器就不会再因为 CA 不受信任而显示"不安全"。

24. 如果使用 sslip.io

同样可以：

192.168.10.202.sslip.io {
    tls internal

    reverse_proxy alist:5244
}

访问：https://192.168.10.202.sslip.io

原理完全相同：

192.168.10.202.sslip.io
          |
          v
192.168.10.202
          |
          v
        Caddy
          |
          v
      alist:5244

第四部分：架构层次与方案对比

25. nip.io / sslip.io 与 HTTPS 的关系

需要明确区分三个功能层次。

第一层：DNS

负责：域名 → IP

例如：

192.168.10.202.nip.io
        |
        v
192.168.10.202

第二层：Caddy

负责：域名 → 后端服务

例如：

192.168.10.202.nip.io
        |
        v
Caddy
        |
        v
alist:5244

第三层：HTTPS

负责：加密 + 证书

例如：tls internal 或者 Let's Encrypt

这三个层次不能混为一谈。

26. 三种典型方案

方案一：hosts + Caddy tls internal

Windows hosts：

192.168.10.202 zdoc.test

Caddy：

zdoc.test {
    tls internal

    reverse_proxy alist:5244
}

优点：完全不依赖公网 DNS

缺点：每台 Windows 都需要修改 hosts

方案二：nip.io/sslip.io + Caddy tls internal

192.168.10.202.nip.io {
    tls internal

    reverse_proxy alist:5244
}

优点：不需要修改 hosts，配置简单，非常适合内网测试

缺点：需要能够正常完成 nip.io 的 DNS 查询，且 Windows 仍然需要信任 Caddy Root CA

这是当前测试环境非常推荐的方案。

方案三：自己的域名 + DNS-01 + Let's Encrypt

例如拥有 example.com，创建 zdoc.example.com。

Caddy 可以通过 DNS-01 方式验证域名。

即使 Caddy 在 192.168.10.202，也可以通过 DNS-01 获得公网可信证书。

结构：

内网Caddy
192.168.10.202
       |
       v
DNS服务商
       |
       v
Let's Encrypt
       |
       v
公网可信证书

这种方案适合长期使用。

27. 三种方案对比

方案内网可用HTTPS浏览器默认信任hosts推荐用途
hosts + tls internal是是否，需要安装 CA需要完全隔离内网
nip.io + tls internal是是否，需要安装 CA不需要快速测试
sslip.io + tls internal是是否，需要安装 CA不需要快速测试
自有域名 + DNS-01是是是不需要长期使用

28. 综合方案对比

方案内网直接可用是否需要公网是否需要安装客户端 CA配置复杂度
nip.io + tls internal是是（用于解析）是低
sslip.io + tls internal是是（用于解析）是低
traefik.me是是（用于解析）否低
自建 DNS 服务是否取决于证书方案中/高
dnsmasq + 自签名是否是低
Cloudflare 泛解析 + Let's Encrypt是是否中

第五部分：总结与建议

29. 当前场景最推荐方案

当前环境：内网 + Caddy + Podman + Alist + 192.168.10.202

如果只是测试，使用 192.168.10.202.nip.io 即可。

Caddy 配置：

192.168.10.202.nip.io {
    tls internal

    reverse_proxy alist:5244
}

然后 Windows：

ping 192.168.10.202.nip.io

确认解析到 192.168.10.202。

再访问 https://192.168.10.202.nip.io。

如果出现 Caddy Local Authority - ECC Intermediate，说明 HTTPS 已经成功。

接下来只需要：

获取 Caddy root.crt
        |
        v
安装到 Windows
        |
        v
受信任的根证书颁发机构
        |
        v
重新打开浏览器

即可解决"不安全"的提示。

30. 最终结论

当前问题可以归纳为：

192.168.10.202.nip.io
        |
        | nip.io DNS
        v
192.168.10.202
        |
        | Caddy
        v
tls internal
        |
        | Caddy Local Authority
        v
HTTPS
        |
        | reverse_proxy
        v
alist:5244

现在 Alist 已经能够打开，并且证书显示 Caddy Local Authority - ECC Intermediate，说明核心配置已经成功。

浏览器显示"不安全"的唯一主要原因是：Windows 不信任 Caddy Local Authority。

解决方法不是修改 nip.io，也不是修改反向代理，而是把 Caddy 的 root.crt 安装到 Windows 的"受信任的根证书颁发机构"。

如果只是内网测试，这是正常且合理的方案。

如果希望以后做到"内网服务 + 自己的域名 + 浏览器默认信任 + 不安装任何客户端 CA"，则应考虑使用自己的域名配合 DNS-01 和 Let's Encrypt，而不是依赖 nip.io + Let's Encrypt 来解决内网 HTTPS。

31. 快速选择指南

需求推荐方案
快速内网测试，能接受安装 CAnip.io 或 sslip.io + tls internal
快速内网测试，希望浏览器直接信任traefik.me
内网完全隔离，无法访问公网 DNS自建 dnsmasq 或 sslip.io 开源版本
长期使用的内网服务自有域名 + Cloudflare 泛解析 + Let's Encrypt
开发环境权限受限kissdns（无需 root 权限）

标签: none

添加新评论