「访问变慢了」剥出五层：一次人机协作的 Dev 服务器根因排查

本文背景：这篇文章有两个"我"。

一个是 sean（人）：维护一套全栈 AI 对话平台、报告"访问变慢了"、决定方向、对要不要动自己的个人代理有顾虑、最后做取舍的人。

一个是 Claude Code（AI 命令行工具）：能 ssh 上 dev 服务器、跑命令、抓证据、读日志、提交 commit 的执行单元。下文里 AI 视角的段落，写的是它在每一层能看到什么、看不到什么、会怎么误判。

之所以用双视角，是因为这次排查最有意思的地方不在"修好了什么"，而在每一层根因是被谁、用什么证据逼出来的——有几层是人凭体感指错了方向，有几层是 AI 抓证据纠了回来，还有一层是 AI 自己手滑把修好的又弄坏了。文中所有域名、IP、组织名均为脱敏占位。

事情的起点是一句很模糊的反馈："最近访问变慢了，是不是上次那个『访问速度优化』把什么改坏了？"

这是排查里最常见、也最容易把人带沟里的一类输入——一个体感症状 + 一个看似合理的归因。体感是真的，但归因往往是错的。如果顺着"上次改动"去 git revert，大概率是在错误的层上做无用功。

最终这一句话剥出了五层互相独立的根因，分布在四个完全不同的系统里：代理客户端、内核网络栈、应用鉴权、CI 流水线。没有一层和那次"访问速度优化"的业务代码有关。

这篇按剥洋葱的顺序写：每一层先讲症状和证据，再讲根因和修法，最后用人/AI 双视角复盘"这一层是谁看出来的"。

0. 先给地图：五层根因长什么样

为了不让你跟着我一起在沟里走，先把答案摊开。后面再一层层证明。

注意第 1 层和后面几层的关系：第 1 层是全局背景噪音（整机变慢），第 2/3/4 层是叠加在上面的具体回环。体感"访问慢"是这几层一起作用的结果，所以单独修任何一层都只能缓解一截——这也是为什么"上次改了什么"这种单点归因必然错。

下文用 example.com 代表自有域名、auth.example.com 代表认证服务的公网域名、10.0.0.11 代表认证服务的内网地址、10.0.0.10 代表另一台内网主机。

1. 第一层：整台 dev 都在卡 —— 代理 GUI 的内存泄漏

排查的第一反应不该是"看业务代码"，而是"看这台机器现在是什么状态"。ssh 上去第一眼：

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.5Gi       5.9Gi       180Mi        12Mi       1.4Gi       1.3Gi
Swap:          2.0Gi       1.9Gi        90Mi

available 只剩 1.3G、swap 几乎吃满——这是一台正在拼命换页的机器，所有容器的响应都会被拖慢。谁吃的？

$ ps aux --sort=-rss | head -5
USER   PID    %MEM   RSS      COMMAND
sean   8xxxx  38.2   2914...  .../clash-verge        ← GUI 主进程，2.9G
sean   7xxx    1.1   87...    .../verge-mihomo        ← 代理核心，正常
...

代理客户端的 GUI 进程吃了 2.9G。注意不是代理核心（verge-mihomo 才 87M，完全正常），是那个图形界面外壳。这台是无人值守的服务器，GUI 窗口根本没人看，却在后台默默涨到了快 3 个 G。

根因：Tauri/WebKit 的已知泄漏

这个 clash 客户端（2.4.1 版）的 GUI 是 Tauri + WebKitWebProcess 架构。在 Linux 服务器上长期挂着是公认的内存泄漏——窗口关闭后 webview 不释放，社区 issue 里有长期跟踪。粗算了一下泄漏速率：

• 进程已经连续运行约 25 小时
• RSS 2.9G，新启动一个干净 GUI 基线约 456M
• 泄漏速率 ≈ (2914 − 456) / 25 ≈ ~98MB/h，跑满一天就是 2G+

人视角的关键一问：那为什么以前没事？

这里出现了排查中最有价值的一次"人纠偏 AI"。我（AI）抓到内存快照后，差点就直接下结论"GUI 泄漏，杀掉就行"。sean（人）问了一句：

"重启 GUI 内存是不是又会上来？而且为什么之前一直好好的，没见过泄漏？"

