基于Cloudflare Worker构建IPv4至IPv6内网穿透网关的最佳实践

背景与需求

随着家庭宽带与移动网络IPv6的普及，许多家庭数据中心（HomeLab）、NAS及软路由设备已获取公网IPv6地址。然而，在当前的公共网络环境（如企业内网、传统公共Wi-Fi）中，纯IPv4环境依然占据主导地位，导致用户无法直接通过IPv6地址访问内网服务。

本文将介绍一种利用 Cloudflare Worker 作为无服务器边缘代理的解决方案。该方案采用 “动态扁平化子域名” 策略，实现了从公网IPv4环境到内网IPv6服务的无缝桥接。其特点在于配置极其精简、原生支持HTTPS加密，并可结合 Cloudflare Zero Trust 实现金融级的安全访问控制。

架构核心设计

该方案的核心逻辑是利用 Cloudflare 的全球边缘网络作为“中转站”。当用户在IPv4环境下发起请求时，Cloudflare 边缘节点接收请求，并通过 Worker 脚本将流量代理转发至用户的 IPv6 源站。

为了解决多端口服务访问及 SSL 证书匹配问题，本方案采用如下命名规范：

端口号-网关标识.主域名

例如，若网关标识定义为 gw，主域名为 example.com：

• 访问 911-gw.example.com $\rightarrow$ 自动转发至内网 IPv6 主机的 911 端口。
• 访问 5000-gw.example.com $\rightarrow$ 自动转发至内网 IPv6 主机的 5000 端口。

这种设计利用了 Cloudflare 通用 SSL 证书对一级泛域名（*.example.com）的支持，避免了多级子域名导致的证书错误，同时无需为每个端口单独配置规则。

---

实施部署指南

第一步：DNS 泛解析配置

在 Cloudflare DNS 管理面板中，需添加一条通配符 A 记录，将特定模式的流量引导至 Cloudflare 代理网络。

• Type（类型）: A
• Name（名称）: *-gw （此处 gw 为示例前缀，可自定义，如 *-4）
• Content（内容）: 192.0.2.1 （保留地址，作为占位符）
• Proxy status（代理状态）: Proxied (开启代理)

注：192.0.2.1 仅用于让 DNS 解析生效，实际流量将由后续配置的 Worker 拦截处理，不会真正流向该 IP。

第二步：部署边缘代理脚本 (Worker)

创建一个新的 Cloudflare Worker，并部署以下代码。该脚本负责解析子域名中的端口信息、伪造请求头以适配内网服务安全策略，并处理响应重定向。

// 配置常量
const ORIGIN_ROOT = "6.example.com"; // 请替换为已解析到内网设备的IPv6域名
const GATEWAY_SUFFIX = "-gw";        // 与DNS配置中的后缀保持一致

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

