Astro를 Cloudflare에 배포하는 방법: SSR 설정과 중국 내 접속 속도 3배 개선

지난주 지인의 Astro 블로그 배포를 도와주다가 흥미로운 문제를 만났습니다. Cloudflare Pages에 사이트를 배포한 뒤 해외에서 테스트했을 때는 페이지가 즉시 열리고 아주 매끄러웠습니다. 그런데 중국에 있는 지인이 접속하자 로딩에 거의 5초가 걸렸습니다.

Cloudflare는 전 세계 300곳 이상의 데이터 센터를 운영하고 무료이며 대역폭도 제한하지 않는데, 왜 중국에서는 이렇게 느릴까요? 많은 개발자가 겪는 문제입니다. ‘최적 IP’라는 말을 들어봤더라도 구체적인 설정 방법, 계정 제한 위험, 실제 효과를 확신하기는 어렵습니다.

여기서는 가장 기본적인 정적 사이트부터 SSR 설정, 중국 내 접속 최적화까지 Astro를 Cloudflare에 배포하는 전체 과정을 살펴봅니다. 저도 직접 여러 문제를 겪었기에 시행착오를 줄이는 데 도움이 되도록 경험을 정리했습니다.

배울 내용:

• 20분 안에 처음부터 서비스 공개까지 완료하기
• SSR 어댑터의 세 가지 모드를 이해하고 알맞게 선택하기
• 중국 내 접속을 개선하는 세 가지 방법으로 지연 시간 3배 줄이기

바로 시작하겠습니다.

Cloudflare Pages를 선택하는 이유

Cloudflare vs Vercel: 무료 호스팅 플랫폼 비교

Vercel과 Cloudflare 중 무엇을 선택해야 하는지 자주 질문을 받습니다. 결국 요구 사항에 따라 달라집니다.

가장 뚜렷한 차이는 대역폭 제한입니다. Vercel 무료 플랜은 월 100GB를 제공하며, 초과분은 100GB당 $40입니다. 예전에 제 프로젝트 하나가 갑자기 인기 목록에 올라 트래픽이 급증했고 결국 Vercel 청구서를 받았습니다. 반면 Cloudflare Pages는 대역폭이 완전히 무료이며 제한도 없습니다. 개인 개발자에게는 상당히 유용하며 트래픽 급증에 따른 요금을 걱정할 필요가 없습니다.

글로벌 성능 측면에서 Cloudflare는 300곳 이상의 데이터 센터를 운영해 더 넓은 범위를 지원합니다. 유럽, 아시아, 미주 여러 지점에서 측정했을 때 모두 지연 시간이 낮았습니다. Vercel의 엣지 네트워크도 좋지만 노드 수가 상대적으로 적습니다. 사용자가 전 세계에 분포한다면 Cloudflare의 장점이 더 두드러집니다.

또 하나 실용적인 장점은 DDoS 보호입니다. Cloudflare 무료 플랜에도 DDoS 보호가 기본으로 포함되어 별도로 설정할 필요가 없습니다. 전에 사이트가 공격받았을 때 Cloudflare가 자동으로 차단해 로그조차 확인하지 못했습니다. Vercel도 보호 기능을 제공하지만 무료 버전의 보호는 주로 자체 네트워크를 위한 것이며 개별 사이트를 위한 심층 보호는 아닙니다.

그렇다면 Vercel의 장점은 무엇일까요? 빌드 캐시가 잘 구성되어 있습니다. 이미지와 의존성이 많은 프로젝트에서는 이전 빌드 캐시를 유지하므로 두 번째 빌드는 3~4분이면 끝납니다. Cloudflare Pages는 매번 처음부터 빌드해 10분 이상 걸릴 수 있습니다. Next.js와의 긴밀한 통합도 강점입니다. Next.js를 사용한다면 같은 회사의 제품인 Vercel이 가장 좋은 선택입니다.

권장 선택:

• Astro 정적 블로그 → Cloudflare Pages(무료 트래픽이 넉넉함)
• 트래픽을 예측하기 어려운 프로젝트 → Cloudflare Pages(예상치 못한 요금 방지)
• Next.js를 깊이 활용하는 사용자 → Vercel(가장 좋은 개발 경험)
• 잦은 빌드와 빠른 반복 작업이 필요한 프로젝트 → Vercel(빠른 빌드 캐시)

Cloudflare Pages vs Workers: 2025년에 달라진 점

