Cloudflare Workers로 공유 호스팅 사이트의 서버 점검을 준비한 방법

공지에는 6시간 작업 창만 있고 실제 중단 시간은 없었습니다. 장애 메일을 기다리면 수동 공백이 생기고, DNS를 한 장의 점검 페이지로 바꾸면 콘텐츠와 브라우저 도구는 유지되지 않습니다.

HostArmada 티켓, Worker 판단, 스냅샷, 동일 존 재귀 문제, 무료 플랜 보호, SEO·광고·분석, 한계를 실제 구현 기준으로 정리했습니다.

시점 안내: 2026년 7월 18일 현재 예정 점검은 아직 진행되지 않았습니다. 결과는 강제 origin 실패, 비공개 staging, 전수 스냅샷 검사, 정상 라이브 통과 시험에서 얻었으며 실제 점검 창 결과가 아닙니다.

HostArmada 티켓이 확인해 준 내용

점검은 2026년 7월 22일 10:00~16:00 CDT였습니다. 6시간 연속 중단인지, 임시 이전이 가능한지, 영향 서비스, 모든 URL에 외부 503을 제공할 수 있는지, 복구와 크레딧을 질문했습니다.

에스컬레이션 후 6시간은 예약 창이지 확정 중단 시간이 아니며, 실제 장애는 짧을 전망이지만 하드웨어 변경·업데이트·검증 때문에 정확히 예측할 수 없다는 답을 받았습니다. 계정을 옮겼다가 되돌리면 DNS, 동기화, 메일, DB 일관성 위험이 커집니다.

영향 없는 서버의 임시 vhost와 점검 페이지, 시작/종료 때 수동 A 레코드 변경안도 제시했습니다. 외부 DNS는 계속 해석되지만 웹, DB, 메일, 패널은 중단됩니다. 백업과 복구 절차가 있고 크레딧은 실제 영향 뒤 검토합니다. 공지용으로 합리적이지만 수동이며 기능 연속성은 아닙니다.

That offer was fair for a maintenance notice. It was still manual and did not provide functional-site continuity, so we used it as the baseline to improve rather than portraying it as a provider failure.

검증 가능한 타임라인: 점검 메일부터 테스트된 연속성까지

호스팅 공지, 우리의 질문, 실제 구축·시험 결과, 아직 일어나지 않은 실제 이벤트를 구분합니다.

1. 2026년 7월 — 점검 메일

   Start Dock 공유 서버 공지는 7월 22일 10:00–16:00 CDT를 예약하고 CPU/RAM/SSD, 웹 보안/software, kernel, tmp/cache/log 정리, 일반 최적화를 적었으며 시작 후 되돌릴 수 없다고 설명했습니다.

2. 7월 16일 — 질문 에스컬레이션

   실제 downtime, 임시 이전, 외부 503, web/DB/email, backup, rollback, credit을 질문했습니다.

3. 7월 17일 — HostArmada 답변

   6시간은 창이고 중단은 짧을 가능성이 있으나 미정. 동기화 위험으로 이전을 거부하고 vhost+수동 A record를 제안했습니다.



4. 7월 17일 설계 선택, 18일 후속 메시지 전송

   상시 origin-first Worker, snapshot, private staging, collision 검사, 503, rollback을 선택했습니다.



5. 7월 17–18일 — 통제 시험

   1,514 page, 1,234 asset, 2,748 path 감사, 실패/통과, 재귀 수정, apex/www fail-open을 검증했습니다.

6. 7월 18일 — 준비 완료, 이벤트 전

   계층은 live·test 완료지만 22일 점검은 아직입니다. 실제 시간, traffic, 수익은 사후 증거가 필요합니다.

구조: 먼저 origin, 실패할 때만 스냅샷

Worker는 apex와 www 경로에 상시 존재하며 제한 시간으로 실제 origin을 확인합니다. 정상 응답은 변경 없이 전달되어 PHP, 세션, 헤더, 광고, 분석이 그대로 작동합니다.

네트워크 실패, timeout, 500/502/503/504 또는 520–527이면 같은 경로의 정적 자산을 찾습니다. GET/HEAD는 계속되고 이후 요청마다 origin을 재확인해 자동 복구합니다.

두 번째 PHP 스택이 아니므로 쓰기 DB 분리, 세션 충돌, 사후 데이터 조정을 피합니다.

요청 흐름

origin 자동 복구이후 요청마다 호스트를 재시도하고 정상 응답을 즉시 통과시킵니다.

호스팅 점검 페이지와 Worker 연속성

간단한 점검 의미만 필요하면 임시 페이지가 쉽습니다. 읽기 경로와 클라이언트 도구를 살리려면 준비와 검증이 필요한 Worker 스냅샷이 맞습니다.

장애 때 사용자와 크롤러가 받는 응답

페이지, 브라우저 도구, CSS, 스크립트, 이미지, 폰트는 작은 축소 운영 안내와 함께 복사본에서 제공되며 canonical과 구조화 데이터는 원래 URL을 유지합니다.

