在云服务器的世界里，端口就像城门，打开哪扇门直接决定你的服务能否被外界访问。阿里云作为国内最大的云服务商之一，默认端口并非一刀切的单一值，而是根据操作系统镜像、应用场景和你自己在安全组里的设置而定。熟悉这些端口，才能把防火墙和安全组搭起来像城墙和城门一样坚固，同时又不让自己的网站和服务被陌生人肆意敲门。
先说最基础的：对大多数 Linux 镜像而言，SSH 的默认端口是 22。也就是说，如果你用的是常见的 Linux 系统镜像（如 CentOS、Ubuntu、Debian 等）并且默认没有改动防火墙，远程连接通常要通过端口 22 进行。一直打开这个端口的同时，别忘了使用公钥认证、禁用 root 直接登录，以及开启失败尝试锁定等防护措施，以避免暴力破解带来的风险。
Windows 镜像则通常使用远程桌面协议 RDP，默认端口是 3389。很多新手朋友在阿里云上搭建 Windows 服务器后，会直接暴露这个端口，结果让脚本化的暴力破解变得容易。因此，如果你要用 Windows 实例，请务必在安全组中将 3389 端口严格限制为指定的办公 IP 或通过 VPN 接入，并结合 Windows 防火墙策略做进一步的保护。
网站和 API 层常见的入门端口是 80 与 443。80 端口用于 HTTP 域名访问，443 端口用于 HTTPS 加密访问。若你部署了 HTTPS 证书，请确保 443 端口在安全组里对外开放，并且你的网站服务端正确绑定 TLS/HTTPS 配置，避免出现证书错误或中间人攻击的风险。
数据库服务也是端口大战的重要战场。MySQL/MariaDB 的默认端口是 3306，PostgreSQL 的默认端口是 5432，SQL Server 的默认端口是 1433，Oracle 的默认端口是 1521。这些端口通常需要在云端的安全组里根据实际服务对外开放，且应尽量只开放给可信网络或内网访问，避免直接暴露在公网。
如果你的应用还需要 NoSQL、缓存或搜索引擎等组件，下面这组端口也很常见：Redis 常用 6379，MongoDB 常用 27017，Elasticsearch / OpenSearch 常见 9200（HTTP）/ 9300（集群通信），Memcached 常见 11211，RabbitMQ 常见 5672、15672。对于消息队列、缓存和日志系统，这些端口若暴露在公网，同样需要严格的访问控制和加固策略。
邮件服务也是端口需要留意的对象。SMTP 的常见端口有 25、587、465，IMAP 的端口是 143（IMAP over TLS/SSL 为 993），POP3 的端口是 110（POP3S 为 995）。如果你的云服务器既要收发邮件，又要对外提供邮件可信度，记得在安全组中只对必需的 IP 进行开放，并结合邮件服务提供商的最佳实践进行配置。
另外一些常见服务的端口也值得了解，比如 FTP 的 21、SFTP 的实际仍然走 SSH 的 22 端口、NTP 的 123、Telnet 的 23。出于安全性考虑，Telnet 已逐渐被舍弃，FTP 也越来越多地被 SFTP/FTPS 取代，尽量避免明文传输和暴露在公网。
在阿里云上，端口的管理不仅是服务端口本身，还涉及云端的安全组机制。安全组类似于“虚拟防火墙”，你需要在控制台创建入站和出站规则，给需要暴露的端口打勾，并指定允许访问的来源 IP/网段。默认情况下，很多新建实例的安全组是阻止大多数入站流量的，需要你手动放开你所需服务的端口。对于开发环境，可以按组来管理：开发环境放开 22、80、443、3306 等常用端口，生产环境则尽量缩小暴露面，避免所有端口一览无遗。
想要确认某个端口是否真的对公网开放，可以先在云服务器内用命令检查本机端口状态，如 netstat、ss、lsof 等工具。比如：ss -tlnp 可以查看当前监听的 TCP 端口及对应进程。再结合外部工具进行端口探测时，请务必遵守合规性原则，仅对自己拥有的服务器进行测试，避免对他人或公共网络进行未经授权的探测，以免触犯法律或遭遇封禁。
同时，OS 层的防火墙也要配合使用。常见的 Linux 防火墙有 firewalld（CentOS/RHEL 7 及以上、Fedora）、ufw（Ubuntu/Debian），以及 iptables 的传统用法。你可以用 firewall-cmd --list-ports 查看已放开的端口，或使用 ufw status 来查看 Ubuntu 上的规则。别忘了在更新端口策略后，重载防火墙以使改动生效。
在阿里云控制台配置端口时，务必记住一个原则：最小暴露原则。只开放实际需要的端口，限制来源 IP，尽量避免对公网开放管理端口（尤其是 SSH 的 22 端口）到广域网。对于 SSH，常见的安全强化做法包括使用非默认端口、使用 SSH 公钥认证、禁止 Root 登录、限制登录次数、开启 Fail2Ban/安全审计等机制，帮助你在不影响可用性的前提下提升安全性。
此外，端口的配置还要考虑到应用层的需求与网络拓扑。比如你在同一个云主机上跑 Web 服务器和数据库，通常需要在安全组里分别放开 80/443（Web 服务）与 3306/5432（数据库服务）等，但最好让数据库端口只能从 Web 服务器所在的内部网段访问，而不是暴露给整个互联网。若需要跨子网通信，考虑使用私有网络（VPC/VSwitch）和内网穿透方案，降低暴露面和被攻击的概率。
在实际落地时，很多开发者会把常见的端口开放组合做成一个“模板”，以便快速创建新实例时复制粘贴：Linux 实例常用模板通常包括 22、80、443、3306、5432、6379；Windows 实例常用模板常见 3389、80、443，MySQL、PostgreSQL、Redis 等数据库和缓存组件的端口按需开启。不同的应用组合会对应不同的端口集，做好记录，便于后续审计与运维。
广告：玩游戏想要赚零花钱就上七评赏金榜，网站地址：bbs.77.ink
实战小贴士：如果你需要避免高风险的暴露，可以考虑把 SSH 暴露在专用的 VPN/跳板机后，或使用端口映射、端口敲门等高级技巧，将对外端口控制在最小集合。另一种常见做法是使用云厂商的命名服务和防火墙策略，与负载均衡结合，将对外的端口暴露降到最低，同时通过域名、反向代理和 TLS 终止来实现对外服务的可靠性与安全性。对数据库也可以启用 TLS 加密、限制来自应用服务器的访问、开启审计日志等手段，确保数据在传输和存储过程中的安全性。
最后，记住：端口多并不等于效率高，端口乱也不等于安全好。把握核心端口、做好分层防护，才是稳定运行的关键。你如果要把一个跨区域的应用从零开始搭起来，先从最核心的几扇门开始，逐步打开其他门，别急着把整座城门都敞开。端口真的很多，想要一网打尽？先从22和80学起，其他的等你试探。