OpenClaw Linux VPS 2026 | 방화벽·루프백 Gateway·SSH vs HTTPS

Linux VPS에 OpenClaw Gateway를 올리면 비용과 유연성은 좋아지지만, 관리 UI가 열린 포트 스캔 대상이 되기도 합니다. 실무 목표는 작고 열거 가능한 노출면입니다. 엣지에서 기본 거부, Gateway는 의도한 경로로만 도달, SSH 터널 관리 접속과 공개 HTTPS 리버스 프록시 중 무엇을 택할지 분명히 하는 것이죠. 아래는 재사용 가능한 방화벽 베이스라인, 루프백 바인딩 가이드, SSH 접근 패턴, 그리고 과도한 설계 없이도 나중에 강화를 빠뜨리지 않도록 돕는 비교 매트릭스입니다.

22 / 443

공개로 정당화되는 대표 포트

127.0.0.1

락다운 시 Gateway 바인딩 권장

L0–L3

티켓 정렬용 단계별 점검

위협 모델을 한 단락으로

SSH에는 크리덴셜 스터핑, 모든 HTTP 리스너에는 스크래핑, 설치 경로에는 공급망 잡음이 붙는다고 가정합니다. Gateway는 토큰·세션을 조율하므로 다른 데몬과 분리하세요. 인바운드 기본 거부에서 출발한 뒤, 키 전용(선택적으로 IP 허용 목록) SSH와 어시스턴트·웹훅을 위해 의도적으로 공개하는 것만 추가합니다.

방화벽 템플릿: 기본 거부, 명시적 허용

ufw든 nftables든 이야기는 같습니다. 루프백 허용, established/related 허용, 신규 인바운드는 SSH와(필요할 때만) TLS용 80/443으로 좁힙니다. IPv6에도 규칙을 맞추거나 의식적으로 끄세요. 실수로 v6만 열어 두는 일은 흔한 발목입니다.

UFW 스타일 베이스라인(SSH 포트는 환경에 맞게)

# 신뢰하는 콘솔 세션에서만 초기화
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH    # 또는: allow 22/tcp
# 이 서버에서 OpenClaw TLS 종료 시:
# sudo ufw allow 80,443/tcp
sudo ufw enable
sudo ufw status verbose

클라우드 보안 그룹을 먼저

콘솔의 보안 그룹도 OS 방화벽과 같은 이야기를 반복해야 합니다. 둘 다 있으면 규칙을 맞춰 두어, UI에서 한 번 잘못 눌러도 VPS가 조용히 넓어지지 않게 하세요.

Gateway 루프백 바인딩

LAN의 다른 호스트가 Gateway를 부를 필요가 없다면 127.0.0.1(v6 루프백을 쓰면 그쪽도)에 바인딩하세요. 「방화벽 깜빡하고 고포트 노출」류의 사고 대부분이 사라집니다. 같은 머신에서 프로토콜 브리지가 필요할 때만 로컬 리버스 프록시를 더하고, 관리 트래픽은 아래 SSH 포트 포워딩을 쓰는 편이 단순합니다.

헬스 체크와 에이전트

외부 가용성 모니터가 Gateway에 직접 때려야 한다면 루프백 전용 모드는 그 경로에 맞지 않습니다. 리스너 분리, 사설 인터페이스 mTLS, 또는 공용 인터넷 대신 호스트 프로세스 감독자가 헬스를 보게 옮기는 방식을 검토하세요.

관리면 접속용 SSH 터널

1인·소규모 팀에는 ssh -L이 키와 내가 쓰는 브라우저 쪽에 신뢰를 남기기 쉽습니다. 예시는 다음과 같습니다.

로컬 포워드 예시(포트는 예시)

ssh -N -L 8443:127.0.0.1:18789 user@vps-hostname
# 터널 스택에 TLS가 있으면 브라우저에서 https://127.0.0.1:8443
# 루프백이 평문 HTTP면 http://127.0.0.1:8443 (운영은 stunnel/WireGuard 등으로 감싸는 편이 안전)

SSH는 키만, AllowUsers를 촘촘히, 필요 시 fail2ban·속도 제한을 붙이세요. SSH를 비표준 포트로 옮기는 것은 위생일 뿐 정책은 아닙니다. 터널은 되는데 Gateway가 응답하지 않으면 2026 OpenClaw Linux 상주 장애: systemd·openclaw logs·게이트웨이 포트 프로브 단계별 FAQ에서 systemd와 로그를 나눠 점검하면 됩니다.

결정 매트릭스: SSH·루프백 경로 vs 공개 HTTPS 리버스 프록시

브라우저·모바일망·웹훅이 안정적인 공개 URL을 필요로하면 HTTPS를 씁니다. 운영자만 관리 UI를 건드리고 엣지 구성요소를 줄이고 싶으면 SSH 쪽이 낫습니다.

축	루프백 Gateway로의 SSH 터널	공개 HTTPS 리버스 프록시(Nginx/Caddy)
대상	SSH 키를 가진 관리자	브라우저·앱·벤더 웹훅
노출	SSH(+선택 VPN)	443(및 ACME용 80)
TLS 작업	SSH 전송을 신뢰하면 최소로 유지 가능	인증서·갱신·암호 스위트 관리
전형적 장애	NAT 타임아웃, ControlMaster 깨짐	Host 헤더 오라우팅, 오래된 업스트림
잘 맞는 경우	1인/소팀, 공개 연동 없음	공유 어시스턴트, 가용성 SLO가 빡센 경우

단계적 노출

1일차는 루프백+SSH로 출고하고, 구체적인 연동이 안정적인 공개 URL을 요구할 때만 HTTPS로 승격합니다. 전환 후에도 예전 SSH 경로는 비상용(break-glass)으로 남겨 두세요.

단계별 FAQ

다른 OpenClaw 런북과 맞추기 위해 L0–L3 표현을 통일해 두면 티켓 비교가 쉬워집니다.

L0 — 「아무 것도 안 듣는다」

유닛이 active인지 확인한 뒤 ss -lntp로 리스닝을 봅니다. Gateway가 루프백 전용이면 다른 호스트에서의 테스트는 거짓 음성이니, 터널을 통하거나 VPS 셸 안에서 재검증하세요.

L1 — 「SSH는 되는데 터널이 안 된다」

로컬 포트 충돌, localhost와 127.0.0.1의 IPv6 동작 차이, VPS 셸에서 루프백 대상으로 curl -v를 돌려 SSH 문제와 앱 문제를 분리합니다.

L2 — 「인증서 갱신 뒤 HTTPS 경로가 들쭉날쭉」

ACME 방식(HTTP-01 vs DNS-01), 프록시 리로드 오류, 업스트림 keepalive를 봅니다. 갱신이 헬스 체크와 조율되지 않으면 Gateway까지 튕기지 않게 자동화를 맞추세요.

L3 — 「침해 의심」

방화벽 규칙을 덤프해 두고 SSH 키·토큰을 교체하며 웹훅을 폐기한 뒤, 살아 있는 디스크 위에서 때려잡기보다 알려진 이미지로 재구축하는 편이 낫습니다. 설치 경로·환경 이슈는 2026 OpenClaw Linux 클라우드 VPS 실전: curl 설치 vs Docker 비교, 환경 검증과 자주 보는 오류 FAQ와 함께 보세요.