1. 从一个被关掉的服务说起Sunshine 到底补上了什么坑NVIDIA 当年那套 GameStream 对很多人来说是第一次真正接触“把客厅电视当成第二块显示器”这件事。主机放在书房客厅只有一台电视和一个手柄游戏画面顺着网线跑到电视上延迟低到能打动作游戏。2023 年前后 NVIDIA 宣布逐步停止对 GameStream 的维护官方客户端从应用商店下架服务端也从驱动包里被摘掉一大批已经习惯这种玩法的用户突然发现自己手里的硬件还在但“回家”的路没了。Sunshine 就是在这条路上接棒的项目。它的定位非常明确重新实现一套与 GameStream 协议兼容的主机端服务让仍然活跃的 Moonlight 客户端可以继续配对、继续串流。GitHub 上四万颗星的体量不是靠情怀堆出来的而是因为它解决的是真实存在的、且没有官方替代品的需求。你不需要换显卡不需要买新的串流盒子只要主机端装一个 Sunshine、客户端装一个 Moonlight配对流程和当年几乎一模一样。这篇文章面向的读者大致分三类。第一类是手里已经有能跑游戏的 PC想把它变成一个“自托管云游戏服务器”的人第二类是被“AMD 处理器到底该下哪个安装包”这类问题卡住、搜索半天没找到明确答案的人第三类是想在自建环境里做低延迟串流、但对编码参数、网络配置一知半解的人。全文不涉及任何跨地域访问手段讨论范围严格限定在你自己能掌控的局域网或私有网络环境里。我个人的判断是Sunshine 真正的价值不在于“免费”而在于它把控制权还给了使用者。官方方案下线后你不是只能认命协议还在、客户端还在、硬件编码器还在缺的只是一个服务端实现而这个实现现在由社区维护迭代速度比当年的官方版本还快。理解这一点后面的所有配置和调优才有意义——你不是在“破解”什么你只是在用自己的机器跑一个开源服务。2. 选型逻辑为什么是 Sunshine而不是别的方案2.1 协议层兼容比功能堆料更重要市面上做串流的方案不少有商业的、有开源的、有基于浏览器推流的但选型的第一个判断标准不是谁功能多而是客户端兼容性。Sunshine 复用的是 GameStream 的协议族这意味着 Moonlight 这个已经迭代多年、覆盖 Windows、macOS、Linux、Android、iOS、tvOS 甚至部分嵌入式设备的客户端生态可以直接拿来用。你不需要给每台设备单独找客户端也不需要担心某个平台的客户端停止维护。这一点在实际使用中的差别非常大。我试过一些基于 WebRTC 的串流方案主机端配置确实简单但客户端往往只有一个浏览器页面手柄支持、HDR、多声道音频、按键映射这些东西要么缺失要么实现得很粗糙。而 Moonlight 的手柄处理已经打磨了很多年Xbox 手柄、DualSense、Switch Pro 手柄的震动和陀螺仪都能透传这是短时间堆不出来的积累。另一个被低估的点是协议层的成熟度。GameStream 协议在延迟控制、丢包恢复、动态码率这些方面有大量工程细节Sunshine 在复现过程中基本沿用了这套思路而不是重新发明一套。对于使用者来说这意味着你在网上翻到的老帖子、老经验很多仍然适用。2.2 自托管意味着哪些具体的好处“自托管”这个词现在被用得很泛落到 Sunshine 上其实是几件很具体的事。配置数据全部存在本地配对信息、应用列表、编码参数都在你自己的机器上没有第三方服务器参与握手串流链路是点对点的画面数据不经过任何中转节点版本升级由你自己决定不会某天早上打开发现服务端被下架了。这三点带来的直接结果是你的使用方式不会因为外部决策而改变。官方方案关停这件事本身就是最好的教训——当服务端不在你手里时你的使用习惯随时可能被一纸公告打断。Sunshine 的配置文件是纯文本你可以备份、可以版本管理、可以在多台机器之间同步这种可控性在长期使用中价值极高。还有一点容易被忽略自托管方案通常有更好的硬件利用率。你可以指定用哪块显卡的哪个编码器可以控制码率上限可以选择 H.264、HEVC 还是 AV1。商业方案往往把这些选择权收走给你一个“智能推荐”但对串流这种对参数极度敏感的场景来说能手动调才是刚需。2.3 主流主机端方案的横向对比下面这张表是我在几个常见方案之间做的对比判断维度都是实际使用中会踩到的点而不是纸面参数。对比维度Sunshine官方 GameStream浏览器推流类方案服务端维护状态社区活跃维护已停止视项目而定客户端生态Moonlight 全平台官方客户端已下架通常仅浏览器编码器支持NVENC / AMF / QSV / VAAPI / 软件仅 NVIDIA通常仅软件或单一硬件手柄透传完整含震动与陀螺仪完整支持有限HDR支持支持多数不支持配置可控性高纯文本配置低中多主机管理支持多实例不支持视实现而定从这张表能看出来Sunshine 的核心优势集中在编码器覆盖度和配置可控性上。前者决定了你的硬件能不能用后者决定了你能不能用得舒服。特别是编码器这一项直接关系到 AMD 用户能不能上车这也是下一节要重点展开的内容。3. AMD 平台安装包怎么选把 CPU 和 GPU 分开看3.1 一个被问爆的问题AMD 处理器该装哪个包“AMD 处理器选择哪个 Sunshine 安装包”这句话在搜索框里出现的频率非常高但这个问题本身藏着一个常见的认知偏差决定安装包选择的不是 CPU而是 GPU。串流画面的编码工作是由显卡承担的CPU 品牌在这里几乎不产生影响。你用的是锐龙还是酷睿只要显卡是同一块需要的安装包就是同一个。这个偏差之所以普遍是因为很多人习惯性地把“我的电脑是 AMD 的”当作一个整体标签。但在串流场景里CPU 主要负责的是系统调度、游戏逻辑、音频处理这些通用任务真正决定串流能不能跑起来、画质能到哪一档的是显卡上的硬件编码单元。所以正确的问法应该是“我的显卡是 AMD 的该装哪个包”。把这个问题捋清楚之后后面的判断就简单了。你需要确认的只有两件事主机上的显卡是哪家的以及你打算用哪种编码格式。3.2 判断依据三步确认你该用哪个包第一步确认主机端显卡品牌。Windows 上可以直接在任务管理器的性能标签页里看或者在显卡驱动控制面板里确认。如果你用的是带核显的 AMD 处理器且没有独显那么核显本身也是 AMD 的编码单元同样按 AMD 显卡处理。第二步确认你想用的编码格式。AMD 显卡走的是 AMF 编码器支持 H.264 和 HEVCAV1 编码需要较新的架构才具备。如果你打算用 HEVC 来降低码率需要确认显卡世代是否支持如果只打算用 H.264那绝大多数近几年的 AMD 显卡都能满足。第三步对照项目发布页选择安装包。Sunshine 的历史版本中曾经为 AMD 显卡单独提供过安装包原因是 AMF 相关的运行库需要额外打包而在较新的版本里官方倾向于把各家的编码器支持合并进统一安装包减少选择成本。所以正确做法是先去发布页看当前版本提供了哪几个安装包再决定下哪个而不是照着两年前的教程去点某个固定的文件名。提示如果你不确定当前版本是否还需要单独的 AMD 包可以先装标准包启动后在 Web 配置界面里查看编码器下拉列表。如果列表里能看到 AMF 相关选项说明当前包已经包含 AMD 支持如果只有 NVENC 或软件编码再换用标注了 AMD 的安装包。3.3 三条稳妥的安装路径与验证方法路径一标准包直装。这是最省事的做法适用于当前版本已经合并编码器支持的情况。装完之后进入 Web 配置界面在编码器选项里找 AMF 字样找到就说明可用。这个路径的好处是后续升级只需要替换同一个安装包不用每次重新判断该下哪个。路径二AMD 专用包。如果标准包里确实没有 AMF 选项就去发布页找带 AMD 标识的安装包。这类包通常会额外打包 AMF 运行库体积会略大一些。装完之后同样进 Web 界面验证编码器列表并且建议实际发起一次串流测试确认画面能正常输出而不是黑屏。路径三源码或包管理器安装。Linux 用户走这条路的比较多各发行版的仓库或者项目提供的安装脚本都能用。这种方式的好处是依赖关系由包管理器处理升级也走同一套流程。代价是需要手动处理一些权限配置比如编码设备节点的访问权限以及在某些桌面环境下需要额外的显示捕获配置。不管走哪条路径验证环节都不能省。具体的验证动作是启动服务端打开 Web 配置页面看编码器列表然后在客户端发起连接观察画面是否正常、帧率是否稳定、延迟是否在可接受范围。我在第一次配置 AMD 平台时就是跳过了验证环节结果客户端连上了但画面全黑排查了半天才发现是编码器选错了。3.4 显卡世代与编码能力的对应关系这张表用来快速判断你的显卡能支持到什么程度。具体型号的支持情况以官方文档为准这里给出的是大致规律。显卡世代H.264HEVCAV1备注较早期 AMD 独显支持部分支持不支持建议用 H.264中后期 AMD 独显支持支持不支持HEVC 可有效降码率较新 AMD 独显支持支持支持可尝试 AV1 进一步降码率NVIDIA 中端及以上支持支持较新世代支持NVENC 稳定性口碑较好Intel 核显支持部分支持较新世代支持QSV 路径功耗表现好从表里能看出来编码格式的选择本质上是码率、画质、兼容性三者之间的权衡。H.264 兼容性最好几乎所有客户端都能解但同码率下画质最差HEVC 在同等画质下能把码率压掉三成左右适合带宽紧张的场景AV1 更省带宽但对客户端解码能力有要求老设备可能跑不动。我在实际使用中的选择是局域网千兆有线环境用 HEVC码率给到 50 到 80 Mbps画质和延迟都能接受如果是无线连接或者带宽受限会降到 H.264 配合更低的码率牺牲一点画质换稳定。4. 从零跑通一次串流主机端部署全流程4.1 环境准备与依赖检查主机端准备工作的核心目标只有一个让编码器能稳定工作。围绕这个目标需要确认的东西其实不多但每一条都不能省。显卡驱动要更新到较新的稳定版本。这一点在 AMD 平台上尤其重要AMF 编码器的实现依赖驱动里的运行库驱动太旧可能出现编码器初始化失败、画面撕裂、偶发花屏这些问题。我不建议追最新的测试版驱动选一个发布了一段时间、口碑稳定的版本就好。系统层面的检查包括确认没有其他程序占用编码器资源关闭不必要的后台录制软件和直播推流工具这些程序会和 Sunshine 抢编码器。另外检查一下电源计划把主机设置成高性能或者平衡模式避免处理器降频影响游戏本身的帧率。网络方面主机端强烈建议走有线。这不是玄学无线链路的抖动对串流体验的影响远大于平均带宽的影响。你可以用一个很简单的测试来判断在主机上持续 ping 客户端设备几百个包看丢包率和延迟波动。如果波动超过几毫秒串流时大概率会出现卡顿。4.2 安装后必须做的四件事装完 Sunshine 之后有四件事必须做顺序不能乱。第一件设置 Web 界面的访问凭据。Sunshine 会启动一个本地 Web 服务用于配置默认监听在本机的一个端口上。第一次访问时会要求你设置用户名和密码这个凭据用来保护配置界面也用于后续的客户端配对。密码建议设得复杂一点因为如果主机在网络里可被访问配置界面就是入口。第二件确认服务以正确的权限运行。Windows 上一般以当前用户身份运行即可Linux 上要确保运行服务的用户有访问显卡设备和输入设备的权限通常需要把用户加入对应的用户组或者在服务配置里显式指定。权限不到位最典型的表现是编码器列表为空或者启动后立刻退出。第三件配置防火墙放行。Windows 上安装程序一般会自动添加规则但如果你的网络环境被系统识别为“公用网络”规则可能不会生效。需要手动确认相关端口的入站规则已启用。这一条是“客户端一直显示正在连接但连不上”的最常见原因。第四件添加你要串流的应用。Sunshine 通过一个应用列表来管理可启动的程序你可以手动添加游戏的可执行文件也可以直接添加桌面会话。添加桌面会话的好处是灵活任何程序都能通过它串流坏处是主机上的任何操作都会同步到客户端隐私上要自己注意。配置文件的路径分别在Windows 上通常在安装目录下的 config 子目录Linux 上在用户配置目录下的 sunshine 文件夹。这个文件是纯文本可以直接编辑也方便备份。4.3 编码参数怎么算码率、帧率、编码格式码率是串流里最容易被拍脑袋设置的参数但它其实是可以算的。基本公式是码率(Mbps) 分辨率宽 × 高 × 帧率 × 每像素比特数 ÷ 1,000,000每像素比特数反映了压缩效率不同编码格式和分辨率下经验值差别很大。1080p 分辨率下大致在 0.15 到 0.24K 分辨率下因为空间冗余更多可以降到 0.1 到 0.12。按这个公式算几个常见场景1080p60 用 H.264取 0.16 的系数得到 1920×1080×60×0.16÷1e6约等于 19.9 Mbps所以 20 Mbps 是个合理起点。4K60 用 HEVC取 0.11得到 3840×2160×60×0.11÷1e6约等于 54.7 Mbps所以 50 到 60 Mbps 是合理区间。1440p60 用 HEVC 取 0.12约等于 35.8 Mbps给 35 到 40 Mbps 比较稳妥。注意这只是起点不是终点。实际码率还要看游戏类型。快速运动的画面赛车、射击需要更高码率才能避免块状伪影静态画面多的游戏可以适当降低。如果看到画面在快速转动视角时出现明显马赛克说明码率不够。帧率方面建议和主机显示器的刷新率保持一致避免不必要的帧率转换。如果你的显示器是 120Hz客户端也支持 120Hz那就可以直接给到 120串流链路在局域网下支撑这个帧率没什么问题。但要注意帧率翻倍意味着码率需求也跟着上去4K120 的码率需求是 4K60 的两倍左右。编码格式的选择在前一节已经说过这里补充一个实践细节HEVC 在部分老客户端上会出现解码延迟偏高的问题。判断方法是看客户端显示的延迟统计如果网络延迟很低但总延迟偏高很可能是解码端在拖后腿这时候换回 H.264 反而更流畅。4.4 客户端配对与首次连接配对流程和当年用官方方案时几乎一样。客户端启动后会自动搜索局域网内的主机找到之后点击配对客户端会显示一个四位数的 PIN 码。回到主机的 Web 配置界面在配对页面输入这个 PIN配对就完成了。如果自动搜索不到主机可以手动添加 IP 地址。这一步失败的话按顺序检查主机端服务是否在运行、防火墙是否放行、两台设备是否在同一个网段、主机的网络配置文件类型是否正确。这四项排查完绝大多数连不上的问题都能定位。首次连接成功后我建议先做一次基线测试选一个负载不重的游戏把码率设低一点比如 15 Mbps帧率设成 60编码格式先用 H.264连上去看基本画面是否正常、音频是否正常、手柄是否符合预期。这个基线跑通之后再逐步往上调参数每调一项就测试一次。一次性把所有参数拉到最高再去排查问题会非常痛苦因为你不知道是哪一项导致的。5. 画质、延迟、稳定性三角平衡的调优实录5.1 编码器与延迟的真实关系很多人以为延迟主要来自网络实际上在局域网环境下编码和解码才是延迟的大头。编码器从拿到画面到输出压缩码流需要时间解码端从收到码流到还原出画面也需要时间这两段加起来往往比网络传输时间长得多。大致的时间分布是这样的主机端编码 5 到 15 毫秒取决于编码格式和硬件性能网络传输在有线局域网下 1 到 3 毫秒客户端解码 5 到 15 毫秒取决于客户端芯片的解码能力显示链路 10 到 20 毫秒取决于电视或显示器的处理延迟。加起来大概 25 到 50 毫秒这是比较典型的水平。从这个分布能得出两个调优方向。一是减少编码层级选择硬件编码器而不是软件编码软件编码在 4K 场景下延迟会飙到几十毫秒。二是优化显示链路如果客户端是电视把电视切到游戏模式能砍掉十几毫秒的延迟这个收益比调码率大得多。还有一个容易被忽略的点编码器的预设级别。部分编码器提供速度优先和画质优先的预设速度优先的预设编码更快、延迟更低但同码率下画质略差。在串流场景里我一般会倾向速度优先因为延迟的感知比画质的细微差异明显得多。5.2 网络侧的几个关键开关网络配置里有几个开关对串流体验影响很大但经常被忽略。第一个是有线优先原则。主机端尽量走网线这一点前面说过。如果客户端也只能无线那就尽量让客户端离路由器近并使用 5GHz 频段。2.4GHz 频段在串流场景下基本不可用带宽和稳定性都不够。第二个是关闭路由器的节能相关功能。部分路由器有节能以太网或者空闲降速的功能会在流量低谷时降低链路速率等流量上来再恢复这个恢复过程会造成卡顿。在路由器设置里关掉这些功能串流稳定性会明显改善。第三个是给主机设置固定的局域网地址。不管是静态地址还是地址保留目的都是让客户端的连接目标保持稳定。用动态地址的话主机重启后地址可能变化客户端就需要重新搜索。第四个是避免网络中的其他大流量任务。串流对带宽的占用是持续的如果有其他设备在同一时间做大量下载或上传会挤压串流的可用带宽表现为周期性的卡顿。这个问题的解决方案要么是给串流设备做优先级标记要么就是在串流时避开大流量任务。5.3 主机侧的性能取舍主机在串流时承担的是双份工作一边跑游戏一边编码。这两件事都会吃 GPU 资源需要做一些取舍。比较有效的做法是给游戏帧率设一个上限。如果游戏本身能跑到 144 帧但客户端只显示 60 帧那多出来的帧数只是白白消耗 GPU 资源还可能让编码器来不及处理。把游戏帧率限制在客户端需求的水平能明显降低 GPU 占用编码延迟也会更稳定。另一个做法是适当降低游戏内的画质设置。这不是为了编码器减负而是为了给编码留出足够的 GPU 余量。如果 GPU 已经跑满编码任务就要排队延迟会突然升高。我一般会把 GPU 占用控制在 85% 以内给编码留出空间。散热也是要考虑的。持续串流时主机是长时间高负载运行如果散热跟不上导致降频画面会周期性卡顿。清理一下机箱灰尘、检查风扇转速这些基础工作比调参更有效。5.4 外设透传与手柄映射手柄的问题主要集中在两类连接方式和按键映射。连接方式上手柄接在客户端还是主机端体验差别很大。接在客户端的话输入信号通过串流链路传到主机延迟取决于网络接在主机端的话输入是本地处理延迟最低但你在客厅操作手柄就得考虑无线接收器的覆盖范围。我的做法是把无线接收器插在主机上用手柄自带的无线连接主机这样输入延迟最低。按键映射上Moonlight 客户端通常自带映射界面可以把手柄按键映射成键盘鼠标操作这对那些不支持手柄的游戏很有用。配置时要注意的是映射是在客户端侧完成的主机看到的只是虚拟输入设备如果映射不生效先检查客户端是不是保存了配置。震动和陀螺仪的透传需要客户端和服务端都支持。震动一般在连接建立后就能用陀螺仪则需要在客户端设置里显式开启。如果发现震动不工作可以尝试在客户端里切换输入模式有时候换一种模式就能解决。6. 常见问题排查黑屏、花屏、连不上、音频跑丢6.1 连不上与配对失败这是最高频的问题排查顺序建议固定下来避免东试一下西试一下。先看主机端服务是否在运行最简单的判断方法是访问本机的配置界面能打开就说明服务起来了。再看防火墙这是重灾区尤其是网络类型被识别成公用网络的时候规则不生效。接着确认两台设备的地址段如果主机是 192.168.1.x 而客户端是 192.168.0.x那中间可能隔了一层路由需要调整网络拓扑。最后检查主机是不是休眠或者睡眠了这个属于低级错误但确实常见。配对失败还有一种是 PIN 码输入后提示错误。这种情况多半是 PIN 码过期了客户端重新生成一个再输就行。如果反复失败可以试着在主机端清除已有的配对记录重新走一遍流程。6.2 画面类问题黑屏、花屏、卡顿黑屏是第二高频问题原因通常有三类。一是编码器选错了比如在 AMD 显卡上选了 NVENC编码器初始化失败但服务没有报错客户端连上就是黑的。二是 HDR 状态不匹配主机开了 HDR 而客户端不支持或者反过来。三是显示捕获方式的问题Linux 上尤其容易遇到需要根据桌面环境选择合适的捕获方式。花屏通常和码率、网络有关。如果花屏是偶发的、伴随画面马赛克基本可以判断是带宽不足或者丢包。降低码率、改用有线连接、检查网络中的干扰源按这个顺序排查。如果花屏是持续性的、特定区域异常那可能是编码器本身的 bug 或者驱动问题换一种编码格式试试。卡顿要区分是网络卡顿还是渲染卡顿。客户端一般会显示延迟统计如果网络延迟稳定但画面周期性地顿一下那是主机侧的渲染或者编码在掉帧需要检查主机 GPU 占用和散热。如果延迟统计本身就忽高忽低那就是网络问题。6.3 音频与输入设备类问题音频丢失的典型表现是客户端有画面没声音或者声音从主机音箱出来了。这个问题的根源是音频输出设备的选择。串流需要在主机上创建一个虚拟音频设备作为输出目标把声音送到这个设备上编码后再传给客户端。如果主机默认输出设备是音箱声音自然就走音箱了。解决方法是手动把默认音频输出切换到虚拟设备或者在 Sunshine 的配置里指定音频设备。注意有些系统会在设备切换后自动改回去需要在声音设置里把虚拟设备设为默认。手柄无响应或者按键错乱一般是客户端没有正确识别设备或者映射配置冲突。先在客户端里看设备列表能不能识别到手柄能识别但按键不对就检查映射不能识别就换一种连接方式试试。6.4 常见问题速查表现象可能原因优先排查动作客户端搜不到主机防火墙未放行 / 不同网段检查入站规则与地址段配对提示 PIN 错误PIN 过期 / 记录冲突清除配对记录重新生成连上后黑屏编码器选错 / HDR 不匹配换编码器统一 HDR 状态画面周期性花屏带宽不足 / 丢包降码率改有线连接画面偶发卡顿主机 GPU 打满 / 散热降频限帧检查温度客户端无声音音频设备选择错误切换默认输出到虚拟设备手柄无响应设备未识别 / 映射冲突检查客户端设备列表延迟忽高忽低无线链路抖动改有线远离干扰源这张表建议保存下来遇到问题先对照能省掉大量无效试错。7. 长期维护升级、备份和扩展玩法7.1 版本升级与配置备份Sunshine 的版本迭代比较频繁但升级这件事不建议盲目跟。我的做法是稳定运行中的版本除非遇到明确影响使用的 bug 或者需要某个新功能否则不主动升。串流配置涉及的变量很多升级引入的行为变化可能让原本调好的参数失效。如果确实要升级先备份配置文件。配置目录下的配置文件和应用列表都要备份最好连同配对信息一起。升级之后先验证编码器列表是否正常再跑一次基线测试确认没问题再恢复日常使用。降级也要做好准备。有些版本在某些显卡上表现更好如果升级后体验变差回退到之前的版本是合理选择。保留上一版的安装包是个好习惯。7.2 多主机与多客户端的管理思路家里如果有多台能跑游戏的机器每台都可以装一份 Sunshine用同一个客户端去连。管理上的关键是给每台主机起一个能分辨的名字避免在客户端列表里看到一堆相似的名字不知道点哪个。多客户端的情况更常见客厅电视、卧室平板、手机、笔记本都可能连过来。需要注意的是不同客户端的解码能力差别很大手机可能只支持 H.264电视可能支持 HEVC 但不支持 AV1。如果配置是全局的就很难兼顾。较新版本支持针对不同客户端做差异化配置可以用起来。另一个实践建议是给不同的使用场景建不同的应用条目。比如一个条目直接启动游戏另一个条目启动桌面会话。这样在客户端选择的时候一目了然不用每次都在桌面上手动点开。7.3 后续还能怎么玩跑通基础串流之后还有不少可以扩展的方向。一是把主机做成常驻的游戏服务器。主机长期开机配合远程唤醒客户端随时连上就能玩。这需要对电源管理和系统休眠做一番配置但一旦跑通体验非常接近真正的云游戏。二是多显示器与虚拟显示。如果主机平时接着显示器串流时希望以另一个分辨率输出可以配置虚拟显示设备让串流链路使用独立的分辨率和刷新率不受物理显示器限制。这个方案在无头运行主机不接显示器的场景下几乎是必需的因为部分显卡在没有显示输出的情况下编码器无法正常工作。三是外设扩展。除了手柄还可以把方向盘、飞行摇杆这类设备接在客户端通过串流链路透传到主机。这类设备的透传支持程度取决于客户端实现需要逐个测试。四是串流质量的量化监控。客户端通常会显示延迟、丢包、码率这些统计定期记录这些数据能帮你在问题出现之前发现趋势。比如延迟逐渐升高可能是主机散热在退化早发现早处理。我在把主机改成常驻服务器之后最大的体会是串流的体验瓶颈往往不在技术上而在习惯上。参数调到一个“够用且稳定”的水平之后就不该再频繁折腾了把时间留给游戏本身。那些花在反复对比码率差异上的时间远不如把网线换成六类线、把路由器换个位置来得实在。
Sunshine 自托管串流：AMD 安装包选择与低延迟调优
1. 从一个被关掉的服务说起Sunshine 到底补上了什么坑NVIDIA 当年那套 GameStream 对很多人来说是第一次真正接触“把客厅电视当成第二块显示器”这件事。主机放在书房客厅只有一台电视和一个手柄游戏画面顺着网线跑到电视上延迟低到能打动作游戏。2023 年前后 NVIDIA 宣布逐步停止对 GameStream 的维护官方客户端从应用商店下架服务端也从驱动包里被摘掉一大批已经习惯这种玩法的用户突然发现自己手里的硬件还在但“回家”的路没了。Sunshine 就是在这条路上接棒的项目。它的定位非常明确重新实现一套与 GameStream 协议兼容的主机端服务让仍然活跃的 Moonlight 客户端可以继续配对、继续串流。GitHub 上四万颗星的体量不是靠情怀堆出来的而是因为它解决的是真实存在的、且没有官方替代品的需求。你不需要换显卡不需要买新的串流盒子只要主机端装一个 Sunshine、客户端装一个 Moonlight配对流程和当年几乎一模一样。这篇文章面向的读者大致分三类。第一类是手里已经有能跑游戏的 PC想把它变成一个“自托管云游戏服务器”的人第二类是被“AMD 处理器到底该下哪个安装包”这类问题卡住、搜索半天没找到明确答案的人第三类是想在自建环境里做低延迟串流、但对编码参数、网络配置一知半解的人。全文不涉及任何跨地域访问手段讨论范围严格限定在你自己能掌控的局域网或私有网络环境里。我个人的判断是Sunshine 真正的价值不在于“免费”而在于它把控制权还给了使用者。官方方案下线后你不是只能认命协议还在、客户端还在、硬件编码器还在缺的只是一个服务端实现而这个实现现在由社区维护迭代速度比当年的官方版本还快。理解这一点后面的所有配置和调优才有意义——你不是在“破解”什么你只是在用自己的机器跑一个开源服务。2. 选型逻辑为什么是 Sunshine而不是别的方案2.1 协议层兼容比功能堆料更重要市面上做串流的方案不少有商业的、有开源的、有基于浏览器推流的但选型的第一个判断标准不是谁功能多而是客户端兼容性。Sunshine 复用的是 GameStream 的协议族这意味着 Moonlight 这个已经迭代多年、覆盖 Windows、macOS、Linux、Android、iOS、tvOS 甚至部分嵌入式设备的客户端生态可以直接拿来用。你不需要给每台设备单独找客户端也不需要担心某个平台的客户端停止维护。这一点在实际使用中的差别非常大。我试过一些基于 WebRTC 的串流方案主机端配置确实简单但客户端往往只有一个浏览器页面手柄支持、HDR、多声道音频、按键映射这些东西要么缺失要么实现得很粗糙。而 Moonlight 的手柄处理已经打磨了很多年Xbox 手柄、DualSense、Switch Pro 手柄的震动和陀螺仪都能透传这是短时间堆不出来的积累。另一个被低估的点是协议层的成熟度。GameStream 协议在延迟控制、丢包恢复、动态码率这些方面有大量工程细节Sunshine 在复现过程中基本沿用了这套思路而不是重新发明一套。对于使用者来说这意味着你在网上翻到的老帖子、老经验很多仍然适用。2.2 自托管意味着哪些具体的好处“自托管”这个词现在被用得很泛落到 Sunshine 上其实是几件很具体的事。配置数据全部存在本地配对信息、应用列表、编码参数都在你自己的机器上没有第三方服务器参与握手串流链路是点对点的画面数据不经过任何中转节点版本升级由你自己决定不会某天早上打开发现服务端被下架了。这三点带来的直接结果是你的使用方式不会因为外部决策而改变。官方方案关停这件事本身就是最好的教训——当服务端不在你手里时你的使用习惯随时可能被一纸公告打断。Sunshine 的配置文件是纯文本你可以备份、可以版本管理、可以在多台机器之间同步这种可控性在长期使用中价值极高。还有一点容易被忽略自托管方案通常有更好的硬件利用率。你可以指定用哪块显卡的哪个编码器可以控制码率上限可以选择 H.264、HEVC 还是 AV1。商业方案往往把这些选择权收走给你一个“智能推荐”但对串流这种对参数极度敏感的场景来说能手动调才是刚需。2.3 主流主机端方案的横向对比下面这张表是我在几个常见方案之间做的对比判断维度都是实际使用中会踩到的点而不是纸面参数。对比维度Sunshine官方 GameStream浏览器推流类方案服务端维护状态社区活跃维护已停止视项目而定客户端生态Moonlight 全平台官方客户端已下架通常仅浏览器编码器支持NVENC / AMF / QSV / VAAPI / 软件仅 NVIDIA通常仅软件或单一硬件手柄透传完整含震动与陀螺仪完整支持有限HDR支持支持多数不支持配置可控性高纯文本配置低中多主机管理支持多实例不支持视实现而定从这张表能看出来Sunshine 的核心优势集中在编码器覆盖度和配置可控性上。前者决定了你的硬件能不能用后者决定了你能不能用得舒服。特别是编码器这一项直接关系到 AMD 用户能不能上车这也是下一节要重点展开的内容。3. AMD 平台安装包怎么选把 CPU 和 GPU 分开看3.1 一个被问爆的问题AMD 处理器该装哪个包“AMD 处理器选择哪个 Sunshine 安装包”这句话在搜索框里出现的频率非常高但这个问题本身藏着一个常见的认知偏差决定安装包选择的不是 CPU而是 GPU。串流画面的编码工作是由显卡承担的CPU 品牌在这里几乎不产生影响。你用的是锐龙还是酷睿只要显卡是同一块需要的安装包就是同一个。这个偏差之所以普遍是因为很多人习惯性地把“我的电脑是 AMD 的”当作一个整体标签。但在串流场景里CPU 主要负责的是系统调度、游戏逻辑、音频处理这些通用任务真正决定串流能不能跑起来、画质能到哪一档的是显卡上的硬件编码单元。所以正确的问法应该是“我的显卡是 AMD 的该装哪个包”。把这个问题捋清楚之后后面的判断就简单了。你需要确认的只有两件事主机上的显卡是哪家的以及你打算用哪种编码格式。3.2 判断依据三步确认你该用哪个包第一步确认主机端显卡品牌。Windows 上可以直接在任务管理器的性能标签页里看或者在显卡驱动控制面板里确认。如果你用的是带核显的 AMD 处理器且没有独显那么核显本身也是 AMD 的编码单元同样按 AMD 显卡处理。第二步确认你想用的编码格式。AMD 显卡走的是 AMF 编码器支持 H.264 和 HEVCAV1 编码需要较新的架构才具备。如果你打算用 HEVC 来降低码率需要确认显卡世代是否支持如果只打算用 H.264那绝大多数近几年的 AMD 显卡都能满足。第三步对照项目发布页选择安装包。Sunshine 的历史版本中曾经为 AMD 显卡单独提供过安装包原因是 AMF 相关的运行库需要额外打包而在较新的版本里官方倾向于把各家的编码器支持合并进统一安装包减少选择成本。所以正确做法是先去发布页看当前版本提供了哪几个安装包再决定下哪个而不是照着两年前的教程去点某个固定的文件名。提示如果你不确定当前版本是否还需要单独的 AMD 包可以先装标准包启动后在 Web 配置界面里查看编码器下拉列表。如果列表里能看到 AMF 相关选项说明当前包已经包含 AMD 支持如果只有 NVENC 或软件编码再换用标注了 AMD 的安装包。3.3 三条稳妥的安装路径与验证方法路径一标准包直装。这是最省事的做法适用于当前版本已经合并编码器支持的情况。装完之后进入 Web 配置界面在编码器选项里找 AMF 字样找到就说明可用。这个路径的好处是后续升级只需要替换同一个安装包不用每次重新判断该下哪个。路径二AMD 专用包。如果标准包里确实没有 AMF 选项就去发布页找带 AMD 标识的安装包。这类包通常会额外打包 AMF 运行库体积会略大一些。装完之后同样进 Web 界面验证编码器列表并且建议实际发起一次串流测试确认画面能正常输出而不是黑屏。路径三源码或包管理器安装。Linux 用户走这条路的比较多各发行版的仓库或者项目提供的安装脚本都能用。这种方式的好处是依赖关系由包管理器处理升级也走同一套流程。代价是需要手动处理一些权限配置比如编码设备节点的访问权限以及在某些桌面环境下需要额外的显示捕获配置。不管走哪条路径验证环节都不能省。具体的验证动作是启动服务端打开 Web 配置页面看编码器列表然后在客户端发起连接观察画面是否正常、帧率是否稳定、延迟是否在可接受范围。我在第一次配置 AMD 平台时就是跳过了验证环节结果客户端连上了但画面全黑排查了半天才发现是编码器选错了。3.4 显卡世代与编码能力的对应关系这张表用来快速判断你的显卡能支持到什么程度。具体型号的支持情况以官方文档为准这里给出的是大致规律。显卡世代H.264HEVCAV1备注较早期 AMD 独显支持部分支持不支持建议用 H.264中后期 AMD 独显支持支持不支持HEVC 可有效降码率较新 AMD 独显支持支持支持可尝试 AV1 进一步降码率NVIDIA 中端及以上支持支持较新世代支持NVENC 稳定性口碑较好Intel 核显支持部分支持较新世代支持QSV 路径功耗表现好从表里能看出来编码格式的选择本质上是码率、画质、兼容性三者之间的权衡。H.264 兼容性最好几乎所有客户端都能解但同码率下画质最差HEVC 在同等画质下能把码率压掉三成左右适合带宽紧张的场景AV1 更省带宽但对客户端解码能力有要求老设备可能跑不动。我在实际使用中的选择是局域网千兆有线环境用 HEVC码率给到 50 到 80 Mbps画质和延迟都能接受如果是无线连接或者带宽受限会降到 H.264 配合更低的码率牺牲一点画质换稳定。4. 从零跑通一次串流主机端部署全流程4.1 环境准备与依赖检查主机端准备工作的核心目标只有一个让编码器能稳定工作。围绕这个目标需要确认的东西其实不多但每一条都不能省。显卡驱动要更新到较新的稳定版本。这一点在 AMD 平台上尤其重要AMF 编码器的实现依赖驱动里的运行库驱动太旧可能出现编码器初始化失败、画面撕裂、偶发花屏这些问题。我不建议追最新的测试版驱动选一个发布了一段时间、口碑稳定的版本就好。系统层面的检查包括确认没有其他程序占用编码器资源关闭不必要的后台录制软件和直播推流工具这些程序会和 Sunshine 抢编码器。另外检查一下电源计划把主机设置成高性能或者平衡模式避免处理器降频影响游戏本身的帧率。网络方面主机端强烈建议走有线。这不是玄学无线链路的抖动对串流体验的影响远大于平均带宽的影响。你可以用一个很简单的测试来判断在主机上持续 ping 客户端设备几百个包看丢包率和延迟波动。如果波动超过几毫秒串流时大概率会出现卡顿。4.2 安装后必须做的四件事装完 Sunshine 之后有四件事必须做顺序不能乱。第一件设置 Web 界面的访问凭据。Sunshine 会启动一个本地 Web 服务用于配置默认监听在本机的一个端口上。第一次访问时会要求你设置用户名和密码这个凭据用来保护配置界面也用于后续的客户端配对。密码建议设得复杂一点因为如果主机在网络里可被访问配置界面就是入口。第二件确认服务以正确的权限运行。Windows 上一般以当前用户身份运行即可Linux 上要确保运行服务的用户有访问显卡设备和输入设备的权限通常需要把用户加入对应的用户组或者在服务配置里显式指定。权限不到位最典型的表现是编码器列表为空或者启动后立刻退出。第三件配置防火墙放行。Windows 上安装程序一般会自动添加规则但如果你的网络环境被系统识别为“公用网络”规则可能不会生效。需要手动确认相关端口的入站规则已启用。这一条是“客户端一直显示正在连接但连不上”的最常见原因。第四件添加你要串流的应用。Sunshine 通过一个应用列表来管理可启动的程序你可以手动添加游戏的可执行文件也可以直接添加桌面会话。添加桌面会话的好处是灵活任何程序都能通过它串流坏处是主机上的任何操作都会同步到客户端隐私上要自己注意。配置文件的路径分别在Windows 上通常在安装目录下的 config 子目录Linux 上在用户配置目录下的 sunshine 文件夹。这个文件是纯文本可以直接编辑也方便备份。4.3 编码参数怎么算码率、帧率、编码格式码率是串流里最容易被拍脑袋设置的参数但它其实是可以算的。基本公式是码率(Mbps) 分辨率宽 × 高 × 帧率 × 每像素比特数 ÷ 1,000,000每像素比特数反映了压缩效率不同编码格式和分辨率下经验值差别很大。1080p 分辨率下大致在 0.15 到 0.24K 分辨率下因为空间冗余更多可以降到 0.1 到 0.12。按这个公式算几个常见场景1080p60 用 H.264取 0.16 的系数得到 1920×1080×60×0.16÷1e6约等于 19.9 Mbps所以 20 Mbps 是个合理起点。4K60 用 HEVC取 0.11得到 3840×2160×60×0.11÷1e6约等于 54.7 Mbps所以 50 到 60 Mbps 是合理区间。1440p60 用 HEVC 取 0.12约等于 35.8 Mbps给 35 到 40 Mbps 比较稳妥。注意这只是起点不是终点。实际码率还要看游戏类型。快速运动的画面赛车、射击需要更高码率才能避免块状伪影静态画面多的游戏可以适当降低。如果看到画面在快速转动视角时出现明显马赛克说明码率不够。帧率方面建议和主机显示器的刷新率保持一致避免不必要的帧率转换。如果你的显示器是 120Hz客户端也支持 120Hz那就可以直接给到 120串流链路在局域网下支撑这个帧率没什么问题。但要注意帧率翻倍意味着码率需求也跟着上去4K120 的码率需求是 4K60 的两倍左右。编码格式的选择在前一节已经说过这里补充一个实践细节HEVC 在部分老客户端上会出现解码延迟偏高的问题。判断方法是看客户端显示的延迟统计如果网络延迟很低但总延迟偏高很可能是解码端在拖后腿这时候换回 H.264 反而更流畅。4.4 客户端配对与首次连接配对流程和当年用官方方案时几乎一样。客户端启动后会自动搜索局域网内的主机找到之后点击配对客户端会显示一个四位数的 PIN 码。回到主机的 Web 配置界面在配对页面输入这个 PIN配对就完成了。如果自动搜索不到主机可以手动添加 IP 地址。这一步失败的话按顺序检查主机端服务是否在运行、防火墙是否放行、两台设备是否在同一个网段、主机的网络配置文件类型是否正确。这四项排查完绝大多数连不上的问题都能定位。首次连接成功后我建议先做一次基线测试选一个负载不重的游戏把码率设低一点比如 15 Mbps帧率设成 60编码格式先用 H.264连上去看基本画面是否正常、音频是否正常、手柄是否符合预期。这个基线跑通之后再逐步往上调参数每调一项就测试一次。一次性把所有参数拉到最高再去排查问题会非常痛苦因为你不知道是哪一项导致的。5. 画质、延迟、稳定性三角平衡的调优实录5.1 编码器与延迟的真实关系很多人以为延迟主要来自网络实际上在局域网环境下编码和解码才是延迟的大头。编码器从拿到画面到输出压缩码流需要时间解码端从收到码流到还原出画面也需要时间这两段加起来往往比网络传输时间长得多。大致的时间分布是这样的主机端编码 5 到 15 毫秒取决于编码格式和硬件性能网络传输在有线局域网下 1 到 3 毫秒客户端解码 5 到 15 毫秒取决于客户端芯片的解码能力显示链路 10 到 20 毫秒取决于电视或显示器的处理延迟。加起来大概 25 到 50 毫秒这是比较典型的水平。从这个分布能得出两个调优方向。一是减少编码层级选择硬件编码器而不是软件编码软件编码在 4K 场景下延迟会飙到几十毫秒。二是优化显示链路如果客户端是电视把电视切到游戏模式能砍掉十几毫秒的延迟这个收益比调码率大得多。还有一个容易被忽略的点编码器的预设级别。部分编码器提供速度优先和画质优先的预设速度优先的预设编码更快、延迟更低但同码率下画质略差。在串流场景里我一般会倾向速度优先因为延迟的感知比画质的细微差异明显得多。5.2 网络侧的几个关键开关网络配置里有几个开关对串流体验影响很大但经常被忽略。第一个是有线优先原则。主机端尽量走网线这一点前面说过。如果客户端也只能无线那就尽量让客户端离路由器近并使用 5GHz 频段。2.4GHz 频段在串流场景下基本不可用带宽和稳定性都不够。第二个是关闭路由器的节能相关功能。部分路由器有节能以太网或者空闲降速的功能会在流量低谷时降低链路速率等流量上来再恢复这个恢复过程会造成卡顿。在路由器设置里关掉这些功能串流稳定性会明显改善。第三个是给主机设置固定的局域网地址。不管是静态地址还是地址保留目的都是让客户端的连接目标保持稳定。用动态地址的话主机重启后地址可能变化客户端就需要重新搜索。第四个是避免网络中的其他大流量任务。串流对带宽的占用是持续的如果有其他设备在同一时间做大量下载或上传会挤压串流的可用带宽表现为周期性的卡顿。这个问题的解决方案要么是给串流设备做优先级标记要么就是在串流时避开大流量任务。5.3 主机侧的性能取舍主机在串流时承担的是双份工作一边跑游戏一边编码。这两件事都会吃 GPU 资源需要做一些取舍。比较有效的做法是给游戏帧率设一个上限。如果游戏本身能跑到 144 帧但客户端只显示 60 帧那多出来的帧数只是白白消耗 GPU 资源还可能让编码器来不及处理。把游戏帧率限制在客户端需求的水平能明显降低 GPU 占用编码延迟也会更稳定。另一个做法是适当降低游戏内的画质设置。这不是为了编码器减负而是为了给编码留出足够的 GPU 余量。如果 GPU 已经跑满编码任务就要排队延迟会突然升高。我一般会把 GPU 占用控制在 85% 以内给编码留出空间。散热也是要考虑的。持续串流时主机是长时间高负载运行如果散热跟不上导致降频画面会周期性卡顿。清理一下机箱灰尘、检查风扇转速这些基础工作比调参更有效。5.4 外设透传与手柄映射手柄的问题主要集中在两类连接方式和按键映射。连接方式上手柄接在客户端还是主机端体验差别很大。接在客户端的话输入信号通过串流链路传到主机延迟取决于网络接在主机端的话输入是本地处理延迟最低但你在客厅操作手柄就得考虑无线接收器的覆盖范围。我的做法是把无线接收器插在主机上用手柄自带的无线连接主机这样输入延迟最低。按键映射上Moonlight 客户端通常自带映射界面可以把手柄按键映射成键盘鼠标操作这对那些不支持手柄的游戏很有用。配置时要注意的是映射是在客户端侧完成的主机看到的只是虚拟输入设备如果映射不生效先检查客户端是不是保存了配置。震动和陀螺仪的透传需要客户端和服务端都支持。震动一般在连接建立后就能用陀螺仪则需要在客户端设置里显式开启。如果发现震动不工作可以尝试在客户端里切换输入模式有时候换一种模式就能解决。6. 常见问题排查黑屏、花屏、连不上、音频跑丢6.1 连不上与配对失败这是最高频的问题排查顺序建议固定下来避免东试一下西试一下。先看主机端服务是否在运行最简单的判断方法是访问本机的配置界面能打开就说明服务起来了。再看防火墙这是重灾区尤其是网络类型被识别成公用网络的时候规则不生效。接着确认两台设备的地址段如果主机是 192.168.1.x 而客户端是 192.168.0.x那中间可能隔了一层路由需要调整网络拓扑。最后检查主机是不是休眠或者睡眠了这个属于低级错误但确实常见。配对失败还有一种是 PIN 码输入后提示错误。这种情况多半是 PIN 码过期了客户端重新生成一个再输就行。如果反复失败可以试着在主机端清除已有的配对记录重新走一遍流程。6.2 画面类问题黑屏、花屏、卡顿黑屏是第二高频问题原因通常有三类。一是编码器选错了比如在 AMD 显卡上选了 NVENC编码器初始化失败但服务没有报错客户端连上就是黑的。二是 HDR 状态不匹配主机开了 HDR 而客户端不支持或者反过来。三是显示捕获方式的问题Linux 上尤其容易遇到需要根据桌面环境选择合适的捕获方式。花屏通常和码率、网络有关。如果花屏是偶发的、伴随画面马赛克基本可以判断是带宽不足或者丢包。降低码率、改用有线连接、检查网络中的干扰源按这个顺序排查。如果花屏是持续性的、特定区域异常那可能是编码器本身的 bug 或者驱动问题换一种编码格式试试。卡顿要区分是网络卡顿还是渲染卡顿。客户端一般会显示延迟统计如果网络延迟稳定但画面周期性地顿一下那是主机侧的渲染或者编码在掉帧需要检查主机 GPU 占用和散热。如果延迟统计本身就忽高忽低那就是网络问题。6.3 音频与输入设备类问题音频丢失的典型表现是客户端有画面没声音或者声音从主机音箱出来了。这个问题的根源是音频输出设备的选择。串流需要在主机上创建一个虚拟音频设备作为输出目标把声音送到这个设备上编码后再传给客户端。如果主机默认输出设备是音箱声音自然就走音箱了。解决方法是手动把默认音频输出切换到虚拟设备或者在 Sunshine 的配置里指定音频设备。注意有些系统会在设备切换后自动改回去需要在声音设置里把虚拟设备设为默认。手柄无响应或者按键错乱一般是客户端没有正确识别设备或者映射配置冲突。先在客户端里看设备列表能不能识别到手柄能识别但按键不对就检查映射不能识别就换一种连接方式试试。6.4 常见问题速查表现象可能原因优先排查动作客户端搜不到主机防火墙未放行 / 不同网段检查入站规则与地址段配对提示 PIN 错误PIN 过期 / 记录冲突清除配对记录重新生成连上后黑屏编码器选错 / HDR 不匹配换编码器统一 HDR 状态画面周期性花屏带宽不足 / 丢包降码率改有线连接画面偶发卡顿主机 GPU 打满 / 散热降频限帧检查温度客户端无声音音频设备选择错误切换默认输出到虚拟设备手柄无响应设备未识别 / 映射冲突检查客户端设备列表延迟忽高忽低无线链路抖动改有线远离干扰源这张表建议保存下来遇到问题先对照能省掉大量无效试错。7. 长期维护升级、备份和扩展玩法7.1 版本升级与配置备份Sunshine 的版本迭代比较频繁但升级这件事不建议盲目跟。我的做法是稳定运行中的版本除非遇到明确影响使用的 bug 或者需要某个新功能否则不主动升。串流配置涉及的变量很多升级引入的行为变化可能让原本调好的参数失效。如果确实要升级先备份配置文件。配置目录下的配置文件和应用列表都要备份最好连同配对信息一起。升级之后先验证编码器列表是否正常再跑一次基线测试确认没问题再恢复日常使用。降级也要做好准备。有些版本在某些显卡上表现更好如果升级后体验变差回退到之前的版本是合理选择。保留上一版的安装包是个好习惯。7.2 多主机与多客户端的管理思路家里如果有多台能跑游戏的机器每台都可以装一份 Sunshine用同一个客户端去连。管理上的关键是给每台主机起一个能分辨的名字避免在客户端列表里看到一堆相似的名字不知道点哪个。多客户端的情况更常见客厅电视、卧室平板、手机、笔记本都可能连过来。需要注意的是不同客户端的解码能力差别很大手机可能只支持 H.264电视可能支持 HEVC 但不支持 AV1。如果配置是全局的就很难兼顾。较新版本支持针对不同客户端做差异化配置可以用起来。另一个实践建议是给不同的使用场景建不同的应用条目。比如一个条目直接启动游戏另一个条目启动桌面会话。这样在客户端选择的时候一目了然不用每次都在桌面上手动点开。7.3 后续还能怎么玩跑通基础串流之后还有不少可以扩展的方向。一是把主机做成常驻的游戏服务器。主机长期开机配合远程唤醒客户端随时连上就能玩。这需要对电源管理和系统休眠做一番配置但一旦跑通体验非常接近真正的云游戏。二是多显示器与虚拟显示。如果主机平时接着显示器串流时希望以另一个分辨率输出可以配置虚拟显示设备让串流链路使用独立的分辨率和刷新率不受物理显示器限制。这个方案在无头运行主机不接显示器的场景下几乎是必需的因为部分显卡在没有显示输出的情况下编码器无法正常工作。三是外设扩展。除了手柄还可以把方向盘、飞行摇杆这类设备接在客户端通过串流链路透传到主机。这类设备的透传支持程度取决于客户端实现需要逐个测试。四是串流质量的量化监控。客户端通常会显示延迟、丢包、码率这些统计定期记录这些数据能帮你在问题出现之前发现趋势。比如延迟逐渐升高可能是主机散热在退化早发现早处理。我在把主机改成常驻服务器之后最大的体会是串流的体验瓶颈往往不在技术上而在习惯上。参数调到一个“够用且稳定”的水平之后就不该再频繁折腾了把时间留给游戏本身。那些花在反复对比码率差异上的时间远不如把网线换成六类线、把路由器换个位置来得实在。