Tomcat配置后台服务器后，端口查询只有三步走：先看conf/server.xml里的Connector配置，再翻logs/catalina.out启动日志，最后用netstat或lsof命令对端口做验证。实际运维中，这三步的顺序基本就是排查路径，大多数情况下，配置文件里写的端口和日志里打印的端口是一致的,不一致时以日志为准。
配置tomcat后端口怎么查：先从server.xml下手
很多朋友配置完Tomcat后台服务器，第一反应是去找安装文档，其实最快的路径是直接打开Tomcat根目录下的conf/server.xml文件，这个文件是整个Tomcat的“中枢神经”,所有对外服务的端口都在这里定义。
找到真正的端口配置标签
用文本编辑器打开server.xml，你需要重点看<Connector>这个标签,Tomcat默认的HTTP连接器长这样：
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />
port="8080"就是HTTP服务的实际监听端口，这里有个细节容易踩坑：redirectPort="8443"不是访问端口，它只是告诉你当请求需要HTTPS跳转时，Tomcat会把请求转发到8443端口，很多新手把8443当成访问端口去连，结果连不上,就很懵。
Tomcat还默认开启了AJP协议,配置在另一个Connector里：
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
AJP端口是给Apache或Nginx做反向代理用的，浏览器直接访问不到，如果你只是单纯配了个后台服务，不用管8009，查HTTP端口就看protocol="HTTP/1.1"那个标签。
一个Tomcat可能绑定多个端口
有的部署场景下，server.xml里会配置多个HTTP Connector，比如一个监听8080给外部用户访问，另一个监听8081给内部管理接口用，这时候光看一个端口肯定不够，逐个排查所有Connector里的port属性才是完整做法。
还有一种情况是端口被改过但不记得改成多少，直接搜索server.xml里的port=关键字，所有监听端口会一次性列出来，用编辑器自带的搜索功能,比肉眼扫描靠谱得多。
改完server.xml端口查询还是老端口？分清楚这几个场景
配置文件的端口查清楚了，但实际运行时的端口不一定和文件一致，这事我遇到过太多次：改完server.xml重启Tomcat，结果访问的还是老端口，甚至直接报错，为什么？因为改动没生效或者没改对地方。
改完端口必须重启才能生效
server.xml是启动时加载的，运行中修改不会热更新，你必须执行完整的重启流程：先跑sh shutdown.sh（Windows下是shutdown.bat）把进程停掉，再跑startup.sh重新拉起，如果只是kill掉进程再手动java启动,可能加载的还是其他路径下的配置。
多实例部署时查错配置文件
一台服务器上部署多个Tomcat实例是常态，每个实例有自己的CATALINA_BASE目录，你按照习惯打开/usr/local/tomcat/conf/server.xml，但实际跑着的服务可能用的是/opt/tomcat_8081/conf/server.xml。查端口前先确认当前进程到底用的哪个目录,这是关键一步。
环境变量覆盖默认端口
有的运维脚本会在catalina.sh里动态修改端口，或者通过-Dserver.port=9090这类JVM参数覆盖配置，这种情况下，server.xml里的8080是“初始值”，实际运行端口是启动参数决定的，怎么确认？下面这张表告诉你不同情况分别查什么：
| 场景 | 查询入口 | 优先级 |
|---|---|---|
| 配置文件明确，未做二次修改 | server.xml的Connector标签 | 最高，配置文件即事实 |
| 启动脚本或JVM参数覆盖 | 进程启动参数/环境变量 | 高于配置文件 |
| 运行中不确定状态 | 日志和网络命令 | 最终事实，以上两者冲突时以此为准 |
tomcat端口查看命令：netstat、lsof、ps三件套实操
配置文件查完，日志也看过，但系统实际监听在哪个端口上，还是要用操作系统的网络命令来验证，这也是排查“端口查不到”“端口冲突”问题时最硬核的一步。
先查Java进程拿到PID
Tomcat本质是个Java进程，先定位进程再查端口，逻辑最顺,Linux下执行：
ps -ef | grep java
输出里找到tomcat相关的行，第二列就是PID，如果你部署了多个Tomcat，可以通过-Dcatalina.base参数区分具体是哪个实例。
用netstat验证端口监听状态
拿到PID后,用netstat精确匹配：
netstat -tlnp | grep java
或者直接指定PID：
netstat -tlnp | grep 12345
12345替换成你查到的PID，输出中0.0.0:8080表示所有网卡都监听，0.0.1:8080表示只有本机能访问如果你想让其他机器通过后台服务器IP访问，后者配置会导致连接超时，这也是“Tomcat启动成功但外部访问不了”的常见原因。
Windows系统下命令稍有不同,在cmd里执行：
netstat -ano | findstr 8080
最后一列是PID，配合任务管理器就能定位进程，注意Windows下findstr是过滤关键字,和Linux的grep一个用处。
lsof直接看端口占用
Linux下还有更直接的方式：
lsof -i:8080
这条命令直接告诉你8080端口被哪个进程占用、进程名叫什么、PID是多少。多数情况下，一条lsof就能把配置、启动、监听三者串起来，快速确认端口状态，如果命令没输出，说明8080根本没进程在监听,问题出在Tomcat没起来或者配置变了。
从Tomcat日志看端口，找线索比猜更快
命令查不到端口时，日志是最后的仲裁者，Tomcat把所有启动过程信息都写进了logs/catalina.out文件,端口相关的信息也在这里。
启动成功时端口怎么显示
正常的启动日志里有一段这样的输出：
INFO [main] org.apache.catalina.startup.Catalina.start Server startup in [2568] milliseconds在这行之前，会有类似Starting ProtocolHandler ["http-nio-8080"]的日志，这里的http-nio-8080就是当前生效的HTTP端口，日志怎么写的，实际就是什么,不用猜。
端口被占用时日志长什么样
如果8080被别的进程占了,日志会直接报错：
SEVERE [main] org.apache.catalina.startup.Catalina.start
The required Server component failed to start so Tomcat will be shut down.再往上翻几行，能看到java.net.BindException: Address already in use: JVM_Bind，这是端口冲突的典型报错，遇到这种情况，用lsof -i:8080找出占用进程，要么杀掉,要么换端口。
查看日志的命令很简单：
tail -200 logs/catalina.out
看最后200行就够了，启动过程的关键信息全在尾部，日志文件过大的话，用grep直接搜端口关键词：
grep -i "port" logs/catalina.out | tail -20
tomcat端口排查的常见场景与解决套路
运维最怕的不是端口查不到，而是查到的端口和实际访问的结果对不上,这里把几个高频场景一次性理清楚。
Tomcat起来了，但外部访问超时
配置文件、日志、netstat都显示端口正常监听，但浏览器就是连不上,这种时候按顺序查三层：
- 防火墙层：CentOS下执行
firewall-cmd --list-ports看端口是否放行，未放行则firewall-cmd --add-port=8080/tcp --permanent后重载，行业共识认为，云服务器安全组的入站规则比本地防火墙更容易被忽略,登录简米云或酷番云控制台检查安全组策略。 - IP绑定层：netstat显示
0.0.1:8080而不是0.0.0:8080，说明只监听了本机回环地址，解决方法是修改server.xml里Connector的address属性为0.0.0。 - 代理层：如果前面挂了Nginx或Apache，Tomcat端口改完后代理配置也要同步改,否则入口还是老端口。
端口能查到，但访问返回404或403
端口通，服务也在，但页面不对，这已经不是端口问题，而是后台应用部署路径的问题，打开conf/server.xml看Host标签下的appBase属性，以及webapps目录里实际放了什么应用包，Tomcat根路径访问http://IP:端口/默认显示的是webapps/ROOT目录下的内容，如果你的后台应用打了war包放在webapps下,访问路径要带上应用名。
业内专家指出，企业级后台系统部署时，多数运维会用<Context path="" docBase="应用绝对路径" />把根路径直接指向应用，省去应用名后缀，这种配置下，只要端口查对,路径基本不会错。
Q&A：tomcat配置后台服务器端口查询常见问题
Tomcat端口改完后，为什么用老端口还能访问？
大概率是Tomcat进程没有被真正杀掉。shutdown.sh有时会失败，进程还残留在后台，建议先ps -ef | grep java拿到PID，kill -9强杀，再确认端口释放，最后重新启动，另一种可能是你访问的其实是Nginx或其他反向代理的端口,代理指向的还是老配置。
同一台机器上怎么区分多个Tomcat实例对应的端口？
先执行ps -ef | grep java，从输出中区分每个进程的-Dcatalina.base路径，路径里通常包含端口号或用例名，再执行netstat -tlnp，把每个PID对应的监听端口列出来，两者一对应,哪个实例占哪个端口就清清楚楚了。
服务器重启后Tomcat端口查询时什么需要最先检查？
检查Tomcat是否随机启动，如果没配systemd服务或rc.local自启动，服务器重启后Tomcat根本没起来，端口自然查不到，启动完成后，按本文顺序：先看server.xml确认预期端口，再看catalina.out确认启动成功，最后用lsof -i:端口验证监听状态即可。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/783476.html