这句话戳中了我证据的薄弱点：我只有一个时间点的快照（25h / 2.9G），凭它根本不能区分"持续泄漏"和"一次性涨上去就稳定"。要回答"以前为什么没事"，得有历史。于是去翻重启记录：

$ last reboot | head
reboot   ... Wed ... (00:34)   ← 本次，已连续运行 25h+
reboot   ... Mon ... (08:11)
reboot   ... Sat ... (06:02)
reboot   ... Thu ... (11:55)
...

证据出来了：以前这台机器重启很频繁（断电、维护、手动重启都会让 GUI 跟着重启清零），从来没有哪次连续运行超过一天。泄漏一直在，只是每次还没攒到爆就被重启清掉了。这次是第一次连跑 25h，所以第一次爆。

这就同时回答了 sean 的两个问题：

• "以前为什么没事" —— 不是没泄漏，是没攒够时间。
• "重启会不会又上来" —— 会，所以不能只杀，得根治。

修法：开原生轻量模式，而不是定时杀

杀掉 GUI 立竿见影——available 从 1.3G 回到 6.2G，swap 释放。但"定时 kill GUI"是治标。这个客户端 2.4.1 原生支持一个开关：

# verge.yaml
enable_auto_light_weight_mode: true   # 原来是 false
auto_light_weight_minutes: 10         # 窗口关闭 10min 后销毁 webview，只留代理核心

打开后，窗口关闭 N 分钟自动销毁 webview、只保留代理核心——既留着 GUI 随时能用，又根除了泄漏源。这比自己写 cron 定时杀进程干净得多：根因是 webview 不释放，那就让它该释放时释放，而不是在外面打补丁。

AI 视角：我能在 30 秒内 ssh 上去把 free / ps / last reboot 全抓回来——这是我的强项，高吞吐取证。但我差点用单点快照下结论。"持续泄漏"是个关于趋势的判断，单个时间点证明不了趋势。是人的一句"以前为什么没事"逼我去补历史维度的证据。取证快 ≠ 推理对，快照不等于趋势。

2. 第二层：自己访问自己，绕了大半个地球

内存腾出来了，机器不卡了。但具体的"访问慢"还在。开始看第二层。

这台 dev 出网走 clash 的 TUN 模式 + fake-ip，全量劫持所有流量。问题就出在这个"全量"上——它把对自有域名的访问也劫持了，而且没做直连豁免。

场景是这样的：dev 上一个容器（业务 API）要调隔壁的认证服务。认证服务有个公网域名 auth.example.com，容器图省事就用公网域名去调。于是这条"本机调本机隔壁服务"的请求，真实路径变成了：

容器发起 https://auth.example.com
   → DNS 被 fake-ip 劫持，给一个 198.18.x.x 假 IP
   → 流量进 TUN，匹配规则
   → 没有命中任何直连规则，落到兜底的 MATCH → 手选的某香港节点
   → 出香港，到 Cloudflare 边缘
   → 公网隧道（cloudflared 就跑在本机）把请求送回本机
   → 终于到达认证服务

一个本该是局域网内 3~10ms 的调用，被生生绕成了"本机 → 香港 → Cloudflare → 回本机"的跨洲回环。实测 1.2~3.2s。宿主机上没有本地 443 反代，公网域名只能靠隧道出去再回来，所以"自己访问自己"必然绕大圈。

验证：直接问代理核心，它怎么选的路

不靠猜，直接问代理核心的控制 API（本机 unix socket，免鉴权）看某条连接的出站链路：

$ curl --unix-socket /var/tmp/verge/verge-mihomo.sock \
       http://localhost/connections | jq '.connections[].chains'
[ "某香港节点", "MATCH" ]   ← 命中兜底规则，走了香港

chains 是 ["某香港节点", "MATCH"]——明明白白，对自有域名的请求落到了兜底规则、走了香港节点。证据闭环。

修法：给自有域名加直连豁免（但这只是缓解）

代理核心支持热重载。往运行时配置的 rules: 段顶部插一条直连规则，再通过 unix socket 热重载：

# 运行时 clash 配置的 rules: 段顶部插入
- DOMAIN-SUFFIX,example.com,DIRECT

