服务注册不上了你敲了 5 个命令排查第 3 个就找到了8 个高频问题的一键排查路径排查问题的前 30 秒决定了你要花 30 分钟还是 3 小时某个核心服务突然不可达。你的第一反应是什么“应该是网络问题。”——过了 10 分钟不是。“是不是注册中心挂了”——又过了 5 分钟8848 端口好好的。“Nacos 日志里有异常吗”——grep 了半天没找到。30 分钟过去了。还没有定位到问题。最后发现是客户端版本和 Nacos 服务端版本不兼容——客户端 1.4.2 连了 2.3.0 的服务端HTTP 请求头格式不对注册请求被静默丢弃了。排查问题的速度不取决于你知道多少而取决于你的排查顺序。这篇文章把 Nacos 生产中最常见的 8 个问题按排查顺序排列——从概率最高的开始逐一给出一键排查命令。你不需要记住所有命令只需要按这个顺序走。⚠️ 本文基于 Nacos 2.3.x 排查经验。排查命令兼容 Nacos 2.0.0部分指标名称在 1.x 版本中不同。客户端版本问题问题一在 1.x→2.x 迁移场景中出现频率最高。排查速查表8 个问题 × 5 个命令一票否决一票否决一票否决高频高频中频中频低频但致命服务出问题了问题一版本不兼容问题二认证失败问题三端口不通问题四心跳超时问题五实例被剔除问题六配置推送延迟问题七MySql连接池耗尽问题八JVM GC 导致无响应curl /nacos/v1/console/server/state检查客户端日志 token 行telnet 8848 telnet 9848查看 nacos_monitor 指标控制台→服务详情→实例列表grep push nacos.logSHOW PROCESSLIST 连接数jstat -gc GC 日志按 8.1 → 8.8 顺序排查。前三个是一票否决级——任何一个都能在 30 秒内被排除或确认。问题一客户端版本和服务端不兼容概率1.x→2.x 迁移场景下最高发现象服务注册成功但其他服务发现不到。或者直接注册失败客户端日志报Request error: 400。根因Nacos 1.x 使用 HTTP 协议端口 8848Nacos 2.x 默认使用 gRPC端口 9848。如果客户端是 1.x它只往 8848 发请求不走 9848 的 gRPC 通道。服务端 2.x 收到 1.x 客户端的请求后会做一个兼容处理——但部分元数据字段会丢失导致服务发现不生效。一键排查# 1. 确认服务端版本curl-shttp://nacos:8848/nacos/v1/console/server/state|jq.# 输出示例# {# version: 2.3.0,# standalone_mode: cluster,# function_mode: null# }# 2. 确认客户端版本# 查看客户端 Maven/Gradle 依赖中的 nacos-client 版本# 或看客户端日志里启动时打印的版本号grepnacosapplication.log|grepversion版本兼容矩阵服务端兼容的客户端不兼容的客户端2.3.x2.0.01.4.x 及以下功能受限2.0.x - 2.2.x2.0.01.x部分降级兼容但推送不生效1.4.x1.x2.x功能受限解决客户端升级到 nacos-client 2.0.0。如果客户端暂时无法升级服务端加参数开启 1.x 兼容模式# nacos/conf/application.properties # 开启 1.x 客户端 HTTP 兼容2.3.x 后默认关闭 nacos.core.support.upgrade.from.1xtrue问题二认证失败但日志不明显概率现象调用 Nacos API 返回 403日志里只有一行unknown user。根因Nacos 2.x 认证开启后客户端需要在spring.cloud.nacos.discovery.username和password里配置正确的凭证。如果用了默认密码nacos/nacos但服务端改过客户端注册静默失败。一键排查# 1. 直接在 Nacos 服务器上用默认密码试一次curl-XPOSThttp://nacos:8848/nacos/v1/auth/login\-dusernamenacospasswordnacos# 期望返回 accessToken# 2. 如果上一步失败确认服务端的实际密码# 连 MySQL → SELECT username FROM users;# 或检查服务端 auth.loggreplogin/home/nacos/logs/nacos/auth.log|tail-5# 3. 确认客户端的配置# Spring Cloud Alibaba 项目检查 bootstrap.yml 或 application.yml:# spring.cloud.nacos.discovery.username# spring.cloud.nacos.discovery.password问题三8848 通了但 9848 没通概率现象Nacos 控制台能打开但服务注册失败。客户端日志报Connection refused或UNAVAILABLE。根因Nacos 2.x 多了一个 gRPC 端口 9848。很多运维在防火墙规则里只放了 8848没放 9848。gRPC 连接不上时客户端会尝试降级到 HTTP但服务发现和配置推送的实时性会丢失。一键排查# 在客户端机器上测两个端口telnet nacos-server-ip8848telnet nacos-server-ip9848# 或者用 ncnc-zvnacos-server-ip8848nc-zvnacos-server-ip9848# 在 Nacos 服务端确认 gRPC 端口是否监听netstat-tlnp|grep9848# 应该有tcp6 0 0 :::9848 :::* LISTEN java进程Nacos 2.x 需要开放的端口完整列表端口协议作用是否必须8848HTTP控制台 配置管理 API✅ 必须9848gRPC服务发现 配置推送实时✅ 必须9849gRPC集群内部 Raft 通信✅ 集群模式必须7848TCPJraft 选举通信集群模式必须问题四心跳超时实例在健康和不健康之间反复横跳概率现象控制台里实例状态来回跳——健康 → 不健康 → 健康 → 不健康。根因排序客户端 GC 停顿超过心跳间隔。默认心跳间隔 5 秒如果客户端 Full GC 超过 5 秒这一轮心跳就丢了。服务端在 15 秒3 个心跳周期后把该实例标记为不健康。服务端 GC 停顿。服务端 Full GC 期间无法处理心跳请求。等 GC 结束后积压的心跳请求同时到达服务端处理不过来。网络抖动。机房之间偶尔丢包。一键排查# 1. 检查客户端 GC 情况jstat-gcclient_pid100010# 2. 检查 Nacos 服务端心跳处理延迟curl-shttp://nacos:8848/nacos/actuator/prometheus|grepnacos_monitor# 关注指标# nacos_monitor{namehealthCheck} - 健康检查处理数# nacos_monitor{namepushCost} - 推送耗时# 3. 调整心跳超时时间如果确认是网络延迟导致# 客户端配置spring.cloud.nacos.discovery.heart-beat-interval10000# 心跳间隔调到 10sspring.cloud.nacos.discovery.heart-beat-timeout30000# 超时 30sspring.cloud.nacos.discovery.ip-delete-timeout45000# 45s 后才剔除问题五实例被无故踢出概率现象服务列表里少了几台机器。重启客户端后自动注册回来了。根因只有三种客户端主动注销。应用优雅关闭时调的namingService.deregisterInstance()——这不是 bug。主动健康检查失败。你配了 HTTP 健康检查但/health端点返回的不是 200。被动健康检查超时。心跳丢了 15 秒默认服务端自动剔除。一键排查# 1. 确认不是客户端主动注销grepderegister/var/log/app/application.log# 2. 确认健康检查配置# 控制台 → 服务详情 → 编辑 → 查看健康检查方式# 如果是 HTTP确认你的 /health 端点能否正常访问curl-shttp://instance-ip:port/health# 如果是 TCP检查端口是否能在 500ms 内建立连接# 3. 看心跳日志grepsend beat/var/log/app/application.log|tail-20问题六配置改了但没推到客户端概率现象在控制台上改了一个配置点了发布。有的实例获取了新配置有的还是老的。根因客户端版本推送机制故障点1.xHTTP Long Polling30s 挂起网络超时后重新发起轮询有延迟2.xgRPC 双向流gRPC 连接断开后会重连重连期间漏掉推送一键排查# 1. 确认配置变更是否被记录grepdataIdyour-data-id/home/nacos/logs/nacos/config.log|tail-5# 2. 在 Nacos 服务端看推送情况# 控制台 → 配置管理 → 监听查询 → 输入 dataId# 可以看到有多少实例正在监听这个配置# 3. 在客户端机器上看是否收到推送greprefresh/var/log/app/application.log|tail-10# 4. 如果客户端是 1.x检查 Long Polling 超时配置# 服务端nacos.config.longPollTimeout30000# 单位毫秒默认 30000问题七MySQL 连接池耗尽Nacos 卡死概率现象Nacos 控制台能打开但任何操作都超时。日志里频繁出现HikariPool - Connection is not available。根因Nacos 集群每个节点默认最大数据库连接数 20。3 节点集群就是 60 个连接。如果 MySQL 配了低连接数上限或者有慢查询积压连接池很快打满。一键排查# 1. MySQL 侧查看当前连接数mysqlSHOW PROCESSLIST;mysqlSHOW VARIABLES LIKEmax_connections;# 2. Nacos 侧查看连接池状态curl-shttp://nacos:8848/nacos/actuator/prometheus|grephikaricp# 关注 hikaricp_connections_active 和 hikaricp_connections_pending# 3. Nacos 日志里找连接池超时grepConnection is not available/home/nacos/logs/nacos.log|wc-l处理# nacos/conf/application.properties db.pool.config.maximumPoolSize20 # 每个节点最大连接数 db.pool.config.connectionTimeout3000 # 获取连接超时毫秒 db.pool.config.idleTimeout600000 # 空闲连接最大存活时间毫秒如果频繁打满先看 MySQL 是不是有慢查询再考虑加到 30。问题八JVM Full GC 导致服务端假死概率低频但致命现象Nacos 进程还在端口能通但所有请求超时。控制台页面转圈。没有明显错误日志。根因进了 Full GC。JVM 堆内存不够了。一键排查# 1. 确认是否是 GC 导致jstat-gcnacos_pid10005# 看 FGC 列Full GC 次数和 FGCT 列Full GC 总耗时# 如果 FGCT 在持续增长 → Full GC 频繁# 2. 看 GC 日志# 前提启动参数里加了 -Xlog:gc*tail-100/var/log/nacos/gc-*.log# 3. 看堆内存jmap-heapnacos_pid|head-30# 4. 临时恢复方法# 如果是单机重启# 如果是集群先摘掉这个节点让其他节点扛流量再排查常规优化# nacos/bin/startup.sh 的 JVM 参数JAVA_OPT${JAVA_OPT}-server -Xms2g -Xmx2g -Xmn1gJAVA_OPT${JAVA_OPT}-XX:UseG1GC -XX:MaxGCPauseMillis200JAVA_OPT${JAVA_OPT}-XX:HeapDumpOnOutOfMemoryErrorJAVA_OPT${JAVA_OPT}-XX:HeapDumpPath/var/log/nacos/一张图带走30 秒排查路径版本 OK端口 OK认证 OK状态异常确认问题后版本不对端口不通认证失败实例被踢GC 频繁服务出问题注册不上/配置推不过/发现不到1. curl server/state确认版本兼容2. telnet 8848 9848确认端口畅通3. curl auth/login确认认证通过4. 控制台看实例列表确认健康状态5. jstat -gc确认不是 GC 问题对应问题按上面一键排查做到底升级客户端到 2.x或开启 1.x 兼容加防火墙规则9848 TCP 入站检查 username/password确认 token.secret.key查心跳配置查健康检查方式调 JVM -Xmx加 GC 日志截图保存。按 1→2→3→4→5 顺序排查每个节点右边的确认问题后是直接跳转定位到上面具体问题的解法。你们遇到过最离谱的 Nacos 问题是什么评论区留数字1版本不兼容 2防火墙端口 3认证失败 4心跳反复横跳 5配置推送延迟 6MySQL 连接池 7GC 假死 8其他评论区说说。