最近，我在 Mac 环境下尝试使用 OpenClaw 运行 Discord 相关功能时，遇到了一系列网络连接与配置问题。起初，当我在终端中启动 OpenClaw 并尝试连接到 Discord 时，程序一直卡在连接阶段，随后在日志中输出了类似 “Gateway Timeout” 的连接超时错误。

经过初步检查，我意识到由于国内的网络环境限制，OpenClaw 在尝试与 Discord Gateway（WebSocket）建立连接时，可能遇到了直接的连通性障碍。在此记录一下我逐步排查并解决这些问题的过程。

排查与学习：网络代理机制

为了弄清楚问题的根本原因，我查阅了一些资料并进行了测试。

我的理解是：虽然我的 macOS 上已经运行了代理软件（例如 ClashX 或 Surge），但在终端中直接设置全局环境变量（如 HTTP_PROXY 和 HTTPS_PROXY）有时对某些特定的命令行工具或基于 WebSocket 的长连接并不完全生效。

这给了我一个重新学习类 Unix 系统网络代理机制的机会。在查阅资料的过程中，proxychains 工具吸引了我的注意。它的原理是通过动态链接库注入（macOS 上的 DYLD_INSERT_LIBRARIES 机制）来 hook 程序的网络请求，从而强制指定的命令或进程走代理通道。在 macOS 上，虽然系统完整性保护（SIP）会限制其对系统自带程序的生效，但对于像 OpenClaw 这样由用户自行安装的第三方程序，它依然是有效的。

尝试与方案

基于上述理解，我尝试通过配置 Proxychains 来解决基础的网络连通性问题，并随后解决了一系列附带的配置问题。以下是我执行的具体操作：

1. 配置 Proxychains 代理

首先，我通过 Homebrew 安装了适用于 macOS 的 proxychains-ng：

1
brew install proxychains-ng

接着，我修改了 Proxychains 的配置文件。在 Apple Silicon 的 Mac 上，这个文件通常位于 /opt/homebrew/etc/proxychains.conf。

如果不确定路径，可以通过 find / -name proxychains.conf 2>/dev/null 来查找。

在配置文件的最末尾 [ProxyList] 部分，我将默认的 Tor 代理替换为了本地代理软件的地址和端口。这里我使用的是本地的 7897 端口（推荐使用 SOCKS5）：

1
2
3
[ProxyList]
# socks4  127.0.0.1 9050  <-- 注释掉或删掉这行默认的
socks5  127.0.0.1  7897   <-- 加上这行

2. 使用 Proxychains 启动并处理后台守护进程

配置完成后，运行以下命令

1
proxychains4 openclaw gateway start

如果 OpenClaw 是作为后台守护进程运行的（例如通过 launchd），还可以修改对应的 plist 文件 ~/Library/LaunchAgents/ai.openclaw.gateway.plist。

在 <key>ProgramArguments</key> 下的 <array> 中，我将 proxychains4 的执行路径加在了原启动命令的最前面：

1
2
3
4
5
6
7
8
9
<key>ProgramArguments</key>
<array>
    <string>/opt/homebrew/bin/proxychains4</string>
    <string>/opt/homebrew/Cellar/node/25.6.1_1/bin/node</string>
    <string>/opt/homebrew/lib/node_modules/openclaw/dist/index.js</string>
    <string>gateway</string>
    <string>--port</string>
    <string>18789</string>
</array>

(注意：通过 where proxychains4 确认了电脑上 proxychains4 的真实绝对路径，通常 Homebrew 安装的是在 /opt/homebrew/bin/ 或 /usr/local/bin/ 下。)

配置完成后，运行以下命令

1
openclaw gateway start

运行之后，控制台正确输出了代理链的连接日志，OpenClaw 成功连上了 Discord 的 Gateway。

3. 解决 Discord 报错 4014

网络通了之后，终端里突然抛出了 4014 错误 (missing privileged gateway intents)。

通过查阅文档，我了解到这是因为机器人在试图读取消息时，没有获得 Discord 官方的“特权意图”许可。
解决办法是前往 Discord Developer Portal，选中对应的 Bot，在左侧菜单点击 Bot，向下滚动找到 Privileged Gateway Intents，并将 Presence, Server Members, Message Content 这三个开关全部打开并保存。

4. 解决 OpenClaw 提示 “access not configured”

随后，当我尝试给机器人发消息时，终端提示：Ask the bot owner to approve with: openclaw pairing approve discord xxx。

这是 OpenClaw 的白名单保护机制。只需在另一个新的终端窗口里，复制它提示的命令执行一下，将自己的 Discord ID 加入白名单即可：

1
openclaw pairing approve discord 你的Pairing_code

OpenClaw Pairing Approve

(顺便提一句 OpenClaw 的本地配置文件其实藏在隐藏目录 ~/.openclaw/openclaw.json 里，这在后续排查中也提供了一些线索。)

5. 解决第三方 AI API 无法调用的问题

解决了 Discord 的连通性后，我发现虽然 Discord 功能正常，但第三方 AI 的 API 却无法调用成功。

API Call Failed

经过排查，在 ~/Library/LaunchAgents/ai.openclaw.gateway.plist 中存在多余的环境变量配置，这些环境变量可能干扰了 Node.js 进程对第三方 API 的直连请求：

1
2
3
4
5
6
<key>http_proxy</key>
<string>http://127.0.0.1:7897</string>
<key>https_proxy</key>
<string>http://127.0.0.1:7897</string>
<key>all_proxy</key>
<string>socks5://127.0.0.1:7897</string>

我将这些环境变量配置删除后，第三方 API 的调用恢复了正常。

Remove Proxy Env from Plist

修改完成后，我执行了 openclaw gateway restart 来重启网关服务，确保所有配置生效。

总结与反思

这次排查帮助我更好地理解了 macOS 下网络交互的差异以及守护进程（launchd）的配置细节。以前的我会经常依赖于设置全局的环境变量来解决代理问题，但这次经历让我认识到，对于复杂的网络协议，结合 Proxychains 进行进程级别的强制代理，同时清理可能引起冲突的全局环境变量，是一个更加精细且可靠的排障方向。

这也提醒了我，在处理涉及多个网络链路（如同时连接 Discord WebSocket 和第三方 REST API）的复杂应用时，需要更仔细地梳理每一层网络请求的走向，避免产生意料之外的代理拦截。