为什么给新加坡服务器加代理，修不好国内用户的访问？

① 先把后文会反复出现的词认清楚

先认词：这一课会同时讨论“用户怎么进入服务”“服务器怎么访问上游”“长连接为什么会卡”和“Clash 为什么开了 Global 还可能没接管流量”。先把控制位置不同的术语分开，再做综合判断。

② 现在再看这段材料到底在说什么

一句话本质：如果真正不稳定的是“用户 → 新加坡 Sub2API”这一段，那么你必须改变用户进入系统的路径；只在新加坡服务器里增加出站代理，只会改变“Sub2API → GPT/Claude 上游”这一段，无法倒过来修复已经发生在用户侧入口之前的连接问题。

因此，“香港节点”不是把整个业务搬到香港，也不是第二套数据库。更准确地说，它是一个前置接入层：客户端先连接一个更容易稳定到达的香港入口，入口完成 TLS、长连接保持和反向代理，再把请求转发到仍然位于新加坡的业务源站。新加坡继续负责账号、鉴权、计费、渠道调度、数据库和 Redis，香港尽量保持无状态。

③ 概念关系与最小知识闭包

1. 概念分类关系：它在网络体系里属于什么？

2. 学习依赖关系：应该按什么顺序理解？

3. 一个主比方：把接入层想成“离客户更近的收件站”

可以把整个系统想成跨城物流。中国大陆用户是寄件人，新加坡 Sub2API 是中央仓库，模型上游是更远的供应商。服务器出站代理相当于中央仓库换了一家“去供应商的运输公司”；它可以改善仓库到供应商，但如果寄件人连中央仓库的大门都经常堵住，这个变化对寄件人的第一段路没有帮助。

香港反向代理则像在离寄件人更近、线路更稳定的位置增加一个官方收件站：用户只需要把包裹交到香港，香港再用稳定干线送到新加坡中央仓库。中央仓库仍然负责订单、库存和结算，所以业务状态没有被复制到香港。

最小知识闭包 1：为什么“出站代理”修不好“入站链路”？

把网络看成有向图。客户端 C 到新加坡源站 S 的入站路径记为 P_in(C,S)；新加坡源站到模型上游 U 的出站路径记为 P_out(S,U)。服务器里的 mihomo 改变的是后者的路由选择函数，而不是前者。

如果坏的是第一项，你只优化第二项，第一项仍然坏。香港前置接入的作用，就是把第一项的路径结构改写为 C → H → S。

最小知识闭包 2：多一跳为什么反而可能更快、更稳？

“少一跳一定更快”是常见误区。互联网不是欧氏平面上的直线距离问题。真正决定路径质量的是运营商互联、跨境出口、拥塞、路由绕行、丢包和对端接入质量。香港节点虽然增加一个逻辑中转，但如果大陆到香港和香港到新加坡的两段都比大陆直接到新加坡更稳定，总体验可以改善。

这里 ε_proxy 是香港代理自身增加的处理开销。对于纯转发的 Caddy/Nginx，它通常应远小于公网路径差异；但这需要实测，不能靠机房宣传词推断。

最小知识闭包 3：RTT 与 TTFB 看的是不同东西

RTT更接近“网络来回一趟要多久”；TTFB则是“从客户端发起请求，到收到 HTTP 第一个响应字节总共等了多久”。TTFB 会叠加 DNS、TCP/TLS 握手、代理排队、应用处理和上游等待，所以 RTT 正常而 TTFB 很大，不能直接下结论说“线路没问题”。

最小知识闭包 4：流式接口不是普通短请求

模型 API 常常不是“请求 → 几十毫秒返回一个完整 JSON”这么简单。流式响应会保持连接很久，并持续吐出小块数据。SSE 是服务器单向持续推送；WebSocket 是双向长连接。对这类连接，代理若默认缓冲、空闲超时太短、读超时太短，都会造成“首包正常但后面卡住”“token 一坨一坨出来”或中途断流。

普通短请求：
client ── request ──→ proxy ──→ origin
client ←── whole response ──────── origin

流式请求：
client ← chunk ← chunk ← chunk ← ... （连接持续存在）

最小知识闭包 5：30 次无超时不能证明 99.9%

“30 次冷连接没有失败”是一个有价值的 smoke signal，但统计上远不足以支持“成功率至少 99.9%”。如果把每次连接近似看成独立伯努利试验，零失败时常用 rule of three 粗估 95% 置信上界：失败率 q ≈ 3/n。

因此 n=30 时只能粗略排除“非常高的失败率”；若希望用零失败样本把 95% 上界压到 0.1% 左右，量级上需要约 3000 次，而且还要跨运营商、时段和网络环境采样，因为现实网络故障并不独立同分布。

最小知识闭包 6：Forward Proxy 和 Reverse Proxy 为什么名字很像、作用却相反？

前向代理站在客户端一侧，代表用户去访问外部目标；反向代理站在服务端一侧，代表一个服务接住外部用户，再把请求交给内部源站。Clash/mihomo 用在个人电脑上时通常是前向代理；Caddy/Nginx 放在 ai.rest2build.lol 前面时是反向代理。

这两个概念的判别方法不是看软件名字，而是问一句：这个代理是在替谁隐藏/选择下一跳？替客户端选外部目标路径，是 forward proxy；替服务端隐藏和保护内部 origin，是 reverse proxy。同一个软件在不同部署位置甚至可以扮演不同角色。

最小知识闭包 7：为什么“无状态香港节点”仍然需要安全设计？

