Azure 个人账号 Azure网络安全组优先级
你有没有试过在Azure里吭哧吭哧配了一堆NSG规则，结果发现——
SSH连不上？
端口3389死活不通？
明明写了Allow，流量却像被施了消失咒？
别急着怀疑人生，也别立刻截图发给同事喊“Azure又抽风了”。大概率，是NSG的优先级在跟你玩捉迷藏。
一、NSG不是菜市场，它是交通指挥中心
想象一下：你的虚拟机不是孤岛，而是一座24小时运转的写字楼。进出大楼的人流（网络流量），得经过唯一一道旋转门——这就是NSG。
但旋转门不靠喊“请进”就放行，它背后站着一位戴白手套、眼神犀利的保安队长。他手里有一本手写规则簿，每条规则都标着编号（Priority），从100到4096，数字越小，权限越大——不是“先来后到”，而是“谁编号小，谁说了算”。
注意：这本规则簿不支持涂改、不支持拖拽排序、不支持Ctrl+Z。你删掉第200条，第210条不会自动顶上来；你新增一条Priority=150，它就稳稳插进100和200之间。它认编号，不认时间，不认心情。
二、三条铁律，比老板的KPI还刚
铁律①：评估顺序=Priority升序
NSG不是扫一遍所有规则再投票表决。它是一条一条往下读，读到第一条匹配的规则，立刻执行动作（Allow/Deny），然后——啪！合上本子，下班。 后面的规则？看都不看。哪怕后面有条Priority=5000写着“允许一切”，只要前面Priority=200已经把流量拒之门外，它就永远没机会亮牌。
铁律②：隐式拒绝，是最后的关门声
你没手动写任何规则？NSG默认自带两条“压箱底”规则：
• Priority=65500：Allow VNet-to-VNet（同VNet内通信自由）
• Priority=65001：Deny All（拒绝所有其他流量）
没错，那个冷酷无情的“Deny All”，编号65001，比你写的最高编号（4096）还大——意味着它永远蹲在队尾，守着最后一道门。你所有自定义规则都失效？恭喜，你被这条隐式拒绝精准捕获。
铁律③：入站≠出站，两本规则簿
NSG管两扇门：一扇进楼（Inbound），一扇出门（Outbound）。它们各自独立记账、独立排序、互不打招呼。你在入站规则里放行了TCP 80，不代表出站响应能回来——如果出站规则没配好，响应包会被拦在门口，客户端看到的就是“连接超时”。就像你允许客人进门，却忘了给保洁阿姨发出门证，她拖完地想走，保安说：“您没通行证，不能出。”
三、真实翻车现场：那些年我们写错的Priority
场景1：想开个SSH，结果全网断联
小王想让开发团队通过SSH访问Linux VM，于是新建规则：
• Priority: 4096
• Source: Any
• Destination: Any
• Port: 22
• Protocol: TCP
• Action: Allow
……结果所有人连不上。为什么？因为NSG里早有一条Priority=100的规则：
• Priority: 100
• Source: 10.1.0.0/16
• Destination: Any
• Port: Any
• Protocol: Any
• Action: Deny
——这是运维部加的“禁止内网横向扫描”规则。它编号更小，先命中，直接拒绝。小王的4096号许可，连露脸机会都没有。
场景2：“允许全部”的幻觉
小李觉得“反正我只跑Web服务”，干脆建一条：
• Priority: 4000
• Source: Any
• Destination: Any
• Port: 80,443
• Action: Allow
……结果HTTP能通，HTTPS死活不行。查了半天，发现另一条Priority=3500的规则写着：
• Priority: 3500
• Source: Internet
• Destination: Any
• Port: 443
• Protocol: TCP
• Action: Deny
——这是上个月安全加固时加的“临时封禁SSL测试流量”，还没删。它编号更小，先卡住443，小李的“允许443”成了废纸。
四、排错四步法：像侦探一样查NSG
① 打开Azure门户 → 进NSG → 点“有效安全规则”
别只看“入站规则”列表！点这个按钮，它会模拟真实流量路径，告诉你“针对某IP+端口+协议，最终生效的是哪条规则”。这是NSG的X光机，照出规则打架的真相。
② 检查Priority是否连续、有空档
理想状态：你用100-300管理内部信任流量，400-600管互联网入口，中间留20-50的空档。万一要紧急加规则，你就插在450，不用动原有结构。别把所有规则挤在4000-4096，那等于把保安队长逼到墙角，一加新规则就得重排整个本子。
③ 出站规则别当空气
尤其对Windows Server、SQL Server这类需要外联更新或依赖外部服务的VM，务必检查出站规则是否放行DNS（UDP 53）、NTP（UDP 123）、时间同步、证书吊销检查（CRL/OCSP）等——它们失败，可能表现为“登录慢”“证书报错”，而不是端口不通。
④ 默认规则别删，但可以绕过
有人想删掉Priority=65001的Deny All？Azure不允许。但你可以用Priority=4095写一条“Allow Internet Outbound for Health Checks”，把它变成你可控的最后一道闸。把隐式拒绝，变成显式掌控。
五、三条反直觉但保命的建议
• 永远用描述性名称+注释：别叫“Rule1”，叫“Allow-Dev-Team-SSH-From-Corp-VPN-Pri150”。六个月后你重启服务器，靠名字就能秒懂逻辑，而不是对着Priority猜谜。
• 批量操作？先备份规则列表：Azure CLI导出NSG规则只需一行命令：az network nsg rule list --nsg-name myNSG --resource-group myRG --query "[*].[name,priority,access,protocol,sourcePortRange,destinationPortRange,sourceAddressPrefix,destinationAddressPrefix]" -o table。截图存档，比后悔药管用。
• 测试不是“连得上就行”，而是“连得准”：用telnet target 22只能测通断；用curl -v https://target看完整TLS握手；用tcpdump -i any port 22在VM里抓包，确认是NSG挡了，还是防火墙/SELinux/服务本身挂了。别让NSG背锅。
Azure 个人账号 结语：优先级不是玄学，是秩序的刻度
NSG优先级，本质是对混沌流量的文明驯化。它不承诺“你写了就一定生效”，但保证“谁编号小，谁拥有最终解释权”。理解它，不是为了背诵数字，而是建立一种思维习惯：每次添加规则前，先问自己三个问题——
• 它的Priority，在现有规则里排第几？
• 前面有没有更小编号的规则，已经把它判了死刑？
• 入站和出站，我是不是只喂饱了一半？
下次再看到“Connection refused”，别急着重启VM。泡杯茶，打开NSG规则簿，从Priority=100开始，一行一行读下去。你会发现，那个最常被忽略的数字，往往藏着最响亮的答案。
