Coolify 사용법: 서버 한 대에 apex와 서브도메인 6개를 올린 Cloudflare 구성

flowoodz.com 하나에 서비스 여러 개가 붙어 있습니다. apex는 브랜드 허브이고, 서브도메인마다 다른 앱이 돕니다. 모두 집에 있는 서버 한 대의 Coolify에서 돌고, DNS와 프록시는 Cloudflare가 맡습니다.

구성 자체는 어렵지 않았습니다. 시간이 든 곳은 apex의 용도를 바꿀 때였습니다. 원래 apex는 대표 서비스로 301 리다이렉트를 걸어 두었습니다. 이것을 브랜드 허브로 바꾸자 예상하지 못한 곳이 깨졌습니다.

같은 실수를 하지 않으려고 구성과 함정을 적어 둡니다.

최종 구조#

flowoodz.com/           브랜드 허브 (Next.js)
flowoodz.com/ads.txt    200 (애드센스)
flowoodz.com/health     200 ok (Coolify / Uptime Kuma)
 
www.flowoodz.com        같은 브랜드 허브 앱
plan.flowoodz.com       주간 할일 보드
yt.flowoodz.com         유튜브 트렌드 도구
capybara.flowoodz.com   미니 게임
kuma.flowoodz.com       Uptime Kuma
n8n.flowoodz.com        n8n

원칙은 하나입니다. apex 도메인은 apex 앱에만 붙이고, 서브도메인 앱에는 붙이지 않습니다. 이것을 어기면 어느 컨테이너가 apex 요청을 받는지 알 수 없게 됩니다. 이 서버에서 운영하는 서비스는 제품 목록에 있습니다. 주간 할일 보드 Plan Wall, 유튜브 트렌드 도구, 미니 게임 카피바라가 위 목록의 서브도메인입니다.

DNS는 이렇게 둡니다.

Cloudflare 전역 리다이렉트가 ads.txt까지 301로 넘겼습니다#

가장 오래 헤맨 문제입니다.

