[태그:] 연재:Cloudflare 완전 정복: 입문부터 2026 AI 에이전트까지

이 글은 「Cloudflare 완전 정복」 시리즈 3회입니다. 2회에서 도메인을 Cloudflare DNS에 연결하고 CDN 캐시까지 설정했다면, 오늘은 그 위에 HTTPS라는 자물쇠를 채울 차례입니다.

왜 2026년에 HTTPS를 다시 이야기하는가

“아직도 HTTPS 설정 글이 필요해?” 하고 물을 수 있습니다. 하지만 현실은 조금 다릅니다. 2026년 현재 Chrome은 HTTP 사이트에 접속하면 주소창에 “주의 요함”이라는 경고를 띄우고, Google 검색 순위에서도 HTTPS는 사실상 필수 요소입니다. 특히 블로그나 개인 프로젝트를 운영하는 분들이 많이 놓치는 부분이 있습니다. 인증서를 설치했다고 끝이 아니라는 것이죠.

인증서만 걸어놓고 보안 헤더를 설정하지 않으면, 클릭재킹(Clickjacking), MIME 스니핑, 다운그레이드 공격 같은 위협에 여전히 노출됩니다. Cloudflare를 쓰면 이 모든 것을 무료로, 클릭 몇 번으로 해결할 수 있습니다. 오늘 이 글 하나로 인증서 발급부터 보안 헤더 자동화까지 깔끔하게 정리하겠습니다.

Cloudflare SSL/TLS — 구조부터 이해하기

Cloudflare의 SSL/TLS를 제대로 설정하려면, 먼저 트래픽이 어떤 구간을 지나가는지 이해해야 합니다. 크게 두 구간으로 나뉩니다.

• 브라우저 ↔ Cloudflare 엣지: 방문자가 여러분의 도메인에 접속할 때, 가장 가까운 Cloudflare 데이터센터까지의 구간입니다.
• Cloudflare 엣지 ↔ 원본 서버: Cloudflare가 여러분의 실제 서버(NAS, VPS, 호스팅)에 콘텐츠를 요청하는 구간입니다.

많은 분이 첫 번째 구간만 생각하고 “HTTPS가 걸렸네” 하고 넘어갑니다. 하지만 두 번째 구간이 HTTP로 열려 있으면 중간자 공격에 취약해집니다. Cloudflare는 이 두 구간을 어떻게 처리할지 네 가지 암호화 모드로 나눠서 제공합니다.

SSL/TLS 암호화 모드 4가지

① Off (암호화 없음)

모든 구간이 HTTP입니다. 2026년에 이 설정을 쓸 이유는 전혀 없습니다. Cloudflare 대시보드에서도 권장하지 않는다는 경고가 뜹니다.

② Flexible (유연)

브라우저와 Cloudflare 사이만 HTTPS이고, Cloudflare에서 원본 서버까지는 HTTP입니다. 언뜻 보면 편리합니다. 원본 서버에 인증서를 설치하지 않아도 방문자 브라우저에는 자물쇠가 뜨니까요. 하지만 Cloudflare와 원본 서버 사이 구간이 평문이라는 근본적인 문제가 있습니다. 워드프레스처럼 리다이렉트 루프가 생기는 경우도 잦습니다. 임시 테스트 외에는 사용하지 마세요.

③ Full (전체)

양쪽 모두 HTTPS입니다. 다만 원본 서버의 인증서가 자체 서명(Self-signed)이어도 허용합니다. Cloudflare가 원본 인증서의 유효성을 검증하지 않으므로, 중간자가 가짜 인증서를 제시해도 Cloudflare가 이를 걸러내지 못합니다.

④ Full (Strict) — 권장

양쪽 모두 HTTPS이며, 원본 서버의 인증서가 신뢰할 수 있는 CA에서 발급되었거나 Cloudflare Origin CA 인증서여야 합니다. 가장 안전한 모드이고, 이 글에서 안내하는 최종 목표입니다.

어떤 모드를 골라야 할까 — 상황별 추천

• 호스팅 업체(카페24, 가비아 등) 사용: 대부분 Let’s Encrypt 인증서를 제공하므로 → Full (Strict)
• Synology NAS / 자가 서버: Cloudflare Origin CA를 설치하면 → Full (Strict)
• 인증서 설치가 불가능한 환경: 최소한 → Full (Flexible은 피할 것)

