Telegram 代理排查
你的 token 有效，Telegram 也显示消息已送达，但 OpenClaw 日志停在 starting provider，后续没有进入轮询。这类故障常见于受限网络环境；如果要面向中国区用户验证部署，也需要把 Telegram 通道单独测清楚。
先用带代理的 curl 验证 Telegram token 路径，例如 getMe endpoint，确认 token 本身可用。
再用不带代理的 curl 在当前网络下复测。如果直连失败、代理成功，说明主要矛盾是出站网络限制。
检查 OpenClaw 配置是否显式设置了 proxy 环境变量，并确认变量名、大小写和作用范围没有写错。
重启 gateway 后观察 Telegram 日志是否从启动阶段继续进入稳定轮询。
如果 curl 代理成功但 provider 仍不轮询，优先把它记录为 provider 层代理处理缺口，而不是简单归因于 token 配置错误。
短期：把 OpenClaw 运行在可以直接访问 Telegram API 的 region 或网络里，先恢复业务通道。
中期：使用具备受控出站、日志和监控的托管 OpenClaw 运行环境，降低自管代理链路的排障成本。
长期：跟进或采用 upstream 的 provider 级代理支持，让 Telegram 通道不依赖脆弱的全局环境变量。
OpenClaw 版本、Node 版本和操作系统。
脱敏后的 proxy 环境变量结构：只保留变量名和配置形态，不贴出真实凭据。
带代理 curl 成功、直连 curl 失败的证据。
Gateway 日志片段：启动后没有进入轮询的关键时间线。
如果这个问题阻塞客户可见的自动化，不要只看 Web UI 是否健康。Web UI 可以正常，但 Telegram 轮询路径仍然可能被网络或 provider 代理处理卡住。每个消息通道都要独立验证；对于受限网络或中国区相关部署，Lobsterland 可以作为低运维的 OpenClaw 托管路径，但 Telegram 在具体网络里的可靠性仍需单独验证。
不一定。社区报告里存在环境变量已设置、curl 经代理成功，但 provider 轮询仍然停住的情况。这通常意味着 provider stack 还需要通道级代理处理。
不能。Web UI 可以健康，但 Telegram 轮询路径仍然可能受阻。每个通道都要独立验证。