(内容来自GPT-6 Astra即时生成，以供本人阅读与学习)

在家里搭好 NAS、部署好个人网站，或者在办公室运行了一套内部系统之后，人们很快会遇到同一个问题：

服务已经运行起来了，但离开这个局域网以后，该怎样安全、方便地访问它？

搜索解决方案时，Tailscale 和 Cloudflare Tunnel 经常一起出现。它们都能在很多情况下实现“不需要公网 IP、不需要路由器端口映射，也能访问内网资源”，因此经常被归为“内网穿透工具”。

但这只是它们的交集。

Tailscale 的核心是把设备连接成一个有权限控制的私有网络；Cloudflare Tunnel 的核心是把内部服务或网络连接到 Cloudflare，再通过 Cloudflare 提供访问。

这一差别决定了它们的数据路径、适用协议、使用体验、隐私边界，以及性能表现。

本文先从基础网络问题讲起，再依次介绍 Tailscale 和 Cloudflare Tunnel，最后深入比较两者。

一、理解它们之前：为什么家里的服务不能直接从外面访问？#

1. 内网地址，就像办公楼里的分机号#

假设你的 NAS 地址是：

192.168.1.100

在家里，你可以打开：

http://192.168.1.100:5000

但走到外面，用手机流量访问同一个地址，一般就不行了。

原因是 192.168.1.100 属于私有 IP 地址，只在相应的内部网络中有意义。无数家庭都可以同时存在一台地址为 192.168.1.100 的设备，互联网无法仅凭这个地址确定你要访问哪一台。

它类似办公楼里的“分机 100”：在楼内有效，外面的人不能只拨 100 就找到你。

2. NAT：让一群设备共享一个对外出口#

家庭路由器通常会做 NAT，网络地址转换。

它把内部设备发出的连接转换成对外连接，并记录对应关系：

你的电脑 ──┐
你的手机 ──┼── 家庭路由器 ── 互联网
你的 NAS ──┘

当你主动访问网站时，路由器知道返回的数据应该交给哪台设备。

但如果外面突然来了一个连接，路由器通常不知道它应该交给谁，也可能被防火墙直接阻止。

传统解决办法是配置端口映射：例如把路由器收到的某个端口上的连接转发给 NAS。

问题在于，很多家庭宽带连路由器本身都没有独立的公网 IPv4 地址。运营商还会在上面再做一层 NAT，这通常称为 CGNAT，运营商级网络地址转换。

此时，只改家里的路由器往往不够。

即使使用公网 IPv6，也仍然需要处理防火墙、地址变化、服务认证和客户端网络兼容性。

3. 两条思路：让设备互联，或者为服务设置外部入口#

解决这些问题，常见的思路有两种。

接下来会看到，两者并不只是“穿透方法不同”，而是围绕不同的使用目标设计。

二、Tailscale：把分散的设备连接成一个私有网络#

1. 使用起来是什么感觉？#

假设你有三台设备：

• 家里的 NAS。
• 随身携带的笔记本。
• 云服务器上的 Linux 主机。

在这些设备上安装 Tailscale，并加入同一个网络后，它们会获得 Tailscale 网络中的地址。

这个私有网络称为 tailnet。

                 你的 tailnet

     笔记本 ───────────── 家里的 NAS
        ╲                   ╱
         ╲                 ╱
              云服务器

之后，你可以在外面：

通过 NAS 的 Tailscale 地址打开管理页面
通过 SSH 登录云服务器
通过文件共享协议访问家里的文件
通过远程桌面控制另一台电脑

对许多应用来说，操作方式和访问一台普通的可达网络主机很接近。

Tailscale 主要负责解决“设备能不能连接，以及允许谁连接”的问题。文件共享、远程桌面、数据库等功能，仍由对应的软件提供。

例如，装上 Tailscale 不会自动让 Windows 开启远程桌面，也不会自动在 NAS 上创建共享文件夹。

2. Tailscale 提供哪些核心功能？#

其中，子网路由器与出口节点尤其容易混淆。

子网路由器解决的是“如何访问那一片内网”。

例如，家里的摄像头不能安装 Tailscale，可以在旁边找一台长期运行的小主机作为子网路由器：

外面的笔记本
      │
      │ Tailscale 加密连接
      ▼
家里的子网路由器
      │
      ├── 摄像头
      ├── 打印机
      └── 其他内网设备

