部署
了解部署及其生命周期——概念和最佳实践以便更深入理解。
🗺️ 协调（Orchestration）
采用我们的云原生边缘计算方法，在几秒钟内启动新服务器以满足容量需求。我们将服务器视为 牲畜而非宠物 ——完全替换故障实例，而不是手动维护每个实例。
您选择的编排方式将 影响您的运维成本、服务器成本和可扩展性.
在 Discord 联系我们 以了解混合编排选项并优化您的托管成本。
为了全面了解所有优缺点，让我们比较各种编排方法。
以匹配为边界（Match-Bound）
为现代工作室提供的黄金标准，带来 最简单的集成与最佳的成本效率.
👍 优点
最佳的成本效率——按分钟实时扩展以满足玩家需求。
最低的运维成本，由于无区域托管，Edgegap 自动化了 99% 的任务。
最低的延迟，得益于 Edgegap 公有云基础设施中的 615+ 个站点。
在意外流量激增时拥有最快的扩容速度（突发能力）。
最高标准的安全性和防作弊（服务器权威）。
意外服务器崩溃对玩家的影响最小，仅影响单场比赛。
👎 缺点
采用新的编排思维模型最初需要一定的学习投入。
运行超过 24 小时的服务器将被自动终止。
🧩 最适合
对延迟敏感的游戏—— 当网络代码优化无法克服高延迟时：
第一人称射击、格斗游戏、VR 与 XR（虚拟和扩展现实）等，……
具有 按设计对比赛时长有上限的,
大逃杀（Battle Royale）， PvPvE，合作射击、MOBA、体育游戏、ARPG 与地牢爬行者等，……
🔎 可发现性
当足够玩家加入时启动新游戏 匹配.
将玩家加入到 使用回填替换现有比赛中的离开者.
允许玩家浏览服务器并从列表中选择，具有 服务器浏览器.
Edgegap 根据每个区域的玩家活动自动上下扩展所有 615+ 个服务器位置。为成功做准备——无缝地 在 60 分钟内扩展到 1400 万并发用户.
区域待命（Regional Standby）
传统模型，适用于 具有用户生成内容的持久世界和社交类 MMO 游戏.
👍 优点
熟悉且易于理解的老派方法，适合久经沙场的资深开发者。
最高标准的安全性和防作弊（服务器权威）。
基于月度承诺的成本易于预测。
👎 缺点
较高的托管成本——每个区域需要一个或多个空闲待命服务器（突发容量）。
较高的运维成本——每个区域的扩展、运营和维护都需要重复投入。
玩家基数较小的地区由于需加入较远的服务器会体验到高延迟。
🧩 最适合
持久世界，其用户生成内容即使玩家下线也存储在服务器上。
MMO、带基地建设或物体放置的沙盒、提取类射击游戏等，…
容忍延迟的游戏—— 当不需要服务器权威的实时物理时:
移动游戏、合作游戏、集换式卡牌/构筑卡牌、回合制策略等，…
异步多人， 服务器崩溃对玩家体验影响最小的情况：
与幽灵竞速、掠夺敌方基地、计时建造/耕作类游戏等，…
具有较重初始化流程的应用——当准备服务器需要数分钟时。
🔎 可发现性
允许玩家浏览服务器并从列表中选择，具有 服务器浏览器.
参见 托管集群 以了解 在 Edgegap 上自托管您的微服务和后端服务 。
点对点（Peer to Peer）
将开发精力从 专用服务器 转移到 用于非竞技游戏的中继网络代码（relay netcode）.
相关主题：监听服务器、玩家托管权威、NAT 穿透。
👍 优点
最低的托管成本，仅需中继服务器来解决 NAT 穿透问题。
最低的运维成本——只需维护客户端构建和分发渠道。
意外服务器崩溃对玩家的影响最小，仅影响单场比赛。
易于实现且原型开发速度快，无需任何后端开发。
👎 缺点
需要更多的点对点网络代码开发工作，需具备并发编程技能。
延迟最差且对不利网络条件（例如移动网络）最为敏感。
安全性最弱，易受中间人攻击和会话劫持的影响。
当主机离开时有会话丢失风险，除非您实现自定义的主机迁移。
🧩 最适合
合作与休闲游戏—— 当作弊不会破坏乐趣或影响游戏时,
儿童游戏、探索类游戏、冒险类游戏等，…
🔎 可发现性
参见我们的 分布式中继（Distributed Relays） 服务，可在延迟与安全性方面为点对点提供业内领先的支持。
📍 服务器放置（Server Placement）
无论您选择哪种编排方法，为一组玩家选择正确的服务器位置对于确保最佳 ping 和最优玩家体验至关重要。了解不同的服务器放置策略及其如何影响玩家。
您的服务器放置策略将 影响玩家体验、留存率和游戏评价.
Edgegap 在 可用容量的最佳位置 部署，以实现快速且低延迟的对局。
参见 部署 转移到 实时分析服务器放置，并进行大规模处理。
服务器评分（Server Score）
服务器评分策略使用 Edgegap 的专利方法， 为每场比赛单独优化服务器放置。执行非侵入式遥测以估算每位玩家到我们服务器位置的网络接近度，并选择提供最佳：
响应性 ——为所有玩家平均提供最低延迟，
公平性 ——为所有玩家提供均衡且公平的延迟。
我们的 匹配器（Matchmaker） 默认使用 服务器评分策略，以确保尽可能好的体验。要在 Deploy APIs中使用此策略，请在部署请求中输入玩家的公网 IP 或地理坐标。
不响应的放置 ——服务器太远，所有玩家延迟都很高：
不公平的放置 ——延迟不均，一名玩家处于劣势：
良好放置示例 ——为所有玩家提供响应且公平的延迟：
该策略 对托管一组彼此相距较远的玩家尤其有效 （北美与欧洲，或西海岸与东海岸），这在预制大厅中经常发生。
地理定位（Geolocation）
作为替代， 在部署时提供玩家的经纬度坐标或首选服务器位置的坐标 ，而不是利用自动遥测。该方法需要额外的客户端侧地理查询实现，完全依赖游戏开发者的方案。
地理定位策略不建议用于 部署 编排，除非应用有关于跨区域数据传输的严格合规要求，或玩家 IP 不可用时。
要在此策略下使用， Deploy APIs请在部署请求中列出玩家的公网 IP 或地理坐标。
区域锁定（Region Lock）
服务器可能使用粗略的区域参数进行放置，方式为：
基于玩家元数据（玩家账户数据库）自动为玩家选择，或
在匹配期间由玩家选择，允许在客户端-服务器延迟较高的情况下进行放置。
单独使用该策略不建议，因为可能导致较差的网络性能。
将 区域选择作为预筛选并与另一策略结合使用 是更好的替代方案。
🟢 连接质量（Connection Quality）
有些游戏（和有些玩家）对延迟或卡顿更敏感。尽管玩家反馈是指示大规模事件或回归缺陷的重要指标， 玩家可能缺乏对网络概念的深入理解 并且很容易将责任归咎于开发者、网络代码或服务器。
某些问题的根本原因可能对玩家不可见，因此工作室与托管提供商的合作可能至关重要。 Edgegap 的首要任务始终是提供尽可能好的服务。
如果您收到大量玩家反馈、遇到大范围故障或反复出现的问题，请通过我们平台的支持工单立即与我们联系。
低延迟（Low Latency）
玩家延迟由在以下各项之间传输数据的延迟组合而成：
物理设备—— 物理信号在 互联网网络拓扑（Internet networking topology）,
主机与主机之间传输 ——由协议、传输和安全措施导致，
进程与进程之间 ——由客户端/服务器中（封包/解包）和处理数据导致。
Edgegap 通过将服务器放置得更靠近您的玩家来减少物理延迟，从而缩短响应时间并减少网络跳数。我们在 17 家云和裸金属提供商之间拥有部署点，为您提供 面向全球玩家的卓越 ping 表现.
全球服务器和互联网覆盖（不仅仅是 Edgegap）受限于诸如以下因素：
基础设施可用性 ——某一区域的互联网连接质量可能不足，
自然因素 ——高度复杂的服务器机架通常需要相对稳定的环境。
高可用性（High Availability）
全球各地不同位置的服务器可用性会随时间变化，一天中可能多次改变。Edgegap 会自动 按需扩展/缩减 位置 ，并会考虑：突发流量（burst traffic）
——在 15 分钟内发起的部署， vCPU 要求
——每次部署更多的 vCPU 会增加特定位置的总体需求， 提供商可用度
——某些偏远位置的提供商选项较少， 机器可用性
——某些位置可能仅提供 4 vCPU 或 8 vCPU 的机器， 工作室请求
用于测试、质量保证、抢先体验、封闭测试或赛事。 所有应用的部署请求会被合并以评估位置需求。默认情况下，所有组织具有相同的分配优先级，且存在
为需要特定硬件或位置的企业客户添加私有服务器池的可能性 。.
请 与我们联系以规划发布，或如果您对位置可用性有任何请求。
玩家问题排查（Player Issue Resolution）
玩家问题可能源于服务器错误或提供商事件，也可能由第三方引起，例如本地 ISP、游戏服务、底层库的 bug、基础设施提供商或其他来源。
在排查玩家报告或事件时，考虑以下因素：
区域性问题：
本地化的互联网服务提供商（ISP）可能会短时导致故障，
某些地区（例如中国、俄罗斯）可能由于本地制裁而受限，
缓存级别（caching level） ——Edgegap 会优先在有缓存的位置进行快速部署：
最大部署时间 ——由于缓慢且繁重的初始化流程，部署可能失败：
参见 应用与版本 要增加超时期限，
将初始化步骤延迟到绝对必要时再执行，
服务器镜像或集成问题.
在客户端对战史 UI 中显示部署 ID 以便在排查时跟踪玩家报告。
向用户通知广泛存在的错误、临时问题和故障以减轻负面情绪。
🔄 部署生命周期（Deployment Lifecycle）
Edgegap 的部署会经历若干生命周期阶段，由部署状态表示。
1. 启动部署
用于 测试目的 的部署可通过以下方式启动：
虚幻引擎 - 针对 Unreal Engine 项目的 Docker 扩展或插件，
Unity - 针对 Unity 项目的插件，
仪表盘 Web UI ——用于测试服务器集成的易用 web 界面。
用于 生产环境（在线） 应通过以下方式启动：
Deploy API ——服务器到服务器的自定义集成（自定义扩展）。
保存 request_id （部署 ID）并为部署打标签 以便稍后识别和排查问题。
在使用 Deploy API测试时，您可以覆盖默认的 Dockerfile CMD 以使用自定义命令。
2. 部署中
一旦部署启动，我们的系统会迅速执行若干步骤：
遥测——我们正在测量可用数据中心到每位玩家的网络响应性，
部署——我们正在预留容量并准备启动您的服务器容器，
容器启动——我们正在启动容器、安装依赖并初始化，
后处理——我们正在添加日志存储、监控并完成部署。
请求过多 429（Too Many Requests） ——为确保稳定并防止意外账单，我们对您的组织进行速率限制，限制为 40 次请求/秒. 联系我们 以规划发布、估算上线流量并为成功做准备。
3. 部署就绪（Deployment Ready）
您的容器已完全初始化，服务器正在启动。在几秒到一分钟内，您的服务器可能仍在初始化，在游戏引擎（或自定义运行时）完全准备好接受玩家连接之前，可能不会响应玩家请求。
一旦部署处于就绪状态， 请重试玩家连接直到成功，或直到预定义的客户端超时。
4. 部署错误（Deployment Error）
您的部署可能在任何时间点因意外原因进入错误状态。这在测试集成或测试新的服务器构建时更可能发生。
错误状态的部署不向您收费，且会在 24 小时后自动停止。
故障排查步骤：
通过 我们的运行时间监控页面.
验证 Edgegap 服务状态
尝试使用 Docker Desktop 在本地测试您的服务器容器以排除 Edgegap 问题。 在寻求帮助时， 请提供您的部署 ID 及任何有用的细节
以便我们尽快调查！
5. 部署已停止（Deployment Stopped）我们不会在未经您指示的情况下停止您的服务器，
以防对玩家体验产生负面影响。您的部署可能由于以下原因被停止： 通过 DELETE_URL
参见 自停止（Self-Stop） 和 ——玩家离开且比赛结束后部署自行停止， Unreal Engine
Unity 有关正确停止部署的指南， 从您的后端停止,
——您的后端使用 Deployments API 应用与版本 停止了此部署，
私人舰队 游戏最大时长（Game Max Duration）
——您在 中设置的分配时间已到期， 托管您部署的主机通过计划动作被删除。 一旦部署被停止， 我们会触发优雅终止（graceful termination） 通过发送 SIGTERM
信号给您的主进程，允许短暂的终止期。到期后，会发送
SIGKILL
可发现性
信号以停止部署。👀 可观测性（Observability）允许游戏服务器与第三方互操作并获得运营洞察。
一旦就绪，部署会被分配一个 URL（ fqdn 和 部署.
）以及每个内部端口对应的外部端口。 使用
部署标签可轻松标记您的部署
来自游戏服务器的出站流量（到客户端或后端）永远不会被阻止
或过滤。Websockets（WS）和安全 Websockets（WSS）
要在 Edgegap 上使用基于 websocket 的网络代码，您有两种选择： 应用与版本 转移到 托管证书（managed certificate）
，1 分钟内设置完成，无需编写任何代码：
配置您的)
使用 Websocket（WS）并启用 TLS 升级，使用 Edgegap URL 连接客户端（例如：
要在 Edgegap 上使用基于 websocket 的网络代码，您有两种选择： 应用与版本 转移到 https://5fa53fa00a57.pr.edgegap.net/,
自管理证书（self-managed certificate） ，如果您想使用自己的自定义域：).
使用安全 Websocket（WSS） 配置您自己的 TLS 证书流程并使用自定义 DNS 记录（例如在 和 Cloudflare. 上）。.
未捕获的服务器异常会导致部署的容器重启并使 TLS 安全无效。在这种情况下，
停止您的服务器
将玩家重新匹配到新的部署 服务器状态可能会丢失 注入变量（Injected Variables） 游戏服务器通常需要额外信息，例如服务器 IP、内部端口值或其他。注入只读环境变量是一种可靠且与云无关的传参方式。.
在 C++ 中获取变量值的 GetEnvironmentVariable
应用版本变量（App Version Variables）
匹配器变量（Matchmaker Variables）
以及下面的部署变量（Deployment Variables）。
自定义变量（Custom Variables）
为每个部署定义最多 20 个自定义变量，每个变量可包含最多 4KB 的字符串数据。避免使用下列保留名称，否则您的自定义变量将被覆盖！通过读取 Edgegap 注入到您的服务器的变量来访问重要信息：.标识符（Identifiers）
ARBITRIUM_REQUEST_ID
——例如：.
f68e011bfb01避免使用下列保留名称，否则您的自定义变量将被覆盖！162.254.141.66.唯一的部署 ID，也称为请求 ID。用于检索更多信息。
部署 URL 始终具有格式避免使用下列保留名称，否则您的自定义变量将被覆盖！{ARBITRIUM_REQUEST_ID}.pr.edgegap.net.ARBITRIUM_PUBLIC_IP
该主机的公网 IP 地址，可用于替代 URL 进行连接。避免使用下列保留名称，否则您的自定义变量将被覆盖！ARBITRIUM_HOST_ID.alpha-north-america-70364ef8 承载您部署的机器的唯一标识符，与其他部署共享。.
ARBITRIUM_DEPLOYMENT_TAGS避免使用下列保留名称，否则您的自定义变量将被覆盖！tag1,tag2以逗号分隔的用户定义部署标签， 私人舰队.
便于搜索和过滤
ARBITRIUM_PRIVATE_FLEET_ID避免使用下列保留名称，否则您的自定义变量将被覆盖！PUBLIC_CLOUD，或如果托管在 私人舰队.上的舰队 ID。避免使用下列保留名称，否则您的自定义变量将被覆盖！2000资源规格（Resource Specifications）ARBITRIUM_HOST_IN_PRIVATE_FLEET避免使用下列保留名称，否则您的自定义变量将被覆盖！256false，表示是否托管在避免使用下列保留名称，否则您的自定义变量将被覆盖！512ARBITRIUM_HOST_BASE_CLOCK_FREQUENCY
，处理器频率，单位 MHz。
ARBITRIUM_DEPLOYMENT_VCPU_UNITS避免使用下列保留名称，否则您的自定义变量将被覆盖！，分配的 vCPU 单位（1024 = 1 vCPU）。.ARBITRIUM_DEPLOYMENT_MEMORY_MB ，分配的内存，单位 MB（1024 = 1 GB）。.
生命周期管理（Lifecycle Management）
ARBITRIUM_DELETE_URLhttps://api.edgegap.com/v1/self/stop/9f511e17/660可从部署内调用，部署将被优雅地停止
ARBITRIUM_DELETE_URL避免使用下列保留名称，否则您的自定义变量将被覆盖！需要唯一的一次性.ARBITRIUM_DELETE_TOKEN避免使用下列保留名称，否则您的自定义变量将被覆盖！在.Authorization
头中。
7df4cd933df87084b34ae80d8abde293https://api.edgegap.com/v1/self/stop/9f511e17/660可从部署内调用，部署将被优雅地停止
7df4cd933df87084b34ae80d8abde293避免使用下列保留名称，否则您的自定义变量将被覆盖！ARBITRIUM_CONTEXT_URL.
可发现性
https://api.edgegap.com/v1/context/9170f5211e17/17避免使用下列保留名称，否则您的自定义变量将被覆盖！7777仅可从部署内调用，返回更多部署详情。需要唯一的避免使用下列保留名称，否则您的自定义变量将被覆盖！31504ARBITRIUM_CONTEXT_TOKENdfaf50b9333b9ee07b22ed247e4a17e6
ARBITRIUM_PORT_GAMEPORT_INTERNAL避免使用下列保留名称，否则您的自定义变量将被覆盖！，服务器监听的内部端口。ARBITRIUM_PORT_GAMEPORT_EXTERNAL
，客户端连接的外部端口。 外部端口值为安全目的对每次部署进行随机化。 ARBITRIUM_PORT_GAMEPORT_PROTOCOL UDP 应用与版本 ，您的网络传输协议。 示例假设您已将端口命名为 gameport （默认）。 .
ARBITRIUM_PORT_SUPER_PORT_INTERNAL避免使用下列保留名称，否则您的自定义变量将被覆盖！139.177.198.69ARBITRIUM_BEACON_ENABLEDtrue避免使用下列保留名称，否则您的自定义变量将被覆盖！30199，如果在上部署且避免使用下列保留名称，否则您的自定义变量将被覆盖！30456ARBITRIUM_HOST_BEACON_PUBLIC_IP
，最近信标的公网 IP。
ARBITRIUM_HOST_BEACON_PORT_UDP_EXTERNAL ，用于通过 UDP 测量 ping。ARBITRIUM_HOST_BEACON_PORT_TCP_EXTERNAL
仪表板监控
我们的 仪表板 提供用于监控服务器可扩展性并协助运维的实用工具。
分析
查找 侧边栏菜单中的分析仪表板 在“服务器托管与编排”类别下。
🌟 升级到按使用付费层 以解锁详细的服务器性能指标和洞察：
总体洞察： 通过实时每个版本的服务器数量和资源使用概览来监控发布，
CPU 洞察: 排查因处理器密集操作导致的服务器卡顿，
内存洞察: 缓解因超出分配内存导致的服务器重启，
网络洞察： 检测低效的网络模式并优化网络代码。
部署地图
在以下位置查找部署地图 仪表板上的部署详情页面.
在地图上预览部署位置、可用位置和估计玩家位置：
部署平衡点
在以下位置查找部署平衡点热力图 仪表板上的应用详情页面.
预览部署平衡点热力图并按以下内容筛选： 应用与版本。平衡点是与给定部署中每位玩家网络距离相等的近似位置：
部署日志
在以下位置查找部署日志 仪表板上的部署详情页面.
部署日志显示有关以下内容的信息： 部署:
容器日志
在以下位置查找容器日志 仪表板上的部署详情页面.
在出现问题或调试时检查您的游戏服务器日志：
一旦部署停止，容器日志将被删除。 设置 第三方 S3 日志存储 以保存日志。
容器指标
在以下位置查找容器指标 仪表板上的部署详情页面.
查看容器指标（处理器、内存、网络）以：
识别常见连接问题时的情况（例如）， 部署,
检测导致资源使用激增的低效实现模式，
在特定场景中定位低效的资源使用，
验证在优化期间服务器资源使用的变化，
基准测试服务器初始化的资源消耗和持续时间。
历史指标以 1 分钟时间周期显示值平均，免费层可用。
🌟 升级到按使用付费层 以解锁具有 1 秒时间间隔的精确指标。
联系我们 在发布前请求大规模发布的实时托管支持。
上下文与状态
可以以 JSON 格式检索附加部署信息：
上下文 API（来自部署）需要 Context API 令牌，而状态 API 使用您的 Edgegap 令牌。
请求过多 429（Too Many Requests） - 我们对您的组织进行速率限制为 20 请求/秒 用于上下文和状态 API 端点。使用 未捕获的服务器异常会导致部署的容器重启并使 TLS 安全无效。在这种情况下， 和 Webhooks（网络挂钩） 以获得可扩展的解决方案。
筛选部署
要在所有部署中快速搜索，您可以 使用我们的仪表板:
使用 API 列出部署 并通过后端集成应用筛选：
https://api.edgegap.com/v1/self/stop/9f511e17/660 注入变量（Injected Variables） 不在数组中（nin）
[ "7e709a0d8efd", "4ba353100b4b" ]
https://api.edgegap.com/v1/self/stop/9f511e17/660 注入变量（Injected Variables） 不在数组中（nin）
[ "tagA", "tagB" ]
等于（eq） 注入变量（Injected Variables） 小于等于（lte） 注入变量（Injected Variables） 大于等于（gte）
https://api.edgegap.com/v1/self/stop/9f511e17/660 注入变量（Injected Variables） 不在数组中（nin）
[ "my-app", "my-other-app" ]
https://api.edgegap.com/v1/self/stop/9f511e17/660 注入变量（Injected Variables） 不在数组中（nin）
[ "1.0.0", "prod" ]
等于（eq） 注入变量（Injected Variables） 不等（neq） 注入变量（Injected Variables）
小于（lt） 注入变量（Injected Variables） 小于等于（lte） 注入变量（Injected Variables）
大于（gt） 注入变量（Injected Variables） 大于等于（gte）
5
每个属性在单个请求中最多可以有 1 个筛选运算符。参见 API 参考 以了解更多。
按请求中出现的顺序按多个字段对结果进行排序：
升序（asc） 注入变量（Injected Variables） 降序（desc）
升序（asc） 注入变量（Injected Variables） 降序（desc）
示例过滤查询：
列出 错误中的部署 以进行故障排除和删除。
编码后的 URL：
格式化的 JSON 查询：
列出 应用版本过期的部署 以确认某次发布已完成。
编码后的 URL：
格式化的 JSON 查询：
别忘了在请求中添加 可从部署内调用， 带有您的 Edgegap API 令牌的头。
Webhooks 与回调（Postbacks）
在游戏后端接收有关以下内容更改的简单 HTTP 通知， 部署 方法是通过在您的请求中指定一个 webhook URL， 部署 API 请求。可用于：
Ready 与 Error 的 webhook 永远不会针对同一部署同时触发。
Webhook 不会重试，因此如果您的后端由于速率限制或错误而未处理请求，webhook 可能会丢失。仅将 webhooks 用于 非关键用例或调试目的.
Webhooks 观察部署生命周期，但不了解场景/关卡的初始化状态。要观察场景/关卡的加载进度，请在游戏服务器中实现自定义 webhook。
🚨 故障排除
在对部署进行故障排除时：
在本地运行您的服务器以排除集成错误，
查看本页上的故障排除步骤，
通过以下方式与我们联系， 社区 Discord 并包含您的部署 ID。
参见 部署 以获取我们关于处理玩家社区反馈的建议。
无法将客户端连接到服务器 - 请求超时。, 请求超时 , 连接失败（ConnectionFailed） ，或 端口验证失败.
首先，确保部署处于 Ready 状态，并且部署日志中没有运行时异常或错误。如果您的部署已停止，请在我们的 仪表板.
中检查日志。 如果您使用的是 Mirror 网络代码，您需要在 中选择
NetworkManager（网络管理器），重新构建、推送并重新部署您的服务器。如果您使用的是 FishNet 网络代码，您需要在 中启用“Start on Headless” 在您的
ServerManager（服务器管理器），重新构建、推送并重新部署您的服务器。如果您使用 Photon Fusion 2 网络代码，请确保您的服务器正在传递部署公有 IP、外部端口和
roomCode（房间代码）在服务器上，并且客户端在 “NetworkRunner.StartGame” 参数中使用相同的房间代码，StartGameArgs。部署 ID（例如b63e6003b19f）是一个很好的选择，因为它在全球范围内是唯一的，并且客户端可以通过 匹配器（Matchmaker） 分配和到 深入解析.轻松访问。 接下来，请验证服务器构建的网络代码设置中的端口设置是否与您的应用版本（App version） 接下来，请验证服务器构建的网络代码设置中的端口设置是否与您的 中的内部端口匹配。您可以通过编辑
来更改端口映射，而无需重新构建。请在您的网络代码集成中查找您的协议。 请确保您的游戏客户端正在连接到 在部署详情页面显示的外部端口，
此值出于安全原因将始终随机化。 接下来，请验证服务器构建的网络代码设置中的端口设置是否与您的 如果您在网络代码集成中使用安全 WebSocket（WSS）协议，请确保为 WSS 端口的端口配置启用了 TLS 升级。
您位于中国并使用 智能机群（Smart Fleets）吗？您的连接可能会被防火长城阻止。考虑向您的机群添加位于中国的服务器，或使用 VPN 进行连接。
我的部署已准备好，但在几分钟后仍无法连接。
一旦部署处于 Ready 状态，您的游戏引擎初始化将开始。该过程可能需要几秒到几分钟不等，在此期间服务器不会接受玩家连接。
考虑优化服务器初始化以减少此时间。
游戏客户端应以 1 秒间隔重试连接，持续有限时间（取决于您的初始化时间），之后返回匹配流程。
考虑添加加载场景，以便服务器可以在客户端同时执行初始化（以及在 Unreal 引擎中进行场景切换）时同步双方状态。
我的 Meta Quest 设备抛出 HTTP 0：无法解析目标主机 .
在为 Android 目标构建 Unity 应用时，Internet Access 权限可能会从输出的 APK 客户端构建产物中被自动移除。
重新在以下位置添加权限（之后需要重新构建客户端）：
项目设置 / OpenXR / ⚙️ Meta Quest 支持 / 强制移除 Internet 权限（取消勾选）。
播放器设置 / Internet Access（设置为 require）。
如果玩家离开我的部署会发生什么？
默认情况下，服务器不会拒绝玩家连接。玩家认证由您的开发者负责，因为可以使用多种不同的方法和玩家认证提供商。
游戏客户端可以将连接信息保存在本地，以便在意外客户端崩溃时尝试重新连接。
为允许玩家加入正在进行的游戏，请考虑使用 深入解析 注入变量（Injected Variables） 会话（Sessions）.
我的服务器在变为 Ready 后显示 100% CPU 利用率。
这可能不是问题，因为游戏引擎在服务器初始化期间往往会执行大量 CPU 密集型操作。如果在部署启动后 2-3 分钟内 CPU 使用率没有下降，您可能需要优化服务器或增加应用版本的资源。
降低 tick 率可以减少服务器执行的消息操作，从而影响 CPU 使用率。
中检查日志。 如果您使用的是 Mirror 网络代码，您需要在 中选择
NetworkManager（网络管理器），重新构建、推送并重新部署您的服务器。如果您使用的是 FishNet 网络代码，您需要在 中启用“Start on Headless” 在您的
ServerManager（服务器管理器），重新构建、推送并重新部署您的服务器。在免费层中，您被限制为 1.5 vCPU 和 3GB 内存（RAM）。
您可以在创建新应用版本时增加分配的资源。您可以在仪表板中复制应用版本并根据需要调整这些值，而无需重新构建服务器或镜像。
最后更新于
这有帮助吗？