家里的 NAS、云上的测试服务器和随身笔记本不在同一张局域网里。要远程访问它们，可以给这些设备接入 Tailscale，再用私有地址连接 SSH、文件服务或管理页面。
Tailscale 基于 WireGuard 加密通信，负责设备发现、密钥管理和访问策略。两端网络允许时会尝试直连，无法直连时可经 DERP 中继。它能减少需要开放的公网入口，但服务本身的账号、监听地址和防火墙仍要配置。
它和传统 VPN 的差别，主要不在速度
WireGuard 本身已经把 VPN 协议做得足够轻。Tailscale 的价值不只是“用了 WireGuard，所以快”，而是替你处理了 WireGuard 在真实团队里最难维护的部分：
- 每台设备的密钥怎么生成、分发、轮换。
- NAT 后面的设备怎么互相发现。
- 两台机器能直连就直连，不能直连时怎么走中继兜底。
- 新人入职、设备更换、员工离职时，访问权限怎么跟身份系统联动。
- 家里 NAS、云服务器、内网数据库、测试环境，怎么只暴露给该看到的人。
传统 VPN 往往是“连上网关就进了一个大内网”。这事省事，但权限边界粗。Tailscale 的思路更细：每台设备都是 tailnet 里的节点，能不能访问，尽量由身份和策略决定，而不是靠“你连进来了，所以默认都能看”。
使用人数增加后，需要明确谁可以访问服务器、哪些服务需要保留公网入口，以及设备更换或人员离开时如何撤销权限。先记录这些访问需求，再配置策略，后续维护会更清楚。
最小上手：先把两台机器拉进同一张私有网
以 Linux 服务器为例，官方提供了一条安装脚本。生产环境里你可以改成发行版包管理器安装，先跑通时这样最快：
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
执行 tailscale up 后，终端会给出登录链接。用浏览器打开，选择 Google、GitHub、Microsoft 或企业 SSO 登录，授权后这台机器就进入你的 tailnet。
首次登录用 tailscale up；已经接入后，修改单项设置用 tailscale set，无需反复填写此前所有非默认参数。CLI 文档列出了两个命令的区别。
查看状态：
tailscale status
查看当前机器在 tailnet 里的 IP：
tailscale ip -4
另一台机器也安装并加入同一个 tailnet 后，在访问策略允许、服务监听地址和防火墙设置正确的前提下，可以用 Tailscale IP 访问它。下面两条命令分别用于 SSH 和 HTTP；user、100.x.y.z 及端口都要替换成实际值：
ssh user@100.x.y.z
curl http://100.x.y.z:8080
设备接入时会完成：设备注册、WireGuard 密钥交换、NAT 穿透、节点发现、加密链路建立。如果两端网络环境允许，流量会尽量点对点直连；如果打洞失败，会走 DERP 中继，仍然保持端到端加密。
MagicDNS：别再记 100.x.y.z
IP 能用，但不好记。Tailscale 的 MagicDNS 会给 tailnet 里的设备一个可读名字。比如一台机器叫 devbox，你可以直接：
ssh user@devbox
curl http://devbox:8080
小团队里这比写一堆内网 DNS 记录舒服多了。尤其是临时开发机、测试机、家用 NAS，经常换网络、换公网出口、换云厂商，固定公网 IP 反而不现实。设备名能跟着身份和 tailnet 走，网络位置变化就没那么折腾。
不过命名也要有纪律。别把机器都叫 server、test、ubuntu，后面迟早乱。建议按用途命名：
alice-macbook
build-runner-01
staging-api-s1
nas-home
agent-lab-01
名字不只是好看，后续写 ACL、排查访问、做审计都会用到。
Subnet Router：把整段内网接进来
很多时候你不是只想访问一台机器，而是想访问某个内网网段。比如家里有 NAS、路由器后台、打印机，或者云上有一个 VPC 私网段。Tailscale 的 Subnet Router 可以让一台已经加入 tailnet 的机器代为宣告某个内网网段。
假设这台 Linux 机器能访问 192.168.10.0/24，先打开 IP 转发：
echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf
然后启动 Tailscale 并宣告路由：
sudo tailscale set --advertise-routes=192.168.10.0/24
接下来要到 Tailscale 管理后台批准这条 route。批准路由后，还要在访问策略中允许目标网段和端口。Linux 客户端默认不接收子网路由，需要在要访问内网的那台 Linux 客户端上执行：
sudo tailscale set --accept-routes
Android、iOS、macOS、tvOS 和 Windows 默认接收这些路由。路由批准与访问授权是两件事；前者不能替代后者。完整条件见子网路由文档。
宣告网段前要确认它包含哪些资源。Subnet Router 等于把一段传统内网桥接进 tailnet，权限边界会变宽。比较稳的做法是：
- 只宣告必要网段，不要一上来就把整个公司内网全打进去。
- 给不同环境分开路由，比如家用、测试、生产不要混成一锅。
- 配合 ACL 限制哪些用户和设备能访问这段网。
- 对数据库、管理后台这类高风险服务，再加应用层账号和审计。
Tailscale 能让你少开公网端口，但不是让你把内网安全全交出去。
Exit Node：把某台机器当安全出口
Exit Node 的作用是把一台 tailnet 设备设置成全局流量出口。你在外面用公共 Wi-Fi 时，可以让笔记本的流量从家里服务器或可信云服务器出去。
如果出口机器是 Linux，先按上一节开启 IP 转发，再宣告它是出口节点：
sudo tailscale set --advertise-exit-node
到管理后台批准后，客户端选择这个 Exit Node 即可。Linux 客户端也可以命令行启用：
sudo tailscale set --exit-node=exit-node-name
把 exit-node-name 换成已批准的节点名。自定义访问策略还需允许使用 autogroup:internet；只允许访问出口机器的 SSH 端口，并不能授权它代转互联网流量。用完后可以取消该客户端的出口选择：
sudo tailscale set --exit-node=
出口节点文档说明了客户端选择、审批及访问权限的关系。它适合三类场景：
- 出差或公共网络下，把流量走回可信出口。
- 访问只允许某个固定出口 IP 的内部服务。
- 给临时测试环境提供一个稳定访问路径。
Exit Node 的速度受出口机器的带宽和网络路径限制。你把所有流量都压到一台机器上，就要承担这台机器的带宽、延迟、日志和合规责任。尤其是团队共用出口，最好明确谁能用、用来做什么、日志保留多久。
Tailscale SSH：少发一把 SSH key
Tailscale SSH 的思路是：既然设备身份和用户身份都在 tailnet 里，那 SSH 访问也可以交给策略控制，不必到处复制公钥。
启用方式大致是：
sudo tailscale set --ssh
然后在管理后台的访问策略里允许某些用户登录某些机器。示意上可以理解成这样：
{
"ssh": [
{
"action": "accept",
"src": [
"group:dev"
],
"dst": [
"tag:staging"
],
"users": [
"ubuntu",
"root"
]
}
]
}
这只是策略片段，不能单独替换完整策略。Tailscale SSH 同时要求网络策略放行目标的 22 端口，以及 ssh 规则允许登录相应系统用户；这些用户必须已经存在。root 权限较大，无此需要就从规则中删除。SSH 服务端支持 Linux 和开源 CLI 版 macOS，其他平台可作为客户端。具体前提见Tailscale SSH 文档。
实际规则要按你的 tailnet、用户组和 tag 调整。重点不是照抄 JSON，而是把 SSH 权限从“机器上散落的 authorized_keys”收回到一套可审查策略里。
这对小团队很实用。新人入职不用到处发 key；人走了，禁用身份就行；某台机器临时需要开放维护权限，也能有边界。仍需清理不再使用的系统账号和普通 SSH 公钥，避免旧的登录方式继续保留权限。
ACL 和 tag：Tailscale 能不能安全，主要看这里
很多人装完 Tailscale 只停在“设备互通”。这只是第一层。真正要在团队里长期用，必须认真写 ACL。
一个简单原则：不要让所有节点默认互访。至少把设备按用途分组：
- 个人设备：手机、笔记本、桌面机。
- 开发环境：devbox、CI runner、临时实验机。
- 测试环境：staging API、测试数据库。
- 生产环境：线上机器、生产数据库、监控后台。
- 家用设备：NAS、路由器、媒体服务。
然后用 tag 给服务器打标签，比如：
sudo tailscale set --advertise-tags=tag:staging
先在策略的 tagOwners 中定义谁能分配这些标签，并确认相关成员有权使用。下文的 group:dev、group:ops 及 tag:staging 都是示例，需按实际成员和服务器填写；不要只复制命令而不定义策略。
策略上可以做成：开发者能进测试环境，但不能直接碰生产数据库；运维组能进生产跳板；家用 NAS 只给个人账号访问；CI runner 只能拉取必要依赖，不能反向访问办公设备。
ACL 的核心价值不是写得多复杂，而是把“谁能访问什么”变成一份可读、可评审、可回滚的配置。这个方向，比“大家都连上 VPN 再说”靠谱得多。
Serve 和 Funnel：别把临时服务一股脑暴露到公网
Tailscale Serve 可以把本机服务发布给 tailnet 内的其他设备访问。比如你本地跑了一个 3000 端口的 Web 应用：
sudo tailscale serve --bg 3000
tailscale serve status
按照首次运行时的提示启用所需 HTTPS 设置，然后使用命令输出的完整 HTTPS 地址访问。--bg 会让 Serve 在后台持续运行；不加它时，前台进程退出后的行为不同。详情见Serve 命令文档。
只监听 127.0.0.1 的服务不能直接通过 100.x.y.z:3000 访问，Serve 可以代理这个本机服务。若选择直接访问 Tailscale IP，则需让服务监听相应地址，并核对防火墙和访问策略。
Funnel 更进一步，可以把服务公开到互联网。这个能力要谨慎用。它很适合短期 demo、Webhook 测试、临时回调，但不要把后台管理、数据库控制台、Agent Web Terminal 这类敏感东西直接 Funnel 出去。
比较稳的规则是：
- 只 Funnel 无敏感数据、短期使用的服务。
- 开之前确认认证、限流和日志。
- 用完立刻关掉。
- 长期服务还是走正式域名、反向代理、TLS、WAF 或 Zero Trust 策略。
临时工具越好用，越容易被当成长期方案。应定期检查仍在公开提供的入口。
给 Agent 和自托管服务准备一张私有运维网
Tailscale 对现在的 AI/Agent 工作流尤其合适。因为 Agent 相关服务天然会散：本地有 Claude Code、Codex、OpenClaw、浏览器自动化、向量库、临时 Web UI；云上有实验机、模型网关、日志面板、任务队列。每个都开公网端口，迟早出事。
更稳的做法是把它们先放进 tailnet：
- Agent 控制台只监听本机或内网地址。
- 通过 Tailscale IP / MagicDNS 访问 Web UI。
- 数据库、Redis、向量库不开放公网端口。
- 需要给外部系统回调时，单独处理入口，不要顺手把整个控制台暴露出去。
- 对长期在线的实验机打 tag，并用 ACL 限制访问人群。
如果你正在维护这类长期在线的 Agent 实验机、模型网关或私有运维节点，最好单独准备一台干净云服务器，不要和生产数据库、个人主机混跑。雨云这类云服务器适合拿来做隔离实验环境，按需开小规格，跑完就清掉，成本和风险都更好控。
一套更稳的落地清单
个人使用可以先接入两台设备，检查一个具体服务是否可访问。团队使用还需记录设备用途、成员和授权范围。
先从设备盘点开始：
个人设备：laptop、phone、desktop
实验机器：agent-lab-01、model-gateway-01
测试环境：staging-api、staging-db
生产环境：prod-jump、prod-monitor
家庭设备：nas-home、router-home
再给服务器设置 tag：
# 在实验节点上执行
sudo tailscale set --advertise-tags=tag:agent-lab
# 在另一台测试节点上执行
sudo tailscale set --advertise-tags=tag:staging
把默认互通收紧，只开放必要路径。示意规则可以这样设计：
{
"groups": {
"group:dev": [
"alice@example.com",
"bob@example.com"
],
"group:ops": [
"ops@example.com"
]
},
"acls": [
{
"action": "accept",
"src": [
"group:dev"
],
"dst": [
"tag:staging:22",
"tag:staging:80",
"tag:staging:443"
]
},
{
"action": "accept",
"src": [
"group:ops"
],
"dst": [
"tag:prod:*",
"tag:agent-lab:*"
]
}
]
}
然后再逐步加 Subnet Router、Exit Node、Tailscale SSH、Serve/Funnel。别一口气全开。网络工具最怕“先打通再补权限”，因为打通之后大家就会默认它一直这么用。
常见坑：不是装不上，而是边界没想清楚
第一，别把 Tailscale 当公网防火墙的替代品。它可以减少公网暴露面，但机器本身的系统更新、服务认证、最小权限、防火墙仍然要做。
第二，别让个人账号长期承载团队关键网络。个人项目无所谓，团队环境最好接企业身份系统，配 2FA，设备命名、tag、ACL、审批流程都要有基本规范。
第三，别滥用 Subnet Router。它方便，也最容易把“一个节点”变成“一整段内网入口”。家用 NAS 和测试网段可以大胆试，生产网段要慎重，最好先走只读、跳板、审计和变更审批。
第四，别把 Funnel 当长期公网发布方案。它适合临时暴露服务，不适合替代正式的线上入口。尤其是数据库后台、Agent 控制台、管理面板，别往公网一挂就完事。
第五，别忽略密钥和设备生命周期。丢手机、换电脑、员工离职、云服务器释放，都要及时从 tailnet 移除或吊销。私有网越好用，越要定期清理旧设备。
它适合谁，不适合谁
Tailscale 很适合这些场景：
- 个人开发者远程访问家里 NAS、树莓派、实验服务器。
- 小团队访问测试环境、内部面板、CI runner。
- 多云服务器之间建立轻量私有管理网。
- Agent / RPA / 自动化服务需要长期在线，但不想裸露公网端口。
- 出差时需要一个可信 Exit Node。
它不适合拿来掩盖混乱的权限管理。也不适合把大规模企业网络简单“一键迁移”进去。组织越大，越要把身份、设备合规、日志、审批、网段规划、现有 Zero Trust 体系一起考虑。
如果目前只需要访问一台 VPS 的后台，先配置两台设备的接入和该服务的访问权限就够了。等确实需要访问整段局域网或统一出口时，再启用 Subnet Router、Exit Node；每增加一种入口，都检查它实际允许访问的资源。