问题源于NSG入站规则配置不当：需检查子网/NIC级NSG绑定、验证端口22/3389允许规则是否被高优先级拒绝规则覆盖、用Network Watcher诊断具体拦截规则、排查Bastion/防火墙等绕过机制，并可临时解绑NSG验证。
如果您尝试通过 SSH 或 RDP 连接到 Azure Linux 或 Windows 虚拟机，但连接失败并提示“Network Security Group 阻止了入站”，则问题很可能源于网络安全组（NSG）的入站规则配置不当。以下是定位和验证 NSG 入站拦截的具体操作路径：
一、检查关联的网络安全组及其应用层级
NSG 可同时绑定到子网和网络接口（NIC），且入站流量按“子网 NSG → NIC NSG”顺序评估，任一环节拒绝即中断连接。需确认 VM 实际使用的 NSG 及其绑定位置。
1、登录 Azure 门户，进入目标虚拟机概览页。
2、在左侧菜单选择“网络”，查看“网络接口”列表中对应 NIC 的名称。
3、点击该 NIC 名称，进入 NIC 详情页，向下滚动至“设置”区域，点击“网络安全组”，确认是否已分配 NSG；若显示“无”，说明仅子网级 NSG 生效。
4、返回资源组或搜索栏输入子网名称，打开子网配置页，在“设置”中点击“网络安全组”，确认子网是否绑定 NSG。
5、分别打开子网级和 NIC 级 NSG 的规则页，重点查看“入站安全规则”标签页下的所有规则。
二、验证端口 22（SSH）或 3389（RDP）是否被显式拒绝
NSG 默认含一条优先级为 65500 的 DenyAllInBound 规则，若无更高优先级（数值更小）的允许规则覆盖，该默认规则将直接阻断所有外部入站流量。
1、在 NSG 的“入站安全规则”页，按“优先级”列升序排列（从小到大）。
2、查找是否存在优先级低于 65500（如 1000、2000）且“源端口范围”为 *、“目标端口范围”为 22（Linux）或 3389（Windows）、“协议”为 TCP、“操作”为 Allow 的规则。
3、检查是否存在任何“操作”为 Deny、目标端口包含 22 或 3389、且优先级高于（数值小于）上述 Allow 规则的条目。
4、特别注意“源地址前缀”字段：若填写为特定 IP 或 CIDR（如 203.0.113.0/24），而您的当前公网 IP 不在此范围内，则连接会被静默拒绝。
三、使用 Network Watcher 的 NSG 诊断功能实时验证
NSG 诊断可模拟真实流量，明确指出某次连接请求是被哪条规则允许或拒绝，无需手动逐条比对规则优先级与匹配条件。
1、确保目标 VM 所在区域已启用 Azure Network Watcher（通常默认启用）。
2、在 Azure 门户顶部搜索“网络观察程序”，进入服务页。
3、在左侧“网络诊断工具”中选择“NSG 诊断”。
4、填写诊断参数：源类型选“公共 IP”，输入您本地设备的公网 IP 地址；目标类型选“虚拟机”，选择目标 VM；协议选 TCP；目标端口填 22 或 3389；首选 IP 版本选 IPv4。
5、点击“运行诊断”，等待结果返回。输出将清晰显示“规则匹配详情”，包括触发的规则名称、优先级、动作（Allow/Deny）及匹配依据。
四、检查 NSG 是否被其他资源间接覆盖或绕过
某些部署模型或高级网络功能可能使 NSG 规则失效或被替代，例如通过 Azure Bastion 访问时，流量不经过公网 IP 和关联 NSG；或启用了服务终结点后，部分流量路由路径发生变化。
1、检查 VM 是否配置了 Azure Bastion：若已部署且通过 Bastion 连接，则 NSG 对 Bastion 流量无影响，此时应排查 Bastion 自身配置而非 NSG。
2、检查是否启用“服务终结点”（如 Microsoft.Storage）：该功能本身不影响 SSH/RDP，但若误配用户定义路由（UDR）将 0.0.0.0/0 指向虚拟设备，可能导致入站流量被重定向并丢弃。
3、检查是否启用了“Azure Firewall”或第三方防火墙：若 NSG 后方部署了 Azure Firewall，需同步检查其应用规则集合（Application Rule Collection）和网络规则集合（Network Rule Collection）是否放行对应端口。
五、临时禁用 NSG 进行最小化验证
为排除 NSG 是唯一阻碍因素，可在测试环境中移除 NSG 绑定以快速验证。此操作不删除规则，仅解除关联，风险可控且可逆。
1、进入目标 NIC 设置页，点击“网络安全组”，在右侧面板点击“无”链接。
2、点击“保存”提交更改，系统会提示该操作将移除所有 NSG 关联。
3、等待约 60 秒让配置生效，立即尝试从本地发起 SSH 或 RDP 连接。
4、若连接成功，即可 100% 确认原 NSG 规则是根本原因；此时应恢复 NSG 绑定，并基于前述步骤精调规则。
