一、问题出现
最近在本地搭建一个基于 Dubbo 3.3 + Nacos 2.4.3 的项目，Nacos 跑在 Docker 里，项目以 jar 包方式跑在宿主机上。启动后遇到报错：
Failed to create nacos config service client. Reason: server status check failed.
Server status: UP. Config Service Available: false.
重试 11 次后直接抛异常退出，项目起不来。最诡异的是——同事机器上的 Nacos 能连上，我自己 Docker 里的就是不行。
二、问题原因
最终定位出两个原因，一个在部署层面，一个在 Dubbo 底层。
2.1 端口映射不全（部署问题）
Nacos 2.x 除了 HTTP 端口 8848，还需要两个 gRPC 端口：
| 端口 | 偏移量 | 用途 |
|---|---|---|
| 8848 | 主端口 | HTTP API、健康探活 |
| 9848 | +1000 | 客户端 gRPC（Dubbo 实际连这个） |
| 9849 | +1001 | 集群 gRPC（服务端间通信） |
只映射 8848 的结果：HTTP 探活能过（Server status: UP），但 Dubbo 做 gRPC 健康检查时连不上 9848，报 Config Service Available: false。三个端口必须全部映射。
2.2 Dubbo 3.3 内置的 ConfigService 连接不兼容 Nacos 认证（根本原因）
补全端口后，如果 Nacos 开启了认证，Dubbo 侧依然报同样的错误。关键发现：Nacos 的认证功能本身没有问题——控制台登录、Token 签发均正常。问题出在 Dubbo 3.3 的底层实现。
经逐一排查，Dubbo 3.3 中有两处会独立创建 Nacos ConfigService 去做健康检查，且都不传递认证凭证：
| 模块 | 触发方式 | 能否通过配置阻止 |
|---|---|---|
NacosDynamicConfiguration（Config Center） |
发现 classpath 上有 Nacos 即自动创建 | 可以，config-center: address: empty://localhost |
NacosMetadataReport（Metadata Report） |
SPI 自动加载，位于 dubbo-3.3.0.jar 核心包内 |
无法阻止——不用 Maven 排除、不用 enabled: false、不用 URL 传参 |
第二处是死结：NacosMetadataReport 的构造函数里会创建 ConfigService 做健康检查，这个请求不带任何认证凭证。只要 Nacos 开了认证，它就会报 Server status: UP. Config Service Available: false 并阻塞启动。
因此目前的结论是：Dubbo 3.3 的 Metadata Report 模块不支持在 Nacos 开启认证的环境下工作。这个问题并非 Nacos 或项目配置的锅，而是 Dubbo 3.3 的局限性。
三、最终方案
3.1 Nacos 侧：关认证
nacos.core.auth.enabled=false
3.2 Conductor 侧：精简 Dubbo 配置
虽然 Metadata Report 无法通过配置阻止，但 Config Center 可以主动禁掉，减少不必要的连接开销：
dubbo:
application:
metadata-type: local
registry:
address: nacos://127.0.0.1:8848
use-as-config-center: false
config-center:
address: empty://localhost
3.3 Nacos 完整配置 + 启动命令
本次项目选择用 Docker 里的 MySQL 做 Nacos 持久化。完整 application.properties：
server.servlet.contextPath=/nacos
server.port=8848
spring.datasource.platform=mysql
db.num=1
db.url.0=jdbc:mysql://mysql:3306/nacos_config?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true&useUnicode=true&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true
db.user.0=root
db.password.0=123456
nacos.core.auth.enabled=false
nacos.console.ui.enabled=true
启动 Nacos（注意用 Docker 网络直连 MySQL，避免 host.docker.internal 连到宿主机上另一个 MySQL 实例）：
# 创建网络，把 MySQL 加进去
docker network create nacos-net
docker network connect nacos-net mysql
# 启动 Nacos（三个端口都要映射）
docker run -d --name nacos --network nacos-net \
-p 8848:8848 -p 9848:9848 -p 9849:9849 \
-e MODE=standalone -e PREFER_HOST_MODE=hostname \
-v "本地路径\application.properties:/home/nacos/conf/application.properties:ro" \
-v "本地路径\logs:/home/nacos/logs" \
nacos/nacos-server:v2.4.3
3.4 初始化 MySQL Schema（使用外部 MySQL 时需要）
从 Nacos 的 release zip 包中取 conf/mysql-schema.sql，建库导入：
# 1. 建库
docker exec -i mysql mysql -uroot -p123456 -e ^
"CREATE DATABASE IF NOT EXISTS nacos_config DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_unicode_ci"
# 2. 导入 schema（PowerShell 下用 cmd /c 避免编码问题）
cmd /c "type C:\Users\Administrator\Desktop\nacos\conf\mysql-schema.sql | docker exec -i mysql mysql -uroot -p123456 nacos_config"
四、总结
- 根因一：Docker 部署 Nacos 2.x 忘映射 gRPC 端口 9848/9849
- 根因二：Dubbo 3.3 的
NacosMetadataReport在 Nacos 开启认证时无法完成内部健康检查，这是 Dubbo 3.3 的底层限制，配置层面无解，当前只能通过关闭 Nacos 认证规避
排查这类问题的心得：
- 先做减法——先把认证、加密、外部存储全部关掉，让最简单的环境跑通，再逐个加回来
- curl 直接测 API——别只看 HTTP 探活，用
curl -X POST /nacos/v1/cs/configs确认 Config Service 能正常读写 - 区分服务端问题和客户端问题——Nacos 控制台能登录、Token 能发，说明服务端没问题，锅在 Dubbo
