STUN / TURN 自建部署调研

NAT 类型决定要不要中继

移动网络的运营商级 NAT（CGNAT）是打洞失败的主因，跨双层 CGNAT 时几乎必然回落中继（APNIC）。反向的好消息是 IPv6 双端可用即可绕过 NAT 直连：全球 IPv6 采用率已约 49.6%（Google，2026-07-26），越南约 65%+、墨西哥约 57.7%，而印尼仅约 26%——同样的产品，在印尼要按更高的中继占比做预算，在越南/墨西哥可以更乐观。

1）一路中继到底吃多少带宽

• TURN 服务器对一路中继流是收进来再转出去：网卡吞吐 ≈ 2 × 单向码率。若一通双向通话的两个方向都经同一台 TURN，网卡吞吐 ≈ 4 × 单向码率。
• 计费口径不同：托管商（Cloudflare/Twilio）通常只按出网（egress）计费，入网免费；云主机自建同理只收出网。所以"计费 GB ≈ 单向码率 × 时长 × 走中继的方向数"。
• 音频：Opus 宽带净荷 16–24 kbps，加 RTP/UDP/IP/SRTP 头后线路约 30–50 kbps/方向，工程按 50 kbps 估；每方向每小时 ≈ 22 MB，双向 ≈ 45 MB/小时。
• 视频 720p（含音频）按 1.5 Mbps：每方向每小时 ≈ 675 MB，双向 ≈ 1.35 GB/小时——视频比音频贵 30 倍，是自建与否的真正分水岭。

# 月度中继流量速算公式（出网口径）
月 GB = 单向码率(kbps) ÷ 8 ÷ 1024 × 3600 ÷ 1024 × 通话小时 × 中继占比 × 中继方向数

# 例 A：50 席网页座席，人均 6 通话小时/天 × 22 天 = 6,600 小时/月，音频 50kbps，中继占比 20%，双向
6600 × 0.2 × 0.045 GB/h ≈ 59 GB/月   → Cloudflare 免费额度（1 TB）内，$0
# 例 B：10 万分钟/月 PSTN 外呼（SIP 中继）
0 GB  ← 不经 TURN
# 例 C：同样 6,600 小时但是 720p 视频客服，中继占比 20%，双向
6600 × 0.2 × 1.35 GB/h ≈ 1,782 GB/月 → 托管 Twilio 新加坡 ≈ $1,069／Cloudflare ≈ $39／自建 VPS ≈ $20–40

coturn 项目健康度：2022 年的"濒死"叙事已过时

• 历史：创始人离开 → 2021 秋停更 → 社区发帖问 "is this project dead?" → 2022 年 Pavel Punsky（@eakraly）等接手救活（webrtcHacks 专访）。
• 现状：2026 年 6–7 月连发 4.12.0 → 4.16.0，内容涵盖性能（--udp-recvmmsg Linux 默认开启、--multiplex-peer）、可观测（Prometheus 重写、支持 HTTPS 指标端点）、协议（RFC 8016 mobility 平滑切换）与大量安全修复。
• 代价：密集的安全修复本身印证了老 C 代码库的固有风险。EnableSecurity 的判断很直白——"coturn 是部署最广的 TURN 服务器，也是我们发现漏洞最多的那个"。运维纪律：把 coturn 当作需要主动追版本的组件，而不是装完就忘的基础设施。
• 扩展哲学：维护者明确解释了为什么没有 Helm chart——TURN 是全球性系统（DNS 就近 + 区域内轮询 + 共享用户库），无法用一条 helm install 表达。

如果你已经在用 LiveKit / Jitsi / mediasoup

• LiveKit 自带 TURN，且与信令认证打通（只有已建 signal 连接的客户端能用其 TURN，不需要独立凭据体系）。注意：不挂 LB 时 turn.tls_port 必须是 443（这是对客户端广告的端口）；挂 L4 LB 时 443→5349 并设 external_tls: true；云上还要 rtc.use_external_ip: true。
• Jitsi Meet Debian 安装默认带 coturn（3478/UDP + 5349/TLS），凭据由 Prosody 走 XEP-0215 下发临时凭据；官方手册给的 443 复用做法就是 nginx stream + ssl_preread 按 SNI 分流。
• mediasoup / Janus 服务端通常不需要 TURN：mediasoup 实现 ICE-Lite、永远做 ICE server，浏览器与媒体服务器直连；TURN 只作为客户端侧在封 UDP 网络下的中继。这条恰好解释了为什么客服星型架构的 TURN 用量远低于 P2P 产品。
• K8s 环境：coturn 的 relay 端口区间与 K8s Service 模型天然冲突（Service 无法声明端口区间），因此大家被迫 hostNetwork: true——这是官方文档明示的反模式（每节点只能一个媒体 Pod、公网 IP 上全 UDP 敞开），且 GKE Autopilot 直接禁用 hostNetwork。要云原生就上 STUNner，或干脆把 TURN 放回 VM。

