简介：这是一套面向串流游戏与超低延迟应用场景的完整工具组合，包含 Sunshine 服务端与 Moonlight 客户端，覆盖 X86、X64 及 Android 平台，适合希望在不同设备间实现高画质、低延迟游戏串流的玩家与开发者。方案兼容 AMD、NVIDIA 独立显卡以及 Intel 核显，并针对 Android 手机和平板做了适配，让移动端也能无缝接入 PC 游戏进程。资源包共 2868 个文件，约 64.79MB，以 2023 个 svg、415 个 js、107 个 scss 等前端资源为主，同时包含 68 个 ts、60 个 map、34 个 css 等构建与样式文件，另有 10 个 hlsl 着色器、8 个 bat 批处理脚本、5 个 exe 可执行程序及若干 json、yml 配置，覆盖服务安装、防火墙规则、虚拟显示驱动等环节。目前已有 16453 人学习下载，可帮助读者快速搭建低延迟串流环境，理解服务端渲染传输与客户端接收显示的完整链路，并借助批处理与配置文件完成部署与排错。

1. 串流方案选型：为什么 sunshine 服务端 + moonlight 客户端值得折腾

如果你手里有一台性能还不错的 Windows 主机，又想在客厅电视、平板或者手机上玩 3A 大作，那 sunshine 服务端加 moonlight 客户端这套组合，大概率是你绕不开的方案。它的核心逻辑很直接：服务端负责采集桌面画面、硬件编码、把视频流和音频流推出去；客户端负责解码、渲染、把键鼠手柄的输入回传。整套链路走的是局域网或公网直连，延迟能压到十几毫秒级别，画质可以跑到 4K 120 帧，前提是你的网络和硬件跟得上。

这套方案解决的是「主机在书房、人想在别处玩」的物理距离问题。适合三类人：一是家里有闲置高性能主机的玩家，二是想用平板或轻薄本远程调用台式机算力的开发者，三是需要跨 X86、X64、安卓多端统一串流入口的折腾党。标题里特意标了 X86、X64、安卓，说明这套东西的客户端覆盖范围很广，老设备也能找到对应版本。下面我从服务端配置讲到客户端选型，再到参数调优和踩坑，尽量把每一步都落到能直接抄的程度。

2. sunshine 服务端部署：从安装到第一帧画面

2.1 硬件编码器怎么选：NVENC、AMF、QSV 的取舍

sunshine 服务端最核心的一步是选编码器。它本身不做软件编码，全靠显卡的硬件编码单元。NVIDIA 卡走 NVENC，AMD 卡走 AMF，Intel 核显走 QSV。三者的画质和延迟差异在低码率下比较明显，高码率下差距缩小。

我一般这样判断：如果你用的是 RTX 20 系以后的 N 卡，直接选 NVENC，它的低延迟模式（低延迟高吞吐）在 moonlight 上表现最稳。AMD 的 AMF 在 6000 系以后进步很大，但驱动版本影响不小，建议用较新的驱动。Intel 核显的 QSV 适合没有独显的轻薄本做服务端，但 4K 编码会吃力，1080P 比较合适。

在 sunshine 的 Web 配置界面里，编码器选项通常在Audio/Video标签下。选错编码器会导致串流直接黑屏或者报错「无法初始化编码器」。如果你不确定，先选Auto，让它自己探测，跑通后再手动锁定。

2.2 安装与首次配对：Web 界面配置全流程

sunshine 服务端的安装包在 Windows 上是一个可执行文件，装完后会注册为系统服务，开机自启。装完第一件事是打开浏览器访问https://localhost:47990，这是它的管理界面。首次访问需要设置用户名和密码，这个凭据是给 Web 界面和客户端配对用的。

配对流程是这样的：moonlight 客户端在同一个局域网里会自动发现 sunshine 服务端，点进去会弹出一个四位数的 PIN 码。你需要在 sunshine 的 Web 界面PIN标签页里输入这个码，点发送，配对就完成了。如果自动发现失败，可以在 moonlight 里手动添加主机 IP。

这里有个细节：Windows 防火墙可能会拦掉 sunshine 的端口。默认情况下它用 47984 到 47990 这几个端口。如果配对一直转圈，先去防火墙里给 sunshine 放行入站规则。我习惯直接关掉防火墙做测试，跑通后再按端口放行。

