Bot Token 相当于 Telegram 机器人的核心凭证。一旦出现在公开仓库、聊天截图、日志或第三方平台中，攻击者可能调用接口、修改 Webhook 或冒充机器人操作。处理原则是先控制风险，再恢复服务，不能只删除泄露消息后继续使用旧 Token。
哪些情况属于Token泄露？
Token 出现在公开代码库、可访问日志、工单截图、群聊、网页源码、构建产物或不可信服务中，都应视为可能泄露。无法确认是否被访问时，也应按泄露处置。
发现后第一步做什么？
记录发现时间、暴露位置和当前服务状态，限制继续传播，但不要在更多群组转发完整 Token。随后立即通过官方 BotFather 撤销旧 Token 并生成新凭证。
为什么删除消息还不够？
消息可能已被转发、缓存、截图或被搜索引擎与代码扫描器记录。只删除原文无法证明凭证没有被复制，因此旧 Token 必须失效。
如何通过BotFather轮换Token？
在确认机器人账号后使用 BotFather 的 Token 管理功能撤销旧凭证并生成新 Token。操作前核对机器人用户名，避免处理错机器人；新 Token 只通过受控渠道保存。
新Token应该存在哪里？
使用服务器环境变量、密钥管理服务或受权限保护的配置中心，不写入 Git、镜像、前端代码或普通文档。开发、测试和生产环境使用不同机器人和凭证。
轮换后Webhook怎样恢复？
更新服务端凭证后重新设置 Webhook，并核对 HTTPS 地址、secret token 和 pending update 状态。基础配置可参考Telegram机器人Webhook部署教程。
是否需要先删除旧Webhook？
旧 Token 失效后无法继续管理机器人，但仍应使用新凭证检查当前 Webhook 并设置正确地址。若怀疑更新积压或来源异常，根据业务需要决定是否丢弃待处理更新。
如何检查是否被滥用？
查看 Webhook 变化、异常 API 调用、发送消息、管理员操作、服务器访问日志和密钥读取记录。没有异常证据不等于没有泄露，轮换仍是必要动作。
服务器还要排查什么？
检查账号权限、部署脚本、环境变量、历史备份、CI 日志、容器镜像和第三方集成。如果泄露来自服务器入侵，只换 Token 不能解决根因。
代码仓库中的历史怎么处理？
从当前代码删除只是第一步，还要评估提交历史、Fork、构建缓存和镜像。即使完成历史清理，新 Token 也不得复用；通知有权限的维护人员更新本地环境。
多个机器人怎样分批轮换？
为每个机器人建立清单，记录负责人、环境、部署位置、轮换时间和验证结果。逐个处理并观察服务，不把所有 Token 放在同一文件或同一消息中传递。
如何避免更新期间重复处理？
部署新 Token 前暂停相关消费者或启用幂等检查，恢复后核对 update_id、订单和任务状态。Webhook 重试与死信处理可参考Webhook失败重试指南。
API鉴权还需要哪些保护？
Token 只解决 Telegram API 身份，业务回调和后台接口仍需签名、时间戳、Nonce 和权限控制。可参考机器人API鉴权与防重放设计。
如何建立日常密钥管理制度？
限制读取人员，设置定期轮换和离职回收流程，扫描代码库与日志中的秘密，并记录密钥版本但不记录明文。生产操作采用最小权限和双人复核。
安全与隐私提醒
应急调查日志可能包含用户、群组和订单信息，只收集必要证据并限制访问。不要公开攻击细节、完整凭证或个人信息；涉及严重入侵时按适用法律和合同履行通知义务。
恢复后怎样验收？
验证 BotFather 状态、Webhook、命令、群权限、后台任务、支付回调和告警，确认旧 Token 无法使用。结合Telegram机器人安全审计清单完成复查。
技术支持咨询
如果你需要排查 Token 泄露、重新部署或建立多机器人密钥管理，可整理机器人数量、部署方式和暴露位置，通过 Telegram 联系 @sosbot 沟通应急与加固范围。请勿在咨询消息中发送完整 Token。