처음에는 저도 이 부분이 혼란스러웠습니다. Cloudflare에는 Pages와 Workers가 모두 있고 양쪽 모두 Astro를 배포할 수 있는데, 어느 것을 써야 할까요?

핵심 차이는 간단합니다. Workers는 엣지에서 JavaScript 코드를 실행할 수 있는 Cloudflare의 서버리스 컴퓨팅 플랫폼입니다. Pages는 Workers + 자동화된 빌드 도구를 하나로 묶은 서비스로 이해할 수 있습니다. Pages도 내부적으로 Workers에서 실행되지만 Git 연동과 자동 배포 같은 기능을 바로 사용할 수 있습니다.

2025년에 달라진 점은 Cloudflare가 새 프로젝트에 Pages보다 Workers를 공식적으로 권장하기 시작했다는 것입니다. 공식 블로그를 살펴보니 주된 이유는 Workers가 더 유연하고 세밀하게 제어할 수 있기 때문입니다. 다만 Astro 사용자라면 이 권장을 너무 엄격하게 따를 필요는 없습니다.

실제 사용 경험:

• Pages 방식: GitHub 저장소를 연결하면 코드 push가 자동으로 빌드를 시작합니다. 단순하고 빠르며 ‘복잡한 설정 없이 빨리 배포하고 싶다’는 상황에 적합합니다.
• Workers 방식: Wrangler CLI로 직접 배포하고 wrangler.jsonc 파일을 설정해야 합니다. 대신 환경 변수와 KV 저장소 binding 등을 더 세밀하게 제어할 수 있습니다.

Astro 프로젝트에서는 무엇을 선택해야 할까요?

• 순수 정적 사이트(output: ‘static’): Dashboard에서 GitHub를 연결하는 Pages 방식이 가장 편리합니다.
• SSR 사이트(output: ‘server’ 또는 ‘hybrid’): 둘 다 사용할 수 있지만 자동화와 유연성을 모두 갖춘 Pages + Wrangler CLI 배포를 더 권합니다.

처음 배포한다면 먼저 Pages의 Git 연동을 사용해 보세요. 몇 분이면 결과를 확인할 수 있으며, 익숙해진 뒤 Wrangler CLI를 검토해도 늦지 않습니다.

Astro를 Cloudflare에 배포하는 전체 과정

정적 사이트 배포: 5분 만에 시작하기

Astro 프로젝트가 블로그, 문서 사이트, 포트폴리오 같은 순수 정적 사이트라면 배포는 매우 간단합니다. 단계별로 진행해 보겠습니다.

사전 조건:

• 프로젝트가 이미 GitHub에 push되어 있음
• Cloudflare 계정이 있음(없다면 무료로 가입)

세부 단계:

1. Cloudflare Dashboard에 로그인
   dash.cloudflare.com을 열고 왼쪽 메뉴에서 Workers & Pages로 이동합니다.

2. 새 프로젝트 생성
   오른쪽 위의 Create application → Pages → Connect to Git을 차례로 선택합니다.

3. GitHub 저장소 연결
   Astro 프로젝트 저장소를 선택합니다. 처음에는 Cloudflare의 GitHub 접근 권한을 승인해야 할 수 있으므로 안내에 따라 진행합니다.

4. 빌드 설정 구성
   잘못 입력하면 배포가 실패할 수 있는 중요한 단계입니다. 다음과 같이 설정합니다.

   • Framework preset: Astro 선택(명령이 자동 입력됨)
   • Build command: npm run build
   • Build output directory: dist
   • Root directory: 프로젝트가 저장소 루트에 있으면 비워 두고 하위 디렉터리에 있으면 경로 입력

5. 배포 클릭
   Save and Deploy를 클릭하고 몇 분 기다립니다. Cloudflare가 코드를 가져와 의존성을 설치하고 빌드한 뒤 배포합니다.

빌드가 성공하면 your-project.pages.dev 도메인을 받습니다. 이 주소로 바로 사이트에 접속할 수 있습니다. 이후 GitHub에 코드를 push할 때마다 Cloudflare가 자동으로 빌드를 시작해 매우 편리합니다.

자주 발생하는 문제:

