Nacos启动报错Unable to start embedded Tomcat的排查指南

先说明一下场景。我第一次在服务器上部署 Nacos 2.2.3 时，控制台直接甩出 Unable to start embedded Tomcat 的全屏堆栈，第一反应以为是 Tomcat 装坏了，又是查版本又是换端口，折腾了快一个小时才发现，罪魁祸首居然是一个早就跑在 8848 端口上的旧 Nacos 进程。

后来帮同事排查过几次同类问题，听到最多的一句话就是“我明明照着教程配置的，Tomcat 就是起不来”。其实这类启动报错里，Tomcat 通常只是被殃及的池鱼。真正的问题往往出在端口占用、数据库连接、JDK 环境，甚至是你自己写的 Spring Boot 服务配置上。

这篇文章就围绕这个报错，把 Nacos 服务端和微服务客户端两种场景分开讲清楚，再把排查思路、实际命令和容易忽略的细节一次说完。

1. 先把报错拆开看：这个 Tomcat 是谁的，为什么 Nacos 会带上它

很多第一次接触 Nacos 的人会有一个误解：认为 Nacos 是一个独立服务，和 Tomcat 没有关系，报错里出现 Tomcat 很莫名其妙。

错。Nacos Server 本身就是一个基于 Spring Boot 的应用。你从官网下载的 nacos-server.jar，解压后在 bin 目录下执行 startup.sh，本质上就是在用 java -jar 启动一个 Spring Boot 工程。Spring Boot 默认的 Web 容器就是内嵌 Tomcat，所以 Nacos 的控制台、HTTP API、健康检查，全部是通过内嵌 Tomcat 对外提供服务的。

这也是 “embedded Tomcat” 里 embedded 的含义：它不是一个独立安装的 Tomcat，不需要你额外下载 apache-tomcat-9.x 去部署 Nacos 的 war 包。报错信息里的那个 Tomcat，是 Nacos 启动时自己带起来的。

那什么时候会报 Unable to start embedded Tomcat？以 Spring Boot 2.x 的典型日志为例，出现这个错之前，通常会有一行指向起不来原因的描述，常见的有这一种：

code复制***************************
APPLICATION FAILED TO START
***************************

Description:

The Tomcat connector configured to listen on port 8848 failed to start. The port may already be in use or the connector may be misconfigured.

Action:

Verify the connector's configuration, identify and stop any process 
listening on port 8848, or configure this application to listen on another port.

看着是 Tomcat 绑定端口失败，对吧？但端口被占只是其中一种可能。你再往下翻堆栈，还可能出现：

code复制Caused by: java.net.BindException: Address already in use: bind

或者：

code复制Caused by: com.alibaba.nacos.api.exception.NacosException: java.lang.IllegalStateException: Fail to get driver of DataSource

又或者干脆是 JDK 版本不匹配、数据库连不上、配置中心拉取失败这一类早期初始化异常。

所以这里先给你一个最重要的判断原则：不要只看第一行，要看最后一个 Caused by。Tomcat 启动失败只是一个结果，你要找的是触发它的那个原因。后面排查章节里，我会反复讲这个原则。

另外还要区分一个关键场景：这个报错到底是谁报的？

• 场景 A：你启动的是 Nacos Server，也就是执行了 bin/startup.sh，或者用 Docker 启动了 nacos/nacos-server 镜像。此时要排查的是 Nacos 自身运行环境。
• 场景 B：你启动的是自己写的 Spring Boot 微服务，pom 里引入了 spring-cloud-starter-alibaba-nacos-discovery 或 nacos-config-spring-boot-starter，你的业务应用自己也是一个内嵌 Tomcat 的服务。

这两种场景看似报错一样，排查方向却完全不同。很多人拿着场景 B 的日志去搜场景 A 的教程，结果越查越乱。下面分别讲。

2. 服务端场景的排查路径：8848、数据库、JDK，按概率从高到低过一遍

如果你确认报错来自 Nacos Server 本身，我的经验是不要乱猜，按下面四条路径走完，