Cloudflare反向代理配置详解

当你第一次在Cloudflare仪表盘的“Workers & Pages”或“Rules”菜单里看到“反向代理”相关选项时，可能会觉得这又是一个复杂的企业级功能。实际上，把Cloudflare当作一个免费且强大的反向代理来用，是很多资深站长和开发者压箱底的技巧。它远不止是“加速网站”那么简单，而是一个能重塑流量路径、隐藏服务器真实身份、甚至实现单域名多后端服务的利器。

反向代理的核心：它替你“接客”

你可以把反向代理想象成公司前台。所有访客（用户请求）都先到前台登记，前台根据访客要找的部门（不同的路径或域名），决定是直接指引到会议室（返回缓存的静态内容），还是需要联系后端的同事（你的源站服务器）。对于用户来说，他们只看到了专业的前台，根本不知道后端的办公室具体在哪栋楼、哪个房间。这就是Cloudflare反向代理在干的事——你的源站IP从此在公网上“消失”了。

实现路径：不止一种玩法

Cloudflare提供了几种方式来实现反向代理，每种都有其适用的场景：

• Workers（无服务器函数）：这是最灵活、功能最强大的方式。通过编写一段JavaScript代码，你可以完全掌控 incoming request（传入请求）和 outgoing response（传出响应）。比如，你可以把 api.yourdomain.com 的流量代理到另一台独立的服务器，而主站流量则指向原来的主机。一段最简单的Worker反向代理代码可能长这样：

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  const url = new URL(request.url);
  // 将所有请求转发到你的源站服务器
  url.hostname = 'your-real-server-ip';
  const modifiedRequest = new Request(url, request);
  return fetch(modifiedRequest);
}

• Transform Rules（转换规则）：位于“Rules”菜单下，这是一种无需写代码的配置方式。你可以通过可视化界面，设置条件（比如匹配特定主机名或路径）和动作（比如重写请求头，或进行主机头覆盖）。比如，你想把 blog.yourdomain.com 代理到第三方托管的博客服务（如Ghost），用Transform Rules配置“重写到”动作，几分钟就能搞定。

一个具体场景：单端口承载多服务

假设你有一台VPS，但80和443端口已经被主网站占用。现在你想部署一个独立的Next.js应用或管理后台。传统做法需要配置复杂的Nginx路径转发或使用不同端口。用Cloudflare Worker，事情就简单了。

你可以在Worker里判断请求的路径：

if (pathname.startsWith('/admin')) {
  // 将/admin路径下的所有请求，转发到内网另一台机器的8080端口
  url.hostname = '192.168.1.100';
  url.port = 8080;
} else {
  // 其他请求照常去主源站
  url.hostname = 'origin-server.com';
}

对外，你的用户访问的始终是同一个优雅的域名，他们完全感知不到背后是两套截然不同的技术栈在协同工作。这种架构的整洁性，对于后期维护来说，能省下大量折腾的时间。

配置中的隐形陷阱

不过，配置反向代理可不是简单改个地址就完事。有几个细节一旦忽略，调试起来能让人头皮发麻。

• SSL/TLS模式：在“SSL/TLS”设置中，如果你的源站服务器没有配置有效的SSL证书（比如在内网或用了自签证书），你必须将模式设置为“Flexible”。如果源站有有效证书，用“Full”或“Full (strict)”会更安全。模式选错，最常见的症状就是“重定向循环”或“连接被重置”。
• Host Header的传递：这是新手最容易栽跟头的地方。当Cloudflare代理请求到你的源站时，默认会修改“Host”头部。如果你的Web服务器（如Nginx）配置了基于域名的虚拟主机，就会因为收不到正确的Host头而返回错误内容。你必须在Worker代码或Transform Rules中显式地设置或保留原始的Host头。
• WebSocket支持：如果你代理的应用需要WebSocket（比如实时仪表盘），务必在Cloudflare的“Network”设置中开启“WebSocket”支持，否则连接会静默失败。

性能与安全的微妙平衡

反向代理不只是转发流量。启用Cloudflare的缓存（Cache Rules），可以将静态资源甚至部分API响应缓存在全球边缘节点，这能将源站负载降低一个数量级。但缓存规则设置不当，又会导致用户看到过期数据。

安全层面，WAF（Web应用防火墙）规则会对代理的流量同样生效。这意味着一把双刃剑：你可以免费获得一层强大的DDoS和应用层攻击防护；但你也必须小心，别让过于严格的WAF规则把你自己的API请求给拦截了。那种半夜收到报警，排查半天发现是自家流量被自家防火墙给毙了的感觉，实在不怎么美妙。

说到底，把Cloudflare反向代理用好了，相当于给你的基础设施穿上了一件“隐形斗篷”，同时手里还多了一根可以随意指挥流量的“魔杖”。它把复杂的网络架构问题，简化成了几条清晰的规则或一小段逻辑。