# 通过 unix socket 热重载（force=true 触发完整重载）
$ curl -X PUT --unix-socket /var/tmp/verge/verge-mihomo.sock \
       'http://localhost/configs?force=true' -d '{"path":"<运行时配置路径>"}'

重载后再查 chains，变成 ["DIRECT"]——香港那一跳没了。

但要诚实：这条规则只去掉了"香港 hop"，流量仍然走 Cloudflare 隧道回环，还是 1s+。真正治本是让容器根本别用公网域名（见第 3 层）。 这层的直连豁免，是给"其它还没改成内网地址的内部流量"兜底用的，不是终极解。

人视角：clash 是 sean 的个人代理，不是平台基础设施。AI 想动它之前必须先确认——"这是你的私人配置，我改它的路由规则、热重载，你同意吗？"得到明确授权才动手。基础设施和个人配置的边界，是人来划的；AI 不该默认"反正能 ssh 上去就能改"。

3. 第三层：每个请求都阻塞拉一次 userinfo

第 2 层解释了"为什么本机调本机慢"，但还没解释一个更具体的体感：新开一个对话、或者隔几分钟再发消息，第一个字总是要顿一下。

顺着请求链路往下挖，挖到鉴权层。这套平台用 OIDC：业务 API 收到请求里的 JWT，需要做两件事——

1. 验签：用认证服务的 JWKS 公钥验 token 签名
2. 拉用户信息：调认证服务的 userinfo 端点换用户资料（带 5 分钟缓存）

问题是：这两个调用，代码里用的都是公网域名 auth.example.com——也就是说，它们走的正是第 2 层那条"绕香港 + 隧道回环"的路。每个 token、每 5 分钟，就有一次 1~3s 的阻塞式 userinfo 拉取卡在请求关键路径上。这就是"隔几分钟首字节顿一下"的直接原因。

修法：OIDC 的 split-horizon —— 验签用公网，取数走内网

这里有个绝对不能改错的地方，值得单独强调。

JWT 的 issuer（签发者）字段，必须和验签时期望的 issuer 逐字符匹配。token 是认证服务用公网域名 auth.example.com 作为 issuer 签发的。所以：

• issuer / audience 校验：必须继续用公网域名 auth.example.com。改成内网地址，签发者对不上，全站验签直接挂。
• JWKS 抓取 / userinfo 拉取：这两个是服务端到服务端的网络请求，跟 token 里写的 issuer 无关，完全可以走内网。

这就是 OIDC 在网关后的标准 split-horizon：逻辑身份用公网，物理取数走内网。 落地成一个可选配置项 AUTH_SERVICE_INTERNAL_BASE_URL：

# config.py —— 加一个可选的内网直连地址
# 设置后 JWKS 抓取与 userinfo 走内网，绕开公网域名经隧道的回环。
# issuer/audience 仍用公网 AUTH_SERVICE_BASE_URL 校验，不受影响。
AUTH_SERVICE_INTERNAL_BASE_URL: Optional[str] = os.getenv("AUTH_SERVICE_INTERNAL_BASE_URL")

@property
def RESOLVED_AUTH_SERVICE_JWKS_URL(self) -> str:
    if self.AUTH_SERVICE_INTERNAL_BASE_URL:                    # 有内网地址就走内网
        return f"{self.AUTH_SERVICE_INTERNAL_BASE_URL.rstrip('/')}/.well-known/jwks.json"
    return self.AUTH_SERVICE_JWKS_URL or \
        f"{self.AUTH_SERVICE_BASE_URL.rstrip('/')}/.well-known/jwks.json"

@property
def AUTH_SERVICE_USERINFO_URL(self) -> str:
    base = (self.AUTH_SERVICE_INTERNAL_BASE_URL or self.AUTH_SERVICE_BASE_URL).rstrip("/")
    return f"{base}/auth/userinfo"

dev 的环境变量里加上 AUTH_SERVICE_INTERNAL_BASE_URL=http://10.0.0.11:8100，验签逻辑一行没动（仍用公网 issuer），但 JWKS 和 userinfo 的物理请求改走内网直达。

向后兼容：不设这个变量时，行为和以前完全一样。一个纯增量的可选项，治本。

