控制台能看到服务，启动日志却持续报注册失败，两种观察并不必然矛盾。要同时看客户端的具体请求、实例健康与配置生效情况，不能只凭控制台有一行数据就认定全部注册流程正常。

第一次：Discovery版本调整后错误消失

2019年一个简单网关项目启动时出现：

failed to req API: /nacos/v1/ns/instance
after all servers ([127.0.0.1:8848]) tried

当时堆栈记录的组合是：

项目历史版本
Spring Boot2.0.9.RELEASE
Nacos Discovery组件0.2.0.RELEASE
nacos-client0.3.0

控制台似乎已经出现实例，应用也打印了启动完成，最初我便没有继续追究。后来检查本机Nacos客户端日志，发现NamingProxy请求同一实例接口时出现 NacosException: null。

我在上游讨论线索中找到版本相关建议，把discovery starter从0.2.0.RELEASE改为0.2.1.RELEASE，之后这条启动错误消失。对应issue和服务端响应没有完整保留，因此只能记录“调整后恢复”的观察，不能认证所有同类异常都由这个版本引起。

消息为null，不等于NullPointerException

NacosException: null 表示异常显示的消息为空，不是Java异常类型已经变成NullPointerException。继续看原因链、客户端文件日志与服务端同一时段记录，才能区分网络、响应、配置和兼容问题。

同时核对服务端地址、命名空间、分组、实例IP/端口和健康状态。实例可能短暂出现、后续请求失败或留有旧状态，不能只凭一次截图判断。

第二次：需要发现服务，却引入了Config

2019年10月的另一项目在初始化配置源时报：

create config service error!
NacosConfigProperties{serverAddr='null', ...}
com.alibaba.nacos.api.exception.NacosException: null

该记录涉及Boot 2.1.4、Nacos Config 0.2.1和Nacos API 1.0.0。它不是上面的实例注册错误：调用路径在创建Config服务、加载配置源，且serverAddr没有得到有效值。

当时没有配置中心需求，移除config starter、保留discovery后恢复。若应用确实需要Config，则应修复对应配置加载，不能为消除报错一律删依赖。

按职责查依赖和地址

Discovery与Config是两项独立接入。历史参考文档分别说明 spring.cloud.nacos.discovery.server-addr 与 spring.cloud.nacos.config.server-addr；其中配置应放在哪个加载阶段，还需按对应版本确认，不能从发现地址已设置推断配置中心也已配置。Spring Cloud Alibaba历史参考

处理顺序是固定Boot/Cloud/Alibaba/客户端/服务端版本，查看实际依赖树与有效配置，再针对异常所属功能做最小变更。旧版本号是案例背景，不是当前项目的依赖推荐；最终还要分别验证注册、发现和实际请求，而非仅看应用Started。