Azure 技术支持 微软云端口不通排查

凌晨两点十七分，咖啡凉透，键盘上残留着半块没吃完的薯片碎屑——你盯着屏幕右下角那个刺眼的红色叉号，心里默念：‘这破服务明明昨天还活蹦乱跳，怎么今天连个TCP握手都懒得跟你打？’

别慌。这不是世界末日，也不是你手抖删了生产环境密钥——大概率，只是微软云上的某个端口，正傲娇地对你装死。

第一步：先别急着怀疑人生，问问自己——你连得上吗？

很多兄弟一上来就冲进Azure Portal狂点NSG、翻VNet路由表、查Application Gateway日志……结果折腾两小时发现：自己笔记本连的是公司WiFi，而公司防火墙早把443以外的端口全焊死了。😅

所以，掏出终端，先来个最朴素的灵魂三问：

1. ping your-app.azurewebsites.net —— 别信这个！ICMP在Azure Front Door和App Service前基本被阉割，通≠能用，不通也≠真挂。
2. telnet your-app.azurewebsites.net 443（或nc -zv your-app.azurewebsites.net 443）—— 这才是真·心跳检测。如果卡住、超时、直接报“Connection refused”，恭喜，你已成功进入‘端口失联’VIP候诊区。
3. curl -v https://your-app.azurewebsites.net —— 看响应头、看HTTP状态码、看TLS握手有没有卡在Client Hello。有时候不是端口不通，是证书链断了，浏览器默默给你返回一个‘ERR_SSL_VERSION_OR_CIPHER_MISMATCH’，你还以为是Azure抽风。

第二步：本地→云边→云内，画一张‘端口旅行地图’

想象你的请求是一趟高铁：从你家路由器出发（起点站），经运营商骨干网（高速段），穿过Azure边界防火墙（安检闸机），再坐上虚拟专列驶入VNet（市内地铁），最后停靠在你的VM或App Service（终点站台）。任何一站临时停运，整趟车都到不了。

我们按顺序捋：

① 你家/办公室出口是否放行？

公司IT策略可能禁用非标端口（比如8080、5000），也可能对Azure IP段做了限流。试下用手机热点重跑telnet——如果秒通，别谢我，去给IT部门发一封‘感谢您帮我省了三小时’的邮件（然后悄悄抄送老板）。

② Azure边界：DDoS防护、Front Door、WAF有没有悄悄‘代收快递’？

如果你开了Azure DDoS Protection Standard或Front Door，注意：它们默认只转发80/443；想走其他端口？得手动在‘后端池’里配健康探测端口，还得在‘路由规则’里显式允许。曾经有位同事把8080端口堵了三天，最后发现是Front Door的‘自定义规则’里写了Block if port != 443——而他根本没写这条规则，是系统模板自带的……（黑人问号.jpg）

③ VNet入口关卡：网络安全组（NSG）

NSG不是玄学，是带编号的流水线工人。记住两条铁律：

• Azure 技术支持 规则按优先级执行，不是按时间先后——哪怕你最后加了一条‘允许所有443’，只要前面有条优先级更高的‘拒绝所有’，它就永远没机会上岗。
• 入站规则管‘谁能把包塞进来’，出站规则管‘我的VM能不能把包吐出去’——App Service没NSG？对，但它背后有平台级安全策略；VM有？请务必检查‘源地址’是不是写成了*却忘了‘目标端口’填成80而不是80-80（Azure认80，不认80-80，但UI会自动帮你补成80-80，然后默默失效）。

④ 云内最后一公里：VM防火墙 or App Service设置

Windows VM？别忘了Windows Defender Firewall默认拦所有入站，除非你勾选‘允许应用通过防火墙’——而你部署的Node.js服务，默认不在白名单里。Linux？ufw status看看，iptables -L -n翻翻，说不定上周更新内核后规则丢了。

App Service更隐蔽：它没有传统防火墙，但有访问限制（Access Restrictions）。点开你的App Service → ‘Networking’ → ‘Access restrictions’，确认没误加一条‘Deny all’，或者把公司IP段写成192.168.1.0/24却忘了这是私有网段，公网根本过不来。

第三步：端口通了，但页面还是白？可能是‘假装在线’

telnet通了，curl返回200，但浏览器一片空白？打开开发者工具→Network标签，点开那个空响应：看Content-Type是不是text/html，还是application/json？如果是后者，大概率你绑错了自定义域名——App Service里‘Custom domains’没验证，或SSL绑定选了‘SNI SSL’却上传了IP SSL证书（反之亦然）。

还有经典陷阱：负载均衡器健康探测端口 ≠ 应用监听端口。你让Load Balancer每5秒探http://:8080/health，结果应用只监听localhost:8080，不监听0.0.0.0:8080——探测永远失败，LB直接把你实例踢出池子，对外显示‘服务不可用’，而你查日志发现应用明明在跑……

第四步：终极核验清单（可打印贴显示器边）

• ✅ 本地网络允许该端口出站（尤其企业网络）
• ✅ Azure资源提供商状态正常（status.azure.com别光看首页，点进‘Compute’‘Networking’‘App Services’子页）
• ✅ NSG入站规则：源=*, 协议=TCP, 端口=你的端口, 优先级＜65000, 动作=Allow
• ✅ VM/容器内服务监听0.0.0.0:端口，非127.0.0.1
• ✅ App Service访问限制未误封
• ✅ 自定义域名已验证，SSL绑定类型与证书匹配
• ✅ Load Balancer/AGW健康探测路径、端口、协议与后端一致
• ✅ DNS解析正确（nslookup your-domain.com看A记录指向是否为Azure分配的IP或CNAME）

最后送一句大实话

微软云的端口不通，80%是配置漏项，15%是理解偏差，5%才是真故障。而那5%，通常会在你改完第十遍NSG后，突然自己好了——这时候，请深呼吸，关掉终端，出门买杯热豆浆。因为真正的故障，往往发生在你终于放松警惕的那一刻。

祝你下次排查时，咖啡还温，薯片还脆，端口秒通。