Cloudflare Tunnel은 자동 라우터가 아닙니다. cloudflared→엣지 인증 파이프와 커밋 가능한 ingress가 계약입니다. OpenClaw를 loopback만 쓰면 MagicDNS와 SSH -R 사이 제3경로로, 공인 인바운드 없이 리전별 고정 호스트명 합성 검사가 가능합니다.

Named Tunnel은 DNS를 Cloudflare에 둔 팀이 HTTP 입구까지 리뷰 가능한 산출물로 만들 때 씁니다. config.yml ingress는 코드처럼 순서·호스트명·끝의 404 캐치올을 고정하세요. 엣지 조향이 더 필요하면 Worker·SSH p95 글을 함께 보고, 여기서는 cloudflared·loopback·프로브 병합만 다룹니다.

「ingress 고정」이 중요한 이유

프로덕션은 Named Tunnel+ingress 파일이 계약입니다. 호스트→http://127.0.0.1:PORT·캐치올을 명시하고 리전별로 호스트·포트만 바꿔 병합 로직을 단순화하세요. 유닛 템플릿 옆에 두면 revert 한 번으로 롤백됩니다. OpenClaw는 0.0.0.0 바인딩 금지—로컬 클라이언트는 cloudflared와 헬스뿐, 브라우저는 엣지 TLS 후 터널로.

재현 절차(vpshalo 리전마다 한 벌)

인벤토리 태그·실제 health 경로에 맞게 치환하세요. 아래 포트·호스트는 예시입니다.

  • 1단계 — OpenClaw를 loopback에 격리. OPENCLAW_HOME=/var/lib/openclaw/<region> 등 리전별 홈을 export하고(이미지가 macOS 경로를 쓰면 그에 맞춤), 게이트웨이가 127.0.0.1:18080만 리슨하도록 플래그를 명시합니다. 동일 호스트에서 curl -fsS --max-time 2 http://127.0.0.1:18080/healthz가 성공할 때까지 확인합니다.
  • 2단계 — Named Tunnel과 DNS. cloudflared를 설치한 뒤 cloudflared tunnel create openclaw-<region>을 실행하고, Cloudflare가 요구하는 CNAME을 <region>.gw.example.com 등에 맞춥니다. 터널 UUID·이름을 CMDB에 남기면 로테이션 시 매핑이 분명합니다.
  • 3단계 — ingress 고정. 자격 증명 JSON을 참조하는 tunnel 블록이 있는 config.yml을 작성하고, ingress에서 https://<region>.gw.example.com/*를 http://127.0.0.1:18080에 연결합니다. 편집 실수로 첫 규칙에 떨어지지 않도록 - service: http_status:404로 끝냅니다.
  • 4단계 — systemd로 TUNNEL_TOKEN. Zero Trust에서 해당 터널 토큰을 복사해 /etc/default/cloudflared-openclaw(권한 0600)에 TUNNEL_TOKEN=…만 기록하고, 유닛은 cloudflared tunnel run --config /etc/cloudflared/openclaw-<region>.yml를 가리킵니다. Restart=on-failure와 백오프로 제어 평면을 두드리지 않게 합니다.
  • 5단계 — 엣지→오리진 검증. 사무 VLAN 밖 CI 등에서 공개 HTTPS URL로 curl합니다. loopback 헬스 RTT와 비교해 엣지만 초록이면 박스 내부 버그, 둘 다 동시에 죽으면 프로세스 쪽을 의심하고 터널 인증서 탓으로 돌리지 않습니다.
# 오리진: cloudflared 전에 loopback이 먼저 살아 있어야 함
curl -fsS --max-time 2 http://127.0.0.1:18080/healthz

# DNS 전파 후: 엣지 검증(별도 클라이언트 인증서 불필요)
curl -fsS --max-time 5 https://usw.gw.example.com/healthz
리전마다 터널 하나를 두면 폭발 반경이 작습니다. TUNNEL_TOKEN이 새면 그 PoP 경로만 위험해지고 전 세계 OpenClaw 홈이 한꺼번에 열리지는 않습니다.

