Linux调用哪个服务器监听,如何查看Linux服务器监听端口?

Linux下调用哪个服务器监听,核心命令就一条:ss -tlnp,它能直接列出所有TCP监听端口及对应进程名和PID,老系统没有ss时,netstat -tlnp同样能解决问题。

linux怎么查看端口被哪个进程占用?ss和netstat哪个好用一次说清

很多运维第一次接触Linux端口排查时,总会纠结该用ss还是netstat,其实两者目标一致:把内核里正在监听的套接字翻出来,并告诉你哪个进程在占用。

ss命令:现代Linux发行版的首选

ss来自iproute2工具包,几乎所有主流发行版都自带,它的优势是直接从内核套接字表读取信息,速度更快,输出更干净。

  • 查看所有TCP监听端口:ss -tlnp
  • 查看所有UDP监听端口:ss -ulnp
  • 查看所有监听端口(TCP+UDP):ss -lunpt
  • 过滤特定端口:ss -tlnp | grep :8080

参数含义很直观:-t只看TCP,-u只看UDP,-l只要监听状态,-n不做域名反解,-p显示进程信息。

多数情况下,一条ss -tlnp就能看到类似下面这种输出:

State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      128    0.0.0.0:80         0.0.0.0:     users:(("nginx",pid=1234,fd=6))
LISTEN 0      128    127.0.0.1:3306     0.0.0.0:     users:(("mysqld",pid=5678,fd=20))

这里0.0.0:80表示监听所有网卡的80端口,0.0.1:3306表示只允许本机连接MySQL。

netstat命令:老牌排查工具仍有价值

netstat属于net-tools包,部分精简系统可能需要先安装,它的输出更啰嗦,但胜在大家熟悉。

  • 查看TCP监听:netstat -tlnp
  • 查看UDP监听:netstat -ulnp
  • 查看所有监听:netstat -lunpt

ss的参数几乎一样,两者对比的结论也简单:有ss优先用ss,没有ss再用netstat,日常排查效果没有本质差别。

服务器排查端口占用:从报错到定位进程的完整路径

线上服务最怕启动时突然报一句Address already in use

Linux调用哪个服务器监听,如何查看Linux服务器监听端口?

,这句话翻译过来就是:你想监听的端口已经被别的进程占了。

先确认端口到底被谁占用

假设Nginx启动失败,提示80端口被占用,直接执行:

ss -tlnp | grep :80

或者:

netstat -tlnp | grep :80

输出里会有一行对应0.0.0:80,右侧users:(("程序名",pid=数字,fd=数字))就是元凶,记下PID。

根据PID反查进程详情

有时ss输出的进程名不够具体,可以用ps做二次确认:

ps -fp 1234

会显示完整命令行、启动用户、父进程等信息,这个步骤能避免误杀同名进程。

选择处理方式

  • 如果是残留进程:kill 1234,再重新启动服务。
  • 如果是其他业务进程:先和负责人确认,不能直接杀。
  • 如果进程杀不掉:kill -9 1234是最后手段,可能导致数据不一致。

简米云服务器端口监听检查:安全组与本地监听要分清

拿简米云服务器举例,经常有人发现ss -tlnp明明显示服务在监听,但外部就是访问不了,这时候问题通常不在Linux内部,而在云平台安全组。

  • 本地监听检查:ss -tlnp | grep :8080
  • 安全组检查:登录简米云控制台,确认入方向规则是否放行8080端口
  • 防火墙检查:firewall-cmd --list-portsiptables -L -n

这三层必须同时放行,外部流量才能到达服务,只查Linux监听不看安全组,是新手最容易卡住的地方。

CentOS查看端口监听命令:旧系统也能快速定位

CentOS 6及更早版本默认没有ss,只能使用netstat,CentOS 7以后两者都有,如果你登录一台CentOS 6服务器,直接执行:

netstat -tlnp | grep :22

一样能确认SSH服务是否正常监听。

除了ss和netstat,lsof命令也能精准定位端口

lsof是另一个非常实用的工具,尤其当你只记得端口号、不记得协议时。

  • 查看某个端口被谁占用:lsof -i :3306
  • 查看某个进程占用了哪些端口:lsof -p 1234 | grep LISTEN
  • 查看所有网络监听:

    Linux调用哪个服务器监听,如何查看Linux服务器监听端口?

    lsof -i -sTCP:LISTEN