실전 설정 1 — Cloudflare 대시보드에서 SSL/TLS 켜기

2회에서 도메인을 이미 Cloudflare에 연결했다고 가정합니다. 아직이라면 2회 가이드를 먼저 따라 주세요.

Step 1: 암호화 모드를 Full (Strict)로 변경

Cloudflare 대시보드에 로그인한 뒤, 해당 도메인을 선택합니다.

• 왼쪽 메뉴에서 SSL/TLS → Overview로 이동합니다.
• 상단의 암호화 모드에서 Full (strict)를 클릭합니다.
• 변경은 즉시 적용됩니다. 별도 저장 버튼은 없습니다.

이 시점에서 원본 서버에 유효한 인증서가 없으면 526 에러가 발생합니다. 당황하지 마세요. 바로 다음 단계에서 원본 인증서를 만들겠습니다.

Step 2: Cloudflare Origin CA 인증서 발급

Cloudflare는 원본 서버 전용 무료 인증서를 제공합니다. 유효 기간은 최대 15년이며, Cloudflare를 통하지 않는 직접 접속에서는 신뢰되지 않지만, Cloudflare 프록시 뒤에서는 완벽하게 작동합니다.

• SSL/TLS → Origin Server로 이동합니다.
• Create Certificate 버튼을 클릭합니다.
• 기본 설정 그대로 두면 됩니다:
  • Private key type: RSA (2048)
  • Hostnames: *.example.com과 example.com (와일드카드 포함)
  • Certificate Validity: 15 years
• Create를 누르면 Origin Certificate와 Private Key가 화면에 표시됩니다.

⚠️ Private Key는 이 화면을 벗어나면 다시 볼 수 없습니다. 반드시 복사해서 안전한 곳에 저장하세요.

Step 3: 원본 서버에 인증서 설치 — Synology NAS 편

Synology NAS DS+925에 Cloudflare Origin CA 인증서를 설치하는 실전 명령어입니다.

방법 A — DSM 웹 UI 사용 (권장)

• DSM에 로그인 → 제어판 → 보안 → 인증서 탭으로 이동합니다.
• 추가 버튼 → 새 인증서 추가 → 인증서 가져오기를 선택합니다.
• 아까 복사한 파일을 입력합니다:
  • 개인 키: Private Key 내용을 origin-key.pem 파일로 저장해 업로드
  • 인증서: Origin Certificate 내용을 origin-cert.pem 파일로 저장해 업로드
  • 중간 인증서: Cloudflare Origin CA 루트 인증서 (아래 명령어로 다운로드)

방법 B — SSH 명령어 사용

Synology NAS에 SSH로 접속한 뒤 다음 명령어를 실행합니다.

# Cloudflare Origin CA 루트 인증서(RSA) 다운로드
curl -o /tmp/origin_ca_rsa_root.pem \
  https://developers.cloudflare.com/ssl/static/origin_ca_rsa_root.pem

# 인증서 파일 준비 (대시보드에서 복사한 내용을 붙여넣기)
cat > /tmp/origin-cert.pem <<'EOF'
-----BEGIN CERTIFICATE-----
(여기에 Origin Certificate 붙여넣기)
-----END CERTIFICATE-----
EOF

cat > /tmp/origin-key.pem <<'EOF'
-----BEGIN PRIVATE KEY-----
(여기에 Private Key 붙여넣기)
-----END PRIVATE KEY-----
EOF

# 인증서 정보 확인
openssl x509 -in /tmp/origin-cert.pem -noout -subject -dates

SSH로 파일을 준비한 뒤, DSM 웹 UI에서 인증서 가져오기로 세 파일을 업로드하면 됩니다. 인증서를 기본 인증서로 설정하면 DSM 웹 인터페이스와 역방향 프록시에 자동 적용됩니다.

Step 3-B: Mac Studio / 일반 리눅스 서버에 설치

Mac Studio에서 nginx를 원본 서버로 사용하는 경우입니다.

# 인증서 디렉토리 생성
sudo mkdir -p /etc/nginx/ssl

