家里没有固定 IP，如何从办公室稳定远程访问 Mac Studio？我的最终方案是 WireGuard + VPS 中转
我家里有一台 Mac Studio，平时会放在家中长期运行。需求很简单：我希望能在办公室随时远程连回去，做一些 SSH 管理、文件操作，必要时也能直接打开 macOS 的屏幕共享进行远程控制。
听起来这是一个很常见的远程访问需求，但实际动手时，会遇到几个现实问题：
- 家里宽带没有固定公网 IP
- 运营商网络和办公网络都可能有 NAT 或更复杂的限制
- 我不想把 SSH、VNC 之类的服务直接暴露到公网
- 我希望方案尽量安全，同时也别太折腾
- 最重要的是，不只是“能连上”，还得“尽量好用”
这篇文章记录的是我从 Tailscale 走到 WireGuard + VPS 中转 的完整过程。如果你也有类似需求，这套思路应该很有参考价值。
一开始，我选择了 Tailscale
最初我用的是 Tailscale。
原因很简单：它的上手门槛真的很低。安装客户端，登录，同一个网络里的设备就能互通。对于“家里一台机器，办公室一台机器”的场景来说，它几乎是最省心的选择之一。
理论上看，它也很适合我这种情况：
- 不需要固定公网 IP
- 自动处理 NAT 穿透
- 不需要我自己搭建复杂控制面
- 底层基于 WireGuard，安全性也没有问题
但问题出在实际网络环境上。
问题出现了：能连上，但远程桌面体验很差
我在办公室连回家里的 Mac Studio 时，发现延迟非常高。普通的终端操作还能勉强接受，但一旦打开屏幕共享，体验就明显不对劲：卡顿、拖影、响应慢，根本不适合长期使用。
后来排查发现，问题不在于“服务没通”，而在于链路质量不理想。
从 tailscale ping 的结果可以看出，连接并没有建立直连，而是走了 DERP 中继。这意味着：办公室电脑和家里的 Mac Studio 没有直接通信，而是通过 Tailscale 的中继服务器绕了一圈。
这对“偶尔连一下”可能无伤大雅，但对屏幕共享这种交互式远程控制来说，体验会明显下降。
这时候我才意识到，远程访问里有两个层次的问题：
- 能不能连上
- 连上之后好不好用
Tailscale 很擅长解决第一个问题，但在我这个具体网络环境里，第二个问题并没有被很好解决。
为什么会这样？
简单说，就是 NAT 穿透没有成功建立直连。
如果两端网络都比较友好，Tailscale 的体验通常非常好。但如果其中一端，尤其是办公室网络，对 UDP、NAT 打洞、直连策略不太友好，那么连接就可能退化成走中继。
一旦走中继，SSH 可能还能用，远程桌面就容易变差。
于是我开始换一个思路：
既然 NAT 穿透靠不住，那我就不要再把希望放在“自动直连”上，而是自己搭一条固定、可控的路径。
最终方案：WireGuard + VPS 中转
最后我采用的方案是：
办公室 Mac ⇄ VPS ⇄ 家里的 Mac Studio
也就是说，我找一台有公网 IP 的 VPS 作为中转节点，让家里的 Mac Studio 主动连过去，办公室的 Mac 也主动连过去。这样一来，办公室访问家里的机器时，流量会稳定地经过这台 VPS。
这个方案有几个明显优点：
- 不依赖家里有固定公网 IP
- 不依赖 NAT 穿透是否成功
- 不需要把家里的管理端口暴露到公网
- 整条路径由我自己掌控
- 只要 VPS 带宽和线路还行，体验通常比不稳定中继更可控
对我来说，这套方案的价值不是“看起来更高级”，而是“链路终于掌握在自己手里”。
我原本就有一条 WireGuard VPN，会不会冲突？
这是我一开始最担心的问题之一。
因为我本来就在用一套基于 WireGuard 的 VPN。如果新方案也建立在 WireGuard 上，会不会互相打架？
实际结论是：可以共存。
真正容易冲突的，不是“都用了 WireGuard”，而是路由设计。只要你避免下面这几件事，问题通常不大：
- 不要让两条 VPN 都抢默认路由
- 不要让两边使用重叠的网段
- 不要把同一批目标流量同时送进两条隧道
我的处理方式很简单：新的这条 WireGuard 中转隧道，只负责访问家里的那台机器，不接管默认出网。
也就是说，办公室电脑这边只让下面两个地址走新隧道：
- VPS：
10.77.0.1 - 家里的 Mac Studio：
10.77.0.2
这样一来，原有 VPN 继续做原来的事，新加的中转 VPN 只负责“回家”这件事，两边互不影响。
我的地址规划
为了避免混乱，我单独规划了一个小网段：
- VPS：
10.77.0.1/24 - Home Mac Studio：
10.77.0.2/24 - Office Mac：
10.77.0.3/24
整个思路很简单：
- VPS 是中转站
- 家里的 Mac Studio 是目标机器
- 办公室 Mac 是访问端
安装过程并不复杂，但 macOS 上有个坑
VPS 是 Ubuntu，这边安装很直接：
sudo apt update
sudo apt install -y wireguard
家里的 Mac Studio 和办公室 Mac 都是 macOS。因为我所在地区不方便通过 App Store 安装 WireGuard，所以我走的是 Homebrew 路线：
brew install wireguard-tools
brew install wireguard-go
这里有一个很容易踩到的坑：macOS 自带的 Bash 版本太旧，而 wg-quick 需要更新版本的 Bash。
所以如果你直接运行：
sudo wg-quick up wg-home
很可能会报错，提示 Bash 版本不对。
我的解决方法是显式使用 Homebrew 的 Bash：
sudo /opt/homebrew/bin/bash /opt/homebrew/bin/wg-quick up /usr/local/etc/wireguard/wg-home.conf
这个点看起来很小，但如果不知道，会卡很久。
实施顺序：先打通家里机器，再接入办公室电脑
我没有一开始就三端一起配，而是分成了两个阶段。
第一阶段：先打通 VPS 和家里的 Mac Studio
先只做一件事：Home Mac Studio ⇄ VPS
这样可以先确认：
- 家里的机器能不能稳定连到 VPS
- WireGuard 基础配置是不是正常
- 路由和端口有没有问题只要这一步成功，后面的事情就简单很多。
第二阶段：再接入办公室 Mac
等家里的机器和 VPS 通了之后，再把办公室电脑作为第三个节点接进来。
最终形成：Office Mac ⇄ VPS ⇄ Home Mac Studio
这一阶段最关键的一点是：办公室电脑的配置里，不要让这条新隧道接管默认路由，而只让访问 VPS 和家里 Mac 的流量走进去。这一步做对了，就不会影响原有 VPN。
VPN 打通之后，还要做什么？
VPN 打通只是“网络通了”，还不等于“能远程管理”。因为目标机器是 macOS，所以还需要在家里的 Mac Studio 上开启系统自带的远程功能。
1. 开启 SSH
在系统设置里打开：
通用 -> 共享 -> Remote Login
然后建议把权限限制成“Only these users”。
这样办公室电脑就可以直接：
ssh 用户名@10.77.0.2
2. 开启屏幕共享
同样在系统设置里打开：
通用 -> 共享 -> Screen Sharing
之后在办公室 Mac 上执行：
open vnc://10.77.0.2
这样就能用 macOS 自带的屏幕共享远程控制家里的 Mac Studio 了。
实际效果怎么样？
就功能可用性来说，这套方案是成功的。部署完成之后：
- SSH 稳定可用
- 屏幕共享也能正常连接
- 整体体验比之前 Tailscale 走中继时明显更好
不过，我在继续使用时还是发现了一个问题：如果开启 High Performance Screen Sharing，延迟依然比较明显。
这时问题已经不是 VPN 方案本身，而更可能是 VPS 带宽。
远程桌面里，带宽和延迟是两回事。我当前这台 VPS 只有 3M 带宽。
这时候就要区分两个概念：
- 延迟 决定操作是不是跟手
- 带宽 决定画面是不是流畅、会不会卡顿、会不会拥塞
很多时候你感觉“延迟很大”，其实不一定只是 RTT 高，也可能是屏幕数据太多，而链路带宽太小，导致排队和拥塞。
对 SSH 来说，3M 带宽绰绰有余。但对屏幕共享，尤其是高性能模式来说，3M 就偏紧了。
我手里还有另一台 5M 的 VPS，位置和当前这台差不多，也在同区域、同城市。所以我后来的判断是：既然地理位置差不多，那优先换带宽更大的那台，更值得尝试。
为了方便迁移，我把整个方案脚本化了
既然这套方案已经跑通了，我就顺手把部署过程整理成了一套可重复使用的脚本：
- setup-wg-relay.sh：在 Ubuntu VPS 上自动部署 WireGuard 中转
- rollback-wg-relay.sh：快速回滚
- generate-wg-clients-safe.sh：根据密钥文件生成客户端配置
- migrate-wg-relay.sh：一键迁移到新 VPS
这样以后换 VPS、换机房、换带宽时，就不用再手工从零配一遍。
这一步看起来像“锦上添花”，但其实很有必要。因为只要你开始长期使用这套方案，迁移和复用迟早会发生。
这次实践最值得记住的几件事
回头看整个过程，我觉得有几个经验特别值得记下来。
- Tailscale 很方便，但并不保证远程桌面体验一定好
如果能直连，它很优秀；如果退化成中继，体验可能明显下降。 - 远程访问不能只看“通不通”，还要看“顺不顺”
SSH 和屏幕共享对网络质量的要求完全不是一个级别。 - 自己控制链路，很多时候比“自动组网”更重要
尤其是在办公网络、复杂 NAT、企业网络环境下，这一点特别明显。 - 多个 WireGuard VPN 完全可以共存
前提是路由设计要克制，别动不动就上默认路由。 - macOS 的命令行 WireGuard 环境有自己的坑
尤其是 wg-quick 对 Bash 版本的要求，必须提前知道。 - VPS 带宽对屏幕共享影响很大
很多“像延迟一样的卡顿”，其实是带宽不足导致的。
最后总结
如果你的目标只是“有时候从外面连回家里机器”，Tailscale 这类方案真的非常省心。
但如果你的目标进一步升级成：
- 办公室长期远程管理家里的机器
- SSH 要稳定
- 屏幕共享要尽量流畅
- 网络环境又不利于 NAT 穿透
那么 WireGuard + VPS 中转 往往是一条更可控、更稳妥的路线。至少对我这次的实际场景来说，它确实比原来的方案更适合。
一句话总结就是：当自动穿透不够稳定时，自己搭一条固定、可控的回家路，往往才是真正好用的方案。