Cloudflare 代理如何悄悄破坏我的 Lambda ALB 通信

Source: Dev.to

流程（修复前）

flowchart LR
    Browser -->|①| CF1[Cloudflare Edge (api.hoge.com)]
    CF1 -->|②| Lambda
    Lambda -->|③ backend.hoge.com = Cloudflare IP| CF2[Cloudflare Edge (backend.hoge.com)]
    CF2 -->|❌ Error 1000| ALB

快速修复

将 backend.hoge.com 的 Proxy 关闭。
长期计划：将 Lambda → ALB 的通信迁移到 VPC 内部。

错误

从前端调用 API 返回了 403 Forbidden，响应体为：

Cloudflare Error 1000
DNS points to prohibited IP

API Gateway 和 Lambda 看起来正常；ECS 端没有日志记录，因此 ALB/WAF 并非问题根源。

架构

flowchart LR
    Browser -->|HTTPS| APIGW[API Gateway]
    APIGW --> Lambda
    Lambda -->|HTTPS backend.hoge.com| ALB
    ALB --> ECS
    ECS --> RDS

Lambda 充当 BFF（Backend‑for‑Frontend）。后端运行在 ALB + ECS（受遗留约束）。Lambda 使用 backend.hoge.com 域名通过 HTTPS 调用 ALB。

故障排除步骤

1. 初始嫌疑 – WAF 规则、安全组限制、ECS 认证逻辑、API‑Gateway 授权器。

2. 没有 ECS 日志 – 表明请求从未到达 ALB。

3. curl 测试

   curl -v https://backend.hoge.com

   响应头包含：

   server: cloudflare

   正文包含 DNS points to prohibited IP，确认是 Cloudflare 本身返回了 403。

4. 文档检查 – Cloudflare 错误 1000 发生在 A 记录指向 Cloudflare 所拥有的 IP，或请求经由其他反向代理后再次回到 Cloudflare 时。

根本原因

Cloudflare DNS 设置：

• 因为 api.hoge.com 的代理 ON，浏览器流量在到达 Lambda 之前已经经过 Cloudflare Edge。
• Lambda 对 backend.hoge.com（同样 ON）的请求解析到 Cloudflare Anycast IP，导致请求再次进入 Cloudflare Edge → 循环。

循环示意图

flowchart LR
    Browser -->|①| CF1[Cloudflare Edge (api.hoge.com)]
    CF1 -->|②| Lambda
    Lambda -->|③ backend.hoge.com = Cloudflare IP| CF2[Cloudflare Edge (backend.hoge.com)]
    CF2 -->|❌ Error 1000| ALB
    ALB --> ECS
    ECS --> RDS

为什么会出现 Error 1000？

当 Cloudflare 检测到循环或解析到的源 IP 属于以下范围时，会返回 Error 1000：

• Cloudflare 所拥有的 IP 段（用于防止循环）
• RFC 1918 私有地址（10.x.x.x、172.16.x.x、192.168.x.x）
• 回环地址（127.0.0.1）

在我们的案例中，backend.hoge.com 解析到的是 Cloudflare IP，导致 Cloudflare 将该请求视为指向自身并予以阻止。

修复 #1 – 快速修复

将 Proxy OFF 用于 backend.hoge.com。

现在 DNS 返回实际的源 CNAME（ALB 域名），而不是 Cloudflare IP，打破了循环。

修复后流程

flowchart LR
    Lambda -->|backend.hoge.com = ALB domain| ALB
    ALB --> ECS
    ECS --> RDS

请求再次正常流转。

我学到的内容

Cloudflare 不仅仅是 DNS

它将权威 DNS、反向代理、CDN 和 WAF 结合在一起。当 Proxy ON 时，所有流量都会先经过 Cloudflare Edge 再到达源站。

• 非常适合面向浏览器的流量（DDoS 防护、缓存、WAF）。
• 如果源站也在 Cloudflare 后面，服务器之间的通信可能会出现问题。

Proxy ON 与 OFF 会改变整个流量路径

flowchart LR
    subgraph Proxy_OFF
        C1[Client] -->|ALB domain| ALB1[ALB]
    end
    subgraph Proxy_ON
        C2[Client] --> CF[Cloudflare Edge] --> ALB2[ALB]
    end

将 Proxy 设置匹配到你的使用场景

结论： 在你的基础设施内部调用任何域名时，都必须确认 Cloudflare 的代理设置。一个简单的 “Proxy ON” 可能会意外产生请求循环，并表现为 Cloudflare 错误 1000。

快速修复（临时）

如果服务器在调用 Proxy ON 域名时，调用的服务本身也在 Cloudflare 之后，你可能会创建一个循环，从而触发 Error 1000。

长期解决方案

Routing Lambda → ALB traffic through a public DNS name works, but it isn’t ideal.
Moving this communication inside the VPC is the proper solution.

flowchart LR
    Browser -->|HTTPS| APIGW[API Gateway]
    APIGW --> Lambda
    subgraph VPC
        Lambda -->|VPC‑internal| ALB
        ALB --> ECS
        ECS --> RDS
    end

迁移时需要注意的事项

• Lambda 必须部署在 VPC 内部（如果尚未部署）。
• Cold‑start impact 因 VPC 部署而产生的影响目前已非常小——AWS 已显著改进。
• Security groups 需要显式规则，允许 Lambda → ALB 流量。

此方案消除了内部流量对 Cloudflare 的依赖，降低了延迟，并简化了网络拓扑。

为什么会突然出现这个问题？

Proxy ON 配置已经稳定运行了很长时间，为什么现在会开始出错？

• 在更新日志中没有找到 Cloudflare 官方关于 Error 1000 检测或代理行为更改的公告。
• 社区中关于 “Error 1000 突然出现” 的报告通常可以追溯到 用户端配置更改（例如 DNS 记录更新、托管方 IP 变更）。
• 我仍在审查 Cloudflare 的审计日志，以寻找可能解释最近故障的线索。如果发现更多细节，我会更新此帖。

Summary

• 当请求经过 Proxy ON 域 并且 随后该请求调用另一个 Proxy ON 域时，Cloudflare 会产生循环，导致 Error 1000。
• 对于服务器间通信，要么为内部域 关闭 Proxy，要么将流量完全保持在 VPC 内部。