• 빌드가 실패하고 Node.js 버전 오류가 표시됨: 프로젝트 루트에 .nvmrc 또는 .node-version 파일을 추가하고 18이나 20을 입력합니다. Cloudflare가 자동으로 인식합니다.
• 페이지에 404가 표시됨: Build output directory가 dist인지 확인합니다. 설정에 따라 public 또는 build일 수 있으므로 astro.config.mjs에 맞게 조정합니다.
• 빌드 시간 초과: 의존성이 너무 많거나 네트워크 문제일 수 있습니다. 다시 배포하면 두 번째에는 정상적으로 끝나는 경우가 많습니다.

사용자 지정 도메인 연결(선택 사항):

배포가 끝나면 프로젝트 설정에서 Custom domains를 찾아 Set up a custom domain을 클릭하고 도메인(예: blog.yourdomain.com)을 입력합니다. Cloudflare가 CNAME 레코드를 제공하면 DNS 서비스 제공업체에서 추가합니다. 도메인 자체가 이미 Cloudflare DNS에 있다면 자동으로 설정되어 더 간단합니다.

SSR 사이트 배포: @astrojs/cloudflare 어댑터 설정

처음 SSR을 설정할 때는 공식 문서가 여러 곳에 나뉘어 있어 저도 혼란스러웠습니다. 실제 작업 순서대로 각 단계를 설명하겠습니다.

SSR은 언제 필요할까요?

사용 여부를 판단할 수 있도록 먼저 사용 사례를 살펴봅니다.

• 실시간 데이터 필요: 댓글, 방문 통계, 사용자 로그인 등
• 서버 사이드 로직 필요: API 호출, 데이터베이스 쿼리, 권한 검증
• 온디맨드 렌더링 필요: 콘텐츠가 너무 많아 모든 페이지를 미리 정적으로 렌더링하고 싶지 않은 경우

Markdown 파일만 사용하는 순수 블로그라면 SSR이 전혀 필요하지 않으며 정적 배포로 충분합니다.

1단계: @astrojs/cloudflare 어댑터 설치

Railway - 현대적인 배포 플랫폼, 번거로운 운영 없이 몇 분 만에 라이브

지금 시작 →광고

프로젝트 루트에서 다음 명령을 실행합니다.

npx astro add cloudflare

이 명령은 자동으로 세 가지 작업을 수행합니다.

1. @astrojs/cloudflare 패키지 설치
2. astro.config.mjs 파일을 수정해 어댑터 설정 추가
3. wrangler.jsonc 파일 생성(Cloudflare Workers 설정 파일)

실행 후 astro.config.mjs는 대략 다음과 같습니다.

import { defineConfig } from 'astro/config';
import cloudflare from '@astrojs/cloudflare';

export default defineConfig({
  output: 'server', // 새로 추가된 줄
  adapter: cloudflare(),
});

2단계: 렌더링 모드 선택(중요)

선택지는 세 가지이며 많은 사용자가 여기서 막힙니다. 하나씩 살펴보겠습니다.

1. output: 'server' - 전체 사이트 SSR

• 모든 페이지를 서버에서 렌더링
• 적합한 경우: 데이터 기반 애플리케이션, 자주 갱신되는 콘텐츠
• 단점: 요청마다 렌더링하므로 성능이 조금 느림

2. output: 'hybrid' - Hybrid 모드(권장)

• 기본적으로 모든 페이지가 정적임
• 특정 페이지만 SSR로 선택 가능
• 적합한 경우: 대부분의 페이지는 정적이지만 일부 동적 기능이 있는 블로그
• 장점: 유연성과 성능이 가장 좋음

3. output: 'static' - 순수 정적

• 어댑터가 필요 없으며 앞에서 설명한 정적 배포와 같음

권장 사항: 전체 사이트에 SSR이 꼭 필요하다고 확신하지 않는다면 90%의 경우 hybrid를 선택합니다.

hybrid 모드 사용 예시:

// astro.config.mjs
export default defineConfig({
  output: 'hybrid', // hybrid로 변경
  adapter: cloudflare(),
});

그런 다음 SSR이 필요한 페이지에 다음 한 줄을 추가합니다.

// src/pages/api/comments.js
export const prerender = false; // 이 페이지는 SSR로 렌더링됨

export async function GET() {
  // 데이터베이스에서 댓글 가져오기
  const comments = await fetchComments();
  return new Response(JSON.stringify(comments));
}

다른 페이지는 수정하지 않아도 기본적으로 정적 상태를 유지합니다.

3단계: Cloudflare 서비스 binding 설정(선택 사항)

Cloudflare의 KV 저장소, D1 데이터베이스, R2 객체 스토리지를 사용하려면 wrangler.jsonc에서 binding을 설정해야 합니다.

