PyPI 博客：事件文件托管错误

基础设施透明度事件报告：文件托管错误执行摘要 在 2026 年 8 月的大约两周时间里，一些 PyPI 用户从 files.pythonhosted.org 下载文件时遇到间歇性 502 和 503 错误，从而在从 PyPI 安装期间触发失败。感谢我们的用户在支持跟踪器中提交报告；一份报告特别将问题范围缩小到单个缓存节点。发现了两个独立的问题。 Fastly 网络内的金丝雀部署触发了一个缓存节点的错误配置，导致 Fastly 的路由层针对到达受影响缓存节点的流量返回 502 响应。另外，我发现并修复了我们自己的 Fastly 配置中围绕原始回退和范围请求行为的几个错误。这些已经存在了一段时间，只是在深入研究这些报告时才浮出水面。这两个间歇性问题现已得到解决，自 8 月 28 日起下载功能恢复正常。 背景：PyPI 的文件托管缓存如何工作大多数人运行 pip install（或您选择的安装程序），它就可以正常工作：请求发出，所需的文件返回。在幕后，files.pythonhosted.org 是三个源（也称为“后端”）前面的 Fastly CDN 服务。上传文件时，PyPI 首先将其写入 Amazon S3 作为主要的持久副本。后台作业将其同步到 Backblaze B2，因为 Fastly 和 Backblaze 具有零成本出口协议：通过 Fastly 从 B2 提供文件除了存储费用之外不需要任何费用。在读取器（安装程序）路径上，Fastly 首先尝试 B2。如果 B2 没有回答，或者回答了我们不期望的内容，则 Fastly 会退回到 S3。 PyPI 使用 Amazon S3 Glacier Instant Retrieval 存储类来平衡存储和检索成本。当 Fastly 将 S3 称为后备方案时，其成本高于 B2，但作为权宜之计将继续为消费者服务。一旦缓存，Fastly 不再需要检查 B2 或 S3 - 文件永远不应该改变，并且 Cache-Control 标头设置 max-age=365000000，不可变，公共 - 大约 11.5 年。名为 Conveyor 的第三个后端处理除包文件请求之外的所有内容，例如可预测的 URL 以及一些旧版重定向。流程图 TD Client([客户端请求]) --> Edge{快速边缘} Edge -->|打包文件| B2[(B2：无出口缓存)] 边缘 -->|其他所有|输送机[输送机] B2 -->|200 或 206| Response([对客户端的响应]) B2 -.->|404、超时或 5xx| Archive[(S3: origin,fallback)] Archive --> Response Conveyor --> Response 该后备路径仅在边缘注意到 B2 发生故障时才起作用。我修复的错误之一是它并不总是能正确注意到，这增加了“正常”错误噪音。时间线 8 月 15 日 Fastly 的报告将问题起始于本周六，地点是西雅图地区的一个缓存节点。 #11876 证实了这一点。 8 月 17 日 来自 files.pythonhosted.org 的前两份持久性 502 报告已打开，#11895 / #11897 。 8 月 18 日 #11908 添加了详细的再现，显示了 6 小时内 88 个记录的 502，跨 32 个不相关的软件包，包括安装程序用于读取 PEP 658 元数据的小 .whl.metadata 范围请求。通过三个开放的网络报告，我在 Datadog 日志中挖掘相应的 PyPI 文件错误，但没有发现任何后果。 infra#237 合并，修复了 B2 根本不响应的情况下 B2 到存档的故障转移，而不是响应错误。 8 月 19 日 #11925 将问题隔离到一个 Fastly 缓存节点，cache-pae2080020 : 502，在超过 19 小时内，路由到该节点的每个请求均由 x-served-by 标头对失败响应进行确认。 Fastly 的网络操作消除了路由覆盖，将一部分流量发送到受影响的存在点。 infra#238 合并，改进了文件托管服务的日志配置。 infra#239 合并，拒绝不涉及文件主机的 HTTP 方法。 8 月 20 日，Fastly 观察到受影响点的恢复情况，随后确认错误率已停止上升。 8 月 21 日 infra#241 合并，在早上高峰追踪到发送逻辑无效范围的单个客户端后，从分段缓存中免除后缀和多范围请求。 8 月 24 日，infra#243 合并，两个损坏的并行下载器在一天内产生了 41,315 个同类错误。 8 月 28 日 快速修补他们这边的底层金丝雀配置错误，并从他们的金丝雀队列中排除所有 PSF 流量，包括 PyPI。 infra#245 合并，修复了 URL 标准化排序错误，该错误使错误的分段缓存响应被缓存并提供给同一文件的每个后续请求。促成因素 POP 走向金丝雀 Fastly 运行着一个金丝雀队列，这是其舰队的一个子集，在全面推出之前运行缓存和路由软件。 PyPI 的流量多年来一直是该群体的一部分，帮助 Fastly 工程验证更改。金丝雀部署期间的部分回滚留下了缓存问题