在Linux服务器上部署Java Web应用，Tomcat几乎是绕不开的中间件。不少初学者下载好Tomcat压缩包之后，直接执行startup.sh却发现浏览器访问不了页面，或者终端一闪而过什么信息都看不到。其实Tomcat的启动涉及JDK环境、环境变量、脚本权限、端口占用等多个环节，任何一处出问题都会导致启动失败。本文将完整梳理在Linux服务器上启动Tomcat的全过程，并针对常见的报错逐一给出排查思路和解决办法。
一、启动前的环境准备
Tomcat是用Java编写的，运行它必须先有JDK。在终端执行java -version命令，如果能正常输出Java版本信息，说明JDK已经安装。如果没有安装，以CentOS为例可以用yum快速安装：
# 检查是否已安装JDK java -version # CentOS安装OpenJDK yum install -y java-1.8.0-openjdk java-1.8.0-openjdk-devel # Ubuntu / Debian安装 apt-get install -y openjdk-8-jdk
安装完成后，建议手动配置JAVA_HOME环境变量。编辑/etc/profile文件，在末尾追加以下内容（路径根据实际安装位置调整）：
export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk export PATH=$JAVA_HOME/bin:$PATH # 使配置立即生效 source /etc/profile
接着下载Tomcat。可以到Apache官方站点获取tar.gz压缩包，传到服务器后解压到目标目录，例如/usr/local/tomcat：
# 解压到指定目录 tar -zxvf apache-tomcat-9.0.xx.tar.gz -C /usr/local/ mv /usr/local/apache-tomcat-9.0.xx /usr/local/tomcat # 赋予脚本可执行权限 chmod +x /usr/local/tomcat/bin/*.sh
这里要特别注意最后一步的权限问题。如果是从Windows环境解压后再上传的文件，或者通过某些FTP工具传输，脚本的可执行权限常常会丢失，执行时会提示Permission denied。用chmod +x统一处理一次可以避免大部分权限类报错。
二、两种启动方式及其区别
进入Tomcat的bin目录后，最常用的启动命令是./startup.sh。这个脚本本质上是调用了catalina.sh start，它会以后台守护进程的方式启动Tomcat，脚本执行完立刻返回终端，不会占用当前窗口。启动成功后可以用ps -ef | grep tomcat查看进程是否存在。
cd /usr/local/tomcat/bin # 后台方式启动 ./startup.sh # 查看进程 ps -ef | grep tomcat
另一种方式是前台运行，执行./catalina.sh run。这种方式会把启动日志直接打印到当前终端，一旦出现异常能立刻看到错误堆栈，非常适合排查问题时使用。缺点是关闭终端窗口或按Ctrl+C会直接停掉Tomcat。两种方式的选择原则很简单：日常运维用startup.sh，调试排错用catalina.sh run。
还可以通过配置环境变量让Tomcat输出更详细的调试日志。在bin目录下创建setenv.sh文件（该文件如果存在会被catalina.sh自动加载），写入类似export CATALINA_OPTS="-Xms512m -Xmx1024m"的内容，即可自定义JVM参数而不用修改官方脚本，升级Tomcat时也更方便。
三、验证启动与日志排查
启动脚本执行后显示的Tomcat started并不代表服务一定正常，必须实际验证。最直接的方式是检查端口监听状态：
# 查看8080端口是否被监听 netstat -tlnp | grep 8080 # 或者使用较新的命令 ss -tlnp | grep 8080 # 测试端口是否可连通 curl http://127.0.0.1:8080
如果curl能返回Tomcat默认页面的HTML内容，说明服务本身已经起来了。此时如果浏览器仍然访问不了，问题多半出在防火墙或安全组上。CentOS 7以上可以执行firewall-cmd --permanent --add-port=8080/tcp然后firewall-cmd --reload放行端口；云服务器还需要到控制台的安全组规则中放行8080端口。
日志是排查Tomcat问题的核心手段。Tomcat的日志都存放在logs目录下，其中catalina.out记录了启动全过程的标准输出，是最常看的文件。查看实时日志可以用tail -f /usr/local/tomcat/logs/catalina.out，启动失败的绝大多数原因都能在这个文件里找到答案。localhost.log和catalina.yyyy-MM-dd.log则分别记录应用级别和按天滚动的日志，遇到具体应用报错时也应一并查看。
四、常见报错与解决方案
1. 端口被占用（Address already in use）。日志中如果出现java.net.BindException: Address already in use，说明8080或其他端口已被占用。用netstat -tlnp | grep 8080找到占用进程，如果是旧的Tomcat进程就执行./shutdown.sh正常关闭，仍然杀不掉时可以用kill -9 进程号强制结束。也可以修改conf/server.xml中的Connector端口配置来换一个端口。
2. JDK环境问题。报错Neither the JAVA_HOME nor the JRE_HOME environment variable is defined，说明系统找不到Java环境。检查环境变量是否配置正确，并确认执行了source命令使其生效。如果用systemd方式管理Tomcat，还要注意在service文件中显式指定JAVA_HOME，因为systemd启动的服务不会读取/etc/profile中的用户级环境变量。
3. 权限不足（Permission denied）。执行startup.sh时提示权限不足，通常是脚本没有可执行权限，用前面提到的chmod命令处理即可。另外如果Tomcat安装在root目录下而以普通用户运行，也会出现类似问题，建议将Tomcat放在公共目录并保证运行用户对整个目录有读写权限。
4. 中文乱码。catalina.out中中文显示为问号，可以在server.xml的Connector节点中添加URIEncoding="UTF-8"属性，同时设置系统环境变量export LANG=zh_CN.UTF-8，一般就能解决。
5. 启动成功但访问404。这种情况要区分是Tomcat首页404还是应用404。如果webapps目录被清空过，默认首页自然不存在，这不影响应用部署。如果是自己的war包访问404，检查war包是否正确放到webapps目录、context路径是否与访问地址一致即可。
五、把Tomcat配置为系统服务
手动执行脚本启动Tomcat在服务器重启后不会自动恢复，生产环境通常将其注册为systemd服务。在/etc/systemd/system/目录下创建tomcat.service文件：
[Unit] Description=Apache Tomcat After=network.target [Service] Type=forking Environment=JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk ExecStart=/usr/local/tomcat/bin/startup.sh ExecStop=/usr/local/tomcat/bin/shutdown.sh User=root [Install] WantedBy=multi-user.target
配置完成后依次执行以下命令即可实现开机自启和日常管理：
# 重新加载systemd配置 systemctl daemon-reload # 启动并设置开机自启 systemctl start tomcat systemctl enable tomcat # 查看运行状态 systemctl status tomcat
需要注意的是，service文件中的Type=forking要与startup.sh的后台启动行为匹配。如果这里写成了simple，systemd会误判服务启动状态。另外前文提到的JAVA_HOME问题也在这里体现得最明显，很多用户命令行能启动、systemd启动就失败，根因就是systemd环境变量独立，必须在service文件里显式声明。
总的来说，在Linux上启动Tomcat本身并不复杂，难的是启动失败后的定位。养成先看catalina.out日志、再查端口和进程、最后检查防火墙的排查习惯，绝大多数问题都能在几分钟内定位并解决。生产环境务必使用systemd管理进程，配合日志轮转策略，才能保证服务的稳定运行。
Linux启动TomcatTomcat部署catalina.sh修改时间：2026-08-31 21:19:11