Apollo 迁移指南从 GameStream 到 UPnP 公网串流【免费下载链接】ApolloSunshine fork - The easiest way to stream with the native resolution of your client device项目地址: https://gitcode.com/gh_mirrors/apollo18/ApolloNVIDIA 在 2023 年 2 月终止了面向 NVIDIA Games 客户端的 GameStream 服务而 Apollo一个以客户端设备原生分辨率串流为目标的 Sunshine fork的性能已达到或超过 GameStream客户端仍可直接使用 Moonlight无需更换。本文讲清两件事如何用 GSMS 工具把原有游戏条目搬进apps.json以及 Apollo 内置的 UPnP 公网串流机制、配置项和常见故障的排查思路。结论先行什么情况值得直接迁移判断很简单只要你的客户端是 Moonlight迁移就是换服务端、不换客户端成本最低。串流质量官方文档明确 Sunshine 性能已达到或超过 GameStream见 docs/gamestream_migration.md公网串流原来依赖 Moonlight Internet Hosting Tool 打洞的迁移后可直接移除该工具改用 Apollo 内置的 UPnP 端口映射需要接受的差异能力GameStreamApollo自动扫描并列出已安装游戏支持不支持依赖apps.json条目或 GSMS 迁移结果自动调整游戏内设置优化串流支持不支持需用prep-cmd等手段自行编排互联网串流依赖 NVIDIA 云服务本地 UPnP 端口映射无需额外服务如果游戏库很小手工在apps.json里写几条就够用条目多、怕出错再上 GSMS 自动迁移。GSMS把游戏条目一次性搬进 apps.jsonGSMSGameStream Migration Service是官方为迁移场景提供的自动化工具。它能把你 GameStream 里的自定义应用和自动检测到的游戏一起迁走具体落点是每个条目的工作目录、启动命令写入apps.json封面图box-art复制到你指定的目录apps.json默认与主配置文件同目录Linux/macOS 为~/.config/sunshineWindows 为%ProgramFiles%\Sunshine\configDocker 为/config首次启动时由内置模板复制生成src/config.cpp 中APPS_JSON_PATH的拷贝逻辑。文件默认模板长这样// src_assets/linux/assets/apps.json { env: { PATH: $(PATH):$(HOME)/.local/bin }, apps: [ { name: Low Res Desktop, image-path: desktop.png, allow-client-commands: false, prep-cmd: [ { do: xrandr --output HDMI-1 --mode 1920x1080, undo: xrandr --output HDMI-1 --mode 1920x1200 } ] } ] }顶层env定义所有应用共享的环境变量$(PATH)、$(HOME)这类占位符在运行时展开apps数组里每个条目就是一个可串流启动的应用。解析逻辑在 src/process.cpp常用字段如下字段类型默认值含义namestring必填显示在客户端的名称cmdstring空启动命令working-dirstring空工作目录Windows 上会自动去引号并补反斜杠image-pathstring空封面图路径须为 PNGelevatedboolfalse是否提升权限运行auto-detachbooltrue自动分离进程wait-allbooltrue等待所有子进程退出exit-timeoutint5退出判定超时秒prep-cmdarray空启动前/退出后执行的命令每项含do、undo、elevateddetachedarray空独立于主进程启动的附加命令virtual-displayboolfalse是否使用虚拟显示器allow-client-commandsbooltrue是否放行 AltTab 等客户端命令uuidstring必填应用唯一标识Web UI 增删改依赖它两个实用细节全局准备命令global_prep_cmd会在所有应用启动前执行任一条失败就中止启动docs/configuration.md 中的示例用nircmd.exe临时切换分辨率undo再切回Web UI 提供GET /api/apps和POST /api/apps两个 REST 接口src/confighttp.cpp新增或编辑应用后调用proc::refresh热刷新不用重启 Sunshine。迁移完成后建议在这个页面上逐条核对cmd、working-dir、image-path是否指向正确路径UPnP 公网串流的内部机制想从外网串流前提只有一个路由器支持 UPnP。开启方式是 Web UI 打开 UPnP 选项或在配置文件中写# docs/configuration.mdNetwork 一节 upnp enabled配置解析在 src/config.cpp读到upnp enabled后翻转flag::UPNP标志位src/upnp.cpp 的upnp::start()发现该标志未置位就什么都不启动否则创建一个后台映射线程。线程启动时先组装端口映射清单基址是port默认 47989实际映射的 6 个端口为端口协议路由表中的描述48010TCPSunshine - RTSP47998UDPSunshine - Video48000UDPSunshine - Audio47999UDPSunshine - Control47989TCPSunshine - Client HTTP47984TCPSunshine - Client HTTPS只有当origin_web_ui_allowed设为wan时才会额外映射 47990Web UI 端口——默认lan下管理端口不对外开放这是安全设计不是 bug。映射线程的工作节奏src/upnp.h中两个常量REFRESH_INTERVAL 120s每 120 秒重新发现 IGDInternet Gateway Device即支持 UPnP 的路由器并逐端口核对映射。注释里写明原因路由器重启、WAN IP 变化等都会让映射丢失必须周期刷新PORT_MAPPING_LIFETIME 3600s映射租约 1 小时到期前被刷新逻辑续上每个端口的处理顺序先用UPNP_GetSpecificPortMappingEntry查是否已映射目标 IP 一致就直接跳过被别的设备占用则记UPnP conflict detected并尝试删除重建如果路由器返回异常错误非 606 Unauthorized会判定为老旧的 IGDv1 设备退化为 0 秒租约的永久映射来兼容。另外若address_family both且 IGD 支持 IPv6 防火墙控制会额外为每个 LAN 端口打 IPv6 pinholeIPv6 下没有 WAN→LAN 端口映射概念。Sunshine 退出时调用unmap_all_upnp_ports清理全部映射。相关配置项速查配置项默认值说明upnpdisabled是否启用内置端口映射port47989端口族基址改动后上表所有端口整体偏移address_familyipv4ipv4仅 IPv4both为 IPv4IPv6origin_web_ui_allowedlanpc/lan/wan三级决定 Web UI 是否对外external_ip自动检测手动指定公网 IP留空则自动⚠️ 一条官方警告Moonlight Internet Hosting Tool 低于 v5.6 的版本与 Sunshine 同时运行会导致 UPnP 端口转发变得不可靠。迁移时直接卸载它或至少升级到 v5.6 及以上。连不上时按这个顺序排查外网串流失败大多是映射没生效或映射被占日志里都有对应线索发现不到 IGD日志出现Couldnt discover any IPv4 UPNP devices或No IGD device found说明路由器没开 UPnP或根本不支持。到路由器后台开启 UPnP/远程端口映射后等 120 秒内线程自动重试即可映射存在但指向别处日志出现UPnP conflict detected with: IP表示端口被局域网内其他设备占用。Apollo 会尝试删除对方映射后重建部分路由器出于安全禁止未认证客户端删除他人映射此时需手动到路由器后台清理旧规则路由器重启后短暂连不上属正常现象。映射丢失后线程会在下一轮最多 120 秒重新发现 IGD 并补建映射同时打印Completed UPnP port mappings提示改了port却忘了客户端port一改上表 6 个端口全部偏移Moonlight 侧需要按新端口重连手动在路由器上转发端口的用户要同步更新规则想从外网管 Web UI 却连不上确认origin_web_ui_allowed已设为wan否则 47990 端口根本不会进入映射清单公网 IP 探测不对多出口/NAT 环境下自动检测可能失败用external_ip手动指定日志级别调到 debug 可以看到每一步查映射、建 pinhole、失败回退永久映射等细节Successfully mapped TCP 47989这类输出都在这条线程里。什么时候不适合这套方案路由器不支持 UPnP部分运营商定制路由关闭了该功能内置映射无从生效只能手动配置路由器端口转发本文机制不覆盖游戏库更新频繁Apollo 不会自动扫描新装游戏新游戏不会自己出现在串流列表里需要重新跑一次 GSMS 或在 Web UI 手工添加希望服务端替你调优游戏GameStream 会自动改游戏内设置适配串流Apollo 不会干预游戏内部配置。替代做法是用prep-cmd/state-cmd在串流前后执行自己的命令切分辨率、开低延迟模式等把 GameStream 的自动化换成脚本化收个尾迁移本身是一次性动作GSMS 跑一遍 核对apps.json真正的长期成本在网络侧。UPnP 开关只影响 6 个固定端口的映射日志每 120 秒一轮自检出问题时先看映射状态再看 IP基本能定位九成故障。【免费下载链接】ApolloSunshine fork - The easiest way to stream with the native resolution of your client device项目地址: https://gitcode.com/gh_mirrors/apollo18/Apollo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Apollo 迁移指南从 GameStream 到 UPnP 公网串流【免费下载链接】ApolloSunshine fork - The easiest way to stream with the native resolution of your client device项目地址: https://gitcode.com/gh_mirrors/apollo18/ApolloNVIDIA 在 2023 年 2 月终止了面向 NVIDIA Games 客户端的 GameStream 服务而 Apollo一个以客户端设备原生分辨率串流为目标的 Sunshine fork的性能已达到或超过 GameStream客户端仍可直接使用 Moonlight无需更换。本文讲清两件事如何用 GSMS 工具把原有游戏条目搬进apps.json以及 Apollo 内置的 UPnP 公网串流机制、配置项和常见故障的排查思路。结论先行什么情况值得直接迁移判断很简单只要你的客户端是 Moonlight迁移就是换服务端、不换客户端成本最低。串流质量官方文档明确 Sunshine 性能已达到或超过 GameStream见 docs/gamestream_migration.md公网串流原来依赖 Moonlight Internet Hosting Tool 打洞的迁移后可直接移除该工具改用 Apollo 内置的 UPnP 端口映射需要接受的差异能力GameStreamApollo自动扫描并列出已安装游戏支持不支持依赖apps.json条目或 GSMS 迁移结果自动调整游戏内设置优化串流支持不支持需用prep-cmd等手段自行编排互联网串流依赖 NVIDIA 云服务本地 UPnP 端口映射无需额外服务如果游戏库很小手工在apps.json里写几条就够用条目多、怕出错再上 GSMS 自动迁移。GSMS把游戏条目一次性搬进 apps.jsonGSMSGameStream Migration Service是官方为迁移场景提供的自动化工具。它能把你 GameStream 里的自定义应用和自动检测到的游戏一起迁走具体落点是每个条目的工作目录、启动命令写入apps.json封面图box-art复制到你指定的目录apps.json默认与主配置文件同目录Linux/macOS 为~/.config/sunshineWindows 为%ProgramFiles%\Sunshine\configDocker 为/config首次启动时由内置模板复制生成src/config.cpp 中APPS_JSON_PATH的拷贝逻辑。文件默认模板长这样// src_assets/linux/assets/apps.json { env: { PATH: $(PATH):$(HOME)/.local/bin }, apps: [ { name: Low Res Desktop, image-path: desktop.png, allow-client-commands: false, prep-cmd: [ { do: xrandr --output HDMI-1 --mode 1920x1080, undo: xrandr --output HDMI-1 --mode 1920x1200 } ] } ] }顶层env定义所有应用共享的环境变量$(PATH)、$(HOME)这类占位符在运行时展开apps数组里每个条目就是一个可串流启动的应用。解析逻辑在 src/process.cpp常用字段如下字段类型默认值含义namestring必填显示在客户端的名称cmdstring空启动命令working-dirstring空工作目录Windows 上会自动去引号并补反斜杠image-pathstring空封面图路径须为 PNGelevatedboolfalse是否提升权限运行auto-detachbooltrue自动分离进程wait-allbooltrue等待所有子进程退出exit-timeoutint5退出判定超时秒prep-cmdarray空启动前/退出后执行的命令每项含do、undo、elevateddetachedarray空独立于主进程启动的附加命令virtual-displayboolfalse是否使用虚拟显示器allow-client-commandsbooltrue是否放行 AltTab 等客户端命令uuidstring必填应用唯一标识Web UI 增删改依赖它两个实用细节全局准备命令global_prep_cmd会在所有应用启动前执行任一条失败就中止启动docs/configuration.md 中的示例用nircmd.exe临时切换分辨率undo再切回Web UI 提供GET /api/apps和POST /api/apps两个 REST 接口src/confighttp.cpp新增或编辑应用后调用proc::refresh热刷新不用重启 Sunshine。迁移完成后建议在这个页面上逐条核对cmd、working-dir、image-path是否指向正确路径UPnP 公网串流的内部机制想从外网串流前提只有一个路由器支持 UPnP。开启方式是 Web UI 打开 UPnP 选项或在配置文件中写# docs/configuration.mdNetwork 一节 upnp enabled配置解析在 src/config.cpp读到upnp enabled后翻转flag::UPNP标志位src/upnp.cpp 的upnp::start()发现该标志未置位就什么都不启动否则创建一个后台映射线程。线程启动时先组装端口映射清单基址是port默认 47989实际映射的 6 个端口为端口协议路由表中的描述48010TCPSunshine - RTSP47998UDPSunshine - Video48000UDPSunshine - Audio47999UDPSunshine - Control47989TCPSunshine - Client HTTP47984TCPSunshine - Client HTTPS只有当origin_web_ui_allowed设为wan时才会额外映射 47990Web UI 端口——默认lan下管理端口不对外开放这是安全设计不是 bug。映射线程的工作节奏src/upnp.h中两个常量REFRESH_INTERVAL 120s每 120 秒重新发现 IGDInternet Gateway Device即支持 UPnP 的路由器并逐端口核对映射。注释里写明原因路由器重启、WAN IP 变化等都会让映射丢失必须周期刷新PORT_MAPPING_LIFETIME 3600s映射租约 1 小时到期前被刷新逻辑续上每个端口的处理顺序先用UPNP_GetSpecificPortMappingEntry查是否已映射目标 IP 一致就直接跳过被别的设备占用则记UPnP conflict detected并尝试删除重建如果路由器返回异常错误非 606 Unauthorized会判定为老旧的 IGDv1 设备退化为 0 秒租约的永久映射来兼容。另外若address_family both且 IGD 支持 IPv6 防火墙控制会额外为每个 LAN 端口打 IPv6 pinholeIPv6 下没有 WAN→LAN 端口映射概念。Sunshine 退出时调用unmap_all_upnp_ports清理全部映射。相关配置项速查配置项默认值说明upnpdisabled是否启用内置端口映射port47989端口族基址改动后上表所有端口整体偏移address_familyipv4ipv4仅 IPv4both为 IPv4IPv6origin_web_ui_allowedlanpc/lan/wan三级决定 Web UI 是否对外external_ip自动检测手动指定公网 IP留空则自动⚠️ 一条官方警告Moonlight Internet Hosting Tool 低于 v5.6 的版本与 Sunshine 同时运行会导致 UPnP 端口转发变得不可靠。迁移时直接卸载它或至少升级到 v5.6 及以上。连不上时按这个顺序排查外网串流失败大多是映射没生效或映射被占日志里都有对应线索发现不到 IGD日志出现Couldnt discover any IPv4 UPNP devices或No IGD device found说明路由器没开 UPnP或根本不支持。到路由器后台开启 UPnP/远程端口映射后等 120 秒内线程自动重试即可映射存在但指向别处日志出现UPnP conflict detected with: IP表示端口被局域网内其他设备占用。Apollo 会尝试删除对方映射后重建部分路由器出于安全禁止未认证客户端删除他人映射此时需手动到路由器后台清理旧规则路由器重启后短暂连不上属正常现象。映射丢失后线程会在下一轮最多 120 秒重新发现 IGD 并补建映射同时打印Completed UPnP port mappings提示改了port却忘了客户端port一改上表 6 个端口全部偏移Moonlight 侧需要按新端口重连手动在路由器上转发端口的用户要同步更新规则想从外网管 Web UI 却连不上确认origin_web_ui_allowed已设为wan否则 47990 端口根本不会进入映射清单公网 IP 探测不对多出口/NAT 环境下自动检测可能失败用external_ip手动指定日志级别调到 debug 可以看到每一步查映射、建 pinhole、失败回退永久映射等细节Successfully mapped TCP 47989这类输出都在这条线程里。什么时候不适合这套方案路由器不支持 UPnP部分运营商定制路由关闭了该功能内置映射无从生效只能手动配置路由器端口转发本文机制不覆盖游戏库更新频繁Apollo 不会自动扫描新装游戏新游戏不会自己出现在串流列表里需要重新跑一次 GSMS 或在 Web UI 手工添加希望服务端替你调优游戏GameStream 会自动改游戏内设置适配串流Apollo 不会干预游戏内部配置。替代做法是用prep-cmd/state-cmd在串流前后执行自己的命令切分辨率、开低延迟模式等把 GameStream 的自动化换成脚本化收个尾迁移本身是一次性动作GSMS 跑一遍 核对apps.json真正的长期成本在网络侧。UPnP 开关只影响 6 个固定端口的映射日志每 120 秒一轮自检出问题时先看映射状态再看 IP基本能定位九成故障。【免费下载链接】ApolloSunshine fork - The easiest way to stream with the native resolution of your client device项目地址: https://gitcode.com/gh_mirrors/apollo18/Apollo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