# 인증서 파일 저장 (대시보드에서 복사한 내용)
sudo nano /etc/nginx/ssl/origin-cert.pem
sudo nano /etc/nginx/ssl/origin-key.pem

# Cloudflare Origin CA 루트 인증서 다운로드
sudo curl -o /etc/nginx/ssl/origin_ca_rsa_root.pem \
  https://developers.cloudflare.com/ssl/static/origin_ca_rsa_root.pem

# nginx 설정 (server 블록에 추가)
# /etc/nginx/sites-available/default 또는 해당 설정 파일
cat <<'NGINX'
server {
    listen 443 ssl;
    server_name example.com *.example.com;

    ssl_certificate     /etc/nginx/ssl/origin-cert.pem;
    ssl_certificate_key /etc/nginx/ssl/origin-key.pem;
    ssl_client_certificate /etc/nginx/ssl/origin_ca_rsa_root.pem;

    # TLS 1.2 이상만 허용
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    location / {
        root /var/www/html;
        index index.html;
    }
}
NGINX

# 설정 검증 및 재시작
sudo nginx -t
sudo systemctl reload nginx

이렇게 하면 Cloudflare ↔ 원본 서버 구간도 암호화되어 Full (Strict) 모드가 정상 작동합니다.

Universal SSL — 무료 인증서의 실체

Cloudflare에 도메인을 등록하면 Universal SSL이라는 무료 인증서가 자동으로 발급됩니다. 2회에서 DNS를 연결한 순간, 사실 이미 브라우저 쪽(엣지) 인증서는 활성화된 상태입니다.

Universal SSL의 특징

• 발급 비용: 완전 무료 (Free 플랜 포함)
• 인증서 종류: DV(Domain Validation) 인증서
• 발급 CA: Google Trust Services 또는 Let’s Encrypt (Cloudflare가 자동 선택)
• 갱신: Cloudflare가 만료 전 자동 갱신. 사용자가 신경 쓸 필요 없음
• 와일드카드: *.example.com 포함 (Free 플랜에서도 제공)
• 적용 범위: Cloudflare 프록시(오렌지 구름)가 켜진 레코드에만 적용

무료 플랜에서도 와일드카드 인증서를 제공한다는 점이 핵심입니다. 일반적으로 와일드카드 인증서는 유료이거나 설정이 번거로운데, Cloudflare는 도메인만 연결하면 자동으로 처리합니다.

Edge Certificate vs Origin Certificate 비교

• Edge Certificate (Universal SSL): 브라우저 ↔ Cloudflare 구간. 자동 발급·갱신. 방문자가 보는 인증서.
• Origin Certificate: Cloudflare ↔ 원본 서버 구간. 수동 발급(15년 유효). Cloudflare를 거치지 않는 직접 접속에서는 신뢰 안 됨.

두 인증서는 역할이 다릅니다. 양쪽 모두 설정해야 end-to-end 암호화가 완성됩니다.

실전 설정 2 — HTTPS 강제 리다이렉트

인증서를 설치했다고 해서 모든 방문자가 HTTPS로 접속하는 건 아닙니다. http://example.com으로 직접 타이핑하는 사용자도 있고, 오래된 북마크나 외부 링크가 HTTP인 경우도 있습니다. 두 가지 설정으로 이 문제를 해결합니다.

Always Use HTTPS

• SSL/TLS → Edge Certificates에서 Always Use HTTPS를 On으로 토글합니다.
• HTTP로 들어오는 모든 요청을 301 리다이렉트로 HTTPS로 보냅니다.
• 원본 서버에 도달하기 전에 Cloudflare 엣지에서 처리하므로, 서버 부하가 전혀 없습니다.

Automatic HTTPS Rewrites

• 같은 페이지에서 Automatic HTTPS Rewrites를 On으로 토글합니다.
• HTML 안에 http://로 시작하는 리소스 링크(이미지, CSS, JS 등)를 자동으로 https://로 바꿔줍니다.
• 이른바 Mixed Content(혼합 콘텐츠) 문제를 방지합니다. HTTPS 페이지에서 HTTP 리소스를 로드하면 브라우저가 경고를 띄우거나 차단하는데, 이 기능이 자동으로 해결합니다.

두 설정 모두 무료 플랜에서 사용 가능하며, 켜는 데 10초면 충분합니다.