出口节点解决的是“上互联网时，从哪里出去”。

你的笔记本
      │
      │ Tailscale 加密连接
      ▼
家里的出口节点
      │
      ▼
互联网网站

这时，网站通常看到的是家里出口的公网地址。

默认使用 Tailscale，并不意味着全部上网流量都会经过其他设备。普通私网互联和使用出口节点，是不同的配置。

3. 原理第一层：WireGuard 负责加密，Tailscale 负责组织连接#

Tailscale 的网络加密建立在 WireGuard 之上。

WireGuard 是一种现代 VPN 技术。这里的 VPN，虚拟专用网络，指在现有网络上建立逻辑上独立、通常经过加密的网络。

不过，单独使用 WireGuard，往往需要自己处理：

• 哪台设备持有什么密钥。
• 各设备应该连接哪个地址。
• 哪些地址通过哪个节点转发。
• 网络地址变化以后怎样更新配置。
• 设备在 NAT 后面时怎样建立连接。

Tailscale 在加密连接之外，增加了身份认证、设备发现、连接协调、访问策略和管理界面。

可以把它理解为：

WireGuard 提供加密通信的基础，Tailscale 负责把大量设备组织成一个容易使用和管理的网络。

4. 原理第二层：控制平面与数据平面#

理解 Tailscale，有两个非常重要的名词。

设备登录 Tailscale 后，需要与协调服务交换必要信息，获知哪些设备可以联系，以及如何尝试连接。

但真正的业务流量，不一定经过 Tailscale 的服务器。

这意味着：

管理连接：
设备 ── Tailscale 协调服务

理想的数据连接：
设备 A ═══════════ 设备 B
          加密直连

协调服务帮助双方认识彼此，随后双方尽可能直接通信。

需要同时理解两件事：

• 业务流量能够直连，不代表整个系统完全不依赖服务提供方。
• 使用协调服务，也不代表全部文件和网页内容都会被协调服务转发。

5. 原理第三层：NAT 穿透与点对点直连#

Tailscale 会尝试建立 P2P，点对点连接。

双方即使都在路由器后面，也可能通过主动发送数据、发现外部地址和协调连接时机，让 NAT 建立可用的映射关系。这类技术常被叫作 NAT 穿透或“打洞”。

可以把它想象成：

两个都不能直接接收陌生来电的人，通过协调，同时向对方发起联系，最终形成一条可用的通信路径。

这个比喻不完全等同于网络实现，但有助于理解：它利用的是网络设备允许的连接行为，不是破解路由器。

直连成功以后，文件可以直接从家里的 NAS 传到你的笔记本，不必先绕到某个公共中继服务器。

不过，直连并不能保证成功。严格的防火墙、复杂 NAT、UDP 限制和网络环境变化，都可能影响结果。

6. 直连失败时：DERP 与其他中继路径#

直连失败时，Tailscale 可以通过中继转发流量，其中最常见的是 DERP 中继。配置了相关功能的网络，也可以使用 Peer Relay，由 tailnet 中的指定设备承担中继。

直连成功：

设备 A ═════════════════ 设备 B


通过中继：

设备 A ═════ 中继服务器 ═════ 设备 B

中继会增加路径长度，也可能带来带宽瓶颈。

但对 Tailscale 节点之间的正常加密通信来说：

中继转发的是端到端加密后的数据，不需要解密业务内容。

因此，“经过中继”与“中继能够读懂文件内容”是两回事。

中继仍可能接触到连接时间、流量大小等元数据。端到端加密保护的是内容，并不等于通信过程没有任何可观察信息。

7. 安全边界：加密保护到哪里为止？#

如果两台设备都直接运行 Tailscale，加密通道建立在这两个节点之间。

但使用子网路由器时，情况不同：

远程电脑 ══ Tailscale 加密 ══ 子网路由器 ── 内网设备

Tailscale 的加密在子网路由器处结束。最后一段是否加密，取决于应用协议。

例如：

• 使用 HTTPS，最后一段可以继续由 HTTPS 保护。
• 使用明文 HTTP，最后一段可能就是明文。
• 使用 SSH，SSH 本身还提供一层端到端加密。

出口节点也类似：

电脑 ══ Tailscale 加密 ══ 出口节点 ── 互联网网站

从出口节点到网站的内容保密性，主要取决于 HTTPS 等应用协议。

