SpringBoot连接Nacos报错No Such Algorithm: HmacSHA256的排查与解决
作者：Sailor_Infra
问题现象
在将 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 版本
登录 Nacos 服务所在宿主机（livp-cou06），执行：
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 也在容器中 |
经验总结
报错定位要准确：客户端日志中的异常信息可能是服务端抛回的错误，务必结合 HTTP 状态码和响应体判断真正的故障点。
BiSheng JDK 并非通用 OpenJDK：其 KAE 加速特性依赖特定硬件和驱动，在不满足条件的 x86 环境中可能引发加密算法缺失问题。
麒麟 V10 系统的 JDK 选择：系统源可能默认提供 BiSheng 版本，安装时需明确指定 -devel 包或手动下载标准版。
HmacSHA256 算法不可用的常见原因：
- 精简版 JDK（如 Alpine 镜像自带的）裁剪了加密组件；
- 厂商定制 JDK 的安全提供者配置异常；
- 系统安全策略文件（
java.security）被修改，移除了SunJCEProvider。
到此这篇关于SpringBoot连接Nacos报错No Such Algorithm: HmacSHA256的排查与解决的文章就介绍到这了,更多相关SpringBoot连接Nacos报错内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！