把war包放到服务器后，最快实现直接访问（即去掉项目名，通过域名或IP加端口直接打开）的方法是：将war包改名为ROOT.war后部署到Tomcat的webapps目录下，或通过修改Tomcat配置指向解压目录。
很多朋友在本地开发时直接把war包丢进Tomcat就能跑，但一上服务器就卡壳访问路径里总是带着一串项目名，又长又丑，本文不绕弯子，直接讲清楚war包部署后如何实现根路径访问，以及不同场景下的最优解,帮你少踩几个坑。
为什么你的war包访问路径总带着项目名
war包本质是一个Web应用的压缩归档，Tomcat检测到它后会自动解压并部署，默认情况下，应用上下文路径（Context Path）就是war包的文件名，比如你放的是demo.war，那访问地址就是http://IP:8080/demo/。
核心矛盾就在这个默认机制上，你希望访问的是http://IP:8080/，不想带任何前缀，这涉及到Tomcat的虚拟主机和Context配置逻辑,属于新手普遍头疼的环节。
明确war包访问失效的典型场景
- 简米云或酷番云服务器上，用
java -jar方式启动打包好的Spring Boot可执行war包,但访问404。 - 将war包上传到Tomcat webapps目录后,重启服务发现依然只能通过带项目名的路径访问。
- 配置了Nginx反向代理，转发到Tomcat端口后,发现静态资源加载404或JS报错。
这些问题的共同点在于：没有理清war包部署路径与外部访问路径之间的映射关系，下面给出三种可落地的方案,按推荐程度排序。
利用ROOT.war实现根路径直达
这是最直接、最省事的方式，适用于大多数单应用服务器场景，Tomcat把webapps/ROOT目录视为默认根路径，只要应用部署在这个上下文下,就能实现IP加端口直接访问。
具体操作步骤
- 将你的war包重命名为
ROOT.war（全大写），上传到Tomcat的webapps目录下。 - 删除原有的ROOT文件夹或旧版ROOT.war,避免冲突。
- 进入
bin目录，执行./shutdown.sh（Windows下是shutdown.bat）再执行./startup.sh重启。 - 浏览器访问
http://IP:8080/,预期看到应用首页。
这里有个细节值得留意：Tomcat启动时会优先处理同名war包和目录，如果旧ROOT目录存在且未清理，新war包可能不会覆盖解压。所以务必备份原ROOT内容，以防回滚需求，行业共识认为，这种做法在单应用VPS上效率最高，但如果一台服务器上需要部署多个应用（如/order和/user），ROOT.war方案就不适用了,得看方式二。
修改server.xml精准控制上下文路径
当服务器上跑多个应用，又不想让URL暴露端口或项目名时，推荐修改conf/server.xml中的Host标签,手动指定Context映射。
编辑conf/server.xml
找到<Host>标签内部，在</Host>前插入以下配置：
<Context path="" docBase="/opt/tomcat/webapps/demo" reloadable="true"/>
需要注意几个关键点：
path=""表示空路径,即根路径访问。docBase建议写绝对路径，指向解压后的war包目录,不要直接指向war包本身。- 如果war包尚未解压，Tomcat会在启动时自动解压，但
docBase最好提前指向解压后的目录名。
重启验证及常见坑
保存文件后重启Tomcat，如果域名和IP都指向这台服务器，那么http://你的域名:8080/就能直接打开应用，若遇到404,优先检查：
docBase路径是否写错,Tomcat对路径大小写敏感。- 原有的
webapps/ROOT目录是否还在,它会干扰空路径的Context映射。 - 是否配置了
autoDeploy="true"导致解压目录冲突。
这种方式对服务器配置有一定要求，但胜在灵活，比如你有一个老项目部署在webapps/order.war，想在同一个Tomcat下新增一个根路径应用，就可以用此方法实现共存，需要说明的是，修改server.xml后，建议同时检查conf/Catalina/localhost目录下有无同名xml文件，这些文件会覆盖server.xml的配置,优先级更高。
Nginx反向代理隐藏端口和项目名
生产环境大多采用Nginx做前端入口，将80端口请求转发到Tomcat，这样访问者只需输入域名,无需关心端口和war包名。
Nginx配置核心片段
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://127.0.0.1:8080/;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
此配置下，proxy_pass末尾的斜杠起到关键作用，它表示将路径直接映射到Tomcat的路径，不附加额外前缀，如果去掉这个斜杠，Nginx会保留完整的请求URI，导致Tomcat接收到的路径变成/demo/,访问又回到了原点。
处理静态资源路径问题
如果页面样式丢失或JS报404，多数是应用内的静态资源使用了绝对路径，比如项目里写了/static/css/style.css，而实际部署上下文为空，就会被Nginx拦截并转发到Tomcat，但Tomcat并不认识这个路径，解决办法是在Nginx中单独配置静态资源alias或root指向,或者将应用内资源路径改为相对路径。
对于Spring Boot嵌入式Tomcat打包的war包，还需要检查application.properties中server.servlet.context-path是否被设置为，否则即使外部代理配置正确,应用自身也会拼出错误路径。
war包访问不了的排查思路和操作清单
遇到“war包放到服务器下怎么直接访问”这个问题，往往不是单一原因造成的，业内专家指出，多数部署失败集中在权限、端口和路径三个方面。
快速排查清单
- 确认Tomcat进程是否有权限读取war包所在目录，特别是使用
/root或/home下自定义目录时,容易出现权限不足导致解压失败。 - 检查
logs/catalina.out日志，重点看Deploying web application archive这行日志后的异常堆栈。 - 确认服务器安全组和防火墙是否放行80或8080端口，简米云、酷番云等厂商的控制台需要单独设置。
- 如果采用ROOT.war方案，启动后访问直接404，执行
ls -l webapps/ROOT查看目录是否为空。
行为对比：三种方式怎么选
| 对比维度 | ROOT.war方案 | server.xml配置 | Nginx代理 |
|---|---|---|---|
| 适用于单应用部署 | 是 | 否（偏向多应用） | 是 |
| 是否需要重启频繁 | 每次替换war均需重启 | 修改配置需重启 | 仅重载nginx |
| 隐藏端口 | 否 | 否 | 是 |
| 处理多个Context共存 | 困难 | 容易 | 可配合server.xml |
| 运维复杂度 | 低 | 中 | 中高 |
结合目前主流云服务器部署模式，Nginx加Tomcat架构是最稳妥的，war包服务器直接访问问题，本质上是对Web容器映射机制的理解问题，只要掌握上面任何一种方式,都能覆盖绝大数部署场景。
常见问题快答
war包放到服务器下怎么直接访问，域名不显示项目名？
域名解析到服务器后，通过Nginx将80端口转发到Tomcat的8080端口，关键在于Nginx配置proxy_pass http://127.0.0.1:8080/;（注意尾部斜杠），同时Tomcat中war包改为ROOT.war或通过server.xml设置空Context路径,两者配合可以彻底去掉项目名。
部署到服务器后访问显示404，怎么快速判断问题？
先确认访问的是Tomcat默认页还是应用报错页，如果能看到Tomcat猫头页，说明Tomcat正常运行且端口可通，问题出在应用部署上，此时查看webapps内是否生成了与war同名的目录，若没有生成，检查启动日志中的解压报错,大多数情况是文件上传不完整或磁盘空间不足导致。
简米云服务器上war包项目访问慢，怎么优化？
云服务器上访问慢不一定是war包部署问题，先排除网络链路因素，应用中批量加载静态资源会拖慢首页加载，适当启用Tomcat的压缩传输（compression=”on”）和静态资源缓存有不错效果，同时检查是否开启了reloadable="true"，该配置会在每次访问时监测文件变化，消耗额外性能,生产环境请务必设为false。
把war包部署到服务器并实现直接访问，本身没有统一的标准答案，但核心逻辑是一致的：让Tomcat的空路径映射到你解压后的应用目录，无论采用ROOT.war还是修改server.xml，都需要保证路径映射正确，第一次配置可能卡壳，将日志和配置文件对照研究就能解决，理清映射关系之后,相关问题自然会迎刃而解。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/776869.html
