我的GitHub 账号被封 33 小时：怎么从 403 到恢复

11 月 7 号晚上，我的 GitHub 没了。

下午 13:34 我还正常推了代码。晚上再打开，API 直接一个 403 甩过来，主页 404，仓库一个都进不去。我盯着那行 “Sorry. Your account was suspended” 看了半天，第一反应是：这什么玩意儿？第二反应才是：完了。

这个号我用了六年，2020 年 9 月注册的，3493 次贡献，68 个公开仓库。说没就没了。

原因我大概能猜到。11 月 4 号晚上，老板让我把名下的仓库迁到公司新成立的组织 ，我一口气转了十来个。短时间往一个刚创建的组织里批量转仓库，在风控眼里跟”账号农场收集垃圾仓库”没什么区别。组织一点事没有，5 个公开仓照常在线，光我被封了。

当时气得我…..冷静下来想想，迁移这事本身没错，错的是我的执行方式：十几个仓库应该分批慢慢迁，或者干脆交给组织管理员，而不是一个晚上全推过去。说到底还是自己莽了。

先保代码

懵了五分钟，开始干正事。

先确认代码在不在。本地所有仓库的 .git 历史都在，一份没少，我又马上推了一份到 Gitee 做备份。账号丢了能申诉，代码丢了是真没了。star、issue、PR 这些社交关系没了可以重建，代码没了就什么都没了。

然后翻证据。统计卡片算一份成绩单，3493 次贡献、36 天连续提交、161 个 star。全球互联网档案馆 Wayback 上还有我主页快照，至少能证明我存在过，https://ghfind.com/u/xingranya 也有我的评分。

这种情况我决定了: 先不动组织，仓库转回来不好,也没必要开新号，不删东西；不反复尝试登录；开新号绕过封禁本身就是违规，新号大概率一起被封，还连累正在走的申诉。

写申诉信

申诉走官方渠道，登录不了就走 cannot_sign_in 验证邮箱，然后用外国手机号接码。11 月 7 号 23:02，确认邮件到了，Ticket #4968647。

申诉信我这样写的

首先是主动交代。别等客服来问，自己先说清楚批量迁移是怎么回事：入职 onboarding，老板让把自有代码资产迁进公司组织，组织刚创建所以看起来是批量涌入。机器误判最怕你遮遮掩掩，你越坦白，它越好判断你是真人。

然后是证据。光喊”我是真人”没用，得拿真人干活的痕迹出来。我列了自己的项目，onekeyjb、GitHub-Stars-AI-Tools、CervixDetectAI。还有给 SAOS-3624/dsh-see-now 提的几个 PR，封号当天上午刚合并了一个，11 月 5 号还合并了两个，维护者还给了详细的复现评审,这些东西脚本批量造不出来。

最后是承诺。迁移可以暂停、可以全撤销重来，以后改走渐进迁移或者交给组织管理员；PAT 轮换，2FA 确认；要雇主证明、仓库清单都行。态度要具体，别写空话。

Cora 回信了

11 月 8 号凌晨 03:02，Cora 回信了。她没直接给结论，而是问：”Could you please share a bit more about how you plan to use GitHub?”（能多说说你打算怎么用 GitHub 吗？）

这个是所有误封申诉的标准固定问题

回信我按她的提问展开：先纠正了申诉信里的一个日期错误，转移实际是 11 月 4 号晚上，不是信里写的 5、6 号；然后用那些具体的 PR 和项目回答”我怎么用 GitHub”；最后重申所有操作都是我在自己电脑上手写完成的，没有爬虫，没有批量自动化。

发完我又手动追加了一封补充邮件，只补了一个新发现：我数了邮箱里的失败通知，11 月 5 号一天 6 次 CI 失败，10 月 25 号一天 16 次，10 月 24 号到 11 月 6 号之间大概 39 封。模式是推了就挂，几分钟后再推再挂，等于拿 CI 当调试器用。这很可能也是触发风控的因素之一，我写的是”可能的原因之一”。

这封补充邮件还有个插曲。第一版是 AI 写的，排版是僵硬的列表加固定句式，我自己看了一眼就觉得像 AI 发的，最后是我自己按自然段落重写了一遍才发出去。写给官方的东西，千万别用模板味的列表，宁可啰嗦一点、像人话。

去 X 上喊了一嗓子