예를 들어 KV 저장소에 사용자 session을 저장하려면 다음과 같이 설정합니다.

// wrangler.jsonc
{
  "name": "my-astro-app",
  "compatibility_date": "2024-01-01",
  "kv_namespaces": [
    {
      "binding": "MY_KV",
      "id": "your-kv-namespace-id"
    }
  ]
}

먼저 Cloudflare Dashboard에서 KV namespace를 생성하고 ID를 복사해 입력해야 합니다.

코드에서는 다음과 같이 사용합니다.

// src/pages/api/session.js
export const prerender = false;

export async function GET({ locals }) {
  const { MY_KV } = locals.runtime.env;
  const sessionData = await MY_KV.get('user:123');
  return new Response(sessionData);
}

4단계: 로컬 개발과 테스트

Cloudflare 공식 도구인 Wrangler CLI를 설치합니다.

npm install wrangler --save-dev

로컬에서 실행합니다.

npm run build
npx wrangler pages dev ./dist

Cloudflare 환경을 모방하는 로컬 서버가 시작되며 SSR 기능과 binding이 정상적으로 작동하는지 테스트할 수 있습니다.

5단계: 서비스 배포

두 가지 방법이 있습니다.

방법 1: Wrangler CLI로 배포(권장, 더 세밀하게 제어 가능)

# Cloudflare 계정에 로그인
npx wrangler login

# 프로젝트 빌드
npm run build

# 배포
npx wrangler pages deploy ./dist

첫 배포에서는 프로젝트 이름을 입력하라는 메시지가 표시되며, 이후에는 한 줄의 명령으로 끝납니다.

방법 2: Git 연동으로 자동 배포

앞의 정적 배포와 같은 방식으로 GitHub 저장소를 연결하면 Cloudflare가 @astrojs/cloudflare 어댑터를 자동으로 인식합니다. 다만 이 방식에서는 KV 같은 서비스를 Dashboard에서 수동으로 binding해야 하므로 조금 번거롭습니다.

자주 발생하는 오류 해결:

1. “Hydration completed but contains mismatches”
   자주 발생하는 오류로, Cloudflare의 Auto Minify 기능이 HTML을 잘못 압축해 생깁니다.
   해결 방법: Cloudflare Dashboard → 도메인 → Speed → Optimization으로 이동해 Auto Minify의 HTML, CSS, JS 옵션을 모두 끕니다.

2. “Cannot find module ‘MY_KV’”
   binding이 제대로 설정되지 않았다는 뜻입니다. wrangler.jsonc의 binding 이름과 코드에서 사용하는 이름이 같은지 확인합니다.

3. 배포 후 페이지에 500 오류가 표시됨
   Cloudflare Dashboard → Workers & Pages → 프로젝트 → Logs(실시간 로그)에서 구체적인 오류를 확인합니다. 코드가 binding되지 않은 리소스에 접근했을 가능성이 큽니다.

환경 변수와 비밀 정보 관리

환경 변수는 자주 혼동되는 부분입니다. 저도 API 키를 실수로 GitHub에 push했다가 급히 되돌린 적이 있습니다. 올바른 방법을 살펴보겠습니다.

로컬 개발 환경:

프로젝트 루트에 .dev.vars 파일을 만듭니다(앞의 점에 유의하세요).

# .dev.vars
DATABASE_URL=postgres://localhost:5432/mydb
API_KEY=your-secret-key-for-dev

중요: .dev.vars를 .gitignore에 추가해 GitHub에 push되지 않도록 합니다.

로컬 개발 시 Wrangler가 이 파일을 자동으로 읽습니다. 코드에서는 다음과 같이 접근합니다.

export const prerender = false;

export async function GET({ locals }) {
  const apiKey = locals.runtime.env.API_KEY;
  // apiKey로 서드파티 API 호출
}

프로덕션 환경:

.dev.vars를 사용하지 말고 Cloudflare Dashboard에서 설정합니다.

단계:

1. Workers & Pages → 프로젝트 선택
2. Settings → Environment Variables 클릭
3. Add variable을 클릭하고 이름과 값 입력
4. 환경 선택(Production 또는 Preview)

민감한 정보에는 Secrets 사용:

결제 API 키처럼 특히 민감한 데이터에는 암호화되어 저장되는 Cloudflare의 Secrets 기능을 사용합니다.

npx wrangler secret put API_KEY

