Azure 合作伙伴 Azure负载均衡监听
你有没有试过——Azure负载均衡器明明配好了，虚拟机也开着，但外部死活连不上？
浏览器转圈、curl超时、telnet拒绝连接……你翻文档、查日志、重配三遍，最后发现：哦，原来监听压根没生效。
别急着删资源重来。这事儿不怪你，怪 Azure 的监听机制太像一个「表面客气、内心较真」的上海房东——门牌号（IP）给你挂好了，钥匙（端口）也递你手上了，但你要是没按他写的《租客守则》第3.2条敲三下门再报身份证号，他理都不理你。
今天咱不背概念，不贴截图，就用烧水壶、快递柜和小区门禁打比方，把 Azure 负载均衡器的「监听」彻底说透。
一、监听不是「开了就行」，而是「四重门禁」
Azure 负载均衡器（Standard SKU）的监听，本质是四层流量准入检查链。漏掉任意一环，请求就在半路被静音处理——不报错、不告警、不丢包，就…消失。这种温柔的拒绝，最磨人。
第一重门：前端 IP 配置（Frontend IP Configuration）
这是你的「门牌号」。LB 本身不带公网 IP，得手动绑一个 Public IP 或 Private IP。常见错误：IP 状态显示「已分配」，但实际没关防火墙或没配 NSG 规则放行入站。就像你家门牌号钉好了，但小区闸机拦着不让进——IP 是假性在线。
Azure 合作伙伴 第二重门：负载均衡规则（Load Balancing Rule）
这才是真正的「监听开关」。它定义了：谁（前端端口+协议）→ 找谁（后端池）→ 怎么找（分发算法+会话持久性）。注意！规则里填的「前端端口」必须和你绑定的 Frontend IP 的端口范围一致——比如你只绑了 TCP 80，却在规则里写 443，Azure 会礼貌地忽略这条规则，且不提示。
第三重门：运行状况探测（Health Probe）
很多人以为探测只是「看看机器活着没」，其实它是「准入资格审查员」。LB 默认每15秒发一次探测包，只有连续2次成功，才把后端实例加入轮询池。重点来了：探测路径必须能被后端服务真实响应，且返回 HTTP 200（或 TCP 连通）。曾有同事把探测路径设成 /healthz，结果应用没部署这个接口，LB 认为所有实例「持续病危」，流量直接归零——连错误日志都懒得记。
第四重门：后端池成员状态（Backend Pool Members）
你以为加进后端池就万事大吉？错。LB 会实时校验每个 VM/VMSS 实例的 NIC 是否启用、是否关联了有效子网、是否有冲突的 NSG 规则拦截 LB 探测源 IP（168.63.129.16）。有一次我们发现某台 VM 在后端池里灰显，点开一看：NIC 网络安全组里一条「拒绝所有来自 168.63.0.0/16 的入站」的规则，正稳稳挡在 LB 探测包前面。
二、那些让工程师凌晨三点改配置的真实坑
坑一：「端口映射幻觉」
想把公网 80 映射到后端 8080？很多人直接在规则里写「前端端口 80 → 后端端口 8080」，然后等奇迹发生。醒醒，Azure LB 不做端口转换（NAT），它只做 IP+端口转发。正确姿势：后端服务必须监听 80 端口，或你在 VM 上用 iptables/netsh 做本地端口转发——LB 本身不背这个锅。
坑二：HTTPS 监听的「证书迷思」
Standard LB 是纯四层设备，它不解析 TLS，也不终止 HTTPS。你想用 443 端口？可以，但 LB 只管转发加密流量到后端，证书管理、SNI、HTTP/2 协商全得后端 Web 服务器自己扛。有人误以为 LB 配了 443 就自动 HTTPS，结果 curl -v https://xxx 返回 SSL handshake timeout——其实是后端 Nginx 没配证书，LB 已忠实地把加密包扔过去了。
坑三：空闲连接超时陷阱
默认 TCP 空闲超时是 4 分钟。长连接应用（如 WebSocket、数据库连接池）可能突然断连。别急着骂网络不稳，先去 LB 规则里把「空闲超时（Idle timeout）」调到 30 分钟——这个值藏得深，得点进规则编辑页底部的「高级设置」才能改。
三、三步诊断法：比 Azure Portal 更快定位问题
第一步：查 LB 自身健康（不看 VM，先看 LB）
进 LB 资源页 → 「运行状况探测」选项卡 → 看「探测状态」列。如果全是「未知」或「不健康」，说明探测根本没发出去，立刻回头检查 NSG 和后端服务端口监听状态（netstat -tuln | grep :80）。
第二步：模拟探测包（不用登录 VM）
在任意能访问后端子网的跳板机上执行：curl -I http://[后端VM内网IP]:[探测端口]/[探测路径] -m 2
如果超时或返回非 200，问题一定在后端；如果通了但 LB 仍标「不健康」，大概率是探测协议/端口/路径与规则配置对不上。
第三步：抓包验证 LB 是否转发
在后端 VM 上运行：sudo tcpdump -i any port [后端端口] -nn -A
同时从公网 curl LB 公网 IP。如果抓不到包，说明 LB 根本没转发——此时回到规则检查：前端 IP 是否绑定？协议是否匹配？后端池是否选对？
四、一份能抄的避坑清单（建议截图存手机）
- ✅ 前端 IP 必须「已分配」且 NSG 放行对应端口（别信默认规则）
- ✅ 负载均衡规则的「前端端口」和「后端端口」必须相同（LB 不做端口映射）
- ✅ 健康探测路径必须由后端服务真实提供，且响应时间 < 探测间隔 × 失败阈值
- ✅ 后端 VM 的 NSG 必须允许源 IP 168.63.129.16 的入站（Azure 平台探测源）
- ✅ 使用 Standard SKU LB 时，后端池必须至少含 2 个实例（单实例不触发探测）
- ✅ 修改任何配置后，等待 2-3 分钟再测试——LB 配置同步不是毫秒级的
最后送一句大实话：Azure LB 的监听机制，不是让你「配得更多」，而是逼你「想得更细」。它不替你兜底，但只要你把四重门禁一扇扇推开，它就会安静、稳定、不知疲倦地扛下百万并发——就像那个从不夸你、但每次你加班到凌晨，桌上永远有杯温热豆浆的后勤大叔。
下次再遇到连不上，别慌。泡杯茶，打开这份清单，一栏一栏打钩。你会发现，所谓云原生运维，不过是把物理世界的严谨，一毫米一毫米，搬进虚拟的控制台里。
