自托管服务域名解析实战：Split DNS与Tailscale方案详解

家庭实验室玩家的经典域名访问难题

在搭建家庭服务器（Home Lab）的过程中，几乎每个人都会遇到同一个痛点：如何用 jellyfin.example.com 这样简洁的域名访问自己的服务，而不是每次都去记忆 192.168.x.x:8096 这样的 IP 加端口号组合？

近期 Reddit 上一位用户的提问精准地击中了这个痛点。他的现状是：使用 Cloudflare 将域名指向本地 IP，再通过 NPM（Nginx Proxy Manager）签发并配置通配符证书。这套方案在家里工作得很好——前提是关闭 Cloudflare 的代理（橙云）功能。但问题随之而来：当他通过 Tailscale 连接家庭网络时，这些域名却无法解析了。

Nginx Proxy Manager（NPM）是一个基于 Nginx 的反向代理管理工具，提供了直观的 Web 界面来管理代理规则和 SSL 证书。反向代理的核心作用是接收外部请求，根据域名或路径规则将其转发到后端不同的服务。例如，NPM 监听 443 端口，当收到发往 jellyfin.example.com 的请求时转发到 192.168.1.100:8096，收到 audiobooks.example.com 的请求时转发到 192.168.1.100:13378。这样用户只需记住域名，无需关心端口号。NPM 还集成了 Let's Encrypt，支持自动签发和续期 SSL 证书，包括通过 DNS-01 验证方式签发通配符证书（*.example.com），为所有子域名提供 HTTPS 加密。

他的核心诉求非常明确：暂时不想把所有服务暴露到公网（安全知识储备不足），但希望无论身处家庭内网还是通过 Tailscale 远程连接，都能用同一个域名顺畅访问服务。

问题根源：DNS解析路径在不同网络下的割裂

要理解"在家能用、Tailscale 下失效"的现象，需要先看清 DNS 解析在两种网络环境下的差异。

家庭内网中为什么能正常工作

当你在家庭网络中访问 audiobooks.example.com 时，DNS 查询最终会解析到你在 Cloudflare 配置的本地 IP（例如 192.168.1.100）。因为你和服务器处于同一个局域网，这个内网 IP 是可达的，所以一切正常。

这也解释了为什么必须关闭 Cloudflare 代理——一旦开启橙云，流量会先经过 Cloudflare 的服务器，而 Cloudflare 无法访问你的私有内网地址。具体来说，Cloudflare 的橙云（Proxied）模式是其核心功能之一：当开启橙云时，域名的 DNS 记录不会直接返回你的源服务器 IP，而是返回 Cloudflare 边缘节点的 Anycast IP 地址。所有流量先经过 Cloudflare 的全球网络进行 DDoS 防护、WAF 过滤和缓存加速，再转发到源站。这意味着 Cloudflare 需要能够回连到你的源服务器——对于公网 IP 这不成问题，但对于 192.168.x.x 这类 RFC 1918 定义的私有地址，Cloudflare 的服务器根本无法路由到达，因此流量会直接失败。关闭橙云（DNS Only 模式，灰云）则让 DNS 直接返回你填写的 IP 地址，不经过 Cloudflare 代理层。

Tailscale 环境下为什么会失效

Tailscale 是一个基于 WireGuard 的虚拟专用网络（VPN），它为每台设备分配一个 100.x.x.x 网段的虚拟 IP。WireGuard 是一种现代化的 VPN 协议，以其极简的代码库（约 4000 行）、高性能和强加密著称，已被合并进 Linux 内核主线。Tailscale 在 WireGuard 的基础上增加了身份认证、密钥分发、NAT 穿透（基于 DERP 中继和 STUN/ICE 协议）以及访问控制等企业级功能，使得用户无需手动交换公钥或配置防火墙端口。

Tailscale 使用的 100.x.x.x 地址段属于 IANA 保留的 CGNAT（运营商级 NAT）地址空间（100.64.0.0/10），这个地址段在普通家庭或企业网络中几乎不会被使用，因此不会与现有网络产生冲突。每台加入 Tailnet 的设备都会获得一个稳定的 100.x.x.x 地址，设备间通过加密隧道直接通信（Mesh 拓扑），尽可能建立点对点连接以降低延迟。

