Sunshine + Moonlight 外网访问方案

实践时间：2026-06-14 本文讨论如何从外网（非同一局域网）通过 Moonlight 连接到 Linux 上的 Sunshine

一、方案总览与对比

方案	延迟	配置复杂度	成本	推荐度
Tailscale（Mesh VPN）	直连 < 5ms，中继 30–100ms	极低	免费（≤3 台设备）	★★★★★
ZeroTier（Mesh VPN）	类似 Tailscale	低	免费（≤25 台设备）	★★★★
WireGuard 自建	取决于 VPS 到两端距离	中	VPS 费用	★★★
frpc 端口转发	高（双倍 VPS 延迟 + 协议开销）	高	VPS 费用 + 大带宽	★★

核心区别：

frpc（中心化中转）:
  Moonlight → [公网] → frps 服务器 → [公网] → Sunshine
  所有流量必经服务器，延迟 = 两段之和，服务器带宽是瓶颈

Tailscale / ZeroTier（去中心化直连）:
  Moonlight → [WireGuard 打洞] → Sunshine    （直连，延迟最低）
  Moonlight → [DERP 中继] → Sunshine          （打洞失败时回退）

二、frpc 端口转发方案分析

2.1 结论先行

有条件可行，但不推荐用于日常串流。

frpc 技术上可以跑通 Sunshine + Moonlight 的外网连接，但在延迟、带宽、成本三个维度上都不如 VPN 方案。如果你已有低延迟高带宽的 frps 服务器，可以作为临时应急手段。

2.2 Sunshine 完整端口/协议分析

Moonlight 连接 Sunshine 涉及以下端口（基于 port = 47989 默认配置）：

端口	协议	用途	流量特征
47984	TCP	HTTPS 客户端认证/配对	低流量，仅连接/配对时使用
47989	TCP	HTTP 服务发现/协商	低流量，控制信令
47990	TCP	Web UI（可选，非串流必需）	低流量，管理界面
48010	TCP	RTSP 会话控制	低流量，串流建立/控制
47998	UDP	视频流	高流量，40–80 Mbps
47999	UDP	控制输入（键鼠/手柄）	低流量，但延迟极敏感
48000	UDP	音频流	中流量，~512 Kbps
48002	UDP	麦克风回传	低流量

关键点：

控制流（TCP）：流量小、延迟不太敏感，frpc 可以胜任
数据流（UDP）：视频流是大头，带宽高、延迟敏感，这是 frpc 的瓶颈所在

2.3 frpc UDP 隧道的技术原理

frpc 的 UDP 隧道并不是简单的 UDP 转发，其工作原理：

frpc 端（本地）                    frps 端（服务器）
    |                                    |
    | Sunshine UDP 包                    |
    ↓                                    |
[封装进 TCP/KCP 隧道] ────────→ [解封装还原 UDP] → Moonlight
    |                                    |
    | frpc-frps 之间是 TCP 或 KCP 长连接  |

问题一：TCP 封装 UDP（Head-of-Line Blocking）

当 frpc 使用默认 TCP 传输模式时，UDP 视频包被封装进 TCP 流。TCP 的可靠传输机制会导致：

一个包丢失 → 后续所有包排队等待重传（队头阻塞）
视频流出现突发性卡顿（不是持续高延迟，而是间歇性冻结）

这是 frpc 用于实时视频最根本的问题。

问题二：KCP 模式可以缓解但不解决

frpc 支持 transport.protocol = kcp 模式，使用 KCP（基于 UDP 的可靠传输协议）替代 TCP 作为隧道承载：

避免了 TCP 的队头阻塞
但 KCP 仍有自己的可靠传输开销（ARQ 重传、拥塞窗口）
frps 服务器需要额外开放 UDP 端口
稳定性不如 TCP 模式

问题三：带宽成本

1440p 60fps 串流需要 40–80 Mbps 持续带宽。所有流量过 frps：