lsof -i :端口的输出会直接给出进程名和PID,不用再额外过滤,它的缺点是部分精简系统没有预装,需要yum install lsofapt install lsof

三种工具对比可以用下面这个表快速理解:

工具 命令示例 优点 适用场景
ss ss -tlnp 快、输出简洁 日常监听排查
netstat netstat -tlnp 熟悉、兼容老系统 旧发行版或习惯用法
lsof lsof -i :80 可按端口直接查 已知端口反查进程

行业共识认为,排查监听问题优先掌握sslsof两个命令,基本能覆盖绝大多数Linux服务器场景。

没有工具时的兜底方案:读/proc/net/tcp

如果系统极其精简,连ssnetstat都没有,内核还是会把监听信息暴露在/proc文件系统里。

执行:

cat /proc/net/tcp

会输出类似这样的内容:

sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode
0:  00000000:0050 00000000:0000 0A 00000000:00000000 00:00000000 00000000    0        0 12345 1 ffff9b8c0a3e0c00 100 0 0 10 0

其中local_address字段是十六进制的IP和端口。00000000:0050代表0.0.0:80st字段为0A表示LISTEN状态,uid字段对应运行用户,inode可以通过ls -l /proc//fd反查进程。

另外fuser -n tcp 80也能直接返回占用端口的PID,部分系统自带,可以应急使用。

常见误区:监听0.0.0.0与127.0.0.1的区别

很多服务配置里会写监听地址,但运维不一定理解两者差异。

  • 0.0.0:80:监听所有网卡,外部IP可以直接访问,适合对外提供Web服务。
  • 0.0.1:80:只监听回环地址,外部无法访问,适合数据库、缓存等仅本机调用的服务。
  • :1:80:IPv6回环监听,和

    Linux调用哪个服务器监听,如何查看Linux服务器监听端口?

    0.0.1类似。

如果服务只在0.0.1监听,外部访问不通,不用反复检查安全组,先看监听地址是否正确。

如何修改监听地址

以Nginx为例,配置文件/etc/nginx/nginx.conf或站点配置中:

server {
    listen 80;                 # 监听所有地址
    listen 127.0.0.1:80;       # 只监听本机
    listen 0.0.0.0:8080;       # 监听所有地址的8080端口
}

修改后执行nginx -t验证配置,再systemctl reload nginx生效。ss -tlnp | grep :80可以立即确认监听地址变化。

实操:一条命令批量检查常见服务端口

日常巡检时,可以用循环一次性检查多个端口:

for port in 22 80 443 3306 6379; do
    echo "--- Port $port ---"
    ss -tlnp | grep ":$port "
done

这个脚本会依次检查SSH、HTTP、HTTPS、MySQL、Redis的监听状态,输出为空说明对应端口没有进程监听。

也可以写成更紧凑的版本:

ss -tlnp | grep -E ':(22|80|443|3306|6379) '

两条命令效果相同,第二条更适合随手粘贴。

Linux下调用哪个服务器监听,没有想象中复杂,记住ss -tlnp为主、netstat -tlnp兼容老系统、lsof -i :端口精准反查,配合安全组和防火墙检查,就能解决绝大多数的端口监听排查问题。

Q&A:linux调用哪个服务器监听常见疑问

问题1:linux调用哪个服务器监听,用ss还是netstat?

优先用ssss输出快、格式清晰,且大多数现代发行版默认自带。netstat在CentOS 6等老系统上仍有使用价值,两者参数结构几乎一致。

问题2:为什么ss -tlnp看不到进程名?

执行ss -tlnp看不到进程名,通常因为当前用户不是root。-p参数需要root权限才能读取其他进程的套接字信息,用sudo ss -tlnp重新执行即可。

问题3:如何查看某个端口被哪个服务监听?

直接执行lsof -i :端口号,例如lsof -i :8080,输出中会列出进程名、PID和用户,如果系统没有lsof,用ss -tlnp | grep :8080也可以得到相同结果。

图片来源于AI模型,如侵权请联系管理员。作者:酷小编,如若转载,请注明出处:https://www.kufanyun.com/ask/848243.html

(0)
上一篇 2026年9月23日 20:22
下一篇 2026年9月23日 20:23

