Jack.Shang的技术博客

一、Mac电脑用户发现的问题：

有使用Mac笔记本电脑的同事按照 Jack.Shang的技术博客 » HZERO PaaS平台-Docker版demo笔记（五）安装部署readme 进行部署后发现问题：

启动平台服务的时候会提示 警告，AMD64 不匹配当前平台

但是可以启动成功。

1. 前台 URL 无法登录

访问 http://dev.hzero.com.cn/

点击重新登录

二、问题分析&解决

分析：我们之前的镜像是基于默认的amd64，需要生成arm64版的，这包括JDK和linux基础镜像都要用arm64版的。

操作步骤：

1. 下载arm64版的 IBM OpenJDK

Semeru Runtime Downloads – IBM Developer

下载这个版本：

• 新建目录 /d01/openJ9-0.53-dockers-arm64

把下载的文件放到这个目录下

• 编辑arm64版的 JavaBase 基础镜像

# 明确指定arm64架构的基础镜像

FROM arm64v8/ubuntu:22.04

ENV TZ=UTC \

    LANG=en_US.UTF-8 \

    JAVA_HOME=/opt/java/openjdk \

    PATH=/opt/java/openjdk/bin:$PATH

# 安装arm64架构的依赖（和amd64依赖名一致，系统会自动匹配架构）

RUN apt-get update \

    && DEBIAN_FRONTEND=noninteractive apt-get install -y –no-install-recommends \

       libc6 libstdc++6 zlib1g ca-certificates \

    && apt-get clean \

    && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

RUN mkdir -p ${JAVA_HOME} && chmod -R 755 ${JAVA_HOME}

# 替换为arm64版本的JDK包

COPY ibm-semeru-open-jdk_aarch64_linux_17.0.16_8_openj9-0.53.0.tar.gz /tmp/