云服务器带宽费用：以阿里云为例，1 Mbps 弹性公网 ≈ ¥23/月，50 Mbps ≈ ¥1150/月
即使使用按量付费（约 ¥0.8/GB），每小时 40 Mbps ≈ 18 GB ≈ ¥14.4/小时
降低码率到 10–15 Mbps 可以降低成本，但画质会严重下降

2.4 完整 frpc 配置示例

如果仍然要使用 frpc，以下是完整配置：

frpc.toml（Sunshine 所在的 Ubuntu 主机）

serverAddr = "你的frps服务器IP"
serverPort = 7000
 
# 建议使用 KCP 减少队头阻塞（frps 也需要配置 kcpBindPort）
# transport.protocol = "kcp"
 
# ===== TCP 控制端口 =====
 
[[proxies]]
name = "sunshine-https-auth"
type = "tcp"
localIP = "127.0.0.1"
localPort = 47984
remotePort = 47984
 
[[proxies]]
name = "sunshine-http"
type = "tcp"
localIP = "127.0.0.1"
localPort = 47989
remotePort = 47989
 
[[proxies]]
name = "sunshine-webui"
type = "tcp"
localIP = "127.0.0.1"
localPort = 47990
remotePort = 47990
 
[[proxies]]
name = "sunshine-rtsp"
type = "tcp"
localIP = "127.0.0.1"
localPort = 48010
remotePort = 48010
 
# ===== UDP 数据端口 =====
 
[[proxies]]
name = "sunshine-video"
type = "udp"
localIP = "127.0.0.1"
localPort = 47998
remotePort = 47998
 
[[proxies]]
name = "sunshine-input"
type = "udp"
localIP = "127.0.0.1"
localPort = 47999
remotePort = 47999
 
[[proxies]]
name = "sunshine-audio"
type = "udp"
localIP = "127.0.0.1"
localPort = 48000
remotePort = 48000
 
[[proxies]]
name = "sunshine-mic"
type = "udp"
localIP = "127.0.0.1"
localPort = 48002
remotePort = 48002

frps.toml（公网服务器端）

bindAddr = "0.0.0.0"
bindPort = 7000
# kcpBindPort = 7000    # 如果启用 KCP 模式取消注释

Moonlight 连接：在 Moonlight 中输入 frps 服务器的公网 IP。

2.5 frpc 方案的已知问题汇总

问题	严重度	说明
TCP 队头阻塞	高	UDP 视频包封装进 TCP，丢包时全部排队等待，画面间歇性冻结
带宽成本高	高	50 Mbps 持续流量过服务器，月费可达数百甚至上千元
服务器成为单点故障	中	frps 服务器宕机或带宽跑满，直接断流
端口映射繁琐	中	需要映射 8 个端口（4 TCP + 4 UDP），任一端口错误即连接失败
延迟叠加	中	总延迟 ≈ Moonlight→frps + frps→Sunshine，通常 > 50ms
Moonlight 连接不稳定	中	部分用户反馈 frpc UDP 隧道在高负载下频繁断开重连
无端到端加密	低	frps 服务器可以看到解封装后的明文流量（WireGuard 方案有端到端加密）

社区反馈：在 Sunshine GitHub Discussions 和 Reddit r/cloudygamer 中，有用户报告通过 frpc 跑通了低码率（10–15 Mbps）的 1080p 串流，但普遍评价是”能用但体验远不如 VPN 方案”，尤其是画面冻结和输入延迟问题。

2.6 什么情况下 frpc 是合理选择

已有 frps 服务器，不想再装新软件
临时/应急使用，不追求画质（降到 1080p 10–15 Mbps）
国内网络环境下 Tailscale DERP 节点不可达，但有国内低延迟 VPS
只需要远程控制（非长时间观看/办公），对卡顿容忍度高

三、Tailscale 方案（推荐）

3.1 方案原理

Tailscale 基于 WireGuard 协议，为每台设备分配 100.x.x.x 虚拟 IP，设备间通过加密隧道直接通信。Moonlight 用 Tailscale IP 替代局域网 IP 连接 Sunshine，其他配置无需改动。

