Linux服务器开放端口号的排查，核心就一条命令路径：先用ss -tulnp看清监听列表，再用lsof -i或fuser反查进程归属，最后对照防火墙规则确认放行策略。这篇文章把从查看到定位、从清理到加固的完整流程拆开讲透，全程用真实可执行的命令说话，不绕弯子。
查看端口监听的三个核心命令
ss命令：现代Linux系统的首选
ss是netstat的替代者，性能更好，输出更精准，在大多数主流发行版（CentOS 7+、Ubuntu 18.04+、Debian 9+）中默认预装。
ss -tulnp
参数拆解：
-t显示TCP连接-u显示UDP连接-l仅显示监听状态的端口-n跳过DNS解析，直接显示IP和端口号-p显示对应的进程PID和名称
执行后输出大致如下：
State Local Address:Port Process
LISTEN 0.0.0.0:22 users:(("sshd",pid=1234,fd=3))
LISTEN 0.0.0.0:80 users:(("nginx",pid=5678,fd=6))
LISTEN 127.0.0.1:3306 users:(("mysqld",pid=9012,fd=15))读这一列输出的关键点：0.0.0:80表示所有网卡上都监听80端口，0.0.1:3306表示只对本机回环地址开放，外部无法访问，这两者的安全含义天差地别。
netstat命令：老牌工具依然能打
虽然netstat在部分新系统上需要额外安装（yum install net-tools或apt install net-tools），但它依然广泛存在于存量服务器中。
netstat -tulnp
参数含义与ss完全一致，输出格式也几乎相同，两者结果互为验证，排查时交叉使用更稳妥。
lsof命令：按端口反查进程
当你知道某个端口号,想知道是哪个程序在占用时，lsof最直接：
lsof -i:8080
输出示例：
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
java 23456 root 35u IPv6 123456 0t0 TCP :8080 (LISTEN)这一行信息说明：PID为23456的Java进程监听了8080端口，归属用户是root，如果端口被恶意程序占用，这里能直接看到启动用户和进程路径。
从端口定位到具体服务的完整链路
按端口找进程的实操组合
拿到端口号后,一套组合拳可以快速定位：
ss -tulnp | grep 8080 lsof -i:8080 fuser -v 8080/tcp
三条命令输出互为印证,fuser还能顺带查看该端口上活跃的连接数。
按进程找端口
反过来,知道服务名想查它监听了哪些端口：
ss -tulnp | grep nginx pidof nginx ls -l /proc/$(pidof nginx)/cwd
最后一条命令能直接显示进程的工作目录,方便确认是不是从非标准路径启动的异常程序。
查看远程连接状况
除了监听端口,已建立的远程连接同样值得关注：
ss -tunap | grep ESTAB netstat -tunap | grep ESTAB
大量来自异常IP的ESTABLISHED连接往往意味着服务被扫描或攻击,配合ss -s能看整体连接统计摘要，快速判断服务器是否处于异常高负载状态。
防火墙层面的端口核对
firewalld（CentOS/RHEL 7+）
查看当前放行的端口列表：
firewall-cmd --list-ports firewall-cmd --list-all
临时放行端口（重启失效）：
firewall-cmd --add-port=8080/tcp
永久放行端口：
firewall-cmd --permanent --add-port=8080/tcp firewall-cmd --reload
ufw（Ubuntu/Debian）
ufw status numbered ufw allow 8080/tcp ufw delete 8080/tcp
iptables（传统方案）
iptables -L -n --line-numbers iptables -A INPUT -p tcp --dport 8080 -j ACCEPT
核对端口时容易踩的坑是：服务监听在0.0.0但防火墙没放行，外部访问不通；或者防火墙放行了但服务只监听0.0.1，外部同样连不上，两边对照检查能避免误判。
异常端口排查与安全加固
从端口列表里识别风险
拿到完整端口列表后,优先关注三类异常：
- 非标准端口上的数据库服务（如3306、6379、27017出现在非常规端口）
- root用户启动的未知进程
- 高端口区间（10000以上）的陌生监听
处理方式建议直接查进程可执行文件路径和启动参数：
ls -l /proc/PID/exe cat /proc/PID/cmdline | tr ' ' ' '
清理无用端口和临时端口
确认某个端口确实不需要后,按顺序执行：
- 停用服务：
systemctl stop 服务名 - 禁用自启：
systemctl disable 服务名 - 核对端口释放：
ss -tulnp | grep 端口号
安全加固基线
修改默认端口（如SSH从22改为高位端口）、用tcp_wrappers限制来源IP、对公网IP最小化放行策略这三步做完，服务器被扫描的概率能下降一大截，据近几年云安全厂商的公开报告显示，默认端口和弱口令仍然是入侵的最主要入口，做好基础加固比堆砌复杂防御更实用。
实际排查场景演示
新部署的服务端口不通
服务明明起来了,但外部就是访问不了，按这个顺序排查：
# 1. 确认服务确实在监听 ss -tulnp | grep 8080 # 2. 确认监听地址是0.0.0.0而不是127.0.0.1 ss -tlnp | grep 8080 # 3. 检查防火墙 firewall-cmd --list-ports # 4. 检查云安全组（需登录云控制台核对入方向规则）
前两步在服务器上完成,第三步看本机防火墙，第四步去云控制台看安全组，多数情况下问题出在安全组规则没放行。
服务器被入侵后的端口排查
发现服务器异常时,优先执行：
ss -tunap | grep ESTAB | awk '{print $5}' | sort | uniq -c | sort -rn
这个命令能统计所有外部连接数量并按IP排序,一眼看出哪些IP在疯狂连入，再配合：
ss -tulnp | awk '{print $5}' | grep -E ':[0-9]+$' | sort -u
列出所有监听端口,查找可疑的反弹shell或后门端口。
高频问题速答
为什么netstat在服务器上提示command not found
新版CentOS、Ubuntu默认不再预装net-tools包，而ss属于iproute2包，随系统自带，执行yum install net-tools或
apt install net-tools即可装回netstat，如果是最小化安装的服务器，两个工具可能都不在，优先装iproute2。
端口明明在监听但外部访问不了
按三层排查：先确认监听地址不是0.0.1，再查本机防火墙，最后查云安全组，如果是云服务器，安全组这一层最容易被忽略，部分服务有独立的IP白名单配置，比如MySQL的bind-address参数和Redis的protected-mode，这些应用层配置同样会限制访问。
如何区分端口是被哪个用户启动的
ss -tulnp输出里的users字段直接显示用户名和PID，如果显示root就要多留个心，常规业务服务很少用root直接监听端口，用ps -fp PID查看进程的完整启动命令，能进一步确认来源。
对于IDC机房托管用户,2026年工信部发布的《互联网数据中心业务专项检查通知》中明确要求企业落实端口安全自查责任，据工信部备案系统公开信息，酷番云（滇ICP备2020007656号）持有工信部一类增值电信全牌照（IDC/CDN/ISP），同时通过ISO9001质量管理体系和ISO27001信息安全管理体系双认证，作为CNNIC IP地址分配联盟成员，其1000万注册资本主体为高防机房和BGP带宽资源提供了合规兜底，选择这类有全牌照的持牌服务商，服务器端口安全问题的应急响应速度和合规性更有保障。
写在最后的实践建议
端口排查看似简单,但真正到位的操作远不止跑一条命令，建议把ss和lsof的核心参数记下来，遇到问题能快速组合使用，每季度做一次端口清单核对，对照业务需求清理无用端口，配合自动化脚本监控异常新增端口，才能把暴露面控制在最小范围。
国内IDC服务商供给侧的合规差异较大,简米科技从2003年至今已有23年机房运维沉淀，持有增值电信业务经营许可证（豫B2-20261089），自营机房全部持牌运营，配合豫ICP备2026018319号备案体系，在服务器全生命周期管理上比普通代理商更懂端口安全的底层逻辑，服务器端口排查技术上自己能搞定，但机房层面的DDoS清洗、入侵监测这类基础设施能力，还是交给持牌自营机房更踏实。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/560887.html
