夜雨聆风在 macOS 上折腾 OpenClaw，最容易让人误判的一件事，不是模型配置，不是权限弹窗，而是代理。
很多人的第一反应都一样：我代理软件明明开着，浏览器也能访问外网，为什么 OpenClaw 还是会出各种怪问题？比如 WhatsApp 连不上，Codex 认证失败，或者某些接口能通、某些接口死活不通。
问题往往不在“你有没有开代理”，而在“你只开了一层代理，但 OpenClaw 实际上跑在四层网络路径里”。这四层只要有一层没接上，表现出来就是一种很拧巴的状态：表面像通了，实际没全通。
我的判断是，macOS 下 OpenClaw 的代理问题，本质上是一个“网络分层失配”问题。
第一层：代理软件开着，不等于所有进程都在走代理
大部分人说“我已经开代理了”，通常指的是网络代理软件已经在本机运行。
但代理软件运行，只说明你的机器上有一个代理入口，比如本地的 HTTP 或 SOCKS 端口。它不等于所有程序都会自动走这个入口。
浏览器能访问外网，只能说明浏览器那条链路通了。OpenClaw 能不能通，要看 OpenClaw 自己那个进程到底有没有被正确导向代理。
这是很多人踩坑的第一步：你看到的是“系统里有代理”，但程序实际面对的是“我根本没被告知要走代理”。
第二层：命令行里的代理配置，只对那个 shell 生效
第二层是命令行环境变量，比如：
• HTTP_PROXY• HTTPS_PROXY• ALL_PROXY• NO_PROXY
如果你在终端里导出了这些变量，那么当前 shell 以及从这个 shell 启动的子进程，通常会继承这些代理设置。
这就会制造出一个非常迷惑的现象：
你在 Terminal 里运行测试命令，一切正常；但 OpenClaw 从桌面 App、菜单栏或后台服务启动之后，网络又不正常了。
原因很简单。命令行环境变量不是“系统全局真理”，它只是“这个 shell 会话里的局部现实”。
也就是说，你在 iTerm 里配好的代理，不代表 launchd 启动的 OpenClaw 也知道；你在 .zshrc 里写的东西，也不代表 LaunchAgent 会自动继承。
这也是为什么很多人会说：“我命令行里 curl 没问题，OpenClaw 却不行。”这不是玄学，这是进程继承链不同。
第三层：LaunchAgent 是另一套世界，plist 不认你的 shell 情绪
OpenClaw 在 macOS 上，本地模式并不是随手起一个子进程就结束。官方文档提到，macOS App 现在依赖外部 openclaw CLI，并通过每用户的 launchd 服务来保持 Gateway 运行。对应的 LaunchAgent plist 一般在：
• ~/Library/LaunchAgents/ai.openclaw.gateway.plist
某些文档或旧版本中，也能看到类似的路径命名。
重点不是文件名，而是它代表了一件事：OpenClaw 的网关进程，常常是被 launchd 拉起来的，而不是被你的 shell 拉起来的。
这意味着你在终端里配置的代理变量，默认并不会自动进入这个 LaunchAgent 进程环境。如果 plist 里没有显式写入环境变量，或者没有通过 launchctl 注入环境，那么这个进程看到的世界，和你在 Terminal 里看到的世界，可能根本不是一个世界。
这时候就会出现一种很典型的故障：
• 浏览器正常 • 终端正常 • Dashboard 看起来正常 • 真正跑到 Gateway 里的请求不正常
很多人会把这个问题归因于“OpenClaw 不稳定”，其实更准确的说法是：启动路径不同，导致代理上下文不同。
第四层：代码里的 fetch、Node 组件、浏览器组件，未必自动吃到同一套代理
再往下一层，才是最容易被忽略的：就算 OpenClaw 这个进程本身启动了，不同代码路径也不一定共享同一套代理策略。
比如一个请求可能来自：
• Node 里的 fetch• 某个 HTTP 客户端库 • WebSocket 连接 • 浏览器自动化组件 • 外部服务回调 • 第三方 channel 集成，比如 WhatsApp、Telegram
这些东西听起来都叫“联网”，但它们不一定用的是同一种网络实现。
这里最容易出现一个误区：很多人以为“只要 Node 进程设置了代理，里面所有请求就都会自动走代理”。现实通常没这么整齐。具体是否生效，要看运行时、库、代理 agent、环境变量继承方式，甚至要看某个模块是不是自己单独建了连接。
从我能查到的 OpenClaw 文档来看，官方对 macOS 的说明重点在于：
• macOS App 不再内置 Gateway 运行时 • 本地模式依赖外部 CLI • Gateway 常驻方式是 LaunchAgent • Node host 会自动暴露 browser proxy，但这里说的是浏览器工具路由，不是“所有 HTTP 请求自动遵循系统代理”
换句话说，我没有看到一条可以简单概括成“OpenClaw 所有 fetch 请求都会自动跟随 macOS 代理”的官方表述。更稳妥的理解应该是：代码层是否走代理，仍然取决于具体组件和进程环境，而不是你在系统设置里点了一个代理开关就万事大吉。
为什么最先出问题的，往往是 WhatsApp 和 Codex 认证
理解了上面四层，再看一些常见故障，就没那么神秘了。
1. WhatsApp 无法连接，不一定是 WhatsApp 本身有问题
OpenClaw 官方平台文档明确提醒过，Gateway 推荐 Node 运行时，不推荐 Bun，因为 Bun 在 WhatsApp 和 Telegram 上有 bug。
这至少说明一点：这些 channel 连接本来就比普通 HTTP 请求更敏感。它们可能涉及长连接、WebSocket、登录态、扫码状态同步，甚至更依赖稳定的网络路径。
于是代理问题一旦出现，WhatsApp 往往是最早暴露异常的那一个。
最常见的几种情况是：
• 代理软件开了，但 LaunchAgent 没吃到代理变量 • HTTP 请求能走，WebSocket 不稳定 • 某些域名被 NO_PROXY误排除了• 浏览器能打开页面，但网关里的 channel 连接并没走同一条路径
所以“WhatsApp 连不上”很多时候不是单点故障，而是在提醒你：你的代理配置只在某一层生效了。
2. Codex 认证失败，往往是“认证流程走了多条链路”
Codex 这类认证失败，看起来像账号问题，实际上经常是网络链路不一致。
因为认证不是一个单一请求，它通常会经过：
• 浏览器打开登录页 • 跳转到认证服务 • 回调到本地或指定地址 • 后续 API 验证 • 可能还有 WebSocket 或 token 刷新过程
只要这里面有一段没走代理，或者走的是另一套代理，就会出现非常诡异的表现：
• 登录页能打开，但回调失败 • 浏览器看起来授权成功，但 CLI 仍然未登录 • 有时成功，有时失败 • 同一台机器上，手动登录可以，程序化认证不行
说白了，认证失败未必是“账号不对”，而是“认证涉及的多条网络路径没有对齐”。
真正该怎么理解 OpenClaw 的代理问题
如果只用一句话总结，我会这么说：
OpenClaw 的代理问题，核心不是有没有代理，而是代理有没有贯通到“代理软件、命令行环境、LaunchAgent、代码组件”这四层。
你只打通一层，系统就会表现出一种半通不通的状态。你打通两层，可能浏览器正常、CLI 正常，但 Gateway 异常。你打通三层，可能 API 正常，但 channel 异常。只有当这些层级尽量对齐，OpenClaw 的联网体验才会稳定。
这也是为什么很多人排查了半天，越查越烦。因为你以为在排一个配置，实际上是在排四套配置之间的错位。
一个更实用的排查顺序
如果你正在排这类问题，我建议不要一上来就怀疑 OpenClaw 本身，先按层看：
先看代理软件本身是否正常工作。
再看命令行环境变量是不是只存在于 shell。
再看 LaunchAgent 的 plist 和启动环境里有没有代理配置。
最后再看具体出问题的是哪一类组件：普通 HTTP、WebSocket、浏览器自动化，还是 channel 集成。
这个顺序的价值在于，它能把“感觉哪都不对”拆成“到底是哪一层没接上”。
结尾
很多 macOS 用户第一次遇到 OpenClaw 网络问题时，都会本能地去问一句：到底是谁没走代理？
但更准确的问题其实应该是：
到底是哪一层，以为别的层已经替它处理好了代理。
这才是 OpenClaw 代理问题最烦人的地方。它不是彻底断，而是分层断；不是完全不通，而是每一层通一点，最后组合成一个非常难排查的“不稳定”。
所以别再把“浏览器能开网页”当成 OpenClaw 网络正常的证据了。对 OpenClaw 来说，真正重要的不是你有没有代理，而是代理有没有穿透整条链路。
参考资料
• OpenClaw macOS Gateway / LaunchAgent 文档：https://docs.openclaw.ai/zh-CN/platforms/mac/bundled-gateway • OpenClaw macOS App 文档：https://docs.openclaw.ai/macos • OpenClaw Platforms 文档：https://docs.openclaw.ai/platforms • OpenClaw Node 文档：https://docs.openclaw.ai/cli/node • OpenClaw Browser 文档：https://docs.openclaw.ai/zh-CN/tools/browser