最典型假成功是客户端日志显示“发送成功”但心跳未达服务端，常见于grpc连接未建立或断开却未被感知；需检查9848端口连通性、grpc状态、clientbeatinterval一致性及服务端健康检查配置。
心跳没发到服务端，但客户端日志显示“发送成功”
这是最典型的假成功现象。客户端 BeatReactor 的定时任务看似在跑，也打印了“send beat to server”，但实际请求根本没抵达服务端——常见于 gRPC 连接未建立或已断开却未被感知。
检查点包括：
- 确认客户端是否连上了正确的 gRPC 端口：
9848（不是8848），K8s 场景下必须在 Service 中显式暴露该端口，否则 DNS 解析到 IP 后连接会被拒绝 - 抓包验证：在客户端容器内执行
telnet nacos-server 9848，不通就说明网络层阻断，和心跳逻辑无关 - 查客户端 SDK 日志关键词：
grpc channel is not ready、connection refused、UNAVAILABLE，这些比“send beat”日志更可信 - 临时实例注册时，Nacos 服务端会返回一个
clientBeatInterval值，客户端应据此修正自己的心跳周期；若客户端忽略该值硬写死 5 秒，而服务端实际下发的是 30 秒，就会因超时被标记不健康
服务端收到了心跳，但实例仍被标记为 UNHEALTHY
收到心跳 ≠ 实例健康。Nacos 服务端的 handleBeat 方法除了更新最后心跳时间，还会校验实例元数据一致性、同步状态到 Distro 协议层。一旦某次心跳携带的 instanceId 或 service name 与注册时不符，服务端会拒绝更新，并维持旧状态甚至触发降级逻辑。
高频诱因有：
- 客户端重启后未清理本地缓存，用旧的
instanceId重发心跳（尤其在 K8s Pod 重建、IP 变更时） - 服务名大小写混用，比如注册用
stock-service，心跳却发向Stock-Service，Nacos 默认区分大小写 - 服务端集群节点间 Distro 同步延迟或失败，导致部分节点看到心跳，部分节点没同步到，最终以多数节点为准判定不健康
- 服务端 GC 时间过长（>15 秒），心跳请求虽到达，但处理线程卡在 STW 阶段，未能及时更新内存中的最后心跳时间戳
控制台看到 UNHEALTHY，但实例没被剔除，等了超过 30 秒
这说明“两段式剔除”机制正在起作用：第一阶段（15 秒无心跳 → 标记不健康）已触发，第二阶段（硬过期 → 彻底删除）尚未执行。这不是故障，是设计行为。
但如果你发现它卡在 UNHEALTHY 状态很久不动，就要盯两个地方：
-
ExpiredInstanceCleaner定时任务是否在运行？查服务端日志是否有clean expired instances周期性输出；若没有，可能是 JVM 参数禁用了该任务，或配置项nacos.naming.clean.expired.metadata.enabled=false - 实例是否被设为永久节点？
ephemeral=false的实例完全不走心跳剔除流程，它的健康检查由服务端主动发起 TCP 探活，且不会被自动删除 - 服务端是否启用了保护阈值（
protectThreshold）？当健康实例比例低于该阈值时，Nacos 会暂停剔除动作，防止雪崩；此时所有不健康实例都会卡在 UNHEALTHY 状态
为什么改了客户端心跳间隔，服务端还是按 15 秒判不健康
因为服务端判定不健康的阈值（defaultHealthCheckTimeOut）是独立配置的，和客户端发心跳的频率无关。它只看“最后一次有效心跳距今是否超过该阈值”。
这个值默认是 15 秒，可通过以下方式调整：
- 启动参数：
-Dnacos.naming.health.check.time.out=30000 - JVM 系统属性：
nacos.naming.health.check.time.out - 注意：该配置只影响“标记不健康”的时机，不影响“最终剔除”的硬过期时间（默认约 30 秒），后者由
nacos.naming.clean.expired.metadata.interval和内部逻辑共同决定
真正要让心跳机制适配你的业务节奏，得两端对齐：客户端按服务端下发的 clientBeatInterval 发，服务端按你预期的容忍窗口调 health.check.time.out。漏掉任何一环，都会出现“我明明在发，你怎么说我不健康”的错觉。
