Question

supermap-iclient3d-for-webgl_webgpu-2026   加载图层报错，

  cesium js sdk加载正常

Answer 1

您好，

麻烦您提供一下具体加载的是哪种类型的图层，比如影像、矢量还是地形等，以及加载该图层的相关代码片段。

另外请问您是通过什么方式加载的，是直接调用 SuperMap3D 的 API，还是通过 iClient3D 封装的接口？初始化时 token 参数是怎么传入的？

还想确认一下，这个问题是仅在您的业务代码中才会出现，还是单独写一个空白页面加载同样数据也会报错？

请提供更多信息方便定位问题。

Comments

//加载模型图层
 var promise = Viewer.scene.addS3MTilesLayerByScp(layerPath );
 promise.then(function (curLayer) ）
 

就这样直接加载， cesiumjs也是这样加载。  只有supermap 报错

初始没有传token, 示例也没传token吧

---

您好，

感谢您提供的代码片段。为了准确排查这个 InvalidCharacterError 报错，我们需要在本地实际复现一下问题。

由于 iClient3D for Cesium 加载正常，而 iClient3D for WebGL 报错，怀疑可能与特定的数据格式或加密（License）校验机制有关。因此，能否麻烦您提供一份能够复现该问题的最小数据？（一小块数据即可，包含对应的 S3M 图层文件及配置文件），您可以直接将数据网盘链接通过私信发送给我们。

收到数据后，我们会尽快在本地进行测试定位。感谢您的配合与支持！

---

您好，

针对您反馈的“同一份 S3M 数据，iClient3D for Cesium 能正常加载，而 iClient3D for WebGL（12.1.0）报错（AESGCMDecrypt 失败）”的问题，经排查，这是由两套产品底层安全验证机制不同所导致的正常现象。具体原因如下：

1、iClient3D for WebGL 12.1.0 启用了“隧道加密”机制
新版本 WebGL 为了提升数据传输安全性，新增了隧道加密功能。在加载图层前，它会强制进行 publickey.json 获取、tunnels.json 请求及 AES 解密验证（即您截图中报错的 AESGCMDecrypt 阶段）。由于您的环境使用了代理服务器，如果代理未正确转发这些加密文件，前端就会因获取到错误内容而抛出 atob 解码异常。

2、iClient3D for Cesium 使用的是“明码验证”机制
而 iClient3D for Cesium 目前使用的是明码验证，它绕过了上述复杂的隧道加密和解密流程。因此，即便代理配置不完整， iClient3D for Cesium 也能直接读取并加载数据。
由于两套产品的机制不同，不能以 iClient3D for Cesium 能加载作为标准。要解决 iClient3D for WebGL 的报错，必须确保代理服务器正确放行并转发以下路径：

• publickey.json

• tunnels.json

• /iserver/services/security/tunnel/v1/tunnels/*.json

请检查您的代理配置，确保上述请求返回的是正确的 JSON 数据。可参考以下代理配置，加密验证通过后， iClient3D for WebGL 即可正常加载数据。

worker_processes  1;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    sendfile        on;
    keepalive_timeout  65;

    # WebSocket 基础映射
    map $http_upgrade $connection_upgrade {
        default upgrade;
        '' close;
    }

    upstream iserver_cluster {
        #ip_hash; # 安全隧道必须保留，会话粘连
        server 127.0.0.1:8082;
        server 127.0.0.1:8083;
        server 127.0.0.1:8084;
    }

    server {
        listen       8080;
        server_name  localhost 172.16.12.218;

        location / {
            root   html;
            index  index.html index.htm;
        }

        location = /publickey.json {
            proxy_pass http://iserver_cluster;
            proxy_redirect off;
            proxy_http_version 1.1;
            proxy_set_header Host $host:$server_port;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

        location = /tunnels.json {
            proxy_pass http://iserver_cluster;
            proxy_redirect off;
            proxy_http_version 1.1;
            proxy_set_header Host $host:$server_port;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

        location /iserver {
            proxy_pass http://iserver_cluster;
            proxy_redirect off;
            proxy_buffering off;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
            proxy_set_header Host $host:$server_port;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

            proxy_connect_timeout 60s;
            proxy_send_timeout 3600s;
            proxy_read_timeout 3600s;
        }

        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }

    server {
        listen       8082;
        server_name  localhost 172.16.12.218;

        location / {
            add_header X-Upstream-Node "8082" always;
            proxy_pass http://127.0.0.1:8090;
            proxy_redirect off;
            proxy_buffering off;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
            proxy_set_header Host $host:$server_port;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }

    server {
        listen       8083;
        server_name  localhost 172.16.12.218;

        location / {
            add_header X-Upstream-Node "8083" always;
            proxy_pass http://127.0.0.1:8090;
            proxy_redirect off;
            proxy_buffering off;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
            proxy_set_header Host $host:$server_port;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }

    server {
        listen       8084;
        server_name  localhost 172.16.12.218;

        location / {
            add_header X-Upstream-Node "8084" always;
            proxy_pass http://127.0.0.1:8090;
            proxy_redirect off;
            proxy_buffering off;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
            proxy_set_header Host $host:$server_port;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }
}

希望能够帮助到您。 

---

有两个问题

1./iserver/services/security/tunnel/v1/tunnels/路径没有找到呢

2.这两个json是都放在这个路径下面吗

---

您好，

1、这个路径不用单独配，已有 location /iserver，它是前缀匹配，会覆盖：

/iserver/services/security/tunnel/v1/tunnels/xxx.json

2、不是都放在这个路径下面，它们是三个不同接口：

• /publickey.json

• /tunnels.json

• /iserver/services/security/tunnel/v1/tunnels/xxx.json

前两个已在 Nginx 单独代理，第三个由 /iserver 覆盖。最终都转发到 127.0.0.1:8090。

配置可参考我上一条回复里贴的完整 Nginx 例子，其中已经包含这三个路径的代理规则。

希望能够帮助到您。