Claude Code 卡在 TTFT 40 秒？KingFlow 国内节点 1-3 秒延迟实测

用 Claude Code 写代码的人应该都有过这种体验：敲完回车，光标在那儿一动不动，等了半天第一个字才蹦出来。任务本身不难，模型也不慢，慢的是你到模型之间那条路。这篇我不聊玄学，只做一件事——把 TTFT（Time To First Token，首字延迟）掰开揉碎讲清楚，然后用三种节点位置的实测数据告诉你：为什么同样是 Claude Code，有人用起来像本地工具，有人用起来像拨号上网。

一、什么是 TTFT，为什么它决定 Claude Code 爽不爽

TTFT 指的是：你发出请求，到收到第一个 token 之间的时间。它和"总生成时间"是两码事。总生成时间受模型输出长度影响，TTFT 只反映"链路 + 排队 + 首包"这一段，是纯粹的延迟指标。

为什么 TTFT 对 Claude Code 特别关键？因为 Claude Code 是交互式工具，不是跑批脚本。你一天要跟它对话几十上百次：

问一句"这个函数哪里有 bug"，你希望立刻看到它开始思考；
让它改个文件，你盯着终端等它动手；
多轮对话里每一轮都要吃一次 TTFT。

如果每次 TTFT 是 40 秒，一天交互 80 次，光是"等它开口"就浪费了将近一小时，而且这种碎片化等待最毁心流——你会忍不住切去刷手机，然后就再也回不来了。反过来，TTFT 压到 1-3 秒，Claude Code 用起来就跟本地 IDE 插件没区别，思路是连贯的。

结论先放这儿：决定 Claude Code 手感的不是模型，是 TTFT；决定 TTFT 的不是带宽，是节点离你有多近、链路有多干净。

二、三种节点位置的 TTFT 实测对比

我用同一份 Claude Code 配置、同一个 claude-sonnet-4-6 模型、同一段 prompt，只切换中转节点的物理位置，各测 20 次取中位数。结果非常直观：

节点位置	TTFT 中位数	长任务稳定性	是否需要本地代理	实际体感
美国 California（直连/回美节点）	40-50 秒	差，长连接易被掐	需要	每句话都在等，心流全断
日本 Tokyo（就近境外中转）	15-25 秒	中，偶发掉线	多数需要	能用，但明显"隔了一层"
国内节点（KingFlow）	1-3 秒	好，长任务不断连	不需要	跟本地工具一样跟手

差距为什么这么大？核心是物理距离 + 中间跳数 + 跨境链路质量三者叠加：

California：请求要横跨太平洋，光速就那么快，一来一回的 RTT 摆在那儿，再叠加国内出口的拥塞和丢包重传，40-50 秒的 TTFT 一点不夸张。长连接还容易在跨境链路上被中间设备重置。
Tokyo：离得近一些，物理 RTT 降下来了，所以能压到 15-25 秒。但你依然在"出境"，链路依然要过境外，抖动和偶发掉线躲不掉。
国内节点：请求在境内就近落地，由 KingFlow 在境内完成到 Anthropic 官方接口的转发，你的客户端到节点这一段是干净的国内链路，TTFT 自然进入 1-3 秒区间。

三、为什么自建代理 / 走境外中转，延迟高还爱掉线

很多人第一反应是"我自己搭个代理不就行了"。理论可以，实操是坑：

1. 延迟叠加，越搭越慢。 自建代理的典型路径是：本地 → 你的境外 VPS → Anthropic。你以为省了中转，其实多了一跳，而且这一跳还是你自己那台带宽有限、可能还超售的 VPS。TTFT 不降反升，很常见。

2. 长连接被掐，长任务前功尽弃。 Claude Code 跑大重构、跑长上下文任务时是长连接、持续流式输出。跨境链路上的中间设备对长连接不友好，高频长连接还会暴露你的代理出口 IP，触发 Anthropic 的风控——直接给你甩 403（拒绝）或 429（限流）。一个跑了几分钟的重构任务，眼看快出结果了，连接一断，全白干。

3. 缓存被破坏，成本翻倍。 更隐蔽的坑：很多自建网关或逆向接口（这里点名一下某些 Cursor/Kiro 式逆向方案，纯当反面教材，不引流）会对请求体做解析重组，把 system、messages、cache_control 拆开再拼回去。这会破坏 Prompt Cache 的哈希一致性，导致缓存永远命中不了，你以为省钱其实比别人贵 3-5 倍。

4. 号还容易废。 设备指纹 + 出口 IP 频繁切换，账号说冻就冻，前面所有投入归零。

一句话：自建代理是"用更高的延迟 + 更差的稳定性 + 更贵的成本，换一个'我自己搭的'心理安慰"。

