服务器上JSP页面访问不了，核心原因集中在Tomcat连接器故障、Java运行环境异常、编译报错或上下文路径配置错误这几类，按链路逐层排查即可定位。
JSP页面打不开,跟普通HTML页面打不开，本质上不是一回事，HTML是静态文件，只要Web服务器（Nginx、Apache）还活着，文件权限没问题，基本就能访问，但JSP是动态脚本，它的访问链路是：浏览器请求 → 连接器（Connector）→ Servlet容器（Tomcat）→ Java编译器 → 操作系统，任何一环断了，浏览器那边看到的结果都是“打不开”或者“500报错”，下面按照排查优先级，从最常见的原因说起。
连接器没起来：端口吞了，请求进不来
Tomcat默认监听8080端口，很多时候JSP突然访问不了，不是代码坏了，而是Tomcat进程死了，或者端口被别的程序占了。
确认端口还活着
先做一件最基础的事：在服务器上执行netstat -tlnp | grep 8080，看看这个端口有没有进程在监听。
- 如果没有任何输出,说明Tomcat没启动，或者启动后崩了，执行
ps -ef | grep tomcat查看进程是否存在，存在但端口没监听，多半是启动时报错了，去logs/catalina.out里翻Java异常堆栈。 - 如果端口被占用,但占用者不是Java进程，那可能是Nginx反向代理配置错误，把请求转发到了错误的位置，或者别的服务抢占了端口，业内专家指出，端口冲突导致的“间歇性打不开”在老旧服务器上相当常见，换端口后重启Tomcat通常能恢复正常。
线程池耗尽会导致页面卡死
有一种场景很迷惑：页面不是打不开，而是“转圈圈”很久，最后浏览器提示无法连接，这往往是Tomcat内部线程池被占满，访问高峰过后，大量连接没有正常释放，线程池耗尽，新请求全部排队，表现就是JSP页面全部无响应。
此时执行jstack <Tomcat进程ID> | grep "http-nio" | wc -l，如果线程数长期接近配置上限，就需要调整server.xml里maxThreads的值，行业共识认为，多数情况下这类问题源于连接未正确关闭，排查代码里是否有流未关闭比盲目调大线程池更有效。
版本兼容性：JDK版本太新，老JSP直接罢工
这个问题在国内服务器上出现频率很高,很多服务器为了安全升级或新装环境，装的是JDK 17甚至JDK 21，但跑的是老项目，用的是Tomcat 8或者Tomcat 9的老版本，JSP编译依赖ECJ（Eclipse编译器），高版本JDK下老Tomcat的JSP解析器会抛出UnsupportedClassVersionError或ClassNotFoundException，导致所有JSP页面直接502或500。
推荐做法是固定JDK大版本,不要随意升级，确认当前Java版本执行java -version，再看项目lib目录下是否有对应版本的ecj.jar，如果项目是从JDK 8迁移到JDK 11，JSP里的某些写法（比如application.setAttribute的泛型强制转换）可能在编译期直接报错，这时候页面会白屏，后台日志能清楚看到编译失败的堆栈。
JSP编译报错：页面文件有问题，不是服务器有问题
这种情况往往只影响个别页面，而不是整个站点，打开A页面正常，打开B页面就报500，那问题基本锁定在JSP文件本身的编译错误。
用命令行单独编译JSP文件需要依赖Tomcat的jasper.jar，不太方便，更快的方式是直接看Tomcat的logs/localhost.<日期>.log文件，搜索页面文件名，会看到具体的编译错误行号，比较常见的有：
- 标签库引用错误：
<%@ taglib %>指定的URI不存在，或版本不匹配。 - Java代码片段（Scriptlet）语法错误：JSP里嵌入了不完整的Java代码块。
- 缺少依赖类：页面引用了某个业务类，但
WEB-INF/lib目录下的jar包没更新或丢失。
如果将JSP文件当作独立的Java源码来编译,很难直接看出端倪；但放到Tomcat容器里整体看，多半是类路径的问题，下载一个完整可用的依赖包放置到WEB-INF/lib后重启，一般就能恢复。
上下文路径与虚拟主机配置：路径对不上，一直404
有时候JSP页面确实能访问,但访问地址变了，比如原来用的IP加端口直接访问，现在整理了服务器，改用域名加路径的方式访问，导致web.xml里配置的Servlet映射失效。
- 直接访问
http://IP:8080/login.jsp打不开，但访问http://IP:8080/项目名/login.jsp能打开。 - 访问https域名启动的JSP站点,外部请求被防火墙拦截了443端口，而HTTP的80端口正常，本地服务器和云服务器在这一步的排查逻辑不同：云服务器需要去简米云或酷番云控制台查看安全组规则，本地服务器直接在防火墙层面放行端口。
这类问题严格来说不是JSP本身出错,而是访问路径的基础设施配置变了，用curl -I http://localhost:8080/你的项目名/在服务器本机测试，如果本机返回200，那就是防火墙或安全组拦截了外部请求。
内存溢出导致整个站点突然瘫痪
JSP编译需要加载大量类定义和生成临时class文件,老项目长期运行，元空间（Metaspace）或堆内存被占满，会直接抛出OutOfMemoryError，表现为所有页面突然无法访问，重启Tomcat后恢复，运行一阵后又复发。
查看catalina.out日志，如果出现java.lang.OutOfMemoryError: Java heap space，说明堆不够用；如果出现Metaspace错误，说明加载的类太多，排查步骤：
- 用
jstat -gc <PID>观察GC频率和内存占用。 - 查看
bin/catalina.sh或setenv.sh里的JAVA_OPTS，确认-Xmx和-XX:MaxMetaspaceSize是否合理。 - 如果业务量不大,但内存持续增长，重点排查项目里是否有静态集合类（比如
static List）不断添加数据不清理这是典型的JSP后台代码泄露。
高并发下的线程阻塞与死锁
一个相对隐蔽的场景：JSP页面平时正常，一到集中访问时段（比如早上9点上班打卡或者月底报表导出）就卡死，这种通常不是资源不足，而是业务逻辑中存在锁竞争，某个公用的Java方法加了synchronized，或者数据库连接池被耗尽，线程都在等待连接释放。
排查方式靠线程快照：执行jstack <PID> > thread_dump.txt，连续抓两三次，间隔几秒，如果看到大量线程处于WAITING状态，且堆栈信息停留在DBConnection.getConnection()或自定义的Lock上，就说明下游数据库或者公共接口响应太慢，拖垮了JSP渲染线程，此时改动JSP页面本身没用，需要优化数据库SQL或者外部API调用的超时时间。
排查工具箱：一套操作路径快速定位
遇到“服务器jsp页面访问不了怎么排查”这种实际问题，顺序比知识储备更重要，按照下面的链路走，绝大多数问题能在10分钟内定位：
- 第一步：看进程。
ps -ef | grep tomcat确认Java进程是否存在。 - 第二步：看端口。
netstat -tlnp | grep 8080确认监听状态，必要时curl -I测试本机回环。 - 第三步：看日志，直接打开
logs/catalina.out，搜索SEVERE或Exception，这一步要打开两个终端对比时间戳。 - 第四步：看内存。
jstat -gcutil <PID> 1000 5观察内存使用率是否持续高位。 - 第五步：看线程。
jstack <PID>检查是否有大量BLOCKED线程。
最后一招是禁用JSP缓存，在Tomcat的web.xml中设置development=true和checkInterval=0，强制JSP每次都重新编译，这样虽然牺牲一些性能，但能确认问题是否由“缓存了旧的编译class文件”导致，如果关了缓存、重启后页面正常，说明是文件名大小写不一致或文件更新时间戳错误引发了诡异缓存问题。
Q&A：服务器上常见JSP故障快问快答
问题：JSP页面访问时出现中文乱码，但页面能打开，是服务器的问题吗？
不是,页面能打开说明连接器和Servlet容器正常，乱码是请求或响应的编码不一致导致的，检查web.xml里是否配置了CharacterEncodingFilter，以及JSP页面顶部的contentType是否设置了项目的实际编码（通常是UTF-8），如果404错误页面本身就能正常显示，那服务器连接层完全正常，故障限定在请求参数的编码格式上，处理方式和Java环境里的字符集配置有关，先确认file.encoding参数是否设置为UTF-8，再调整代码，不要盲目在服务器层面乱改语言环境。
问题：JSP页面上传图片时提示服务器错误，其他功能都正常，怎么回事？
多半是web.xml里配置了multipart-config的max-file-size（最大文件上传大小）限制过小，上传文件一旦超过这个阈值，Tomcat会直接抛出IllegalStateException，并把整个请求判定为异常，调整max-file-size和max-request-size到合理值（比如50MB或100MB）即可，这本质上和JSP的“页面访问”不同连接是通的，业务处理中断了。
问题：为什么HTML能访问，JSP却显示404？
因为HTML是静态资源,Web服务器可以直接从系统文件目录里读取并返回；JSP则需要经过JSP引擎的uri映射处理，如果URL地址没有映射到web.xml中的<servlet-mapping>定义，容器自然返回404，检查index.jsp是否正确放置在webapps/ROOT目录下，以及项目的WEB-INF/web.xml中welcome-file-list（欢迎文件列表）是否包含了index.jsp，JSP和HTML访问差异的第一道分水岭就在这静态文件由文件系统决定，动态文件由容器映射决定。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/794372.html