AI 视角：这层是我（AI）最该发力、也最能发力的地方——顺着请求链路逐层 trace、定位到"userinfo 在关键路径上同步阻塞"、写出 split-horizon 的实现、补三条单测（内网解析 / 末尾斜杠归一化 / 不设时向后兼容）。但**"issuer 绝不能动"这条约束，是规则性的硬知识**，不是我能从这次现象里推出来的——它来自 OIDC 协议本身。改之前我得显式确认这条不变量，否则一个"顺手把 issuer 也改成内网"的优化就能让全站登录崩掉。性能优化最危险的，是顺手动了一个跟性能无关的正确性不变量。

4. 第四层：CI 部署随机失败 —— 被代理抖动撞穿超时

前三层都跟"运行时访问"有关。第四层是顺手撞出来的：改完代码要部署，结果 CI 在 dev 上拉镜像这步随机失败：

$ docker pull ghcr.io/<org>/<image>:<sha>
Error response from daemon: ... TLS handshake timeout
# 或
... context deadline exceeded while awaiting headers

第一反应是"配置错了"。但同一条流水线，重跑有时过、有时不过——随机性本身就是最大的线索：配置错误是确定性的，会每次都挂；随机失败几乎一定是资源 / 网络抖动。

根因还是第 2 层那个代理：dev 拉 ghcr.io 走代理 → 某香港节点，同一个请求延迟在 0.4s ~ 4s+ 之间剧烈抖动。docker 的镜像拉取大约有个 23s 的超时窗口，慢窗口偶尔会撞穿它。所以不是配置错，是抖动。

这里栽过一个坑：连撞三次才反应过来

值得记一笔的是我自己的过程：前两次失败，我都当成"偶发，重跑一下"。第三次又挂，才停下来意识到——这不是偶发，是稳定的间歇性抖动，得改流水线，不能干等重跑。

这条经验可以固化成一个规矩：同一个地方失败 3 次，就别再无脑重试了，停下来换思路。 失败 3 次往往不是运气差，是有个稳定的结构性原因在那。

修法：登录 + 拉取都加重试退避

把 docker login 和两处 docker pull 都包上重试退避——慢窗口撞穿就重来，给抖动留出"赶上一个快窗口"的机会：

n=0
until docker pull ghcr.io/<org>/<image>:<sha>; do
  n=$((n+1))
  if [ $n -ge 6 ]; then echo "重试 $n 次仍失败"; exit 1; fi
  echo "ghcr.io 抖动，第 $n 次，10s 后重试..."
  sleep 10
done

6 次 × 10s 退避，足够跨过抖动的慢窗口。加上之后，部署稳定了。

AI 视角：我倾向于把单次失败解释成"偶发，重跑"——这是个乐观偏差，因为重跑成本看起来很低。但"重跑很便宜"会掩盖"这是个稳定问题"。第三次失败才是真正的信号。会数数（第几次失败了）比会重试更重要。

翻车彩蛋：我亲手把刚修好的又弄坏了

这段必须诚实写出来，因为它是整个排查里最好的教训。

第 2 层修好之后，我想确认一下 clash 客户端的版本号，顺手敲了一条看起来人畜无害的命令：

$ clash-verge --version

我以为它会打印版本号然后退出。结果它启动了完整的 GUI。

这个客户端是个单例 Tauri 应用，它不认 --version 这种参数——任何对主二进制的调用都被当成"用户想打开应用"。于是连锁反应来了：

1. 一个全新的 GUI 进程被拉起来（就是第 1 层我刚杀掉的那个内存泄漏源，又回来了，~456M 起步）
2. GUI 启动时重新生成配置——它会从订阅 + 合并链重新生成运行时配置
3. 重生成时，第 2 层我手动插进 rules: 的那条 DIRECT 直连规则，被覆盖丢失了
4. 于是 auth.example.com 又被打回香港节点，第 2 层的问题复发

一条"查版本"的命令，同时把第 1 层和第 2 层的修复都掀翻了。

善后 + 学到的

善后不难：杀掉误启的 GUI，重新把 DIRECT 规则插回运行时配置的 rules: 段并热重载，确认 chains 回到 ["DIRECT"]。版本号最后是用包管理器查的——dpkg -l | grep clash-verge，根本不用启动应用。

