tomcat网页无法访问

Tomcat 启动成功，网页无法日志里连一个报错都没有，访问浏览器打开却只看到「无法访问此网站」——这种反差最让人摸不着头脑。网页无法我遇到过好几次，访问有一次印象特别深：本地 8080 端口跑着 Tomcat，网页无法控制台干干净净，访问可页面就是网页无法死活不出来。折腾半小时才发现，访问是网页无法防火墙把 8080 拦了。

先说一个最常见的访问坑：端口根本没在监听。Tomcat 显示「Server startup in xxx ms」不代表它一定绑到了你期望的网页无法端口。打开命令行敲 netstat -ano | findstr 8080（Windows）或 lsof -i:8080（Linux/Mac），访问看看有没有进程真的网页无法在 LISTEN。如果什么都没有，访问八成是网页无法 server.xml 里的 Connector 配置被改过，比如端口写成了 8081，或者被注释掉了。

还有一种情况，端口在监听，但你访问的是 http://localhost:8080，Tomcat 却只绑定了 IPv6 的 ::1，没绑 IPv4 的 127.0.0.1。这时候换 http://127.0.0.1:8080 试试，能通就说明是绑定地址的问题。在 Connector 里加个 address="0.0.0.0" 就能解决。

防火墙这事值得单独拎出来说。Linux 上 firewalld 或 iptables 默认可能只放行了 22 和 80。你本地 curl 能通，外部浏览器打不开，基本就是防火墙的锅。临时关掉防火墙测试一下：systemctl stop firewalld，如果页面立刻能访问，那就老老实实加规则放行 8080。云服务器还有安全组，这个更隐蔽，我第一次用阿里云的时候就被安全组坑了一下午。

项目部署本身的问题也常被忽略。Tomcat 起来了，但你的 war 包没解压成功，或者 context path 跟你以为的不一样。默认情况下，把 myapp.war 丢进 webapps，访问路径是 /myapp，不是根路径 /。想直接根路径访问，得把 war 包重命名为 ROOT.war。我见过有人把 war 包扔进去，然后访问 http://localhost:8080/ 看到 Tomcat 默认页，就以为部署失败了，其实应用在 /myapp 下面跑得好好的。

日志也得看对地方。catalina.out 里如果出现 SEVERE: Error deploying web application archive，那说明 war 包本身有问题，比如 web.xml 配置错误、依赖冲突。还有一种静默失败：Tomcat 的 host 配置了 autoDeploy="false"，war 包扔进去根本不会自动部署，得手动触发或者重启。这个配置在 server.xml 的 Host 标签里，默认是 true，但有人为了「优化」把它关了，后面就忘了。

浏览器缓存和代理也值得排查。公司网络经常配了 HTTP 代理，浏览器请求 localhost 的时候走了代理，代理服务器当然找不到你本地的 Tomcat。Chrome 里检查一下代理设置，或者用 curl -v http://localhost:8080 绕过浏览器直接测。curl 能通、浏览器不通，那就是浏览器或代理的问题。

最后说一个比较隐蔽的：Tomcat 的 appBase 路径配置。server.xml 里 Host 标签的 appBase 默认是 webapps，但如果你改成了绝对路径，而那个路径下没有你的应用，Tomcat 启动不会报错，访问就是 404 或者连接被拒。检查一下 appBase 指向的目录，确认 war 包确实在里头。

排查这类问题，顺序很重要：先确认端口监听，再确认防火墙，然后看应用部署路径，最后查浏览器和代理。别一上来就翻 catalina.out，有时候日志干净得很，问题压根不在 Tomcat 本身。