直连模式（NAT 穿透成功）：
  Moonlight ←──── WireGuard P2P 隧道 ────→ Sunshine
  延迟增加：仅 1–3ms（加密开销）

中继模式（NAT 穿透失败）：
  Moonlight ←→ DERP 中继节点 ←→ Sunshine
  延迟增加：30–100ms（取决于 DERP 节点距离）

3.2 Ubuntu 安装 Tailscale

# 一键安装
curl -fsSL https://tailscale.com/install.sh | sh
 
# 启动并认证（会输出一个 URL，在浏览器中打开登录）
sudo tailscale up
 
# 验证
tailscale ip -4          # 查看本机 Tailscale IP（如 100.64.x.x）
tailscale status         # 查看已连接设备列表
 
# 确认开机自启
sudo systemctl enable --now tailscaled

3.3 Windows 安装 Tailscale

访问 https://tailscale.com/download/windows 下载安装包
安装后系统托盘出现 Tailscale 图标
点击图标 → Log in → 浏览器弹出授权页 → 用同一账号登录
登录后图标变绿，鼠标悬停可看到 Tailscale IP

验证连通性：

# Windows PowerShell 中 ping Ubuntu 的 Tailscale IP
ping 100.64.x.x

3.4 Moonlight 通过 Tailscale 连接

Sunshine 不需要修改任何配置。Tailscale 工作在网络层，对 Sunshine 完全透明。

打开 Moonlight → 点击 + 添加主机
输入 Ubuntu 的 Tailscale IP（如 100.64.1.5）
后续 PIN 配对流程与局域网完全相同
配对成功后点击 Desktop 即可投屏

提示：如果启用了 Tailscale 的 MagicDNS，也可以用主机名代替 IP： zbc-system-product-name.tail1234ab.ts.net

3.5 防火墙配置（如果启用了 UFW）

本机 UFW 当前未启用（inactive），无需配置。如果将来启用了 UFW：

# 方式一：允许 Tailscale 接口的所有流量（简单）
sudo ufw allow in on tailscale0
 
# 方式二：精确放行 Sunshine 端口（更安全）
sudo ufw allow from 100.64.0.0/10 to any port 47984,47989,48010 proto tcp
sudo ufw allow from 100.64.0.0/10 to any port 47998,47999,48000 proto udp

3.6 直连 vs DERP 中继

连接模式	触发条件	延迟影响
直连 P2P	至少一方 NAT 可穿透（家用路由器通常可以）	仅增加 ~1–3ms
DERP 中继	双方都在严格对称型 NAT 后（企业/校园网）	增加 30–100ms

查看当前连接模式：

tailscale status
# "direct" = 直连，"relay" = 经过 DERP 中继

提升直连成功率：

在路由器上启用 UPnP
或手动转发 UDP 端口 41641（WireGuard 使用的端口）

3.7 免费版限制

项目	限制
设备数量	最多 3 台（2024 年 5 月起从 100 台缩减）
带宽	无限制
DERP 中继	使用官方节点，免费
MagicDNS	支持
子网路由	支持

对 Sunshine 场景的评估：

2 台设备（1 Ubuntu + 1 Windows）→ 完全够用
3 台（加手机 Moonlight）→ 刚好用满
超过 3 台 → 需付费（Personal Pro ~$5/月）或使用 Headscale（开源自建控制面，无设备限制）

3.8 已知的坑

1. 中国大陆 DERP 节点不稳定

Tailscale 官方 DERP 节点在中国大陆访问不稳定。如果无法 P2P 直连，中继连接可能很差甚至断开。

解决方案：

确保两端能 P2P 直连（家用宽带通常可以）
使用 Headscale + 自建 DERP 节点（需要有一台 VPS）
或改用 ZeroTier（见下文）

2. Sunshine Web UI 远程访问

通过 Tailscale IP 访问 Sunshine Web UI 时，如果 origin_web_ui_allowed = lan，可能被拒绝（Tailscale IP 不被视为 LAN）。需要改为：

# ~/.config/sunshine/sunshine.conf
origin_web_ui_allowed = wan

