1. 为什么不用 yum 一键安装而要手动部署 JDK新拿到一台 Linux 服务器准备装个 JDK、跑个 Tomcat这本该是十分钟的小事。但如果你真在搜索引擎里翻过一轮教程就会发现事情没那么简单——有人让你用 yum 装 OpenJDK有人让你去官网下载带账号登录的安装包还有人直接丢给你一串神秘的环境变量配置代码复制过去却始终不生效。我这篇文章的定位很明确不需要你有任何前置经验照着做就能把 JDK 和 Tomcat 装上、启动、验证通过。而且我会把每一个关键步骤背后的“为什么”讲清楚让你不只是复制命令而是真正明白这条部署链路的逻辑。这样以后再换机器、换系统、换个 Java 版本你都能自己搞掂。先回答一个最基础的问题为什么我不推荐在服务器上直接用yum install java这类命令一步到位第一yum 装的 OpenJDK 版本往往跟着系统源走。CentOS 7 的默认源里通常只有 JDK 8Ubuntu 22.04 的源里默认是 JDK 11而这些版本可能和你本地开发环境、或者项目要求的版本对不上。你费半天劲装完一运行项目发现版本不对又得卸载重装麻烦得很。第二yum 安装会把你家目录、PATH 变量、软链接这些弄得一团乱。它装完的 Java 路径分散在/usr/lib/jvm、/usr/bin/java等多个位置你排查问题的时候根本不知道系统里到底有几份 Java哪份在生效。对于生产环境来说这种“不确定性”本身就是隐患。第三也是最关键的一点——手动部署是你真正理解这套服务运行机制的唯一途径。JDK 装在哪个目录、Tomcat 以哪个用户运行、配置了哪些环境变量、日志写到哪里这些信息在出问题的时候就是你排查的第一手线索。靠 yum 装的系统你连 JAVA_HOME 指向哪里都不清楚日志报错的时候只能干瞪眼。所以本文采用的方式是用 tar.gz 源码包手动部署到/opt目录手工配置环境变量用 systemd 或后台脚本托管 Tomcat 进程。这套方案在 CentOS 7/8、Ubuntu 20.04/22.04、以及各类国产系统上都能走通因为 JDK 解压出来就是一套二进制跟系统发行版没有强耦合。2. JDK 安装实录下载、解压、环境变量与验证一条龙2.1 选择哪个 JDK 版本JDK 8 还是 JDK 17在动手指安装之前先想清楚版本问题。很多老项目到现在还跑在 JDK 8 上因为 Spring Boot 2.x、老版本的 Tomcat、一些第三方依赖对 JDK 8 的兼容性最好。而新项目如果是 Spring Boot 3.x最低要求就是 JDK 17JDK 8 连启动都不给启动。我的建议很简单如果是维护现有系统跟项目要求走项目说 JDK 8 就装 JDK 8。如果是全新部署、没有历史包袱直接 JDK 17 起步。JDK 17 是长期支持版本性能、GC、安全特性都比 JDK 8 强一大截且 Spring Boot 3.x 和 Tomcat 10 对它的支持已经非常稳定。JDK 21 也是 LTS但生态适配度还在爬坡期除非项目明确要求否则没必要追新。下文以 JDK 8 为例因为这套配置兼容性最广。JDK 17 的安装流程完全一样只是压缩包文件名和JAVA_HOME路径里的目录名不同照着替换即可。2.2 从哪下载 JDK 包JDK 的下载渠道有三个优先级从高到低Oracle JDK 官网oracle.com/java/technologies/downloads/—— 官方原版但要接受 Oracle 的许可协议下载前需要勾选确认框某些版本还需要登录账号。胜在权威、补丁及时。Adoptium / Eclipse Temurinadoptium.net—— OpenJDK 的社区发行版免费、无需登录、提供 JDK 8/11/17/21 全版本。生产环境用这个渠道很稳很多云厂商的默认 Java 镜像就基于它。国内镜像源—— 如果你不想访问官网下载或者官网速度太慢直接用华为云、腾讯云、阿里云的镜像站。以华为云为例repo.huaweicloud.com/java/jdk/下有8u202等多个版本的 Linux x64 压缩包直接 wget 就行速度和稳定性比官网好很多。从镜像站下载时注意后缀为tar.gz的是我们要的文件后缀为.rpm的是给 RedHat 系系统用的安装包.deb是给 Debian 系用的。我们手动部署的目标是解压即用所以认准tar.gz。2.3 解压、目录规划与软链接拿到压缩包后先规划安装位置。我习惯把所有中间件统一放在/opt下结构如下/opt/jdk/ # JDK 安装根目录 /opt/tomcat/ # Tomcat 安装根目录 /opt/logs/ # 业务日志统一目录这样做的理由是/opt是 Linux 里专门放第三方软件的目录权限清晰、不易误删把所有 Java 相关的东西聚拢到一起后续做备份、迁移、权限管控都方便。# 1. 创建目录并解压 mkdir -p /opt/jdk tar -zxf jdk-8u202-linux-x64.tar.gz -C /opt/jdk/ # 2. 查看解压出来的目录名 ls /opt/jdk/ # 通常得到一个类似 jdk1.8.0_202 的目录 # 3. 建立版本无关的软链接 ln -s /opt/jdk/jdk1.8.0_202 /opt/jdk/current这个软链接非常重要。以后你想升级 JDK只要把新版本解压到/opt/jdk下、把current重新指向新目录、重启服务即可环境变量完全不用动。这是运维上的“解耦”思想——代码不直接依赖具体版本而是依赖一个稳定的入口。2.4 环境变量配置的完整链路环境变量配置是新手最容易翻车的地方。网上一搜教你改/etc/profile、改~/.bashrc的都有甚至还有人把配置写进了/etc/environment。到底改哪个我的建议是统一写到/etc/profile.d/java.sh。原因很简单/etc/profile是所有用户登录时都会加载的全局配置但它本身明确注释了“尽量不要改动”因为它还负责调用/etc/profile.d/下的所有脚本。~/.bashrc只对当前用户生效如果你用 root 配好了环境变量换一个业务用户su过去java 命令直接找不到你又要排查半天。/etc/profile.d/下放一个独立脚本既是全局生效又不污染主配置文件删掉这个文件就等于完全卸载环境变量配置干净利落。创建/etc/profile.d/java.sh内容如下# JDK 环境变量配置 export JAVA_HOME/opt/jdk/current export PATH$JAVA_HOME/bin:$PATH export CLASSPATH.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar逐行解释一下JAVA_HOME这是整个 Java 生态的“根”Tomcat、Maven、Gradle、Jenkins 这些工具都会靠它找到 JDK。PATH把$JAVA_HOME/bin放在最前面是为了让系统优先使用我们指定的这个 JDK而不是系统自带的旧版 Java。这点极其关键很多人明明配好了 JAVA_HOME但敲java -version出来的还是老版本就是因为 PATH 里别的 java 排在了前面。CLASSPATHJDK 9 之前最好显式配一下JDK 9 之后官方已经不推荐配了。这里写上是为了兼容那些还需要tools.jar的老工具。注意最前面的.代表当前路径让 JVM 能找到当前目录下的 class 文件。配置完成后让环境变量立即生效source /etc/profile.d/java.sh然后验证java -version # 输出类似java version 1.8.0_202 echo $JAVA_HOME # 输出/opt/jdk/current到这一步JDK 就算装好了。2.5 验证环境变量是否真正写入系统很多帖子到java -version能输出版本号就收工了但这不够严谨。你还要确认两件事第一重启后环境变量是否仍然生效。source只是让当前 shell 临时读取了一次真正的验证是退出终端、重新登录甚至重启服务器后再敲java -version。如果还能输出说明配置写进了登录脚本链路里。第二换成别的用户是否也能找到 java。用业务运行用户比如后面的tomcat用户登录再敲一次java -version。这一步能确保你通过 systemd 或脚本启动 Tomcat 时进程能拿到正确的环境变量。很多事故就发生在这一步——root 下一切正常一切换到普通用户启动服务就报Cannot find JAVA_HOME。这里补一个最容易踩的坑如果你修改了/etc/profile.d/java.sh但当前终端已经开着你需要重新登录或手动source才能生效。那些“配置了环境变量却不生效”的求助帖一半是这个问题。重启服务器验证是最省心的如果不想重启至少确保新开的 SSH 会话里测试通过。3. Tomcat 部署与启动目录规划、端口检查和日志排查3.1 Tomcat 版本怎么选和 JDK 版本强相关Tomcat 的版本选择和 JDK 版本是强绑定的关系。选错了最典型的报错就是在 Tomcat 启动日志里看到UnsupportedClassVersionError意思是 class 文件版本号高于当前 JVM 能支持的版本。直接给结论Tomcat 主版本支持的最低 JDK适用场景Tomcat 8.5JDK 7老项目维护JDK 8 环境下的经典组合Tomcat 9.xJDK 8最广泛的生产组合配 JDK 8/11 都很稳Tomcat 10.0/10.1JDK 8建议 JDK 11适配 Servlet 6.0配 JDK 17 是新项目的常见组合如果你用的 JDK 8那装 Tomcat 9.x 最省心它是目前兼容性最广、踩坑最少的选择。如果你配的是 JDK 17用 Tomcat 10.1。注意Tomcat 10 之后把包名从javax.*改成了jakarta.*如果你的项目代码还在用javax.servlet的旧依赖部署到 Tomcat 10 上会直接 404 或启动报错这是从 Tomcat 9 升到 10 时最需要警惕的差异。下载地址就是 Apache 官网tomcat.apache.org进入下载页面后选tar.gz格式的那个链接。也可以直接走国内镜像比如清华镜像mirrors.tuna.tsinghua.edu.cn/apache/tomcat/速度快且稳定。3.2 创建专用运行用户为什么不能用 root 跑 Tomcat这一步是安全底线。很多新手图省事直接用 root 去startup.shTomcat 确实能跑起来但这等于把 web 服务以最高权限暴露在网络上。一旦应用有漏洞被利用攻击者拿到的是 root 的 shell整个服务器就沦陷了。正确做法是创建一个专用于运行 Tomcat 的系统用户useradd -r -s /sbin/nologin tomcat参数解释-r创建系统账户不分配家目录、不打算让它登录。-s /sbin/nologin禁止该用户通过 shell 登录系统。它只用来跑服务进程不能被人顺藤摸瓜进入系统。然后把 Tomcat 所有文件的属主改给这个用户chown -R tomcat:tomcat /opt/tomcat/注意如果你以 root 身份解压了 Tomcat文件属主就是 root。不改成 tomcat 用户的话Tomcat 进程将没有权限往logs/、work/、temp/目录写数据启动时会报Permission denied或者启动了但日志没法落盘。3.3 目录结构速览至少认识这四个目录Tomcat 解压后大概长这样/opt/tomcat/apache-tomcat-9.0.87/ ├── bin/ # 启动、关闭脚本 ├── conf/ # server.xml、context.xml 等核心配置 ├── logs/ # 所有日志输出目录 ├── temp/ # 临时文件 ├── webapps/ # 部署 web 应用的目录 ├── work/ # JSP 编译后的 class 文件 └── lib/ # Tomcat 自身的依赖库你需要重点记住的是前四个bin、conf、logs、webapps。后面排查问题时你 90% 的时间都在这四个目录之间来回跑。特别是logs/下有两个文件要分清catalina.out标准输出和错误输出Tomcat 启动的大部分异常堆栈都打在这里排查启动失败第一个看它。localhost.log记录请求处理过程中的异常尤其适合排查运行时抛出的ClassNotFoundException、NoSuchMethodError这类错误。3.4 启动前的检查清单端口、内存、JDK 路径在敲startup.sh之前先花一分钟做三个检查能帮你避免 80% 的启动失败。第一检查 8080 端口是否被占用ss -lntp | grep 8080如果有输出说明端口已经被别的进程占了。最常见的情况是之前部署过一次 Tomcat进程还在跑着你没注意直接启动新的实例然后发现服务起不来日志里报Address already in use。遇到这种情况要么先杀掉旧进程要么在server.xml里改端口。切忌两台 Tomcat 挤同一个端口。第二确认当前用户的 PATH 里能找到 javawhich java如果没输出说明 2.4 节的环境变量没配好此时就算直接启动Tomcat 的启动脚本也会在检查 JAVA_HOME 的环节报错退出。第三确认系统内存足够free -hTomcat 默认的 Java 堆内存是 256MB新版本的启动脚本根据机器自动调整但保守起见先看一眼如果机器本身只有 512MB 内存装完操作系统后剩 200MBTomcat 启动会非常勉强。建议至少保证 1G 以上可用内存生产环境 4G 起步。3.5 正式启动与二次验证不要只看“Tomcat started”启动命令很简单cd /opt/tomcat/apache-tomcat-9.0.87/bin ./startup.sh看到Tomcat started.只代表启动脚本执行了不代表 Tomcat 真的启动成功了。必须做以下三个验证# 1. 看进程是否存在 ps -ef | grep tomcat # 2. 看端口是否监听 ss -lntp | grep 8080 # 3. 看首页能否访问 curl -I http://127.0.0.1:8080curl返回HTTP/1.1 200才算是真正成功了。如果看到Tomcat started但端口没监听基本可以断定启动过程中出了异常——别慌下一节就是讲怎么排查的。3.6 快速定位启动失败三个日志帮你找出真相遇到启动失败第一反应不该是搜报错关键字而是按顺序看三个东西先用tail看catalina.out的最后 30 行。这里写的报错信息一般已经能说明大部分问题比如端口被占java.net.BindException: Address already in useJDK 版本对不上java.lang.UnsupportedClassVersionError堆内存不足Could not reserve enough space for object heapJDK 路径找不到Neither the JAVA_HOME nor the JRE_HOME environment variable is defined如果catalina.out没有明确报错再看logs/localhost.log——这里记录了 webapp 部署阶段的失败原因比如解压目录权限问题、web.xml 配置错误。最后看logs/catalina.2025-xx-xx.log这是按天滚动的日志一些老问题会被覆盖这里能看到更完整的历史轨迹。排查完问题、修好后记得先关掉旧进程再重新启动./shutdown.sh # 若 shutdown.sh 都起不来说明进程已经僵死直接 kill kill -9 $(ps -ef | grep tomcat | awk {print $2})kill -9是最后手段尽量先让 Tomcat 自己优雅退出避免正在处理的请求被硬生生打断。4. 生产环境进阶systemd 托管、JVM 参数与 JMX 监控配置到这里用startup.sh启动的 Tomcat 已经能正常服务了。但如果你只是这么做一旦服务器重启Tomcat 不会自动拉起来——你得手动进终端再敲一次startup.sh。这对一个真正的服务来说是致命的。4.1 用 systemd 把 Tomcat 变成开机自启服务CentOS 7、Ubuntu 16.04 之后Linux 主流发行版都使用systemd管理系统服务。我们可以把 Tomcat 的启动和关闭指令封装成一个 service 文件让系统自动接管进程的启停、崩溃重启、开机自启。创建文件/etc/systemd/system/tomcat.service[Unit] DescriptionApache Tomcat 9 Web Application Container Afternetwork.target [Service] Typeforking Usertomcat Grouptomcat EnvironmentJAVA_HOME/opt/jdk/current EnvironmentCATALINA_PID/opt/tomcat/tomcat.pid EnvironmentCATALINA_HOME/opt/tomcat/apache-tomcat-9.0.87 EnvironmentCATALINA_BASE/opt/tomcat/apache-tomcat-9.0.87 ExecStart/opt/tomcat/apache-tomcat-9.0.87/bin/startup.sh ExecStop/opt/tomcat/apache-tomcat-9.0.87/bin/shutdown.sh Restarton-failure [Install] WantedBymulti-user.target几个关键点解释一下Typeforking表示启动脚本会 fork 出一个子进程常驻后台systemd 认为这个子进程是服务主体。User和Group指定了以tomcat用户身份运行这延续了 3.2 节的安全策略。CATALINA_PID指定了 PID 文件路径这样systemctl stop能精确找到主进程并优雅停止。Restarton-failure是生产环境的保命配置——进程意外崩溃时 systemd 会自动把它拉起来。配置完成后依次执行systemctl daemon-reload systemctl enable tomcat systemctl start tomcat systemctl status tomcat如果status显示active (running)你再重启一次服务器验证自启是否生效。这一步实测不能省因为 systemd 的 service 文件写错一点比如路径拼写错误、权限不对开机后服务就是起不来等你真正需要的时候才发现就晚了。4.2 JVM 参数怎么设堆内存、元空间与 GC 配置默认情况下Tomcat 的 JVM 使用系统自动探测的堆大小但这往往不是最优配置。生产环境必须显式指定JAVA_OPTS否则并发一上来GC 频繁、内存不足服务就卡死了。在bin/catalina.sh里找到设置JAVA_OPTS的位置加一行JAVA_OPTS-Xms2048m -Xmx2048m -XX:MetaspaceSize512m -XX:MaxMetaspaceSize512m -XX:UseG1GC -Djava.security.egdfile:/dev/./urandom逐项拆解-Xms2048m和-Xmx2048m都设为 2G堆内存初始值和最大值一致。这样做的目的是避免 JVM 在运行中动态扩缩容内存——扩缩容是要停顿的会引发性能抖动直接固定大小更稳定。-XX:MetaspaceSize512m元空间存的是类元数据老项目加载的类多设太小会频繁触发 FullGC。-XX:UseG1GCJDK 8 之后 G1 是默认垃圾回收器JDK 8 的默认是 Parallel GC需要显式打开它在堆 2G 以上的场景下延迟更平滑。如果你用的是 JDK 11默认就是 G1这行可以省略。-Djava.security.egdfile:/dev/./urandom这是个经典优化。Java 的SecureRandom在某些系统上会阻塞等待熵源导致 Tomcat 启动时 SSL 初始化特别慢。指向/dev/urandom非阻塞随机源能让启动快很多。内存规划的计算逻辑如果你的服务器总内存是 8G堆设 4G、元空间 512M再留出 2G 给操作系统和 Tomcat 自身的线程栈、直接内存、JIT 编译缓存。经验法则是堆内存不要超过物理内存的 2/3否则操作系统内存紧张时会触发 OOM Killer 把整个 Java 进程干掉。4.3 JMX 远程监控内网安全边界必须设好线上服务跑起来了你得知道它的运行状态堆内存用了多少、GC 频率如何、哪个线程在打转。JMXJava Management Extensions就是干这个的它通过一个端口暴露 JVM 的运行指标你可以用本地 JConsole 远程连上去看。在JAVA_OPTS里追加-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port19999 -Dcom.sun.management.jmxremote.rmi.port19999 # 这个必须显示指定否则每次重启端口会随机跳 -Dcom.sun.management.jmxremote.authenticatetrue -Dcom.sun.management.jmxremote.sslfalse -Dcom.sun.management.jmxremote.access.file/etc/jmxremote.access -Dcom.sun.management.jmxremote.password.file/etc/jmxremote.password这里要特别强调一个安全原则JMX 端口绝不能直接暴露到公网。JMX 认证只支持明文的账号密码JMX 协议本身的认证比较弱SSL 配置又麻烦直接开公网上等于送人一个后门。正确做法是让 JMX 端口只监听内网 IP例如-Dcom.sun.management.jmxremote.host192.168.1.10。如果实在要跨网络访问用 SSH 隧道转发把远程的 19999 端口映射到本地再用本地 JConsole 连接如ssh -L 19999:127.0.0.1:19999 userhost。同时在/etc/jmxremote.password里配置账号密码monitoruser YourStrongPassword然后设置文件权限为 600属主为 tomcatJMX 认证要求密码文件权限必须严格chown tomcat:tomcat /etc/jmxremote.password /etc/jmxremote.access chmod 600 /etc/jmxremote.password这样配置好JConsole 连192.168.1.10:19999输入账号密码就能看到 Heap 使用曲线和线程数了。我自己排线上问题的时候JMX 是第一个会打开的工具——比日志快得多内存泄漏、线程阻塞一眼就能定位方向。5. 高频故障清单环境变量失效、闪退与 404 的排查链路部署教程写得再全实际操作时总会遇到些稀奇古怪的问题。这一章把我遇到频次最高的几个状况整理成清单每个都给一条清晰的排查链路而不是丢给你一句玄学般的“重新装一遍”。5.1 环境变量配了但 java -version 还是提示找不到这个问题的排查链路非常典型我建议按顺序自查确认配置文件路径你写的是/etc/profile.d/java.sh还是写进了/etc/profile或~/.bashrc如果是~/.bashrc换个用户登录当然找不到。确认文件是否执行ls /etc/profile.d/java.sh确认文件存在再cat看内容看是否有语法问题。确认是否重新登录改完了没有重开新的 SSH 窗口或重启系统只在当前终端里修改环境变量是不生效的。检查 PATH 次序bash echo $PATH如果发现 /usr/bin/java 排在了 $JAVA_HOME/bin 前面那你敲 java -version 出来的还是系统自带的旧版本。修改 PATH 时记得把 $JAVA_HOME/bin 放在最前面如 2.4 节所示。 5. **偶然的坑**某些发行版比如 Ubuntu的 /etc/profile 里会强制 unset JAVA_HOME 之类的命令会把你配的变量清掉。这时候需要用 env | grep JAVA_HOME 确认变量是否在登录后还存在。 实战中最常见的还是第 3 条——**source 一次只是当前的 shell 生效新用户、新终端默认还得重新读取登录脚本**。验证方式就是重开 session 再测。 ### 5.2 Tomcat 启动“闪退”秒开秒关的背后是什么 操作步骤没问题执行 ./startup.sh屏幕打印 Tomcat started然后等你习惯性地 ps -ef | grep java 一看——进程没了。这就是“闪退”。 闪退的排查套路就是查日志。先说一个新手最容易忽略的点**catalina.out 不一定在 Tomcat 的 logs 目录里**。如果你是用 systemd 方式启动的日志可能会被 systemd 收集走用 journalctl -u tomcat 看如果用 startup.sh 直接从终端启动日志才在 logs 下。 闪退最常见的三类原因 1. **端口被占用**BindException: Address already in use。这个在 3.4 节已经讲过了ss -lntp | grep 8080 查出来直接处理。 2. **堆内存设太小**启动时报 Could not reserve enough space。遇到过一台 512MB 的机器-Xmx2048m 根本起不来把堆降到 -Xmx512m 就正常了。 3. **JAVA_HOME 没找到**报错信息非常直白Cannot find /opt/jdk/current/bin/java。多半是你用的启动用户比如 tomcat 用户读不到你自己 root 用户配的环境变量。解决方式是 4.1 节里 systemd 文件里显式加入 EnvironmentJAVA_HOME/opt/jdk/current而不要依赖登录 shell 里的变量。 注意**闪退时不要慌着改配置**先看 catalina.out 有没有打出一个 Caused by: 开头的段落——那是真正的根因。前面的异常链只是表象。 ### 5.3 “源服务器未能找到目标资源”等于 Tomcat 404 的三类原因 这个报错其实是浏览器翻译后的 HTTP 404 状态码。Tomcat 能启动、首页也能访问但你部署的业务应用路径访问时打不开最常见了三类情况 1. **应用没部署对位置**。你把 war 包扔哪里了必须是 webapps/ 目录。Tomcat 启动时扫描 webapps 下的 war自动解压并映射成应用上下文。如果你把 war 包放在了别处Tomcat 根本不知道这个应用的存在访问任何路径都是 404。 2. **应用路径大小写不匹配**。Tomcat 对路径是区分大小写的。你部署了 myapp.war访问 /MyApp/ 和访问 /myapp/ 是两回事后者直接 404。 3. **应用上下文名不是你想象的那个**。默认情况下myapp.war 部署后上下文名就是 myapp访问 http://IP:8080/myapp/。如果你想自定义上下文名要么把 war 包改名为 ROOT.war这样访问根路径就行要么在 conf/server.xml 的 Host 节点下配置 Context 标签。 补充一句**如果你把战争的 ROOT.war 部署在 webapps/ROOT.war但清空了 webapps/ 下的默认应用目录那你访问根路径时看到的就是你自己的应用而不是 Tomcat 那只小猫首页**。很多人在这一步卡了半天才意识到。 ### 5.4 Tomcat 默认管理页面上传 war 被限制 IP 如果你用的是 Tomcat 自带的 manager 管理页面来在线部署 war 包访问 /manager/html看到“您的 IP 地址已被拒绝”这类的提示这是 Tomcat 的**默认安全策略**manager 应用只允许从 127.0.0.1 访问。 修改方式是编辑 webapps/manager/META-INF/context.xml在 Context 里找到这段 xml Valve classNameorg.apache.catalina.valves.RemoteAddrValve allow127\.\d\.\d\.\d|::1|0:0:0:0:0:0:0:1 /把你的内网 IP 加进去allow127\.\d\.\d\.\d|::1|0:0:0:0:0:0:0:1|192\.168\.1\.\d改完重启 Tomcat 生效。这里要提醒manager 页面本身就是高风险的攻击面。如果你没有特别需求在生产环境把 manager 应用直接移除都不过分——“删除它”永远比“给它加 IP 白名单”更安全。真有部署需求建议直接把 war 扔到webapps目录或用 Jenkins 这类 CI 工具做流水线发布而不是开 web 管理台。这一路走下来从选版本、配环境变量、起服务、设自启、加监控、到排查翻车基本覆盖了 Linux 上装 Java 服务环的全流程。我个人在实际项目里把这套流程固化成了一个部署脚本换个机器只要改一下版本号和路径十分钟内就能把一套干净的 Java 环境搭出来。你第一次操作时卡住也别灰心把每一步的验证命令跑全大部分问题都能在日志里找到答案——这比背一百遍命令都管用。