所谓无状态，主要是说香港节点不保存余额、订单、用户数据库和业务真相；这能让它容易替换、扩容和故障切换。但它仍然终止公网连接，通常能看到来源 IP、Host、请求路径、Header 大小和连接持续时间。如果 TLS 在香港终止，它还会在内存中处理解密后的 HTTP 请求。

因此生产入口仍要做最小日志、Authorization 等敏感 Header 脱敏、系统补丁、速率限制和来源可信链。若需要把真实客户端 IP 传给新加坡，可以使用 X-Forwarded-For / Forwarded 等头，但新加坡只能信任自己控制的香港代理写入这些头，不能盲信公网客户端自带值。

最小知识闭包 8：WireGuard 解决的是哪一类问题？

WireGuard 不会自动让大陆用户到香港更快。它位于香港 → 新加坡这一段，主要价值是给两个你控制的节点建立加密的三层隧道，让源站业务端口可以只在隧道地址上开放，并简化“只允许香港访问新加坡”的网络策略。

如果香港到新加坡公网本身质量已经很好，直接使用双向 TLS + 严格 ACL 也可能满足需求；是否上 WireGuard 应由安全边界、运维复杂度、MTU、故障定位和实际线路表现共同决定。隧道本身也可能因 MTU 不匹配产生“短请求正常、大包或长连接异常”的问题，所以要测真实负载。

最小知识闭包 9：HTTP/2 有帮助，但不是“加速开关”

HTTP/2（Hypertext Transfer Protocol Version 2，超文本传输协议第 2 版）可以在一条连接里多路复用多个请求，并通过头部压缩等机制减少部分开销。它适合入口层，但它不会修复底层跨境路径丢包，也不会替代 SSE/WebSocket 的超时和缓冲配置。

网络工程里要避免“支持了 HTTP/2，所以一定更快”这种单变量推理。真实体验取决于连接复用、TLS、拥塞、请求大小、服务端实现和用户网络；最可靠的方法仍然是端到端测量。

最小知识闭包 10：为什么平均值经常骗你？

假设 99 次请求都是 100 ms，另 1 次超时 10 秒，平均值看起来仍可能“还不错”，但用户会明确感知到失败。因此生产网络更关心分位数和失败率：p50 表示典型体验，p95/p99 暴露长尾，timeout rate 直接反映可用性。

对于 API 中转站，建议把监控按运营商 × 城市/探针 × 时间分桶，再看 p50/p95/p99 和错误类型。否则“全国平均 200 ms”可能掩盖某个运营商晚高峰大量超时。

④ 把真实案例重新还原

把 Sub2API 的真实链路拆开

中国大陆用户 / Codex / Claude Code
            │
            │ ① DNS：ai.rest2build.lol → 香港入口
            ▼
香港优化线路接入节点 H
Caddy / Nginx
TLS 终止 · HTTP 转发 · SSE/WebSocket 长连接
            │
            │ ② WireGuard 或受控公网链路
            ▼
新加坡 Sub2API 源站 S
鉴权 · 计费 · 渠道调度 · DB / Redis
            │
            │ ③ 现有 mihomo / egress
            ▼
GPT / Claude 等上游 U

第一阶段：单香港入口，先证明方向

ai.rest2build.lol
      ↓
Hong Kong ingress
      ↓
Singapore Sub2API

保留一个源站管理域名，例如 origin.ai.rest2build.lol，但它应该面向运维而不是普通客户：可以限制来源 IP、要求 VPN/WireGuard、额外认证，避免用户绕过香港入口直接打源站。

第二阶段：去掉香港单点

Hong Kong ingress A ─┐
                      ├──→ Singapore Sub2API
Hong Kong ingress B ─┘

双节点之后还需要真正的健康切换机制。简单放两个 A 记录只能提供有限的客户端重试机会，并不等于严格的故障转移；更可靠的是带健康检查的 DNS/边缘调度或上层负载入口，同时要观察 DNS TTL 和切换收敛时间。

为什么新加坡安全组要收紧？

一旦香港成为正式入口，新加坡公网源站就不应继续对所有互联网开放相同业务端口。常见做法是：只允许香港节点公网 IP 访问源站 443，或者仅开放 WireGuard 端口、让业务流量走隧道内网地址。这样既减少绕过入口的路径，也降低源站被扫描和直接打流量的暴露面。

⑤ 概念如何映射到现实

代理到底接在哪一侧？

Clash 的几个开关为什么容易误解？

流式 API 的反向代理配置应该关心什么？

选香港节点时到底看什么？

“香港机房”只是地理标签，不能推出大陆访问质量。常见市场标签如 CN2/GIA、CMI、CTGNet、三网优化可以作为筛选线索，但不能替代实测。真正要看的是中国电信、中国联通、中国移动分别到该节点的去程/回程、拥塞和稳定性。

对你这个案例，可以把“大致 15–40 ms 的大陆到香港 RTT、健康接口 50–200 ms 的 TTFB、30 次冷连接无超时、SSE 不缓冲不截断”当作第一阶段工程验收目标，但不要把它们包装成供应商普遍保证。尤其“99.9% 成功率”应该由长时间、多地域、多运营商的监测数据支持，而不是 30 次人工测试。

几个特别容易混淆的边界

一套更可靠的验收分层

⑥ 现在把它当成一道题

现在假设你得到下面一组持续 7 天的合成监测数据，采样覆盖中国电信/联通/移动三个网络，每条线路各约 1 万次健康请求，同时每天跑长时间 SSE：

⑦ 分级提示，最后就是实际答案