OpenClaw를 쓰다 보면 openclaw gateway status는 정상처럼 보이는데, 정작 browser 작업만 안 되는 순간이 있다. 이때 많은 사람이 브라우저를 다시 띄우거나 프로필부터 지우려 한다. 그런데 공식 문서를 같이 보면, 이 증상은 종종 브라우저 장애보다 Gateway 서비스는 살아 있지만 RPC가 실제로 건강하지 않거나, 브라우저 control plane 확인이 덜 끝난 상태에 더 가깝다.
공식 gateway CLI 문서는 gateway status가 서비스 상태 + 선택적 RPC probe를 보여준다고 설명한다. 여기서 중요한 건 --require-rpc다. 문서도 자동화에서는 “서비스가 떠 있다”보다 RPC 자체가 실제로 응답 가능한지를 보려면 openclaw gateway status --require-rpc를 쓰라고 권한다. 즉 status가 정상처럼 보여도 browser가 안 될 수 있는 이유가 이미 공식 문서에 들어 있다.
반대로 공식 browser CLI 문서는 브라우저 쪽 최소 진단 순서를 status → tabs → snapshot처럼 짧게 자르라고 안내한다. 이 말은 거꾸로, gateway status 한 줄만 보고 브라우저 전체를 정상이라고 단정하면 안 된다는 뜻이다.
flowchart TD A[`gateway status`는 정상처럼 보임] --> B{`--require-rpc`로도 정상인가?} B -->|아니오| C[Gateway RPC 문제부터 복구] B -->|예| D{browser status / tabs 되는가?} D -->|아니오| E[브라우저 control plane 점검] D -->|예| F{snapshot 또는 open 실패?} F -->|예| G[프로필/대상 페이지 정책/원격 경로 점검] F -->|아니오| H[정상 진행] C --> I[`gateway probe` + 원격 포워딩 확인] E --> J[`openclaw` / `user` 프로필 분기 확인] G --> K[문제 범위 축소 후 재시도] I --> K J --> K
칠판 치트시트
gateway status정상 = browser 정상은 아니다- 자동화에서는
openclaw gateway status --require-rpc가 더 중요하다- browser 쪽은
status → tabs → snapshot으로 짧게 자른다tabs까지 되는데snapshot만 실패하면 브라우저 전체보다 정책/프로필 문제일 수 있다- remote 환경이면 브라우저보다 SSH 포워딩·Gateway 대상부터 다시 본다
이런 증상이면 이 문서가 바로 맞다
openclaw gateway status는 정상인데 browser tool이 계속 실패한다.- 서비스는 살아 있는 것 같은데
snapshot,open,navigate가 간헐적으로 안 된다. - 브라우저를 재시작해도 증상이 반복된다.
- remote gateway를 쓰는데 어떤 날은 되고 어떤 날은 안 된다.
status하나만 보면 괜찮아 보이는데 실제 자동화는 멈춘다.
왜 이런 일이 생기는가
1) gateway status는 기본적으로 서비스 관점이 섞여 있다
공식 gateway 문서는 gateway status를 서비스 상태 + 선택적 RPC probe라고 설명한다. 즉 서비스가 떠 있다는 정보와, RPC가 실제로 제대로 응답하는지는 완전히 같은 얘기가 아니다.
실무에서는 이 차이가 꽤 크다.
- 서비스는 살아 있음
- 포트도 열려 있음
- 그런데 RPC는 중간에서 실패하거나, 필요한 범위까지 응답하지 않음
- 결과적으로 browser tool만 체감상 먹통처럼 보임
이때 단순 status만 보면 “정상”처럼 읽히기 쉬워서, 원인을 브라우저 쪽으로만 몰아가기 쉽다.
2) 브라우저는 또 따로 control plane을 확인해야 한다
공식 browser CLI 문서는 최소 진단 순서를 꽤 분명하게 제시한다. 먼저 status, 그다음 tabs, 그다음 snapshot 또는 공개 페이지 open이다. 이 순서는 그냥 예시가 아니라, 어디서 실패하는지 분리하기 위한 최소 단위에 가깝다.
예를 들면 이런 식으로 읽으면 된다.
browser status도 실패 → 브라우저 control plane 자체 문제 가능성 큼status와tabs는 됨 → 브라우저 자체는 어느 정도 살아 있음snapshot만 실패 → 대상 페이지 정책, 프로필, 권한, 원격 구조 문제일 수 있음
즉 gateway status와 browser status는 같은 상태 체크가 아니다.
3) remote 환경에서는 더 자주 착시가 생긴다
공식 gateway 문서는 gateway probe가 로컬 loopback, 설정된 remote gateway, 필요하면 SSH 터널까지 함께 보도록 설계됐다고 설명한다. 여러 gateway가 동시에 reachable할 수는 있지만, 대부분의 환경에서는 어느 gateway가 실제 winner인지를 먼저 확정해야 한다.
그래서 remote 환경에서는 이런 오해가 자주 생긴다.
- 로컬에서 보는 서비스는 살아 있음
- 실제 browser 요청은 다른 gateway나 다른 포워딩 경로를 탐
- 결과는 browser 실패처럼 보임
- 하지만 실제 원인은 RPC 대상 drift 또는 포워딩 충돌
이때는 브라우저 프로필을 바꾸기 전에 gateway probe가 훨씬 더 큰 힌트를 준다.
가장 빠른 5분 복구 순서
1) 먼저 gateway status --require-rpc로 다시 자른다
가장 먼저 할 일은 단순 status를 한 번 더 보는 게 아니라, RPC가 진짜 살아 있는지를 강제로 확인하는 것이다.
openclaw gateway status --require-rpc공식 문서도 스크립트와 자동화에서는 이 옵션을 권장한다. 이유는 단순하다. 서비스가 떠 있는 것만으로는 browser 도구가 쓸 수 있는 상태라고 단정할 수 없기 때문이다.
여기서 실패하면, 브라우저 쪽을 계속 만지기보다 gateway 문제를 먼저 푸는 편이 빠르다.
2) 그다음 gateway probe로 실제 대상 범위를 본다
openclaw gateway probe이 명령은 “어디가 실제로 reachable한가”를 한 번에 보여준다. 공식 문서 설명대로 explicit URL, configured remote, local loopback 순서로 후보를 비교하고, 여러 gateway가 동시에 보이면 경고도 준다.
실무에서는 이 단계가 특히 중요하다.
- 예상한 gateway가 아니라 다른 target이 살아 있음
- SSH 터널이 꼬여 fallback target으로 붙고 있음
- loopback은 되는데 remote만 죽어 있음
이런 정보는 브라우저 재시작만 반복해서는 보이지 않는다.
3) browser 쪽은 짧게 status → tabs → snapshot만 본다
gateway가 살아 있다는 게 확인되면, 이제 browser 쪽은 길게 보지 말고 짧게 자르는 편이 좋다.
openclaw browser --browser-profile openclaw status
openclaw browser --browser-profile openclaw tabs
openclaw browser --browser-profile openclaw snapshot공식 browser 문서의 quick start도 이 흐름과 비슷하다. 중요한 건 길게 자동화를 다시 돌리는 게 아니라, 지금 control plane이 어디까지 되는지만 먼저 확인하는 것이다.
4) tabs까지 되는데 snapshot이 안 되면 브라우저 전체 장애로 보지 않는다
이 구간이 가장 많이 헷갈린다. 공식 browser 문서는 status와 tabs는 되는데 snapshot이나 navigate가 실패하면, 브라우저 control plane 전체보다 페이지 접근 정책, SSRF 정책, 프로필 경로를 먼저 의심하라고 안내한다.
즉 이런 식으로 해석하면 된다.
- status OK
- tabs OK
- snapshot 실패
이 조합은 “브라우저가 완전히 죽었다”보다 지금 열려는 대상 또는 사용 중인 프로필이 문제일 가능성이 높다. 예를 들어 공개 페이지 테스트는 openclaw로 먼저 자르고, 로그인 세션이 꼭 필요한 경우만 user 경로로 다시 보는 편이 낫다.
5) remote면 마지막에 SSH/포트 점검을 붙인다
remote 환경이라면 아래같이 아주 기본적인 포트·별칭 점검을 함께 붙이는 편이 좋다.
lsof -nP -iTCP:18789 -sTCP:LISTEN
ssh -G relay39 | egrep '^(hostname|user|identityfile) '
ssh -o BatchMode=yes relay39 'echo relay39-ok'이 단계는 화려하지 않지만 효과가 크다. 포워딩 경로가 어긋난 상태에서 browser만 만져 봐야 같은 증상이 반복되기 때문이다.
현장 미니 사례 2개
사례 A) 서비스는 살아 있는데 snapshot만 계속 실패한 경우
- 상황:
gateway status는 정상처럼 보였고 browser도 가끔 반응했음 - 실제 원인: 단순 status만 봤고, RPC 상태와 browser control plane을 분리하지 못함
- 복구:
gateway status --require-rpc→gateway probe→browser status/tabs/snapshot순서로 다시 확인 - 검증:
tabs와snapshot이 모두 통과하는 공개 페이지로 먼저 재테스트
사례 B) remote gateway에서 간헐적으로 browser가 먹통처럼 보인 경우
- 상황: 같은 명령이 어떤 날은 되고 어떤 날은 실패함
- 실제 원인: 원격 포워딩과 실제 probe 대상이 매번 달라지는 drift 상태
- 복구:
gateway probe로 active target을 먼저 확인하고 SSH 포워딩 정리 - 검증: loopback/remote 중 어느 쪽이 실제 winner인지 고정한 뒤 browser 재시도
운영자가 바로 판단하는 기준
| 상황 | 먼저 볼 것 | 이유 |
|---|---|---|
gateway status만 정상 | --require-rpc 재확인 | 서비스 up과 RPC health는 다르다 |
| browser 전체가 막힌 듯함 | browser status | control plane 자체 이상인지 먼저 가른다 |
tabs까진 됨 | snapshot 실패 원인 분리 | 프로필/정책/대상 페이지 문제일 수 있다 |
| remote에서만 이상 | gateway probe | 실제 어느 target에 붙는지 확인해야 한다 |
| 증상이 들쭉날쭉 | SSH/포트/remote drift | 같은 gateway를 보고 있지 않을 가능성이 있다 |
검색형 FAQ
Q1. gateway status가 정상이면 browser도 정상 아닌가요?
꼭 그렇진 않다. 공식 문서 기준으로 gateway status는 서비스 상태와 RPC probe가 함께 섞여 있다. 자동화에서는 --require-rpc까지 확인해야 더 정확하다.
Q2. 왜 browser 재시작만으로 안 풀리나요?
실제 원인이 브라우저 자체가 아니라 Gateway RPC, active target drift, 포워딩 경로 문제일 수 있기 때문이다. 이 경우 브라우저만 다시 띄워도 같은 증상이 반복된다.
Q3. status와 tabs는 되는데 snapshot만 안 되면 무엇을 봐야 하나요?
공식 browser 문서 기준으로는 브라우저 control plane 전체보다 페이지 정책, 프로필 경로, 접근 제한을 먼저 의심하는 편이 맞다.
Q4. remote gateway에서는 무엇이 제일 중요하나요?
내가 보고 있는 브라우저와, 실제 Gateway가 붙는 target이 같은지부터 확인하는 것이 중요하다. 그래서 gateway probe가 생각보다 자주 답이 된다.
Q5. 가장 짧은 복구 순서는 무엇인가요?
gateway status --require-rpc → gateway probe → browser status → tabs → snapshot 이 순서가 가장 빠르다. 이 흐름이면 gateway 문제와 browser 문제를 섞지 않고 자를 수 있다.
내부링크·다음글 연결 (10)
- 32. OpenClaw browser에서 Access denied가 뜰 때 해결
- 15. gateway token mismatch로 remote unauthorized 뜰 때 해결
- 27. OpenClaw 대시보드가 안 열릴 때 해결
- 28. OpenClaw 예전 세션이 계속 붙을 때 정리
- 30. OpenClaw 채널은 연결됐는데 답이 없을 때 해결
- 01. 크롬 9222 연결 오류 해결
- 12. 브라우저 릴레이 연동 구조
- 11. 연동 체크
- systemd 충돌 해결
- Troubleshooting 허브
한 줄 결론
openclaw gateway status가 정상처럼 보여도 browser가 바로 정상이라는 뜻은 아니다.
가장 빠른 복구는 --require-rpc로 Gateway RPC를 먼저 자르고, 그다음 browser를 status → tabs → snapshot으로 짧게 분리해서 보는 것이다.
※ 이 문서는 생성형 AI를 활용해 작성되었습니다.