RUN cd ${JAVA_HOME} \

    && tar -xvf /tmp/ibm-semeru-open-jdk_aarch64_linux_17.0.16_8_openj9-0.53.0.tar.gz –strip-components=1 \

    && rm -f /tmp/*.tar.gz \

    && rm -rf ${JAVA_HOME}/docs \

    && rm -rf ${JAVA_HOME}/lib/src.zip \

    && rm -rf ${JAVA_HOME}/legal \

    && rm -rf ${JAVA_HOME}/man \

    && java -version

CMD [“java”, “–version”]

• #构建Ibm OpenJDK OpenJ9-0.53版 arm版的Java基础镜像

#先把arm64版的ubuntu 22.04 pull下来

$ docker pull –platform linux/arm64/v8 arm64v8/ubuntu:22.04

22.04: Pulling from arm64v8/ubuntu
0ec3d8645767: Pull complete
Digest: sha256:e59ca854700f0c80ac005a52585e2e594ba70dfe82fa4c5228db509163222444
Status: Downloaded newer image for arm64v8/ubuntu:22.04
docker.io/arm64v8/ubuntu:22.04

#构建java运行基础镜像

$ cd /d01/openJ9-0.53-dockers-arm64

$ docker build –platform linux/arm64/v8 -t ibm-semeru-runtimes:open-17-jdk .

5、#拷贝复制jar文件

打开/d01/batch_copy_jar_from_wsl_openj9.ps1

复制并在powershell窗口中粘贴，可完成拷贝。

6、#修改批量构建镜像的脚本

$ cd /d01

$ cp hzero-batch-build-dockerimage.sh hzero-batch-build-dockerimage-arm64.sh

$ vi hzero-batch-build-dockerimage-arm64.sh

更改构建命令部分，添加–platform linux/arm64/v8：

    # 执行Docker构建命令，并捕获结果

    if docker build –platform linux/arm64/v8 -t “$image_name:$VERSION” . >> “$LOG_FILE” 2>&1; then

7、#基于新的java基础镜像批量构建平台服务镜像

$ cd /d01

$ bash hzero-batch-build-dockerimage-arm64.sh

• 更换中间件服务为arm64版

8.1 mysql

$ cd /d01/hzero-dockers/mysql-docker

$ vi Dockerfile

修改：

# 基于官方 MySQL 8 镜像

FROM –platform=linux/arm64/v8 mysql:8.4.7

# 设置 MySQL root 密码  ENV MYSQL_ROOT_PASSWORD=

ENV MYSQL_ALLOW_EMPTY_PASSWORD=yes

# 复制自定义配置文件到 MySQL 配置目录（配置文件无架构差异，无需修改）

COPY my_custom.cnf /etc/mysql/conf.d/

#构建mysql镜像

$ docker build –platform linux/arm64/v8 -t mysql-hzero-jk-demo:8.4.7 .

#下载 arm64版的minio

docker pull –platform linux/arm64/v8 minio/minio:RELEASE.2025-06-13T11-33-47Z

这个下载下来后，没有arm64标记，点进去看也是x_86的版本

$ docker compose up -d

$ docker exec -it minio-hzero uname -m

$ 显示的也是 x86_64

豆包说这是多架构的镜像，多架构镜像不会有arm64标记，至于说在镜像层看到的x86_64标记可能是镜像制作者“偷懒”没改掉，实际可能是arm64的，最终能判断的是容器启动后看docker exec -it minio-hzero uname -m返回的结果

另外：必须在docker-compose.yml中指定平台，否则默认就是启动当前架构（x86）的镜像:

#更改docker-compose.yml文件，指定平台：

## 要求Docker/Docker CE >= 19.x

services:

  minio-hzero:

    image: minio/minio:RELEASE.2025-06-13T11-33-47Z

    platform: linux/arm64/v8

    container_name: minio-hzero

$ docker compose up -d

启动命令执行后发现它主动去拉去镜像了，说明之前docker pull –platform linux/arm64/v8 minio/minio:RELEASE.2025-06-13T11-33-47Z 没有真实拉到arm64的镜像？

$ docker exec -it minio-hzero uname -m

确实启动后进入可以看到确实是arm64的架构：

#下载 arm64版的mongo:5.0.25

docker pull –platform linux/arm64/v8 mongo:5.0.25

#下载arm64版的neo4j

docker pull –platform linux/arm64/v8 neo4j:5.16.0

#下载arm64版的nginx:latest

docker pull –platform linux/arm64/v8 nginx:latest

#下载arm64版的onlyoffice/documentserver

docker pull –platform linux/arm64/v8 onlyoffice/documentserver:latest

#下载arm64版的redis:6-alpine（6-alpine标签下载失败，改成latest标签，不影响使用）

docker pull –platform linux/arm64/v8 redis:latest

#下载arm64版的elasticsearch:8.12.2

docker pull –platform linux/arm64/v8 elasticsearch:8.12.2

#实验发现：mongo,neo4j,nginx,onlyoffice,redis,elasticsearch  指定arm平台Pull之后，都没有arm64标记：

那就是应该认为，这些中间件都是多架构镜像，都要像minio一样在docker-compose.yml中指定平台：

platform: linux/arm64/v8

#redis 修改后启动

确认是arm64架构

其他几个：mongo,neo4j,nginx,onlyoffice,elasticsearch 也都这样修改，再启动验证

实验发现，这几个在启动的时候都有pulling的过程，说明之前直接执行pull命令没啥作用，关键还是要在docker-compose.yml启动文件中指定平台。

#下载arm64版的kkfileview

https://resource.kkview.cn/kkFileView-4.4.0-docker_aarch64.tar

$ docker load -i kkFileView-4.4.0-docker_aarch64.tar

#这个加载后是有arm64标记的

修改kkfileview的docker-compose.yml

#修改image:  image: keking/kkfileview_aarch64:4.4.0

9、2个python镜像：

#下载arm64版的hzero-hkms
docker pull –platform linux/arm64 registry.hand-china.com/hzero-public/hkms-python_arm64:1.6.1

注意：这个命令要在Linux安装的docker环境执行，汉得的这个制品库在WSL集成的Docker Desktop环境中执行报连不上，经测试不是用户名密码的问题，ping也能通，但就是连不上。

#下载arm64版的hzero-hype

docker pull –platform linux/arm64  registry.hand-china.com/hzero-public/hkms-python_arm64:1.6.1

注意：这个命令要在Linux安装的docker环境执行，汉得的这个制品库在WSL集成的Docker Desktop环境中执行报连不上，经测试不是用户名密码的问题，ping也能通，但就是连不上。

#hzero-hkms 镜像

$ cd /d01/hzero-dockers/hzero-hkms-docker

$ cp docker-compose.yml docker-compose.yml.x86

#编辑 docker-compose.yml

#更改：

image: registry.hand-china.com/hzero-public/hkms-python_arm64:1.6.1

#hzero-hype 镜像

$ cd /d01/hzero-dockers/hzero-hype-docker

$ cp docker-compose.yml docker-compose.yml.x86

#编辑 docker-compose.yml

#更改：

 image: registry.hand-china.com/hzero-public/haip-python-executor_arm64:0.2

10、更改save-dockers.sh  & Save Arm版镜像

$ cd /d01/hzero-docker-images-arm64

#更改 save-dockers.sh ,主要是两个python镜像名，kkfileview 镜像名要改，另外几个中加件原来用registry.hand-china.com的，改成直接用官方的了。其他不需要变。

#导出arm64版的镜像集合

$ bash save-dockers.sh

结果，有6个save未成功：

docker save -o mongo-hzero.tar mongo:5.0.25

docker save -o redis-hzero.tar redis:latest

docker save -o nginx-hzero.tar nginx:latest

docker save -o elasticsearch-hzero.tar elasticsearch:8.12.2

docker save -o neo4j-hzero.tar neo4j:5.16.0

docker save -o onlyoffice-hzero.tar onlyoffice/documentserver:latest

豆包分析是：问题根源：x86 Docker 对 arm64 镜像的元数据解析和文件存储不兼容，导致 “创建时间 N/A” 和 “导出失败”；

解决方案：无需解决，因为docker-compose.yml 中已经指定arm平台，且可以自动下载，都是官方镜像。

在save-dockers.sh 中注释掉这几个镜像

在load-dockers.sh 中去掉这几个镜像

#docker load -i mongo-hzero.tar

#docker load -i redis-hzero.tar

#docker load -i nginx-hzero.tar

#docker load -i elasticsearch-hzero.tar

#docker load -i neo4j-hzero.tar

#docker load -i onlyoffice-hzero.tar

1. 打包

# 先删除jar文件

$ cd /d01
$ bash delete_jar_files.sh
# 再打包
$ tar -czvf hzero-dockers-arm64.tar.gz hzero-dockers

$ tar -czvf hzero-docker-images-openj9-0.53-arm64.tar.gz hzero-docker-images-arm64

1. 备份下Ibm OpenJDK OpenJ9-0.53版 arm版的Java基础镜像

$ cd /d01/openJ9-0.53-dockers-arm64

$ docker save -o ibm-semeru-runtimes-open-17-jdk-openJ9-0.53-arm64.tar ibm-semeru-runtimes:open-17-jdk

三、后续工作

一、恢复到x86环境

1、#批量并执行-恢复到x86环境的shell脚本

$ cd /d01

$ bash batch_recovery_x86_env.sh

==============================

#!/bin/bash

#恢复中间件服务

cp -f /d01/hzero-dockers/redis-docker/docker-compose.yml.x86  /d01/hzero-dockers/redis-docker/docker-compose.yml

cp -f /d01/hzero-dockers/onlyoffice-docker/docker-compose.yml.x86  /d01/hzero-dockers/onlyoffice-docker/docker-compose.yml

cp -f /d01/hzero-dockers/nginx-docker/docker-compose.yml.x86  /d01/hzero-dockers/nginx-docker/docker-compose.yml

cp -f /d01/hzero-dockers/neo4j-docker/docker-compose.yml.x86  /d01/hzero-dockers/neo4j-docker/docker-compose.yml

cp -f /d01/hzero-dockers/mongo-docker/docker-compose.yml.x86  /d01/hzero-dockers/mongo-docker/docker-compose.yml

cp -f /d01/hzero-dockers/minio-docker/docker-compose.yml.x86  /d01/hzero-dockers/minio-docker/docker-compose.yml

cp -f /d01/hzero-dockers/elasticsearch-docker/docker-compose.yml.x86  /d01/hzero-dockers/elasticsearch-docker/docker-compose.yml

cp -f /d01/hzero-dockers/kkfileview-docker/docker-compose.yml.x86  /d01/hzero-dockers/kkfileview-docker/docker-compose.yml

#恢复hzero 两个python服务

cp -f /d01/hzero-dockers/hzero-hkms-docker/docker-compose.yml.x86  /d01/hzero-dockers/hzero-hkms-docker/docker-compose.yml

cp -f /d01/hzero-dockers/hzero-hype-docker/docker-compose.yml.x86  /d01/hzero-dockers/hzero-hype-docker/docker-compose.yml

#恢复Mysql

cp -f /d01/hzero-dockers/mysql-docker/Dockerfile.x86  /d01/hzero-dockers/mysql-docker/Dockerfile

2、#恢复x86版的Java运行环境基础镜像

cd /d01/openJ9-0.53-dockers

docker build -t ibm-semeru-runtimes:open-17-jdk .

3、#恢复加载X86版的Java服务和中间件镜像

$ cd /d01/hzero-docker-images

$ bash load-dockers.sh

#或者先拷贝jar文件再批量构建

#在Windows powershell 窗口中粘贴batch_copy_jar_from_wsl_openJ9.ps1中的内容，然后

#构建x86版Java服务镜像和mysql镜像

$ cd /d01

$ bash hzero-batch-build-dockerimage-arm64.sh

$ cd /d01/hzero-dockers/mysql-docker

$ docker build -t mysql-hzero-jk-demo:8.4.7 .

二、批量切换到arm64环境

1、#批量并执行-切换到arm64环境的shell脚本

$ cd /d01

$ bash batch_switch_to_arm64_env.sh

==============================

#!/bin/bash

#切换到arm64版中间件服务

cp -f /d01/hzero-dockers/redis-docker/docker-compose.yml.arm64  /d01/hzero-dockers/redis-docker/docker-compose.yml

cp -f /d01/hzero-dockers/onlyoffice-docker/docker-compose.yml.arm64  /d01/hzero-dockers/onlyoffice-docker/docker-compose.yml

cp -f /d01/hzero-dockers/nginx-docker/docker-compose.yml.arm64  /d01/hzero-dockers/nginx-docker/docker-compose.yml

cp -f /d01/hzero-dockers/neo4j-docker/docker-compose.yml.arm64  /d01/hzero-dockers/neo4j-docker/docker-compose.yml

cp -f /d01/hzero-dockers/mongo-docker/docker-compose.yml.arm64  /d01/hzero-dockers/mongo-docker/docker-compose.yml

cp -f /d01/hzero-dockers/minio-docker/docker-compose.yml.arm64  /d01/hzero-dockers/minio-docker/docker-compose.yml

cp -f /d01/hzero-dockers/elasticsearch-docker/docker-compose.yml.arm64  /d01/hzero-dockers/elasticsearch-docker/docker-compose.yml

cp -f /d01/hzero-dockers/kkfileview-docker/docker-compose.yml.arm64  /d01/hzero-dockers/kkfileview-docker/docker-compose.yml

#切换到arm64版 hzero 两个python服务

cp -f /d01/hzero-dockers/hzero-hkms-docker/docker-compose.yml.arm64  /d01/hzero-dockers/hzero-hkms-docker/docker-compose.yml

cp -f /d01/hzero-dockers/hzero-hype-docker/docker-compose.yml.arm64  /d01/hzero-dockers/hzero-hype-docker/docker-compose.yml

#切换到arm64版Mysql

cp -f /d01/hzero-dockers/mysql-docker/Dockerfile.arm64  /d01/hzero-dockers/mysql-docker/Dockerfile

2、#切换到arm64版的Java运行环境基础镜像

cd /d01/openJ9-0.53-dockers-arm64

docker build –platform linux/arm64/v8 -t ibm-semeru-runtimes:open-17-jdk .

3、#切换到arm64版hzero java和中间件服务镜像

$ cd /d01/hzero-docker-images-arm64

$ bash load-dockers.sh

#或者先拷贝jar文件再批量构建

#在Windows powershell 窗口中粘贴batch_copy_jar_from_wsl_openJ9.ps1中的内容，然后

#构建Arm64版Java服务镜像和mysql镜像

$ cd /d01

$ bash hzero-batch-build-dockerimage-arm64.sh

$ cd /d01/hzero-dockers/mysql-docker

$ docker build –platform linux/arm64/v8 -t mysql-hzero-jk-demo:8.4.7 .

#faq-section

四、实测问题

问题1：访问注册中心服务的网页速度很慢的问题

原因：同事的mac版Docker Desktop设置里面分配的内存太少（默认是8G）

解决：在Docker的设置/资源管理处把内存调整到30G后速度很快，问题解决。

问题2：启动服务时发现oauth服务的8021端口被占用，导致该服务启动失败

这个8021端口冲突问题在MAC上比较常见
现象：docker start  hzero-oauth

Error response from daemon: ports are not available: exposing port TCP 0.0.0.0:8021 -> 127.0.0.1:0: listen tcp 0.0.0.0:8021: bind: address already in use

Error: failed to start containers: hzero-oauth

可以用如下命令查看8021被什么程序占用？

PID=$(lsof -t -i tcp:8021) && if [ -n “$PID” ]; then ps -ef | grep “$PID”; else echo “端口 8021 未被占用”; fi

之前已经发现的原因有：
原因1：有同学发现是因为Docker Desktop本身的进程占用了该端口。

解决：重启Docker Desktop之后问题解决，因为该端口也是随机占用的端口。

原因2：也有同学发现是ftp-proxy占用了这个端口

解决：临时停止ftp-proxy
$ sudo launchctl tootout system/com.apple.ftp-proxy

#再次确认端口情况

$ sudo lsof-l :8021

#长期解决方案：鉴于8021端口在MAC环境冲突概率很高，所以改成18021端口：

#源环境：更改端口，重新build oauth服务 jar包

# windows powershell中

cp \\wsl.localhost\Ubuntu-2204-hzero-openjdk\d02\hzero\project\ps-oauth\target\ps-oauth.jar \\wsl.localhost\Ubuntu-22.04\d01\hzero-dockers\hzero-oauth-docker\

# 加载arm64版java base镜像

cd /d01/openJ9-0.53-dockers-arm64

docker load -i ibm-semeru-runtimes-open-17-jdk-openJ9-0.53-arm64.tar

#切换到arm64环境

cd /d01

bash batch_switch_to_arm64_env.sh

#重新构建oauth服务docker镜像

cd /d01/hzero-dockers/hzero-oauth-docker

docker build –platform linux/arm64/v8 -t hzero-oauth-jk-demo:1.12 .

#更改docker-compose.yml文件

#把8021端口映射改成18021端口

#导出镜像

cd  /d01/hzero-docker-images-arm64

docker save -o hzero-oauth-docker.tar hzero-oauth-jk-demo:1.12

#删除jar包

rm -f /d01/hzero-dockers/hzero-oauth-docker/ps-oauth.jar

#重新打包hzero-dockers

cd /d01

tar -czvf hzero-dockers-arm64.tar.gz  hzero-dockers

#重新打包hzero-docker-images-arm64

cd /d01

tar -czvf hzero-docker-images-openj9-0.53-arm64.tar.gz  hzero-docker-images-arm64

==========

恢复x86环境

# 加载x86版java base镜像

cd /d01/openJ9-0.53-dockers

docker load -i ibm-semeru-runtimes-open-17-jdk-openJ9-0.53-x86.tar

#切换到x86环境

cd /d01

bash batch_recovery_x86_env.sh

备注：在2026.01.08提交的安装文件中，已经改成18021端口。

问题3：登录时要求验证码，提示错误：缺少字体

原因：arm64版ubuntu 22.04 默认没有安装验证码所需字体（但该问题在x86/amd64版的ubuntu 22.04上不存在）

解决方案：先进入容器安装字体，然后进入hzero平台系统之后，在界面上把验证码设置关闭掉。

#进入 oauht服务的容器

docker exec -it hzero-oauth bash

# 更新软件源

sudo apt update

# 安装字体相关包（对应CentOS的fontconfig、dejavu字体）

sudo apt install -y fontconfig fonts-dejavu-core fonts-dejavu-extra

# 更新字体缓存（和CentOS的fc-cache命令一致）

fc-cache -fv

#完成上述字体安装后，再次登录hzero平台，多刷新几次可以成功登录；

登录后，在hzero平台系统设置的安全设置中，去掉验证码设置。

问题解决。

进一步思考：既然是hzero-oauth服务的容器缺少字体，那么在java基础运行环境镜像构建的时候把 fontconfig fonts-dejavu-core fonts-dejavu-extra 一并加上就可一劳永逸解决问题了。

于是就开始修改Dockfile ，添加字体，重新构建，但失败了，只要加上这个内容，就构建失败，当然可能是因为放在同一层构建才导致失败？ 再尝试放在单独层构建，也同样失败，看起来这字体想在镜像中直接加上是难以成功了。先这样吧，以后再说。

成功登录系统之后，更改系统设置:  在平台菜单/系统管理/安全设置 处，把验证码设置为非必须。

备注：在2026.01.06提交的安装文件中，已经预先更改系统设置:  在平台菜单/系统管理/安全设置 处，把验证码设置为非必须。

问题4：AIGC中台/Agent编排/编排测试 出现会话链接失败的错误

新建一个Agent编排，保存后，点上方的“编排测试” 结果出现 “会话链接失败，请联系管理员”的错误：

前端错误：

connection to ‘ws://aigc.hzero.com.cn/websocket?access_token=c45eaa37-5af6-41ed-aef5-bbd9c4ec995f&appSessionId=ea30a822-33fa-4cd0-a6e2-e4243de14025&interactionFlowCode=ZTEST_SAP_001&appFlowVersionNum=3&processorKey=interaction-pc&tenantId=2’ failed:

分析：

查看后台hzero-aip-app服务的日志，错误提示：

org.springframework.web.server.ServerWebInputException: 400 BAD_REQUEST “Invalid ‘Upgrade’ header: [X-Real-IP:”172.18.0.1″, Host:”aigc.hzero.com.cn”, X-Forwarded-For:”172.18.0.1″, Connection:”close”, Pragma:”no-cache”, Cache-Control:”no-cache”, User-Agent:”Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36 Edg/143.0.0.0″, Origin:”http://dev.hzero.com.cn”, Sec-WebSocket-Version:”13″, Accept-Encoding:”gzip, deflate”, Accept-Language:”zh-CN,zh;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6″, Sec-WebSocket-Key:”bBfD+JwcSTroPEwfkFnziA==”, Sec-WebSocket-Extensions:”permessage-deflate; client_max_window_bits”]”

问题给豆包，豆包说：

核心原因：Upgrade 头被代理 / 网关错误覆盖或过滤，导致其值不是 websocket 而是其他请求头的集合；

关键修复：代理（Nginx）需配置 proxy_set_header Upgrade $http_upgrade 和 proxy_set_header Connection “upgrade”，网关需保留 WebSocket 相关头部；

解决方案：

在nginx.conf 中添加配置（hzero-dockers\volumes\nginx\nginx.conf）：

在反向代理前面增加：

# 添加WebSocket支持

map $http_upgrade $connection_upgrade {

    default upgrade;

    “” close;

}

在反向代理中增加：

          # 添加WebSocket支持

          proxy_http_version 1.1;

          proxy_set_header Upgrade $http_upgrade;

          proxy_set_header Connection $connection_upgrade;

更改后重启nginx服务

$ cd /d01/hzero-dockers/nginx-docker && docker compose down && docker compose up -d

然后再次访问编排页面，就正常了：

这个问题是之前非docker环境迁移docker环境时漏掉的配置，之前非docker环境中，在/etc/nginx/sites-available/default中 反向代理是这么配置的：

# aigc.hzero.com.cn 专用服务器

server {

    listen 80;

    server_name aigc.hzero.com.cn;

    location / {

        # 改为后端服务实际IP:端口

        proxy_pass http://127.0.0.1:8088;  # 示例：假设后端在本机8088

        proxy_set_header Upgrade $http_upgrade;

        proxy_set_header Connection “upgrade”;

        proxy_set_header Host $host;  # 保留一个Host配置

        proxy_set_header X-Real-IP $remote_addr;

        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_buffering off;  # 按需开启/关闭（实时交互场景建议关闭）

    }

}

迁移到Docker环境后，由于$http_upgrade 变量缺少，当时为了启动Nginx，直接把这两行删除掉了：

        proxy_set_header Upgrade $http_upgrade;

        proxy_set_header Connection “upgrade”;

后来测试容器环境的时候只是测试了对话应用和知识库问答应用，但因为对话应用和知识库问答应用走的是SSE协议，没有走WS协议，所以就没发现问题。但编排应用会走WS协议，所以测试编排应用的时候就会发现问题。而且原来在default中的设置也不规范，有隐藏风险：

• 如果客户端请求全是 WebSocket（必然带 Upgrade: websocket 头），硬编码 Connection: upgrade 完全匹配需求；
• 只有当同一 location 同时处理「WebSocket 请求」和「普通 HTTP 请求」时，硬编码才会出问题（普通 HTTP 请求不需要 Connection: upgrade，会导致协议异常）。

问题已经更正。

备注：在2026.01.06提交的安装文件中，已经包含了更正过的nginx.conf配置文件了。