실행 후 값을 입력하라는 메시지가 표시되며 명령줄에는 노출되지 않아 더 안전합니다.

권장 사항:

• 데이터베이스 URL, 서드파티 API 키 → Secrets
• 공개 설정(사이트 이름, CDN 주소 등) → 일반 환경 변수

중국 내 접속 속도 최적화 실전

문제 진단: 중국에서 사이트의 실제 속도 측정하기

배포가 끝났다고 바로 최적화하지 말고 먼저 실제 속도를 측정하세요. 모든 사이트에 최적화가 필요한 것은 아닙니다. 사용자가 주로 해외에 있다면 Cloudflare 기본 설정만으로도 매우 좋습니다.

온라인 속도 측정 도구:

Alibaba Cloud - 개발자 클라우드 1순위, Lighthouse 서버 15% 할인

15% 할인 받기 →광고

1. 17ce.com(권장)
   17ce.com을 열고 도메인을 입력한 뒤 ‘웹사이트 속도 테스트’를 선택합니다. 중국의 여러 지역과 통신사에서 측정한 결과를 확인할 수 있습니다. ‘응답 시간’ 열을 살펴보세요. 대부분 200ms 이하면 괜찮지만 300ms를 넘으면 최적화를 권합니다.

2. Chinaz 웹마스터 도구 Ping 테스트
   tool.chinaz.com/speedtest는 비슷한 기능을 제공하며 더 자세한 라우팅 정보를 확인할 수 있습니다.

로컬 테스트:

중국에 있다면 Chrome 개발자 도구로 테스트할 수 있습니다.

1. F12를 눌러 DevTools 열기
2. Network 탭으로 전환
3. 페이지를 새로 고친 뒤 첫 번째 요청의 Time 값 확인

판단 기준:

• 지연 시간 < 150ms: 매우 좋으므로 최적화 불필요
• 지연 시간 150~250ms: 무난하며 요구 사항에 따라 결정
• 지연 시간 > 250ms 또는 로딩 시간 > 3초: 최적화 권장

중국에서는 왜 느릴까요?

간단히 말해 Cloudflare는 Anycast 기술을 사용하지만 중국의 네트워크 환경 특성상 경로가 크게 우회하는 일이 많습니다. 예를 들어 베이징에서 접속한 트래픽이 홍콩까지 갔다가 돌아올 수 있어 지연 시간이 늘어납니다. 최적 IP/CNAME은 더 직접적인 경로의 노드를 찾는 방식입니다.

방법 1: 최적 IP 사용(무료, 가장 좋은 효과)

가장 효과가 뚜렷한 방법입니다. 직접 측정했을 때 지연 시간이 약 280ms에서 70ms로 줄었습니다. 다만 어느 정도 직접 설정해야 하며 뒤에서 설명할 위험도 있습니다.

최적 IP란 무엇인가요?

Cloudflare에는 수백 개의 IP 주소가 있고 각각 서로 다른 데이터 센터에 대응합니다. 중국에서 각 IP에 접속하는 속도는 크게 다릅니다. 멀리 우회해 매우 느린 IP도 있고 직접 연결되어 아주 빠른 IP도 있습니다. 최적 IP는 이 가운데 빠른 IP를 찾아 도메인이 직접 해당 주소를 가리키게 하는 방식입니다.

1단계: 최적 IP 테스트

CloudflareSpeedTest 도구를 사용합니다. GitHub의 XIU2/CloudflareSpeedTest에서 다운로드할 수 있습니다.

Windows 사용자는 CloudflareST.exe, Linux/Mac 사용자는 해당 버전을 다운로드합니다.

실행 방법(Windows):

# 두 번 클릭하거나 명령줄에서 실행
CloudflareST.exe

도구가 수백 개의 Cloudflare IP를 자동으로 테스트하며 약 5~10분이 걸립니다. 완료되면 다음과 같이 가장 빠른 IP 목록을 출력합니다.

IP 주소          지연 시간   다운로드 속도
104.16.160.10   68ms       15.2MB/s
172.64.32.5     75ms       14.8MB/s
104.23.240.28   82ms       13.9MB/s

첫 번째 IP(지연 시간이 가장 낮은 주소)를 기록합니다.

2단계: DNS 레코드 변경

중요한 사전 조건: 도메인의 DNS를 Cloudflare에서 호스팅하면 안 되며 알리바바 클라우드, DNSPod 등 다른 서비스 제공업체를 사용해야 합니다. 현재 Cloudflare DNS를 사용한다면 먼저 이전해야 합니다.

