OpenClaw 调用海外模型失败，为什么先查 Clash 路由
OpenClaw 调用海外模型时出现连接超时、请求失败或长时间没有响应，不一定意味着模型服务不可用。一次模型请求通常会经过 OpenClaw 所在的进程、DNS 解析、Clash 入站端口、策略组和代理节点，最后才到达你配置的模型服务商。链路中任意一环没有按预期工作，都可能表现为相似的报错。尤其要注意：浏览器可以打开模型服务商的网站，并不能证明 OpenClaw 发出的 API 请求也走了同一条网络路径。
具体行为取决于 OpenClaw 的运行方式和系统环境。它可能运行在桌面应用、终端进程、容器或远程主机中；不同场景是否继承系统代理、是否读取 HTTPS_PROXY 等变量，以及是否使用独立 DNS 设置，都可能不同。Clash 的系统代理通常只影响遵循系统代理设置的应用；如果 OpenClaw 不读取这些设置，就需要为其配置代理环境变量，或在确认网络影响后考虑 TUN 模式。先确认请求从哪里发出，再选代理方法，比盲目更换节点更有效。
准备 Clash 配置：确认核心、端口与策略组
开始排查前，确认你使用的 Clash 客户端已成功启动内核，并且当前启用的是预期配置。Clash Verge、Clash Verge Rev、Mihomo 或其他兼容客户端的菜单名称可能不同，但需要核对的内容相同：活动配置是否正确、代理节点是否可用、策略组是否有可选节点，以及本地入站端口是否正在监听。客户端窗口打开并不等于代理核心正常运行；如果日志持续显示配置解析失败或内核退出，应先解决这些问题。
找到配置中声明的 mixed-port 或其他入站端口。mixed-port 通常同时接受 HTTP 和 SOCKS 连接，适合需要通过环境变量接入代理的命令行程序；实际端口以当前配置为准，不要照抄其他教程里的默认值。若端口绑定在本机地址，通常应使用回环地址连接；容器或远程进程则可能需要单独的网络桥接设置，不能把宿主机的 127.0.0.1 当成容器自己的地址。
在客户端的代理或策略组页面，确认用于海外流量的策略组里确实有可用节点，并手动选中一个已完成延迟测试的节点。订阅中可能同时包含自动选择、地区组和具体节点；如果 OpenClaw 命中的策略组没有可选出口，即便订阅里显示许多节点，请求也可能失败。先用一条明确可用的线路完成验证，之后再启用自动选择或故障转移，能减少变量。
确认 OpenClaw 的请求是否经过本机代理
在 OpenClaw 当前运行环境中检查代理设置，而不是只检查浏览器。若该版本支持标准代理环境变量，可以在启动 OpenClaw 的同一个终端会话中临时设置 HTTP_PROXY、HTTPS_PROXY，并按客户端文档设置对应的 SOCKS 变量。地址和端口应替换为 Clash 实际监听值。设置变量后，从该终端启动 OpenClaw，再进行一次短请求；如果应用由桌面启动器、服务管理器或容器启动，它未必能看到你在另一个终端里设置的变量。
临时验证时可先只影响当前进程，确认有效后再决定是否写入用户级或服务级环境配置。某些运行时对代理变量的支持并不一致，变量名称、代理协议和大小写处理也可能不同。如果 OpenClaw 文档提供了专用代理设置，应优先采用该版本正式支持的方式。不要把未经确认的变量写进长期启动脚本，否则以后切换网络或关闭 Clash 时，程序可能仍尝试连接一个已不存在的本地端口。
若应用无法读取系统代理或环境变量，可以评估 Clash 的 TUN 模式，让符合路由条件的系统流量由虚拟网卡接管。开启前应先了解客户端的权限要求、路由模式和与现有 VPN 的冲突风险；企业设备或远程服务器尤其要谨慎。TUN 能覆盖部分不遵循系统代理设置的程序，但它不会自动修正错误的 DNS、策略规则或上游网络故障，也不意味着所有请求都应该被代理。
按实际 API 地址配置分流规则
OpenClaw 可以连接不同模型服务商，也可能使用兼容接口或自定义 base URL。因此不要照搬一份固定域名清单：真正需要路由的是你当前配置里填写的 API 主机名，以及运行时确实观察到的相关请求。主机名可能属于模型厂商，也可能是组织提供的网关或自建服务。以配置值和 Clash 连接日志为依据，才能避免把无关流量误送到代理节点。
在规则模式下，规则顺序会影响最终出站。若已有更宽泛的规则先命中，后来添加的模型域名规则就可能不会生效。建议把针对实际 API 主机名的规则放在会抢先匹配的宽泛规则之前，并指向已验证可用的策略组；国内服务和本地地址则按个人需要保留直连。编辑远程订阅生成的配置前，先确认更新订阅是否会覆盖本地修改，必要时通过客户端支持的覆写或规则提供者功能管理增量规则。
规则调整后发起一次新的模型请求，并在 Clash 的连接面板或日志中观察对应记录。重点核对请求的域名、命中的规则、最终策略组和出站节点。若日志只显示 IP 地址，可检查 DNS 解析、连接嗅探或日志过滤设置，但不要仅凭一个无法辨认的连接就批量添加域名。不同版本的内核和客户端界面字段可能略有差异，判断标准是请求最终是否进入预期的代理出站。
排障阶段可以短暂切换到全局模式做对照：若全局模式成功，而规则模式失败，通常应重点检查规则顺序、目标域名和策略组；若两种模式都失败，则还要检查节点本身、代理端口、DNS 和 OpenClaw 的代理接入方式。全局模式适合定位问题，不一定适合作为长期配置，因为它会让原本应直连的流量也经过代理，增加延迟并扩大故障范围。
区分 DNS、TLS 与流式响应问题
代理规则正确并不代表 DNS 一定正确。若 OpenClaw 在连接前就把主机名解析到了不合适的地址，或者客户端、系统和 Clash 分别使用不同的 DNS 路径，日志里可能出现解析失败、连接到异常地址或 TLS 握手中断。此时先比较同一 API 主机名在当前环境中的解析结果，并查看 Clash 是否使用了预期 DNS 设置。不要为了验证而把所有 DNS 请求随意转发给陌生服务器，也不要把 DNS 故障直接归结为节点速度慢。
TLS 错误需要与超时区分。证书校验失败、握手被重置和等待响应超时，指向的原因并不相同。检查设备时间是否准确、系统证书是否更新，以及是否存在企业 HTTPS 检查、杀毒软件网络过滤或其他 VPN。不要通过关闭证书校验来绕过问题，这会削弱 API 密钥和对话数据的传输保护。若只有某个节点出现握手错误，换一条可信节点做对照；若所有节点都失败，则检查客户端和系统层面的网络拦截。
部分模型接口使用流式响应，连接建立后会持续传送数据。普通网页能打开，只能说明基本访问可用，不能证明长连接或流式传输稳定。记录请求是否在建立连接前失败、收到首个响应后中断，还是运行一段时间后停止；再对照 Clash 日志中的连接持续时间和断开原因。若短请求成功而长对话中断，优先检查代理链路稳定性、节点负载和中间网络是否会回收空闲连接，而不是反复修改模型名称或提示词。
按单变量顺序完成验证与回滚
- 记录当前状态：记下 OpenClaw 的模型服务商、API 主机名、运行位置和报错时间，同时保存当前 Clash 配置副本。不要在排障中同时升级客户端、改 DNS、换订阅和重写规则，否则很难知道是哪项改变带来了结果。
- 验证 Clash 出口：确认核心正常运行，选择一条已测通的节点，并检查代理入站端口确实处于监听状态。先用客户端自身的连接或延迟测试判断节点是否可用，再观察本机代理是否能建立连接。
- 验证进程接入：让 OpenClaw 通过受支持的代理设置启动，或在评估影响后启用 TUN。使用一次短请求进行测试，并确认连接日志中出现了与 API 主机名对应的连接记录。若日志没有记录，先检查请求是否由另一个容器、远程主机或后台服务发出。
- 验证规则结果：在规则模式下确认 API 请求命中了预期规则和策略组。必要时短暂使用全局模式做对照；完成判断后恢复更合适的日常模式，不要把诊断配置长期留在全局代理状态。
- 验证稳定性：至少完成数次短对话和一次较长请求，分别观察首次响应、连续输出和工具调用是否正常。一次成功只能证明某次链路可用，不能证明节点在高峰时段或长连接场景下稳定。
- 逐项恢复与记录：关闭不再需要的临时环境变量或测试模式，保留最终规则和节点选择，并记录客户端、内核及配置版本。若改动后问题更严重，恢复备份，再按单项修改重新测试。
OpenClaw 调用海外模型不稳定时，常见桌面代理设置的局限是：只开启系统代理，却没有确认命令行或后台进程是否遵循它；只添加一个猜测的域名规则，却没有查看实际 API 主机名；或者换了节点，却没有检查策略组最终选择。Clash V.CORE 的价值在于让节点、规则模式和连接日志集中在同一套工作流中，便于逐项确认请求走向；如果你希望按本文方法检查本机代理与模型 API 路由，可以前往前往下载获取客户端，并从备份现有配置、验证单条请求开始。