如何在Azure中打开套接字？.NET自定义SMTP服务部署及访问疑问

App Service/WebJob的套接字限制 #

是的，你的判断完全正确——App Service（包括附属的WebJob）不允许直接监听自定义端口（如587）或主动打开套接字接收外部非HTTP/HTTPS流量。这是因为App Service属于多租户托管环境，所有入站流量必须经过Azure前端负载均衡器，仅开放80/443端口用于HTTP/HTTPS请求，底层网络套接字的直接访问被严格限制，WebJob作为App Service的子进程，自然受此约束。

WebJob无法实现目标 #

基于上述环境限制，WebJob里根本做不到打开套接字接收外部SMTP流量，这条路走不通，无需再尝试。

以下是适合部署自定义SMTP服务器（.NET Worker Service）的替代选项，按推荐优先级排序：

• Azure Container Apps
  无服务器容器托管服务，支持直接部署.NET Worker Service的容器镜像，可自由配置暴露587端口，能设置静态IP或关联自定义域名，满足外部访问需求。无需管理VM，成本可控，是最接近你需求的无服务器替代方案。

• Azure Kubernetes Service (AKS)
  适合需要容器编排、灵活扩缩容的场景。将Worker Service打包为容器后部署到AKS，通过LoadBalancer类型的服务暴露587端口，即可实现外部访问。适合有容器运维经验或后续需扩展多服务的场景。

• Azure Virtual Machine Scale Sets (VMSS)
  比单个VM更可靠，支持自动扩缩容。你可以在VMSS中部署Worker Service，配置网络安全组（NSG）开放587端口，绑定公共IP即可接收外部流量。无需手动维护单个VM的可用性，兼顾了VM的灵活性和托管服务的便利性。

• Azure Functions（折中方案，仅部分场景适用）
  如果你的核心需求是处理邮件而非完整的SMTP服务，可以用Azure Functions接收HTTP请求，再通过后端逻辑转发邮件。但这不是真正的SMTP服务器，无法直接接收外部SMTP协议请求，仅适合邮件发送类需求。

• App Service + 反向代理（不推荐）
  若一定要用App Service，可通过额外的反向代理层将SMTP请求转换为HTTP请求转发到App Service，但配置复杂、性能损耗大，且稳定性无法保证，仅作为极端情况的备选。

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