自建 NAT 高可用是什么
用一台云主机自建 NAT 出口（iptables MASQUERADE 或 nftables、或 NAT 软件）成本低，但天然是单点：这台机器故障或重启，整个 VPC 的出网就断了。常见高可用做法是两台出口机配合高可用虚拟 IP，用 keepalived 主备漂移；另一种做法是直接换成托管 NAT 网关，把高可用责任交给平台。
基本信息
| 主备方案 | 两台出口机 + 高可用虚拟 IP（HAVIP）+ keepalived |
|---|---|
| 健康检查 | 对公网出口做探测，连续失败达到阈值触发主备切换 |
| 切换要点 | VIP、iptables/nftables 规则、内核转发参数、路由需一并同步 |
| 备用机状态 | 保持规则已加载，避免切换后才补配置 |
| 替代方案 | 云托管 NAT 网关，节点故障由平台自动处理 |
| 成本构成 | 主机 + 带宽/EIP + 运维人力 |
典型使用场景
- 小规模环境想省成本，用一台或两台主机做统一出口
- 需要做出口流量的白名单、审计、协议拦截等自建定制逻辑
- 与自建代理、日志采集联动，托管 NAT 不支持的场景
- 临时测试环境，用完即释放
- 多云/混合云统一出口，自建出口可以跨环境保持同一套规则
自建与托管对比
| 维度 | 自建 NAT 主备 | 托管 NAT 网关 |
|---|---|---|
| 高可用 | 需自己实现检测与切换 | 平台多节点，自动切换 |
| 运维成本 | 升级、规则、演练都要自己管 | 基本免运维 |
| 定制能力 | 强，可任意改写转发规则 | 受产品能力限制 |
| 弹性 | 受单机规格限制，扩容要换机型 | 可按需调整规格 |
| 故障面 | 主机、系统、规则任一环出错即断网 | 故障面集中在配置错误 |
出口健康检查与切换骨架
出口健康检查与切换骨架
#!/bin/bash
# 每 10 秒探测公网可达性，连续失败达到阈值触发切换
curl -s --connect-timeout 3 -o /dev/null https://www.example.com \
&& miss=0 || miss=$((miss+1))
[ "$miss" -ge 3 ] && echo "trigger failover (miss=$miss)"
# 切换动作至少包含：VIP 漂移、net.ipv4.ip_forward 确认、
# iptables/nftables 规则加载、到 NAT 网段的回程路由发布自建高可用方案可行，但维护成本和故障面都高于托管产品：评估时把升级、演练、值班人力一起算进成本，多数情况下省下的钱不足以覆盖一次断网事故。
切换脚本要幂等且可重入：切换过程中被重复触发不能叠加规则或产生半套配置；建议把「检测」与「执行」分离，执行前先做一次配置一致性校验（转发开关、规则、路由三项齐全）。