历史实验：CloudFront 转发 Bilibili API 的配置与费用边界

历史实验。 本文记录 2023 年 CloudFront 反代 Bilibili API 的结构。地区出口、授权脚本和接口兼容性需要单独验证，截图不保证当前番剧播放可用。

一、当时的结构与遗漏

客户端/浏览器脚本 → 自定义 CloudFront 域名 → Bilibili API。CloudFront 能转发 HTTP API，不代表源站把其请求认作有授权的港澳台观看，也不意味着媒体内容一定沿相同出口传输。

旧流程在控制台新建分配，以 api.bilibili.com 为自定义源站，再配置自定义域名和证书。下面是当时界面：

若要研究同类 API 转发，至少应逐项检查：

1. 回源使用 HTTPS，并让上游 Host、TLS 名称和源站证书相匹配。
2. 按 API 需要配置请求方法，以及查询参数、Cookie、Authorization 等转发。需要全部查询参数时明确设置，不能把“所有 API 都必须转发所有信息”作为一般规则。
3. 用户相关的 API 禁用共享缓存，避免把一个账号的响应复用给其他人。缓存策略和 Origin Request Policy 是两个不同配置。
4. 自定义域名要在分配中声明、由证书覆盖，按 CloudFront 提供的 DNS 目标接入。使用 ACM 的查看器证书需按官方要求在 us-east-1 区域配置。

这些要求分别见回源请求策略与自定义域名 HTTPS。旧截图不是当前控制台的完整操作说明。

二、原生 gRPC 不能只开放 POST

后续 iOS 实验还涉及 grpc.biliapi.net。当前 CloudFront 官方 gRPC 配置要求 HTTPS 源站、HTTP/2、允许 POST，并在缓存行为中启用 gRPC。仅选择全部 HTTP 方法并不等于完成 gRPC 配置；业务 grpc-status 也要检查。AWS 官方 gRPC 文档列出了功能与限制。

API、客户端版本和请求格式仍需相容，应通过完整业务流程验证。

三、纠正费用说明

费用应按 CloudFront 定义的流量方向和计费项目判断，不能只用“入站流量”概括。按量计费页面区分向互联网输出、向源站输出、请求数量和附加功能等费用；客户端 POST/PUT 或 WebSocket/gRPC 上行经过 CloudFront 发往源站的部分，属于 CloudFront 向源站输出，不能与普通回源下载混为一谈。

CloudFront 的计费方案包括按量计费和固定套餐。旧的每月 1 TB 免费额度说明不能推导所有分配、所有请求或所有架构都零成本。日志、边缘函数、源站服务、套餐之外的能力都需按实际方案核对。以当前定价页和按量计费项目为准，部署前设置预算和核对账单。

四、IP、脚本与现状边界

固定一个 CDN 入口 IP 或看到其地理标签，不能证明 Bilibili API 看到同一地区出口。使用公共解析服务或第三方 IP 清单前，应确认当前维护状态与实际回源路径。

浏览器脚本的登录授权、API 和 UPOS 路径变化需要独立核查。代理能收到账号信息，不能以“自建”就忽略凭据处理和共享缓存风险。使用前应逐项核对请求转发、缓存、授权与出口条件。

相关历史记录：Workers、Gcore、iOS 请求改写。