打开浏览器，浏览地址栏输入那个以.jsp结尾的器打链接，回车。不开页面要么一片空白，浏览要么直接甩出个500错误，器打再或者干脆提示“无法访问此网站”。不开后端同事跑过来说“我本地跑得好好的浏览”，运维那边查了日志说“请求根本没到Tomcat”。器打这事我遇到过不下十次，不开每次原因都不一样。浏览

先看一个最常被忽略的器打情况：JSP文件本身根本没被编译。Tomcat这类容器第一次收到对某个JSP的不开请求时，会把它翻译成Java文件再编译成class。浏览如果JSP里写了语法错误，器打比如漏了个分号、不开标签没闭合，编译阶段就挂了。浏览器看到的可能是500，但真正的报错藏在Tomcat的logs目录下，local_host.<日期>.log里会有一大段堆栈。很多人只盯着浏览器看，不去翻日志，自然找不到北。

另一个高频问题是路径。JSP放在WEB-INF目录下，浏览器直接访问就是404。这不是bug，是Servlet规范规定的，WEB-INF下的东西不允许外部直接请求。有人把页面丢进去，然后纳闷为什么打不开。还有大小写，Linux服务器上Login.jsp和login.jsp是两个完全不同的文件，Windows开发机上没事，一部署到Linux就404。

端口和协议也常出岔子。开发环境用8080，生产环境走Nginx反代到443。如果Nginx配置里只转发了/api路径，没处理*.jsp，那浏览器请求JSP时Nginx直接返回404或者502。我见过一个案例，Nginx的proxy_pass后面多写了个斜杠，导致所有JSP请求的路径被重写，后端收到的URL全变了样。

浏览器这边也有锅。有些安全插件或者企业策略会拦截包含.jsp的URL，尤其是那些带查询参数的。Chrome的F12打开Network面板，看请求状态是(blocked:other)还是真的发出去了。如果是前者，跟后端一点关系都没有。还有缓存，强刷Ctrl+F5能解决一部分“昨天还能打开今天就不行”的玄学问题，因为浏览器可能缓存了之前的302跳转或者错误页面。

Tomcat自身的配置也得查。比如web.xml里servlet-mapping把*.jsp映射到了某个自定义Servlet，那个Servlet又没正确处理请求，结果就是404。或者context.xml里配了antiResourceLocking，在某些文件系统上会导致JSP无法编译。还有个冷门情况：JDK版本和Tomcat版本不匹配，比如Tomcat 9跑在JDK 17上，JSP编译用的ECJ版本太老，直接抛java.lang.NoClassDefFoundError。

我的排查顺序一般是：先看浏览器Network面板确认请求发出去了没有，再看Nginx或Apache的access log确认请求到了反向代理没有，然后看Tomcat的localhost log确认JSP编译有没有报错，最后才去翻应用自己的日志。大部分问题在前两步就能定位。别一上来就重启Tomcat，那只能掩盖问题，下次还会犯。

说个真事。有次线上一个JSP页面突然打不开，浏览器转圈然后超时。查了一圈发现是JSP里有个<jsp:include>指向了另一个JSP，那个被包含的JSP里又去查数据库，数据库连接池满了，整个请求就卡死在那。浏览器超时是因为Tomcat的connectionTimeout设了20秒，但数据库查询等了60秒。这种问题看浏览器报错根本没用，得去抓线程dump。

所以浏览器打不开JSP，从来不是单一原因。它可能是编译错误、路径错误、代理配置错误、权限问题、依赖冲突，甚至就是浏览器自己抽风。别指望有个万能解法，老老实实一层一层剥。

(责任编辑：休闲)