Linux端口不通：检查监听地址、服务与访问规则
本篇检查Linux服务器端的TCP监听、服务和访问规则。先在本地按端口测试文档确认当前IP、实际端口及错误；Windows服务器请使用Windows连接指南。还能通过其他管理连接或产品实际提供的控制台进入系统时，按下面顺序做只读检查；没有可用管理入口时，保留现象提交工单。
检查实际端口是否监听
在Linux服务器执行：
sudo ss -lntp-l列出监听，-n显示数字地址和端口，-t只看TCP，-p显示可见的进程信息。找到实际业务端口，核对Local Address:Port和进程，不能只确认“存在某个22端口”。
| 看到的结果 | 下一步 |
|---|---|
| 没有目标端口 | 查实际服务状态、端口配置及启动日志，尚不需要先扩大防火墙放行范围。 |
| 只监听127.0.0.1或::1 | 该监听通常仅供本机访问。先确认是否本来就应通过代理或隧道使用，勿直接将数据库等内部服务改成公网监听。 |
| 监听0.0.0.0、特定网卡地址或IPv6地址 | 核对客户端使用的地址族与目标地址，再检查访问规则。IPv6监听不能直接证明IPv4也可用。 |
| 端口由其他进程占用 | 按进程名称和PID核对实际用途及服务配置，不直接结束未知进程。 |
查服务状态和启动错误
以SSH为例，使用systemd的Debian／Ubuntu常见服务名为ssh，其他发行版可能为sshd；以下名称须与实际服务一致：
systemctl status ssh --no-pager
sudo journalctl -u ssh --since "30 minutes ago" --no-pageractive (running)只说明服务当前在运行，仍需与监听结果对应；inactive或failed时，保存退出原因和最近错误。日志范围要覆盖故障时段；服务名错误或日志缺失不能作为正常结论。非systemd系统使用其已有服务管理方式。
配置有误时，先备份并按对应服务方法校验，再安排恢复。保留现有管理连接，不在唯一远程会话中贸然改端口、重启未知服务或替换认证方式。
核对实际生效的访问规则
产品实际提供安全组或云防火墙时，核对TCP协议、入站方向、目标端口和当前公网来源IP。公司网络有多出口或来源IP已变时，原来的来源白名单可能不再匹配。服务器内只检查正在使用的防火墙，不再并行启用另一套规则工具。
使用UFW的服务器
sudo ufw status verbose核对状态、默认策略，以及目标端口、地址族和允许来源。inactive只说明UFW未启用，不等于服务器不存在其他过滤规则。
使用firewalld的服务器
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --get-default-zone先核对网卡或来源明确绑定的zone；没有明确绑定时，再核对默认zone。下面的public只是示例，必须替换为上一步得到的实际zone，再查看当前运行规则：
sudo firewall-cmd --zone=public --list-all核对interfaces、sources、services、ports及相关富规则。仅有永久配置不一定已在运行时生效；不要为排查直接reload、清空规则或关闭整个防火墙。nftables、iptables或容器端口映射由熟悉现有规则的管理员核对。
监听和规则看似正常，仍然连不上
- 换网络复测同一IP和端口，记录不同来源的结果。一次热点正常只提供来源差异，不能直接确定责任。
- 检查应用自己的允许名单、登录限制和相关安全日志；若已部署fail2ban等封禁工具，核对失败时刻与来源IP，不盲目取消全部限制。
- 超时、主动拒绝和认证失败是不同阶段；端口可达后仍认证失败，应回到用户名、凭据、认证方式和登录策略排查。
仅修改已经确认的必要配置，保留原连接，从第二个客户端验证端口与业务。仍不通时提交产品ID、来源IP、目标IP与端口、测试时间和错误、监听与进程、服务状态、规则摘要及网络对照；不要附私钥或密码。