做Unity WebGL上云部署这件事我前后折腾过不少项目。最典型的一次是帮朋友把一个3D展厅项目发布出去本地编辑器里跑得飞快构建也顺利结果一放到云服务器上远程用户打开浏览器不是白屏就是加载超慢有的还会直接崩掉。排查到最后问题全都集中在部署链路那几个容易忽略的细节上压缩格式、MIME类型、安全隔离头、缓存规则。后来我换成阿里云ECS做源站、ESA做边缘加速这套组合才真正稳定下来。这篇文章就把完整的部署思路和实操步骤写出来给正在搞Unity WebGL上云的朋友做个参考。1. 方案拆解为什么选ECS做源站、ESA做加速层1.1 名字撞车了此ECS非Unity的ECS先说个容易绕晕的地方。Unity圈子里提到ECS很多人第一反应是Entity Component System也就是Unity DOTS那套实体组件架构。但部署这里说的ECS是阿里云的云服务器Elastic Compute Service。两个缩写一模一样很多新手在搜索引擎里一翻出来的全是Unity ECS性能优化和DOTS架构的文章跟服务器部署完全不搭边。我自己也因为这个多绕了不少弯路所以先把名字区分开。ESA同样有歧义。欧洲航天局叫ESA有的资料分类里也会出现ESA土地利用数据下载之类的关键词。但我们这里聊的ESA是阿里云的边缘安全加速Edge Security Acceleration属于云加速和安全防护产品别搞混。1.2 WebGL发布到底难在哪Unity WebGL构建产物和传统网站完全是两码事。第一次接触的人最容易犯的错就是把它当成一个普通静态网站直接扔进Nginx就能跑。结果跑起来全是问题。核心难点有几个。第一是体积大。一个稍微完整点的3D项目构建出来的data文件动辄几百兆如果压缩策略不对用户首次加载能等到怀疑人生。第二是WebAssembly对浏览器环境要求苛刻。wasm文件需要正确的Content-Type否则浏览器直接拒绝解析如果开启了多线程还必须有跨域隔离相关的响应头否则SharedArrayBuffer不可用工程会在启动时报错。第三是安全问题。Unity WebGL里的摄像头、麦克风、WebSocket等API强制要求HTTPS非安全上下文里直接不可用。这意味着从ECS到ESA整条链路都必须把HTTPS做好。还有一个很多人忽略的点构建产物是带版本hash的文件名。这个特性和缓存策略密切相关配好了能显著提升二三次访问的加载速度配不好就会把用户永远留在旧版本里。1.3 整体链路与数据流向我最终跑通的链路是这样的用户浏览器先请求ESA边缘节点边缘节点根据域名和路径查找缓存。如果命中直接返回静态资源不再往后端跑如果没有命中ESA回源到ECS上的Nginx从磁盘读取Unity构建产物返回同时按缓存规则在边缘节点留一份副本。这个结构最合理的地方在于分工明确。ECS负责源站存储和基础Web服务跑Nginx、托管构建产物、配置证书、控制响应头ESA负责所有边缘侧的能力包括TLS终止、HTTP/2和HTTP/3、静态缓存加速、WAF基础防护、DDoS过滤、限速防刷。源站不需要太高的配置因为大部分流量都被边缘节点挡住了CPU和带宽压力都不大。三种常见的部署方案对比一下更容易看出选型的理由方案维护成本扩展性安全防护适用场景ECS裸奔直连低但暴露公网差带宽和防御都在一台机器无测试环境、临时演示OSS CDN低纯静态托管好稳定且便宜CDN自带的有限防护纯静态、没有后端需求的项目ECS ESA中需要维护源站好边缘层可扩展源站可跑后端WAF、DDoS、Bot防护齐全生产环境、后续要加后端API的项目我选ECS ESA不只是为了加速。Unity WebGL项目做完展示后面大概率要上用户系统、数据上报、在线配置这些后端能力这时候ECS的价值就体现出来了。ESA则让整条访问链路足够快同时把刷流量、攻击之类的风险挡在边缘。2. Unity Build配置构建产物决定上线体验2.1 Player Settings里必须动的那几个参数很多人在部署环节反复折腾服务器结果问题出在构建参数上。构建阶段定下的参数直接决定了产物体积、压缩格式、内存模型和服务器端要配合的HTTP头。打开Project Settings面板在Player设置里选择WebGL平台先处理这几个关键项。Compression Format选Brotli还是Gzip这是第一个分水岭。Brotli压缩率比Gzip能再小10%到15%对动辄几百MB的Unity产物来说省下的体积就是实打实的加载时间。缺点是构建耗时变长因为压缩工作量更大。如果本地构建还能忍建议直接上Brotli。我这里实际项目中开启Brotli之后data文件从520MB压到286MBwasm从18MB压到8.4MB效果非常显著。如果项目用CI机器构建、时间卡得紧那Gzip是更折中的选择至少比不压缩强太多。Enable Exceptions正式发布建议选择None或Explicitly Thrown Exceptions Only。开发和测试阶段可以开Full但发布版开Full会带来额外体积和性能损耗没必要为不会走的错误分支买单。Data Caching这个选项如果你有多个场景且希望移动端浏览器按关卡缓存数据可以打开。但如果已经用了Addressable做资源分包这个选项的优先级就没那么高了反而可能造成本地缓存和内存的双重压力。WebGL Memory Size是新手最容易乱调的一项。这个值代表Unity启动时向浏览器申请的内存大小单位是MB。项目大不代表这个值就要无限调大因为浏览器能申请的连续内存是有限的设置过大会导致初始化直接失败设置过小又会频繁触发GC甚至内存溢出。我一般先按256MB跑然后用Profiler观察实际峰值再在这个基础上留出30%余量。别一上来就填个1024浏览器不一定买账。2.2 构建产物长什么样搞清楚构建产物的结构部署时心里才踏实。构建完成后Build目录下大概长这样WebGL/Build/MyGame_0.1.data WebGL/Build/MyGame_0.1.framework.js WebGL/Build/MyGame_0.1.loader.js WebGL/Build/MyGame_0.1.wasm.loader.jsUnity的启动加载器负责下载其余资源并初始化运行时。.framework.js引擎和IL2CPP相关的JavaScript绑定与元数据。.wasm编译好的WebAssembly模块是引擎执行代码的主体。.data所有场景、纹理、音频、预制体等序列化资源数据体积最大的通常是它。注意文件名里带版本号或hash这是Unity的构建机制决定的。这个特性对缓存特别友好文件名变了浏览器和ESA缓存都会自然失效自动加载新文件文件名没变就放心大胆地长缓存。部署时千万不要自己去改这些文件名改了加载器就找不到资源了。2.3 资源加载优化上线前的体积自查构建产物体积超标别急着怪Unity先检查资源。我给项目做上线自查时有一张常规清单Texture压缩格式WebGL平台优先选ASTC或ETC2避免PNG/JPG直传大图。带透明通道的UI图尽量打图集。Audio资源WAV和未压缩的音频是体积杀手能切成Compressed格式就切背景音乐用Ogg或MP3。初始场景资源首场景同步加载的资产越少首屏越快。大场景模型、高清贴图能异步加载就异步加载。Addressable分包把核心包和关卡包分开第一屏只需要核心包后续内容按需拉取。粒子特效WebGL上粒子系统的内存释放不及时经常导致内存持续上涨尽量用对象池复用不要频繁创建销毁。这些工作不做后面无论部署得多完美用户该等还是等。2.4 修改一个合适的WebGL模板Unity默认的WebGL模板只有个转圈圈加载动画生产环境根本不够用。我习惯在Assets/WebGLTemplates/下建一个自定义模板改出中文进度提示、启动图、自定义Logo。新版Unity模板的加载进度回调在createUnityInstance的配置里大致是这样一个结构createUnityInstance(canvas, config, onProgress).catch(message { alert(message); }); function onProgress(progress) { var percent Math.round(progress * 100); document.getElementById(progressBar).style.width percent %; document.getElementById(progressText).textContent percent %; }不同Unity版本模板API略有差异关键看模板目录里Unity自带的index.html注释它会把启动进度回调的示例写在里面。改模板时顺手把加载期间的背景色、进度条样式一起做了上线后观感会专业很多。3. ECS搭建Nginx源站必须稳3.1 买台什么样的ECS够用源站机器不用追求高配因为边缘层挡掉了大部分请求。我常用的起步配置是2核4G、SSD云盘50G起步、固定带宽5M或以上。CPU和内存不是瓶颈带宽才是。ESA回源时要拉取几百MB的资源带宽太小回源很吃力尤其在缓存刚刷新的阶段。操作系统建议选Alibaba Cloud Linux 3.0或者Ubuntu 22.04。Alibaba Cloud Linux对阿里云基础设施的兼容性更好安全更新也及时Ubuntu则社区资料多、排查问题方便。两个都能用看团队熟悉哪个。安全组规则一定要在购买后第一时间配好开放22端口用于SSH开放80和443用于Web访问其他端口全部关闭。这一步别偷懒源站暴露多余端口等于给攻击者留门。3.2 安装并配置Nginx的关键细节Nginx安装很简单Ubuntu执行apt update apt install nginx -yAlibaba Cloud Linux执行dnf install nginx -y。真正的坑在配置细节。先看一个生产可用的站点配置server { listen 80; server_name game.example.com; return 301 https://$host$request_uri; } server { listen 443 ssl http2; server_name game.example.com; root /var/www/webgl; index index.html; ssl_certificate /etc/nginx/cert/game.example.com.pem; ssl_certificate_key /etc/nginx/cert/game.example.com.key; # wasm的MIME类型必须显式声明 types { application/wasm wasm; } # 带hash的构建产物长缓存 location ~* \.(wasm|data|framework|js|css|png|jpg|jpeg|webp|svg)$ { add_header Cache-Control public, max-age31536000, immutable; } # 跨域隔离Unity WebGL多线程必需 add_header Cross-Origin-Opener-Policy same-origin; add_header Cross-Origin-Embedder-Policy require-corp; add_header Cross-Origin-Resource-Policy same-origin; # 跨域访问 add_header Access-Control-Allow-Origin *; location / { try_files $uri $uri/ /index.html; } }第一件事.wasm的Content-Type如果不设置Nginx默认按application/octet-stream返回浏览器会拒绝解析WebAssembly直接白屏。这个我排查过太多次了永远是第一嫌疑。第二件事multi-threading相关的三个跨域隔离头。Unity WebGL开启多线程后运行时需要SharedArrayBuffer而浏览器要求页面处于cross-origin isolation状态。也就是说必须同时返回Cross-Origin-Opener-Policy: same-origin和Cross-Origin-Embedder-Policy: require-corp。如果项目没开多线程这两个头不要加尤其COEP会阻止加载外部域名的资源加了反而添乱。第三件事Unity构建时如果启用了Brotli或Gzip产物文件本身就是压缩过的服务器端不要再对Build目录做二次压缩。Nginx默认不会压缩未知MIME类型问题不大但如果你额外配置了gzip_types记得把application/wasm排除在外。3.3 上传构建产物与权限设置产物上传我习惯用rsync增量同步省时间rsync -avz --progress Build/ root你的ECS公网IP:/var/www/webgl/Build/上传完成后目录权限必须检查否则Nginx的worker进程读不到文件。我遇到过索引页能打开、但Build目录请求全部403的怪问题最后发现是构建产物目录权限是700只有root能读。执行一遍chown -R root:root /var/www/webgl chmod -R 755 /var/www/webgl上传完先用curl验证MIME和状态码curl -I https://game.example.com/Build/MyGame_0.1.wasm如果返回200且Content-Type: application/wasm这一步才算过关。3.4 HTTPS证书免费证书的申请与续期WebGL项目离不开HTTPS。阿里云的数字证书管理服务可以申请免费DV证书也能下载Nginx格式的证书文件。申请下来后把xxx.pem和xxx.key放到/etc/nginx/cert/目录再在Nginx配置里引用。有一点提醒一下阿里云免费证书的有效期现在是3个月到期需要重新申请并更新配置。这个没办法免费的东西总要勤快点。习惯之后每次上线前检查证书有效期顺手续期操作成本并不高。另外如果域名和ECS都在国内ICP备案是上线前提。没有备案的域名无论是ECS的80/443端口还是ESA接入都会被云厂商拦截。这一环要在项目排期里提前留出时间别等构建完了才开始走流程。4. ESA配置边缘加速和安全兜底4.1 ESA和CDN的关系传统CDN主要做缓存加速把静态资源分发到边缘节点。阿里云ESA把这一层升级成了边缘安全加速平台缓存加速仍然是基础能力但DDoS防护、WAF、Bot管理、四层代理、DNS配置这些安全功能全部整合了进来。对Unity WebGL项目来说ESA最实用的价值在于大文件从边缘节点就近返回延迟和下载速度都能改善同时WAF和限速能把刷流量的恶意请求挡在源站前面。WebGL包体积大一旦被恶意刷流量源站带宽费和ESA流量费都会涨得非常快防刷配置不是可有可无是必须做的。4.2 域名接入与回源配置在ESA控制台添加站点接入方式有NS接入和CNAME接入两种。NS接入是让ESA接管整个域名的DNS解析配置更彻底但影响面也大CNAME接入只需要在现有DNS解析里加一条CNAME记录改动小、回滚容易。我建议用CNAME接入除非你有特殊需求想把DNS统一管理。回源配置那一栏填ECS的公网IP回源协议建议选HTTPS回源HOST填你的域名而不是IP。这个HOST头很关键如果不填或填IPNginx的server_name匹配不上源站会找不到对应的站点配置返回502或者默认站点页面。接入完成后在DNS服务商处添加一条CNAME记录指向ESA分配的加速域名。生效时间一般在几分钟到一小时可以在控制台看到状态变为正常。4.3 缓存规则决定用户加载速度的关键Unity构建产物文件名带hash这一特性配合ESA缓存规则能做到既缓存加速又不错版本。我常用的设置是资源类型缓存策略index.htmlno-cache或 max-age0*.wasm / *.data / *.framework.js / *.js / *.cssmax-age31536000, immutable图片字体等max-age31536000, immutable原则很简单index.html是入口不能缓存因为每次发版它引用的新文件名要第一时间生效带hash的静态资源可以永久缓存因为文件名变化自然会让缓存失效。还有一个细节ESA通常有“缓存规则”和“源站缓存配置”的联动。如果源站Nginx已经返回了Cache-Control头ESA默认策略有时会覆盖它。你需要在规则里明确静态资源的缓存时间和源站保持一致或者直接用源站响应头。我在实际项目里是两边都设了长缓存然后发布新版时手动在ESA控制台执行一次“缓存刷新”保证新版本能立即全量生效。4.4 防刷与WAF基础配置ESA控制台的安全配置里基础WAF默认开启就能拦掉大部分常见攻击。对Unity WebGL项目我额外做了两件事。第一是频率限制。针对整个站点设置单IP的请求频率阈值超过就触发拦截或加验证。WebGL包这么大单用户正常访问不会产生高频请求阈值可以设得相对严一些。万一有人拿脚本循环刷新下载限速能直接让他的流量成本飙升同时保护你的账户。第二是对敏感路径单独配置防护规则。如果以后后端API挂在同一个域名下比如/api路径就针对这个路径单独开Bot管理、加更严格的限速。静态资源路径保持宽松即可太严格的规则反而可能误伤正常用户。5. 上线后的常见故障与排查思路5.1 白屏、404、MIME类型先看这三个白屏是Unity WebGL部署最常见的故障排查顺序我固定是三步。第一步看Network面板确认index.html是否返回200。如果index.html都没加载出来问题在DNS、ESA接入或者ECS安全组。第二步看Build目录下请求是否全部返回200。如果有404大概率是上传文件不完整或路径不对检查上传目录结构和Nginx的root是否匹配。第三步看wasm请求的Content-Type。如果响应头里不是application/wasm几乎可以断定白屏根源就是MIME类型没配。Solution就是前文那个types配置加完重载Nginxnginx -s reload5.2 SharedArrayBuffer is not defined如果Unity工程开启了多线程浏览器控制台会报SharedArrayBuffer is not defined这个错代表页面没有进入跨域隔离状态。检查Nginx响应头里是否同时包含Cross-Origin-Opener-Policy: same-origin和Cross-Origin-Embedder-Policy: require-corp。配置正确后还需要强制刷新浏览器因为跨域隔离状态变化后旧页面进程不会自动恢复要重新打开。加了COEP之后还有个连锁反应页面加载的外部域资源会被全部拦截。如果你的自定义模板里引用了外部字体、统计脚本或广告SDK记住要么改成同源文件要么把外部资源的响应也加上Cross-Origin-Resource-Policy: cross-origin。不然资源会被Block掉页面看起来像是坏了一半。5.3 首屏加载慢的排查思路首屏加载慢先分清是“边缘缓存没命中”还是“Unity运行时初始化慢”。在浏览器Network面板看第一个大资源文件的加载耗时。如果耗时主要花在data和wasm的下载上说明是传输层问题。检查ESA控制台的命中率如果命中率低可能是刚发布完没做缓存预热。我的做法是上线后先自己用多个地区节点访问一遍页面让边缘缓存把资源拉起来之后用户访问就有命中了。如果下载很快、但浏览器要很久才出现Unity画面问题出在Unity初始化阶段。这种情况查压缩格式是否开启Brotli/Gzip会显著影响下载后加载器解压的耗时再查WebGL Memory Size是否合理内存申请过大时浏览器会自动回收再申请导致启动迟钝。还有一个细节源站Nginx如果配置了gzip而Unity产物又已经压缩过两边重复压缩不仅浪费CPU加载器解压时还可能出错。检查Nginx的gzip_types确保没有针对Unity产物开启动态压缩。5.4 内存溢出和浏览器崩溃Unity WebGL跑在浏览器里内存空间是平铺的而且受浏览器限制比较死。项目里最典型的崩溃场景打开页面玩了一会儿标签页直接黑屏然后提示“页面无响应”。先看Player Settings里的WebGL Memory Size是不是偏小用Profiler抓运行时内存峰值留足余量。再看场景和资源释放逻辑。WebGL上最容易内存泄漏的坑之一就是粒子特效和动态加载的Texture用完之后引用没有清干净内存只涨不跌。这类问题在编辑器里跑PC平台不一定暴露得出来但WebGL的苛刻内存环境下隐藏不住。做对象池、用完后主动销毁、清理AssetBundle这一步逃不掉。5.5 一组实测数据参考用一个实际项目的数据做参照。原始构建产物data约520MBwasm约18MBframework.js约1.2MB。开启Brotli后data压到286MBwasm压到8.4MB整体下载体积减少约45%。首次部署完成、边缘缓存尚未命中时同城用户首屏加载耗时约35秒到47秒其中绝大部分是data下载和Unity初始化。缓存预热后二次访问降到12到18秒浏览器本地命中缓存后更快。ESA缓存命中率稳定在92%以上源站的回源流量压力很小ECS的CPU占用常年不到10%。这套数据说明把缓存策略和压缩格式做好体感提升远比换更高配的服务器明显。我个人在实际操作中最深的一个体会是Unity WebGL上云这件事真正的功夫不在云上而在构建参数和缓存策略的提前规划。MIME类型、跨域隔离头、压缩格式、缓存TTL这四样东西如果你在第一天就配好上线时根本不会遇到那些折腾人的白屏和加载失败。等真的遇到问题再回头补每一步都要重新排队心态也是最差的。后面无论项目怎么迭代发布流程基本上就是三步本地构建、上传Build目录、刷新ESA缓存。把这套流程固定下来Unity WebGL发布到阿里云就不再是玄学。