我有 2 个虚拟机 (CentOS)，在同一 VNET(和子网)中运行。 它们都有一个静态公共(public) IP。
我有一个网络安全组，它定义了入站和出站规则，附加到两个 NIC 以及 VNET。
入站规则之一是 default-allow-ssh 规则。 到目前为止一切都很好，使用 SSH，我可以从 Azure 外部、从我自己的计算机从网络上的任何位置访问这两个虚拟机。
在其中 1 个虚拟机上，我正在运行网络服务器。
在端口 80 上公开 Web 服务器并在端口 80 上添加新的 NSG 入站安全规则(src:any、src 端口范围:*、dest:any、端口:80、协议(protocol):any)允许 met 从以下位置访问 Web 服务器任何地方:从我的电脑，从网络上的任何地方，从 Azure 中的其他虚拟机，正如我所期望的那样。
现在，当我将网络服务器的端口从 80 更改为 7181 时:
我仍然可以从我托管网络服务器的服务器以及位于同一 VNET(子网)的其他 CentOS 服务器执行“curl http://[PUBLIC_IP]:7181”，但不再从我的电脑或 Azure 领域之外的任何电脑执行“curl enter image description here”操作(网络)。
Firewalld 未在网络服务器上运行，我也未设置 iptables，只有 NSG 规则定义入站和出站流量。
始终可以使用 ssh 从 Azure 之外的任何位置访问 Web 服务器的主机。端口 80 上的 Web 服务本身(包括适当的入站 NSG 规则)也可以在 Azure 内外的任何位置正常工作。自定义端口的配置与 NSG 中的端口 80 或 22 相同(当然端口号除外)，只能从同一 VNET 内部访问。
有人吗？
(我得到的错误是众所周知的:ERR_CONNECTION_REFUSED)
NSG 屏幕截图: ojit_a
最佳答案
重新启动虚拟机实例解决了该问题。因此，动态添加/更新 NSG 规则似乎不会立即影响正在运行的实例，或者其他需要花费大量时间同步才能生效的操作。我一定忘记了我早期的 Windows 时代，在更改配置或安装新东西时，重新启动是相当标准的。不管怎样，感谢大家在这个问题上花费的时间和精力。
关于Azure，从 Internet 访问时某些端口上的连接被拒绝，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/49687369/