梦行志折腾了三个小时，问题出在 Cloudflare WARP
OpenClaw + WSL2 + LM Studio 本地模型调用全程排查记录
同一台机器，WSL2 里怎么都连不上 Windows 上的 LM Studio / Cherry Studio，本以为是 OpenClaw 配置或 WSL 网络问题，最后发现只是 Cloudflare WARP 在背后“捣乱”。这篇就是那三个小时来回兜圈子的完整复盘。
背景：一台机子，三套主角
先简单交代一下登场角色和拓扑。
- 物理机：Windows
- 虚拟环境：WSL2 Ubuntu（后面都叫它 WSL）
- 本地大模型服务：
- LM Studio（跑本地模型）
- Cherry Studio（反向代理外部模型，顺便托管 DeepSeek / Qwen 等）
- 编排层：OpenClaw
- Windows 里有一个安装版本
- WSL 里又用官方脚本安装了一份
- 代理软件：
- Cloudflare WARP
- 一个走 10808 端口的传统 VPN 客户端
目标很简单：
- 在 WSL 里跑 OpenClaw；
- 让它去调用同一台机器上 Windows 里的 LM Studio / Cherry Studio；
- 最终形成一个「WSL 开发 + 本地大模型」的闭环。 听上去一点都不复杂，但实际排查过程非常「耗命」。
初始症状：服务明明在，调用就是不通
最开始遇到的现象是这样的：
- Windows 上的 LM Studio / Cherry Studio 打开后，在浏览器里用
http://127.0.0.1:xxx测试接口一切正常； - WSL 里 OpenClaw 的服务也跑起来了，日志看上去没有报什么明显错误；
- 但在 WSL 里，无论是 curl，还是 OpenClaw 里的模型调用配置，都连不上 Windows 那头的本地服务。 典型表现：
- 请求会卡住很久，然后超时；
- 或者直接报连接失败；
- 换端口、重启服务都没用。 直觉第一反应就是：
这肯定是 WSL2 的网络问题，或者是 OpenClaw 连接配置写错了。 于是开始了一次又一次的「理性排查」。
第一轮怀疑：是不是 OpenClaw 配错了？
直觉里，最容易背锅的当然是「新玩意」——OpenClaw。 我先排查了这些：
- 模型 provider 的 endpoint 是否写对（域名、端口、路径）；
- API key 有没有带上、是不是写错了；
- OpenClaw 的 UI 配置和命令行配置有没有冲突；
- Windows 那一份 OpenClaw 和 WSL 这一份有没有搞混。 在这过程中有两个发现：
- OpenClaw 的 UI 配置确实比较绕，很容易在不同 profile 或不同 section 里点来点去迷路；
- 用命令行
openclaw configure --section model反而更清晰，改一次就生效，不容易错。 于是我干脆把 UI 配置放一边，专心用命令行去写 provider 配置，结果——
- WSL 里依然连不上 Windows 的 LM Studio / Cherry Studio；
- 但 Windows 里本地测试（甚至用 Postman）都很正常。 这意味着：OpenClaw 只是「报信的人」，问题在网络路径上。
第二轮怀疑：WSL2 网络与 127.0.0.1 的迷思
排除掉 OpenClaw 配置问题之后，矛头自然指向 WSL2 本身。 几件事情需要厘清：
- WSL2 里的
127.0.0.1是指向虚拟机自己，不是宿主机的 Windows； - Windows 和 WSL2 之间通过虚拟网卡互通，一般会有一个
172.x.x.x或类似段的 IP； - 有些时候重启 Windows / WSL 会让这个网段 / IP 变化。 于是我做了几件事：
- 在 Windows 里查 WSL 的虚拟网卡 IP；
- 在 WSL 里用
curl http://<windows-ip>:<lm-studio-port>测试； - 尝试把 endpoint 从
127.0.0.1换成 Windows IP； - 重启了几次 WSL 服务、甚至干脆重启了整台机器。 神奇的是：
- 有一次重启之后，连接突然就通了；
- 但这看起来更像是「把所有网络状态重置了一遍」，而不是找到了真正的根因。 当时我心里是这么想的：
也许是 Windows 网络适配器重置后，某些奇怪的路由问题被洗掉了？ 这个想法不算完全错，但只是一层表象。真正的问题还在后面。
第三轮怀疑：Cloudflare WARP 到底动了什么？
真正的突破发生在我注意到一个细节：
不能连接的时候，Cloudflare WARP 是开着的；
刚才重启后一切正常，是因为我退出了 WARP，换成了一个 10808 端口的 VPN 代理。 简单复盘一下当时的步骤：
- 开着 Cloudflare WARP 的时候：
- WSL 里访问 Windows 上的 LM Studio / Cherry Studio 一直失败；
- 不只是 OpenClaw，连 curl、浏览器也有问题。
- 把 WARP 退出，换成一个走本地 10808 端口的代理软件：
- WSL 里立刻就能连上 Windows 的本地服务；
- Cherry Studio 的 API 反代端点也恢复正常。 这说明最关键的一点：
Cloudflare WARP 不只是给你「上外网」这么简单，它会劫持或改写本机的网络路径，包括你原本以为安全的 127.0.0.1 / 局域网流量。 而 10808 端口的传统代理则相对「老实」：
- 它主要通过本地监听端口，把出站流量转出去；
- 对于本机的回环地址（127.0.0.1）和局域网访问不会做太多手脚；
- 所以在它开启时，WSL ↔ Windows 的本地互联依然是通的。 用一句更直白的话说：
- 开着 WARP：本地 AI 服务全都「出国留学」，回不来。
- 换成普通 10808 代理：本地 AI 服务乖乖待在家里，谁都能访问。
现象对比：谁让本地服务「消失」了？
可以用一个小表格总结一下当时的现象对比：
- 场景 1：开启 Cloudflare WARP
- Windows 自己访问本地 LM Studio / Cherry Studio：正常
- WSL 访问 Windows 本地服务：经常连不上，要么超时要么直接失败
- 场景 2：退出 Cloudflare WARP，改用 10808 端口代理
- Windows 自己访问本地服务：正常
- WSL 访问 Windows 本地服务：正常
这给了一个很直接的结论：
- 问题不在 OpenClaw，不在 WSL 配置，也不在 LM Studio / Cherry Studio 本身；
- 是 WARP 改写了本机的网络路由，导致 WSL ↔ Windows 的「本地」路径被拐到了奇怪的地方。
如果把网络链路打个比方：
- 原本你期望的是：WSL → Windows 内网 IP → LM Studio
- 开了 WARP 之后，链路变成了某种「WSL → WARP 虚拟网卡 → 某个出口」之类的；
- 本以为是走房间内的短路，结果被送进「机场」，绕了一大圈。
经验教训 1：本地大模型优先排查“代理”和“加速器”
这次踩坑给我的一个直接经验是：
只要你涉及「本地大模型 + WSL + 各种代理 / 加速器」，排查顺序里应该把代理软件提前很多。
具体建议：
- 任何时候本地服务「突然连不上」或「在某个环境里连不上」，先看：
- 你有没有开 WARP、Tailscale、某些「一键加速」之类的工具；
- 系统托盘里有没有新出现的网络图标。
- 尝试快速验证：
- 暂时退出这些代理；
- 或者切换成一个更传统、只暴露本地端口的代理（如 10808 那种）。
- 如果退出代理后，WSL ↔ Windows 或本机不同进程之间的访问恢复正常，那十有八九就是代理在干预。
很多时候，我们会习惯性地怀疑：
- 是不是防火墙挡了；
- 是不是 Docker / WSL 网段冲突了；
- 是不是服务没起来。
但这次之后，我会把「你是不是开了某个全局代理 / VPN / 加速器」排到前面，很可能它才是那个最隐蔽的凶手。
经验教训 2：OpenClaw 配置要“先简后繁”
在这次折腾里，还有一个顺带的收获是在 OpenClaw 的配置方式上。
刚开始我在 UI 里来回点：
- 不同模型 provider；
- 不同 profile；
- 试图找到是哪一个选项写错了。
后来换成命令行：
openclaw configure --section model收获是：
配置更可控：
每次只改一个 provider；
出问题时可以轻松回滚；
更容易做版本管理：
可以把当前的配置导出成文件；
日后迁移 / 备份会方便很多。
所以，即便这次问题最终跟 OpenClaw 无关，这个习惯也值得保留：
复杂的模型编排系统，UI 适合「观察」，具体配置还是用命令行更靠谱。
经验教训 3：重启不是玄学，而是“网络状态重置”
在问题还没明确指向 WARP 之前，有一段时间是这样的：
我重启了整台电脑之后，WSL ↔ Windows 的连接突然恢复正常；
当时并没有意识到是因为我顺手关掉了 WARP；
于是潜意识里把这个现象归结为「WSL 网络玄学」。
现在回过头来看，这其实是「重启顺带关闭了某些网络组件」，比如：
WARP 自己，或者它注入的某个驱动；
某些虚拟网卡状态被清空；
路由表被重新生成。
这类现象会带来一个误导：
你会以为是「重启电脑」这个行为本身解决了问题；
但实际上，它只是顺便把罪魁祸首带走了，而你没有把问题定位清楚。
所以以后再遇到类似情况，我会刻意做两件事：
记录重启前后的所有「状态变化」：哪些软件自动启动了，哪些没启动。
重启后，如果问题消失了，优先怀疑：
- 它是不是和某个常驻后台的软件有关，而不是操作系统本身。
如何让 WARP 和本地 AI 服务和平共处？
如果你确实需要同时用 Cloudflare WARP 和本地 AI 服务（LM Studio / Cherry Studio / OpenClaw），有两个方向可以尝试：
在 WARP 里配置「分流 / 分离隧道」（Split Tunnel）：
把下面几类地址加入「不走 WARP」的名单：
127.0.0.1WSL 虚拟网段（比如
172.16.0.0/12或具体的 IP 段）Windows 与 WSL 之间通信用到的那几个本地网卡 IP
这样做的效果是：
出国流量仍然走 WARP；
本地服务调用保持在机器内部，不被 WARP 改写。
如果懒得折腾分流规则：
在调试和使用本地大模型的时候，暂时退出 WARP；
改用一个传统的本地代理（例如监听
127.0.0.1:10808的那种）；用完再开回 WARP。
两者的本质区别是：
WARP 更倾向于接管整个网络栈；
传统代理更多只是「在本地开一个端口，把出站流量拦一下」。
在涉及 WSL + 本地服务这种「半虚拟化」场景时，前者的干预力度往往会过大。
这次排查过程的 TL;DR
如果只用几句话复盘这三个小时的折腾，它大概是这样一条时间线：
发现 WSL 里的 OpenClaw 无法调用 Windows 上的 LM Studio / Cherry Studio。
先怀疑 OpenClaw 配错，反复修改 endpoint / API key、改 UI / CLI 配置，效果不佳。
再怀疑 WSL2 网络，研究 127.0.0.1 与宿主机 IP、重启 WSL / Windows，偶尔会短暂恢复，但原因不明。
最终注意到一个关键事实：连不上的时候开着 Cloudflare WARP，换成 10808 端口代理之后一切正常。
确认根因：Cloudflare WARP 改写了本机网络路由，影响了 WSL ↔ Windows 的本地服务访问。
最后经验：
有任何「本地服务连不上」的情况，先检查各种代理 / 加速器；
复杂模型编排系统优先用命令行配置；
重启电脑能解决的问题，背后往往是某个常驻网络组件在作妖。
写在最后：给未来的自己看
这篇文章更多是写给未来的自己看的。
当你某一天再次遇到：
同一台机器上，本地服务怎么都连不上；
明明端口没占用，防火墙也放行；
重启之后不知为何又好了；
记得先问自己三个问题：
你有没有开 Cloudflare WARP、某种「加速器」或奇怪的 VPN 客户端？
你是不是在 WSL / Docker / 虚拟机里访问宿主机的本地服务？
你最近有没有改过网络设置、装过什么「一键网络优化」工具？
如果答案有一个是「是」，那就先把这些东西关掉试试看。
很多时候，真正的问题其实没那么复杂，只是被我们绕了好几圈而已。
“同频之人，终会相遇；同行之路，终有光亮。”
若你有故事想讲、有困惑想聊、或是想找个人说说心里话，甚至只是吐槽发泄一下情绪，都欢迎来找我聊聊：
“同频之人，终会相遇；同行之路，终有光亮。”
“技术终归是工具，而我们一次次认真把问题理顺，守住的其实不只是页面样式和代码输出，还有那一点不愿被混乱打败的心气，是每一个深夜仍愿点灯前行的人。”
「码艺轩・以技立身，实干谋生」系列 · 持续更新
本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明来自：https://oklife.me。