turnserver.conf 关键段（合并官方文档 + EnableSecurity 加固模板，已剔除过期参数）

# ── 监听与中继 ─────────────────────────────
listening-port=3478
tls-listening-port=5349
alt-tls-listening-port=443          # 企业防火墙"核选项"；与 Web 共 IP 时见第七章
listening-ip=0.0.0.0
external-ip=<公网IP>                 # 云上 1:1 NAT 必填，可写 公网IP/内网IP
relay-ip=<公网IP>
min-port=49152
max-port=65535                      # 可收窄；收窄即降低单机 allocation 上限

# ── 认证：时限凭据 ──────────────────────────
lt-cred-mech
use-auth-secret
static-auth-secret=<openssl rand -hex 32>
realm=t                              # 短 realm 可减小 401 响应体积（降低放大倍数）
stale-nonce=600

# ── TLS ───────────────────────────────────
cert=/etc/letsencrypt/live/turn.example.com/fullchain.pem
pkey=/etc/letsencrypt/live/turn.example.com/privkey.pem
cipher-list="HIGH"
# 注意：no-tlsv1 / no-tlsv1_1 在 4.7.0 已被移除，写了会报 Bad configuration format

# ── 访问控制（防中继滥用，第一优先级）────────
no-multicast-peers
denied-peer-ip=0.0.0.0-0.255.255.255
denied-peer-ip=10.0.0.0-10.255.255.255
denied-peer-ip=172.16.0.0-172.31.255.255
denied-peer-ip=192.168.0.0-192.168.255.255
denied-peer-ip=127.0.0.0-127.255.255.255
denied-peer-ip=169.254.0.0-169.254.255.255   # 云元数据服务 169.254.169.254
denied-peer-ip=100.64.0.0-100.127.255.255
denied-peer-ip=224.0.0.0-239.255.255.255
denied-peer-ip=240.0.0.0-255.255.255.255
denied-peer-ip=::1
denied-peer-ip=::ffff:0.0.0.0-::ffff:255.255.255.255  # 关键：堵 IPv4-mapped 绕过
denied-peer-ip=fc00::-fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
denied-peer-ip=fe80::-febf:ffff:ffff:ffff:ffff:ffff:ffff:ffff
# 若媒体只发往自家 SFU，改用白名单最稳（Zoom 的做法）：
# allowed-peer-ip=<SFU公网IP> + denied-peer-ip=0.0.0.0-255.255.255.255

# ── 协议瘦身 ───────────────────────────────
no-tcp-relay                          # WebRTC 只要 UDP 中继，关掉 RFC6062
# no-rfc5780 / no-software-attribute 在 4.7.0+ 已是默认，无需再写
unauthorized-ratelimit                # 4.14.0+，限制 UDP 401 反射（实验性，先灰度）
unauthorized-ratelimit-rps=10

# ── 限额（按实际峰值给余量，别照抄）─────────
user-quota=100
total-quota=10000                     # 全服务器上限：设太小 = 自制 DoS（错误 486）
max-allocate-lifetime=3600
max-bps=<单会话上限>
bps-capacity=<整机带宽上限>

# ── 运维面与进程 ───────────────────────────
no-cli                                # 管理面是历史 CVE 高发区，一律关
# web-admin 不要开
prometheus
proc-user=turnserver
proc-group=turnserver
log-file=/var/log/coturn/turnserver.log
syslog

防火墙与内核（最常见的"能连上但没声音"就出在这）

# 端口：信令口 + 中继口，云安全组与主机防火墙两层都要开
ufw allow 3478/udp; ufw allow 3478/tcp
ufw allow 5349/udp; ufw allow 5349/tcp
ufw allow 443/tcp
ufw allow 49152:65535/udp        # ← 忘了这条：allocate 成功、媒体不通

# /etc/sysctl.d/99-coturn.conf
net.core.rmem_max=26214400
net.core.wmem_max=26214400
net.core.netdev_max_backlog=65536
net.ipv4.udp_rmem_min=8192
net.ipv4.udp_wmem_min=8192
fs.file-max=2097152

# /etc/systemd/system/coturn.service.d/limits.conf
[Service]
LimitNOFILE=1048576

后端签发时限凭据（TURN REST API 事实标准）

// username = 过期时间戳[:业务ID]，credential = HMAC-SHA1(username, secret) 的 base64
function turnCredentials(secret, ttl = 12 * 3600) {
  const username = `${Math.floor(Date.now()/1000) + ttl}:agent-42`;
  const credential = crypto.createHmac('sha1', secret).update(username).digest('base64');
  return { username, credential };
}
// 下发多个 URL 让 ICE 自行竞速：UDP 优先，TCP/TLS 443 兜底，再挂一个托管商做异地冗余
iceServers: [
  { urls: 'stun:turn-sg.example.com:3478' },
  { urls: ['turn:turn-sg.example.com:3478?transport=udp',
           'turns:turn-sg.example.com:443?transport=tcp'], username, credential },
  { urls: 'turn:turn.cloudflare.com:3478', username: cfUser, credential: cfCred }  // 兜底
]

