前言：先分清模型连接与代理连接
OpenClaw 连接模型失败，并不一定是 Clash 节点不可用。一次模型调用通常经过多个环节：OpenClaw 读取模型服务商和 API 凭据，向对应的 API 地址发起请求，再等待服务端返回结果。配置错误、密钥无效、账户额度不足、域名解析异常、代理没有接管 OpenClaw 的流量，任何一项都可能表现为“初始化超时”或“模型不可用”。
本文以 Clash Verge 为例说明排查方法，其他使用 Mihomo 内核的客户端也可以参考。OpenClaw 的版本、安装方式和模型服务商不同，配置文件的位置、字段名称及代理支持方式可能不一样；请以你所用版本的文档为准，不要把示例中的占位地址或配置字段直接当成通用答案。Clash 负责转发网络流量，并不会提供模型、API 额度或访问权限；使用模型服务时还应遵守服务商的地区限制、账户条款和当地适用规定。
排查目标
先确认 OpenClaw 能连上 Clash，再验证模型 API 地址、凭据和模型名称，最后按需添加精确分流规则，避免不必要地让所有应用走代理。
1配置前：确认客户端、服务商与运行环境
开始修改配置前，先记下 OpenClaw 的运行方式：它是在当前电脑直接运行，还是在 Docker、虚拟机、远程服务器或 WSL 等环境中运行？Clash Verge 的系统代理通常主要影响遵循系统代理设置的应用，并不能保证所有命令行程序、容器或后台服务都会自动使用代理。如果 OpenClaw 运行在另一台设备或独立网络环境中，本机开启 Clash 也不会自动代理那台设备的流量。
- 确认模型服务商：查阅服务商提供的 API 地址、认证方式、模型 ID 和使用限制。不要仅凭模型名称猜测 API 域名；同一模型可能由不同平台托管，接口格式也可能不同。
- 检查账户状态：确认 API 密钥仍有效、账户具备调用权限且额度充足。网页端可以使用，不代表对应 API 已开通或与 OpenClaw 所需的接口兼容。
- 确认 OpenClaw 的网络设置：查看当前版本是否支持为模型请求指定代理、是否读取系统代理或标准代理环境变量。不同版本的实现可能不同，优先采用项目文档明确支持的方式。
- 准备可用的 Clash 策略组：在 Clash Verge 的「代理」页面确认订阅已更新、节点可用，并记下承载模型流量的策略组名称。配置中引用的组名必须与现有配置完全一致。
先做最小化测试
先在 Clash Verge 中选择一个稳定节点，并用浏览器访问服务商的官方 API 文档或状态页面。页面能打开只说明浏览器路径可用，仍需进一步验证 OpenClaw 进程是否走了同一条代理线路。
还要区分“模型 API 主机”和“模型网页”。例如，浏览器可以打开某个产品网站，并不能证明 OpenClaw 正在请求的 API 域名也已被正确分流。反过来，网页打不开也不一定代表 API 不可达。排查时以 OpenClaw 日志中实际请求的主机名为准；如果日志没有显示完整地址，可在服务商控制台或应用调试信息中核对。
2动手配置：让 OpenClaw 模型请求经过 Clash
建议按“先验证节点，再接入应用，最后做精细分流”的顺序操作。这样每次只改变一个因素，出现问题时更容易判断是客户端、配置还是模型服务导致的。
- 打开 Clash Verge，确认配置文件已载入，代理内核正在运行，且已选中可用节点。
- 先使用「规则」模式测试。若你的配置采用规则分流，确认目标模型服务的域名不会被错误地命中为
DIRECT。 - 打开连接记录或日志，准备在稍后观察 OpenClaw 发出的请求是否出现，以及它最终使用的策略组和节点。
不建议长期全局代理
全局模式可以用作短暂对照测试，但会改变其他应用的出站路径，也可能带来额外延迟。测试后应恢复规则模式或直连模式，并按需设置明确规则。
如果 OpenClaw 的文档说明支持标准代理环境变量，可在启动 OpenClaw 的同一终端会话中设置代理。以下地址仅为常见本机 HTTP 代理端口示例，请在 Clash Verge 的设置中确认实际端口；端口不一致时，照抄不会生效。
HTTP_PROXY、HTTPS_PROXY 和 ALL_PROXY 是否被识别，取决于 OpenClaw 使用的网络库及其配置。部分程序只接受其中一类变量，部分程序要求在自身设置中填写代理地址，也有程序完全不读取环境变量。请以官方文档为准；不要为了测试而把代理变量写入不必要的全局系统设置。
设置后，从同一个终端启动 OpenClaw，并观察 Clash 连接记录。如果 OpenClaw 运行在 Docker 或 WSL 中，容器内的 127.0.0.1 通常指向容器自身，而不是宿主机；此时需要按照对应环境的网络方式配置可访问的宿主机地址和端口，同时确认 Clash 允许来自该网络的连接。不要在不了解防火墙和监听范围的情况下将代理端口暴露到公网。
如果日志显示 OpenClaw 的请求已经到达 Clash，但规则将它送往错误策略组，可以在 Clash 配置的 rules 中增加服务商官方文档确认过的域名规则。以下仅展示规则格式：api.example.com 是占位域名，AI-Proxy 也必须替换成你配置中真实存在的策略组。
规则通常按从上到下的顺序匹配，因此新增项应放在会覆盖它的宽泛规则之前，同时保留原有规则和最后的兜底规则。不要直接覆盖订阅配置中的整段 rules，否则可能造成国内网站、其他应用或默认流量的分流行为改变。若使用 Clash Verge 的合并或脚本功能，应确认该功能和语法适用于当前内核版本；修改后先检查配置校验结果，再重新载入配置。
接下来回到 OpenClaw，按照项目文档填写模型提供商、API 地址、模型 ID 和密钥。密钥应使用受支持的密钥管理方式或本地环境变量，不要写入公开仓库、截图、日志或可分享的配置文件。发送一次最简单的测试请求，同时查看 OpenClaw 错误信息和 Clash 连接记录：请求命中预期域名、使用预期策略组，且服务商返回正常响应，才算完成端到端验证。
3连接失败时：按现象定位问题
不要一出现超时就连续更换节点、DNS、TUN 和模型配置。先保留错误原文和发生时间，再根据连接记录逐层排查。下面的判断可以帮助区分网络路径问题与账户、接口问题。
| 现象 | 优先检查 | 建议处理 |
|---|---|---|
| Clash 连接记录中没有 OpenClaw 请求 | OpenClaw 是否读取系统代理或环境变量；程序是否在容器、WSL 或远程环境运行 | 按应用文档设置代理；核对运行环境中的代理地址、端口和宿主机可达性 |
| 请求出现，但命中 DIRECT 或错误策略组 | 域名规则顺序、策略组名称、规则模式和配置是否重新载入 | 按日志中的实际主机添加精确规则，并确认其位于冲突规则之前 |
| 代理已命中，仍出现连接超时 | 节点状态、出口网络、DNS 解析、服务商 API 可用状态及目标域名 | 更换一个稳定节点做对照；检查 Clash 日志与服务商状态页，不要先扩大规则范围 |
| 快速返回认证或权限错误 | API 密钥、模型 ID、账户额度、项目权限和接口格式 | 在服务商控制台核对凭据及模型权限；网络代理通常不能修复无效凭据或账户限制 |
如果怀疑 DNS 问题，先查看 Clash 是否记录了目标域名解析失败，并检查客户端 DNS 设置与系统 DNS 是否互相冲突。启用 TUN 模式可能帮助接管不遵循系统代理的部分程序，但它会改变更多系统流量，并涉及系统权限、路由和 DNS 行为。只有确认 OpenClaw 绕过普通代理、且你理解当前客户端的 TUN 设置时，才考虑开启；开启后逐项验证，并在不需要时关闭。
保留可复现信息
排查时记录 OpenClaw 版本、运行环境、报错状态码、请求域名、Clash 命中规则和所选策略组。分享日志前先删除 API 密钥、授权头、账户标识、内网地址及订阅链接。
完成配置后，建议保持一个简单、可维护的方案：OpenClaw 使用文档支持的代理方式，模型 API 只匹配必要的服务商域名，规则指向一个名称明确的策略组，并保留原有兜底规则。这样节点失效或服务商调整 API 时，你可以从日志快速判断是哪一层发生变化，而不必重建整份 Clash 配置。若连接在更新后突然中断，先核对服务商公告、OpenClaw 版本变更和节点状态，再逐项回退最近修改。