飞书群里 一下机器人半天没回登到 ECS 上看容器docker logs干净得像刚启动。这种「OpenClaw 没响应」的现场十次里有六七次跟飞书没关系问题出在模型那一层早就断了只是没人去看。TaoToken 这边先把模型通道理顺打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 注册并创建 API Key然后把 Base URL 填成 https://taotoken.net/api让 OpenClaw 的对话和任务消耗走这条统一接入。顺序很关键——先把模型侧 curl 通再回头查telnet 公网IP 3000、netstat -tulpn | grep 3000和feishu-connector插件日志不然你会把半小时浪费在飞书开放平台的配置页上来回改 App Secret 却始终没碰对地方。1. 飞书 机器人没回先分清是哪一层断了1.1 两种「没响应」在聊天窗口里长得一模一样在飞书里发一条「帮我看下昨天的任务」机器人不吭声可能是三种情况消息压根没送到 ECS 上的 3000 端口消息送到了但 OpenClaw 调模型时鉴权失败直接抛错并吞掉了回复或者事件订阅的 Verification Token 对不上飞书侧在回调校验阶段就拒绝了。这三种在飞书客户端看起来完全一致所以排查不能靠猜得按「从内到外」的顺序压先确认容器活着、模型能返回再去查端口和回调。原文那套阿里云 ECS Docker Compose 飞书自建应用的部署方式本身没问题卡点几乎都集中在第三步——模型侧的 Key 和通道地址。1.2 排障前先把三样东西放在手边动手之前准备好这些能省掉大量来回切窗口的时间ECS 的公网 IP 和 SSH 登录方式以及部署目录一般是/opt/openclaw或~/openclaw飞书开放平台里那个自建应用的App ID、App Secret、Verification Token一把可用的模型侧 Key从 TaoToken 控制台创建形如YOUR_API_KEY注意第三条经常被跳过。很多人是部署完 OpenClaw 才想起要配模型然后随手翻出某个旧的百炼 API-Key 填进去结果是那把 Key 所属的账号早就欠费或者权限被回收了。与其回阿里云百炼控制台再点一遍不如直接在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 建一把新的后面所有模型请求都从这条通道出。1.3 一个判断方向的土办法先在容器内部 curl 一下本机的健康检查接口如果/health有返回说明 OpenClaw 主进程是活的这时再去发一条测试消息、盯feishu-connector的日志有没有新行。日志不刷新 → 问题在飞书到 ECS 这一段回调地址、端口、安全组。日志刷新了但内容是模型报错 → 问题在 Key 或 Base URL。日志刷新了、模型也返回了、飞书里就是没消息 → 去看回复推送接口的权限有没有开。这三岔口分清楚后面每一步都是十分钟内的事。2. 把百炼 API-Key 那一步挪到 TaoToken 通道2.1 在模型广场挑一个 ID顺手创建 Key登录 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 之后先去模型广场看当前有哪些可用模型把要用的模型 ID 原样抄下来。这里不要凭印象写gpt-5、也不要自己给模型名加日期后缀——模型 ID 以模型广场当时的列表为准抄错一个字符OpenClaw 侧就是一句含混的「上游返回错误」排查成本很高。挑完模型进控制台创建一把 API Key复制保存。这把 Key 只用于服务端调用不要贴到飞书机器人的可见回复里也不要在群里发截图。填配置时统一用占位符YOUR_API_KEY表示。2.2 docker-compose 与 .env 里改模型通道OpenClaw 的 Docker Compose 部署一般把模型参数放在.env里由 compose 文件注入容器环境变量。先看你的部署目录里是不是这个结构services: openclaw-core: image: openclaw/openclaw:latest container_name: openclaw-core ports: - 3000:3000 env_file: - .env volumes: - ./data:/app/data restart: unless-stopped对应的.env里把模型相关的三行改成MODEL_PROVIDERopenai-compatible MODEL_BASE_URLhttps://taotoken.net/api MODEL_API_KEYYOUR_API_KEY MODEL_NAME以模型广场当时的列表为准几个容易翻车的点单独说MODEL_BASE_URL结尾不要加/v1OpenClaw 这类客户端自己会拼路径你多写一层就会变成/api/v1/v1/chat/completions报的是 404MODEL_PROVIDER要选 OpenAI 兼容那一类别选成某个厂商私有协议变量名以你所用镜像自带的模板为准如果镜像的.env.example里叫别的名字按.env.example来别硬套。2.3 改完必须重建容器不是重启改.env之后执行docker compose restart openclaw-core往往不生效因为环境变量是在容器创建时注入的。正确做法是先删再起cd /opt/openclaw docker compose down docker compose up -d docker compose psdocker compose ps看到状态是Up且没有反复重启再进下一步。如果一启动就退出用docker compose logs --tail100 openclaw-core看是不是 Key 那行留了空格或引号。3. 在 ECS 上先 curl确认模型侧真的返回了3.1 容器健康检查/health 该长什么样这一步的目的是把「容器活着」和「模型通」分开确认。在 ECS 上执行curl -s -o /dev/null -w %{http_code}\n http://127.0.0.1:3000/health返回200就说明 OpenClaw 主进程在监听本机 3000 端口跟模型配置无关。如果这里是Connection refused先别管模型去看docker compose ps和容器日志端口没起来说明进程根本没跑起来。3.2 对话接口 curl 一次看模型侧有没有真回复健康检查过了之后再打一次对话接口。路径以你部署版本的注册路由为准常见的是/api/chat一类curl -s -X POST http://127.0.0.1:3000/api/chat \ -H Content-Type: application/json \ -d {message:ping,session_id:debug-001}期望是拿到一段正常的模型输出。如果返回里出现 401、403、invalid api key、insufficient这类字样问题百分之百在MODEL_API_KEY或账户状态上跟飞书没半点关系。此时回 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 的控制台对一下这把 Key 是不是被删了、有没有复制到多余的空格、有没有贴串行。如果返回的是 404 或者路径不存在先确认自己请求的是 OpenClaw 的路由而不是模型的路径——模型那一层是 OpenClaw 内部去调的不需要你手动拼。3.3 从容器内部再打一次排除网络策略宿主 curl 通、容器内不通的情况在 ECS 上并不罕见尤其是给容器配了自定义网络或代理变量的时候。进容器里再确认一遍docker exec -it openclaw-core sh -lc wget -qO- http://127.0.0.1:3000/health || curl -s http://127.0.0.1:3000/health这一步通了模型侧基本可以判定没问题接下来所有排查都往飞书方向走。4. 公网 3000、netstat 与 feishu-connector 日志逐项过4.1 telnet 公网 IP 3000先确认外部能不能进飞书服务器要从公网回调你的 ECS所以本机通不代表外部通。在你自己的电脑上执行telnet 你的ECS公网IP 3000连不上优先查三处ECS 安全组有没有放行 3000入方向来源建议按需收紧而不是0.0.0.0/0、服务器上有没有firewalld或ufw还在拦、Docker 的端口映射是不是写成了127.0.0.1:3000:3000这样只有本机能访问外部必然不通要写成3000:3000。4.2 netstat 看监听地址别自己骗自己在 ECS 上执行netstat -tulpn | grep 3000关注Local Address那一列。如果是127.0.0.1:3000说明只监听回环外部一定连不上是0.0.0.0:3000或:::3000才算对外。顺便看一眼 PID 对应的是不是 docker-proxy 或容器进程避免你改了另一个占用 3000 的服务却以为改的是 OpenClaw。4.3 跟着 feishu-connector 的日志读飞书这一层到底有没有收到请求日志比任何猜测都准docker exec -it openclaw-core tail -f /app/plugins/feishu-connector/logs/app.log保持这个窗口不关然后在飞书里 一次机器人观察三类输出完全没有新行请求没到问题在回调地址、端口或飞书事件订阅状态有新行但写着verification failed/signature mismatchVerification Token 或 Encrypt Key 对不上有新行、事件解析成功、但后面跟着模型调用错误回到第 2、3 节检查通道配置4.4 飞书开放平台侧要核对的三项在飞书开放平台那个自建应用里把App ID、App Secret、Verification Token与服务器.env里的值逐个比对注意不要多空格、不要漏字符。事件订阅的回调地址要写成公网可访问的 HTTPS 地址路径是/feishu/webhook证书必须是有效证书自签名证书在 URL 校验阶段就会失败。另外确认两件事应用已经发布并通过审核未发布的版本不会真正推送事件以及机器人的消息接收权限、发送单聊/群聊消息权限都已勾选。很多人 App Secret 改对了、端口也通了最后卡在权限没勾表现同样是「消息无响应」。5. 权限验证失败与消息无响应对照表5.1 按现象定位别按猜测改配置把常见现象和对应方向列成一张表出错时直接查表比反复重启容器高效得多现象最可能的原因先看哪里飞书里完全没反应日志无新行回调没到 ECStelnet 公网IP 3000、安全组、回调地址日志有行但报校验失败Verification Token / Encrypt Key 不一致飞书应用配置与.env对照日志显示事件收到回复超时模型侧报错容器内 curl 对话接口、Key 状态本机 curl 通、公网 telnet 不通端口只绑定 127.0.0.1 或防火墙拦截netstat -tulpn偶发无响应上游超时或容器重启docker compose ps、容器日志时间戳5.2 两个最常见的误判第一个误判是看到「权限验证失败」就去改模型 Key。这句话里的「权限」指的是飞书应用的事件订阅校验跟模型通道完全是两回事改 Key 不会有任何变化。第二个误判是看到「消息无响应」就重装 OpenClaw。重装能解决的概率很低因为问题通常在容器的环境变量或飞书后台配置里重装反而把好不容易跑通的部署覆盖掉。真想快速分方向就回到第 3 节那两条 curl本机对话接口有正常模型返回就把注意力全部放到飞书侧没有正常返回就先修模型通道别碰飞书。6. 跑通之后去控制台对一下这次调用配置改完、容器重建完、飞书里 机器人能正常回话之后建议再回 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 看一次用量记录确认刚才那几条测试消息确实从这条通道出账了。这一步能帮你排除一种隐蔽情况Key 写得对但环境变量没被容器读到OpenClaw 悄悄退回了某个默认通道短期内看起来正常换个模型或重启之后就断。想省事的话先用 TaoToken 模型对话 拿同一把 Key 发一条测试消息确认模型 ID 和 Base URL 都没填错长期跑机器人任务可以到 Coding Plan 看套餐是否够用Key 丢了或者要换新在 控制台 API Keys 里重建即可。如果你顺手也在用 Claude Code 做调试环境变量对照这份 接入文档 改就行注意 Base URL 填 https://taotoken.net/api末尾同样不要加/v1。最后留一句经验这类「机器人不回话」的问题八成的时间都花在来回改飞书配置上而真正的断点常常在一行环境变量里。养成先 curl 本机、再看插件日志的习惯排障会从一下午缩短到十几分钟。