2.3 配置文件手改：分辨率、帧率、码率的底层参数

Web 界面能改大部分参数，但有些底层选项得直接改配置文件。sunshine 的配置文件在安装目录下的config文件夹里，文件名是sunshine.conf。你可以用文本编辑器打开，里面是键值对格式。

# sunshine.conf 关键参数示例 # 分辨率与帧率，建议和客户端显示设备匹配 output_name = 0 dd_resolution = 1920x1080 dd_refresh_rate = 60 # 编码器相关，nvenc 是 NVIDIA，amf 是 AMD，qsv 是 Intel encoder = nvenc # 码率单位是 kbps，局域网千兆网可以拉到 50000 以上 video_bitrate = 50000 # 音频设备，留空则用默认输出 audio_sink =

dd_resolution和dd_refresh_rate是虚拟显示器的分辨率，如果你没有接物理显示器，sunshine 会创建一个虚拟显示设备。这个值要和 moonlight 客户端请求的分辨率一致，否则会触发缩放，增加延迟。video_bitrate是码率上限，局域网内可以设高一些，公网串流则要根据上行带宽来压。

改完配置文件需要重启 sunshine 服务才能生效。重启方式是在 Windows 服务管理器里找到 sunshine 服务，右键重启。或者用命令行net stop sunshineservice && net start sunshineservice。

3. moonlight 客户端多端部署：X86、X64、安卓的差异与选择

3.1 X86 与 X64 客户端的安装包差异

moonlight 客户端的 Windows 版本分 X86 和 X64 两种架构。X86 是 32 位，X64 是 64 位。现在还在用 32 位系统的设备基本是十年前的旧机器，比如某些老款 Atom 平板。如果你的设备是 64 位处理器，一律选 X64，性能更好，内存寻址范围更大。

安装包本身很小，几兆到十几兆。装完后第一次打开，它会自动扫描局域网里的 sunshine 服务端。如果没扫到，点右上角的加号手动输入 IP。配对码流程和服务端那边是对应的，输入 PIN 码后两边就绑定了。

X86 版本在旧设备上的实际表现：1080P 60 帧解码会占用较多 CPU，因为老设备的核显解码能力弱。如果你非要用 X86 设备，建议把串流分辨率降到 720P，帧率降到 30，码率压到 10000 以下，这样才勉强能玩。

3.2 安卓端的三种解码模式：硬解、软解、混合

安卓端的 moonlight 客户端在解码上有三个选项：硬件解码、软件解码、混合模式。硬件解码走的是手机 SoC 里的视频解码单元，功耗低、延迟低，但兼容性看芯片。高通骁龙系列对 H.264 和 H.265 的硬解支持最好，联发科部分型号对 H.265 硬解有问题，会花屏或者绿屏。

软件解码靠 CPU 跑，兼容性无敌，但功耗高、发热大，高码率下手机会烫得拿不住。混合模式是让系统自己选，通常优先硬解，失败时回退软解。

我的建议是：先试硬解，如果画面正常就锁定硬解。如果出现花屏、卡顿、音画不同步，切到软解验证是不是硬解的问题。确认是硬解兼容性问题后，要么换 H.264 编码（兼容性比 H.265 好），要么就用软解但把码率降下来。

3.3 手柄与触屏映射：安卓端的输入配置

安卓端 moonlight 支持蓝牙手柄和触屏虚拟按键。蓝牙手柄连上后，moonlight 会自动识别，但有些手柄的键位映射和 Xbox 标准不一致，需要在 moonlight 的设置里手动校准。触屏虚拟按键适合玩回合制或者策略游戏，动作游戏还是手柄靠谱。

在 moonlight 的设置里有一个输入选项卡，可以调整手柄的摇杆死区、扳机键行程。如果你发现摇杆漂移，把死区调大一点。触屏映射可以自定义按键位置和大小，但配置起来比较繁琐，建议直接用手柄。

4. 串流参数调优：延迟、画质、稳定性的三角平衡

4.1 码率与分辨率的匹配公式

