OpenClaw Telegram 排障（Windows）：长轮询可能不稳定，部分白名单用户收不到回复（v2026.3.23-2）

最新一条 Windows 11 报告显示：OpenClaw 在 Telegram 长轮询（polling） 模式下可能出现不稳定——上游 getUpdates 明明能看到用户消息，但下游不一定会触发 OpenClaw 的回复。

在该报告中，现象甚至呈现为：

白名单用户 A 有时能收到回复
白名单用户 B 经常收不到回复
但 B 的消息依然能在 Telegram Bot API 的更新流里看到

来源：

Issue： openclaw/openclaw#54560

报告里提到的关键现象（症状）

报告者先验证了一些“基础条件”都没问题：

bot token 可用（getMe 成功）
getChat 在受影响的私聊里可用
受影响用户的消息能出现在 getUpdates 里

但 OpenClaw 的处理是间歇性的：

有时能看到类似 telegram sendMessage ok ... 的成功日志
但另一个白名单用户会频繁“无回复”
同时日志里出现过类似：
- polling stall detected（一段时间没有 getUpdates，触发强制重启）
- polling runner stop timed out（停止轮询 runner 超时，约 15 秒）

报告环境：

OpenClaw：2026.3.23-2
系统：Windows 11

怎么快速确认你遇到的是同一类问题

如果下面几条同时成立，你大概率命中的就是同一类故障：

你使用的是 Telegram polling。
你能明确验证：用户消息在上游 getUpdates 里出现。
网关日志里出现轮询停滞、强制重启或 runner 停止超时等提示。
白名单配置正确，但仍有用户经常收不到回复。

建议用一个更“可判定”的小测试：

让两个不同的白名单用户在 30 秒内各发一条简单消息（如“ping”）。
立刻查看 gateway 日志里是否出现：
- update 收到/解析
- 白名单判定（是否接受该用户）
- 消息路由到 session 的记录
如果上游 update 明确存在，但下游没有路由/回复，那更像是 polling/runner 或路由链路的问题（而不是 token 或 Telegram 本身不可用）。

优先排除的高频运维坑（并非已确认根因）

以下并不是 #54560 的最终结论，但足够常见，建议先快速排除。

1）同一个 bot token 被多个实例“同时轮询”

Telegram 的 polling 对“多消费者”非常敏感：

如果你同时跑了两个 OpenClaw 实例（或两个 Telegram provider 配置），很容易出现看似随机的漏回/不回。

建议做：

确认只存在一个 gateway 实例
确认只启用了一个 Telegram provider
干净地停止旧实例后再启动并复测

2）runner 卡住导致“重启也不完全恢复”

报告里提到清理过 ~/.openclaw/telegram 仍不稳定；如果你也反复看到 “runner stop timed out”，说明可能存在：

轮询线程/任务无法按预期退出

建议做：

先停止 gateway
确认进程真的退出（没有残留 node 进程）
再启动并复测

3）Windows 网络环境对长轮询更脆弱

Windows 下长轮询实际使用中可能更容易被这些因素影响：

VPN / 代理劫持
防火墙/杀软拦截
笔记本休眠/省电策略导致连接被打断

可尝试的止血动作：

在稳定网络下复测（尽量不要 VPN）
测试期间关闭休眠
临时放行 gateway 进程的网络权限

谁最容易被这个 Windows Telegram polling 问题影响

这类问题尤其影响下面三类人：

把 Telegram 当成主告警或主控制通道的操作者，因为间歇性不回消息最容易在真正重要的通知上暴露出来。
允许多人通过同一个 bot 协作的团队，因为“用户 A 正常、用户 B 异常”最容易把排障注意力带偏到错误的白名单猜想上。
为了省事直接在原生 Windows 上跑 polling 的用户，因为看起来最省心的部署方式，往往也是最容易被长轮询脆弱性放大的那一种。

实用止血：把 Telegram polling 从 Windows 迁走

如果 Telegram 对你的工作流很关键，最务实的止血方案通常是：

把 gateway（或至少 Telegram provider）跑在 Linux 上

可选落地方式：

小型 VPS
同机 WSL2（取决于你环境的稳定性）
家用服务器/NAS