所以，“使用 Tailscale”不能笼统理解成“所有经过的每一段网络都自动获得同样的加密保护”。

8. Tailscale 能做到什么，不能做到什么？#

它很擅长：

• 让个人设备跨网络互联。
• 安全访问 NAS、SSH、远程桌面和数据库。
• 连接分散在不同地点的服务器。
• 通过子网路由器访问不能安装客户端的设备。
• 在直连条件良好时传输大量数据。
• 按用户、设备和服务范围限制访问。

它有明确边界：

这里的“三层网络”，指主要按 IP 地址传输数据；而交换机所在的“二层网络”，还涉及以太网帧、广播等机制。

因此，一些游戏或设备即使能够手动输入 IP 连接，也未必能在“搜索局域网设备”的列表里自动出现。

此外，Tailscale 的访问控制需要认真配置。加入同一个 tailnet 后能访问多少资源，取决于实际策略，不能想当然地认为所有设备默认都彼此隔离。

9. Funnel：Tailscale 也能公开发布服务，但有范围#

Tailscale Funnel 可以让互联网上的人访问特定服务，而不必加入你的 tailnet。

这对临时演示、小型公开服务很方便。

不过，按照官方当前文档，Funnel 对使用的域名、监听端口和带宽有明确约束，例如使用 tailnet 的 ts.net 域名，并只支持规定的入口端口。[1]

因此：

Funnel 扩展了 Tailscale 的公开访问能力，但不能据此把 Tailscale 当成完整的网站代理、CDN 和 WAF 平台。

三、Cloudflare Tunnel：让内部服务通过 Cloudflare 接受访问#

1. 使用起来是什么感觉？#

假设你在家里的服务器上运行了一个网站：

http://localhost:8080

现在希望别人访问：

https://app.example.com

你可以在服务器或能够访问这个网站的另一台设备上运行 cloudflared。

它是 Cloudflare Tunnel 的连接程序。

配置完成后，请求路径类似：

访问者的浏览器
      │
      │ HTTPS
      ▼
Cloudflare 边缘网络
      │
      │ Tunnel
      ▼
内网中的 cloudflared
      │
      ▼
网站 localhost:8080

访问者只需要打开域名。

家里的服务器不需要为了这项服务向公网开放入站端口，也通常不需要独立的公网 IP。[2]

2. 原理第一层：为什么不开放入站端口，也能收到请求？#

关键在于：连接由内网主动建立。

cloudflared ── 主动建立出站连接 ── Cloudflare

大多数家庭网络允许内部设备主动访问外部服务。cloudflared 利用这种能力，建立并维持与 Cloudflare 的连接。

之后，Cloudflare 可以把访问者的请求通过这条已有连接转发回来。

这与聊天软件的某种行为很相似：你主动连上服务器以后，服务器也能通过已建立的连接向你传送消息。

“出站连接”描述的是谁发起连接，不代表数据只能向外流动。

Tunnel 的连接建立后，数据是双向传输的。

它仍然需要网络允许访问 Cloudflare 所需的服务和端口；如果出站访问本身被阻止，隧道也无法凭空建立。

3. 原理第二层：反向代理和源站#

这里涉及两个常见名词。

源站是实际提供内容或处理请求的服务器，例如家里运行网站的主机。

反向代理是站在服务前面的代理。用户先连接它，再由它联系真正的服务。

用户 ── 反向代理 ── 源站

Cloudflare 的常规网站访问模式就是这种思路。

Cloudflare Tunnel 则让代理到源站这一段，不必依赖公开可达的源站 IP，而是通过内网主动建立的隧道完成。

因此，Tunnel 首先是一种源站连接方式。

缓存、访问认证、恶意请求过滤等能力，来自与其配合的 Cloudflare 产品和配置。

4. 必须分清：Tunnel、Access、WARP 和 WAF#

这些名字经常出现在同一套教程里，但各自解决不同问题。

由此可以避免一个危险误解：

建立 Tunnel，不等于已经给网站加了身份验证。

如果你发布了一个公网域名，又没有配置 Access，也没有应用自身的登录保护，它可能就是公开可访问的网站。

反过来，启用了 Access，也不代表应用漏洞已经全部解决。身份认证和应用安全，解决的是不同层面的问题。

5. 两种主要用法：发布应用与访问私有网络#

