常用端口速查表

一、Web 与代理

80 与 443 只差一层 TLS。现象是“网站打不开”，先分清到底是服务没起来，还是只开了 HTTPS 而你在用 HTTP 访问。 另外 8080 / 8443 / 8888 都不是标准端口，只是约定俗成的备选，换软件前记得回配置文件里确认。

二、文件与共享

445 与 139 的区别：139 是 SMB 跑在老式 NetBIOS 会话之上的产物，445 是 SMB 直接跑在 TCP 上。 现代 Windows 共享只走 445，137/138/139 在跨网段时还经常被设备和运营商拦掉——共享看不到、连不上， 先确认 445 通不通，别在 139 上耗时间。

还有个大坑在 FTP：主动模式下数据连接由服务器反过来连客户端的高位端口，客户端在 NAT 后面基本连不上； 被动模式虽然改由客户端发起，但服务器要额外开放一段高位端口。所以“只放行 21 端口”的 FTP 通常是不通的。

三、邮件

记一条分工就够：25 是服务器发给服务器，587 / 465 才是客户端往外发信。 所以“邮件客户端发不出去”别去纠结 25；而“自建邮件服务器发不出”则往往是 25 出站被运营商或云厂商封了， 要单独申请解封。收信方面，多设备就用 IMAP（993），POP3（995）容易踩到“这台收完那台就没了”的坑。

四、远程管理

为什么 3389 千万不要直接暴露到公网：它是被扫描和暴力破解得最多的端口之一，一旦对外开放， 日志里很快就是成片的登录失败；历史上多个 RDP 漏洞也是被这样批量利用的。要做远程运维， 就套一层 VPN、走跳板机，或者在网关后面加多因素认证并限制来源地址。SSH 同理—— 把 22 改成别的端口只能躲开扫描器，禁用密码登录、只用密钥才是真正有效的做法。 VNC 自身的认证机制同样很弱，不要直接对外。

五、数据库

这一节里 27017、6379、11211 是被拖库和被当反射放大器用得最多的三个端口，共同点是默认几乎没有认证。 原则很简单：数据库只监听内网地址或 127.0.0.1，需要远程访问就走 SSH 隧道或跳板机， 公网安全组里一条都不要放。顺带一句，“改端口”不算安全措施，扫描器是全端口扫的。

六、基础设施与监控

DNS 一定要同时放行 UDP 和 TCP：绝大多数查询走 UDP，但大响应、区域传送、DoT 走 TCP， 只放 UDP 就会出现“小域名能解析、大记录查不到”这种看起来很玄的现象。 SNMP 的 161 和 162 方向相反：161 是管理端去问设备，162 是设备主动上报——监控收不到告警时先看 162 通不通。 还有 514 这条，很多设备日志默认发 UDP 514，而防火墙里 TCP 514 是另一个老协议，别顺手放错。

七、其他常被问到

这一段里的 VPN 和物联网端口有两个共同点：一是软件默认值不等于标准值，现场一定要看配置； 二是走 UDP 的（1194、51820）在防火墙上要放 UDP，只放 TCP 是彻底的无效操作。 另外 RTSP 和 FTP 一样有“控制端口之外还要额外开数据端口”的脾气，跨网段调监控时最容易卡在这里。

端口不通，按这个顺序查

顺序很重要：从里往外查，每一步都能把问题范围砍掉一半。 一上来就去翻防火墙，往往白折腾半天，最后发现是服务压根没起来。

1. 服务本身起没起。先在这台机器上连 localhost 试， 并用 ss -lntp（Windows 用 netstat -ano）看这个端口到底有没有处在 LISTEN 状态。 本机都连不上，那跟网络一点关系都没有，直接去翻服务自己的日志和配置。
2. 本机防火墙放没放。Linux 上是 firewalld / ufw / iptables，Windows 上是自带的防火墙。 放行时务必确认放的是 TCP 还是 UDP——这是最常见的放错。
3. 服务器上的安全组 / ACL 放没放。云主机、云数据库的安全组和网络 ACL 是独立于系统防火墙的另一层， 系统里放行了但安全组没放，照样不通；两层都要看。
4. 中间设备。路由器、交换机的 VLAN 划分、公司出口策略、旁路防火墙都可能拦。 一个很好用的判断：同网段能通、跨网段不通，问题基本就在这一层，而不是在两端主机上。
5. 是不是只监听在 127.0.0.1 而不是 0.0.0.0。 这条最容易被忽略：服务只绑了本地回环地址（很多软件默认如此，尤其是数据库和各类管理后台）， 本机测着一切正常，外面却永远连不上。改绑 0.0.0.0 或对应内网地址后才谈得上后面的排查。
6. 用 telnet IP 端口 或 curl -v 实测，别靠猜。 例如 telnet 192.168.1.1 445。通与不通是事实，比“我觉得应该是防火墙”靠谱得多。 注意端口写错、连到了另一台机器、或者本机 telnet 客户端没装，都会让你得到错误结论。

小提示：不想装 telnet 客户端时，可以用 curl -v telnet://192.168.1.1:445， 或者 PowerShell 里的 Test-NetConnection 192.168.1.1 -Port 445，效果一样。 另外，“被拒绝”和“超时”含义不同：明确拒绝通常是对方主机回了 RST（服务没监听或防火墙 reject）， 一直卡住超时则更像被中间的设备默默丢弃（drop），排查方向不一样。

几个容易搞混的点

第一，TCP 和 UDP 是两回事。 端口号在 TCP 和 UDP 里是各自独立的一套，防火墙规则也分开算。 DNS（53）、NTP（123）、SNMP（161/162）、Syslog（514）、DHCP（67/68）、TFTP（69）默认都走 UDP， 只放 TCP 就会出现“端口明明放行了却还是不通”的怪事。反过来，抓包时看到一堆 UDP 53 的流量也别惊讶，那是正常解析。

第二，“端口开着”不等于“服务正常”。 端口通只说明 TCP 三次握手成功了，仅此而已。访问网页返回 500、401、404，都算“通”； 连上 FTP 后一片空白、连着数据库却认证失败，也都是“通”。 反过来说，端口不通也未必是坏事——如果服务本身没问题却连不上，那才需要按上面的顺序往下查。 一句话：端口测的是“路”，不是“路尽头的店开着没有”。

第三，别忘了动态端口的存在。 客户端发起连接时会用一个高位随机端口作为源端口，这个范围叫临时端口（ephemeral port）： Linux 默认约 32768-60999，Windows 默认约 49152-65535。 这解释了一个常见现象：服务器主动来连你，常常被防火墙挡——因为每次的目标端口都不一样， 没法预先放行。FTP 主动模式、“回调/心跳回连”类的接口、某些监控上报都会踩到这个坑， 解决办法是改用被动模式、固定回连端口，或者干脆走反向隧道。

端口分配以 IANA 官方登记（Service Name and Transport Protocol Port Number Registry）为准； 上表中的 3000 / 5173 / 8000 / 51820 等属于软件默认值而非标准分配，不同软件还会临时占用非标准端口， 现场一律以实际的 netstat / ss 结果和软件配置为准。