Tomcat安装配置完成后，最典型的现象是启动窗口里出现Server startup in xxx ms，或者日志中显示部署完成，但打开浏览器访问http://localhost:8080/却看不到任何页面。这种结果和配置过程脱节的问题，通常意味着Tomcat进程本身没有崩溃，而是请求根本没有到达能够处理它的Connector，或者到达之后找不到对应的Web应用。排查不能只盯着启动日志，还要从端口监听、绑定地址、网络策略、应用部署几个层面逐层确认。
一、先确认Tomcat是否真的在监听8080端口
Tomcat启动成功并不代表HTTP端口一定已经进入监听状态。Bootstrap主线程在初始化过程中，如果某些Connector配置错误或端口权限不足，部分版本可能只是记录一条警告日志，进程仍然继续运行。因此第一步要用系统命令查看8080端口有没有被监听，以及监听进程是不是Tomcat。
在Windows系统中打开命令提示符执行：
netstat -ano | findstr :8080
如果返回类似下面这样的结果，说明端口已经在监听：
TCP 0.0.0.0:8080 0.0.0.0:0 LISTENING 4568
其中4568就是进程PID，可以继续用任务管理器确认该PID是否属于Tomcat对应的Java进程。如果命令没有任何输出，或者只看到TIME_WAIT状态，说明8080端口没有进入可接收连接的监听状态。此时需要进入Tomcat的日志目录，查看logs/catalina.out或logs/catalina.日期.log，搜索Failed to initialize connector、Address already in use等关键字。
Linux系统可以使用下面两条命令之一：
ss -lntp | grep 8080 netstat -lntp | grep 8080
如果端口存在监听但PID不是Tomcat进程，大概率是8080被其他程序占用，例如Nginx、Oracle数据库或者另一个Java服务。这种情况下需要修改Tomcat的端口，或者停止占用端口的进程。端口监听是后续所有排查的基础，先把这一层确认清楚，能避免很多无效操作。
二、检查Tomcat绑定的IP地址和防火墙规则
端口确认监听之后，如果本机可以访问但局域网或公网访问不了，问题通常出在绑定地址或防火墙。Tomcat的HTTP连接器在server.xml中通过<Connector>元素配置，其中address属性决定监听在哪个IP上。如果配置成address="127.0.0.1"，那么只有本机能够通过127.0.0.1访问，其他机器访问服务器实际IP时会失败。
打开conf/server.xml，找到类似下面的片段：
<Connector port="8080" protocol="HTTP/1.1"
address="127.0.0.1"
connectionTimeout="20000"
redirectPort="8443" />
如果业务需要通过局域网IP或公网IP访问，应该将address改为0.0.0.0，表示监听本机所有IPv4地址。也可以直接删除address属性，Tomcat会根据版本和协议自动处理。修改后重启Tomcat，再用netstat确认监听地址是否从127.0.0.1变成0.0.0.0。
防火墙是另一个高频原因。Windows Server或Windows 10以上的系统，需要检查Windows Defender防火墙的入站规则是否放行TCP 8080。测试阶段可以临时关闭防火墙，如果关闭后可以访问，说明需要添加放行规则。Linux系统使用firewalld时执行：
firewall-cmd --permanent --add-port=8080/tcp firewall-cmd --reload
如果使用ufw，则执行ufw allow 8080/tcp。云服务器还要检查安全组入方向规则，很多用户在本机排查一圈后才发现是云平台安全组没有开放8080端口。判断依据是：在服务器本机执行curl -I http://127.0.0.1:8080/返回200，但从外部机器访问失败，问题大概率在防火墙或安全组。
三、应用部署路径与ROOT目录问题
有些时候Tomcat本身完全正常，端口也在监听，但访问根路径http://localhost:8080/却看到404错误页面。这时需要检查webapps目录下的ROOT应用是否被删除或被覆盖。Tomcat默认会把根路径映射到webapps/ROOT目录，如果这个目录为空或者不存在，访问根路径自然找不到资源。
常见情况是开发者把项目war包直接放进webapps，比如命名为myapp.war，Tomcat会自动解压到myapp目录，此时正确访问路径应该是http://localhost:8080/myapp/，而不是根路径。如果希望不携带项目名直接访问，最稳妥的做法是把war包命名为ROOT.war，删除旧的ROOT目录后重启Tomcat。
也可以修改conf/server.xml中的<Host>配置，添加一个空路径的<Context>，但Tomcat 8以后对path=""的配置有较多限制，推荐直接使用ROOT.war部署。无论使用哪种方式，都要在修改后查看logs/localhost.日期.log，确认应用部署过程中没有出现ClassNotFoundException、数据库连接失败等异常。因为如果项目启动失败，Tomcat进程可能仍然活着，但业务页面无法正常展示。
四、JDK环境变量与启动方式检查
Windows用户双击startup.bat启动Tomcat时，如果JAVA_HOME配置错误，命令窗口可能会一闪而过。很多用户看到窗口消失，就误以为Tomcat已经成功运行，但实际上JVM根本没有启动。要准确判断启动状态，应该进入Tomcat的bin目录，在命令行中执行：
catalina.bat run
Linux系统则执行：
./catalina.sh run
使用run参数可以在当前终端前台启动Tomcat，所有异常信息都会直接打印出来，窗口不会自动关闭。如果看到JAVA_HOME未设置、UnsupportedClassVersionError或者NoClassDefFoundError，说明JDK版本与Tomcat版本不匹配。Tomcat 9需要Java 8及以上，Tomcat 10.1要求Java 11及以上，Tomcat 11则要求Java 17及以上。安装JDK后要检查环境变量是否指向JDK而不是JRE，路径中的反斜杠在Windows下必须保留，例如C:\Program Files\Java\jdk-11.0.20。
通过run方式启动后，如果看到Server startup in xxx ms，再用另一个终端窗口测试访问。能够正常访问，说明之前双击启动脚本时可能因为环境变量或权限问题没有真正拉起服务。前台启动还可以更直观地观察请求是否到达Tomcat，便于后续定位是应用问题还是网络问题。
五、常见问题与注意事项汇总
除了上述几类核心原因，还有一些细节容易让排查走弯路。比如浏览器缓存和系统代理：测试时建议使用无痕窗口或者命令行工具curl，避免浏览器缓存旧的失败页面。公司网络中的HTTP代理也可能拦截localhost请求，需要在浏览器代理设置中勾选绕过本地地址。
还应该注意localhost与127.0.0.1并不总是等价。某些系统的hosts文件会把localhost解析为IPv6地址::1，如果Tomcat只监听IPv4地址0.0.0.0，那么访问http://localhost:8080/可能失败，而访问http://127.0.0.1:8080/却正常。遇到这种情况可以检查Windows下的C:\Windows\System32\drivers\etc\hosts文件，确认localhost的映射关系。安全软件也可能拦截Java进程的端口监听，测试阶段可以暂时退出安全软件来排除干扰。
如果服务器上存在多个Tomcat实例，还要确认CATALINA_HOME环境变量是否指向了当前正在修改配置的实例。不少用户修改了A实例的server.xml，但实际启动的是B实例，排查很久也找不到原因。日志永远是最可靠的信息来源，logs/catalina.out、logs/localhost.日期.log以及应用自身的日志文件都能提供直接线索。最后可以按顺序整理排查步骤：先看端口监听，再看绑定地址和防火墙，然后确认ROOT部署，最后检查JDK和启动日志。按照这个顺序一般都能定位到问题所在，不必一上来就重装Tomcat。