connection refused说明tcp连接建立失败，根本原因是目标地址端口无监听进程或被拦截；需依次验证心跳配置、手动模拟连接、检查服务监听状态（ss -tuln）、排查防火墙/安全组及协议路径错配。
心跳检测报 Connection Refused，说明心跳请求在 TCP 连接建立阶段就被拒绝了——不是心跳包发出去没回，而是压根连不上目标地址和端口。这和业务逻辑、超时设置、重连策略都无关，问题一定出在“网络可达性”或“服务监听状态”上。
确认心跳目标是否真实可连
心跳通常是客户端（如前端 WebSocket、Redisson、Hyperf 连接池）定期向某个地址+端口发一个轻量探测（比如 HTTP GET /health、TCP ping、Redis PING）。先搞清它到底想连谁：
- 查代码或配置：看心跳 URL 或 host:port 是什么，比如
http://localhost:8080/health、redis://127.0.0.1:6379、ws://192.168.1.100:9001 - 手动模拟一次：用
curl -v http://localhost:8080/health或telnet 127.0.0.1 6379测试。如果也报Connection refused，就坐实是目标不可达 - 特别注意 Docker/容器场景：宿主机 localhost 不等于容器内 localhost；检查
docker port <container></container>，确认端口映射是否正确（例如容器内 6379 映射到宿主机 6380，但心跳却连了 6379）
验证目标服务是否真正在监听
服务“启动了”不等于“监听了”。常见陷阱包括绑定地址错误、端口冲突、静默启动失败：
- 执行
ss -tuln | grep :端口号（Linux/macOS），看输出中 Listen 地址是不是0.0.0.0:端口或具体 IP；若只显示127.0.0.1:端口，则外部（包括同机其他容器或进程）无法访问 - 用
ps -p $(lsof -ti:端口号) -o pid,comm,args（macOS）或netstat -tulnp | grep :端口（Linux）确认该端口对应的 PID 确实是你的心跳目标服务，而非残留旧进程 - 检查服务日志：是否有绑定失败提示？比如 Node.js 报
Error: listen EADDRINUSE，或 Spring Boot 启动后没打印Tomcat started on port(s): 8080
排查中间链路拦截
即使服务在监听，也可能被系统级策略提前拦下：
- 防火墙：CentOS/RedHat 执行
sudo firewall-cmd --list-ports，确认目标端口已放行；Ubuntu 检查ufw status - SELinux（仅限部分 Linux 发行版）：运行
getenforce，若为Enforcing，临时设为Permissive测试是否恢复：sudo setenforce 0 - 云服务器安全组：阿里云、腾讯云等控制台里，检查入方向规则是否开放对应端口（注意协议是 TCP 还是 UDP）
- 本地杀毒软件或代理工具：某些 Windows 安全软件会拦截本地 loopback 连接，临时关闭试试
检查心跳配置是否错配协议或路径
看似连的是对的地址，实际因协议或路径不匹配被内核拒连：
- Redis 心跳连的是
redis://，但你配成了http://或tcp://—— 协议错配会导致连接直接被拒绝 - Nginx 代理 WebSocket 时，心跳请求本该走
proxy_pass http://backend，但 backend 实际监听 Unix socket，而你写成http://127.0.0.1:8080，导致协议不匹配 - HTTP 健康检查路径写错：后端只暴露
/actuator/health，但心跳请求的是/health，404 不会报 Connection Refused，但若反向代理配置了错误 upstream，可能触发 upstream 连接拒绝