四、KingFlow 国内节点怎么做到 1-3s、无需代理、长任务不断连

KingFlow 的做法很朴素，就是把复杂度扛在自己这边：

国内就近落地。 你的 Claude Code 直接连 https://www.kingflow.ai，请求在境内节点就近接入，跨境那一段由 KingFlow 用优化过的专线链路完成。你本地不用挂任何代理，TTFT 稳定进 1-3 秒。
官方 /v1/messages 透传，不逆向。 走的是 Anthropic 官方接口协议，原始 request body 透明转发，不解析不重组，所以 cache_control 原样带过去，Prompt Cache 完整生效，成本能砍 50%-90%。
长连接扛得住。 节点针对流式长连接做了保活，配合客户端把超时拉长，几分钟甚至更久的长任务也不会中途 403/429 掉线。

关键的客户端配置在 ~/.claude/settings.json，一份配置全搞定：

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://www.kingflow.ai",
    "ANTHROPIC_AUTH_TOKEN": "在 KingFlow 控制台领取的 API Key",
    "API_TIMEOUT_MS": "3000000",
    "CLAUDE_CODE_ATTRIBUTION_HEADER": "0"
  },
  "effortLevel": "medium"
}

几个参数解释一下，全是防延迟/防掉线/省钱的关键：

ANTHROPIC_BASE_URL 写根域，不要带 /v1，Claude Code 自己会拼 /v1/messages；
API_TIMEOUT_MS: 3000000（50 分钟）——长任务超时的救命参数，默认超时太短，大重构还没跑完就被客户端自己掐了，别怪节点；
CLAUDE_CODE_ATTRIBUTION_HEADER: "0" 关掉署名头，能提高 Prompt Cache 命中率，间接降延迟降成本；
effortLevel: "medium" 省 20-30% 推理 token，遇到硬题临时 /model 配合调 high 即可。

五、怎么自己测 TTFT（照抄就能跑）

别信任何人的截图，自己测最实在。下面这段用 curl 直接打 KingFlow 的官方接口路径，-w 把首字节时间打出来：

curl -s -o /dev/null \
  -w "DNS: %{time_namelookup}s | 连接: %{time_connect}s | 首字节(TTFT近似): %{time_starttransfer}s | 总计: %{time_total}s\n" \
  -X POST https://www.kingflow.ai/v1/messages \
  -H "x-api-key: 你的_KingFlow_API_Key" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-sonnet-4-6",
    "max_tokens": 16,
    "messages": [{"role": "user", "content": "只回复 ok"}]
  }'

time_starttransfer 就是从发起请求到收到第一个字节的时间，可以近似当作 TTFT。国内节点跑出来通常在 1-3 秒区间。想更严谨就跑个循环测中位数：

for i in $(seq 1 10); do
  curl -s -o /dev/null -w "%{time_starttransfer}\n" \
    -X POST https://www.kingflow.ai/v1/messages \
    -H "x-api-key: 你的_KingFlow_API_Key" \
    -H "anthropic-version: 2023-06-01" \
    -H "content-type: application/json" \
    -d '{"model":"claude-sonnet-4-6","max_tokens":16,"messages":[{"role":"user","content":"ok"}]}'
done | sort -n | awk '{a[NR]=$1} END{print "TTFT 中位数:", a[int(NR/2)+1]"s"}'

跑完你就有自己的数据了，不用听我吹。

六、FAQ

Q1：TTFT 1-3 秒是稳定值还是理想值？ 是国内节点的常态中位数。首次请求、冷缓存、网络抖动时可能偶尔冲高，但连续交互下大多落在这个区间。用上面的循环脚本测中位数最能反映真实体感。

Q2：我本地要不要挂代理 / 开梯子？ 不用。KingFlow 走国内节点直连 https://www.kingflow.ai，本地任何代理都不需要，反而挂了代理可能多一跳把延迟拉高。

Q3：长任务跑到一半断连是节点问题吗？ 先检查 API_TIMEOUT_MS 是不是设成了 3000000。默认超时偏短，大重构没跑完就被客户端自己掐断，这不是节点掉线。设好这个参数后长任务基本不断连。

Q4：这是逆向接口吗？会不会哪天挂掉？ 不是。走的是 Anthropic 官方 /v1/messages 协议，原始请求体透传，Prompt Cache 完整生效，不做任何逆向解析。

Q5：降低延迟会牺牲缓存或省钱效果吗？ 不会，反而互相成就。节点透传 cache_control，Prompt Cache 命中后不光省 50%-90% 成本，命中的请求响应更快，TTFT 也更低。具体价格以官网 www.kingflow.ai 为准。

官网：https://www.kingflow.ai ｜更多教程：https://yemaochuanmei.github.io/