香港机房 03:12，我正盯着 42U 机柜里那台贴着“HK-API-02”的服务器。业务端报警“外呼 API 失败率 18%→62%”，应用日志里一片 WSAEADDRINUSE(10048) 和 TCP/IP failed to establish an outgoing connection...（事件 4227）。现场网络值班问我：“是不是对端把我们限流了？”我看了眼 netstat，心里已经有了 80% 的把握——这更像是本机的临时端口（ephemeral port）被耗光了。

1. 现场与基线

硬件/环境（真实投产规格）

• 机型：Dell R730（2U）
• CPU：2 × Intel Xeon E5-2650 v4（12C/24T）
• 内存：128 GB ECC
• 存储：2 × 1.92 TB 企业级 SATA SSD（RAID1）
• 网卡：Intel X520 10GbE（双口，LACP 到汇聚交换机）
• 系统：Windows Server 2012 Datacenter（PowerShell 3.0，.NET 4.6）
• 角色：大量出向连接（调用第三方支付、短信、风控等 HTTP/HTTPS API），IIS 8.0 + 后端 C# 服务
• 上游：边界是 F5 做 SNAT（重要：NAT 设备也有“端口池”）

事发现象

• API 调用延迟抖动，失败率爬升
• Windows 事件查看器：系统日志有 Event ID 4227（经典“端口耗尽/重复端点”症状）
• netstat 大量 TIME_WAIT、CLOSE_WAIT，本机到多个外部目的地址的连接数上万

2. 快速定位：是否“端口耗尽”

我在现场先跑了三条命令，用来“定性 + 定量”：

# 1) 动态端口范围（默认一般是 49152-65535）
netsh int ipv4 show dynamicport tcp
netsh int ipv4 show dynamicport udp

# 2) 连接状态分布
Get-NetTCPConnection | Group-Object -Property State -NoElement

# 3) 目的地维度的连接数量（看是否单点集中爆）
Get-NetTCPConnection | Group-Object -Property RemoteAddress | Sort Count -Descending | Select -First 10

观察结果（真实夜班记录的典型值）

结论：默认 16k 多的临时端口池 + 较高的 TIME_WAIT 残留，在高并发出向短连接场景下，完全可能被“吃光”。

3. 原理拎清：为什么会“吃光”

Windows 2012 的动态端口（Ephemeral Port）通常是 49152–65535，大约 16k。每一个出向 TCP 连接都要占用一个本地临时端口。

连接关闭后会进入 TIME_WAIT（保持一段时间以防迟到包），这段时间端口不能立即复用。

高并发 + 短连接（如大量 HTTP 调用未复用）= 端口周转太慢 → “没有可用本地端口” → 连接失败 / 4227。

额外提醒：如果经过 NAT/SLB（比如 F5/云负载），上面的 SNAT 端口池也可能成为瓶颈；需要两侧同时评估。

4. 方案设计：三板斧（先救火，再治本）

扩大 Windows 动态端口范围（立竿见影，风险可控）

适度缩短 TIME_WAIT 停留（谨慎：全局 TCP 行为调整，先压测再上线）

从应用层减少“新建连接”（长期最佳实践：连接池/HTTP Keep-Alive）

下面是我当晚在 HK-API-02 的完整实操，以及第二天的回滚/验证流程。

5. 实操一：扩大动态端口范围（IPv4/IPv6、TCP/UDP 全量对齐）

目标：把池子从 16k 扩到 ~55k。我们选择 10000–64999（55000 个），保留 65000–65535 给少数固定端口/特例。

5.1 变更命令

# 以管理员 PowerShell 执行
# 查看当前范围
netsh int ipv4 show dynamicport tcp
netsh int ipv6 show dynamicport tcp
netsh int ipv4 show dynamicport udp
netsh int ipv6 show dynamicport udp

# 设置新范围：start=10000，num=55000 → 10000–64999
netsh int ipv4 set dynamicport tcp start=10000 num=55000
netsh int ipv6 set dynamicport tcp start=10000 num=55000
netsh int ipv4 set dynamicport udp start=10000 num=55000
netsh int ipv6 set dynamicport udp start=10000 num=55000

# 再次查看确认
netsh int ipv4 show dynamicport tcp
netsh int ipv6 show dynamicport tcp

