前言
做 Java Web 项目时，我以前最容易停在“本机能打开”这一步：JDK 装好了，Tomcat 也启动了，8080 页面能访问，看起来一切正常。但只要同事离开同一局域网，或者自己想用手机测试，那个 localhost 和内网 IP 就突然失去了意义。
这次我把整条链路从头走了一遍：先在 CentOS 7 上安装 OpenJDK 11，再单独创建 tomcat 用户，上传并解压 Tomcat 10.1.9，启动后确认默认页面可以访问。为了验证 ROOT 应用确实在工作，我还直接修改了 index.jsp，重启后再看页面变化。
本地部分跑通以后，再把 Tomcat 的 8080 页面带到外部网络，先用随机地址验证，最后切到固定二级子域名。
这篇重点不是追求“5分钟上线”，而是把 Java 运行环境、Tomcat 用户、ROOT 页面、8080 访问和外部入口之间的关系讲清楚。
另外，源配置里还有一处 xport JAVA_HOME=... 的疑似拼写错误，我会保留代码不动，但正文会明确提醒，避免读者机械复制后卡在环境变量这一步。
这种文章如果只写成“安装Tomcat教程”，其实会浪费掉后半段最有价值的部分。真正有用的是把“本地服务为什么只有自己能看、为什么同事回家后就访问不到、8080又是怎样被带到外部网络”串成一条完整链路。这样以后换成自己的Java项目、API或者测试页面时，思路也能直接复用。
1 先把这篇真正要跑通的链路看明白
这篇其实分成四层：
- Java 运行环境；
- Tomcat 应用服务器；
- ROOT Web 页面；
- 外部浏览器访问入口。
也就是：
OpenJDK 11 → Tomcat 10.1.9 → ROOT应用 → 8080 → 外部访问
如果前面某一层没跑通，后面再配公网入口也没有意义。
2 先检查CentOS 7上有没有Java
先查询已安装包：
rpm -qa | grep java
如果没有，再查询 yum 中可用的 Java 11：
yum list | grep java-11
这里使用的是 OpenJDK 11。
3 安装OpenJDK 11
执行：
yum install -y java-11-openjdk-headless-11.0.13.0.8-1.el7_9.x86_64 java-11-openjdk-11.0.13.0.8-1.el7_9.x86_64 java-11-openjdk-devel-11.0.13.0.8-1.el7_9.x86_64
安装完成以后检查版本：
java --version
能正常返回 Java 版本，说明运行环境已经基本准备好。
4 配置JAVA_HOME环境变量
编辑：
vim /etc/profile
在文件最后加入：
xport JAVA_HOME=/usr/lib/jvm/java-11-openjdk-11.0.13.0.8-1.el7_9.x86_64
export JRE_HOME=$JAVA_HOME
export CLASSPATH=.:$JAVA_HOME/lib:$JRE_HOME/lib:$CLASSPATH
export PATH=$JAVA_HOME/bin:$JRE_HOME/bin:$PATH
这里需要特别提醒一处。
第一行写的是：
xport JAVA_HOME=...
从语法看，这里很可能应该是：
export JAVA_HOME=...
但为了保持现有技术内容不被擅自改动，代码块仍然原样保留。
真正执行时，如果 JAVA_HOME 没有生效，应该首先检查这一行拼写。
5 让环境变量生效
执行：
source /etc/profile
然后检查 Java 路径：
whereis java
到这里，Java 环境这一层基本完成。
6 下载Tomcat 10安装包
接下来进入 Tomcat 部署。
源操作下载的是 Tomcat 10.1.9。
下载页面：
继续选择：
现有操作里把它称为“最新版 Tomcat 10”。
这个说法具有时效性。
更准确的写法应该是：
本文演示版本为 Tomcat 10.1.9。
实际下载时，应以自己准备使用的版本为准。
7 给Tomcat单独创建系统用户
切到 root 后执行：
useradd tomcat
设置密码：
passwd tomcat
然后切换到 Tomcat 用户：
su - tomcat
这个做法比直接长期用 root 运行 Tomcat 更合理。
至少在账号层面把应用服务和系统最高权限分开了。
8 把安装包上传到Tomcat用户目录
源操作把：
apache-tomcat-10.1.9.tar.gz
上传到：
/home/tomcat/
上传完成：
9 解压Tomcat
执行：
tar -zxvf apache-tomcat-10.1.9.tar.gz
然后改名：
mv apache-tomcat-10.1.9 tomcat
最终目录变成：
/home/tomcat/tomcat
这样后面脚本路径更短，也更容易记。
10 启动Tomcat
进入目录并启动：
cd tomcat/
bin/startup.sh
如果脚本正常执行，Tomcat 会在后台启动。
接下来应该从浏览器确认页面。
这里真正验证的是：
Java环境 + Tomcat启动 + 8080页面
都已经工作。
11 停止Tomcat
需要停止时执行：
bin/shutdown.sh
这条命令和 startup.sh 对应。
学习和调试阶段经常会用到。
12 不只看默认页，再改一次ROOT应用验证
如果一直只看到 Tomcat 默认页，很容易把“服务器启动”和“自己的 Web 应用能工作”混在一起。
所以这篇继续进入：
cd /home/tomcat/tomcat/webapps/ROOT
Tomcat 默认 ROOT 应用就在这里。
13 页面文字在index.jsp里
默认页面主要入口：
index.jsp
样式文件则包括：
tomcat.css
这篇实际做的是修改首页文字。
14 修改index.jsp
执行：
vi index.jsp
然后在页面文字里加入内容：
修改以后回到 bin 目录重启 Tomcat：
重启后页面发生变化：
这一步很重要。
它证明：
当前访问的不是单纯的 Tomcat 服务状态页，而是 ROOT Web 应用内容确实被修改并重新加载。
15 这篇其实没有部署独立WAR包
虽然标题很容易写成“部署 Web 应用”，但正文实际没有演示：
- 上传独立
.war文件； - 自定义 Context；
- 独立项目目录；
- Tomcat Manager 部署；
- Maven / Gradle 打包。
实际做的是：
修改 Tomcat 自带 ROOT 应用中的 index.jsp。
所以更准确的定位是：
Tomcat 基础部署 + ROOT 页面修改 + 外部访问。
如果后面要部署真正的 Java Web 项目，可以继续把 WAR 包放入 webapps，或者配置独立应用目录。
16 本地能打开，不代表外部网络能访问
在同一局域网里，Tomcat 可以通过：
http://服务器IP:8080
访问。
但同事回家以后，这个内网 IP 通常就不可达了。
这也是后半部分要解决的问题。
17 安装cpolar
执行：
sudo curl https://get.cpolar.sh | sh
安装完成以后检查服务：
sudo systemctl status cpolar
然后通过：
服务器IP:9200
进入 Web UI：
后面的隧道都在这里配置。
18 给Tomcat的8080创建随机公网入口
进入：
隧道管理 → 创建隧道
参数：
- 隧道名称：
tomcat - 协议：
http - 本地地址：
8080 - 域名类型：随机域名
- 地区：
China Top
创建以后查看在线隧道：
复制公网地址测试：
页面能够从外部网络打开以后，说明：
外部浏览器 → 公网地址 → cpolar → CentOS 7:8080 → Tomcat ROOT应用
这条链已经跑通。
19 远程演示最适合这种临时入口
如果只是：
- 给同事看一下页面；
- 测试手机端；
- 做课堂演示；
- 临时联调；
随机公网地址已经足够。
这种场景不一定需要先买云服务器、配置域名、Nginx 和证书。
但这并不意味着它适合直接替代正式部署。
20 长期访问再配置固定二级子域名
进入预留页面：
示例名称使用：
tomcat
然后进入隧道列表，找到 tomcat：
修改：
- 域名类型：二级子域名；
- Sub Domain：填写预留名称；
- 地区：
China Top。
更新：
查看在线隧道：
最后使用固定地址访问：
页面可以正常打开以后，固定入口配置完成。
具体套餐、固定地址规则和使用条件可能变化，应以实际账号页面为准。
21 “固定地址”不等于“生产级上线”
这一点很容易被标题带偏。
现在已经做到的是：
Tomcat页面有一个长期可记的外部访问入口。
但正式生产环境通常还会继续考虑：
- HTTPS 与证书策略；
- Nginx / Apache 反向代理；
- 防火墙；
- Tomcat 用户权限；
- 日志；
- JVM 参数；
- 进程托管；
- 自动重启；
- 应用备份；
- 安全更新；
- 访问认证；
- 数据库安全。
所以本文更适合：
学习、测试、开发联调和临时演示。
22 8080公开以后，最该检查的是暴露范围
如果只是展示一个 ROOT 首页，风险相对容易控制。
但如果 Tomcat 里还有：
- Manager；
- Host Manager；
- 后台管理系统；
- 测试接口；
- 内部 API；
- 调试页面；
就不应该默认一起暴露给公网。
更合理的是：
只开放真正需要外部访问的服务。
应用负责业务。
cpolar负责网络入口。
23 这套链路适合什么场景
比较适合：
- Java Web 初学；
- Tomcat 安装练习；
- 本地页面临时展示；
- 手机测试；
- 同事远程查看；
- 小型联调；
- 课堂演示。
如果是正式线上业务，更推荐按照生产环境架构重新设计，而不是直接把开发用 Tomcat 8080 暴露出去。
24 整条链路回头看
本地部分：
CentOS 7 → OpenJDK 11 → Tomcat 10.1.9 → ROOT应用 → 8080
远程部分：
外部浏览器 → 公网地址 → cpolar → 8080 → Tomcat
真正有价值的不是“几分钟上线”。
而是把：
Java运行环境、应用服务器、Web应用和网络入口
四层关系一次理清楚。
总结
这次从 OpenJDK 11 一直走到 Tomcat 的外部访问，我觉得最有用的不是“多快能上线”，而是终于把 Java Web 服务真正经过了几层说清楚：先有 Java 环境，再有 Tomcat，Tomcat 里还有具体 ROOT 应用，最后才轮到 8080 怎么被外部浏览器访问。
本地阶段不只启动了 Tomcat，还实际进入 webapps/ROOT 修改了 index.jsp，重启以后确认页面内容已经变化。这个验证比只看到默认欢迎页更有意义。
远程部分只是给 8080 增加网络入口。它适合学习、联调和临时演示，但不能因为固定地址能打开，就直接把它理解成完整生产部署。
如果后面继续往真正的 Java Web 项目走，下一步更值得做的是 WAR 包部署、systemd 托管、反向代理、HTTPS 和访问安全，而不是只停留在“页面能从公网打开”。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/leopold_man/article/details/167702222
