Azure VM自定义端口9000的TCP监听无法正常工作问题求助

看起来你已经做了不少关键排查：客户端SYN包确实到达了VM，netstat也显示9000端口在正常监听，Azure的NSG入站规则也配置好了，但连接还是失败。结合这些信息，大概率是VM内部的拦截或者配置细节问题，下面是具体的排查方向：

1. Windows本地防火墙没放行9000端口 #

Azure的NSG是外部第一道关卡，但VM自身的Windows Defender Firewall是内部的第二道防线。很多人容易忽略这点——即使NSG允许了，本地防火墙如果没开对应端口的入站规则，就会直接丢弃SYN包，不会返回响应。

• 你可以在VM上打开Windows Defender防火墙高级设置，检查是否存在针对TCP 9000端口的入站允许规则；
• 快速测试的话，可以临时关闭Windows防火墙（测试完记得立刻打开），再尝试连接。如果能通，那就确定是本地防火墙的问题，直接添加对应规则即可。

2. 确认监听进程的有效性 #

虽然netstat显示0.0.0.0:9000处于LISTENING状态，但可以再仔细核对下：

• 执行命令 netstat -ano | findstr :9000，看看输出的PID是不是你的TCP服务器进程的PID，确保没有其他进程占用这个端口，或者你的程序没真正在监听；
• 另外，试试在VM本地用telnet 127.0.0.1 9000连接9000端口，如果本地能通，说明服务本身没问题；如果本地都连不上，那就是你的服务器程序有问题（比如没获取到管理员权限，或者代码逻辑有隐藏bug）。

3. 子网NSG的额外限制 #

有时候VM所在的虚拟网络子网也配置了NSG，而子网NSG的规则优先级可能和VM网卡的NSG冲突。你需要检查：

• 登录Azure门户，找到VM所在的子网，查看子网的NSG规则，确保里面也允许9000端口的入站流量。

4. 其他安全软件的拦截 #

如果VM上安装了第三方杀毒软件、安全防护工具，或者启用了Azure DDoS保护的严格模式，这些工具可能会拦截未被授权的端口连接。可以暂时关闭这类软件，再测试连接是否正常。

5. 监听地址的隐性问题 #

你的代码用了IPAddress.Any，理论上是监听所有网卡，但极少数情况下，系统的网络策略可能会限制程序只能监听内网IP（10.1.1.4）。不过从你netstat的输出看，0.0.0.0:9000已经说明是监听所有地址，这个可能性很低，但如果前面的排查都没问题，可以试试把代码里的IPAddress.Any换成VM的内网IP（10.1.1.4）或者公网IP，重新启动服务再测试。

按照这个顺序排查，应该能很快找到问题——最常见的就是Windows本地防火墙没放行端口的情况。

内容的提问来源于stack exchange，提问作者Murat