经验：在 2012 上修改 即时生效，无需重启（已在现场验证）。但已有连接不受影响；真正意义的缓解来自随后新建连接从更大的端口池里取号。

5.2 Windows 防火墙/边界防火墙校验

出向通常无需额外放行，但我们仍然做了对齐，避免特殊策略“卡端口段”：

# Windows 高级防火墙（如果你们有细粒度出向策略）
netsh advfirewall firewall add rule name="Dynamic TCP Out (10000-64999)" dir=out action=allow protocol=TCP localport=10000-64999
netsh advfirewall firewall add rule name="Dynamic UDP Out (10000-64999)" dir=out action=allow protocol=UDP localport=10000-64999

边界 F5/硬件防火墙也要让 SNAT 端口池≥ 55k（或按并发峰值评估）。

6. 实操二（可选且谨慎）：缩短 TIME_WAIT

风险提示：TIME_WAIT 是 TCP 的“保险丝”。过度缩短可能导致罕见乱序/延迟包问题在边缘场景放大。我的做法是从默认值小幅调到 60 秒，先在预发/压测环境验证，再灰度到生产。

# 注册表路径
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

# 新建/修改：
# TcpTimedWaitDelay (DWORD, 十进制) = 60
# 建议范围：30–120，默认通常更大；改动后需重启生效

注意：此项通常需要 重启 才能生效。夜间窗口我们安排了 3 分钟维护重启（已与业务方沟通好低谷时段）。如果不能重启，优先只做“端口池扩容”，也能明显缓解。

7. 实操三（根治方向）：应用侧连接复用

.NET/HttpClient：复用单例，启用默认 Keep-Alive，禁止每次 new HttpClient() 导致短连接暴增。

增大 ServicePointManager.DefaultConnectionLimit（老框架）或使用 SocketsHttpHandler 配置连接池。

gRPC/数据库驱动同理，尽量长连 + 池化。

与对端确认：对端需允许较长 Keep-Alive 与合理 Idle Timeout，否则被动断开仍会导致重连风暴。

我们最终把最“话痨”的三个外呼 SDK 都切到连接池，峰值新建连接数直接下降 70%+。

8. 验证与观测脚本

8.1 端口与状态分布（PowerShell）

$before = Get-Date
$g1 = Get-NetTCPConnection | Group-Object State -NoElement
$g1 | Format-Table Name, Count

# 5分钟后再看一眼
Start-Sleep -Seconds 300
$g2 = Get-NetTCPConnection | Group-Object State -NoElement
$g2 | Format-Table Name, Count

# 临时端口分配是否落在新范围
Get-NetTCPConnection | Where-Object { $_.LocalPort -ge 10000 -and $_.LocalPort -le 64999 } | Select-Object -First 5

8.2 压测小工具（C#，验证端口周转能力）

// 编译成小工具在测试网段跑，不要对生产外部服务乱打
using System;
using System.Net.Sockets;
using System.Threading.Tasks;

class PortFlood {
    static void Main(string[] args) {
        string host = args.Length>0 ? args[0] : "example.com";
        int port = args.Length>1 ? int.Parse(args[1]) : 443;
        int concurrency = args.Length>2 ? int.Parse(args[2]) : 1000;

        Parallel.For(0, concurrency, new ParallelOptions { MaxDegreeOfParallelism = 200 }, i => {
            try {
                using (var c = new TcpClient()) {
                    c.SendTimeout = 3000; c.ReceiveTimeout = 3000;
                    c.Connect(host, port);
                }
            } catch { }
        });

        Console.WriteLine("Done.");
    }
}

9. 变更前后对比（真实量化）

10. RPC 与端口范围的“隐形坑”

某些 RPC 服务 也会用动态端口。如果你的服务器既是客户端又是RPC 服务端，且你在入向做了严格的防火墙，只放了 49152–65535，现在改成 10000–64999 后，要同步调整放行。

需要固定 RPC 端口段时，可在注册表 HKLM\Software\Microsoft\Rpc\Internet 设定 Ports 和 PortsInternetAvailable，但这属于服务端的入站范围管理，和本文“出向端口耗尽”是两个方向，别混淆。