Cloudflare Tunnel 的能力不能只用“给网站加域名”概括。

用法 A：发布 Web 应用

普通浏览器 ── HTTPS 域名 ── Cloudflare ── Tunnel ── 内部网站

可以公开访问，也可以在前面加入 Access 登录验证。

典型用途包括：

• 个人网站。
• 开发演示。
• 内部管理页面。
• Webhook 接收地址。
• 只允许指定成员登录的 Web 工具。

用法 B：访问私有网络

获准终端上的 Cloudflare 客户端
                │
                ▼
        Cloudflare 网络与策略
                │
                ▼
          Tunnel 连接器
                │
                ▼
          内网 IP / 服务

这种模式可以支持私有网络中的 TCP、UDP 等访问，但需要配置终端接入、路由、流量代理和访问策略等相关组件。

这里的 TCP 和 UDP 是两种常见传输协议：TCP 提供可靠、有序的字节传输；UDP 提供数据报传输，常用于实时通信、DNS 等场景。

不能把“公开主机名发布应用”与“通过客户端接入私有网络”的协议能力混为一谈。

6. SSH、数据库和游戏服务器：为什么不能简单套用网页经验？#

网页浏览器天然会使用 HTTP/HTTPS 访问 Cloudflare 的 Web 入口。

但普通 SSH 客户端、数据库客户端或游戏客户端，使用的是其他协议，不会自动理解同一套接入流程。

Cloudflare 的公开应用配置支持多种服务类型，但对于任意 TCP 服务，官方文档中的常见方式是由访问端运行：

cloudflared access tcp

先建立本地代理连接，再由原生应用连接本地端口。

对于长时间保持的连接，官方文档建议考虑 Client-to-Tunnel 模式，也就是通过客户端接入隧道后的资源。[3]

例如，下面这个预期通常不成立：

配置 mysql.example.com
        ↓
任何人的 MySQL 客户端都能直接连接 mysql.example.com:3306

是否能够直接连接，取决于具体产品、接入方式和配置，不能仅凭“Tunnel 支持 TCP”得出结论。

同理，常规公开主机名 Tunnel 不是任意公网 UDP 游戏端口的通用映射服务。

Cloudflare 其他产品可能覆盖某些公网 TCP/UDP 场景，但不能把这些能力自动算到基础 Tunnel 功能里。

7. HTTPS 的深层问题：谁能够看到请求内容？#

对于常规 Web 应用发布，连接可以分为三段：

浏览器 ── HTTPS ── Cloudflare 边缘
                       │
                    加密隧道
                       │
                   cloudflared
                       │
                  HTTP 或 HTTPS
                       │
                     源站

浏览器通常与 Cloudflare 边缘建立 HTTPS 连接。

TLS 是保护 HTTPS 连接的加密协议。“TLS 在 Cloudflare 终止”，表示 Cloudflare 是这段加密连接的终点，能够获得解密后的 HTTP 请求，再按配置代理到源站。

这也使它能够处理 WAF、缓存和相关访问控制。

因此，在常规 HTTP/HTTPS 反向代理模式下：

各段连接经过加密，并不等于浏览器与源站之间存在一条 Cloudflare 无法解密的完整 TLS 通道。

但这不应该被泛化成“Cloudflare Tunnel 一定能解密所有应用流量”。

如果私网中的应用自行建立 SSH 或端到端 TLS，且没有配置相应的解密检查，那么应用层加密仍然可以保护内容。

判断隐私边界，应同时看：

1. 使用的是公开 Web 代理还是私网访问。
2. 应用协议本身是否加密。
3. 加密在哪些节点终止。
4. 是否启用了流量检查或解密功能。

8. Cloudflare Tunnel 能做到什么，不能做到什么？#

它很擅长：

• 把内部 Web 服务通过域名提供给访问者。
• 让浏览器用户无需安装专用客户端。
• 为源站建立不依赖公网入站端口的接入路径。
• 与 Access 配合，为内部应用增加身份验证。
• 与 Cloudflare 的网站安全、缓存和流量管理能力结合。
• 与终端客户端和私网路由配合，访问内部网络资源。

它有明确边界：

Tunnel 能减少直接暴露源站的需要，但如果服务器还有其他公网入口，或者过去已经泄露过地址，部署 Tunnel 不会自动消除这些事实。

四、深入比较：它们的差异究竟在哪里？#