왜 그럴까요? Cloudflare DNS는 Anycast를 강제로 사용하므로 A 레코드를 바꿔도 효과가 없습니다.

설정 방법(DNSPod 예시):

1. DNS 서비스 제공업체에 로그인

2. 도메인을 찾아 A 레코드 추가 또는 수정:

   • 호스트 레코드: @(루트 도메인) 또는 www
   • 레코드 유형: A
   • 레코드 값: 104.16.160.10(측정한 최적 IP)
   • TTL: 600(10분)

3. 저장하고 적용될 때까지 대기(일반적으로 5~10분)

3단계: 효과 검증

DNS가 적용되면 17ce.com에서 다시 측정합니다. 속도가 뚜렷하게 개선되어야 합니다.

위험 안내(중요):

2025년 1월 Cloudflare는 서비스 약관을 업데이트했으며 ‘남용’ 행위를 제한하거나 제재할 수 있다는 조항을 포함했습니다. 최적 IP 사용이 이에 해당하는지는 명확하지 않지만 위험은 존재합니다.

권장 사항:

• 개인 블로그, 소규모 프로젝트: 사용할 수 있으며 위험이 크지 않음
• 상용 사이트, 트래픽이 많은 프로젝트: 신중하게 접근하고 방법 2(CNAME) 또는 방법 3(회선별 DNS) 권장
• 정기 확인: IP가 무효화될 수 있으므로 1~2개월마다 다시 측정해 교체

자주 발생하는 문제:

1. DNS를 바꿨지만 적용되지 않음

   • 브라우저 캐시를 지우거나 시크릿 모드로 테스트
   • nslookup yourdomain.com 명령으로 DNS가 실제로 적용되었는지 확인

2. 최적 IP가 일정 시간이 지나 다시 느려짐

   • IP가 무효화되었을 수 있으므로 다시 측정해 새 주소로 교체

3. 일부 지역은 빠르고 일부 지역은 느림

   • 통신사(China Telecom/China Unicom/China Mobile)마다 가장 빠른 IP가 다르며 방법 3(회선별 DNS)으로 해결 가능

방법 2: 최적 CNAME 도메인 사용(무료, 더 안정적)

직접 IP를 측정하기 번거롭거나 IP가 자주 무효화되는 일이 걱정된다면 공개 최적 CNAME 도메인을 사용할 수 있습니다. 다른 사람이 최적 IP를 관리하고 정기적으로 업데이트하므로 훨씬 간편합니다.

작동 원리:

일부 개발자나 조직은 정기적으로 테스트해 최신 최적 IP를 가리키는 도메인을 운영합니다. 자신의 도메인에서 해당 도메인으로 CNAME만 설정하면 가속 효과를 얻을 수 있습니다.

1단계: 공개 CNAME 선택

자주 사용되는 공개 최적화 도메인(예시일 뿐이므로 사용 전에 직접 테스트하세요):

• cdn.cloudflare.quest
• cf.xiu2.xyz

주의: 공개 CNAME은 언제든 작동을 멈출 수 있습니다. 관련 커뮤니티나 Telegram 그룹에 참여해 현재 사용할 수 있는 도메인을 확인하는 것이 좋습니다.

2단계: DNS 레코드 변경

마찬가지로 도메인 DNS가 Cloudflare에 있으면 안 됩니다. 설정 방법은 다음과 같습니다(DNSPod 예시).

1. DNS 서비스 제공업체에 로그인

2. CNAME 레코드 추가:

   • 호스트 레코드: @ 또는 www
   • 레코드 유형: CNAME
   • 레코드 값: cdn.cloudflare.quest(선택한 공개 도메인)
   • TTL: 600

3. 저장하고 적용될 때까지 대기

3단계: 발생할 수 있는 403 오류 해결

CNAME 방식에서는 403 Forbidden 오류가 발생하기 쉽습니다. Cloudflare 시스템에 등록되지 않은 도메인이 Cloudflare IP를 통해 접속하는 것을 감지하기 때문입니다.

해결 방법:

1. 도메인 DNS가 아직 Cloudflare에 있다면 다른 곳으로 이전
2. Cloudflare Dashboard에서 해당 사이트를 삭제
3. 몇 분 기다린 뒤 다시 접속하면 정상적으로 작동해야 함

4단계: 효과 검증