실전 설정 3 — TLS 최소 버전 올리기

TLS 1.0과 1.1은 이미 보안 취약점이 알려진 오래된 프로토콜입니다. 대부분의 최신 브라우저는 TLS 1.2 이상만 지원하므로, 구버전을 허용할 이유가 없습니다.

• SSL/TLS → Edge Certificates에서 Minimum TLS Version을 TLS 1.2로 설정합니다.
• 보안이 특히 중요한 서비스라면 TLS 1.3으로 올릴 수도 있지만, 일부 구형 클라이언트 호환성 문제가 있을 수 있으므로 TLS 1.2가 현실적인 최선입니다.

TLS 1.3의 장점

TLS 1.3은 Cloudflare에서 기본 활성화되어 있습니다. 클라이언트가 지원하면 자동으로 1.3을 사용합니다.

• 핸드셰이크 속도: TLS 1.2의 2-RTT에서 1-RTT로 단축 (0-RTT 재접속도 지원)
• 보안: 취약한 암호 스위트 제거, Forward Secrecy 필수화
• 성능: 첫 페이지 로드가 체감 가능하게 빨라짐

보안 헤더 — HTTPS 다음에 반드시 해야 할 것

여기서부터가 오늘의 핵심입니다. 인증서를 설치하고 HTTPS를 강제한 것만으로는 절반만 한 겁니다. 보안 헤더(Security Headers)는 브라우저에게 “이 사이트를 어떻게 다뤄야 하는지” 지시하는 HTTP 응답 헤더입니다.

필수 보안 헤더 6가지

1. HSTS (Strict-Transport-Security)

브라우저에게 “이 사이트는 앞으로 지정된 기간 동안 반드시 HTTPS로만 접속해라”고 지시합니다. HTTP → HTTPS 리다이렉트조차 거치지 않고, 브라우저 자체에서 HTTPS로 바꿔 접속합니다.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

• max-age=31536000: 1년(초 단위). 브라우저가 이 기간 동안 HTTPS만 사용.
• includeSubDomains: 모든 서브도메인에도 적용.
• preload: HSTS Preload List에 등록 요청. 등록되면 브라우저가 첫 방문부터 HTTPS를 강제합니다.

⚠️ HSTS 주의사항: 한번 설정하면 되돌리기 어렵습니다. HTTPS에서 HTTP로 다시 돌아가야 할 상황이 없다면(거의 없겠지만) 적용하세요. max-age를 처음엔 86400(1일)로 시작해서 문제가 없으면 점진적으로 늘리는 것도 방법입니다.

2. X-Content-Type-Options

X-Content-Type-Options: nosniff

브라우저가 응답의 MIME 타입을 “추측”하지 못하게 합니다. 예를 들어 공격자가 악성 스크립트를 이미지 파일로 위장해 업로드하면, 브라우저가 MIME 스니핑으로 이를 실행할 수 있습니다. nosniff는 이를 차단합니다.

3. X-Frame-Options

X-Frame-Options: SAMEORIGIN

사이트가 다른 페이지의 <iframe>에 삽입되는 것을 제한합니다. 클릭재킹 공격 방어의 기본입니다. DENY(완전 차단)와 SAMEORIGIN(같은 출처만 허용) 중 선택할 수 있습니다.

4. X-XSS-Protection

X-XSS-Protection: 1; mode=block

구형 브라우저의 내장 XSS 필터를 활성화합니다. 최신 브라우저는 CSP로 대체하고 있지만, 하위 호환성 차원에서 설정해두면 좋습니다.

5. Referrer-Policy

Referrer-Policy: strict-origin-when-cross-origin

사용자가 링크를 클릭해 다른 사이트로 이동할 때, 어디에서 왔는지(Referrer) 정보를 얼마나 전달할지 제어합니다. strict-origin-when-cross-origin은 같은 출처에서는 전체 URL을, 다른 출처에서는 도메인만 전달합니다.

6. Content-Security-Policy (CSP)

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; upgrade-insecure-requests

가장 강력하면서도 설정이 까다로운 헤더입니다. 어떤 출처의 리소스(스크립트, 스타일, 이미지 등)를 로드할 수 있는지 세밀하게 제어합니다. XSS 공격의 근본적인 방어선이 됩니다.