쓰기 작업은 성공한 척하지 않습니다. POST와 이용 불가 작업은 503 Service Unavailable, Retry-After: 300, Cache-Control: no-store를 반환합니다. RFC 9110의 임시 점검 의미에 맞습니다.

This distinction matters: returning a pretty 200 OK “maintenance” page for a failed form can mislead users and crawlers. Returning a controlled 503 for the unavailable action is both more honest and easier for clients to retry.

실제 fallback 판단표

스냅샷 구축과 검증

미공개 변경이 있는 로컬 PHP 대신 렌더링된 라이브 사이트를 크롤링했습니다. 1,514개 페이지, 1,234개 자체 자산, 최종 2,749개 파일 약 547.6 MB였고 모든 파일은 개별 제한 이내였습니다.

canonical과 schema를 유지하고 오래된 상대 경로는 복사본 안에서만 수정했습니다. 캡처 시 tracker를 제거하고 운영 Worker만 GA4, AdSense, 홈페이지 Clarity를 지연 삽입합니다. 비공개 staging은 추적 없이 noindex입니다.

TypeScript·단위·강제 origin 실패·인증 staging·브라우저·origin preview·전수 원격 감사를 수행했고 공개 페이지/자산 2,748개 경로가 모두 성공했습니다.

공개 라우트 전 비공개 staging인증, noindex, 강제 장애, origin 비교, 승인 순서로 검증합니다.

안전하게 재현하기: 단계와 정제된 코드

1. 계약 정의. host, 안전 method, 실패 status, timeout, unknown path, route 제거를 먼저 정합니다. non-200이 모두 장애는 아닙니다.

2. 렌더링된 운영 crawl. canonical sitemap에서 same-origin HTML/CSS 자산만 수집하고 URL 정규화, traversal 차단, 개수/크기 초과 시 build 실패를 적용합니다.

3. 의미 보존. canonical, hreflang, schema, link, client tool 자산을 유지하고 service worker/tracking은 복사본에서 제거합니다. 광고/분석은 운영에서만 삽입합니다.

4. ASSETS와 run_worker_first. 복사본 전에 origin을 확인하며 예시는 placeholder만 포함합니다.

5. 동일 zone 재귀 방지. 관리되는 DNS-only 이름을 resolveOverride로 쓰고 URL/Host는 유지하며 TLS/vhost를 시험합니다.

6. 비공개 staging. secret, noindex, robots 차단, 광고/분석 없음, origin preview를 사용합니다.

7. apex 다음 www. collision을 거부하고 redirect를 확인합니다. fail-open은 가용성 용도에만 씁니다.

8. rollback 분리. 소유 route만 삭제하고 Worker/snapshot은 보존하며 임시 권한을 철회합니다.

{
  "name": "example-host-outage-fallback",
  "main": "src/index.ts",
  "compatibility_date": "2026-07-17",
  "assets": {
    "directory": "./snapshot/dist",
    "binding": "ASSETS",
    "run_worker_first": true,
    "html_handling": "none",
    "not_found_handling": "none"
  },
  "vars": {
    "MODE": "production",
    "ORIGIN_BASE": "https://example.com",
    "ORIGIN_RESOLVE_OVERRIDE": "origin-bypass.example.com",
    "ORIGIN_TIMEOUT_MS": "4500"
  }
}

const FALLBACK_STATUSES = new Set([
  500, 502, 503, 504, 520, 521, 522, 523, 524, 525, 526, 527
]);

try {
  const origin = await fetch(originRequest, {
    signal: AbortSignal.timeout(4500),
    redirect: "manual",
    cf: { resolveOverride: "origin-bypass.example.com" }
  });
  if (!FALLBACK_STATUSES.has(origin.status)) return origin;
  return serveSnapshot(request, origin.status);
} catch {
  return serveSnapshot(request);
}

if (!new Set(["GET", "HEAD"]).has(request.method)) {
  return new Response("Temporarily unavailable", {
    status: 503,
    headers: {
      "Retry-After": "300",
      "Cache-Control": "no-store",
      "Content-Type": "text/plain; charset=utf-8"
    }
  });
}

# Build from rendered production and validate the package
python scripts/build_snapshot.py
npm run types
npm run check
npx wrangler deploy --env staging --dry-run

# Deploy and test the private preview (use your own secret securely)
npx wrangler deploy --env staging
python scripts/smoke_staging.py --base "https://<private-preview>" --password "<secret>"

# Inspect, activate, or remove only the owned routes
python scripts/manage_routes.py status
python scripts/manage_routes.py activate --confirm ACTIVATE-KBT-FALLBACK
python scripts/manage_routes.py deactivate --confirm REMOVE-KBT-FALLBACK

테스트 계획: 장애, 통과, 복구 증명

홈, 핵심 tool, CSS/JS, 글, Arabic RTL, 긴 locale, robots, missing path, HEAD, POST, www redirect, mobile light/dark를 시험합니다.

snapshot에서 header/canonical/H1/JSON-LD/asset/notice, origin preview에서 loop 없음, 정상 운영에서 fallback header 없음과 무변경 응답을 확인합니다.

공개 origin을 고의로 중단하지 말고 private preview나 별도 test origin을 쓰며 생성 시간과 manifest hash를 기록합니다.