리전 간 프로브 출력 병합

JSON에 region·lane(loopback / tunnel_origin / edge_https)·rtt_ms·http_status·error_class를 고정하고 검사마다 한 줄을 쌓은 뒤 리전 키로 5분 롤링 창에 넣습니다. 세 레인 동시 실패 시에만 리전 페이지, 두 리전 이상 edge_https 동시 실패일 때만 다중 리전 승격으로 중복 알림을 줄입니다.

  • 레인 A — loopback: 비용이 가장 낮은 신호로, 모델 호스트 cron에서 1분 주기.
  • 레인 B — tunnel_origin: cloudflared가 붙는 동일 포트에 127.0.0.1로 curl해 프로세스 쌍 배선을 증명.
  • 레인 C — edge_https: 외부 시점에서 5분마다 저빈도로 호출해 레이트 리밋과 장애를 혼동하지 않기.

FAQ: 터널 인증서·포트·토큰

Cloudflare Tunnel 뒤에서 vpshalo 호스트에 TLS 서버 인증서가 필요한가요? 대개 아니요. 사용자 TLS는 Cloudflare에서 종료되고 cloudflared는 127.0.0.1에 평문 HTTP로 붙을 수 있습니다. 규제상 오리진 구간 암호화가 필요할 때만 루프백 TLS를 추가하고, 공용 CA 와일드카드를 git에 복사하지 말고 금고의 짧은 수명 인증서로 로컬 종료하세요.

로컬 포트는 어떻게 고르고 검증하나요? 리전마다 문서화된 높은 포트(예: 18080)를 정하고 OpenClaw 플래그와 ingress에 동일 값을 넣습니다. ss -lntp로 해당 포트가 0.0.0.0에 열려 있지 않은지 확인합니다. 포트를 바꿀 때는 두 파일을 같은 커밋으로 옮겨 cloudflared가 죽은 업스트림에 매달리는 드리프트를 막습니다.

TUNNEL_TOKEN은 어떻게 다루나요? 클라우드 API 키와 같이 취급합니다. git·티켓에 넣지 않고 EnvironmentFile이나 비밀 관리자에서 주입하며, 유출 시 즉시 재발급한 뒤 그 리전 노드를 한꺼번에 재시작해 구·신 토큰이 섞인 스플릿 브레인을 피합니다.

장애 시 무엇이 먼저 깨지나요? OpenClaw 자체보다 DNS나 git에 남은 옛 ingress가 흔합니다. 온콜은 모델을 재시작하기 전에 실행 중 config.yml과 저장소 diff를 익히게 하세요.

면책: OpenClaw 릴리스마다 플래그·헬스 경로가 다릅니다. 실행 빌드 문서로 바인드 주소를 대조하세요. Cloudflare 상품 한도·규제 준수는 본 런북 범위 밖이며, 데이터 상주와 지연 튜닝은 별도 검증이 필요합니다.

구매 정렬: 터널 RTT·레지스트리와 맞는 PoP를 고르고 전환 후 edge_https 기준선을 ingress 문서에 같이 적어 용량을 증거에 묶으세요.

vpshalo 공개 페이지에서 다음 단계

체크리스트를 주문으로 이어가기

첫 페이지에서 제품 맥락을 보고, 요금제로 PoP·리소스를 비교한 뒤 도움말에서 연결 전제를 확인하세요. 터널이 이미 깔린 리전 옆에 원격 Mac을 열려면 구매로 이동하면 DNS·ingress·빌더 지연이 한 장 운영 시트에 남습니다. OpenClaw·엣지 라우팅 자매 글은 기술 블로그 목록을 이어서 읽으면 됩니다.

원격 Mac 구매로 이동 요금제 보기 도움말 다른 글 보기