香港链路延迟优化清单

定稿时间：2026-07-23。适用现状：香港 ECS（公网 IP 47.76.82.240，暂未挂域名/TLS）+ 同 VPC 内网 RDS PostgreSQL + Redis，上游为多个 API 中转渠道。本文只涉及部署与配置层面的优化，不涉及代码改动。配套阅读：香港生产部署执行手册、反向代理与 HTTPS、分阶段方案。

结论先行

请求链路拆成四段：

用户 ──A──> 香港 ECS 入口 ──B──> sub2api 内部处理（RDS/Redis）──C──> 下游中转渠道 ──D──> AI 源站

1. B 段（RDS/Redis 同 VPC 内网）已是最优解，不用动。
2. 最大优化空间在 C+D 段：多个订阅渠道之间按「实测 TTFT」择优排序，中转选址「顺路化」，能砍的中转层砍掉。选错一个中转位置，每请求就多 150~300ms。
3. A 段有前置欠账：当前明文 HTTP + 裸 IP 直连，执行手册里 Caddy + 域名 + TLS 那一步还没做。这既是安全问题（API Key/JWT 明文过公网），也堵死了 HTTP/3、TLS 会话复用、CDN/加速产品等一切入口层优化。
4. 先测量，再花钱。 流式场景用户感知的是 TTFT（首 token 时间），模型生成本身往往占 500ms~数秒。网络段占比不清楚之前，不买精品 BGP、不上 GA。

各段延迟量级（建立直觉用）

段	路径	典型量级	可优化性
A	用户 → 香港入口	亚太 30~80ms RTT；大陆晚高峰可抖到 150~200ms+；每次新建 TLS 连接额外 1~2 个 RTT	中（线路/协议层）
B	鉴权/限流/并发槽位（Redis、PG 内网往返）	个位数 ms	已最优，仅剩微调
C	香港 → 下游中转	同城 <5ms；日本/新加坡 30~60ms；美西 130~150ms；绕路可翻倍	高（选渠道、选位置）
D	中转 → 源站 + 模型排队生成	网络几 ms~百余 ms；模型 TTFT 500ms~数秒	只能靠选路和渠道质量

---

P0：立即执行（半天内）

1. 补上域名 + Caddy + TLS（安全 + 一切入口优化的前置）

按执行手册既定步骤：Caddy 绑 api.oneseatai.com 反代 127.0.0.1:8080，安全组只开 22（限自己 IP）/80/443。Caddy 默认同时启用 HTTP/2 与 HTTP/3（QUIC）——QUIC 对跨境高丢包链路收益明显（0-RTT 重连、无队头阻塞），TLS 1.3 会话复用让 SDK 长连接用户的握手成本趋近于零。

• [ ] api.oneseatai.com 解析到 ECS，Caddy 自动签证书成功，https://api.oneseatai.com/health 通过
• [ ] 检查暴露面：现在 http://47.76.82.240/ 能直接访问，说明 80 有直通或 BIND_HOST 未绑 127.0.0.1。对照执行手册验收项确认 5432/6379/8080 无公网暴露、.env 里 BIND_HOST=127.0.0.1
• [ ] 上 TLS 后通知用户切换 base_url，观察期结束后关闭 80 明文直通（仅保留 301 跳转）

2. ECS 开启 BBR（5 分钟，零成本）

Ubuntu 24.04 默认拥塞控制是 cubic；跨境丢包链路上 BBR 对流式响应的吞吐与尾延迟改善明显：

echo -e "net.core.default_qdisc=fq\nnet.ipv4.tcp_congestion_control=bbr" | sudo tee /etc/sysctl.d/98-bbr.conf
sudo sysctl --system
sysctl net.ipv4.tcp_congestion_control   # 应输出 bbr

• [ ] sysctl net.ipv4.tcp_congestion_control 输出 bbr

---

P1：拿数据 + 免费选路（1 天内）

3. 分段测量（所有花钱决策的依据）

用户侧 → 入口（A 段），分别在电信/联通/移动、平峰与晚高峰（21:00–23:00）执行：

mtr -rwzbc 50 47.76.82.240
curl -so /dev/null -w 'DNS:%{time_namelookup}s TCP:%{time_connect}s TLS:%{time_appconnect}s TTFB:%{time_starttransfer}s\n' https://api.oneseatai.com/health

ECS → 每个下游渠道（C 段），在 ECS 上对每个渠道 base_url 执行，平峰/晚高峰各几轮：

curl -so /dev/null -w 'DNS:%{time_namelookup}s TCP:%{time_connect}s TLS:%{time_appconnect}s TTFB:%{time_starttransfer}s\n' https://<渠道域名>/v1/models

判读：TLS - TCP 大 → 握手贵（渠道远，或连接没被复用）；TTFB - TLS 大 → 渠道处理慢或它到源站远。

端到端 TTFT（C+D 段）：用低额度 Key 对每个渠道发一个便宜模型的流式请求，记录首个 SSE 事件到达时间。