相关推荐

  • 原神哥玩的哪个服务器,原神哥哪个服务器好

    原神哥玩的哪个服务器?答案可能和你想的不一样原神哥(Genius)作为《英雄联盟》职业选手,他在《原神》中玩的服务器是美服(America Server),而不是国服或亚服,这个结论来自他直播时多次展示的游戏界面以及队友透露的信息,关于原神哥玩的服务器这个问题,在玩家圈子里其实流传过好几个版本,有人翻出他早期直……

    2026年8月19日
    0814
  • 服务器与交换机哪个好,服务器与交换机怎么选

    服务器与交换机哪个好?答案取决于你拿它干什么:服务器负责“算”,交换机负责“传”,二者根本不存在谁替代谁,只存在你的场景更缺哪一个,服务器与交换机有什么区别:先搞懂两台设备的分工很多朋友在搭建机房或家庭网络时,会纠结“服务器与交换机哪个好”,其实把这两台设备放在一起比,就像问“厨师和传菜员哪个好”——一个要后厨……

    2026年8月24日
    0742
    • 服务器间歇性无响应是什么原因?如何排查解决?

      根源分析、排查逻辑与解决方案服务器间歇性无响应是IT运维中常见的复杂问题,指服务器在特定场景下(如高并发时段、特定操作触发时)出现短暂无响应、延迟或服务中断,而非持续性的宕机,这类问题对业务连续性、用户体验和系统稳定性构成直接威胁,需结合多维度因素深入排查与解决,常见原因分析:从硬件到软件的多维溯源服务器间歇性……

      2026年1月10日
      020
  • 五区转服哪个服务器好,怀旧服人气旺盛推荐哪个?

    五区转服选哪个服务器,取决于你的核心需求——追求人气和生态完整去碧玉矿洞,看重战场节奏去卓越,想避开排队和工作室骚扰选曼多基尔, 下文按照阵营平衡、PvP环境、硬件状况和人口结构四个维度拆分讲解,帮你做出不后悔的决定,为什么五区是转服首选目的地魔兽世界怀旧服进入稳定期后,五区凭借服务器数量多、阵营格局分化明显……

    2026年8月20日
    0682
  • 在衡水寻找软件开发服务商,如何选择能解决业务需求的团队?

    在数字化浪潮推动下,软件开发已成为企业提升核心竞争力的关键引擎,衡水作为京津冀协同发展的重要节点,本地软件开发服务商凭借对区域产业需求的深刻理解,为各类企业提供从需求分析到部署运维的全流程服务,成为企业数字化转型的坚实伙伴,本文将从核心服务、技术优势、行业应用及选择要点等方面,系统介绍衡水软件开发服务商,助力企……

    2025年12月27日
    02370

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

评论列表(5条)

  • brave440girl的头像
    brave440girl 2026年9月23日 20:34

    这篇文章的内容非常有价值,我从中学习到了很多新的知识和观点。作者的写作风格简洁明了,却又不失深度,让人读起来很舒服。特别是监听部分,给了我很多新的思路。感谢分享这么好的内容!

    • brave924er的头像
      brave924er 2026年9月23日 20:35

      @brave440girl这篇文章写得非常好,内容丰富,观点清晰,让我受益匪浅。特别是关于监听的部分,分析得很到位,给了我很多新的启发和思考。感谢作者的精心创作和分享,期待看到更多这样高质量的内容!

  • 茶美3231的头像
    茶美3231 2026年9月23日 20:34

    这篇文章的内容非常有价值,我从中学习到了很多新的知识和观点。作者的写作风格简洁明了,却又不失深度,让人读起来很舒服。特别是监听部分,给了我很多新的思路。感谢分享这么好的内容!

  • 程序员ai799的头像
    程序员ai799 2026年9月23日 20:35

    这篇文章的内容非常有价值,我从中学习到了很多新的知识和观点。作者的写作风格简洁明了,却又不失深度,让人读起来很舒服。特别是监听部分,给了我很多新的思路。感谢分享这么好的内容!

  • 雨雨1206的头像
    雨雨1206 2026年9月23日 20:36

    读了这篇文章,我深有感触。作者对监听的理解非常深刻,论述也很有逻辑性。内容既有理论深度,又有实践指导意义,确实是一篇值得细细品味的好文章。希望作者能继续创作更多优秀的作品!