当你通过 Tailscale 远程连接时，设备虽然逻辑上"进入"了家庭网络，但域名解析出的仍然是 192.168.x.x 的内网地址——而这个地址在 Tailscale 的虚拟网络中并不直接可达，访问链路自然就断了。

换句话说，问题的本质不在于"要不要自建 DNS 服务器"，而在于同一个域名在不同网络环境下需要解析到不同的地址。

核心解决方案：Split DNS分割DNS详解

正如该帖子评论区所引导的方向，真正的答案是 Split DNS（分割 DNS，也称分离视图 DNS / Split-horizon DNS）。

Split DNS 的工作原理

Split DNS 的核心思想是：根据发起查询的客户端所处的网络位置，为同一个域名返回不同的解析结果。

• 在家庭内网时：audiobooks.example.com → 解析到局域网 IP 192.168.1.100
• 通过 Tailscale 连接时：audiobooks.example.com → 解析到 Tailscale 虚拟 IP 100.x.x.x

这样，无论你身处何处，输入的都是同一个域名，却总能被引导到当前环境下最优的可达路径。这恰好满足了原帖用户"同一个 URL、同一张 SSL 证书、内外网通用"的需求。

Split DNS 并非家庭实验室的专属技术，它在企业 IT 基础设施中已经使用了数十年。典型场景是：企业员工在办公室内网访问 mail.company.com 时，DNS 返回内部服务器地址（如 10.0.1.50），流量走内网直连；而同一员工出差在外访问同一域名时，公共 DNS 返回公网地址或 VPN 网关地址。BIND（Berkeley Internet Name Domain）是最早支持 view 指令来实现 Split DNS 的权威 DNS 服务器软件，管理员可以根据客户端源 IP 所属的 ACL（访问控制列表）返回不同的区域文件。这项技术的核心价值在于：用户无需关心自己处于哪个网络，统一的域名体验大幅降低了运维复杂度和用户认知负担。

传统实现方式：自建 DNS 服务器

实现 Split DNS 的经典做法是自建 DNS 服务器，比如 Pi-hole、AdGuard Home 或 Unbound。你可以在本地 DNS 服务器中创建自定义解析记录，让内网域名指向内网 IP。

这三者虽然都涉及 DNS，但定位有所不同。Pi-hole 最初设计为网络级广告拦截器，通过 DNS 黑名单（blocklist）将广告域名解析到空地址来屏蔽广告，同时也支持添加自定义 DNS 记录（Local DNS Records）。AdGuard Home 功能类似但更现代化，支持 DNS-over-HTTPS（DoH）和 DNS-over-TLS（DoT）等加密 DNS 协议，内置了更丰富的过滤规则引擎。两者本质上都是 DNS 转发器（forwarder），将自己无法回答的查询转发给上游 DNS 服务器。Unbound 则是一个完整的递归 DNS 解析器，它不依赖上游 DNS 服务器，而是从根域名服务器开始逐级查询，直到获得最终结果，从而提供更好的隐私性。在家庭实验室中，常见的组合是 Pi-hole/AdGuard Home 作为前端负责广告过滤和自定义记录，Unbound 作为后端负责递归解析。

但正如社区名言所说——"It's always DNS"（问题总是出在 DNS），这句话恰恰反映了自建和维护 DNS 服务的复杂性与踩坑概率。对于新手来说，这确实是一条陡峭的学习曲线。

更优雅的落地方案：Tailscale App Connector

你可能没注意到，这位提问者最终在社区帮助下找到了一个无需完整自建 DNS 服务器的方案——Tailscale App Connector。

实际使用效果

根据原帖作者的实测反馈，配置完成后实现了理想效果：

• 家庭网络环境：访问 audiobooks.example.com，直接可用，带有效 SSL 证书，无需输入 IP 和端口。
• Tailscale 远程连接环境：访问完全相同的 URL，同样正常工作，使用同一张 SSL 证书。

两种网络环境下体验完全一致，这正是 Split DNS 想要达到的目标。

关于 SSL 证书的补充说明：Let's Encrypt 等免费证书颁发机构（CA）通过 ACME 协议自动签发证书，常用的验证方式有两种。HTTP-01 验证要求你在 Web 服务器的特定路径放置验证文件，这需要服务器可以从公网访问；DNS-01 验证则要求你在域名的 DNS 记录中添加一条特定的 TXT 记录来证明域名所有权。对于家庭实验室场景，DNS-01 验证尤为重要——因为你的服务器可能并不暴露在公网上，无法完成 HTTP-01 验证，但你仍然可以通过 Cloudflare 等 DNS 提供商的 API 自动添加 TXT 记录来完成 DNS-01 验证，成功获取甚至通配符证书。NPM 内置了对 Cloudflare API 的支持，可以全自动完成这一流程。