위 예시는 기본적인 정책입니다. Google Analytics, 외부 폰트, 광고 스크립트 등을 사용한다면 해당 도메인을 허용 목록에 추가해야 합니다. 처음엔 Report-Only 모드로 시작해 차단되는 리소스를 확인한 뒤 본격 적용하는 것이 안전합니다.

Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report

Cloudflare에서 보안 헤더 자동화하기

보안 헤더를 적용하는 방법은 크게 세 가지입니다. 원본 서버에서 설정하거나, Cloudflare에서 설정하거나, 양쪽을 조합하거나. Cloudflare를 쓰고 있다면 Cloudflare 쪽에서 일괄 관리하는 것이 가장 효율적입니다.

방법 1 — Cloudflare 대시보드: HSTS 설정

HSTS는 Cloudflare 대시보드에서 직접 켤 수 있습니다.

• SSL/TLS → Edge Certificates로 이동합니다.
• HTTP Strict Transport Security (HSTS) 섹션에서 Enable HSTS를 클릭합니다.
• 권장 설정:
  • Max Age: 12 months (최대)
  • Include subdomains: On
  • Preload: On (HSTS Preload List 등록 의향이 있을 때)
  • No-Sniff: On (X-Content-Type-Options: nosniff 자동 추가)
• 경고 문구를 확인하고 Save를 누릅니다.

이것만으로 HSTS와 X-Content-Type-Options 두 가지가 한번에 적용됩니다.

방법 2 — Transform Rules로 나머지 헤더 추가

HSTS 외의 보안 헤더는 Cloudflare의 Transform Rules (HTTP Response Header Modification)로 추가합니다. 무료 플랜에서 최대 10개의 규칙을 만들 수 있습니다.

• Rules → Transform Rules로 이동합니다.
• Modify Response Header 탭을 선택합니다.
• Create Rule을 클릭합니다.

아래 설정으로 규칙 하나에 여러 헤더를 묶어서 추가합니다.

Rule name: Security Headers

When incoming requests match: All incoming requests (모든 요청에 적용)

Then: 아래 헤더들을 각각 Set static으로 추가합니다.

• X-Frame-Options → SAMEORIGIN
• X-XSS-Protection → 1; mode=block
• Referrer-Policy → strict-origin-when-cross-origin
• Permissions-Policy → camera=(), microphone=(), geolocation=()
• Content-Security-Policy → 사이트에 맞는 정책 (아래 예시 참조)

워드프레스 블로그용 CSP 예시:

default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' *.googleapis.com *.gstatic.com *.google-analytics.com *.googletagmanager.com; style-src 'self' 'unsafe-inline' *.googleapis.com; img-src 'self' data: https:; font-src 'self' *.gstatic.com *.googleapis.com; connect-src 'self' *.google-analytics.com *.analytics.google.com *.googletagmanager.com; frame-src 'self' *.youtube.com *.youtube-nocookie.com; upgrade-insecure-requests

정적 사이트(Hugo, Next.js 등)용 CSP 예시:

default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; upgrade-insecure-requests

Deploy를 누르면 즉시 적용됩니다.

방법 3 — Cloudflare API로 자동화 (고급)

여러 도메인을 관리하거나, 인프라를 코드로 관리(IaC)하고 싶다면 Cloudflare API를 사용할 수 있습니다.

# Cloudflare API로 Transform Rule 생성
# API 토큰 생성: Cloudflare 대시보드 → My Profile → API Tokens
# 필요 권한: Zone.Transform Rules (Edit)

ZONE_ID="your-zone-id"
API_TOKEN="your-api-token"

curl -X POST \
  "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/rulesets/phases/http_response_headers_transform/entrypoint" \
  -H "Authorization: Bearer ${API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{
    "rules": [
      {
        "expression": "true",
        "description": "Security Headers",
        "action": "rewrite",
        "action_parameters": {
          "headers": {
            "X-Frame-Options": {
              "operation": "set",
              "value": "SAMEORIGIN"
            },
            "X-Content-Type-Options": {
              "operation": "set",
              "value": "nosniff"
            },
            "X-XSS-Protection": {
              "operation": "set",
              "value": "1; mode=block"
            },
            "Referrer-Policy": {
              "operation": "set",
              "value": "strict-origin-when-cross-origin"
            },
            "Permissions-Policy": {
              "operation": "set",
              "value": "camera=(), microphone=(), geolocation=()"
            }
          }
        }
      }
    ]
  }'

