开放端口分3类，真正要关的只有少数

服务器上跑着十几个监听端口，是常态；真正需要动手关掉的，一般不超过三个。开放端口分3类真正要关只有少数——这话听着有点像标题党，可你把 ss -tulnp 的结果拉出来逐行看一遍，比例差不多就是这样。麻烦的地方在于，多数人一上来就问「哪些端口要关」，却很少先问一句「这些端口在听谁的」。

开放端口分3类真正要关只有少数，先看监听地址而不是端口号

ss -tulnp 的输出里，Local Address 那一列比端口号本身更有信息量。写成 127.0.0.1:3306 或者 :::1 的，只有本机能连上去；写成 0.0.0.0:3306 或者 *:6379 的，等于这台机器所有网卡都在听，公网连不连得上只取决于前面那道防火墙放不放行。老一点的系统用 netstat -tulnp，看的东西一样。所以判断一个端口该不该动，顺序是：先看它在哪个地址上监听，再看这个服务是给谁用的，最后才轮到讨论关不关。顺序掉过来，就容易出现把内网服务当成后门砍掉、又把绑在 0.0.0.0 上的数据库当成「本地服务」放着不管的情况。

第一类：对外提供服务的，关错了网站直接掉线

80 和 443 属于必须开的那一档，这两个一关，站点在浏览器里直接打不开，没什么讨论空间。SSH 的 22 也归这一档，只是它不该对所有来源开放——限制成自己常用的几个 IP，或者至少改成密钥登录、禁掉 root 直连，比关掉它有意义得多。面板类工具的端口（不少默认落在 8888 那一档）同理，能开，但要绑 IP、要改掉默认入口路径。这一类的关键词是「限制来源」，不是「关闭」。判断标准也简单：这个端口关了，业务会不会立刻断？会断的，就归到这一类，别在它身上折腾。

第二类：本机内部用的，被绑到公网才成了漏洞

3306、6379、27017、11211 这些，设计上就是给本机程序调的，压根没打算让外面连。MySQL 在 /etc/my.cnf 里写 bind-address = 127.0.0.1；Redis 在 redis.conf 里把 bind 收成 127.0.0.1、protected-mode 保持 yes；MongoDB 看 /etc/mongod.conf 的 bindIp；Memcached 启动参数里带 -l 127.0.0.1。这些服务一旦以 0.0.0.0 露在外面，又没设密码或者密码很弱，被人扫到之后干什么都不用你同意。还有一个特别容易被忽略的来源：docker run -p 3306:3306 会把容器端口直接映射到宿主机所有网卡上，配置文件里那行 bind-address 完全不起作用，这个坑过不少人。要映射就写 -p 127.0.0.1:3306:3306。

第三类：装软件顺手带进来的，真正要关的就在这儿

装面板、装监控、装个备份脚本，经常会顺手带起一两个 web 服务，端口开在 8080、9000 这类位置，装完就忘。旧项目迁走之后留下的测试目录、临时给同事看的演示站、某次排查问题时开的调试端口，都属于这一档。它们的共同点是不在业务链路里，关掉没人会喊。真正需要你动手的那少数，基本都从这一类里出。清理办法不用多高级：把 ss -tulnp 的输出和 systemctl list-units、docker ps、crontab -l 对着看一眼，对不上号的就查，查不明白的先停掉观察半天。这个笨办法比任何扫描器都靠谱。

云主机上有两道门，只关一道等于没关

云主机的端口能不能连上，卡在两处：控制台里的安全组（有的厂商叫防火墙策略），和机器里的 iptables、firewalld、ufw。两边都放行才通，任何一边拦着都进不来。常见的乌龙是安全组里删了规则、机器里的服务还开着，自己以为关干净了；反过来也有机器里 firewall-cmd 关了一堆、安全组全放行，实际暴露面一点没变。排查顺序建议从机器里往外查：先 firewall-cmd –list-all 或者 ufw status，再回头看控制台。安全组的入口和字段各家的叫法不太一样，以服务商控制台的说明为准，别照着网上截图瞎点。

把 SSH 换个端口，别当成安全方案

22 改成 2222 这类做法，作用只有一个：少掉一大截无差别扫描的噪音，日志清净点。它不减暴露面，也不挡针对性的探测。真想收紧，密钥登录、禁 root 直连、失败次数限制、日志定期翻一遍，这几样才是实打实有用的。另外很多人改完端口忘了同步安全组，第二天自己都连不上，还得去控制台开 VNC 救回来，这种场面运维群里隔三差五就有人发一次。

照着走的检查顺序

第一步，ss -tulnp 全量导出来，把监听在 0.0.0.0 和 * 的行先标黄。第二步，逐行对照业务：网站相关、面板相关、SSH 归第一类，数据库和缓存归第二类，剩下不认识的全归第三类待查。第三步，第二类改配置文件里的 bind 地址，改完必须重启服务再用 ss 复核，别只看配置文件就以为生效了。第四步，第三类里对不上号的进程，用 systemctl status 或者 docker ps 找它的来历。第五步，云控制台的安全组和机器里的防火墙对齐。第六步，隔一天再翻业务访问日志，确认没把正常流量关在外面。

最后提醒一句：端口清单是会自己长出来的，装一次软件就多那么一行。隔几个月重新跑一遍 ss，比当初记在文档里那份「最终版」靠谱得多。