码率和分辨率不是随便设的。有一个经验公式：H.264 编码下，1080P 60 帧至少需要 15000 kbps 才能看得过去，20000 到 30000 比较舒服。H.265 编码效率高一些，同画质下码率可以降 30% 左右。

4K 60 帧的话，H.265 建议 50000 kbps 起步，H.264 要 80000 以上。但码率越高，网络抖动的影响越大。局域网千兆有线随便跑，WiFi 5 跑 4K 高码率会吃力，WiFi 6 好很多。

我一般这样设：局域网有线，1080P 60 帧，H.265，码率 30000。WiFi 环境，1080P 60 帧，H.265，码率 20000。公网串流，720P 60 帧，H.264，码率 8000 到 12000，具体看上行带宽。

4.2 帧率 pacing 与垂直同步：消除画面撕裂和卡顿

moonlight 客户端有一个帧率 pacing选项，作用是让解码后的帧按显示器的刷新节奏输出，避免撕裂。如果你的显示器是 60Hz，串流帧率也是 60，开这个选项画面最顺。如果显示器是 120Hz，串流 60 帧，开 pacing 可能会引入轻微抖动，可以关掉试试。

垂直同步在 moonlight 里叫V-Sync。开它能消除撕裂，但会增加一两帧的输入延迟。竞技类游戏建议关掉，画面撕裂比延迟更可接受。单机游戏可以开，画面更干净。

4.3 网络层优化：有线、WiFi 6、QoS 的取舍

串流最怕网络抖动。有线连接永远是最稳的，千兆网卡直连路由器，延迟能稳定在 1 毫秒以内。WiFi 环境下，5GHz 频段是必须的，2.4GHz 的带宽和干扰根本扛不住高码率串流。

WiFi 6 在串流场景下的优势是 OFDMA 和 MU-MIMO，多设备同时用网时抖动更小。如果你的路由器支持 WiFi 6，客户端设备也支持，优先走 WiFi 6。另外，路由器的 QoS 功能可以把串流流量标记为高优先级，减少其他设备下载时的卡顿。

我遇到过一种情况：串流跑在 WiFi 上，每隔十几秒卡一下。排查后发现是路由器在后台做信道扫描。关掉自动信道选择，锁定一个干净的信道，问题就消失了。这种玄学问题只能靠排除法。

5. 避坑与排查：串流翻车的五个血泪教训

5.1 黑屏但有声音：编码器初始化失败

现象：moonlight 连上后画面全黑，但声音正常，或者提示「无法解码视频流」。

原因：服务端的编码器选错了，或者显卡驱动不支持当前编码格式。比如老 N 卡选了 NVENC 但驱动太旧，或者 A 卡选了 AMF 但驱动版本有 bug。

解决：先去 sunshine 的 Web 界面看日志，日志里会明确写「encoder init failed」之类的信息。然后换编码器试，NVENC 换 QSV，或者换 H.264 编码格式。更新显卡驱动到最新版。如果还不行，把 sunshine 的日志级别调到 debug，看具体报错。

5.2 画面卡顿但延迟显示很低：帧率 pacing 的锅

现象：moonlight 的统计信息里延迟只有几毫秒，但画面肉眼可见地一顿一顿。

原因：帧率 pacing 和显示器的刷新率不匹配。比如显示器是 59.94Hz，串流是 60Hz，pacing 会周期性丢帧。

解决：关掉帧率 pacing，或者把显示器刷新率手动设成和串流帧率完全一致。Windows 显示设置里可以选 60Hz 还是 59.94Hz，选 60Hz。如果还卡，把 moonlight 的渲染模式从「独占全屏」改成「窗口全屏」试试。

5.3 手柄延迟高：蓝牙干扰与轮询率

现象：手柄操作有明显延迟，尤其是摇杆，感觉像在划水。

原因：蓝牙手柄的轮询率低，或者蓝牙适配器和 WiFi 共用 2.4GHz 频段，互相干扰。

解决：换有线手柄，或者用 2.4GHz 专用接收器的手柄。如果必须用蓝牙，把蓝牙适配器插在 USB 2.0 接口上（USB 3.0 的干扰更大），并且让适配器远离路由器。Windows 的蓝牙设置里可以关掉「允许计算机关闭此设备以节约电源」，减少唤醒延迟。

