Azure App Service容器部署Node.js WebRTC服务器无法完成STUN发现（srflx候选地址）问题求助

阿华AIGC实验室

2026-4-2

核心问题定位：Azure App Service的多租户PaaS网络模型限制

我之前帮好几个开发者排查过类似的WebRTC部署问题，你的情况完全踩中了Azure App Service的核心网络限制——它本质是为HTTP/HTTPS这类请求响应式流量设计的多租户PaaS，网络架构从根本上不支持WebRTC需要的直接UDP ICE候选交换，这也是为什么你在DigitalOcean VM（有独立公网IP和直接端口访问权）上能正常运行，但在App Service上失败的根本原因。

具体原因拆解

平台级NAT端口强制替换
App Service的容器没有独立的公网IP，所有出站UDP流量都会经过平台前端的NAT网关转发，这个过程中，你配置的应用端口（10000-60000）会被动态替换成平台随机分配的端口。当STUN服务器返回srflx候选时，对应的端口是平台前端的随机端口，而非你应用指定的范围，而且App Service平台不会把这个随机端口的入站UDP流量转发回容器内的应用端口。WebRTC库验证候选可达性时会失败，因此直接放弃生成srflx候选。
平台前置防火墙拦截入站UDP
虽然你在NSG中开放了UDP端口范围，但App Service的入站流量首先会经过平台自身的前置防火墙，这个防火墙默认只允许HTTP/HTTPS（80/443）和你在应用设置中明确配置的少数自定义TCP端口，所有未被允许的UDP流量（包括STUN响应需要的入站UDP）会被直接拦截，根本到不了你的NSG层面。

可行的解决方案

1. 更换到更适配的Azure服务（推荐生产环境使用）

如果要在Azure上稳定运行WebRTC实时媒体应用，建议切换到以下支持直接UDP流量的服务：

Azure Virtual Machines：你已经验证过这种方式可行，完全可控的网络环境，支持直接分配公网IP和配置端口规则。
Azure Container Apps：保留容器化部署优势的同时，支持分配静态公网IP，可配置入站端口规则允许UDP流量直接到达容器，完美适配WebRTC的ICE候选需求。
Azure Kubernetes Service (AKS)：适合大规模部署场景，可通过LoadBalancer Service或NodePort配置公网IP和端口转发，完全满足WebRTC的网络要求。

2. 临时Workaround（仅用于测试/紧急场景）

如果必须暂时使用App Service，可以强制WebRTC仅依赖TURN中继候选，放弃srflx和host候选。具体是在RTCPeerConnection的配置中添加iceTransportPolicy: "relay"：

const pc = new RTCPeerConnection({
  iceServers: [/* 你的STUN/TURN配置 */],
  icePortRange: [10000, 60000],
  iceTransportPolicy: "relay" // 强制仅使用TURN中继
});

注意：这种方式会让所有媒体流量经过TURN服务器中转，会增加延迟和TURN服务的使用成本，不适合生产环境大规模使用。

3. 最后确认的配置细节（你已完成大部分，可再核对）

确保你的App Service实例是Premium v3或更高层级（基础/标准层的网络限制更多），但即使是Premium层，依然解决不了UDP入站的核心限制。
如果你用了VNET集成，确认是Regional VNET Integration（而非Gateway Required），但这也只能解决出站流量的VNET路由问题，无法突破平台对入站UDP的拦截。