이 API 호출 한 번으로 모든 보안 헤더가 설정됩니다. CI/CD 파이프라인에 넣어두면 도메인 추가 시 자동 적용도 가능합니다.

설정 검증 — 내 사이트는 안전한가

설정을 마쳤으면 반드시 확인해야 합니다. 세 가지 방법을 소개합니다.

검증 1: 브라우저 개발자 도구

Chrome에서 사이트에 접속한 뒤 F12 → Network 탭을 엽니다. 페이지의 메인 요청을 클릭하고 Response Headers를 확인합니다. 위에서 설정한 헤더들이 보이면 성공입니다.

검증 2: 터미널 명령어

# curl로 응답 헤더 확인 (Synology NAS 또는 Mac Studio 터미널에서)
curl -I https://example.com

# 출력 예시에서 확인할 항목:
# strict-transport-security: max-age=31536000; includeSubDomains; preload
# x-content-type-options: nosniff
# x-frame-options: SAMEORIGIN
# x-xss-protection: 1; mode=block
# referrer-policy: strict-origin-when-cross-origin

검증 3: 온라인 스캐너

보안 헤더 전문 스캐너에서 종합 점수를 확인합니다.

• securityheaders.com: 무료. A+ 등급이 목표입니다. 위의 6가지 헤더를 모두 설정하면 A+ 달성 가능.
• SSL Labs (ssllabs.com/ssltest): SSL/TLS 설정 전반을 심층 분석. A+ 등급이 목표.
• Cloudflare SSL/TLS Recommender: 대시보드 SSL/TLS 탭에서 자동 권장 사항을 확인.

securityheaders.com에서 A+ 등급을 받았다면, 보안 헤더 설정은 완벽합니다.

Synology NAS 홈랩 실전 — 원본 서버 보안 강화

Cloudflare 엣지에서 보안 헤더를 추가했더라도, Cloudflare 프록시를 거치지 않는 직접 접속(내부망 등)을 대비해 원본 서버에도 기본 헤더를 설정하는 것이 좋습니다.

Synology DSM 역방향 프록시에서 헤더 추가

DSM의 역방향 프록시는 웹 UI에서 커스텀 헤더를 추가하는 기능이 제한적입니다. nginx 설정을 직접 수정해야 합니다.

# SSH로 Synology NAS 접속 후
# 역방향 프록시 사용자 설정 파일 생성
sudo cat > /usr/local/etc/nginx/conf.d/security-headers.conf <<'EOF'
# Security Headers for Origin Server
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
EOF

# nginx 설정 테스트
sudo nginx -t

# nginx 재시작 (DSM 서비스 재시작)
sudo synoservice --restart nginx

⚠️ DSM 업데이트 시 이 설정이 초기화될 수 있으므로, 작업 스케줄러에 복원 스크립트를 등록해두는 것이 좋습니다.

Authenticated Origin Pulls — 원본 접근 제한

보안을 한 단계 더 올리려면 Authenticated Origin Pulls를 활성화합니다. Cloudflare가 원본 서버에 접속할 때 클라이언트 인증서를 제시하도록 하여, Cloudflare를 통하지 않는 모든 접근을 원천 차단합니다.

• Cloudflare 대시보드 → SSL/TLS → Origin Server → Authenticated Origin Pulls를 On으로 토글합니다.
• 원본 서버 nginx에 Cloudflare 클라이언트 인증서 검증을 추가합니다:

# Cloudflare의 클라이언트 인증서 (Authenticated Origin Pulls용)
curl -o /etc/nginx/ssl/cloudflare-origin-pull-ca.pem \
  https://developers.cloudflare.com/ssl/static/authenticated_origin_pull_ca.pem

# nginx 서버 블록에 추가
ssl_client_certificate /etc/nginx/ssl/cloudflare-origin-pull-ca.pem;
ssl_verify_client on;

이 설정이 활성화되면, 누군가가 원본 서버 IP를 알아내 직접 접속하더라도 Cloudflare 클라이언트 인증서가 없으므로 403 에러가 반환됩니다.

