Docker及Kubernetes暴露5671端口后ASP.NET Core无法访问Service Bus问题

核心误区先澄清 #

你Dockerfile中写的EXPOSE 5671/EXPOSE 5672仅为端口声明作用，不会实际开放端口，而且你作为客户端主动连接外部Azure Service Bus属于出站流量，不需要在容器、Deployment、Service层面开放这两个端口的入站规则，多数此类问题都是搞错了流量方向或者出站网络限制导致的。

排查步骤 #

1. 核查出站网络限制 #

• 检查AKS集群关联的NSG（网络安全组）、子网出站规则，确认是否禁止了5671（AMQP TLS端口）、5672（AMQP非TLS端口）的出站流量，公网Service Bus必须放开这两个端口的出站权限
• 如果集群开启了Istio、Linkerd等服务网格，确认sidecar拦截规则没有阻断AMQP协议的出站流量
• 如果你给Service Bus配置了私有端点，确认AKS集群和Service Bus私有端点在同一虚拟网络或者已经打通跨网链路

2. 验证Pod到Service Bus的网络连通性 #

直接进入运行的Pod内部执行连通测试，先排除链路问题：

# 替换为你实际的Pod名称进入容器
kubectl exec -it <your-pod-name> -- /bin/bash
# 替换为你的Service Bus命名空间域名，测试5671端口连通性
nc -zv <your-namespace>.servicebus.windows.net 5671

如果返回连接超时/拒绝，说明是集群到Service Bus的网络链路问题，和应用配置无关。

3. 检查资源配置正确性 #

• Deployment不需要额外配置5671/5672的端口暴露，只要确认应用的Service Bus连接字符串配置正确，命名空间、共享访问密钥没有写错
• 如果你使用托管身份而非连接字符串连接Service Bus，确认Pod绑定的服务账号有对应Service Bus的访问权限
• 检查K8s Service配置，确认没有占用容器本地的5671/5672端口导致应用无法发起出站连接，可在Pod内执行netstat -tulpn查看本地端口占用情况

4. 验证Service Bus侧配置 #

• 检查Service Bus的防火墙设置，确认AKS集群的出口公网IP已经加入Service Bus的IP白名单，或者开启了「允许受信任的Azure服务访问」开关
• 确认Service Bus本身处于运行状态，没有资源锁定或者欠费停用的情况

5. 排查应用日志 #

查看应用运行日志确认错误类型：

• 如果报连接超时错误：100%为网络链路问题，回到前两步排查网络规则
• 如果报认证/权限错误：排查连接字符串、托管身份权限配置
• 如果报协议错误：确认你应用使用的Service Bus SDK版本和服务端兼容，没有强制用不支持的AMQP版本

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