1. 首先要公平比较：一个产品体系与一个连接组件#

日常说“Tailscale 对比 Cloudflare Tunnel”，实际上有一点不对称：

• Tailscale 已经包含设备客户端、连接协调、身份与网络策略等能力。
• Cloudflare Tunnel 主要是连接组件。
• 若要比较完整的企业私网访问能力，通常应比较 Tailscale 与 Tunnel + Cloudflare One Client + Access/Gateway 等组合。

因此，不能因为 Tunnel 单独没有某项能力，就断言整个 Cloudflare 平台不具备；也不能把 Cloudflare 所有其他产品的能力，都当作 Tunnel 安装后自动拥有。

2. 访问对象不同：设备与网络，还是应用入口#

Tailscale 的典型表达方式是：

允许这位开发者访问那台服务器的 SSH 端口。

Cloudflare Access 配合 Tunnel 的典型表达方式是：

允许这组员工通过身份验证后访问这个 Web 应用。

二者都能做更复杂的策略，但起点不同。

这里的“可信”不是永久信任。两者都可以围绕身份和策略实现更细的访问控制。

零信任的核心思想，是不能仅因为设备位于某个网络里，就自动授予广泛权限；访问仍应依据身份、设备状态和明确策略作出判断。

3. 数据路径不同，决定了性能上限与瓶颈#

Tailscale 直连时：

访问者 ────────── 源设备

Cloudflare Tunnel：

访问者 ── Cloudflare 网络 ── 源站连接器 ── 源服务

Tailscale 经中继时：

访问者 ── 中继 ── 源设备

因此，不能简单宣布哪一个“永远更快”。

性能至少由以下因素决定：

• 两端网络之间的线路质量。
• 是否需要中继或绕路。
• 源站上传带宽。
• 丢包率和延迟。
• 中继、代理和设备处理能力。
• 内容是否能够缓存。

对于 NAS 备份和设备间文件传输，Tailscale 直连通常有吸引力。

对于能在 Cloudflare 边缘缓存的静态内容，请求可能直接在边缘得到响应，源站压力更小。但登录后的动态页面、数据库查询和许多下载请求，并不会自动获得这种效果。

尤其在中国大陆及跨境网络环境中，应使用实际运营商、实际设备和实际业务测试，不能把品牌或“全球网络”直接等同于稳定和低延迟。

4. 隐私与信任边界不同#

如果你的明确要求是：

中间平台不能读取应用明文。

那么需要优先选择能满足该要求的端到端加密结构，并核对每个中转节点的角色。

但“中间平台读不到内容”也不能等同于“完全不依赖平台”：设备身份、访问策略、密钥分发以及账户安全，仍然影响整体安全性。

5. 可用性与依赖不同#

Tailscale 的控制平面暂时不可用时，部分已建立、状态仍有效的设备连接可能继续工作。

但新设备加入、权限更新、密钥到期、网络地址变化等情况，可能需要协调服务参与，不能把这种特性理解为永久离线自治。

Cloudflare Tunnel 的数据路径经过 Cloudflare，因此相关边缘、隧道连接或平台配置出现问题时，即使源站仍在线，用户也可能无法通过该路径访问。

两者也都依赖自己的端点：

• NAS 关机，Tailscale 无法替它提供文件。
• cloudflared 所在设备断电，Tunnel 连接可能中断。
• 子网路由器故障，它后面的设备可能无法访问。

多连接器、多节点和冗余部署可以改善可用性，但不会自动解决应用数据库、存储和电源等其他单点故障。

6. 自托管能力不同#

Tailscale 默认使用官方托管的协调服务。

如果希望自行维护控制服务，可以研究 Headscale。它是独立的开源项目，实现了兼容 Tailscale 客户端的控制服务能力，但不等于完整复制官方产品，功能支持、升级兼容和运维都需要自行评估。

自建 DERP 或 Peer Relay，只是改变中继部署，也不等于已经自建整套控制平面。

Cloudflare 的 cloudflared 客户端开源，但其服务依赖 Cloudflare 网络。你不能只把 cloudflared 部署到自己的机器上，就得到一套脱离 Cloudflare 的同等平台。

五、具体场景：什么时候选哪个？#

下面几个场景值得进一步展开。

场景 A：我只想远程访问自己的 NAS

通常先选 Tailscale。

因为“访问 NAS”可能包括多个需求：

