SpringBoot连接Nacos报错No Such Algorithm: HmacSHA256的排查与解决_Java

问题现象

在将 spring boot 应用部署至容器环境时，应用启动失败，日志中出现如下错误：

2026-08-07 22:20:50.111 error 6 --- [s.client.worker] c.a.nacos.client.security.securityproxy : login failed: {"code":400,"message":"caused: no such algorithm: hmacsha256;","header":{...}}

应用使用的 nacos 客户端（spring-cloud-starter-alibaba-nacos-discovery）在向 nacos 服务端发起登录认证请求时，服务端返回了 400 错误，并指明 hmacsha256 加密算法不可用。

问题排查

1. 确认错误来源

报错日志中的 securityproxy 属于 nacos 客户端，但 code:400 和异常信息 caused: no such algorithm 是服务端响应的内容。这说明：

客户端请求已发出
服务端在处理请求时抛出了算法不支持的异常，并将异常封装成 http 400 返回给客户端

因此，问题出在 nacos 服务端 的 java 环境上。

2. 检查服务端 jdk 版本

java -version

输出：

openjdk version "1.8.0_482"
openjdk runtime environment bisheng (build 1.8.0_482-b08)
openjdk 64-bit server vm bisheng (build 25.482-b08, mixed mode)

关键信息：服务端使用的是 华为 bisheng（毕昇）jdk，这是一个针对鲲鹏芯片优化的 openjdk 发行版。

3. 分析 bisheng jdk 的问题

bisheng jdk 包含一个称为 kae provider 的安全组件，旨在利用硬件加速加密运算（主要在鲲鹏平台上）。但在以下场景中可能导致 hmacsha256 不可用：

运行在非鲲鹏平台（如 x86 服务器）
缺少硬件驱动或相关设备文件
kae provider 配置不完整，导致 jvm 的安全提供者列表中未能正确注册该算法

当 nacos 服务端在认证过程中使用 hmacsha256 计算签名时，由于算法不可用，抛出 nosuchalgorithmexception，最终以 http 400 返回给客户端。

4. 客户端环境检查（补充）

本例中，业务容器使用的 docker 镜像是标准 openjdk：

from openjdk:8-jre-alpine

客户端 jdk 本身无问题，因此无需修改客户端。

5. 操作系统环境

宿主机操作系统为 麒麟 v10。如果考虑更换 jdk，需要选择合适的 rpm 包。麒麟 v10 不同子版本对应的软件包生态如下：

麒麟版本	推荐使用 el 版本
v10 sp3	el8
v10 sp2	el8
v10 sp1	el7

注意：麒麟 v10 从 sp1 开始，官方源中的 java-1.8.0-openjdk 可能已被替换为 bisheng jdk，安装时需格外留意。

解决方案

针对上述问题，提供三种解决思路，推荐优先使用 方案一。

方案一：禁用 bisheng jdk 的 kae provider

在 nacos 服务端的启动脚本 ${base_dir}/bin/startup.sh 中，为 java_opt 追加禁用 kae 的参数：

# 在所有 java_opt 赋值完成后增加一行
java_opt="${java_opt} -dkae.enable=false"

修改示例（只展示关键部分）：

if [[ "${mode}" == "standalone" ]]; then
    java_opt="${java_opt} ${custom_nacos_memory:- -xms512m -xmx512m -xmn256m}"
    java_opt="${java_opt} -dnacos.standalone=true"
else
    # ... 集群模式配置 ...
    java_opt="${java_opt} -server ${custom_nacos_memory:- -xms2g -xmx2g -xmn1g -xx:metaspacesize=128m -xx:maxmetaspacesize=320m}"
    java_opt="${java_opt} -xx:-omitstacktraceinfastthrow -xx:+heapdumponoutofmemoryerror -xx:heapdumppath=${base_dir}/logs/java_heapdump.hprof"
    java_opt="${java_opt} -xx:-uselargepages"
fi

# 🔧 新增禁用 kae
java_opt="${java_opt} -dkae.enable=false"

保存后，重启 nacos 服务端：

sh ${base_dir}/bin/shutdown.sh
sh ${base_dir}/bin/startup.sh -m standalone   # 或 -m cluster

重启后，bisheng jdk 将使用标准 java 加密提供者，hmacsha256 即可正常使用。

若上述参数无效，可尝试追加 -dcom.huawei.arm.security.disablekae=true 作为补充。

方案二：更换 nacos 服务端 jdk 为标准 openjdk

如果希望彻底摆脱 bisheng jdk 问题，可在宿主机上安装标准 openjdk，并让 nacos 使用它。

在麒麟 v10 上安装标准 openjdk：

# 安装开发工具包（避免安装 headless 版本）
sudo yum install -y java-1.8.0-openjdk-devel

安装后，确认版本：

java -version

输出应显示 openjdk runtime environment，无 bisheng 字样。

修改 nacos 启动脚本，强制指定 java_home：

在 startup.sh 开头添加：

export java_home=/usr/lib/jvm/java-1.8.0-openjdk-xxx

重启 nacos。

方案三：更换 nacos 服务端容器基础镜像

如果 nacos 本身也运行在容器中，可直接将 dockerfile 的 from 替换为国际公认的标准 jdk 镜像：

from eclipse-temurin:8-jre-alpine
# or
from amazoncorretto:8-alpine

重新构建并部署即可。

方案对比

方案	优点	缺点	适用场景
禁用 kae	改动极小，无需更换 jdk，生效最快	未根本解决 bisheng 的潜在其他兼容性问题	生产紧急恢复
更换为标准 jdk	根本消除加密算法兼容隐患	需要安装新 jdk 并调整环境变量	维护窗口期，计划性变更
更换容器基础镜像	完全标准化，适合容器化环境	需要重新构建、测试镜像	容器化部署且 nacos 也在容器中