用户报告在尝试访问 GitHub 仓库和下载软件发布版本时，出现了广泛的 504 Gateway Timeout（网关超时）和 503 Service Unavailable（服务不可用）错误。值得注意的是，这些中断发生在官方 GitHub 状态页面继续报告所有系统正常运行的同时，导致官方报告与实际用户体验之间存在显著差距。
报告的服务中断
Hacker News 上的原始帖子链接到 Linux 内核仓库，强调了 GitHub 似乎对许多用户处于宕机状态的一段时间。评论者证实了这一点，报告在尝试打开仓库网页或下载工具时出现了特定的 504 Gateway Timeout 和 503 Service Unavailable 错误。
一位以 shimms 为名的评论者指出，该问题专门影响发布下载，破坏了他们的持续集成 (CI) 系统。另一位用户 bagels 报告称，这些故障持续了 30 多分钟，导致无法使用 Terraform 和其他自动化工具。
状态报告中的差异
讨论中的主要争议点是官方状态页面的不准确性。评论者指出，虽然页面显示“一切正常”，但许多用户仍无法访问服务，导致用户对故障是源于他们自己的网络还是 GitHub 产生困惑。
一位评论者 skissane 建议，状态页面可能仅显示管理层认为“足够重大”的故障。其他人指出，如果第三方状态追踪器依赖于 GitHub 提供的相同事件数据，那么它们也可能是不准确的。
还有证据表明访问情况不一致；一些用户报告称，他们在登录状态下可以访问网站，但在退出登录时收到 504 错误，这表明可能存在内容分发网络 (CDN) 或面向公众的基础设施问题。
基础设施负载与替代方案
讨论中的一些参与者将这种不稳定归因于平台负载的巨大增加。一位评论者 czarek_pl 引用报告称，GitHub 的提交数量在过去一年中增加了五倍，这可能是由于“AI 革命”以及由此产生的对基础设施的需求。
为了应对这些反复出现的问题，一些评论者建议放弃 GitHub，以避免“单点故障”的风险。建议包括在廉价的虚拟专用服务器 (VPS) 上托管私有仓库，或使用 Codeberg 等替代方案，一位评论者将其描述为轻量级且对开源友好的选择。
未解决的技术原因
提供的资料尚未确认 504 和 503 错误的具体技术原因。目前尚不清楚问题是局部的 CDN 故障、发布下载基础设施的特定故障，还是与报告的提交量增加相关的更广泛的容量问题。
“一切正常”的状态与报告的 504 错误之间的差异仍是一个不确定点。在没有 GitHub 官方确认的情况下，无法确定状态页面是故意过滤了信息，还是仅仅未能捕捉到特定类型的服务降级。