部署于GCP Cloud Run的Telegram机器人Webhook更新异常排查

现象概述 #

将Telegram机器人部署在GCP Cloud Run上，实例缩容至0时多数情况正常：Telegram发起调用后实例启动，机器人可接收更新。但存在未知场景下的异常：

• 向机器人发送消息
• GCP无相关请求记录
• 实例未触发扩容

特殊恢复场景 #

调用getWebhookInfo方法后，Telegram会立即推送更新，仿佛被“提醒”后恢复，具体流程：

1. 当前无待处理更新
2. 向机器人发送消息
3. GCP无请求、日志及事件记录
4. 等待N小时后
5. 调用getWebhookInfo
6. 返回待处理更新数为1，且Telegram立即发起调用

补充信息 #

• 应用启动时会调用setWebhookMethod，多数情况返回Webhook is already set，但偶发返回Webhook was set——说明Telegram在未知场景下“遗忘”了Webhook配置，且机器人从未调用deleteWebhook接口

已排除的情况 #

• 仅使用默认防火墙规则
• 证书由Google管理，无问题
• 尝试过带静态IP（负载均衡）和不带的情况，问题均存在
• 已确认与"allowed_updates": [ "message" ]配置无关

可能的原因分析 #

1. Telegram Webhook静默失效机制：Telegram可能在检测到Webhook端点长时间无响应（比如Cloud Run缩容为0后的首次调用超时窗口过短）后，暂时停止推送更新，直到getWebhookInfo触发状态校验才恢复。
2. 冷启动超时与重试策略不匹配：Cloud Run冷启动耗时如果超过Telegram的首次调用超时阈值，Telegram会标记该Webhook为无效，停止后续推送，直到主动查询Webhook状态才重新触发推送。
3. Telegram Webhook配置缓存异常：Telegram对Webhook配置的缓存可能出现异常过期，导致推送路由丢失，调用getWebhookInfo会强制刷新缓存，恢复推送路径。
4. GCP网络层静默丢弃请求：极少数情况下，GCP网络网关可能在长时间无流量后的连接回收阶段丢弃Telegram的初始请求，而Telegram未收到错误回执不会重试，直到getWebhookInfo触发状态同步后重新推送。

内容的提问来源于stack exchange，提问作者Artem Ptushkin