最近被 Nacos启动成功但访问不了报 Connection refused 这个问题折磨的人应该不少。我在好几个技术群里都看到有人贴启动日志明明最后几行写着类似 Nacos started successfully 的话可浏览器一打开 http://localhost:8848/nacos 就提示连接被拒或者项目启动时注册服务报java.net.ConnectException: Connection refused: connect。今天就把我这些年排查这个问题的思路完整捋一遍从怎么判断真正的启动成功到不同部署环境下的坑再到客户端连不上的另类原因一次说清楚。1. 先泼盆冷水日志显示启动成功不等于服务真的可用1.1 你看到的成功可能只是脚本的安慰Nacos 的启动脚本startup.shWindows 下是startup.cmd在拉起 JVM 进程后就会输出 Nacos started successfully。但这行字只能说明进程被创建出来了完全不代表 Nacos 完成了初始化、把 8848 端口绑定了。我见过太多情况是进程确实在日志也没报错但端口根本没监听。所以第一步不是越想越慌而是要看对日志。logs/start.out这是启动脚本的输出一般就记录到 started successfully 为止信息量很少。logs/nacos.log这是 Nacos 应用真正的日志Spring Boot 的启动过程、数据库初始化、端口绑定、集群选举全在这里。我个人判断 Nacos 是不是真的启动完成从来不看 start.out只看 nacos.log 里有没有这一行INFO Tomcat started on port(s): 8848 (http) with context path /nacos看到这句话再确认一下 9848 端口起来了才算启动成功。1.2 Nacos 2.x 的端口关系千万别搞错Nacos 从 2.0 开始引入了 gRPC 通信端口默认是主端口加 1000。也就是说如果你用默认配置实际涉及的端口有三个端口用途说明8848主 HTTP 端口控制台页面、HTTP API9848gRPC 客户端通信端口2.x 客户端注册、配置订阅走这里9849gRPC 服务端通信端口集群节点间通信这是一个极其隐蔽的坑很多人只放行了 8848打开控制台页面一切正常但服务注册就是失败日志里报Connection refused: connect索性连错都没报对端口。而且很多 Connection refused 根本不是连 8848 被拒是连 9848 被拒。排查时ss、netstat查看端口监听时8848 和 9848 都要看。ss -lntp | grep -E 8848|9848如果 8848 有监听、9848 没有说明 Nacos 2.x 的 gRPC 部分没有正常起来大概率是启动中途出问题但进程没退出。这种情况最典型的诱因是内嵌 Derby 数据源异常或者cluster.conf配置有误。2. Connection refused 的四种典型成因你大概率栽在第二种2.1 成因一端口根本没有被监听这是最基础的一种但也很常见。Nacos 进程可能因为内存分配不足、JDK 版本不兼容、数据库连接失败等原因启动到一半悄悄退出或者卡在某个初始化阶段。判断方法非常简单ps -ef | grep nacos ss -lntp | grep 8848如果进程还在但 8848 没监听就直接看logs/nacos.log最后 100 行的报错。常见错误包括java.lang.OutOfMemoryError启动脚本默认的 JVM 参数太大小内存机器尤其是 1G 以下的云服务器很容易中招解决办法是调小JVM_XMS、JVM_XMX、JVM_XMN。Derby 数据库文件损坏之前用 CtrlC 强杀过 Nacos内嵌 Derby 很容易起不来。删掉data目录重新启动通常能解决但数据会丢所以生产环境一定要用外置 MySQL。端口被占用8848 被别的程序占了Nacos 启动时虽然报错但脚本可能没捕获到。2.2 成因二网络层把连接拦了最常见这是我遇到过最多的情况。服务端确实起来了8848 和 9848 都在监听但你就是访问不了。原因不外乎三个服务器防火墙拦了入站连接云平台安全组没有放行对应端口容器环境端口映射漏配或者配错把这个类比成开店就容易理解了Nacos 是店铺服务已经营业了但小区大门防火墙锁着客户根本进不来。很多人在服务端折腾半天其实问题出在网络中间层。2.3 成因三客户端连错了地址/端口还有一种情况是服务端一切都好但客户端配置的server-addr有问题。最常见的有服务端监听的是0.0.0.0:8848但客户端从注册中心拿到的NACOS_SERVER_IP是内网 IP、容器 IP 或者127.0.0.1自然连不上。客户端配置了http://前缀Nacos 的server-addr不用加协议头直接写ip:port。各种原因导致的端口混淆比如服务端改了主端口但忘了确认 gRPC 偏移端口是否可用。2.4 成因四启动阶段配置问题导致的假成功Nacos 的启动脚本为了在纯命令行下也能友好输出把很多错误吞掉了进程在日志也写了几行然后就没下文了。我印象最深的一次是集群模式配置错误cluster.conf里写了一个不可达的节点地址Nacos 一直尝试建集群连接8848 端口迟迟不监听但进程看起来是活着的。成因典型现象快速定位方式端口未监听本机 curl 127.0.0.1:8848 也失败ss -lntp | grep 8848网络层拦截本机通、外部不通检查防火墙和安全组客户端配错服务端正常但应用报错看客户端日志里实际连接的 IP:端口配置假成功进程在但端口未监听看 nacos.log 初始化段3. 一套可复制的排错链路从本机 curl 到跨容器验证3.1 第一层本机验证服务端是否真的健康在任何花里胡哨的排查之前先在 Nacos 所在机器上直接验证curl http://127.0.0.1:8848/nacos/能够正常返回 HTTP 200才说明服务端本身是健康的。接下来再看健康检查接口curl http://127.0.0.1:8848/nacos/v1/console/health/readiness如果这个接口返回的 JSON 里UP状态没问题说明 Nacos 已经「真正启动成功」。此时可以从进程、端口、健康接口三个层面确定服务端状态。3.2 第二层从容器内和宿主机分别验证如果你用的是 Docker 或者 Kubernetes 部署问题可能出在映射而不是 Nacos 本身。Ex啊我见过太多人直接在外面 curl 失败就开始改 Nacos 配置结果折腾半天发现容器端口没映射出来。先进入容器内部验证docker exec -it container-id bash curl http://127.0.0.1:8848/nacos/容器内通、宿主机不通说明端口映射有问题。docker ps --format table {{.Names}}\t{{.Ports}}如果宿主机直接部署本机通、外部机器不通则重点检查防火墙。3.3 第三层跨机器验证网络是否通在另一台机器上先用端口工具验证 TCP 层是否可连telnet nacos-ip 8848或者用 bash 自带的/dev/tcptimeout 3 bash -c echo /dev/tcp/nacos-ip/8848 echo port openTCP 层通不了后面一切免谈。这一步能直接区分是服务端问题还是网络中间层问题。3.4 第四层防火墙和安全组核查如果跨机器 TCP 不通接下来就看网络策略。Linux 服务器上我一般按顺序查这几个systemctl status firewalld firewall-cmd --list-ports iptables -L -n | grep 8848云服务器的话还要去云控制台看安全组有没有放行 8848 和 9848。Rancher 或 Kubernetes 环境则要额外确认 Service 和 NodePort 的映射关系。我用一个简单的判断逻辑来引导排查浏览器/客户端访问失败 → 先本机 curl → 本机失败查 Nacos 自身本机成功则检查容器映射 → 容器映射正常则检查防火墙/安全组 → 防火墙放行则检查客户端配置。4. 部署环境决定排错方向Windows、Linux、Docker、Rancher 各有各的坑4.1 Windows启动脚本和黑窗口的坑Windows 上最容易犯的错是直接双击startup.cmd黑窗口弹出来然后不小心关掉Nacos 就没了。而且 Windows 下如果当前目录不对脚本可能找不到配置文件和日志目录。我建议在 Windows 上这样启动cd nacos/bin cmd /c startup.cmd -m standalone然后别关那个窗口盯着它输出。如果没有输出监听端口就看logs/nacos.log。另外 Windows 下防火墙弹窗要选允许访问不然本机浏览器能开、局域网其他机器访问不了。4.2 Linux 直接部署内存参数和防火墙Linux 下用startup.sh -m standalone启动是最常见的姿势。小内存服务器跑不起来十有八九是 JVM 参数问题。启动前先改bin/startup.sh里的内存配置export JVM_XMS256m export JVM_XMX256m export JVM_XMN128m还有一点很多人忽略如果你改了 Nacos 的application.properties里的端口启动脚本支持的-D参数和配置文件之间可能会有覆盖关系最好确认你改的文件路径是conf/application.properties而不是conf/application.properties.example。4.3 Docker 部署端口映射和容器 IPDocker 跑 Nacos 是非常常见的部署方式但也是 Connection refused 高发区。一个最容易被忽略的问题是8848 和 9848 必须都映射出来。我自己常用的启动命令docker run -d \ --name nacos \ -p 8848:8848 \ -p 9848:9848 \ -p 9849:9849 \ -e MODEstandalone \ -e NACOS_SERVER_IP192.168.1.100 \ nacos/nacos-server:v2.2.3NACOS_SERVER_IP这个环境变量特别关键。如果不设置容器可能拿到自己的容器 IP客户端从服务端拿到的地址就是172.17.0.x这种外部肯定连接不上。设置成宿主机 IP 后客户端才能通过宿主机 IP 回连。4.4 Rancher 和 Kubernetes 部署外部访问的最后一公里用 Rancher 部署 Nacos 的场景我收到过很多求助问题集中在集群里能访问外部访问不了。Rancher 里部署的 Nacos 如果做成了 Workload需要把 Service 类型选对只在集群内访问用 ClusterIP需要通过节点 IP 访问用 NodePort 并放行节点端口需要通过域名访问用 Ingress 配置但要注意后端 Service 的 targetPortRancher 部署下最容易踩的坑是跨节点访问。如果你的 Nacos 副本被调度到了多个节点客户端拿到的节点地址可能是 Pod IP 或者错误的 Node IP结果从外部访问的时候就出现了部分节点通、部分节点连不上的诡异现象。稳妥的做法是给 StatefulSet 或 Deployment 设置NACOS_SERVER_IP为固定的宿主机 IP并且用单副本 宿主机网络或 NodePort 暴露给外部使用。5. 客户端视角应用连不上 Nacos 时的另类排查路径5.1 Spring Cloud 项目最常见的配置未导入问题如果你用的是 Spring Cloud Alibaba应用启动报Connection refused除了网络问题还要注意一个非常经典的新版本变更Spring Boot 2.4 之后bootstrap上下文默认不再启用了。很多人升级依赖之后Nacos 配置中心的配置死活加载不进来日志里还会出现No spring.config.import property has been defined这个时候有两种解法第一种引入spring-cloud-starter-bootstrap依赖恢复 bootstrap 机制dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-starter-bootstrap/artifactId /dependency第二种在application.yml里加spring.config.import显式导入 Nacos 配置spring: application: name: demo-service config: import: nacos:demo-service.yaml cloud: nacos: server-addr: 127.0.0.1:8848 config: file-extension: yaml这个问题看着像是 Connection refused很多时候其实是配置加载失败后连接池没有正确初始化最后暴露成了连接异常。5.2 命名空间和鉴权被拒的不只是连接Nacos 开启鉴权或者配置了命名空间之后客户端如果没配对反馈也可能表现为连接失败或拒绝。常见的情况有客户端没填namespace默认走 public服务端配置在别的命名空间。开启了鉴权后客户端没带username/password或者密码错误。使用了 Nacos 2.2.1 之前的默认密钥服务端开启鉴权后认为客户端是非法请求。尤其是现在很多安全扫描工具会报 Nacosnamespaces未授权访问漏洞随着 Nacos 2.2.1 起官方推动默认打开鉴权很多人在升级之后就发现原来能连的现在连不上了。这种情况下的 Connection refused服务端网络完全正常问题出在认证握手被拒。5.3 客户端日志怎么定位真正的 IP:端口当客户端报Connection refused的时候一定不要只看 Connection refused 这几个字要把完整的异常堆栈打出来重点看它到底连的是哪个 IP 和端口。我遇到的一个典型案例Caused by: java.net.ConnectException: Connection refused: connect at java.base/sun.nio.ch.NioSocketImpl.connect(NioSocketImpl.java:120) ...堆栈里没有端口号但更早的日志一定有一行写着类似[Nacos Client] Try to connect to server: 192.168.0.15:9848如果连接目标是9848那就要检查 gRPC 端口放行如果是其他陌生的 IP那基本可以确定是NACOS_SERVER_IP配置错了。5.4 客户端版本与服务端版本不匹配Nacos 1.x 的客户端连接 2.x 的服务端一般没什么大问题但反过来或者跨版本较大时可能出现注册成功但心跳异常、配置订阅失效等问题。2.x 客户端默认走 gRPC如果服务端是 1.x 只开放了 8848客户端会回退到 HTTP 长轮询但如果服务端配置禁止了 HTTP 通信就会连不上。我建议能锁版本就锁版本客户端尽量与 Nacos 服务端同大版本。6. 针对Connection refused的兜底经验这几条经验是我踩了无数次坑之后沉淀下来的分享出来给你们省点时间。判断启动成功的黄金标准就三条ss -lntp | grep -E 8848|9848两个端口都监听2.x 必须两个都有1.x 看 8848 即可。健康检查接口返回 HTTP 200内容显示UP。浏览器能打开/nacos控制台页面本机至少能打开跨机器访问取决于网络策略。生产环境部署 Nacos 的建议不要用latest标签明确固定版本我常用v2.2.3或v2.3.x避免社区版迭代带来的配置兼容问题。使用外置 MySQL不要用内嵌 Derby。Derby 适合单机体验生产环境一旦重启或异常退出数据文件损坏的概率很高。显式配置NACOS_SERVER_IP或修改application.properties中的 IP 绑定不要依赖自动探测。开启鉴权并修改默认密钥。Nacos 社区很多未授权访问漏洞都和默认配置有关现在安全基线要求也高了早改早安心。关于 Nacos 的端口速查表再贴一次建议收藏端口用途排查重点8848HTTP API、控制台防火墙、端口冲突、Tomcat 启动9848gRPC 客户端通信端口映射漏配、客户端连接目标9849gRPC 服务集群通信集群节点地址、跨节点通信最后再分享一个小技巧遇到 Connection refused 不要慌先分清是服务端没起来、网络不通、还是客户端配置不对。用先本机再跨机、先端口再防火墙、先网络再配置的顺序排查90% 的问题都能在五步内定位。剩下 10%大概率是版本或者环境变量的问题按上面列的方向逐个排除就行。