자주 하는 실수와 해결법

실수 1: ERR_TOO_MANY_REDIRECTS (리다이렉트 루프)

가장 흔한 문제입니다. 원인: SSL 모드가 Flexible인데, 원본 서버(워드프레스 등)에서도 HTTPS를 강제하는 경우. Cloudflare → 원본 서버로 HTTP 요청 → 원본이 HTTPS로 리다이렉트 → Cloudflare가 다시 HTTP로 → 무한 반복.

해결: SSL 모드를 Full 또는 Full (Strict)로 변경하면 즉시 해결됩니다.

실수 2: 526 Invalid SSL Certificate

Full (Strict) 모드인데 원본 서버에 유효한 인증서가 없는 경우. Cloudflare Origin CA를 설치하거나, Let’s Encrypt 인증서를 발급받으면 됩니다.

실수 3: Mixed Content 경고

페이지는 HTTPS인데 일부 리소스(이미지, 스크립트)가 HTTP로 로드되는 경우. Automatic HTTPS Rewrites를 켜면 대부분 해결됩니다. 그래도 남으면 소스 코드에서 http://를 https://로 직접 수정하세요.

실수 4: HSTS 설정 후 사이트 접속 불가

HSTS를 적용했는데 인증서에 문제가 생기면, 브라우저가 HTTP 폴백조차 허용하지 않아 사이트에 접속할 수 없게 됩니다. 처음에는 max-age를 짧게(1일 = 86400초) 설정하고, 안정성을 확인한 뒤 점진적으로 늘리세요.

실수 5: CSP가 너무 엄격해서 사이트가 깨짐

CSP를 설정하면 외부 서비스(Analytics, 광고, 폰트 등)의 스크립트가 차단될 수 있습니다. 반드시 Report-Only 모드로 먼저 테스트하세요.

월 비용 명세표

이번 회차에서 다룬 기능들의 플랜별 비용입니다.

기능	Free ($0)	Pro ($20/월)	Business ($200/월)
Universal SSL (Edge 인증서)	✅ 포함	✅ 포함	✅ 포함
Origin CA 인증서 (15년)	✅ 무료	✅ 무료	✅ 무료
Always Use HTTPS	✅	✅	✅
Automatic HTTPS Rewrites	✅	✅	✅
HSTS 설정	✅	✅	✅
TLS 1.3	✅	✅	✅
Minimum TLS Version 설정	✅	✅	✅
Transform Rules (헤더 수정)	✅ 10개	✅ 25개	✅ 50개
Authenticated Origin Pulls	✅	✅	✅
Advanced Certificate Manager	❌	$10/월 추가	$10/월 추가
Total Encryption Mode 설정	❌	✅	✅

핵심 결론: 이 글에서 다룬 모든 보안 설정은 무료 플랜으로 충분합니다. Advanced Certificate Manager(커스텀 인증서 업로드, 인증서 우선순위 제어)는 대부분의 개인/소규모 사이트에서는 불필요합니다.

한 장 요약 — 오늘 해야 할 체크리스트

여기까지 읽었으면 이제 직접 적용할 차례입니다. 순서대로 따라가세요.

• ☐ SSL/TLS 모드를 Full (Strict)로 변경
• ☐ Origin CA 인증서 발급 → 원본 서버에 설치
• ☐ Always Use HTTPS 켜기
• ☐ Automatic HTTPS Rewrites 켜기
• ☐ Minimum TLS Version을 1.2로 설정
• ☐ HSTS 활성화 (max-age 86400부터 시작)
• ☐ Transform Rules로 보안 헤더 5종 추가
• ☐ securityheaders.com에서 A+ 등급 확인
• ☐ (선택) Authenticated Origin Pulls 활성화

모두 무료입니다. 걸리는 시간은 Origin CA 인증서 설치까지 포함해도 30분 이내입니다.

다음 4회에서는 Cloudflare Pages로 정적 사이트를 무료 배포하는 방법을 다룹니다. GitHub 저장소 하나로 빌드·배포·커스텀 도메인·HTTPS까지 자동화되는 Jamstack 워크플로를 실습합니다.

이미지는 Leonardo AI 로 생성되었습니다.

이미지는 Claude AI 로 생성되었습니다.

---