CNAME이 적용되면 nslookup yourdomain.com으로 공개 CNAME 도메인을 가리키는지 확인하고 속도를 측정합니다.

장단점 비교:

• 장점:

  • 직접 IP를 측정하지 않아도 되어 간편함
  • 운영자가 정기적으로 업데이트하므로 더 안정적임
  • 직접 최적 IP를 사용할 때보다 위험이 조금 낮음

• 단점:

  • 서드파티에 의존하므로 서비스가 중단되면 함께 영향을 받음
  • 자신에게 맞춰 측정한 주소가 아니므로 직접 찾은 IP보다 느릴 수 있음

권장 사항: 최적화는 필요하지만 복잡한 설정을 원하지 않는 사용자에게 적합하며 비용 대비 효과가 좋습니다.

KiloClaw - 기업용 매니지드 OpenClaw, AI Agent 오케스트레이션 및 스마트 라우팅

시작하기 →광고

방법 3: 회선별 DNS(유료 DNS 필요, 가장 좋은 효과)

효과가 가장 좋은 최종적인 방법이지만 약간의 비용이 듭니다. 중국 내외 사용자가 모두 많고 속도가 중요한 사이트에 적합합니다.

핵심 아이디어:

사용자 지역에 따라 서로 다른 IP 주소를 반환합니다. 예를 들면 다음과 같습니다.

• 중국 China Telecom 사용자 → China Telecom 최적 IP로 연결
• 중국 China Unicom 사용자 → China Unicom 최적 IP로 연결
• 해외 사용자 → Cloudflare 기본 주소(또는 your-project.pages.dev)로 연결

모든 사용자가 가장 좋은 경로로 접속하게 됩니다.

필요한 도구:

스마트 DNS를 지원하는 서비스 제공업체가 필요합니다.

• DNSPod(Tencent Cloud 서비스이며 개인 플랜에 기본 기능 무료 제공)
• Alibaba Cloud DNS(유료지만 기능이 강력함)
• Cloudflare DNS(중국 내 회선별 DNS를 지원하지 않아 이 상황에는 적합하지 않음)

설정 방법(DNSPod 예시):

1. 통신사별 최적 IP 테스트

   CloudflareSpeedTest 도구를 China Telecom, China Unicom, China Mobile 네트워크에서 각각 실행하고 가장 빠른 IP를 기록합니다. 다음처럼 자주 쓰이는 IP 대역을 참고할 수도 있지만 직접 측정하는 편이 더 정확합니다.

   • China Telecom: 104.16.160.0/24
   • China Unicom: 104.23.240.0/24
   • China Mobile: 172.64.32.0/24

2. 회선별 DNS 설정

   DNSPod에 로그인해 A 레코드를 여러 개 추가하고 각 레코드에 서로 다른 ‘회선 유형’을 설정합니다.

   레코드 1:
   - 호스트 레코드: @
   - 레코드 유형: A
   - 회선 유형: China Telecom
   - 레코드 값: 104.16.160.10
   
   레코드 2:
   - 호스트 레코드: @
   - 레코드 유형: A
   - 회선 유형: China Unicom
   - 레코드 값: 104.23.240.5
   
   레코드 3:
   - 호스트 레코드: @
   - 레코드 유형: A
   - 회선 유형: China Mobile
   - 레코드 값: 172.64.32.8
   
   레코드 4(해외 사용자를 위한 기본 회선):
   - 호스트 레코드: @
   - 레코드 유형: CNAME
   - 회선 유형: 기본
   - 레코드 값: your-project.pages.dev

3. 저장하고 적용될 때까지 대기

효과:

회선별 DNS를 설정하면 중국의 각 통신사 사용자는 가장 빠른 노드에 접속하고 해외 사용자는 기본 Cloudflare 경로를 이용하므로 양쪽을 모두 고려할 수 있습니다.

비용:

• DNSPod 개인 플랜: 무료(기본 회선별 DNS 지원)
• DNSPod 프로 플랜: 월 20위안(더 세밀한 지역 구분 지원)
• Alibaba Cloud DNS: 쿼리 수에 따라 과금되며 소규모 사이트는 월 몇 위안 정도

권장 사항: 사이트의 월 방문 수가 10,000회를 넘는다면 이 정도 비용을 투자할 가치가 있으며 사용자 경험도 크게 개선됩니다.

최적화 효과 비교와 모니터링

각 방법의 실제 효과를 데이터로 비교해 보겠습니다.

