搭建 Cloudflare R2 中转服务：VPS 选型与技术实现

最近有朋友在问，想给 Cloudflare R2 找个中转机子，这其实是个很典型的“刚需”场景。Cloudflare R2 虽然号称免流出费，但直接通过公网访问在某些地区可能会有网络不稳或者速度受限的问题，而且如果你需要通过特定的线路回源，或者做一些更灵活的访问控制，一台作为中转的 VPS 就显得尤为重要。

今天我们就来深扒一下，给 R2 搭中转，到底该怎么选机子，又该怎么配置。

VPS 中转架构：通过优质线路（如 CN2）的 VPS 将用户请求转发至 Cloudflare R2，优化访问体验并隐藏源站。

为什么我们需要给 R2 中转？

首先得明确，Cloudflare R2 本身是支持公网访问的，配置自定义域名绑定到 R2 桶是最基础的玩法。但在实际折腾中，大家往往面临以下几个痛点：

1. 网络优化需求：虽然 Cloudflare 的全球节点很强，但在特定时段或特定运营商线路下，直接访问 R2 域名可能会出现丢包或者连接重置的情况。通过一台线路优质的 VPS（比如 CN2 线路或去程优化的线路）做中转，可以有效提升国内用户的访问体验。

2. 隐藏源站与安全防护：直接暴露 R2 的绑定域名有时不太放心，利用 Nginx 反向代理在 VPS 层做一次转发，可以隐藏真实的后端存储地址，顺便加上一层防盗链或者简单的访问鉴权。

3. 功能扩展（伪静态/重定向）：R2 毕竟是对象存储，不适合跑复杂的逻辑。如果你需要根据访问路径做重写、兼容旧版 API 接口，或者做一些简单的网页跳转，VPS 上的 Nginx 或 Caddy 就是最好的中间件。

VPS 选型：性价比与线路的博弈

选机器这事儿，永远是“一分钱一分货”，但针对 R2 中转这个场景，我们可以有的放矢。

Nginx 反向代理配置逻辑：配置 SSL 证书、缓存策略以及将请求转发至 R2 源站。

1. 核心关注指标

给 R2 做中转，本质上这台 VPS 是在跑流量。所以，带宽 和 流量限制 是首要指标。

• 带宽：如果是小站或者图床，100Mbps - 200Mbps 的共享带宽其实够用了。如果是视频流媒体分发，那得冲 1Gbps 甚至 CN2 GIA 的大水管。注意区分“峰值带宽”和“月均带宽”，很多低价 VPS 是限制月流量的。
• 流量：这点至关重要。既然是为了绕过某些限制或优化线路，流量包一定要足。TMT (Tencent Mobile Technologies) 或某些美西线路的商家，常有“1T 流量 100 刀”之类的羊毛可以薅，但得警惕虚标。
• 线路：如果是面向国内用户，CN2 GIA 是王道，但价格感人；CN2 GT 或 9929 线路是性价比之选；至于普通的联通 4837 或移动 CMI，价格低廉但在晚高峰可能会波动，适合预算有限的应用场景。

2. 推荐区域

• 美西 (Los Angeles)：去国内延迟最低，物理距离近，且大部分大带宽服务器都集中在这里。是做中转的首选区域。
• 日本 / 新加坡：东南亚访问快，国内访问延迟也能接受，但日本带宽通常较贵，新加坡商家鱼龙混杂，需仔细甄别。
• 中国香港：低延迟的代名词，但价格普遍偏高，而且容易遭受 DDoCC 攻击导致段内波动，适合预算充足、对延迟极度敏感的用户。

3. 配置建议

因为只是做转发，对 CPU 和内存的要求极低。甚至 1 核 512M 的小鸡都能跑得飞起。不要为了买高配而买高配，把预算加在带宽和流量上才是正道。当然，硬盘容量稍微给足一点（20G+），方便我们在本地做一下反向代理的缓存，进一步回源 R2 节省流量费或加速访问。

技术实现：从 Nginx 到 Caddy 的方案对比