具体实现路径

作者明确提到了他所依赖的两份关键资料：

1. Tailscale 官方 YouTube 频道的视频教程：《App Connectors - Split DNS for any website on your tailnet》
2. Tailscale 官方文档

App Connector 的机制是让 Tailnet（你的 Tailscale 网络）中的某个节点充当特定域名流量的"应用连接器"，配合 Tailscale 内置的 Split DNS 能力，将指定域名的解析和流量路由到正确的出口节点。

值得区分的是，Tailscale 还提供了另一种网络接入方式——Subnet Router（子网路由器）。Subnet Router 的作用是将整个子网（如 192.168.1.0/24）通告到 Tailnet 中，使得 Tailscale 网络中的设备可以直接访问该子网内的所有 IP 地址，无需在每台目标设备上安装 Tailscale 客户端。这种方式简单粗暴但有效，相当于打通了一条到整个局域网的隧道。App Connector 则更加精细化，它针对特定域名工作：你指定哪些域名应该通过 Tailnet 路由，Tailscale 会自动配置 Split DNS，将这些域名的 DNS 查询拦截并路由到指定的 App Connector 节点处理。这种基于域名而非 IP 的方式更符合零信任网络的最小权限原则，也避免了暴露整个子网带来的安全风险。

相比从零搭建并维护一个 DNS 服务器，这种方式的配置成本和维护负担都大幅降低。

自建服务新手的域名解析学习路线

结合这个真实案例，如果你也在为自托管服务的域名访问发愁，以下是值得系统学习的几个方向：

第一步：理解 DNS 解析的完整流程

搞清楚从浏览器发起请求到最终建立连接的全过程中，DNS 扮演的角色，以及递归解析、权威 DNS、本地缓存之间的区别。这是排查各类"域名不解析"问题的基础。

第二步：掌握 Split DNS 的概念和应用场景

理解为什么同一域名需要在不同网络中返回不同结果，以及 Split-horizon DNS 在家庭实验室中的典型应用场景。这是家庭服务器进阶的必修课。

第三步：优先利用 VPN 工具的内置能力

如果你已经在用 Tailscale，优先探索它的原生功能——Split DNS、Subnet Router、App Connector。这些功能往往能以更低的复杂度解决问题，避免过早陷入自建 DNS 的维护泥潭。

第四步：循序渐进处理安全问题

原帖作者"暂不把服务暴露到公网"的谨慎态度值得肯定。通过 Tailscale 这类零信任网络先在私有环境中跑通全套流程，等安全知识扎实后再考虑公网暴露、反向代理加固、身份认证等进阶话题，是更稳妥的路径。

零信任网络（Zero Trust Network）是近年来网络安全领域的核心范式转变。传统网络安全采用"城堡与护城河"模型——信任内网、防御外网，一旦攻击者突破边界防火墙就可以在内网横向移动。零信任模型的核心原则是"永不信任、始终验证"（Never Trust, Always Verify），无论请求来自内网还是外网，每次访问都需要经过身份验证、设备健康检查和权限校验。Tailscale 天然契合零信任理念：每台设备都有独立身份（与 SSO 身份提供商绑定），通信默认加密，访问控制通过 ACL 策略集中管理。对于家庭实验室用户而言，使用 Tailscale 意味着你的服务永远不需要直接暴露在公网上，所有访问都必须先通过 Tailscale 的身份认证和授权，这比简单地在路由器上开放端口转发要安全得多。

总结：选择适合自己的域名解析方案

这个案例给我们最大的启示是：面对"是否必须自建 DNS 服务器"的疑问，答案往往是否定的。真正需要理解的是 Split DNS 这一核心概念，而实现它的手段可以非常灵活。借助 Tailscale App Connector 这样的现代工具，即便是新手也能在不牺牲安全性的前提下，享受统一、优雅的域名访问体验。

技术选型的智慧，有时不在于"能不能自己搭"，而在于"有没有更省心的路"。