롤백, 이벤트 모니터링, 복구

즉시 롤백은 소유 Worker route만 삭제하는 것입니다. DNS 변경이나 Worker 삭제가 아닙니다. apex/www를 확인하고 오래된 HTML이 있을 때만 purge합니다.

점검 중 header, origin status, log, 핵심 page, 503을 봅니다. 첫 정상 응답이 자동 복구합니다. 이후 안정성 확인, 임시 권한 철회, 측정 보관, snapshot 갱신을 합니다.

두 함정: 동일 존 재귀와 무료 한도

keyboardtester.click/* Worker가 같은 공개 호스트를 그대로 fetch하면 자신에게 되돌아올 수 있습니다. 동일 존의 기존 DNS-only 이름과 resolveOverride를 사용해 URL/Host는 canonical로 유지하며 origin으로 해석했습니다. origin 주소와 우회 인프라는 공개하지 않습니다.

Free는 현재 하루 100,000 Worker 요청, 버전당 20,000 정적 파일, 파일당 25 MiB입니다. 2,749개는 맞습니다. 라우트는 fail-open이라 한도 초과 시 Error 1027 대신 HostArmada로 직접 갑니다. 가용성에는 맞지만 보안 강제에는 맞지 않습니다.

폴백 중 SEO, 광고, 분석

존재하는 페이지는 원 URL에서 200, canonical, schema, 내부 링크를 유지하고 이용 불가 쓰기만 503입니다. 별도 공개 백업 도메인이나 새 제출 URL이 없습니다.

staging은 비밀번호·robots 차단·noindex·무추적입니다. 운영 폴백 HTML만 지연 GA4/AdSense와 홈페이지 Clarity를 받으며 정상 origin 응답은 손대지 않습니다. 측정과 광고 기회는 남지만 fill과 수익은 보장되지 않습니다.

We did not submit fallback URLs to search engines because there are no new public URLs. The continuity layer sits behind the same addresses Google already knows.

운영 삽입은 live 성능과 같아 GA4는 상호작용 또는 load 2초 후, AdSense는 상호작용 또는 15초 후, 홈페이지 Clarity는 상호작용 또는 12초 후 로드됩니다. streaming HTMLRewriter는 fallback GET HTML만 바꾸며 HEAD, CSS, JS, 이미지는 바꾸지 않습니다.

한계와 다른 구조가 필요한 경우

폼, 서버 AI, 이메일, DB 쓰기, 세션, 저장 제출은 origin 장애 중 사용할 수 없습니다. 브라우저 도구도 필요한 파일이 모두 복사됐을 때만 동작합니다.

스냅샷은 낡으므로 큰 변경 후 갱신하고 실패뿐 아니라 복구도 시험합니다. 거래·쓰기 중심 제품은 앱과 DB 복제가 필요합니다.

콘텐츠와 클라이언트 도구가 많은 공유 호스팅 사이트에는 데이터 분리, 수동 전환, 중복 공개 도메인 없이 명확한 축소 모드를 제공해 잘 맞았습니다. 보이는 장애를 줄이지만 모든 의존성을 없애지는 않습니다.

1차 자료와 직접 검증

수치는 2026년 7월 17~18일 manifest, 배포, 실라우트 점검에서 얻었습니다. 동작과 제한은 연결된 1차 문서를 따릅니다.

• Cloudflare Workers: Static Assets
• Cloudflare Workers: Platform Limits
• Cloudflare Workers Request API
• Cloudflare Workers Routes API
• RFC 9110: HTTP Semantics
• HostArmada support correspondence, July 16–17, 2026

자주 묻는 질문

• 공유 호스팅이 정말 무중단이 되나요?

  아닙니다. 읽기 복사본은 남지만 폼, 쓰기, 이메일, AI, 세션은 origin이 필요합니다.

• 장애 때 DNS를 바꿔야 하나요?

  상시 방식에서는 아닙니다. Worker가 매번 검사하고 자동 복귀합니다.

• Google이 모든 URL에서 점검 페이지를 보나요?

  아닙니다. 복사된 페이지는 200과 canonical/schema를 유지하고 이용 불가 작업만 임시 503입니다.

• 왜 계정 전체를 임시 이전하지 않나요?

  왕복 이전은 DNS, 파일, 메일, DB 동기화 위험을 더합니다.

• 왜 resolveOverride를 쓰나요?

  Worker가 자기 공개 경로를 호출하지 않도록 같은 존의 다른 이름으로 해석하고 URL/Host는 유지합니다.

• 무료 한도를 넘으면 어떻게 되나요?

  fail-open이 Worker를 우회해 origin으로 갑니다. origin 장애 시 폴백은 사라지지만 추가 한도 오류는 막습니다.

• 스냅샷은 언제 갱신하나요?

  큰 콘텐츠·템플릿·스크립트·자산 변경 후와 계획 점검 전에 갱신하고 실패/복구를 시험합니다.

핵심은 모든 것을 Worker 뒤에 두는 게 아니라 장애에 맞는 최소 연속성 계층을 선택하고, 비공개로 검증하고, 한계를 밝히고, 복구를 자동화하는 것입니다.