)
1: SNAT 是怎么工作的
以 TCP 连接为例，一次出站访问大致是这样发生的：
image
负载均衡器会维护一条映射记录，例如：
字段 示例
协议 TCP
Worker 实例地址 10.0.5.60:51014
负载均衡器公网地址 13.76.245.72:12481
外部服务地址 52.189.232.180:80
注意：
应用看到的是自己连到了外部服务
外部服务看到的是负载均衡器的公网地址
负载均衡器负责在两边之间做地址转换
这个过程对应用和外部服务都是透明的
2: SNAT 端口耗尽
SNAT 端口的消耗和 TCP 五元组有关：
字段 含义
Protocol 协议，例如 TCP
Source IP 源 IP，SNAT 后是负载均衡器公网 IP
Source Port 源端口，也就是 SNAT 端口
Destination IP 外部目标 IP
Destination Port 外部目标端口
注意：
如果多个 TCP 流访问的是同一个目标 IP、同一个目标端口、同一个协议，那么它们需要不同的源端口来区分。也就是说，高并发访问同一个外部服务时，SNAT 端口会很快被消耗。
反过来，如果多个流访问的是不同目标 IP 或不同端口，那么五元组本身已经不同，SNAT 端口就有机会被复用。
每个 IP 地址最多只能打开有限数量的端口。如果应用频繁打开和关闭连接，情况会更严重。因为 SNAT 端口关闭后不会马上释放：
关闭方式 SNAT 端口释放时间
正常 FIN/ACK 关闭 约 240 秒后释放
RST 重置 约 15 秒后释放
达到 idle timeout 按 idle timeout 释放
这意味着，如果一个 Web 应用每秒打开 1 条 HTTP 连接，调用后端服务后正常关闭，那么在 240 秒内可能累计占用约 240 个 SNAT 端口。
另一个例子是数据库连接池：如果一个繁忙站点的 SQL 连接池大小是 300，并且数据库查询执行较慢，那么这些连接可能持续占用约 300 个 SNAT 端口。
还有一种常见情况是队列触发的 Function App：如果压测一开始就把大量消息一次性灌入队列，Function 可能瞬间启动大量到 Storage 或其他外部服务的连接，很快耗尽 SNAT 端口。
3: SNAT 端口分配算法
为了避免某个站点耗尽整个 stamp 的 SNAT 端口并影响其他站点，Azure Load Balancer 需要对 SNAT 端口做分配控制。常见算法包括：
分配方式 端口数量
On-demand 算法 每实例基础 160 个，可按需尽力分配更多
新算法 每实例固定预分配 128 个
这里的 160 个 SNAT 端口 可以用一个粗略的容量分摊思路来理解。一个典型的 App Service stamp 可能有 5 个出站 IP，每个 IP 理论上有大约 65536 个端口。如果这些端口要被 stamp 内大约 2000 个实例共享，那么每个实例能稳定分到的端口数量大约是：
5 × 65536 ÷ 2000 ≈ 163.84 取整后就接近 160 个端口 / 实例。
4: SNAT 端口耗尽时的症状
当 SNAT 端口耗尽时，应用常见表现包括：
连接外部 endpoint 变慢；
请求长时间 pending；
最终出现 socket timeout；
Application Insights 里能看到依赖调用失败。
如果启用了 Application Insights dependency tracking，也可能看到外部依赖调用失败。
5: 如何解决 App Service 的 SNAT 端口耗尽
总体方向是：先减少不必要的连接占用，再考虑扩展。
image
具体建议：
复用连接：不要每次请求都 new 一个 HttpClient；
使用连接池：数据库、HTTP 客户端都应合理复用连接；
控制连接池大小：连接池不是越大越好，过大的池会持续占用端口；
降低重试强度：失败时疯狂重试会进一步放大端口占用；
让后端尽快响应：后端越慢，连接存活越久，SNAT 端口占用越久；
横向扩容 App Service Plan：SNAT 端口按实例分配，实例变多，总可用端口也会增加；
使用 App Service Environment：ASE 的实例池更小，worker 实例通常可以获得更多 SNAT 端口；
压测要贴近真实流量：负载测试应以稳定速度投喂数据，而不是一开始就把所有消息一次性灌入队列。
示例代码及优化
下面的代码可以复现 SNAT 端口耗尽问题：
复制代码
public string Index(string url)
{
var request = HttpWebRequest.Create(url);
request.GetResponse();
return "OK";}
复制代码
为了复用连接，可以改成关闭响应对象：
复制代码
public string Fin(string url)
{
var request = HttpWebRequest.Create(url);
var response = request.GetResponse();
response.Close();
return "OK";}
复制代码
下面这种写法也会造成 SNAT 端口泄漏，因为每次调用都会创建新的 HttpClient：
复制代码
public async Task Client(string url)
{
using (var client = new HttpClient())
{
await client.GetAsync(url);
}
return "OK";}
复制代码
可以改成复用同一个 HttpClient：
复制代码
private static Lazy _client = new Lazy();
public async Task ReuseClient(string url)
{
var client = _client.Value;
await client.GetAsync(url);
return “OK”;
}
复制代码
常见问题（FAQ）：
Q：我能自己看到 App Service 的 SNAT 端口分配指标吗？
A：一般情况下，这个指标不直接公开。日常设计时不要依赖“实际能拿到多少端口”，而应按每实例 128 个的保守值来控制。
Q：为什么不能直接根据 SNAT 端口指标做自动扩缩容？
A：因为很多 SNAT 问题本质是连接没有复用。如果代码持续浪费连接，单纯扩容只是把问题摊开，并不一定治本。应该先优化连接复用和后端响应，再考虑扩容。
Q：SNAT 耗尽和 TCP Connections 耗尽有什么区别？
A：TCP Connections 是 worker 实例层面的连接计数，SNAT 是出站负载均衡器上的公网源端口资源。前者统计所有 TCP 连接，后者只和外部网络流量有关。二者有关联，但不能互相替代。
Q：多个 WebJob 共用同一个 App Service Plan，怎么判断谁占用了最多连接？
A：如果没有按进程维度的连接指标，可以把部分 WebJob 移到另一个 App Service Plan，通过隔离法观察问题是否缓解，逐步定位高连接消耗的任务。