服务器逻辑端口就是一台服务器对外提供服务的“门牌号”，按IANA标准分为公认端口、注册端口和动态端口三类，日常运维打交道最多的是80、443（网站）、22（远程管理）、3306（数据库）这几个。
服务器常用端口有哪些？先分清三类
公认端口：默认的“老牌门牌”
端口号0到1023是公认端口，也叫周知端口，这类端口被大部分网络服务默认绑定，相当于行业里约定俗成的编号，比如HTTP服务一来就找80，HTTPS服务默认蹲在443，SSH远程登录固定用22，服务器装好系统后，这些服务往往自动监听对应端口，不需要额外配置。
常见公认端口速览：
- 21：FTP文件传输
- 22：SSH远程管理
- 25：SMTP邮件发送
- 53：DNS域名解析
- 80：HTTP网页访问
- 110：POP3邮件接收
- 143：IMAP邮件接收
- 443：HTTPS加密网页
这类端口是攻击者扫描的首要目标,比如22端口暴露在公网上，每天会收到大量暴力破解尝试，业内专家指出，管理类服务最好改成非默认端口，或者严格限制来源IP。
注册端口：软件自己挑的“常态门牌”
1024到49151是注册端口范围，一些知名软件和数据库默认使用这里的端口，这些端口不属于系统强制分配，但软件厂商选定了某个编号，用的人多了就成了事实标准。
- 3306：MySQL数据库
- 3389：Windows远程桌面
- 6379：Redis缓存
- 8080：HTTP备用服务
- 9200：Elasticsearch搜索服务
- 27017：MongoDB数据库
这里有个典型坑：很多人装了Redis没改配置，6379直接暴露公网，被挖矿病毒扫描后植入木马，数据库和中间件端口原则上只允许内网访问，不要映射到公网。
动态端口：用完就还的“临时门牌”
49152到65535是动态端口，也叫临时端口，客户端向服务器发起请求时，系统随机从这段范围分配一个端口作为回话通道，数据传输完就释放，这段端口一般不需要手动放行，防火墙会结合连接状态自动处理回包。
| 端口范围 | 类型 | 典型服务 | 对外暴露建议 |
|---|---|---|---|
| 0-1023 | 公认端口 | HTTP、SSH、FTP | 按需放行，管理类必须限制IP |
| 1024-49151 | 注册端口 | MySQL、Redis、Tomcat | 禁止公网直接访问 |
| 49152-65535 | 动态端口 | 客户端临时回话 | 无需手动配置 |
服务器需要开放哪些端口？按业务场景定
Web服务器场景：80和443打底
假设你买了一台云服务器放公司官网,那么在安全组里至少要放行80和443端口，80负责普通HTTP访问，443负责HTTPS加密访问，如果你用宝塔面板或手动配了SSL证书，443就成了主通道，管理服务器还需要放行22（Linux）或3389（Windows），但建议把来源IP限制成你自己的固定公网IP。
数据库与中间件场景：只开内网
业务跑起来之后,往往要在服务器上装MySQL和Redis，这时候需要明确一点：3306和6379只该监听内网地址，比如应用服务器和数据库服务器在同一台机器上，程序通过127.0.0.1连接，端口根本不需要暴露到公网，如果数据库单独部署一台服务器，那就在安全组里放行应用服务器私网IP对3306的访问，而不是放行0.0.0.0/0。
游戏与自定义应用场景：端口区间按需开放
游戏服务器比较特殊,比如Steam平台的经典射击游戏CS:GO默认使用27015端口，Minecraft Java版默认使用25565端口，这类服务通常需要玩家直连，端口必须公网可访问，如果你的应用采用自定义协议，记住一个原则：能用一个端口就不要开放多个，能用区间就不要逐个放行。
Linux查看端口占用命令：三条够用
第一条：netstat -tlnp
netstat -tlnp
-t表示查看TCP连接，-l表示只看监听状态，-n用数字显示端口，-p显示对应进程PID，输出结果里能看到协议、本地地址、进程名称三列信息，比如看到0.0.0:3306说明MySQL正监听所有网卡，如果只看到0.0.1:3306那就只有本机才能连。
第二条：ss -tlnp
ss命令是netstat的现代替代品,输出更快：
ss -tlnp
参数含义一致,某些精简版系统可能没有预装netstat，用ss更保险。
第三条：lsof -i:端口号
查某个特定端口被谁占用：
lsof -i:8080
输出会显示PID和进程名,比如运行Java程序占用8080，你想停掉它，先用这条命令拿到PID，再kill -9 PID即可。
Windows服务器端口查看方法
Windows服务器用图形界面更方便,在“运行”里输入resmon打开资源监视器，切到“网络”选项卡，能看到所有监听端口和对应进程PID，命令行方式则是：
netstat -ano | findstr 3306
-a显示所有连接，-n数字形式，-o显示PID，findstr相当于Linux的grep，过滤出包含3306的行，拿到PID后，在任务管理器里定位进程名。
服务器对外开放端口怎么选？遵循最小化原则
行业共识认为,端口开得越少，暴露面越小，选端口时按这个顺序思考：
- 这个端口服务于什么业务？ 不知道用途就不开。
- 业务必须公网访问吗？ 管理后台、数据库、日志系统这些都不该公网访问。
- 能否换一个非默认端口？ SSH换成22026，Redis换个五位数的端口，能避开绝大多数自动扫描脚本。
云安全组规则配置实操
以主流云厂商控制台为例,安全组规则的优先级顺序是：先拒绝再放行，建议这样配置：
- 入方向只放行80、443（来源IP：0.0.0.0/0）
- 入方向放行22或自定义SSH端口（来源IP：你的办公网IP段）
- 出方向不用特殊限制,默认允许全部
- 其他端口一律拒绝
服务器端口连不上？排查三步走
端口没通时,别急着怀疑服务挂了，按顺序逐个排查。
第一步：确认服务在监听，Linux下执行ss -tlnp | grep 端口号，如果输出为空，说明服务根本没启起来，检查进程状态和配置文件，比如Nginx没启动，80端口自然不存在。
第二步：检查系统防火墙，CentOS系执行firewall-cmd --list-ports查看放行列表，Ubuntu用ufw status，如果规则里没有对应端口，就执行放行命令：
firewall-cmd --zone=public --add-port=8080/tcp --permanent firewall-cmd --reload
第三步：看云安全组，很多用户本机防火墙关了还是连不上，因为云控制台的安全组规则没放行，进入实例所在的安全组，添加入方向规则，协议选TCP，端口填对应数字，来源选0.0.0.0/0或指定IP，保存后立刻生效。
快速测试端口通不通
在本地电脑命令行执行：
telnet 服务器公网IP 8080
出现黑屏或版本信息,说明端口通了，没通的话会提示无法打开到主机的连接，Windows系统telnet默认未启用，可以用PowerShell里的Test-NetConnection IP -Port 8080替代，也能用在线端口扫描工具测试，但要选靠谱的平台，避免敏感信息泄露。
端口配置文件都在哪里改
大多数服务监听端口的配置都有固定位置：
- Nginx：
/etc/nginx/nginx.conf里的listen字段 - Apache：
/etc/httpd/conf/httpd.conf或/etc/apache2/ports.conf - MySQL：
/etc/my.cnf里的port=3306 - Redis：
/etc/redis/redis.conf里的port 6379 - SSH：
/etc/ssh/sshd_config里的Port 22
改完端口后需要重启对应服务,这里有个易错点：SSH改端口后，如果防火墙或安全组没放行新端口，你会直接被关在门外，操作前务必先放行新端口再改配置。
日常运维的端口自检习惯
服务器跑得久了,端口管理容易留下死角，建议形成这样的自检节奏：每次上线新服务前，先规划端口清单，记录服务名、端口、协议、是否需要公网访问四项信息，每月查一次ss -tlnp，审计当前所有监听端口，把已经停用服务的端口从防火墙里摘掉。
安全扫描工具比如Nmap也可以定期跑一遍：
nmap -sT -p 1-65535 服务器IP
扫出来的开放端口如果和你端口清单对不上,就去查嫌疑进程。
服务器逻辑端口开放需要注意什么
改默认端口一定能防攻击吗？
改端口只能防住“无差别扫描”，防不住定向攻击，攻击者用全端口扫描照样能发现你，但只要改了默认端口，就能过滤掉绝大多数脚本扫描流量，总体收益明显，改完端口后务必同步更新防火墙和安全组规则。
动态端口打不开是什么原因？
多数情况下是安全组回包规则设置太严格,如果服务器同时跑FTP，FTP主动模式下需要放行20和21端口，被动模式则需要放行30000-40000左右一段端口区间，普通网站应用不存在这个问题，TCP连接回包会被状态防火墙自动识别，不需要额外放行动态端口段。
端口扫描显示开放了很多端口是正常的吗？
不正常,正常业务服务器公网开放端口通常在5个以内，比如80、443加一个SSH管理端口，如果扫描结果超过了这个范围，要么是业务需要但没记录在册，要么是服务器已经被植入后门程序，先用ss -tlnp排查所有监听进程，对照端口清单逐一确认身份。
端口管理的本质就是最小暴露、精确管控，把每一个对外通道都握在自己手里，知道它是谁、为什么存在、业务用不用得上，这三件事想清楚，服务器就稳了一大半。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/783064.html