申诉走工单的同时，我也在 X 上发了两条帖子。先说结论：公开求助有用，但发错了等于白发。

发之前我读了一个叫 Junie 的博主的经历。他的号 10 月 31 号被封，也是申诉后石沉大海，最后在 X 上 @ GitHub COO Kyle Daigle、Martin Woodward 和 Cassidy Williams 求复核，约一小时后 Cassidy 回了一句 “Check now, you should be all set”，账号就恢复了。从被封到解封，他一共用了三天多。

他的帖子格式后来成了我的模板：第一句就是请求加 Ticket 号，接着是账号、被封日期、诚实交代的可能原因、已经做了的整改、回客服的日期和”至今无下文”，最后是一句个人处境和感谢。不哀求，不指责，信息一次给全。

第一条帖子是 11 月 8 号凌晨 02:12 发的，回复在 @github 一条推文下面，没激起什么水花。

第二条是 11 月 9 号凌晨 01:13 发的，单独发帖，@ 了 kdaigle、martinwoodward、cassidoo 三个人。时间我特意选在美东周日中午，Kyle 最活跃的窗口是美东中午到晚上，对应北京时间半夜到早上。

帖子发出去，Kyle 他们还没回，骗子先来了。第一条回复是个叫 JAXON OSCAR 的账号，”message me for quick assistant”，X 自己都把它归到了”可能的垃圾信息”里。凌晨三点多又来一个 @Pako_Jackson，”Same. Luckily @izl_martin handles cases like these.”，同样是把求助者往第三方那里引。这些账号专门蹲求助帖，私信过去不是要钱就是钓鱼，千万别理。

还有个教训，是从另一个被封用户 Scorpion 的经历里看到的：Kyle 确实会看这些帖子，也确实会帮忙转给团队，但他明确说过，”please stop mentioning every GitHub employee”。求助可以，别刷屏、别 @ 一圈人、别连发。最多发一条，几天没动静再在自己帖子下面礼貌追加一次，别的不要做。

回来了

11 月 9 号早上 07:08，GitHub Support 的 Nico 在同一个 Ticket 里回信了。开头就是道歉：是垃圾检测系统误判了。

我 10:31 核实了一遍：API 查账号已经恢复 200，主页、bio、70 个公开仓库、49 个粉丝，全回来了。从 11 月 7 号 22:21（北京时间）被封，到 11 月 9 号 07:08 收到恢复邮件，一共 33 个小时。

到底是哪一步起的作用，我说不准。可能是工单里的证据起了作用，也可能是 X 帖子被人看到了然后转给了团队，或者两者都有。Junie 的经验是 X 帖子约一小时就等到了回复，我的恢复邮件是在发帖后约六小时到的，时间上对得上，但也没有直接证据说明两者之间有因果关系。

如果重来一次

如果重来一次，11 月 4 号那个晚上，我一定不会一口气转十几个仓库。分批迁，或者直接让组织管理员动手，根本不会有后面这 33 小时。

CI 当调试器这个习惯也得改。推了就挂、挂了再推，一天 16 次失败通知，自己看着没觉得有什么，风控眼里这就是机器在刷。以后本地先跑通，攒着一起推，旧的运行及时取消。

申诉这件事本身，最大的教训是只开一个工单，永远回复同一封确认邮件追加信息，别另开新工单。每次追加都要带新信息，没新信息就别写。7 到 10 个工作日没动静，再礼貌跟进一次。

公开求助只发一条，信息一次给全，@ 三个人就够了。帖子下面的”帮你快速处理”全是骗子，别理。

恢复之后也别得意忘形。短期内别批量操作，申诉里承诺过的事，PAT 轮换、2FA 确认，一件一件落实。

六年的账号，33 小时就回来了，算运气好。Junie 只用了三天多，有人等了 54 天，也有人等了两个月。运气是一部分，但申诉信写得越具体、证据越实在，运气好的概率就越大。

33 小时，说长不长，说短不短。够把一个用了六年的账号从 404 里捞回来，也够让我把”别拿 CI 当调试器”这句话刻进脑子里。

---

2026 年 11 月 9 日写于账号恢复当天。文中 Ticket 号、时间线、数据均为真实记录，X 帖链接：@github 回复帖、@kdaigle 求助帖。Junie 的经历见 https://juniexd.cn/blog/Others/github-account-suspended/。

阅读 Markdown 原文