安全提醒：改为 wan 后，任何能访问到该 IP 的人都能尝试登录 Web UI。因为 Tailscale 本身已经提供了网络隔离，只有加入你 Tailscale 网络的设备才能访问，所以风险可控。

3. Windows Tailscale 的 DNS 劫持

Tailscale 在 Windows 上启用 MagicDNS 后会修改系统 DNS，可能影响其他应用。如果不需要用主机名连接，可以在 Tailscale 管理面板中关闭 MagicDNS。

4. CPU 开销

WireGuard 加密/解密会占用 CPU。在 Intel UHD 630 这种集显平台上，如果同时跑 VAAPI 编码和 WireGuard 加密，高码率（>60 Mbps）时可能出现 CPU 瓶颈。可以通过 Ctrl+Alt+Shift+S（Moonlight 性能面板）观察 Encoder Latency 是否异常升高。

四、其他方案简介

4.1 ZeroTier

与 Tailscale 同类的 Mesh VPN，核心区别：

对比	Tailscale	ZeroTier
底层协议	WireGuard	自研（Layer 2 仿真）
免费设备数	3 台	25 台
配置复杂度	极简	略复杂（需要管理网络 ID 和规则）
中国可用性	DERP 节点不稳定	可自建 Moon 节点，更灵活
延迟	直连时极低	略高于 Tailscale（协议开销更大）

适合场景：设备超过 3 台、国内网络环境复杂需要自建中继节点。

安装：

# Ubuntu
curl -s https://install.zerotier.com | sudo bash
sudo zerotier-cli join <network-id>
 
# Windows：下载安装包后加入同一网络 ID

4.2 WireGuard 自建

适合有公网 IP VPS 且需要完全自主控制的用户。

架构：

Moonlight(Windows) → WireGuard → VPS(公网) → WireGuard → Sunshine(Ubuntu)

优点：无设备数限制，无第三方依赖缺点：需要自行管理密钥、配置路由；所有流量过 VPS（无 P2P 直连）

五、方案选型建议

你的情况	推荐方案
快速上手，设备 ≤ 3 台	Tailscale
设备较多（>3 台）	ZeroTier（25 台免费）
中国大陆，DERP/Moon 不稳定	Headscale 自建或 ZeroTier + 自建 Moon
已有高带宽低延迟 VPS	WireGuard 自建
已有 frps，临时应急	frpc（降码率到 10–15 Mbps）
追求画质，不差钱	Tailscale（直连）或高带宽 VPS + WireGuard

附：frpc vs Tailscale 一句话总结

frpc：所有流量必须经过中转服务器，延迟 = 两段之和，服务器带宽是天花板，高码率串流成本高昂
Tailscale：尽量 P2P 直连（延迟接近局域网），打洞失败才走中继，安装 5 分钟，免费

对于 Sunshine + Moonlight 这种对延迟和带宽都敏感的实时串流场景，能直连就不要中转，这是选择 Tailscale 而非 frpc 的根本原因。

Quartz 4

Explorer

Sunshine + Moonlight 外网访问方案

Sunshine + Moonlight 外网访问方案

目录

一、方案总览与对比

二、frpc 端口转发方案分析

2.1 结论先行

2.2 Sunshine 完整端口/协议分析

2.3 frpc UDP 隧道的技术原理

2.4 完整 frpc 配置示例

2.5 frpc 方案的已知问题汇总

2.6 什么情况下 frpc 是合理选择

三、Tailscale 方案（推荐）

3.1 方案原理

3.2 Ubuntu 安装 Tailscale

3.3 Windows 安装 Tailscale

3.4 Moonlight 通过 Tailscale 连接

3.5 防火墙配置（如果启用了 UFW）

3.6 直连 vs DERP 中继

3.7 免费版限制

3.8 已知的坑

四、其他方案简介

4.1 ZeroTier

4.2 WireGuard 自建

五、方案选型建议

附：frpc vs Tailscale 一句话总结

Graph View

Table of Contents

Backlinks