• [ ] 三大运营商晚高峰到香港入口的 RTT/丢包基线已记录
• [ ] 每个渠道的 DNS/TCP/TLS/TTFB 分解数据已记录（平峰 + 晚高峰）
• [ ] 每个渠道的端到端流式 TTFT 已记录
• [ ] （建议长期化）cron + 低额度专用 Key 的合成拨测落地，按渠道记录 TTFT 与 429/529 率

4. 按实测 TTFT 调整渠道权重

sub2api 管理后台里渠道优先级/权重就是为此准备的：低 TTFT 渠道设为主力，高延迟渠道降为兜底。这是零成本、立竿见影的选路优化。

• [ ] 渠道权重已按测量数据重排，主力渠道 = TTFT 最低的渠道
• [ ] 429/529 率高的渠道已降权（上游并发额度不足时，加机器/买线路都无效）

5. B 段微调三项

• [ ] Redis 主节点与 ECS 同可用区：跨 AZ 主从架构下，控制台确认主节点在可用区 D（与 ECS 一致）。鉴权/槽位/限流每请求多次 Redis 往返，跨 AZ 每次多 ~1ms；主从切换后主节点可能漂走，需要切回
• [ ] 验证 SSE 不被压缩层缓冲：deploy/Caddyfile 的 encode 按 Content-Type text/* 匹配，会命中 text/event-stream。按反向代理与 HTTPS的 curl -N 方法验证事件逐段到达；有缓冲迹象则对 /v1/* 单独关闭 encode
• [ ] 主机基线：ulimit -n 拉高（fd 由应用 + Caddy + 上游连接共同消耗），确认 net.ipv4.ip_local_port_range 够宽。Docker bridge NAT 开销可忽略，不折腾 host network

---

P2：结构性优化（数天）

6. 下游中转「顺路化」与减层

• 理想中转位置在「香港 → 源站」路径上（源站在美国时即日本/美西方向）。香港 → 美西一跳约 130~150ms，中转在美西则它到源站 <10ms，总路径接近直连；反之香港 → 新加坡中转 → 美国源站属于绕路，白吃 60~80ms。

• 执行手册已确认「无出口 IP 风控顾虑」——凡是拿得到最终上游直连方式的渠道，评估让 sub2api 直连源站，砍掉整层中转：少一次 TLS 握手、少一次转发处理、少一个故障点。

• 保住连接复用：自己控制的下游把入口 keepalive idle 拉到 ≥90s；渠道单独挂代理会导致每请求重建隧道，尽量避免。观察方式：测量数据里 TLS 时间列总是不为零 ≈ 一直在重新握手。

• DNS 保持 ECS 默认阿里内网 DNS（100.100.2.136/138），不要改成境外公共 DNS。

• [ ] 自控下游已迁至源站同区域（或确认现址已顺路）

• [ ] 可直连源站的渠道已直连，中转层数已最小化

• [ ] 自控下游入口 keepalive idle ≥90s，无渠道级代理导致的短连接

7. 大陆用户线路 A/B（如大陆占比高）

• 加一个 Cloudflare 代理的域名做 A/B 对比（自定义域名大陆可达，质量随运营商/时段波动；CF 空闲超时约 100 秒，应用默认 stream keepalive 10 秒可保活）。

• 按执行手册计划，保留一个不走 CF 的直连备用域名写进用户文档作 fallback。

• API 路径经任何 CDN 时必须禁用缓存，核对项见反向代理与 HTTPS。

• [ ] CF 代理域名与直连域名的晚高峰 TTFT 对比数据已记录

• [ ] 不走 CF 的备用直连域名已配置并写入用户文档

---

P3：花钱项（先有 P1 数据再决策）

只有 P1 测量证明 A 段占端到端延迟的比重足够大（例如 >30%）时才考虑：

• 精品 BGP EIP：香港 BGP（多线）精品约 232 元/Mbps/月（分阶段方案 §路线 C），5 Mbps 仅带宽约 1,160 元/月。

• 阿里云 GA：跨境加速涉及资质审核与合规承诺，不是开关即用。

• [ ] P1 数据显示 A 段占比 >30% 且 P2 已做完，才进入采购评估

• [ ] 采购前按分阶段方案价格复核清单出续费级报价

优先级速查

优先级	动作	成本	预期收益
P0	域名 + Caddy + TLS；检查 8080/BIND_HOST 暴露	半天	安全质变；解锁 H2/H3 与全部入口优化
P0	ECS 开 BBR	5 分钟	跨境流式尾延迟改善
P1	分段测量 + 合成拨测	半天	拿到所有决策数据
P1	按 TTFT 调渠道权重；Redis 同 AZ；验证 SSE 不缓冲	1 小时	立竿见影的选路收益
P2	中转顺路化/减层；大陆 CF 域名 A/B	数天	C 段每请求省 50~300ms
P3	精品 BGP / GA	232 元/Mbps/月起	仅当 A 段被证明是大头