别再踩坑！访问阿里云Tomcat失败的致命排查清单

很多团队把应用部署到云服务器后，第一时间遇到的不是业务问题，而是“怎么就是访问不了”。尤其是访问阿里云tomcat时，明明本地跑得好好的，上线后却报错、超时、502或空白页。本文基于真实运维案例，总结一套可落地的排查清单，帮助你从网络、系统、服务、应用四个层面定位问题，避免反复试错。

一、先确认“能访问”的定义：端口、协议、路径

不少人说“访问失败”，但失败是什么样的？是浏览器打不开？是curl超时？还是能打开但业务接口报错？先把问题归类：

• 连接超时：多数是网络或安全组问题。
• 连接被拒绝：端口未监听或服务未启动。
• 能访问首页但接口404：上下文路径或反向代理配置问题。
• 返回502/504：前置网关或反向代理与后端Tomcat不通。

只有明确失败类型，排查才不会盲目。接下来进入清单。

二、网络层排查：安全组与防火墙是第一关

1. 安全组端口是否放行

阿里云ECS默认只开放部分端口，Tomcat通常监听在8080或自定义端口。如果未在安全组中放行，外网一定无法访问。检查路径：控制台 → 安全组 → 入方向规则。确保目标端口对外网开放，并限定合理的来源IP。

案例：某教育平台在端口改为18080后仅在系统防火墙开放，安全组未开。内部curl正常，外部访问超时。加规则后立即恢复。

2. 系统防火墙与SELinux

CentOS、Ubuntu可能默认启用防火墙。建议使用如下命令确认：

• CentOS：firewall-cmd –list-ports
• Ubuntu：ufw status

若端口未放行，添加规则并重载。另一个隐蔽点是SELinux，某些情况下会阻止Tomcat绑定端口或访问目录。

3. 公网IP与绑定网卡

有些实例被绑定了弹性IP或通过负载均衡访问，Tomcat却监听在127.0.0.1，导致外网不可见。检查server.xml中的Connector是否绑定了地址，避免只监听本地回环。

三、系统服务层：进程、端口、启动日志

1. Tomcat是否真的启动

“启动成功”的判断不能只看启动脚本输出，要看进程和端口监听：

• ps -ef | grep tomcat
• netstat -lntp | grep 8080

若进程存在但端口未监听，可能是端口被占用或启动失败。查看logs/catalina.out更直观。

2. 端口冲突与权限问题

端口已被其他进程占用时，Tomcat会启动失败，但脚本可能仍返回成功。高频案例是运维人员将Nginx和Tomcat都配置在8080。改端口后务必同步安全组与防火墙。

权限问题常发生在自定义目录部署。Tomcat的运行用户没有权限读写webapps或logs，会导致启动异常或应用加载失败。

3. Java环境与版本兼容

访问失败并非全是网络，某些时候Tomcat启动就报错。例如JDK版本与Tomcat不匹配，日志中会出现Unsupported major.minor version或模块缺失。确认JAVA_HOME指向正确版本，尤其是在多JDK环境中。

四、应用层排查：上下文路径、反向代理、配置错误

1. 上下文路径常被忽略

部署WAR包后，访问路径不是根目录，而是/应用名。如果把应用名当成根访问，会得到404。可以通过server.xml配置Context指定路径，或将war改名为ROOT.war。

案例：某电商系统将war包命名为shop.war，却在浏览器访问IP:8080/，结果404。加上/shop后立刻正常。

2. Nginx反向代理配置不当

很多线上环境通过Nginx代理Tomcat。如果访问阿里云tomcat出现502，一定要检查Nginx upstream配置、proxy_pass地址、以及Tomcat端口。还要注意Nginx所在机器与Tomcat在不同实例时，安全组要放行内网访问。

3. Tomcat线程与连接池耗尽

并不是“访问失败”都来源于不可达。有时服务压力大，Tomcat线程池耗尽，表现为连接超时或极慢。检查server.xml中的maxThreads、acceptCount，结合应用数据库连接池配置进行调整。

五、最容易忽略的“云”相关坑

1. 弹性IP更换导致DNS失效

很多人直接用公网IP访问，IP变更后访问自然失败。建议绑定弹性IP并使用域名访问，通过DNS快速更新。同时确认DNS解析生效时间。

2. SLB健康检查与路径

如果通过负载均衡访问，健康检查路径不正确会导致后端被剔除。比如Tomcat应用路径是/portal，但健康检查配置为/，返回404，SLB认为不健康。修改健康检查路径即可。

3. 云安全策略与WAF拦截

开启WAF后，一些请求被误判为恶意访问而拦截，表现为访问失败或返回403。结合WAF日志检查拦截规则，适当放行。

六、快速诊断顺序：从外到内，避免绕圈

1. 外部访问是否能连接：curl -v http://公网IP:端口
2. 安全组与系统防火墙是否放行端口。
3. Tomcat进程与端口监听是否正常。
4. Tomcat日志中是否有启动错误。
5. 访问路径是否正确，是否需带应用名。
6. 有无反向代理或负载均衡中间层。
7. 应用是否超载导致连接慢或超时。

这个顺序的核心是“先排外部、再排内部”，避免在应用层纠结时，实际问题却是端口未放行。

七、一个完整案例：从超时到恢复的全过程

某SaaS团队在阿里云ECS部署Tomcat，访问阿里云tomcat时外网超时。运维先检查Tomcat日志，无报错；服务器内网curl本地端口正常。随后检查安全组发现只开放了80和22，8080未开放。放行端口后仍访问失败。继续排查发现系统防火墙中仅允许特定IP访问8080，外网被拦截。放开规则后访问恢复正常。最后再将Tomcat置于Nginx后，通过80端口对外，关闭8080公网访问，形成更安全的访问链路。

这个案例说明：单点修复不够，必须把链路上的每一层都核查一遍。

八、可复制的“上线前自检清单”

• 安全组开放必要端口，且限定来源。
• 系统防火墙规则与安全组一致。
• Tomcat监听地址为0.0.0.0或绑定正确网卡。
• 应用路径明确，必要时配置ROOT。
• 反向代理、SLB健康检查路径正确。
• JDK版本与Tomcat匹配。
• 日志目录可写，避免权限问题。

结语：让访问失败成为可控问题

访问失败并不可怕，可怕的是没有结构化排查思路。把问题拆成“网络、系统、服务、应用、云产品”五层，你就能快速定位。下一次遇到访问阿里云tomcat失败时，别再盲猜，按清单逐条核对，你会发现大多数问题都有明确原因与修复路径。技术不是运气，而是方法。