管理网页
文件共享
照片服务
SSH
备份
媒体播放

Tailscale 可以让获准设备通过私网分别访问这些服务，不必为每一个都设计公开入口。

但如果你只是想把照片网页分享给几个不愿安装客户端的家人，Cloudflare Tunnel 加上合适的认证也可能更方便。此时需要测试图片上传、视频播放和大文件请求等实际行为。

场景 B：我想给别人看正在开发的网站

Cloudflare Tunnel 更符合这种体验：

发出一个链接 → 对方打开浏览器 → 看到网页

若只是一次轻量演示，Tailscale Funnel 也可以考虑，但要接受它的域名和其他限制。

如果网页包含私有信息，应配置认证。所谓“很长、很难猜的链接”，不能替代访问控制。

场景 C：我想接收 GitHub、支付平台或其他系统的 Webhook

Webhook 是某个平台在事件发生后，主动向指定地址发送 HTTP 请求的机制。

它通常需要一个外部可达的 HTTPS 地址，因此 Cloudflare Tunnel 很合适。

但不能直接把交互式登录页面放在回调接口前面，否则机器请求可能被拦住。应根据调用方能力使用服务身份认证、签名校验等机制。

“浏览器登录成功”与“第三方机器可以调用接口”，是不同的验证目标。

场景 D：我想远程 SSH 或连接数据库

个人或小团队通常先考虑 Tailscale，客户端使用方式接近原来的习惯。

Cloudflare 也能完成，但应明确采用：

• 客户端本地代理。
• Cloudflare One Client 私网接入。
• 特定的浏览器访问方案。

不要把“支持 SSH”误解成“任何 SSH 客户端都能无需额外配置地直连公开域名”。

六、两者一起使用：一个很实用的家庭服务器架构#

两者可以部署在同一台服务器或同一个内网中。

                       家庭服务器
                    ┌───────────────┐
自己的电脑 ─ Tailscale ─ SSH / 文件共享 │
                    │               │
家人的浏览器 ─ Cloudflare ─ 照片网页   │
                    │               │
第三方平台 ─ Cloudflare ─ Webhook 接口 │
                    └───────────────┘

对应的思路是：

这种组合既保留了设备级访问能力，也能为需要低门槛访问的网页提供入口。

不过，要分别检查每一条访问路径的权限。某个网页通过 Tailscale 很安全，不代表它经另一个公开入口访问时也自动受同样的策略保护。

七、选择之前，真正应该验证的五件事#

第一，访问者是谁？

自己、固定团队和受管理设备，更适合私有网络。

陌生访客、临时用户、第三方平台，通常需要公开应用入口。

第二，访问的是什么协议？

网页、SSH、文件共享、数据库、游戏通信，对接入方式的要求很不一样。先明确协议，再比较产品。

第三，数据实际走哪条路？

Tailscale 是否直连？Cloudflare 访问是否绕路？源站带宽够不够？

对于 Tailscale，可以用 tailscale status、tailscale ping 等工具观察连接情况；但网络连通测试不能替代真实的文件传输和应用测试。

第四，加密在哪里结束？

要能清楚指出：

谁加密 → 谁转发 → 谁解密 → 后面还有没有明文段

这比只看到界面上有一个“加密”标识更有意义。

第五，出了问题以后，自己能维护到什么程度？

Tailscale 的常见排查涉及直连、中继、路由、DNS 和设备权限。

Cloudflare 的常见排查涉及域名、Tunnel 状态、源站连接、Access 策略、HTTP 代理限制以及终端私网配置。

两者都有免费可用的能力，但成员数、设备数、高级策略、日志保留、支持等级和使用限制会变化。正式部署时，应按实际场景核对当前套餐，尤其不要把“免费”理解成“任何用途都没有边界”。

参考资料与延伸阅读#

以下优先列出官方资料；具体套餐、界面名称和功能限制可能随产品迭代变化。

1. Tailscale Funnel：功能与限制
2. Cloudflare Tunnel：工作原理与出站连接模型
3. Cloudflare：公开应用支持的协议与客户端要求
4. Tailscale：整体工作原理
5. Tailscale：直连、Peer Relay 与 DERP 连接类型
6. Tailscale：子网路由器
7. Tailscale Serve：在私有网络内提供服务
8. Cloudflare：私有网络中的 UDP 与内部 DNS