如何基于请求头自定义字段在Cloudflare实现多区域ELB路由？

针对你需要根据请求头region字段路由至KR ELB或SG ELB的场景，以下是几种优化后的实现思路，解决你提到的现有方案的痛点：

一、无编码方案：Transform Rules + Origin Rules 组合使用 #

虽然Origin Rules不直接支持自定义请求头路由，但可以通过Cloudflare的Transform Rules做中转，间接实现基于自定义头的路由，全程GUI配置无编码：

• 步骤1：转换请求头为可路由的Host字段
  配置Request Transform Rules：
  • 匹配条件：请求头存在region，且值为kr/sg
  • 执行动作：将请求的Host头修改为{region}.abc.com（例如kr.abc.com或sg.abc.com）
• 步骤2：基于转换后的Host配置Origin Rules
  分别创建两条Origin Rules：
  • 规则1：匹配Host等于kr.abc.com，将源地址设置为KR ELB的域名
  • 规则2：匹配Host等于sg.abc.com，将源地址设置为SG ELB的域名
• 补充：确保kr.abc.com和sg.abc.com已在Cloudflare DNS中配置（可设置为指向主域名的CNAME，Origin Rules会自动覆盖源地址）

这种方式既保留了Origin Rules无编码、零额外成本的优势，又规避了使用查询参数的设计缺陷。

二、CF Workers优化方案：降低延迟与风险 #

如果选择Workers，可通过以下方式解决你担心的问题：

1. 缩小路由范围
   不要将Worker路由设置为abc.com/*，仅匹配需要区域路由的路径（例如abc.com/api/*），减少Worker处理的流量规模，降低延迟影响。
2. 极简代码实现
   保持Worker逻辑只专注于路由，避免冗余操作，示例代码如下：

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

async function handleRegionRouting(request) {
  const region = request.headers.get('region')?.toLowerCase()
  const originMap = {
    kr: 'kr-elb.your-domain.com',
    sg: 'sg-elb.your-domain.com'
  }

  // 优先使用指定区域的ELB，否则 fallback 到默认区域（例如SG）
  const targetOrigin = originMap[region] || originMap.sg
  
  // 构造代理请求，指定目标源
  const proxyRequest = new Request(request)
  proxyRequest.headers.set('Host', targetOrigin)
  
  return fetch(proxyRequest, {
    cf: { resolveOverride: targetOrigin } // 强制解析到指定源，提升路由效率
  })
}

3. 规避链式调用风险
   • 若存在多个Worker，通过调整Worker Routes的优先级，让路由Worker仅处理目标路径，其他请求直接跳过；
   • 尽量将路由逻辑合并到单个Worker中，避免多Worker链式调用的复杂度。
4. 成本控制
   Cloudflare Workers提供免费额度（每日10万请求），超出部分费用极低（每百万请求约0.5美元），可通过Cloudflare Analytics监控调用量，合理控制成本。

三、额外建议 #

• 验证请求头合法性：添加规则（Transform Rules或Worker逻辑）校验region字段值仅为kr/sg，非法值直接返回400或路由到默认区域，避免错误路由；
• 区域节点优化：在Worker或Origin Rules中指定Cloudflare的区域节点（例如KR请求使用首尔节点），进一步降低跨区域延迟。

内容的提问来源于stack exchange，提问作者HFX