OpenClaw Linux VPS·Ollama 연동 | Gateway 업스트림, TLS, SSH, NO_PROXY

공개 채널·Webhook은 작은 Linux 클라우드 VPS에 두고, 가중치와 GPU는 집이나 사내망의 Ollama에 두는 구성은 2026년에도 흔합니다. 실패 원인은 모델 품질보다 네트워킹인 경우가 대부분입니다. 업스트림 URL 혼선, TLS 이중 종료, 기업망 HTTP_PROXY가 루프백 트래픽까지 가로채기, 절전 뒤 조용히 끊기는 SSH 터널까지. 아래는 재현 가능한 배선 패턴과 엣지·Gateway·Ollama 세 층으로 502와 “타임아웃”을 나누는 절차입니다. 경량 VPS와 역할 분리를 같이 고민한다면 2026 단주기 AI 도구 트라이얼·배치 버스트: 일 단위 클라우드 Mac vs 경량 VPS — 격리·이그레스·비밀 의사결정 매트릭스 FAQ도 함께 보면 좋습니다.

분리 진단: 엣지·Gateway·Ollama

TLS

리버스 프록시에서 한 번만 종료

NO_PROXY

루프백은 환경 프록시 우회

토폴로지: 홉 소유권 정리

브라우저·메신저 채널 → 443 TLS → Caddy/Nginx → OpenClaw Gateway 루프백 포트 → Ollama로 나가는 HTTP 한 줄로 그리세요. Ollama는 같은 VPS의 127.0.0.1:11434, 컨테이너 브리지 IP, 또는 집에서 SSH로 포워딩한 포트일 수 있습니다. 컨테이너 안 localhost와 호스트 localhost를 포트 공개 없이 섞으면 “어제는 됐는데”류 버그가 납니다. 설정을 고치기 전에 종이에 홉 목록을 적어 두세요.

Gateway → Ollama 업스트림

모델 백엔드 베이스 URL은 하나로 고정하세요. 동일 장소면 http://127.0.0.1:11434, 터널 전용 포트면 http://127.0.0.1:18080처럼 명시합니다. 머신 내부에서 또 HTTPS 체인을 쌓지 마세요. 변경 뒤에는 systemd와 동일 유저로 curl /api/tags를 찍고, 셸에서는 되는데 Gateway만 실패하면 유저·네트워크 네임스페이스·stale unit 오버라이드를 의심합니다. 상주 장애 때 로그·포트를 단계별로 보는 방법은 2026 OpenClaw Linux 상주 장애: systemd·openclaw logs·게이트웨이 포트 프로브 단계별 FAQ에 정리해 두었습니다.

TLS 분리: 공개 엣지 vs 내부 HTTP

TLS는 리버스 프록시에서만 끝내고, Gateway에는 127.0.0.1:18789 같은 예시로 평문 HTTP만 붙이세요. 프록시 업스트림을 루프백 https://로 두면 내부 호에도 인증서 갱신 스케줄이 생겨 보통 손해입니다. Ollama 스트리밍은 HTTP/1.1 keep-alive와 프록시 버퍼 설정을 확인하세요. 공개 HTTPS 대 SSH만 노출하는 비교는 기존 매트릭스 글을 참고하면 됩니다.

재현 절차: SSH 역방향 터널(집 Ollama → VPS)

집에서 항상 켜 둔 호스트에서 ssh -N -o ServerAliveInterval=30 -o ExitOnForwardFailure=yes -R 127.0.0.1:18080:127.0.0.1:11434 user@vps로 VPS 루프백에 Ollama를 붙입니다. VPS에서는 Gateway 업스트림을 http://127.0.0.1:18080로 둡니다. GatewayPorts no, 키 인증, 집 쪽 systemd로 터널 상주를 권장합니다. 티켓 열기 전에 18080 포트의 소유 주체를 문서에 적어 두세요.

VPS 셸에서 빠른 확인

# 포워딩된 Ollama
curl -sS http://127.0.0.1:18080/api/tags | head

# 프록시 뒤 Gateway 헬스(호스트 치환)
curl -sS https://gw.example.com/healthz

NO_PROXY 매트릭스

많은 VPS 이미지가 미러용 HTTP_PROXY 환경 변수를 기본으로 넣어 둡니다. Gateway 유닛에서는 대소문자 정렬 또는 해제하고, 루프백은 아래처럼 예외를 둡니다.

대상	틀렸을 때	조치
`127.0.0.1` / `localhost`	로그에 사내 프록시로의 connect, 수 ms 만에 502	systemd 유닛에 `NO_PROXY=127.0.0.1,localhost,::1`
Docker 브리지(`172.17.0.2` 등)	compose 재시작 시 IP 바뀌며 간헐 타임아웃	고정 서비스명·사용자 브리지, 이름을 `NO_PROXY`에 추가
Unix 소켓 업스트림	소켓 파일이 있는데도 `ECONNREFUSED`	유닛 UID 일치, `ProxyCommand`가 로컬 도구를 감싸지 않는지 확인

타임아웃도 종류가 다릅니다

클라이언트 120초 “타임아웃”은 스트림이 한동안 가만히 있으며 VRAM에 모델을 올리는 중일 수 있습니다. 프록시 read_timeout을 늘리고 GPU 여유를 확인하세요. 응답 본문이 거의 없이 즉시 뜨는 502는 업스트림 소켓에 아직 아무도 안 붙었을 때가 많습니다.

계층별 FAQ: 502 vs 멈춤 vs 리셋

층 A — 엣지: Nginx/Caddy 에러 로그를 봅니다. HTTPS 업스트림에서 connect() failed (111: Connection refused)면 포트에 리스너가 없습니다. 층 B — Gateway: 나가는 URL이 같은 유닛에서 쓴 curl과 동일한지 확인합니다. 층 C — Ollama: 콜드 스타트 후 첫 토큰이 프록시 기본 읽기 타이머를 넘길 수 있습니다. 긴 프롬프트만 실패하면 엣지 바디 한도를 먼저 의심하세요.

재현 체크리스트

티켓에는 네 가지를 붙이세요. 외부에서 본 전체 HTTPS 응답 헤더, 대응하는 리버스 프록시 한 줄, Gateway 로그 슬라이스, VPS 루프백에서의 한 줄 curl 증명. 이 순서면 한 라운드로 대부분 결론이 납니다.