主题
Hapi 进阶：优选 IP 配置
这一页讲怎么在 Hapi 里配「优选 IP」，把 Agent 发出的 LLM 请求走更稳的节点。先说清楚它在哪些场景有用、哪些场景没用——不是所有人都该配。
它解决什么
优选 IP 的本质是绕开运营商默认 anycast 路由，自己指定一组实测延迟低、丢包少的目标 IP，让 HTTP 请求走更优链路。
代价是这组 IP 可能过段时间失效（云厂商动态调度），需要定期重新挑。
适用 / 不适用场景
| 场景 | 用不用优选 | 原因 |
|---|---|---|
| Hapi 内跑的 Agent 直连 OpenAI / Anthropic / Google 官方 API | 建议优选 | 官方 API 挂在 Cloudflare / Google 边缘后面，国内常被路由到欧洲 |
| Hapi 内跑的 Agent 走 why01 中转 | 不需要 | why01 源站直连东京（2026-05-11 已撤 CF 代理），中间没有 CF anycast 可优选 |
| Hapi 部署在海外 VPS | 多半不需要 | 海外到上述 API 通常已经是较优路由 |
| Hapi 部署在国内 VPS / 本机 | 视实测 | 跑 配置前 vs 配置后 对比，看你的运营商默认路由是否绕路 |
一句话判断
目标 API 走 why01 = 不用优选；目标 API 直接连官方 = 优选有意义但要定期换。
配置前 vs 配置后
下面这组对比是上游伙伴提供的实测截图（运营商 / 时段会影响绝对数值，自己跑一次更准）：
| 阶段 | 截图 |
|---|---|
| 优选前 |  |
| 优选后 |  |
配置步骤
1. 获取候选 IP 列表
通用做法是用开源的 Cloudflare 优选 IP 测速工具（GitHub 搜「CloudflareSpeedTest」之类的项目，本站不引用具体仓库以避免链接失效）跑一遍：
- 测速工具会在本地拉一组 CF IP，按延迟 / 丢包 / 下载速度排序输出 Top N
- 取前 5-10 个备用，不要只用第 1 个（防失效）
2. 在 Hapi 里填入优选 IP
进 Hapi 的网络 / hosts 设置（不同版本 UI 路径略有差异），填入目标域名 + 候选 IP 的映射。本质相当于给 Hapi 进程加了一份私有 hosts 文件。
例（示意，按你目标域名替换）：
api.anthropic.com <候选 IP 1>
generativelanguage.googleapis.com <候选 IP 2>不要把 s1.why01.top 写进优选列表
why01 源站不在 CF 后面，硬写优选 IP 会导致请求发到错的目标（CF 节点收到不在它管辖范围的域名，返回 1003 / 1014 错误）。
3. 验证
最直观的验证：在 Hapi 跑一个小任务（让 Claude 算个 1+1），看两个指标：
- 首字延迟（time-to-first-token，控制台「日志」每条记录有耗时）
- 失败率（连续跑 20 次，看 4xx/5xx 比例）
优选生效的标志：首字延迟下降明显（典型从 1.5s 降到 0.6s 以下）、失败率不升高。
常见问题
优选 IP 多久要换一次？
云厂商 anycast 动态调度，1-2 周建议重测一次。如果你发现 Hapi 任务突然变慢或频繁报连接重置，先重测优选。
哪些情况下完全不需要优选？
- 走 why01 中转——源站直连东京，本身没有 CF 边缘要绕
- 海外 VPS 部署 Hapi——上游 API 对海外节点路由本来就好
- 企业专线 / 走代理走梯子——专线 / 代理的链路质量已经稳定，硬加优选反而干扰
优选 IP 算「翻墙」吗？
优选 IP 本身只是告诉 OS 把某个域名解析到指定 IP，不绕过任何中国大陆的网络管控。被封的目标域名优选 IP 也访问不通；CF / Google 这种没被全局封的边缘网络才有优选意义。