服务掉线主因是健康检查失败导致实例被剔除：consul依赖server端主动http探测（需真实可用接口），nacos默认client端心跳上报（ephemeral=true），配置错位或网络/超时/鉴权问题均会触发下线。
服务掉线不是注册中心的问题，而是健康检查没过导致实例被主动剔除——先确认你的脚本是否真在探测业务可用性，而不是只查进程存活。
为什么服务在Consul/Nacos里显示“不健康”或“临时下线”
Hyperf服务启动后注册成功，但几秒或几分钟后就从控制台消失，常见原因不是网络断开，而是注册中心反复调用健康检查接口失败，最终判定实例不可用并下线。Consul默认用HTTP GET /health，Nacos则依赖客户端上报心跳+可选的自定义探针，两者行为差异大：
- Consul的健康检查由Server端主动发起，
check.http配置必须指向一个真实返回 200 的接口，且该接口需同步验证关键依赖（如数据库连通性） - Nacos的健康检查默认由Client SDK内部定时上报心跳（
ephemeral=true时），不依赖HTTP接口；但若你启用了spring.cloud.nacos.discovery.health-check-path或Hyperf中配置了health_check_path，它就会走HTTP探针，此时行为就和Consul接近 - Hyperf的
hyperf/consul扩展默认注册时会带上check.http，而hyperf/nacos默认不启用HTTP探针，除非你在services.php里显式配了health_check_path
检查Consul健康检查脚本的三个硬性条件
Consul不会执行你的Shell脚本，它只发HTTP请求或执行命令行（需在Server节点上）。Hyperf项目里所谓“健康检查脚本”，实际是指你配置在consul.php或服务注册参数里的check字段内容。常见失效点：
-
check.http地址写成http://127.0.0.1:9501/health：容器内能通，但Consul Server在宿主机或另一节点，根本访问不到。应改用服务实际监听的IP（如http://172.18.0.5:9501/health）或确保网络互通 -
check.timeout设为1s，但你的/health接口因DB连接池满或Redis超时，平均响应 1.2s —— 每次都被判失败 - 接口返回 200 但 body 是
{"status":"down"}：Consul只看状态码，不解析body，这没问题；但如果你误配成check.tcp却没开对应端口，或check.script脚本权限不对、路径不存在，就会静默失败
Nacos健康检查失效的典型配置陷阱
Nacos本身不主动探测，所以“掉线”往往源于客户端心跳中断。排查重点不在脚本，而在连接与配置一致性：
- 客户端配置的
server-addr是nacos-server:8848，但DNS未解析或/etc/hosts没配，导致心跳请求一直Connection refused，日志里可能只打印“failed to send beat” -
ephemeral=false时，实例注册为持久节点，不依赖心跳，但Hyperf默认设为true；若你手动改成false却忘了配好CP模式的Raft集群，单机Nacos会拒绝持久注册 - 命名空间
namespace_id填了名称（如dev）而非真实ID（如7f8e9d1a-1234-5678-90ab-cdef12345678），注册能成功，但心跳请求因namespace不匹配被静默丢弃 - Hyperf的
nacos.php里没配username/password，而Nacos开启了鉴权，心跳请求全部返回 403，SDK重试几次后放弃维持连接
快速验证健康检查是否生效的三步法
别等服务掉线再查，每次部署后立刻验证：
- 进Consul容器或Server节点，手动执行：
curl -v http://[服务IP]:[服务端口]/health，确认返回 200 且无超时 - 在Nacos控制台“服务管理”页找到对应服务，点击实例，看“最后心跳时间”是否在持续更新（间隔约5秒），不是固定在启动时刻
- 查Hyperf服务日志，搜关键词：
registerInstance（注册成功）、sendBeat（心跳发送）、fail to send beat（心跳失败）—— 最后一条出现即意味着即将掉线
真正容易被忽略的是：Consul的HTTP检查路径和Nacos的心跳保活是两套独立机制，混用时若同时开启，又没对齐超时与重试策略，会导致服务在两个系统里状态不一致。比如Consul已剔除，Nacos还显示健康，下游调用就会打到一个实际已不可用的实例上。