这能显著降低“Windows 长轮询不稳定”的概率。

搜索入口补强：用户真正搜索的通常不是完整 issue 标题

真实搜索里，用户更常输入的是症状，而不是完整 bug 名称，例如：

OpenClaw Telegram Windows 不回复
Telegram getUpdates 有消息但机器人不回
OpenClaw polling stall detected Telegram
白名单用户收不到回复 Telegram OpenClaw
runner stop timed out Telegram polling

如果你是从这些搜索词进来的，最快的判断顺序是：

如果 getUpdates 里根本看不到该消息
- 更像是 Telegram 上游投递、token、webhook/polling 模式或网络配置问题，不是这篇说的同一类故障。
如果 getUpdates 能看到消息，但 OpenClaw 没有继续路由处理
- 优先排查 polling stall、allowlist 判定和重复 gateway 实例。
如果用户 A 能回、用户 B 不能回
- 优先对比 chat 类型、allowlist 身份写法，以及是否有第二个实例在抢同一个 bot token。
如果每次重启后短暂恢复，随后又再次失效
- 在拿到反证前，先按 runner 稳定性或 Windows 长轮询脆弱性处理。

这种“按症状走”的入口，往往比一上来翻配置文件更快。

哪些情况大概率不是这篇在说的问题

如果你遇到的是下面这些情况，这篇文章大概率并不对症：

你使用的是 Telegram webhook，不是 polling
用户消息在 getUpdates 里根本看不到
所有用户都同时彻底失效，而且恰好发生在 token 轮换之后
bot 在已知正常的聊天里也完全发不出消息

这几类情况更应该先从 token 是否有效、投递模式是否冲突、webhook/polling 是否打架，以及 provider 基础配置是否正确开始查，而不是先假设命中了本文讨论的 Windows polling 不稳定模式。

3 步运维摘要

如果你只有 2 分钟，优先按这个顺序排：

先确认收不到回复的那个用户，其消息是否真的出现在 getUpdates
再确认是否只有一个活跃 gateway 在消费这个 bot token
最后确认把 polling 从原生 Windows 迁走后，问题是否明显缓解

如果第 1 步就不成立，那大概率不是本文讨论的问题形态。如果第 2 步不成立，先消灭重复消费者。如果只有第 3 步能显著改变结果，就应把 Windows polling 稳定性视为首要怀疑对象。

常见止损判断问题

什么时候该停止纠结白名单写法，优先怀疑 polling 稳定性

如果受影响用户已经明确出现在 getUpdates 里、allowlist 也确认包含该用户，且问题会在重启后短暂缓解又反复出现，那就更该先查 polling stall，而不是继续反复改 allowlist 写法。

现在已经影响生产使用时，最快的低风险止血动作是什么

优先把 Telegram provider 从原生 Windows 迁走。相较于继续在带有休眠、VPN、防火墙或杀软变量的机器上调长轮询，这通常是更低风险的止血手段。

给维护者/issue 补充信息时，优先带这些

想加速定位，建议准备一份最小证据包：

精确 OpenClaw 版本（openclaw --version）
运行形态（原生 Windows / WSL2 / 远端 Linux）
是否存在多个实例同时运行
脱敏后的日志片段，覆盖：
- Telegram provider 启动
- getUpdates 轮询循环（含 stall detected）
- 用户 B 发消息的时间窗口
- 白名单是否判定通过

从 Telegram polling 流量转成 Windows 稳定性排查清单

如果你是因为 Telegram polling 在 Windows 上不稳定、且 allowlisted user 偶尔收到异常回复搜到这里，先不要只重启 bot。要把问题拆成四个边界：polling offset 是否连续、allowlist 匹配是否命中正确用户、Windows 进程是否被休眠或网络切换打断、以及重复消息是否来自旧轮询结果重放。

最小排查清单包括：保存一次 polling offset 日志、当前 allowlist 配置、Windows 电源和网络状态、以及异常回复对应的 update id。这样 Telegram 故障流量会被引导到“Windows 部署、轮询恢复、权限边界”三类高意图入口，而不是停在偶发收不到消息。

来源

openclaw/openclaw#54560