选好了机器，接下来就是怎么搭。最常见的方案就是 Nginx 反向代理，但 Caddy 这种自动 HTTPS 的工具也值得一试。

方案一：Nginx 反向代理（经典稳重型）

Nginx 的优势在于配置灵活，社区文档丰富，几乎能实现任何你能想到的转发逻辑。

配置示例： 假设你的 R2 桶域名是 mybucket.r2.dev（或者你自己绑定的域名），VPS IP 为 1.2.3.4。

server {
    listen 80;
    server_name your-vps-domain.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name your-vps-domain.com;

# SSL 证书配置，推荐使用 acme.sh 脚本自动申请 Let's Encrypt 证书
    ssl_certificate /path/to/fullchain.pem;
    ssl_certificate_key /path/to/privkey.pem;

# 开启缓存（可选，用于热门资源加速）
    proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g
                     inactive=60m use_temp_path=off;

location / {
        # 核心配置：反向代理到 R2
        proxy_pass https://mybucket.r2.dev;
        proxy_set_header Host mybucket.r2.dev;

# 保持头部转发
        proxy_ssl_server_name on;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

# 缓存配置
        proxy_cache my_cache;
        proxy_cache_valid 200 302 1h;
        add_header X-Cache-Status $upstream_cache_status;
    }
}

注意点：

• proxy_ssl_server_name on; 这一行很重要，如果 R2 源站是共享 IP 的证书，不加这一行会报 SSL 错误。
• 如果 R2 设置了防盗链（Referer 限制），需要在 Nginx 里伪造 Referer：proxy_set_header Referer "https://your-allowed-domain.com";。

方案二：Caddy（极简自动型）

如果你不想折腾证书申请和续期，Caddy 是个神器。它默认支持自动化 HTTPS。

Caddyfile 示例：

your-vps-domain.com {
    reverse_proxy https://mybucket.r2.dev {
        header_up Host {upstream_hostport}
    }
}

就这么简单！Caddy 会自动通过 HTTP-01 或 DNS-01 挑战签发证书，并自动续期。对于只想简单做个中转的同学来说，Caddy 的上手成本几乎为零。

进阶玩法：添加鉴权

如果你的存储内容不想被公开访问，可以在 VPS 层加一把锁。比如使用 Nginx 的 auth_basic 做个简单的 HTTP 认证，或者配合 ngx_http_accesskey_module 模块实现更复杂的签名验证。这样，即便别人知道了你的域名，没有密码也是无法访问 R2 资源的。

避坑指南与常见问题

在折腾的过程中，有几个细节很容易导致“翻车”：

1. IP 被墙/污染：选用的 VPS IP 如果在国内被墙了，那中转也就无从谈起。购买时建议先去 ping 一下商家的测试 IP，或者在买后第一时间测试连通性。

2. R2 的自定义域名 CNAME 限制：Cloudflare R2 如果绑定在 Cloudflare 的 CDN 下，通过 CNAME 接入是没问题。但如果你是在 VPS 上反向代理 R2 的 dev 域名，偶尔会遇到 Host 指向不一致的问题。最稳妥的方式是给 R2 绑定一个专门的自定义域名，然后 VPS 代理这个自定义域名，而不是代理 .r2.dev 的临时域名。

3. 流量超额：很多廉价 VPS 虽然标称 1Tbps 带宽，但其实是月流量限制。一旦超了，不仅停机，还可能面临高额的扣费。务必配置好 Nginx 的日志分析，或者使用 VnStat 监控流量。

总结

给 Cloudflare R2 找个中转，本质上是用低成本换取更好的网络掌控权和访问体验。对于个人站长或图床爱好者来说，选一台美西线路上、带宽充裕的低配 VPS，配合 Nginx 做反向代理，是目前性价比最高的方案。

如果你对延迟不敏感，纯粹为了备份或非公开访问，其实直接用 R2 的官方 S3 兼容 API + rclone 挂载也是极好的选择，完全不需要中转，也就省去了维护 VPS 的精力。折腾嘛，终究是为了让服务更稳，而不是更麻烦。

希望这篇分享能帮你选到心仪的中转小鸡！