cloud flare 1014 우회

이프·2026년 2월 15일

CMC Cloudflare 트러블 슈팅

trouble-shooting

목록 보기

9/9

상황

Busan CMC 1st 활동 중 진행하게 된 Ondo 프로젝트에서 빠른 마케팅과 SEO 노출을 목적으로 Domain을 구매했고 적용하려고 했다.

하지만 우리는 서비스를 Serverless로 운영하면서 DB를 Sass인 Supabase로 선택했는데, Supabase에 CName Record 설정을 하던 중 CF 1014 문제가 발생했다.

문제 분석

CF 1014 Trouble Shooting Docs에서 어떤 에러인지 부터 확인했다.

Error 1014: CNAME Cross-User Banned
This error indicates that a CNAME record between domains in different Cloudflare accounts is prohibited.

해당 에러는 Cloudflare 서로 다른 계정의 도메인에 대해 CNAME을 설정할 수 없다는 내용이다. (Supabase가 Cloudflare로 배포하고 있나보다..)

CF 입장에서 크게 두가지 측면에서 CNAME Record 설정을 막고 있다.

도메인 하이재킹 방지
CF를 이용중인 Client A의 Domain 정보를 활용해 악성 코드가 포함된 피싱사이트를 제작하거나 쿠키등을 탈취할 수도 있다. 이것을 CF는 방지해주는 것이 목적으로 보인다.
도메인 하이재킹에 대한 설명은 CF Learning Docs에 잘 정리되어있다.
경제적/인프라 측면
CF를 이용중인 악의적인 Client가 CF를 이용중인 다른 Client들의 정보들을 무단으로 사용하면서 트래픽을 발생시킨다. CF는 계정 별로 요금을 책정하는데 다른 Client들은 악의적인 Client로 인해 말도 안되는 요금을 납부해야된다.
이랬을 때 CF 입장에서 책임을 묻기도 힘들고... 너무 복잡해지니까 막아버린 것으로 추측된다.

문제 해결 방안

문제 해결 방안은 크게 2가지가 있는데 Supabase 유료 플랜 사용과 CloudFlare Workers를 활용하는 것이다. 두가지 각 각 장단점이 있지만 최종적으로 CloudFlare Workers를 선택했다.

각 각에 대해 한 번 알아보고 어떤 이유로 CloudFlare Workers를 선택했는지 알아보자.

Supabase 유료 플랜

Supabase 유료 플랜은 Custom Domain에 대한 기능을 제공하지만 달달이 돈을 내야한다. 이거 하나면 해결이 된다!

CloudFlare Workers를 선택하면서 이후 프로세스에 대해 자세히는 모르겠지만, 아마도 CF를 사용하는 대표적인 Sass인 Vercel과 같이 Cloudflare for SaaS를 통해 Custom Domain에 대한 승인을 통해 1014를 해결해 줄 것으로 예상된다.

정리하자면 장점은 간단하다는 것이고 단점은 유료라는 것이다.

CloudFlare Workers

다음으로 Worker를 활용하는 방식은 CF에서 DNS 설정이 된 Web Server(Vercel)와 Supabase 간에 Proxy를 하나 두는 것이다.

그림과 같이 보안 처리, 요청 가공, 캐싱 등 중간에 필요한 정보들을 Worker에서 처리하는 방법이다. 이 방법에도 장/단점이 존재한다.

장점

Supabase 유료 플랜에서 벗어나 무료로 서비스를 제공 할 수 있다.
Supabase 관련 정보를 front에서 은닉할 수 있다.
- CSR과 ServerLess기반 BackEnd로 명확한 관심사 분리
요청/응답에 따른 필요한 처리를 커스터마이징 할 수 있다.

단점

Worker는 하루에 10만 건의 요청까지만 무료로 제공하기 때문에 서비스가 커지면, 유료 요금제로 전환을 하거나 아키텍처 변경이 필수 동반된다.
Worker에 대해 작업하는 추가 비용이 발생한다.

Worker를 선택한 이유

각 각의 장단점을 비교 했을 때 핵심은 비용 vs 복잡도로 좁힐 수 있다.
프로젝트의 MVP 관점에서 바라봤을 때 비용 최소화가 가장 중요하게 다가왔다. 복잡도도 간단하면 좋겠지만, 복잡도를 낮추는 것은 MVP 관점이 아닌 유지보수 관점에서 바라봐야 한다고 생각했기 때문에 Worker를 선택했다.

Worker에 대한 설정 방법은 사진에서 보이는 것과 같이 Worker Page에서 Create application -> Start with Hello World를 통해 index.js를 직접 작성할 수 있다.

export default {
  async fetch(request, env) {
    const SUPABASE_URL = 'https://project-id.supabase.co';
    const SUPABASE_KEY = 'supabase-anon-key';

    const targetUrl = `${SUPABASE_URL}/rest/v1/store?select=*`;

    try {
      const response = await fetch(targetUrl, {
        method: 'GET',
        headers: {
          'apikey': SUPABASE_KEY,
          'Authorization': `Bearer ${SUPABASE_KEY}`,
          'Content-Type': 'application/json',
        },
      });

      const data = await response.json();

      return new Response(JSON.stringify(data, null, 2), {
        headers: {
          'content-type': 'application/json;charset=UTF-8',
          'Access-Control-Allow-Origin': 'https://ondoguide.com',
        },
      });

    } catch (error) {
      return new Response(JSON.stringify({ error: error.message }), { 
        status: 500,
        headers: { 'content-type': 'application/json' }
      });
    }
  },
};