apex를 대표 서비스로 넘기던 시절에 Cloudflare에 전역 Redirect Rule을 걸어 두었습니다. flowoodz.com/*를 plan.flowoodz.com/*로 보내는 규칙입니다. Coolify 앱을 건드릴 필요가 없어서 편했습니다.

apex를 브랜드 허브로 바꾸자 문제가 생겼습니다. Coolify에 앱을 새로 붙이고 도메인을 등록했는데도 /가 계속 301로 넘어갔습니다. Coolify 설정을 몇 번이나 다시 봤지만 문제가 없었습니다. Cloudflare가 요청을 오리진으로 보내지 않고 엣지에서 먼저 리다이렉트하고 있었습니다.

/ads.txt도 같은 문제를 겪었습니다. 애드센스는 flowoodz.com/ads.txt가 200으로 응답해야 합니다. 그런데 전역 리다이렉트는 경로를 가리지 않아서 이것도 301이 됐습니다. 브라우저로 /만 보고 있으면 알아채기 어렵습니다.

그래서 apex의 용도를 바꿀 때는 Coolify보다 Cloudflare의 Redirect Rule과 Page Rule을 먼저 봅니다. 오리진 설정을 고쳐도 엣지에서 잡히면 요청이 오리진까지 오지 않습니다.

증상별 원인은 이렇습니다.

Proxied 상태에서는 SSL 모드를 Full 이상으로 둡니다#

Cloudflare에서 오렌지 구름(Proxied)을 켜면 트래픽이 Cloudflare를 거칩니다. 이때 Cloudflare와 오리진 사이의 암호화 모드가 따로 있습니다.

Coolify는 Let's Encrypt로 오리진 인증서를 받습니다. 그래서 SSL/TLS 모드는 Full이나 Full (Strict)이어야 합니다. Flexible로 두면 Cloudflare는 오리진에 평문으로 붙고, Coolify는 HTTPS로 리다이렉트합니다. 그 결과 무한 루프나 인증서 오류가 납니다.

• SSL/TLS 모드는 Full 이상으로 둡니다.
• Always Use HTTPS를 On으로 둡니다.

이 두 값은 DNS 편집 권한만 있는 API 토큰으로는 볼 수 없습니다. 대시보드에서 직접 확인해야 합니다. 스크립트로 DNS만 관리하면 이 항목을 놓치기 쉽습니다.

모든 서브도메인을 Proxied로 두는 것이 늘 맞지는 않았습니다. 게임 웹소켓은 Cloudflare를 거치면서 핑이 279ms까지 올랐습니다. 소켓만 DNS 전용 호스트로 빼서 8ms로 줄인 과정은 RAYFRAME 웹소켓 글에 적었습니다.

헬스체크 경로는 앱마다 따로 둡니다#

앱마다 /health를 따로 두고, 그 앱의 컨테이너와 외부 도메인을 각각 확인합니다. 구현과 프로브가 실패한 원인은 Next.js 배포 기록에, Docker 내부 검사와 Uptime Kuma의 역할 차이는 모니터링 기록에 있습니다.

여러 앱이 같은 서버에 있어도 검사 경로를 같이 쓰지 않습니다. Coolify는 정상인데 외부 모니터만 실패하면 DNS나 Cloudflare 구간을 먼저 봅니다. 한 앱의 /health만 실패하면 그 컨테이너부터 확인합니다.

같은 서버에서 도는 n8n의 환경변수와 백업은 n8n 셀프호스팅 글에 따로 정리했습니다.

배포 설정보다 결과 HTML을 확인합니다#

2026년 8월 19일에 프로덕션 HTML을 다시 보다가 애드센스 스크립트가 통째로 빠진 것을 찾았습니다. 클라이언트 ID는 로컬 .env.local에만 있었고 Coolify 빌드에는 전달되지 않았습니다. 설정 화면에 값을 적었다는 기억보다 배포된 HTML이 정확했습니다.

지금은 공개 값인 애드센스 클라이언트 ID를 코드에 직접 적고, 빌드 결과의 <head>에서 스크립트를 확인합니다. NEXT_PUBLIC_*가 빌드 시점에 정해지는 원리와 두 번째 반려 대응은 애드센스 기록에 이어서 적었습니다.

배포와 검증#

Coolify에 GitHub App으로 저장소를 연결하면 push할 때마다 자동으로 빌드합니다. private 저장소는 GitHub App으로 붙여야 합니다. Public Repository 방식으로 등록하면 git ls-remote가 실패합니다.

수동 배포가 필요하면 API를 씁니다.

curl -H "Authorization: Bearer $COOLIFY_API_KEY" \
  "https://coolify.example.com/api/v1/deploy?uuid=<APP_UUID>&force=true"

push 직후에 이 API를 또 부르면 같은 커밋이 두 번 빌드됩니다. 겹친 배포를 찾은 기록은 Coolify API deploy 글에 적었습니다.

배포 뒤에는 항목별로 나눠서 봅니다. /만 확인하면 ads.txt 같은 문제를 놓칩니다.

# apex가 리다이렉트가 아니라 200인지
curl -sSI https://example.com/ | head -5
 
# 헬스체크
curl -sS https://example.com/health
 
# 경로별 응답 (전역 리다이렉트가 남았는지)
curl -sSI https://example.com/ads.txt | head -3
 
# www도 같은 앱으로 가는지
curl -sSI https://www.example.com/ | head -3

-I로 헤더만 받아 상태 코드가 200인지 301인지 봅니다. 브라우저는 리다이렉트를 자동으로 따라가 최종 화면만 보여 줍니다. 그래서 눈으로는 정상처럼 보입니다.

장애는 바깥 구간부터 확인합니다#

서버 한 대에 서비스 여러 개를 올리면 비용이 적게 듭니다. 앱을 하나 더 붙여도 추가 비용이 거의 없습니다. 대신 요청이 거치는 단계가 늘어납니다.

요청은 Cloudflare DNS, Cloudflare 엣지(리다이렉트와 SSL), Coolify 프록시, 컨테이너 순서로 흐릅니다. 문제가 생기면 이 순서대로 의심하는 것이 가장 빠릅니다. 저는 늘 가장 안쪽인 컨테이너 설정부터 의심해서 시간을 버렸습니다. 원인은 대부분 가장 바깥쪽에 있었습니다.