async function handleRequest(request) {
  const url = new URL(request.url);

  // 1. 端口提取逻辑
  // 正则匹配格式：数字-后缀.域名
  // 例如：911-gw.example.com -> 提取出 911
  const portRegex = new RegExp(`^(\\d+)${GATEWAY_SUFFIX}\\.`);
  const match = url.hostname.match(portRegex);

  // 若不符合格式，返回帮助信息或 400 错误
  if (!match) {
    return new Response("IPv6 Gateway Error: Invalid Format", { status: 400 });
  }

  const port = match[1];
  
  // 2. 构建回源请求对象
  // 目标构建为：http://IPv6源站:端口/路径
  const targetUrl = new URL(url.toString());
  targetUrl.hostname = ORIGIN_ROOT;
  targetUrl.port = port;
  targetUrl.protocol = "http:"; // 内网服务通常运行在 HTTP 协议

  // 3. 请求头处理（关键安全适配）
  const newHeaders = new Headers(request.headers);
  
  // 核心步骤：重写 Host、Origin 和 Referer
  // 许多路由器和 NAS 会校验这些头部以防止 CSRF 攻击，必须伪装成内网直接访问
  const originAuthority = `${ORIGIN_ROOT}:${port}`;
  newHeaders.set("Host", originAuthority);
  newHeaders.set("Origin", `http://${originAuthority}`);
  newHeaders.set("Referer", `http://${originAuthority}/`);
  
  // 清理 Cloudflare 边缘节点注入的头部，避免干扰后端日志
  newHeaders.delete("cf-connecting-ip");
  newHeaders.delete("cf-ipcountry");
  newHeaders.delete("cf-ray");
  newHeaders.delete("cf-visitor");

  try {
    // 发起回源请求
    const response = await fetch(targetUrl.toString(), {
      method: request.method,
      headers: newHeaders,
      body: request.body,
      redirect: "manual" // 手动处理重定向，防止后端返回内网IP导致跳转失败
    });

    // 4. 响应头处理
    const responseHeaders = new Headers(response.headers);
    
    // 修正 Location 重定向头
    // 如果后端返回了指向内网域名的跳转，将其替换回当前的公网代理域名
    if (responseHeaders.has("Location")) {
      const loc = responseHeaders.get("Location");
      if (loc.includes(ORIGIN_ROOT)) {
        responseHeaders.set("Location", loc.replace(ORIGIN_ROOT, url.hostname).replace("http:", "https:"));
      }
    }

    // 修正 Set-Cookie 的 Domain 属性
    // 防止 Cookie 被限制在内网域名下导致登录态丢失
    const setCookie = responseHeaders.get("Set-Cookie");
    if (setCookie) {
      responseHeaders.set("Set-Cookie", setCookie.replace(/Domain=[^;]+;/gi, ""));
    }

    return new Response(response.body, {
      status: response.status,
      statusText: response.statusText,
      headers: responseHeaders
    });

  } catch (e) {
    return new Response(
      `Gateway Error: Unable to connect to upstream service.\nTarget: ${ORIGIN_ROOT}:${port}\nDetails: ${e.message}`, 
      { status: 502 }
    );
  }
}

第三步：配置路由触发器 (Triggers)

在 Worker 的 Settings -> Triggers 页面添加路由规则，确保所有符合格式的请求都能触发该脚本。

• Route: *-gw.example.com/*
• Zone: example.com

至此，基础的代理功能已部署完毕。用户访问 911-gw.example.com 即可通过 IPv4 网络访问位于 IPv6 内网的 911 端口服务。

---

安全增强：集成 Cloudflare Zero Trust

由于该方案将内网端口暴露在公网，为了防止未经授权的访问或暴力破解，强烈建议结合 Cloudflare Zero Trust (Access) 构建安全边界。

配置流程：

1. 进入 Zero Trust 控制台，导航至 Access -> Applications。
2. 添加一个 Self-hosted 应用。
3. Application Domain 配置：
   • Subdomain: *-gw （支持通配符，一次性保护所有端口）
   • Domain: example.com
4. Policies (准入策略) 配置：
   • Action: Allow
   • Include: 选择 Emails 或 Emails ending in，填入允许访问的邮箱地址。

效果说明：
启用 Zero Trust 后，当访问任何 *-gw.example.com 域名时，Cloudflare 会优先拦截请求并展示身份验证页面。用户必须通过邮箱验证码或 SSO 登录通过后，流量才会经过 Worker 转发至内网。这一机制从网络边缘层面彻底杜绝了端口扫描和未授权访问风险。

方案总结

相比于传统的路径重写代理或VPN方案，基于 Cloudflare Worker 的“扁平化子域名”方案具有显著优势：

1. 兼容性极佳：无需侵入修改 HTML/JS 代码，天然适配所有 Web 应用（包括 WebSocket）。
2. HTTPS 原生支持：利用 Cloudflare 免费证书，无需在内网设备上折腾 SSL 证书。
3. 运维成本低：一次配置，永久适用。新增内网服务无需修改 Worker 代码，仅需通过 URL 端口号区分。
4. 安全性高：配合 Zero Trust，实现了零信任架构下的内网穿透。

该方案是目前解决 IPv4 环境访问 IPv6 家庭数据中心的理想选择。