Azure 虚拟机 微软云服务器常用端口设置

你有没有试过——凌晨三点，盯着屏幕里那个红得刺眼的「连接超时」错误，一边猛敲键盘一边怀疑人生：我明明开了3389端口，为啥远程桌面还是连不上？

别急，这不是你的错。这大概率是 Azure 云服务器上最经典的「端口幻觉」现场：你以为它开着，其实它正被三层防火墙联手按在地上摩擦——网络安全组（NSG）、Windows 防火墙、甚至 SQL Server 自带的协议监听开关，三重门神，缺一不可。

今天咱不讲虚的，不列干巴巴的端口表，不甩一堆 Azure CLI 命令截图完事。咱们就坐下来，泡杯茶（或者咖啡，看你熬到几点），把微软云服务器上那些「天天见、常报错、一配就懵」的端口，掰开揉碎了聊明白。

先划重点：端口不是「开关」，是「关卡」

Azure 的端口管理，本质是「漏斗式放行」：外网请求要穿过「云层（NSG）→ 虚拟机操作系统层（系统防火墙）→ 应用层（服务本身是否监听）」三道门。少开一道？对不起，直接拒之门外。

所以，别再问「3389端口怎么开」，而要问：「NSG 放了没？Windows 防火墙放了没？RDP 服务启没启动？本地策略锁没锁？」——这才是真问题。

RDP（3389）：远程桌面的命脉，也是黑客最爱的靶心

没错，3389 是 Windows VM 的灵魂端口。但 Azure 默认不开放它。为啥？因为微软比你还怕你把自己搞挂。

✅ 正确姿势：

• NSG 规则：新建入站规则，源地址选「Any」或精确 IP 段，协议 TCP，端口范围 3389，优先级建议 100-200（越小越靠前），描述写「RDP-Prod-TeamOnly」；
• Windows 防火墙：控制面板 → Windows Defender 防火墙 → 允许应用通过防火墙 → 勾选「远程桌面」，且确保「专用」和「公用」都打钩；
• 系统设置：「系统属性 → 远程 → 允许远程连接到此计算机」必须勾选；若用域环境，还得确认「仅允许运行使用网络级别身份验证的远程桌面的计算机连接」是否与客户端兼容。

Azure 虚拟机 ⚠️ 血泪教训：曾有客户把 NSG 开了，防火墙也放了，结果死活连不上——最后发现，他用的是 Azure AD 登录的 Windows VM，而默认 RDP 只认本地管理员账户……（默默掏出小本本记下：AD 账户需额外加组「Remote Desktop Users」）

SSH（22）：Linux VM 的呼吸口，别让密钥白生成

22 端口对 Linux 来说，就像空气对人。但 Azure 创建 Ubuntu/CentOS VM 时，默认只在 NSG 放行 22，系统防火墙（UFW/iptables）却是关闭状态——等等，关着？那咋连上的？答案是：UFW 默认未启用，iptables 规则为空，等于「门开着但没人守」。

✅ 安全加固建议：

• 先 sudo ufw enable 启用防火墙；
• 再 sudo ufw allow OpenSSH（比写端口号更稳妥，自动适配配置）；
• 顺手 sudo ufw status verbose 确认状态；
• 终极操作：改 SSH 默认端口（比如 2222），并在 NSG 和 /etc/ssh/sshd_config 里同步更新——能筛掉 90% 的暴力扫描脚本。

Web 服务：80/443 不是「默认畅通」，而是「默认沉默」

很多人部署完 Nginx/Apache，浏览器输公网 IP，显示「无法访问此网站」，第一反应是「DNS 没配好」……其实，八成是端口没动。

✅ 必做三件事：

• NSG 必须放行 80（HTTP）和 443（HTTPS）入站；
• Linux 上检查 sudo ufw status，Windows 上确认 IIS 或 Nginx 所在进程没被防火墙拦截；
• 最关键一步：检查 Web 服务是否绑定 0.0.0.0:80，而非 127.0.0.1:80！很多新手用 Docker 或本地调试模式启动，只监听回环地址，外网当然打不通。

💡 小技巧：用 curl -v http://localhost 测试本地通不通；再从另一台 Azure VM telnet your-ip 80，判断是服务问题还是网络问题。

数据库端口：SQL Server（1433）、MySQL（3306）、PostgreSQL（5432）

这些端口，开得越早，风险越高。Azure 官方强烈建议：绝不暴露数据库到公网。但现实很骨感——测试环境、临时迁移、合作伙伴对接，有时真得开。

✅ 最低限度操作：

• NSG 规则严格限制源 IP（比如只允公司出口 IP 或跳板机）；
• SQL Server：SQL Server Configuration Manager → 协议 → TCP/IP → 属性 → IP 地址页 → 确保「IPAll」下的 TCP 端口填了 1433，且「TCP 动态端口」留空；
• Windows 防火墙单独添加入站规则，协议 TCP，端口 1433，作用域限定为可信子网；
• 务必禁用 SA 账户，强制使用强密码+登录失败锁定策略。

🚨 真实翻车现场：某客户开了 1433，结果被扫出弱口令，半小时内数据库被加密勒索……后来发现，他连「混合模式认证」都没关，SQL Server 还开着「SQL Server Browser」（UDP 1434），等于把家门钥匙焊在门把手上。

其他高频端口速查表（带避坑备注）

• 53（DNS）：除非你自建 DNS 服务器，否则不用开；Azure 内置 DNS 已处理；
• 135/137-139/445（SMB/NetBIOS）：文件共享常用，但公网暴露=送分题，仅限 VNet 内部通信；
• 3389 + 443 组合：用 Azure Bastion 时，无需开 3389 到公网，Bastion 自动走 443 加密代理，安全又省心；
• 自定义端口（如 8080、9000）：务必在 NSG 和系统防火墙双重确认，且避免用常见攻击端口（如 21、23、110）。

终极排错三板斧

1. 抓包法：在 VM 内用 tcpdump -i any port 3389（Linux）或 Wireshark（Windows），看请求到底有没有进来；
2. 跳过 NSG 法：临时删掉 NSG，用 Azure 串行控制台直连 VM，执行 netstat -ano | findstr :3389，确认端口是否真在监听；
3. 反向验证法：从 VM 内 telnet google.com 443，确认出站正常；再 telnet 127.0.0.1 3389，确认服务本地 OK——两头通，中间断，那问题铁定在 NSG 或防火墙。

最后送一句大实话：在云上，「端口开得越多，安全感越少」。真正的高手，不是能把所有端口都打开的人，而是知道哪些端口必须不开，哪些可以最小化开放，哪些干脆绕过去不用（比如用 Bastion 代替 3389，用 Private Endpoint 代替 1433）。

所以，下次再看到「端口设置」四个字，请别急着点「添加规则」——先问问自己：这个端口，真的非开不可吗？

（完）