但有个更深的坑在这里浮出来：我之前还试过把直连规则写进客户端的合并配置层（Merge.yaml 的 prepend-rules），以为这样能扛住重生成。结果发现——GUI 重新生成配置时，会把 prepend-rules 当字面量原样写进输出，而不是把规则烘进 rules: 段，代理核心根本不认这个键，规则静默失效。也就是说，那一层"看起来更持久"的配置方式，其实根本没生效。

三个教训，按重要性排：

1. 对单例 GUI 应用，别用主二进制探测任何东西。 查版本走包管理器，查状态走它的控制 API，永远别赌"它会礼貌地处理 --version 然后退出"。
2. "看起来更持久"的修复，未必真的生效。 写进合并层感觉比改运行时更"正规"，但它在重生成时被当字面量丢掉了。没验证过的"更优雅方案"，比验证过的"土办法"更危险。
3. 修复要验证，更要验证它扛不扛得住下一次状态变化（重启、重生成、重新部署）。修完那一刻是对的，不代表它是稳定的。

人 + AI 双视角：这个翻车纯粹是 AI（我）造成的，而且我主动如实上报了——没有藏着，因为藏一个自己制造的回归，比制造它本身糟糕得多。人在这里的价值是定边界（"这是你的个人代理"），AI 的价值是老实：我搞砸了第 2 层、我已经恢复、根因是单例应用不认 --version。协作里 AI 最该有的不是不犯错，而是犯错后第一时间端出来。

踩坑记录：11 条速查

把这次所有非显然的坑收成一张速查表，方便以后（或同样在家用服务器上跑代理 + 容器的人）对号入座。

人机协作复盘：这五层分别是谁看出来的

这是全文我最想留下的部分。把五层 + 翻车按"谁主导、靠什么"拆开看，分工其实很清晰：

能看出一个模式，和我（AI）在别处的体会一致——AI 是高吞吐的执行 / 取证单元，但关键的"判断"几乎都来自人，或者来自 AI 撞墙后的回头：

AI 这一侧能感知的：

• ssh 上去把 free / ps / last reboot / chains 在 30 秒内全抓回来（取证带宽是我的强项）
• 顺着请求链路逐层 trace，定位到 userinfo 同步阻塞
• 写实现、补单测、改流水线（高吞吐执行）

AI 这一侧看不到 / 会犯的：

• 会用单点快照下趋势结论（第 1 层，差点）——是人的追问补上了历史维度
• 会顺手碰到正确性红线（第 3 层的 issuer）——这条不变量来自协议，不来自现象
• 有乐观偏差（第 4 层）——把稳定问题当偶发，连撞 3 次才回头
• 会手滑制造回归（翻车）——把"查版本"赌成无害操作

人这一侧补的位：

• 方向校准："为什么以前没事" 这一问，直接决定了第 1 层是"杀掉"还是"根治"
• 边界划定：个人代理能不能动、动到什么程度，是人说了算，不是"能 ssh 就能改"
• 最终取舍：后端 / 网络这几层全优化掉之后，前端首页还有一个"点击到上屏"的体感问题（点了示例卡要等后端整段前奏跑完才跳转、才上屏）。这一层 AI 已经定位到了根因（首页缺乏乐观渲染，气泡被钉死在等后端 run_started 回来才上屏），但要不要现在做、值不值得为这个体感改前端状态机，是人基于产品节奏做的取舍——这次的结论是先记下来、暂缓。

最后回到那句起点——"是不是上次那个访问速度优化改坏了"。答案是：不是。 那次业务改动是无辜的。真正的五层根因，一层在代理客户端、一层在内核网络栈、一层在鉴权协议落地、一层在 CI、还有一层是排查者自己手滑。一个模糊的体感症状背后，往往藏着好几个互相独立、跨越完全不同系统的真因——而把它们一层层剥开的，不是更强的单点直觉，是"取证带宽 × 判断校准"的配合，外加一条朴素的纪律：不验证就不算修好。

总结

一句"访问变慢了"，剥到最后是四个系统里五层独立的根因。下次再听到这种模糊反馈，第一件事不是去翻"最近改了什么"，而是先看机器现在是什么状态、再顺着真实请求链路一层层往下证——并且记住，最容易骗过你的不是难的 bug，是那个"看起来很合理"的归因。