简介：这是一份面向Java Web开发与运维人员的Apache Tomcat 7.0.103 Windows x64发行版压缩包，适用于在本地快速搭建Servlet/JSP运行环境或部署测试Web应用。包体共648个文件，大小10.38MB，其中包含237个HTML页面、106个class类文件、78个Java源文件、58个JSP页面以及30个jar依赖包，同时提供bin目录下的启动/关闭脚本与conf目录下的配置文件，整体结构完整，解压后即可直接使用，免去手动配置环境变量的繁琐步骤。目前已有573人学习或下载该资源。对于正在学习Tomcat基础运维、需要对比不同版本行为或准备部署环境的开发者而言，这份免费资源能帮助快速获得一个可运行的中间件实例，并可通过自带示例应用和JSP文件验证配置是否生效。
1. Tomcat 7.0.103 Windows x64：你的老项目部署兜底方案
Tomcat 7.0.103 这个 Windows x64 压缩包，是很多遗留系统部署时的兜底方案。虽然新项目都已经跑在 Tomcat 8.5 或 9/10 上了，但老业务一旦依赖 Servlet 3.0 时代的 API，或者项目里写死了硬编码路径，升级容器往往比改代码还痛苦。这个版本正好卡在“还能跑老代码”和“补过不少 bug”的平衡点上。适合三类人：接手老项目的运维、给客户做离线交付的集成商、以及本地要还原生产环境的开发。它解决的从来不是“最新最强”，而是“能不能起来、稳不稳定”的问题。如果你手里的应用绑定的是 JDK 7 或 JDK 8，这个 zip 基本就是最稳的选择。有人觉得 7.0 太老，但老系统的兼容性才是它的核心价值：没有人会因为选型够新而感激你，但部署一次成功会让整个团队记住你。
2. 下载与解压：为什么这个 zip 包这么受人待见
2.1 选型逻辑：7.0.103 在补丁版里是什么位置
Tomcat 7 系列从 7.0.0 一路补到 7.0.100 以上。7.0.103 属于后期补丁版，相比 7.0.50 这种“中年版本”，它修复了很多和连接器、会话管理相关的 bug。站在源码维护的角度，补丁版之间的接口几乎不变，也就是说，你在 7.0.50 上跑得好好的应用，直接换 7.0.103 的 zip 目录替换，通常不用改一行配置。我做过好多次测试，最省心的做法就是保留原有 conf 目录，只替换 bin 和 lib 目录。
但为什么非要 7.0.x，而不是 8.5 或 9？因为 Servlet 版本。Tomcat 7 对应 Servlet 3.0，8.5 对应 3.1，9 对应 4.0。很多老框架在 Servlet 3.0 下用反射直接访问那些内部类，升到 3.1 后类加载器结构变了，立刻报 NoSuchMethodError。这种问题绝不是小修小补能解决的，所以很多公司宁可把 Tomcat 7 用到天荒地老，也不愿意动这个根子。7.0.103 在这个背景下，就成了一个“既稳定又不太落后”的终态版本。你说它新吗？不新。你说它能用吗？对于老项目来说，太能用了。
这里还要考虑 JDK 兼容性。Tomcat 7 官方支持的 Java 范围很宽，从 Java 6 到 Java 8 都行。但我实际部署中看到最多的是 JDK 7 和 JDK 8。如果你打算用 JDK 11 跑 Tomcat 7，那就要谨慎了，高版本 JDK 做了模块化封装，Tomcat 7 启动时可能抛出IllegalAccessError，原因是内部反射访问被限制。这时候要么换更高版本 Tomcat，要么老老实实装一个 JDK 8。选 zip 之前，先问清楚生产的 JDK 版本，这是第一步。
java -version这条命令用来确认 JDK 位数和版本。输出里要有64-Bit，才配得上windows-x64这个包名。32 位 JDK 跑 64 位 Tomcat，会在启动瞬间报错：Could not find the main class或者更直接的JVM.dll位数不匹配。这种问题发生在刚入职的同事身上，通常会被看成“基础没打好”，但其实是打包命名太有迷惑性。
2.2 解压路径与 JAVA_HOME：第一道坑
解压路径可以说是 Tomcat 在 Windows 上的第一大坑。你解压到D:\Program Files\Tomcat 7这种带空格和英文单词的路径，Tomcat 本身通常能启动，但当你再用 ant 脚本执行部署、或者在 CI 工具里拼接路径时，空格会把整个命令行参数打散，导致各种莫名其妙的结果。更可怕的是中文路径。Tomcat 对 Windows 中文路径的支持一直有历史包袱，就算启动成功，日志里的路径显示也不正常，session 持久化文件还可能写不进去。
因此我给自己定的规矩是：所有服务器上的 Tomcat 一律放在D:\apps\tomcat7这种“三级纯英文”目录里。不要用C:\Users\你的用户名\Downloads\tomcat7这种用户目录，因为权限和路径长度都会带来额外限制。Windows 的路径长度默认限制在 260 字符以内，Tomcat 某些功能一次会拼接很长的路径，放在用户目录下容易触发PathTooLongException。
环境变量方面，JAVA_HOME必须指向 JDK 的安装根目录，而不是bin目录。CATALINA_HOME指向 Tomcat 根目录。很多教程说这两个变量可选，因为 startup.bat 会自动找 java。但实际生产中，第三方监控、部署脚本、IDE 都要读这两个变量，所以我建议一律显式配置。在系统环境变量里设置好之后，重开命令行：
echo %JAVA_HOME% d:\apps\tomcat7\bin\catalina.bat versionecho验证变量是否生效，第二行直接调用catalina.bat version，如果能打印出 Tomcat 版本和 JVM 版本，说明基础环境就绪了。catalina.bat version这个命令不会启动服务，只是读取版本信息，非常适合用来验证环境。注意，JAVA_HOME的值不能加引号，路径末尾也不要有空格，否则脚本拼接路径时会出问题。
2.3 zip 包目录结构：每个文件夹负责什么
解压完，你会看到 bin、conf、lib、logs、temp、webapps、work 这 7 个默认目录。表格快速记录一下：
| 目录 | 职责 | 你需要在什么时候关注 |
|---|---|---|
| bin | 启动关闭脚本、tomcat7.exe | 服务安装、手动启动 |
| conf | server.xml、web.xml、context.xml | 端口、线程池、虚拟目录 |
| lib | Tomcat 自身的 jar 包 | 补丁升级时整个替换 |
| logs | 运行日志 | 启动失败、应用异常排查 |
| temp | 临时文件 | 磁盘满时清理 |
| webapps | 应用部署根目录 | 拷 war 包、看自动部署 |
| work | JSP 编译产物 | 页面不更新时清理 |
特别注意lib目录。Tomcat 自身的类库放在这里，也允许你放一些公共 jar。但如果你把某个应用专属的 jar 也丢进lib，当多个应用同时运行时，类冲突会让人头大。我的原则是：lib里只放 Tomcat 官方自带的 jar，以及确实需要全局共享的驱动；应用依赖一律打进 war 包里的WEB-INF/lib。这样每个应用之间是隔离的，不会出现 A 应用把 B 应用的 jar 版本覆盖掉的情况。
work目录是 JSP 首次访问时编译 Java 文件的存放地。如果你修改了 JSP 但浏览器一直显示旧页面，最常见的情况就是 work 目录里的编译产物还在。有的是因为文件时间戳没变，Tomcat 以为 JSP 没改；有的是因为浏览器缓存。这时候手动删除work\Catalina\localhost下的对应应用目录，再刷新页面，通常就好了。所以我排查页面不更新问题时，第一步不是清浏览器缓存，而是看 work 目录。
2.4 zip 包与安装版的区别：我为什么坚持用绿色版
Tomcat 官方在 Windows 下提供 zip 和 exe 安装版两种形式。exe 安装版会向注册表写入服务信息，默认装到Program Files，卸载时如果勾选删除配置，可能把你好不容易调好的 server.xml 也一起删了。zip 包则是一个纯手工的压缩包，解压到哪里都可以用，删除时直接删目录，不残留注册表项。
我坚持用 zip 包还有一个原因：多版本共存。接手老项目时，生产环境可能是 7.0.103，本地开发还要装 8.5 来对比新代码。用 zip 包可以同时解压两份，通过CATALINA_HOME切换；用安装版则两个版本的服务容易互相抢占环境变量。当然 zip 包没有图形化托盘工具，也没有自动注册服务的向导，多用命令行而已。对于要写自动化脚本的人来说，命令行远比图形界面友好。如果你的生产环境有安全基线，双击安装版很可能被安全软件拦一道，而 zip 包解压后直接放在指定目录，反而更可控。
3. 核心配置：server.xml 和 web.xml 的必改项
3.1 端口与连接器：8080、8005、8009 的分工
conf/server.xml是 Tomcat 的全局配置核心。打开后，你会看到这几个默认节点在听端口：
<Server port="8005" shutdown="SHUTDOWN">：这是 Tomcat 自己的关闭端口。它只负责接收本机的 SHUTDOWN 指令，不对外提供服务。很多人以为这是安全漏洞，其实只要不绑定到0.0.0.0，问题不大。<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />：对外 HTTP 端口，也是你浏览器访问的入口。<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />：AJP 协议端口，用于和 Apache/Nginx 集成。如果不用集成，建议直接注释掉这行，减少不必要的端口暴露。
日常改的最多的就是 8080。生产环境如果 80 端口被 IIS 或其他服务占用，你可以改到 8088、9090 都行。改完后要留意redirectPort="8443"，这个配置在访问受保护资源时，会把 HTTP 请求重定向到 HTTPS 的 8443 端口。如果你的 HTTPS 端口不是 8443，记得改成实际的。
修改端口示例：
<Server port="8005" shutdown="SHUTDOWN"> <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" maxThreads="300" URIEncoding="UTF-8" /> </Server>这里保留了默认 8080，但加了maxThreads和URIEncoding。connectionTimeout=20000是建立连接后等待请求数据的超时时间，单位毫秒，20 秒是 Tomcat 默认经验值。redirectPort=8443表示需要 HTTPS 时跳到哪个端口。改完端口后，不要忘了看 Windows 防火墙是否放行了新端口。我遇到过本地应用连着打开都正常，但外部访问不通，最后发现是防火墙拦了 8088，这个和 Tomcat 本身没关系。
3.2 URIEncoding 与 maxThreads：中文乱码和高并发水位线
中文乱码是 Tomcat 7 上被问得最多的问题之一。GET 请求里的中文参数，经过 URL 编码后传到服务器，Tomcat 解析 URL 时按什么字符集解，就由URIEncoding决定。Tomcat 7 默认是 UTF-8，但如果你维护过老项目，配置文件里很可能写的是URIEncoding="GBK"。这种配置在早期系统里能跑，但碰到前后端约定用 UTF-8 的新页面，中文参数就会变成一堆问号。
我的建议是统一改成 UTF-8：
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" maxThreads="300" minSpareThreads="50" acceptCount="200" URIEncoding="UTF-8" />注意URIEncoding只影响 URI 里的参数，也就是GET请求的查询字符串。POST 请求的参数编码在请求头Content-Type里声明，受request.setCharacterEncoding("UTF-8")控制，这两个别混为一谈。很多人在 POST 里乱码也去改URIEncoding，改了半天没用，原因是找错了方向。
maxThreads是连接器的线程池上限。Tomcat 每收到一个请求，就从线程池里取一个工作线程来处理。默认值 200 适合小团队内部系统，但对外服务在高峰期瞬间就会把线程池占满。线程不是越多越好，线程多了上下文切换成本高，内存占用也高。我给一个初步估算：如果你接口平均响应耗时 200ms，maxThreads=300的情况下，理论吞吐上限是 300/0.2=1500 QPS。如果响应耗时 1s，那 300 线程只有 300 QPS。所以调参前先看接口耗时，再看线程数，不要直接拍脑袋定 1000。
与maxThreads配套的还有minSpareThreads和acceptCount。minSpareThreads是最少保持的空闲线程数，Tomcat 启动时就会预热好，避免请求突然进来时来不及创建线程。acceptCount是等待队列长度，当线程池全忙时，新请求先排队，队列满了直接拒绝。如果系统经常报Connection refused，除了端口问题，还可能是acceptCount设太小导致队列满。
3.3 虚拟目录与 docBase：不重新打包也能挂应用
有时候你只是想把某个静态前端目录挂到 Tomcat 下，或者把一个还没打成 war 的模块临时跑起来。这时候不必频繁打包，可以用<Context>配置虚拟目录。推荐的做法是在conf\Catalina\localhost下新建一个 XML 文件，文件名对应虚拟路径名。比如我要访问/demo，就建一个demo.xml，内容如下：
<Context path="/demo" docBase="D:\projects\demo" reloadable="true" />Tomcat 会自动加载这个 XML。path是访问路径，对应浏览器里的http://localhost:8080/demo/。docBase是磁盘上的真实路径，可以是绝对路径。reloadable="true"表示监控类文件变化，开发时改 JSP 不用重启，但生产环境不建议开启，因为 Tomcat 要定期扫描文件更新时间，高并发下白白消耗 CPU。
如果非要把<Context>写进server.xml的<Host>里，也能生效，但改完必须重启才能加载。放在localhost目录下的方式好处是支持热部署，改完文件名或内容，Tomcat 会在几秒内自动加载。有一点要小心：docBase指向的目录如果放在webapps内，同时path又和 webapps 里的应用同名，会产生冲突。所以虚拟目录的docBase我一般放在webapps外面。
3.4 conf/web.xml 中的默认 Servlet 和 MIME：配置误区
conf/web.xml是全局公共配置文件，所有应用都会继承它。有人会在这里改默认 Servlet 的映射或者添加 MIME 类型，但我要提醒：这个文件尽量保持原样，因为它是 Tomcat 的“出厂设置”，升级或补丁时会整体覆盖。应用需要特殊配置时，在应用自己的WEB-INF/web.xml里覆盖，或者用META-INF/context.xml写容器相关配置。
默认 Servlet 负责处理静态资源。如果你发现某个目录下的.js、.css被当成下载而不是正常加载，原因多半是 MIME 类型没定义。conf/web.xml里自带几百个mime-mapping，覆盖常见类型。但如果你用了特殊的扩展名，比如.apk、.ipa，默认可能没有，这时用户在浏览器访问这个文件就会提示下载。最常见的是把.apk映射成application/vnd.android.package-archive：
<mime-mapping> <extension>apk</extension> <mime-type>application/vnd.android.package-archive</mime-type> </mime-mapping>注意，如果你把这个加在全局 web.xml，所有应用都会生效；如果只给某个应用生效，应该放在该应用的WEB-INF/web.xml里。另外，有些项目为了支持前端路由，把 default Servlet 的映射改成/<custom>，这会导致静态资源加载路径全乱，不到万不得已别去动 default 的 url-pattern。我见过最严重的翻车：有人把 default servlet 的readonly参数改成false，结果服务器上的静态文件能被人直接上传，这是安全漏洞级别的问题，绝对不要试。
4. 部署与启动：从 startup.bat 到多实例
4.1 手动启动与日志定位：窗口一闪而过不可怕
很多人第一次启动 Tomcat，双击startup.bat后屏幕一闪就没了，第一反应是“是不是坏了”。其实只是脚本执行完自动关闭了窗口，但如果你启动失败，错误信息也会一闪而过。正确的姿势是打开 cmd，切到 bin 目录，手动执行：
cd /d D:\apps\tomcat7\bin startup.bat这样窗口会停留，你能直接看到报错。如果错误信息不全，再去看日志文件。Tomcat 的日志按天滚动，命名如catalina.2025-04-05.log。启动失败时，重点关注日志里的SEVERE级别记录，常见的是端口绑定失败或者类加载异常。
另一个容易被忽略的现象是：Tomcat 进程起来了，但 HTTP 端口没监听。排查方法是netstat -ano | findstr 8080，如果根本没有输出，说明连接器初始化失败；如果有 LISTENING 行，说明 Tomcat 正常监听，问题可能在应用层。
手动启动还有一个好处，就是能直观看到JAVA_HOME指向的是哪个 JDK。有时候PATH环境变量里混入了另一个 JDK 的 bin 目录，导致java -version显示版本不对。记住，startup.bat优先使用JAVA_HOME，但如果你在命令行里又临时 set 过 PATH，它也可能被覆盖。遇到这种“玄学”问题，建议在catalina.bat的开头强制写死：
set JAVA_HOME=C:\jdk1.8.0_202这样不管外头 PATH 怎么变，Tomcat 启动用的就是你指定的 JDK。这属于“人肉锁版本”的做法，在交付现场特别管用。
4.2 安装成 Windows 服务：开机自启与权限
生产环境的服务器不可能每次重启后都让运维手动启动 Tomcat，必须装成 Windows 服务。Tomcat 7 自带了service.bat，先到 bin 目录下使用管理员权限打开 cmd，执行：
service.bat install Tomcat7这会把 Tomcat 注册成一个名为 Tomcat7 的服务。服务默认以 LocalSystem 账户运行，本地权限很大。如果应用需要访问网络共享盘，比如\\server\share\file，LocalSystem 往往没有权限，你需要在服务属性的“登录”选项卡里指定一个域账户或本机账户，并赋予相应权限。
卸载服务用：
service.bat remove Tomcat7如果服务正在运行，先net stop Tomcat7停掉再卸。我遇到过卸不掉的情况，最后发现是服务依赖的 jar 被某个进程锁住了。重启服务器，再执行卸载，一次成功。这说明 Windows 文件锁在服务卸载场景下也是个隐形坑。
安装为服务后，Tomcat 的日志输出位置不变，还是在logs目录。如果你想看服务模式下的控制台输出，那是看不到的，因为服务没有控制台。所以服务模式下调试问题更要依赖日志文件。
4.3 WAR 包部署与更新：先删目录再复制
部署 war 包最无脑的方式是直接复制到webapps。Tomcat 默认开启autoDeploy=true，会监视 webapps 目录，发现新的 war 包就自动解压部署。但有经验的运维都知道，升级应用时不能直接覆盖 war 包，因为 Tomcat 检测到 war 包变化后，会尝试增量更新，旧解压目录里残留的 class 文件和新 jar 混在一起，轻则功能错乱，重则启动失败。
我习惯的更新步骤是这样：
net stop Tomcat7 rd /s /q D:\apps\tomcat7\webapps\myapp copy /y D:\deploy\myapp.war D:\apps\tomcat7\webapps\ net start Tomcat7先把服务停掉，删掉旧的解压目录，再复制新 war，最后启动服务。这样每次部署都是全量重新解压，不会出现新旧文件混用的问题。如果你不想停服，也可以把 war 复制到 webapps 后，手动删除同名目录，Tomcat 会重新解压；但不停服期间，正在执行的会话可能被中断，所以核心系统还是建议走两步。
关于部署目录的位置：war 解压后的目录权限默认继承 Tomcat 进程的权限。如果你用 LocalSystem 启动，那么 webapps 里的文件可写可读，这可能带来安全隐患，因为任何应用如果被绕过鉴权，就能写文件。生产环境可以把webapps目录设置为只读（对运行账户），同时把上传目录单独映射到外部。
4.4 多实例配置：一份二进制，多个 CATALINA_BASE
有时候一台 Windows 机器要跑多个 Tomcat 实例，分别监听不同端口，部署不同的应用。如果每条路径都复制一份完整的 Tomcat 压缩包，浪费磁盘空间，升级时还要逐个改。Tomcat 提供的多实例方案是：共用一份CATALINA_HOME（bin 和 lib 目录），每个实例有自己的CATALINA_BASE（conf、logs、temp、webapps、work）。
先按实例建立目录：
mkdir D:\instances\app1\conf mkdir D:\instances\app1\logs mkdir D:\instances\app1\temp mkdir D:\instances\app1\webapps mkdir D:\instances\app1\work然后把主 Tomcat 的 conf 目录内容复制到 app1\conf 下，并修改它的server.xml端口，避免和主实例冲突。启动时指定CATALINA_BASE：
set CATALINA_HOME=D:\apps\tomcat7 set CATALINA_BASE=D:\instances\app1 D:\apps\tomcat7\bin\catalina.bat start注意这里CATALINA_HOME指向二进制，CATALINA_BASE指向实例。日志、临时文件、应用部署都在CATALINA_BASE下，所以两个实例互不干扰。多实例的坑主要在于：如果你忘记设置CATALINA_BASE，catalina.bat 默认会把CATALINA_BASE当成本目录，也就是和主实例共用，导致端口冲突或者配置交叉。我一般会在每个实例的 bin 目录下放一个setenv.bat，把这两个变量固定住，防止人工漏掉。
5. 避坑与常见问题：五个翻车现场
5.1 端口被占用：BindException 的定位方法
现象：启动日志出现java.net.BindException: Address already in use，Tomcat 退出。
原因：8080 端口被其他进程占用。常见的“嫌疑犯”有 IIS、另一个 Tomcat、开发工具的内置服务器、甚至某些杀毒软件的内部代理。
解决：用netstat查端口对应的 PID，再用tasklist查进程名。
netstat -ano | findstr :8080 tasklist /FI "PID eq 1234"netstat输出第 5 列就是 PID，tasklist可以反查进程名。如果是无关进程，taskkill /F /PID 1234强制结束；如果舍不得杀，就改 Tomcat 的监听端口。改完端口后，记得去 Windows 防火墙“入站规则”里放行新端口。有一种特殊情况：netstat显示端口没有进程监听，但启动还是报占用，这可能是端口被 HTTP.sys 服务占用，比如 IIS 的 HTTP 服务。这种要用netsh http show servicestate进一步查看，不建议硬杀，直接换端口最省心。
5.2 JDK 版本不匹配：UnsupportedClassVersionError
现象：应用部署后，首次访问页面报UnsupportedClassVersionError，日志里还会打出类似class file has wrong version 52.0的提示。
原因：class 文件是 JDK 8（major 52）编译的，但 Tomcat 运行在 JDK 7（major 51）上。低版本 JRE 无法加载高版本编译的类。
解决：先用javap查看 class 文件的版本：
javap -verbose 你的类名.class | findstr majormajor version: 52对应 JDK 8，51对应 JDK 7，50是 JDK 6。确认后，要么升级JAVA_HOME到匹配版本，要么让开发重新用低版本编译。生产环境里升级 JDK 是个受控操作，但为了跑老项目，很多时候只能装双 JDK，按实例切换。注意：改了JAVA_HOME后，Windows 服务的 PATH 是随服务启动时读取的，必须重启服务才生效。
5.3 CATALINA_HOME 没生效：环境变量设置细节
现象：执行startup.bat提示The CATALINA_HOME environment variable is not defined correctly，但你在系统设置里明明配了CATALINA_HOME。
原因：三种可能。一是环境变量设置后没有重开命令窗口；二是变量值里末尾有空格或引号；三是用了D:\apps\tomcat7\这种带反斜杠的写法，Windows 一般能容忍，但某些脚本会拼出双斜杠。
解决：打开一个新 cmd，执行：
echo %CATALINA_HOME%如果输出为空或多出空格，说明变量没配对。也可以临时用 set 指定，但只对当前窗口生效。如果确认系统变量没问题，再检查是不是被其他脚本覆盖了。Tomcat 支持在catalina.bat中使用set CATALINA_HOME=...如果在某个环境变量加载脚本里写死了另一个路径，那你设的系统变量会被无视。排查时可以临时在 catalina.bat 开头加一行set CATALINA_HOME=D:\apps\tomcat7，强行指定。
5.4 中文乱码与中文路径：编码玄学
现象：页面显示正常，但通过 URL 传递的中文参数变成%E4%BD%A0%E5%A5%BD或者乱码。另一种情况，应用放在中文路径下，访问时 404，但代码检查没问题。
原因：第一，GET 参数乱码是 Tomcat 解码 URI 的字符集和应用期望的字符集不一致。第二，中文路径让docBase的绝对路径在文件系统层被转码，Tomcat 内部在解析静态资源时可能会找不到。
解决：连接器上设置URIEncoding="UTF-8"，这是最常见的修正手段。但注意，如果 Tomcat 后还有一层反向代理，代理在转发请求时也可能改编码，要从前到后统一字符集。中文路径的问题，最干脆的办法是不要用中文目录。项目代码里的虚拟目录配置也全部改成英文路径，再在操作系统中做目录符号链接，把中文目录指向英文别名。
还有一种乱码容易被忽略：JSP 本身编码不对。JSP 文件头如果没有声明pageEncoding="UTF-8"，Tomcat 会按默认的 ISO-8859-1 读取文件，文件里的中文字符直接变“锟斤拷”。检查方法是在 JSP 第一行写上：
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" %>5.5 老版本安全漏洞：CVE 扫描绕不过怎么办
现象：安全扫描工具对 Tomcat 7.0.103 报出多个 CVE，比如信息泄露、拒绝服务之类的条目。
原因：Tomcat 7 已经停止维护，官方不再发布安全补丁。7.0.103 作为 7.0 系列的后期版本，虽然修复了前面不少问题，但后续发现的漏洞没有“解药”。这是老版本共命运的结局。
解决：在不能升级的情况下，只能缓解风险。第一步，禁用 AJP 端口。很多 Tomcat 7 漏洞都是 AJP 协议相关的，如果没用过 Apache 集成，直接注释<Connector port="8009" .../>。
第二步，隐藏版本信息。默认错误页面会泄露 Tomcat 版本号，攻击者可以据此定向扫描漏洞。在 server.xml 的<Host>中添加：
<Valve className="org.apache.catalina.valves.ErrorReportValve" showReport="false" showServerInfo="false" />第三步，限制管理端口和 8080 的访问来源，在防火墙层面只允许内网访问。第四步，定期检查 webapps 里有没有未知文件，防止被上传过 webshell。数据文件备份要随时可用，一旦被入侵，至少能快速恢复。
不过要清醒一点：这些都是止血手段，不可能让老版本变成安全的。如果系统还能改架构，尽早安排升级到 Tomcat 9，哪怕做一次小改造，长远看也比在 CVE 列表上裸奔强。
6. 进阶：一条 PowerShell 命令体检 Tomcat 7 健康状态
分享一个我投产前必跑的体检脚本。与其每次改完配置手动开浏览器看首页，不如让脚本替你做四件事：检查端口监听、检查进程存活、检查启动日志、请求一次自带首页。
$port = 8080 $tomcat = "D:\apps\tomcat7" $url = "http://127.0.0.1:$port/" $listener = netstat -ano | findstr ":$port" | findstr "LISTENING" if ($listener) { Write-Host "[OK] Port $port is listening" } else { Write-Host "[FAIL] Port $port not listening"; exit 1 } $proc = Get-Process -Name "tomcat7" -ErrorAction SilentlyContinue if ($proc) { Write-Host "[OK] Tomcat process running, PID: $($proc.Id)" } else { Write-Host "[FAIL] No tomcat7 process"; exit 1 } $log = Get-ChildItem "$tomcat\logs\catalina.*.log" | Sort-Object LastWriteTime -Descending | Select-Object -First 1 if (Select-String -Path $log.FullName -Pattern "Server startup in") { Write-Host "[OK] Startup completed at $($log.LastWriteTime)" } else { Write-Host "[WARN] No startup marker found. Check $($log.FullName)" } try { $resp = Invoke-WebRequest -UseBasicParsing -Uri $url -TimeoutSec 10 Write-Host "[OK] HTTP $($resp.StatusCode)" } catch { Write-Host "[FAIL] Request failed: $($_.Exception.Message)" exit 1 }脚本第一行定义端口。如果改了 Tomcat 的 8080，这里要对应改。netstat -ano | findstr ":$port" | findstr "LISTENING"用来精确匹配指定端口正在监听的状态，避免被 TIME_WAIT 的残留干扰。Get-Process -Name "tomcat7"对应服务模式下的进程名；如果是手动启动的startup.bat，进程名是java，要改成java。日志检查里，Server startup in是 Tomcat 完整启动成功的标志，如果日志里没有这句话，说明还在部署应用或者启动中途失败。最后用Invoke-WebRequest请求首页，确认 HTTP 返回 200，而不是只停留在“进程活着”。
在 Windows 计划任务里加上这个脚本，每 5 分钟跑一次，失败就发邮件，这样我不用等用户投诉，就能提前发现问题。这个脚本也是有边界的：它只能检测 HTTP 是否响应，不能检测内存泄漏和线程池异常。如果某段时间响应变慢，还要看 JVM 的 GC 日志。我在生产环境还会额外设置jstat采集Full GC次数，超过警值就触发健康检查失败。从那以后，每次改完 server.xml，我都会强制跑一遍体检脚本再加一键发布。希望帮到你。
本文还有配套的精品资源，点击获取
