Telegram 机器人使用 Webhook 时出现 502、连接超时或证书错误，通常要沿着“Telegram—域名—Nginx—应用进程”逐层检查。只反复调用 setWebhook 往往无法解决后端端口、证书链或代理配置问题。
502错误表示哪一层异常？
502 Bad Gateway 一般说明反向代理已经收到请求，但无法从上游应用取得有效响应。常见原因是应用未启动、端口写错、进程崩溃、连接被拒绝或上游提前关闭连接。
先检查Webhook当前状态
通过 Bot API 的 getWebhookInfo 查看当前 URL、待处理更新数和最近错误信息。确认域名、路径与预期一致。排查时不要公开完整 Bot Token，截图或日志中应将凭证脱敏。
域名和DNS如何核对？
确认域名解析到当前服务器，IPv4 与 IPv6 记录都要检查。迁移服务器后旧 DNS 缓存可能继续把请求送到原机器。服务器迁移步骤可参考Telegram机器人服务器迁移教程。
SSL证书常见问题有哪些？
检查证书是否过期、域名是否匹配以及中间证书链是否完整。浏览器能打开网页不代表 Webhook 路径一定正确。自动续期后应确认 Nginx 已加载新证书，并监控到期日期。
Nginx反向代理检查什么？
核对 location 路径、proxy_pass 地址、协议、端口和尾部路径拼接。若应用仅监听 127.0.0.1，Nginx 应连接本机地址；容器部署时则需确认网络名称和端口映射。
应用端口怎样确认？
在服务器本机请求健康检查接口，验证进程确实监听目标端口。检查 systemd、Docker 或进程管理器状态以及启动日志。完整搭建流程见Polling与Webhook部署教程。
为什么会出现504或超时？
Webhook 处理时间过长、数据库连接阻塞或第三方接口等待会导致代理超时。接收端应尽快确认更新，把耗时任务交给队列；同时设置合理超时和幂等处理，避免 Telegram 重试产生重复业务。
日志应该按什么顺序看？
先看 Nginx access/error 日志，再看应用启动与请求日志，最后检查数据库、Redis和外部接口。使用请求标识关联同一次更新，日志中不得输出 Token、密码、私钥或完整个人资料。可参考机器人日志设计指南。
防火墙和安全组可能怎样拦截？
确认公网 HTTPS 端口已开放，服务器本机防火墙、安全组和面板规则一致。后端应用端口通常不必直接暴露公网，应仅允许 Nginx 或内部网络访问。
修复后如何验证？
重新检查 getWebhookInfo，发送受控测试消息并确认更新进入应用、任务执行一次、错误计数不再增加。不要用真实客户订单作为首次测试，也不要为了测试向无关群组批量发送消息。
需要协助排查时准备什么？
准备脱敏后的 Webhook URL、错误时间、Nginx错误行、应用状态、部署方式和最近变更。需要排查 Telegram Webhook、SSL 或 Nginx，可通过 Telegram 联系 @sosbot 沟通。
发表回复