5.4 公网串流连不上：端口映射与 NAT 类型

现象：局域网串流正常，出门用 4G 或 5G 就连不上。

原因：服务端在 NAT 后面，没有做端口映射，或者运营商给的是大内网 IP。

解决：在路由器里把 sunshine 的端口映射到公网。默认需要映射 47984 到 47990 的 TCP 和 UDP。如果路由器显示 WAN IP 是 100.64 开头的，说明是运营商大内网，端口映射无效，这种情况只能走其他中继方案。另外，有些路由器的 NAT 类型是「对称型」，也会导致连不上，改成「全锥型」会好很多。

5.5 安卓端花屏：H.265 硬解兼容性

现象：安卓手机串流时画面出现绿色或紫色色块，声音正常。

原因：手机 SoC 的 H.265 硬解单元有 bug，或者 moonlight 的硬解实现和该芯片不兼容。

解决：把服务端的编码格式从 H.265 改成 H.264。H.264 的硬解兼容性在安卓上普遍更好。如果非要 H.265，试试在 moonlight 里关掉「硬件解码」用软解，但软解功耗高，手机发热会很明显。另一个办法是换一个 moonlight 的衍生版本，有些第三方编译版对特定芯片做了适配。

6. 进阶技巧：把串流延迟压到个位数

6.1 服务端独占全屏与 HDR 的取舍

sunshine 服务端有一个「独占全屏」选项，开启后它会接管显示器的输出，减少桌面合成器带来的延迟。但这个选项和 HDR 有冲突，开 HDR 时独占全屏可能黑屏。如果你追求极致延迟，关掉 HDR，开独占全屏。如果你更在意画质，保留 HDR，用窗口全屏模式。

HDR 串流需要客户端也支持 HDR 显示。安卓端目前对 HDR 串流的支持参差不齐，Windows 客户端支持较好。开 HDR 后码率要相应提高，否则暗部会出现色带。

6.2 用脚本自动切换分辨率和刷新率

每次串流前手动改分辨率和刷新率很麻烦。可以写一个批处理脚本，在 moonlight 启动前自动把显示器设成串流需要的模式，退出后再改回来。Windows 下可以用QRes这个小工具，命令行调用。

# 串流前切换到 1080P 60Hz QRes.exe /x:1920 /y:1080 /r:60 # 启动 moonlight start "" "C:\Program Files\Moonlight\Moonlight.exe" # 等待 moonlight 退出 :wait tasklist | find /i "Moonlight.exe" >nul if not errorlevel 1 ( timeout /t 2 >nul goto wait ) # 串流结束后切回 4K 144Hz QRes.exe /x:3840 /y:2160 /r:144

这个脚本的逻辑是：先切分辨率，再启动 moonlight，然后循环检测 moonlight 进程是否还在，退出后切回原分辨率。QRes的参数/x是宽度，/y是高度，/r是刷新率。你可以根据自己的显示器型号调整。

6.3 验证延迟的三种方法

第一种是 moonlight 自带的统计面板，按Ctrl+Alt+Shift+S调出来，能看到解码延迟、网络延迟、渲染延迟。第二种是用高速摄像机拍屏幕和手柄操作，数帧数差。第三种是在服务端跑一个秒表程序，客户端看着秒表按截图，对比时间戳。

我一般用第一种，够直观。如果统计面板显示网络延迟低于 2 毫秒，解码低于 5 毫秒，渲染低于 3 毫秒，总延迟就在 10 毫秒以内，基本感觉不到。

6.4 我的习惯：先保稳定再压延迟

折腾串流这几年，我最大的教训是：不要一上来就追求极限参数。先把 1080P 60 帧跑稳，码率给足，确认网络不丢包，再逐步降码率、提分辨率、开 HDR。每次只改一个变量，改完跑十分钟，看统计面板的丢帧计数。丢帧数不为零，就回退。

另一个习惯是保留一份能用的配置文件备份。sunshine 的配置文件改崩了，直接覆盖回去，省得重装。moonlight 的配对信息也可以导出，换设备时不用重新配对。这套东西的坑大多在细节里，耐心比技术更重要。希望帮到你。

本文还有配套的精品资源，点击获取