最典型假成功是客户端日志显示“发送成功”但心跳未达服务端，常见于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。漏掉任何一环，都会出现“我明明在发，你怎么说我不健康”的错觉。