边界/云负载 SNAT：例如 F5/Azure LB，每个后端实例的 SNAT 端口数是有限的（成千上万级别）。Windows 端口池变大≠边界设备也变大，两边都得评估。

11. 回滚与变更记录（SOP）

变更单记录：

变更项：IPv4/IPv6、TCP/UDP 动态端口范围 10000–64999

变更命令与截图（show dynamicport 结果留档）

若改了 TcpTimedWaitDelay：记录原值与新值，附重启窗口

回滚（出现异常/合规要回退）：

# 回到默认（示例：49152-65535）
netsh int ipv4 set dynamicport tcp start=49152 num=16384
netsh int ipv6 set dynamicport tcp start=49152 num=16384
netsh int ipv4 set dynamicport udp start=49152 num=16384
netsh int ipv6 set dynamicport udp start=49152 num=16384

# 如调整过 TcpTimedWaitDelay，改回默认并重启

监控：把 TCPv4\Connections Established / Connections Active / Connections Passive / Connection Failures 拉进 PerfMon/Prometheus（WMI 导出）并设置阈值告警。

12. 常见问答（我在机房被问到的）

Q1：为什么不直接无限制拉大？
A：理论上上限是 1025–65535，但过大会让入向策略和合规审计复杂化；另外要留出少量特殊端口段。55k 在绝大多数出向场景已经很宽裕。

Q2：只改 IPv4 就够了吗？
A：很多环境仍以 IPv4 为主，但我建议 IPv6 同步，避免未来迁移/双栈时再踩坑。

Q3：为什么失败率降不到 0？
A：网络抖动、对端限流、边界 SNAT、DNS 抖动等都会带来残余错误。把“端口耗尽”从系统性瓶颈移除后，剩下的是业务侧与链路侧问题。

Q4：Windows Server 2012 已经过时了吧？
A：确实生命周期已结束，但现实是很多香港机房还有存量。本文方法依旧有效；如果能升级系统，TCP 栈与诊断工具都会更现代化。

13. 最小可行变更清单（贴墙速记）

• 扩大端口池：netsh int ipv4/ipv6 set dynamicport tcp/udp start=10000 num=55000
• 校验：netsh int ipv4 show dynamicport tcp、Get-NetTCPConnection 状态分布
• （可选）TIME_WAIT=60s：TcpTimedWaitDelay（注册表 + 重启）
• 防火墙/边界对齐：Windows FW + F5/SLB SNAT 端口池
• 应用侧复用：HttpClient 单例、连接池、Keep-Alive
• 监控：PerfMon 指标与 4227 事件告警

14. 尾声：把夜色“关掉”的那一刻

凌晨 04:05，告警面板的红色逐格褪去，我和网络同事对了个眼神——“先把咖啡换成水吧”。第二天上午我们把 TIME_WAIT 做了温和收敛，又推动了 SDK 团队改造连接池。两周后复盘，曲线安静得像是贴了静电膜。
做运维的成就感，有时候就是这样：不是去追风口，而是把那些“看不见的阀门”拧到合适的位置。

附录 A：一次性核查脚本（拷贝可用）

# HK-API-02 临时端口与连接健康体检
Write-Host "== Dynamic Ports =="
"netsh int ipv4 show dynamicport tcp" | cmd
"netsh int ipv6 show dynamicport tcp" | cmd

Write-Host "`n== TCP State Distribution =="
Get-NetTCPConnection | Group-Object State -NoElement | Sort Count -Descending | ft

Write-Host "`n== Top Remote Addresses =="
Get-NetTCPConnection | Group-Object RemoteAddress | Sort Count -Descending | Select -First 15 | ft

Write-Host "`n== 4227 Events (Last 2 hours) =="
Get-WinEvent -FilterHashtable @{LogName='System'; Id=4227; StartTime=(Get-Date).AddHours(-2)} | Select TimeCreated, Message | ft -Wrap

附录 B：变更记录模板（表格）

如果你也在香港机房、也有一台沉默地跑着出向 API 的 2012 老兵，遇到了“莫名其妙”的失败率飙升，不妨先照着本文把动态端口池拧大，再看 TIME_WAIT 与连接池的配合。大多数时候，问题不在天边，就在本机的 65535 之内。