Azure托管Service Fabric WebAPI服务公网及本地均无法访问求助

咱一步步来拆解这个问题，毕竟我自己也踩过Service Fabric端口访问的坑，给你梳理几个关键排查点：

1. 先把Azure网络层的关卡打通 #

首先得确认Azure那边的网络安全组（NSG）和负载均衡器有没有给8210端口开绿灯：

• 找到你Service Fabric集群对应的虚拟机规模集（VMSS），查看它的NSG入站规则，必须添加一条允许TCP 8210端口的规则，优先级要设得比默认的拒绝规则高。
• 同时检查负载均衡器的规则，有没有把公网的8210端口转发到后端VM的8210端口——默认情况下负载均衡器不会自动帮你配置自定义端口的转发。

2. 确认服务和程序的端口配置匹配 #

别光看ServiceManifest.xml里的<Endpoint>配置，还要确保你的ASP.NET Core程序真的在监听这个端口：

• 打开Program.cs，检查Kestrel的配置是不是明确指定了监听8210端口，比如：

  builder.WebHost.ConfigureKestrel(options =>
  {
      options.ListenAnyIP(8210); // 这里要和ServiceManifest里的端口一致
  });
  

  很多时候问题就出在这：Service Fabric给了端口，但程序自己没监听，自然访问不通。

3. 到节点上验证端口是否真的被监听 #

登录到集群的任意一个节点（可以通过Azure门户的VMSS远程桌面，或者用Azure CLI连进去），跑个netstat -ano命令，看看有没有进程在占用8210端口。

• 如果没看到这个端口的监听记录，要么是服务没启动成功，要么是端口配置不匹配，得去看服务的启动日志。

4. 用Service Fabric反向代理试访问 #

Service Fabric自带反向代理（默认端口19081），可以先通过它来验证服务本身是否正常：

• 访问格式大概是：https://appname.region.cloudapp.azure.com:19081/你的应用名称/你的服务名称/api/你的接口路径
• 如果反向代理能访问到服务，说明是直接端口访问的网络配置有问题；如果反向代理也不行，那大概率是服务本身启动失败了，得去查日志。

5. 扒一扒服务的日志和健康事件 #

打开你能正常访问的Service Fabric Explorer，找到你的服务实例：

• 查看它的健康状态详情和事件日志，有没有启动失败的报错？比如端口被别的程序占用，或者ASP.NET Core启动时抛出了异常？
• 也可以登录到节点，去C:\ProgramData\SF\Log\Application目录下翻服务的详细日志，里面会有更具体的错误信息。

6. 本地localhost访问的额外排查 #

如果你在本地开发环境也访问不了：

• 确认本地Service Fabric集群的防火墙有没有开放8210端口；
• 查看本地集群的节点是否真的部署了你的服务实例，有没有启动成功；
• 尝试用节点的实际IP（而不是localhost）来访问，有时候localhost绑定会有问题。

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