2026년 OpenClaw Gateway가 공용 네트워크에 노출되면 5개 계층 각각의 결함은 어떤 모습일까요?
첫 번째 레이어는클라우드 공급업체 보안 그룹 및 경계 ACL: 기기 내부에서는 정상적으로 모니터링이 되고 있는 것을 볼 수 있으나, 공용망 입구에서는 진입이 불가능합니다. 일반적으로 인바운드 규칙은 22 및 80만 열고 18789나 리버스 프록시의 대외 포트가 허용 목록에 없는 경우가 많습니다. 두 번째 층은호스트 방화벽입니다. Ubuntu의 ufw, CentOS의 firewalld, 이미지 기본 deny는 보안 그룹으로 NIC를 연 뒤에도 패킷을 떨어뜨립니다. 세 번째 층은리버스 프록시와 WebSocket입니다. Nginx나 Caddy가 Upgrade와 Connection을 제대로 투과하지 않으면 브라우저에는 핸드셰이크 실패나 재연결 루프로 보이지만 Gateway 프로세스는 여전히 정상일 수 있습니다.
네 번째 층은게이트웨이 바인딩 및 인증: 모니터링을 루프백에서 LAN 또는 사용자 정의 주소로 변경하면 공식 가드레일에 토큰 또는 이에 상응하는 인증이 필요합니다. 누락된 경우 "바인딩을 거부"하거나 "바인딩할 수 있지만 제어 플레인이 RPC 감지를 완료할 수 없습니다"입니다. 5층은채널 및 전략: Telegram, Discord, Webhook 어느 쪽이든 속도 제한, 페어링 상태, 그룹 정책 및 DM 정책으로 인해 "게이트웨이는 온라인이지만 비즈니스 측에서는 인식하지 못합니다"라는 현상이 로그에 나타납니다.
5개의 레이어를 분리한 후에는 오류가 발생할 때마다 다시 설치할 필요가 없습니다. 다음 섹션의 표는 네트워크 진입 문제, 제어 평면 구성 문제 또는 채널 제품 문제를 해결하고 있는지 확인하는 데 사용됩니다.
보안 그룹:공용 IP에서 가장 작은 프로브를 사용하여 포트에 연결할 수 있는지 확인한 다음 비교를 위해 인트라넷으로 돌아갑니다.
호스트 방화벽:"두 레이어 모두 다른 레이어가 이를 허용할 것이라고 생각하는" 것을 방지하기 위해 보안 그룹 규칙을 교차 확인합니다.
리버스 프록시:TLS 종료 지점이 업스트림 프로토콜과 일치하는지, WebSocket 헤더가 변경되지 않고 전달되는지 확인하세요.
바인딩·인증:gateway.mode, gateway.bind, gateway.auth가 같은 전제를 쓰는지 확인합니다.
채널:channels status --probe 출력과 공급자 콘솔 타임스탬프를 맞춥니다.
사이트에서 "OpenClaw 설치부터 게이트웨이 연결까지" 기사를 이미 읽었다면 이 기사를 「공용망 입구와 리버스 프록시」에 대한 보강 장으로 생각할 수 있습니다. 해당 기사는 설치 및 데몬 프로세스 승인에 대해 설명하고, 이 기사에서는 외부 네트워크 경로 및 WebSocket 세부 정보에 대해 설명합니다. 두 글을 겹쳐서 "전천후 안정적인 운영과 클라우드 노드 솔루션"을 읽어보시면 동기부여와 커맨드라인, 네트워크 레이어를 한번에 정리하실 수 있습니다.
루프백, LAN 및 tailnet을 모니터링하고 바인딩할 때 인증과 노출을 비교하는 방법
루프백 바인딩은 최소한으로 노출되며 동일한 머신에서만 제어 평면을 사용하는 데 적합합니다. 다른 노트북에서 대시보드를 열려고 하면 루프백이 아닌 주소로 모니터링을 확장해야 합니다. 이때 인증은 선택이 아닌 가드레일입니다. LAN 바인딩은 어떤 네트워크 카드와 네트워크 세그먼트가 신뢰할 수 있는지 명확하게 해야 합니다. 테일넷 또는 제로 트러스트 터널 시나리오에서는 "내부 네트워크로 간주되는 사람"을 팀 합의로 작성해야 합니다. 그렇지 않으면 디버깅 중에 잘못된 계층으로 반복적으로 점프하게 됩니다.
| 비교 축 | 루프백 바인딩만 | 비루프 바인딩 + 리버스 프록시 |
|---|---|---|
| 노출된 표면 | 최소, 기본적으로 외부 네트워크에 연결할 수 없습니다. | 보안그룹, 방화벽, TLS, 토큰 조합 관리 필요 |
| 대시보드 경험 | SSH 터널 또는 피어 액세스가 필요합니다. | 팀이 제어 평면을 공유하는 데 적합한 사용 가능한 도메인 이름 및 인증서 |
| 문제 해결 순서 | gateway status·doctor를 먼저 | 포트·리버스 프록시를 먼저 본 뒤 gateway·doctor로 |
| 일반적인 위험 | 루프백 전용 주소를 공용 네트워크 사용 가능한 주소로 착각함 | 토큰 없이 WebSocket Upgrade 미투과 또는 비루프백 |
| VPS와의 호환성 | 임시 테스트에 적합 | 게이트웨이를 장기적인 제어 평면 구성 요소로 사용하는 것이 적합합니다. |
공용 네트워크 문제 해결의 첫 번째 원칙은 먼저 패킷이 도착할 수 있음을 증명한 다음 핸드셰이크를 통과할 수 있음을 증명하고 마지막으로 비즈니스 로직이 온라인임을 증명하는 것입니다.
게이트웨이를 VPS에 배치했지만 여전히 동일한 시스템에서 스택 재컴파일 및 브라우저 도구 로드를 수행하면 경합이 "무작위 비정상"으로 증폭됩니다. 컨트롤 플레인과 과도한 로드를 다른 베어 메탈 인스턴스로 분할하는 것이 JVM 스타일 매개변수를 반복적으로 조정하는 것보다 더 효과적인 경우가 많습니다. 병렬성과 임대 기간을 결합해야 하는 경우 같은 날 게시된 "Mac mini M4 구매 또는 임대 TCO" 기사를 참조하여 예산과 마일스톤을 함께 묶어 검토할 수 있습니다.
Nginx 또는 Caddy로 OpenClaw Gateway를 노출할 때 WebSocket Upgrade 투과 골격
다음 스켈레톤은 WebSocket에 필요한 핵심만 남깁니다. proxy_http_version 1.1, Upgrade, Connection 헤더입니다. TLS를 리버스 프록시에서 끊으면 업스트림은 평문 루프백을 쓸 수 있습니다. end-to-end TLS로 바꿀 때는 업스트림 프로토콜과 인증서 검증용 블록을 별도로 두고 Runbook 한 페이지에 두 전제를 섞지 마십시오.
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
server {
listen 443 ssl;
location / {
proxy_pass http://127.0.0.1:18789;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header Host $host;
}
}
힌트:리버스 프록시 레이어에 IP 제한이나 지역 차단이 있으면 채널 공급자 콜백 IP를 화이트리스트에 넣어야 합니다. 그렇지 않으면 헬스는 녹색인데 실제 메시지는 안 들어오는 오탐이 납니다.
Caddy는 자동 인증서와 짧은 설정 파일이지만 WebSocket 투과 원칙은 같습니다. HTTP/1.1 Upgrade 의미와 Host 투과가 맞아야 합니다. 어떤 스택을 쓰든 팀 문서에 리버스 프록시 뒤의 최종 URL을 적어 OAuth·콜백 도메인 불일치를 막는 것이 좋습니다.
입구부터 채널 레이어까지 '외부 네트워크가 연결되지 않음'을 수렴하는 6단계
이 순서는 의도적으로 로컬 curl 검증을 뒤로 둡니다. 공용망 이슈를 내부 관점으로 착각하지 않도록 먼저 외부 경로로 프로브합니다. 각 단계 출력을 티켓에 붙이면 인수인계가 쉬워집니다.
대상 URL 고정:대시보드가 최종으로 쓰는 도메인·포트와 TLS 종단 여부를 적고 HTTP·HTTPS나 다른 호스트를 섞어 검증하지 않습니다.
외부 네트워크 프로브 포트에서:보안 그룹 스크린샷에 맞춰 별도의 네트워크 경로를 사용하여 443 또는 18789에 연결할 수 있는지 확인하세요.
호스트 방화벽을 확인하세요.ufw 또는 Firewalld 규칙을 나열하여 로컬 거부가 글로벌 패스를 재정의하지 않는지 확인합니다.
WebSocket 확인:브라우저 개발자 도구나 curl로 Upgrade 이후 101 응답인지 확인합니다.
Gateway로:openclaw gateway status와 openclaw doctor를 실행해 bind·토큰 전제가 리버스 프록시 뒤에 가려지지 않았는지 봅니다.
채널:openclaw channels status --probe를 실행하고 공급자 측 속도 제한·페어링 상태를 함께 기록합니다.
01~04가 녹색이고 05가 빨간색이면 먼저 업그레이드 후 구성 드리프트 또는 기본값 변경을 의심합니다. 05가 녹색이고 06이 빨간색이면 게이트웨이를 다시 시작하기 위해 서두르지 말고 먼저 채널을 독립 하위 시스템으로 취급하십시오.
클라우드상의 변경 검토 및 영구 분업에 작성할 수 있는 세 가지 기준
포트·프로토콜 일치:443에서 TLS를 끊으면 북마크·OAuth 콜백·Webhook URL을 같은 도메인 공간으로 다시 맞춥니다. 그렇지 않으면 로컬에선 되고 공용에선 안 되는 흔들림이 납니다.
층별 신호:포트 도달·HTTP 200·WebSocket 101·Gateway RPC ok·채널 준비를 나누고 한 층의 녹색으로 다른 층을 대체하지 않습니다.
제어 평면 분리:같은 머신에서 무거운 IDE·시뮬레이터를 돌리면 스왑만 늘리기보다 Gateway를 별도 베어 메탈 노드로 옮기는 편이 낫습니다.
알아채다:인증 없이 게이트웨이를 공용 네트워크에 직접 연결하는 것은 생산 사고의 위험이 높은 모드입니다. 공식 가드레일에 따라 토큰 또는 동등한 제어 영역 인증을 구성하고 감사 로그에 변경 사항을 기록해야 합니다.
노트북에만 Gateway를 두면 TLS·콜백 도메인·토큰 갱신이 감사하기 어렵습니다. 무거운 빌드와 브라우저 도구를 같은 VPS에 얹으면 네트워크는 정상처럼 보이는데 프로세스 지터만 섞입니다. 제어 평면을 MESHLAUNCH Mac mini 클라우드 베어 메탈처럼 분리해 두면 Apple Silicon 기반으로 일·주·월 단위로 지역을 바꾸며 OpenClaw를 장기 운영하기 쉽습니다. 먼저 대여 요금 페이지에서 제어 평면용 인스턴스를 고르고 고객 센터에서 SSH·네트워크 요구를 확인한 뒤 상시 클라우드 노드와 설치부터 Gateway·doctor 분리 글을 함께 읽으면 맥락이 맞습니다.
예, 일반적인 충돌은 포트 점유와 두 세트의 구성 루트 디렉터리입니다. 동일한 호스트에 하나의 제어 평면 세트만 유지하거나 포트 격리 및 데이터 디렉터리 격리를 문서에 명확하게 명시하는 것이 좋습니다. 선택은 대여 요금 페이지에서 하면 됩니다.
공식 마이그레이션 안내에 맞춰 로컬·데몬 설정을 맞춘 뒤 서비스를 재시작합니다. 전체 명령 체인은 설치부터 Gateway·doctor 분리 글을 참고하세요.
검색해주세요도움말 센터네트워크 및 SSH 지침, 포트 및 보안 그룹 확인은 Runbook의 동일한 페이지에 기록됩니다.