최적화 전후 속도 비교(베이징 China Telecom 네트워크에서 한 블로그를 실제 측정):

최적화 후 속도는 3~5배 향상되어 사용자 경험이 완전히 달라집니다.

장기 모니터링 방법:

최적화가 끝난 뒤에도 IP가 무효화될 수 있으므로 정기적으로 모니터링해야 합니다.

권장 도구:

1. UptimeRobot(uptimerobot.com)

   • 사이트 50개까지 무료로 모니터링
   • 5분마다 ping하고 다운되면 이메일 알림 전송
   • 응답 시간 추세 확인 가능

2. Cloudflare Analytics

   • Cloudflare Dashboard에 기본 포함되며 무료
   • 접속 출처, 대역폭 사용량, 오류율 확인
   • 중국 내 구체적인 지연 시간은 볼 수 없다는 단점이 있음

3. Better Uptime(betteruptime.com)

   • 유료지만 무료 버전도 제공
   • 공개 상태 페이지를 만들어 사용자 신뢰를 높일 수 있음

최적 IP를 조정해야 하는 시점:

1~2개월마다 확인하도록 알림을 설정합니다.

1. 17ce.com에서 속도를 측정해 지연 시간이 크게 늘었는지 확인
2. 지연 시간이 200ms를 넘으면 CloudflareSpeedTest를 다시 실행해 새 IP로 교체
3. DNS 레코드 업데이트

제 경험으로는 IP가 약 2~3개월마다 한 번씩 크게 변동합니다. 그때 교체하면 됩니다.

결론

핵심 내용을 정리해 보겠습니다.

배포 과정에서 Cloudflare Pages를 이용한 Astro 배포는 매우 간단합니다. 순수 정적 사이트는 GitHub를 연결하면 몇 분이면 끝납니다. SSR이 필요하다면 npx astro add cloudflare로 한 번에 설정하고 hybrid 또는 server 모드를 선택해 정적 페이지와 동적 페이지를 유연하고 효율적으로 구성할 수 있습니다.

SSR 설정에서는 다음 사항을 기억하세요.

• 90%의 상황에는 hybrid 모드가 가장 적합함
• KV/D1/R2가 필요하면 wrangler.jsonc에서 binding 설정
• 로컬 개발에는 .dev.vars, 프로덕션 환경 변수는 Dashboard 사용
• Hydration 오류가 발생하면 Auto Minify 끄기

중국 내 접속 최적화에는 각기 다른 상황에 맞는 세 가지 방법이 있습니다.

• 방법 1(최적 IP): 효과가 가장 좋고 무료지만 정기적인 유지 관리와 어느 정도 위험이 있음
• 방법 2(공개 CNAME): 간편하고 무료이며 효과는 보통이어서 복잡한 설정을 원하지 않는 사용자에게 적합
• 방법 3(회선별 DNS): 소액 비용이 들지만 중국 내외 사용자를 모두 고려할 수 있는 최종적인 방법

권장 선택:

• 개인 블로그, 트래픽이 적은 사이트 → 방법 1 또는 방법 2
• 트래픽이 많고 사용자 경험을 중시하는 사이트 → 방법 3
• 상용 프로젝트 → 최적 IP를 신중하게 사용하고 방법 3이나 기본 속도를 우선 고려

다음 단계:

아직 시작하지 않았다면 지금 바로 다음과 같이 진행할 수 있습니다.

1. Cloudflare 계정을 만들고 정적 배포를 시험해 속도 확인
2. 중국 내 접속이 느리다면 먼저 17ce.com에서 측정한 뒤 최적화 여부 결정
3. 최적화한 뒤 알림을 설정해 IP가 무효화되지 않았는지 정기적으로 확인

다음 학습 주제:

배포는 첫 단계일 뿐이며 Cloudflare 생태계에는 더 많은 기능이 있습니다.

• Workers KV: 캐시와 session에 적합한 키-값 저장소
• D1: 엣지에서 바로 실행되는 SQLite 데이터베이스
• R2: AWS S3에 대응하는 객체 스토리지이며 무료 할당량도 큼
• Pages Functions: Pages에서 바로 서버리스 함수를 작성

모두 Astro와 원활하게 연동할 수 있으므로 차근차근 살펴볼 수 있습니다.

이 글이 도움이 되었다면 댓글에서 배포 경험이나 겪었던 문제를 공유해 주세요. 함께 의견을 나눠보면 좋겠습니다.