现状
简单描述下最近在做啥，我手里维护的一些系统的线上服务器，还在使用centos7，7.3/7.6/7.9都有，运维侧选定的替换系统是openEuler20.03-LTS-SP1。按理说，运维直接在线上升级系统就完了，但是，由于风险太大了（直接升级后可能导致应用异常），就还是需要研发出迁移方案、测试组进行测试后，比较保险。
于是，我就在本地虚拟机virtualbox先来折腾试试，先搭了个centos 7.3的系统，部署了个应用，监听端口9900，结果怎么都访问不了。
下面记录下排查过程。
应用介绍
我们这个服务器是centos7.3，上面的应用也比较老，是一种java servlet容器：resin，和tomcat类似，对外提供http接口。
配置监听端口的地方如下：
程序启动后，我看端口是在监听的：
我本机curl试了下，可以访问：
[root@node7 my168_web]# curl localhost:9900
Hello World!
我这个虚拟机的端口9900，需要暴露到windows宿主机进行访问，配置了下端口映射：
然后，通过浏览器访问localhost:19900，发现失败：
排查过程
怀疑ipv6
我在虚拟机上，开了tcpdump，发现可以收到syn握手：
tcpdump -i any tcp port 9900 -Ann
我在虚拟机，又试了下：
[root@node7 my168_web]# curl localhost:9900
Hello World!
发现抓包如下：
此时，就看到通过localhost访问时，用的ipv6的地址，此时，开始怀疑是不是9900端口，仅监听了ipv6导致的。
下面这个输出，强化了我的猜测：
我又看了下其他环境，发现：
如果这个环境里，只有ipv4地址，netstat的输出就不一样
另外一套环境，有ipv6地址，netstat输出就是inet6啥的。
尝试修改配置文件，监听ipv4
把配置改成了下面这样：
重启后，netstat结果发现输出没啥变化：
[root@node7 my168_web]# netstat -nltp|grep 9900
tcp6 0 0 :::9900 :::* LISTEN 11992/java
此时，在网上问大模型，大模型提到：
大模型建议实际测试下，看看到底是否支持ipv4：
测了之后，发现确实可以，那就说明对ipv4的支持没问题：
尝试从其他虚拟机telnet该端口
我找了另一台同网段的机器10.0.2.8：
[root@node-4 yum.repos.d]# telnet 10.0.2.12 9900
Trying 10.0.2.12...
telnet: connect to address 10.0.2.12: No route to host
很奇怪的是，你说no route我可以理解，就是找不到目标主机的路由项嘛，但是，我在目标主机开了抓包的，发现telnet的时候，能收到syn包：
而且，抓包到wireshark看的时候，发现mac地址也是正确的：
下图附两台机器的mac地址：
我于是在发起端的机器，查看下路由表：
发现路由表没错。
安装了个traceroute，发现就一跳，然后看看arp，发现这个ip对应的mac地址也是对的。
此时，又去网上查了下，开始怀疑到了防火墙的身上。
防火墙排查
找了下centos7.3中对应的防火墙相关命令：
https://www.ctyun.cn/zhishi/p-330299
发现目标服务器上，防火墙真的开着的：
查了下，9900端口是否开放，发现没开放：
[root@node7 my168_web]# firewall-cmd --query-port=9900/tcp
no
9900加入开放：
firewall-cmd --permanent --add-port=9900/tcp
firewall-cmd --reload
[root@node7 my168_web]# firewall-cmd --permanent --add-port=9900/tcp
success
[root@node7 my168_web]# firewall-cmd --reload
success
[root@node7 my168_web]# firewall-cmd --query-port=9900/tcp
yes
然后再试试，果然就好了：
总结
这个centos7.3是新装的虚拟机，忘了防火墙会自动开启这回事了。
由于对netstat的输出也是半桶水，导致走了弯路，好歹最后还是找到了正确的路。