1. 端口号为什么会成为排查第一站1.1 一次连不上MySQL的半小时排障我印象里最深的一次值班事故和端口号有关。凌晨两点业务侧反馈订单写入超时我登录数据库服务器服务进程明明在跑mysqladmin ping也正常但应用侧就是连不上。现场几个人围着看了半天CPU、内存、磁盘全都正常最后有人冒了一句防火墙规则上周是不是改过查完安全组才发现新加的访问控制策略把应用服务器到数据库 3306 端口的放行规则覆盖了流量到了主机门口就被丢掉服务进程其实毫发无伤。那次之后我养成了一个习惯任何连接问题第一件事永远是确认端口而不是去看进程和日志。端口号虽然只是 0 到 65535 之间的一个数字但它同时承担了三件事——识别服务、隔离访问、暴露错误。凡是网络连接出问题九成都能在端口层面先找到方向。1.2 端口到底在替网络做什么从原理上说一台服务器只有一个 IP 地址但可以同时跑几十个服务。如果没有端口的概念数据包到了服务器之后不知道该交给哪个进程。传输层协议TCP 和 UDP引入端口号本质上是给同一台机器上的不同程序做多路复用和分流。这里有个容易忽略的点端口号本身没有归属于哪个服务的强制约束。系统只是规定了 0 到 65535 的范围并把前 1024 个称为知名端口确认某个端口对应某个协议服务靠的是约定俗成。也就是说你不用 8080 跑 HTTP非要用 8080 跑 SSH系统也拦不住你。理解这一点后面排查端口冲突端口被占时思路会特别清晰。1.3 三类端口的划分与选择逻辑端口按范围分为三档范围类型特点与用途0 - 1023知名端口预留给系统级标准服务通常需要管理员权限绑定1024 - 49151注册端口由各类软件和业务服务使用如 MySQL 3306、Redis 637949152 - 65535动态端口客户端发起连接时随机分配也用于临时回包我建议所有做后端开发、运维、网络安全相关工作的读者至少要把知名端口和常用注册端口的对应关系记熟。不是为了背题而是排障速度快。很多人遇到端口不通第一反应是改防火墙规则结果改了也没用——因为服务根本没在那个端口监听。记住端口号能帮你把以为是网络问题和其实是配置问题这两类场景迅速分开。2. 从零梳理常用端口清单按服务类型分组记忆2.1 Web 与远程管理类Web 服务和远程管理是日常打交道最多的场景端口号相对固定服务端口传输层协议说明HTTP80TCP明文网页访问HTTPS443TCP加密网页访问HTTP 代理/网关8080TCP常用于代理解析或 Web 缓存开发服务器8000 / 8888TCPPython、Node 开发服务常用SSH22TCP安全 Shell远程管理主力和 SCP/SFTP 通道Telnet23TCP明文远程登录生产环境已不建议使用RDP3389TCP远程桌面连接这里值得多说一句 8080 和 8000。很多新手会把它俩当成 HTTP 的默认端口其实它们只是开发框架为了方便设置的非标准端口。一旦上了生产环境通常都会通过负载均衡把 80/443 映射到后端实际监听端口所以你在服务器上看到 Nginx 监听 80后面可能还跟着一堆业务进程监听 8000、8080 之类的非标准端口这是正常的不是重复占用。2.2 文件传输与邮件类文件传输类端口有个经典组合FTP 的 20 和 21。21 是控制端口负责传输命令20 是数据端口负责实际传文件。以前配置 FTP 主动模式时必须把这两个端口都放行漏一个就可能出现能登录但列不出目录的诡异现象。服务端口传输层协议说明FTP 控制21TCP命令传输FTP 数据20TCP主动模式下传输文件数据SFTP22TCP挂在 SSH 下不需要额外端口SMTP25TCP邮件发送SMTP 加密465TCPSMTPSPOP3110TCP邮件接收POP3 加密995TCPPOP3SIMAP143TCP邮件接收支持多目录同步IMAP 加密993TCPIMAPSSMB445TCPWindows 文件共享运维中也用于远程管理实际运维中SMB 445 和 MSSQL 的 1433 往往容易在同一个场景下出现因为 Windows 环境下文件共享和数据库服务经常在同一批服务器上。我处理过不少案例安全组只开了 1433结果备份脚本走 445 共享目录怎么跑都失败最后才想起共享端口没放行。2.3 数据库与缓存类数据库端口我单独整理成一张表因为它们在各行各业中都是出现频率最高的连接串参数服务默认端口说明MySQL3306最常用的关系型数据库MySQL X Protocol33060MySQL 8 新增的 X 插件通信端口PostgreSQL5432另一个主流关系型数据库Oracle1521商业数据库默认监听端口SQL Server1433Windows 生态常用数据库MongoDB27017文档型数据库Redis6379缓存、内存数据库Memcached11211内存对象缓存数据库端口有个特点几乎都可以在配置文件里改但大家基本都不改。改成非标准端口能规避一部分扫描攻击但也带来维护成本——所有连接方都得跟着改。我见过有团队把 MySQL 改成 3307运维脚本里写死 3306上线时一片红。我的建议是除非有明确安全合规要求否则数据库端口保持默认把防护重心放在网络隔离和访问控制上。2.4 消息队列与中间件类消息中间件的端口是排障时最容易混乱的领域因为一个组件往往不是只监听一个端口服务端口说明Kafka9092客户端连接端口Kafka Connect8083数据集成服务端口RabbitMQ5672AMQP 协议通信端口RabbitMQ 管理界面15672Web 管理后台RocketMQ9876NameServer 端口ZooKeeper2181分布式协调服务Elasticsearch9200HTTP 接口Elasticsearch 节点通信9300集群内部通信Consul8500服务注册与发现 HTTP 接口每次处理消息队列连不上的问题时我都会先问一句你连的是哪个端口上面这张表里Kafka 的 9092 和 ZooKeeper 的 2181 是同一个集群里两个完全不同的端口都开才能跑通业务链路。如果只开了 2181生产者能连接但数据不一定能发到 Broker这类问题看客户端日志时容易被误导。2.5 基础服务与运维类底层基础设施类端口日常排查网络问题时也常见服务端口传输层协议说明DNS53TCP / UDP域名解析几乎都用 UDP 查询TCP 用于区域传送DHCP67 / 68UDP67 服务端68 客户端NTP123UDP时间同步SNMP161 / 162UDP161 查询162 陷阱上报Syslog514UDP系统日志转发PingN/AICMP没有端口ICMP 协议这里想强调一个特别容易误解的点Ping 命令用的是 ICMP 协议不走 TCP 和 UDP所以它根本没有端口号。很多人在防火墙里放行了所有 TCP/UDP 端口但 Ping 不通就开始怀疑安全组规则实际原因是云平台默认禁掉了 ICMP。你需要在安全组里单独放行 ICMP 协议才能让 Ping 工具正常工作。2.6 快速查找端口映射的辅助参考网上有大量端口大全的资料但我不推荐全背。日常主用服务的端口用熟冷门端口遇到时用本地文档查即可。有一个非常有用的技巧Linux 系统自带/etc/services文件里面记录了系统已知的绝大多数端口与服务名映射。忘了某端口属于哪个服务直接grep 端口号 /etc/services就能查到比上网搜索更快也避免了搜索引擎里过时信息的误导。3. 端口排查实战从定位到验证的完整链路3.1 Linux 下快速定位端口占用先说什么命令最常用。很多人还停留在netstat -antp但新版本 Linux 发行版里netstat不一定预装而且在大连接数场景下性能很差。我现在的习惯是用ss命令# 查看所有监听的 TCP 端口和对应进程 ss -tlnp # 精确查看某端口谁在监听 ss -tlnp | grep 3306 # 查看 UDP 端口占用 ss -ulnp如果你的环境必须用netstat命令参数是netstat -tlnp同样可以看清端口状态、监听地址和进程名。这里有个细节-p参数能显示进程信息但需要 root 权限普通用户看到的进程号是隐藏的。遇到这种情况先用sudo或者ps配合进程名查询。3.2 排查端口被占的出发角度端口被占时不要只盯着端口号本身还要看监听地址。同端口的两种监听规则是完全不同的概念# 只监听本机回环地址外部网络无法访问 ss -tlnp | grep 8080 # 监听所有网卡外部可以访问 ss -tlnp | grep 0.0.0.0:8080如果服务配置绑定了127.0.0.1:8080远程机器当然连不上但ss显示端口确实存在本地telnet 127.0.0.1 8080却通。这种本地通、远程不通的现象根因往往不是防火墙而是监听地址配置错了。我接手的故障里这类问题占比很高尤其是从开发机复制配置到生产机时忘了把127.0.0.1改回0.0.0.0。3.3 远端端口连通性验证的三种手法验证远端服务器某个端口是否开放有几种常用方式各自适用场景不同# 方法一telnet适合快速判断 TCP 端口通不通 telnet 192.168.1.100 3306 # 方法二ncnetcat比 telnet 更灵活可以发送探测数据 nc -vz 192.168.1.100 3306 # 方法三nmap端口扫描的老牌工具适合批量探测 nmap -p 22,80,3306 192.168.1.100三者的区别在于telnet只是建立一个 TCP 连接就退出适合粗筛nc可以指定超时时间适合在脚本里做循环探测nmap能返回端口状态包括 open、closed、filtered其中filtered意味着防火墙或安全组拦截。如果你看到filtered就要去查安全组规则而不是继续折腾服务本身。3.4 端口不通排查链路以A 机器连不上 B 机器的 3306为例我推荐按下面链路逐层排查B 机器本地确认服务监听ss -tlnp | grep 3306确认端口在监听且监听地址非127.0.0.1。B 机器本地回环验证mysql -h 127.0.0.1 -P 3306 -u user -p判断数据库服务和密码本身没问题。B 机器防火墙验证查看firewalld或ufw状态确认 3306 已放行或者临时停掉防火墙再做对比测试。云安全组验证登录云控制台查看对应实例/子网的安全组入方向规则确认源地址和端口范围匹配。A 机器出口验证确认 A 机器的出口 IP 落在安全组允许的源地址范围内NAT 环境尤其注意。网络抓包确认tcpdump port 3306 -n观察 SYN 包是否有回包有回包说明网络层通问题就在服务层无回包则卡在防火墙或安全组。这套链路几乎适用于所有 TCP 服务MySQL 只是例子。遇到连不上先别急着怀疑代码或配置把端口链路走一遍往往几分钟就能定位。4. 容器与云环境下的端口映射陷阱4.1 Docker 端口映射的三种常见形态容器普及之后端口的含义又多了一层。容器里跑的服务仍然监听端口但你在宿主机上看到的不一定是容器内端口而是映射出来的端口。Docker 提供三种常见的映射写法# 随机映射把容器 8080 暴露到宿主机的随机端口 docker run -p 8080 nginx # 指定端口映射 docker run -p 8080:80 nginx # 绑定特定网卡并指定端口 docker run -p 127.0.0.1:8080:80 nginx第一种写法我在生产环境见过不少坑自动分配的随机端口毫无规律后续防火墙规则、负载均衡配置全都要跟着动态调整。正规做法是明确指定端口并且尽可能固定绑定在需要的网卡上避免暴露面无谓扩大。4.2 localhost 在容器内外不是同一个概念容器网络有一个特别反直觉的地方在容器内部localhost指的是容器自己在宿主机上localhost指的是宿主机。如果容器里的 MySQL 监听的是127.0.0.1:3306很可能并没有绑定到 Docker 的虚拟网卡上宿主机端口映射也就无法把请求转发进去。典型表现是docker ps显示端口映射正常但宿主机访问3306一直超时。排查方式很简单进入容器看监听地址docker exec -it 容器ID bash ss -tlnp | grep 3306如果监听地址是127.0.0.1把配置改成0.0.0.0再重启服务即可。这个坑在把传统部署方式迁移到容器时特别常见属于代码没变、行为变了的典型案例。4.3 云安全组和主机防火墙的双层拦截云环境下的端口访问通常要过两层关卡虚拟网络层的安全组Security Group和云主机操作系统自身的防火墙如 firewalld/iptables 或 Windows 防火墙。我在很多生产系统上看到的情况是安全组明明放行 443 端口但操作系统的 firewall 条目在初始镜像里默认 deny结果内外网全访问不了。正因为是两层排障时一定要遵循由内到外的顺序先在本地确认端口监听再关掉或正确配置系统防火墙最后检查安全组。不建议一开始就在云控制台反复改规则那样很难定位到底是哪一层在丢包。稳妥的验证方式是可以临时放行某个端口观察短暂效果测试完成立即删除避免留下不必要的开放端口。5. 同端口不同配置那些被混淆的典型场景5.1 80 端口上的多服务共存与端口冲突80 端口是 Web 服务的默认端口因此也成了所有 HTTP 应用的争夺焦点。一个服务器上同时装 Nginx、Apache、Tomcat然后启动第二个 Web 服务时报端口被占用这种事我遇见过很多次。根因不是端口不够用而是服务配置里默认绑定了 80。解决办法通常是把其中一个服务改到其他端口比如把 Tomcat 的server.xml里 Connector 端口从 8080 改为 8081或者让 Nginx 做反向代理转发到后端服务从而避免多个进程直接抢同一个端口。端口冲突的排查命令很简单ss -tlnp | grep 80看到哪个进程占用了 80 就去处理对应配置。如果发现 Nginx 和 Apache 同时存在于冲突名单里就要考虑是否真的需要两个 Web 服务进程同时运行很多时候架构本身就有冗余。5.2 MySQL 的 3306 与 33060 为什么容易弄混MySQL 8 引入 X Protocol 后默认监听 33060 端口。但很多老运维对 33060 不熟悉在做连接串配置时把端口从 3306 改成 33060或者反过来导致客户端文错误地连到别的端口服务。33060 主要用于 MySQL Shell 和 X DevAPI它提供的是另一种访问协议可以理解为 MySQL 的新型接口。日常业务代码大多数走 3306 的经典协议。如果代码连接串写的是 33060而服务器上根本没有开 X Plugin 支持结果是连接超时但这并不代表 MySQL 主服务故障。排这类问题最直接的办法先看应用的连接串再对照数据库进程的监听端口。用连接串里写的端口去ss确认能一步定位。5.3 端口复用一个端口承载多个协议的情况还有一种更隐蔽的情况某些软件会用一个端口承载多种协议典型如 SSH。SSH 服务不仅支持远程登录还承载 SFTP、SCP 以及端口转发。很多人在防火墙里只放行了 22 端口就以为文件上传都走通了实际 SFTP 走的也是 22这个过程里通常还要配合认证和权限配置。再比如 Consul 的 8500 端口同时提供 HTTP API 和 DNS 解析接口Elasticsearch 的 9200 端口既是 REST 接口也是节点间通信入口。你用ss看到某个端口被某个进程监听不代表所有协议都支持。遇到客户端报请求被拒绝时除了查端口通断还要确认服务是否开放了对应的协议功能。6. 我的端口记忆方法与管理习惯6.1 关联记忆法把端口串成故事端口号太多记不住怎么办我的方法是把相关端口放到场景里去记。比如远程登录三兄弟SSH 22、Telnet 23一个安全一个明文从数字上也连续容易成组记忆。再比如邮件整套流程SMTP 25 发送POP3 110 和 IMAP 143 接收加密版本在原有端口前加了一个 4 或者 9像 465、995、993。这套端口连起来看就是一个完整的邮件收发链路。当你在防火墙规则里看到这一串端口不用逐一匹配服务名脑子里就能浮现出邮件系统大概的拓扑。缓存和数据库也有规律MySQL 的 3306、Redis 的 6379、MongoDB 的 27017没有太多逻辑关联但你可以用自己的业务记忆来接。比如我对 6379 的印象就来自于它的配置文件和项目里的一段缓存服务代码用多了自然记住。6.2 本地维护一个快捷查询文件我电脑里有一个ports.md文件专门记录工作中用过的所有端口及用途。每接入一个新系统、发现一个新端口就追加一行。遇到线上问题需要快速确认时直接搜这个文件比上网查找更准确因为它本身就是自己踩坑经验的沉淀。# 常用端口速查 - 3306 MySQL 主库 - 3307 MySQL 备用集群 - 6379 Redis main - 6380 Redis 旧版本已迁移 - 8081 大数据平台 API 网关 - 9200 Elasticsearch REST 接口这个习惯看起来很简单但在多环境、多项目的背景下能省下大量的认知负担。建议每个项目维护一份端口注册表记录每台机器的端口用途、绑定地址、放行来源。6.3 配置端口的几条实操建议折腾了这么多年端口相关问题最后给大家总结几条实操建议。第一进程启动前先确认端口规划特别是多服务部署在同一台机器时把端口规划写清楚避免随意占用。第二安全组和系统防火墙规则要有注释写明放行的端口用途、来源和过期时间避免三个月后看到一条规则不知道是谁、为什么开的。第三改动端口后一定要全链路验证包括服务监听、防火墙、安全组、负载均衡四层只改一处往往引发新故障。端口不是简单的数字它是网络世界里最直接的服务身份证。把常用端口吃透、把排查链路跑熟很多诡异的网络问题在你面前就只剩下了清晰的三步看监听、看防火墙、看安全组。这套方法论从单机时代到容器时代再到云原生环境都不过时也是我处理线上故障时最依赖的底牌。