注意：draft-uberti-behave-turn-rest-00 早已过期但仍是事实标准，coturn / eturnal / Cloudflare 都兼容。TTL 别给太长（Cloudflare 侧上限 48 小时），且必须服务端签发。

为什么必须有 443

• 企业防火墙、酒店/机场网络、部分运营商会直接封 UDP 3478/5349；TURN over TLS on TCP 443 长得像普通 HTTPS，是穿透率最高的兜底。厂商经验：不配 443 的话，企业环境会有 15–20% 的通话失败。
• 代价必须认清：TCP 中继在丢包网络上会因重传与队头阻塞抬高延迟与抖动——它是兜底，不是主路径。ICE 的候选优先级本身会让 UDP 优先，只要 UDP 通就不会走它。

同一 IP 上同时跑 Web 和 TURNS：nginx stream + ssl_preread 按 SNI 分流

# 需要 nginx ≥1.11.5 且编入 stream_ssl_preread 模块（Jitsi 官方手册同款方案）
stream {
  map $ssl_preread_server_name $backend {
    turn.example.com  127.0.0.1:5349;   # TURNS → coturn
    default           127.0.0.1:8443;   # 其它 → Web
  }
  server {
    listen 443;
    ssl_preread on;
    proxy_pass $backend;
    proxy_timeout 3600s;                # 长通话别被默认超时切断
  }
}

nginx 只读 ClientHello 的 SNI、不解密，因此不影响 DTLS/SRTP 端到端加密。若 TURN 独占一个 IP，直接 alt-tls-listening-port=443 更简单——但注意 443/UDP 也建议放开（可蹭 QUIC 放行策略）。

区域选点（东南亚 + 拉美）

• 东南亚：新加坡（AWS/GCP/Azure/阿里/腾讯/DO/Vultr 全有）为主枢纽；雅加达（AWS ap-southeast-3、GCP、阿里云）覆盖印尼本地；曼谷（AWS 泰国区 ap-southeast-7，2025-01 GA）。
• 拉美：圣保罗（AWS sa-east-1、GCP、Azure、Vultr）覆盖南美锥体；墨西哥中部（AWS Querétaro 2025-01 GA、GCP、Azure）覆盖墨西哥+中美。
• 选点纪律：TURN 应与用户就近，而不是与自家机房就近；同时尽量与媒体网关/SFU 同区域，避免"用户→TURN→跨洲 SFU"两跳绕行。各国到区域的具体 RTT 需自测（云商延迟矩阵/wondernetwork），不要照抄经验值。

三条反直觉总结

• 自建不一定省钱：在大云上自建（出网 $80–120/TB）比 Cloudflare TURN（$50/TB，前 1 TB 免费）更贵；省钱的前提是选含流量套餐的主机。
• 厂商标称容量是网卡打满值：1 Gbps 机器"10,000 路音频"反推正好 1.0 Gbps，实际可运营量要打 4–6 折；视频标称 1,000 路反推 3 Gbps，根本不成立。
• 外呼业务的 TURN 账单可能接近 0：PSTN 链路不经 TURN，星型架构又让多数客户端直连——先量出自己的 relay 占比，再决定要不要自建这套东西。

验证清单

1. 监听确认：ss -tulpn | grep turnserver，3478/5349/443 齐全。
2. 协议连通：turnutils_uclient -t -T -v -u USER -w PASS turn.example.com（TCP/TLS 分别跑）；openssl s_client -connect turn.example.com:443 -servername turn.example.com 验 SNI 分流与证书链。
3. 强制走中继：浏览器侧把 iceTransportPolicy 设成 'relay'，只有这样才真的在测 TURN（默认 'all' 时通常直连，测不到）。
4. 候选类型统计：Trickle-ICE 页面 + chrome://webrtc-internals 看选中候选是 relay / srflx / host，并把这个指标接进生产埋点。
5. 指标与告警：coturn Prometheus 端点（4.14+ 支持 HTTPS）+ node-exporter；告警项：分配速率突增、带宽尖峰、认证失败率、ACL 拒绝次数、证书到期。
6. 横向对标：ICEPerf.com 提供各托管 TURN 的 STUN/TURN 候选延迟与建连时间公开数据，可作为"自建是否值得"的外部参照。

与现有报告矩阵的衔接

媒体链路与自研架构：RTC 自研架构 ↗ / RTC 全球基础设施 ↗；编排框架与 wss 媒体流对接：语音 Agent 编排框架；把中继流量并入单通成本：全链路单通成本模型；PSTN 侧线路与合规：东南亚 / 拉美线路。