일하는 ai

27. OpenClaw 대시보드가 안 열릴 때

10 min read

-

브라우저에서 OpenClaw 대시보드가 안 열리면, 사람들은 보통 URL부터 몇 번 더 새로고침한다. 그런데 실제로는 브라우저 문제보다 Gateway가 안 떠 있거나, 접속 주소를 헷갈리거나, 원격 접속인데 pairing 승인이 안 된 경우가 더 많다. 그래서 이 문제는 “왜 안 열리지?”라고 넓게 보지 말고, Gateway 실행 → 접속 주소 → pairing 필요 여부 순서로 자르는 편이 가장 빠르다.

공식 문서 기준으로도 흐름은 단순하다. 설치 뒤에는 openclaw gateway status로 Gateway가 살아 있는지 보고, 그다음 openclaw dashboard 또는 http://127.0.0.1:18789/로 들어가면 된다. 즉, 대시보드 문제처럼 보여도 출발점은 거의 항상 Gateway 상태 확인이다.

안내: 이 문서는 생성형 AI로 초안을 구성한 뒤, OpenClaw 공식 문서와 실제 openclaw gateway status 확인 흐름을 기준으로 점검해 정리했습니다.

flowchart LR
A[대시보드 안 열림] --> B{Gateway 살아있나?}
B -- 아니오 --> C[openclaw gateway status 확인]
B -- 예 --> D{접속 주소 맞나?}
D -- 아니오 --> E[127.0.0.1:18789 또는 dashboard 명령]
D -- 예 --> F{원격 접속인가?}
F -- 아니오 --> G[로컬 브라우저 재확인]
F -- 예 --> H[pairing required 여부 확인]
H --> I[devices list / approve]

칠판 치트시트

  1. 새로고침보다 먼저 openclaw gateway status를 본다
  2. 로컬이면 http://127.0.0.1:18789/가 기본이다
  3. 원격이면 페이지가 열려도 pairing approval이 필요할 수 있다
  4. disconnected (1008): pairing required는 고장보다 승인 대기에 가깝다
  5. 초보자 막힘은 거의 Gateway 미기동 / 주소 혼동 / pairing 미승인 셋 중 하나다

가장 빨리 확인하는 순서

1) Gateway가 살아 있는지 본다

가장 먼저 볼 것은 브라우저가 아니라 Gateway다.

openclaw gateway status

정상이라면 보통 아래 성격의 정보가 나온다.

  • 서비스가 systemd/launchd 등으로 실행 중인지
  • 어떤 포트에서 듣고 있는지
  • Dashboard 주소가 무엇인지
  • RPC probe가 살아 있는지

실제로 점검해 보면 이런 식으로 확인된다.

  • Runtime: running
  • Listening: *:18789
  • Dashboard: http://<host>:18789/
  • RPC probe: ok

여기서 Gateway가 안 떠 있으면, 브라우저를 아무리 건드려도 대시보드는 안 열린다.

2) 접속 주소를 단순하게 줄인다

공식 문서 기준 기본 주소는 아래 둘이다.

  • http://127.0.0.1:18789/
  • http://localhost:18789/

그리고 가장 쉬운 열기 명령은 이거다.

openclaw dashboard

초보자는 종종 LAN 주소, Tailnet 주소, 예전 포트 번호를 섞어 쓴다. 그래서 한 번 꼬였을 때는 복잡한 주소를 버리고 127.0.0.1 기본 주소로 먼저 돌아오는 편이 낫다.

3) 원격 접속이라면 pairing required를 의심한다

이건 대시보드가 “안 열리는” 문제처럼 보이지만, 사실은 열렸는데 연결 승인이 안 된 상태인 경우가 많다.

공식 Control UI 문서에는 새 브라우저/새 디바이스에서 접속할 때 one-time pairing approval이 필요하다고 나온다. 이때 자주 보이는 문구가 아래다.

  • disconnected (1008): pairing required

이 경우는 비밀번호를 다시 넣기보다, pending request를 승인해야 한다.

openclaw devices list
openclaw devices approve <requestId>

왜 자주 헷갈리나

원인 1) 대시보드 문제를 브라우저 문제로만 본다

실제로는 브라우저보다 Gateway 상태가 먼저다. Gateway가 안 떠 있으면 탭을 바꾸거나 캐시를 지워도 해결되지 않는다.

원인 2) 로컬 접속과 원격 접속을 섞는다

같은 18789 포트라도, 로컬 127.0.0.1 접속과 LAN/Tailnet 원격 접속은 느낌이 다르다. 로컬은 비교적 단순하지만, 원격은 pairing 승인까지 함께 봐야 한다.

원인 3) 대시보드 URL이 바뀐 줄 모르고 예전 주소를 계속 쓴다

gateway.controlUi.basePath를 따로 쓰거나, 예전에 저장한 주소가 남아 있으면 헷갈릴 수 있다. 그래서 문제를 자를 때는 항상 기본 주소부터 다시 보는 게 좋다.

5분 복구 루틴

A. Gateway부터 확인

openclaw gateway status
  • running이 아니면 서비스가 먼저 문제다
  • 포트가 18789인지 확인한다
  • Dashboard 주소가 무엇으로 찍히는지 확인한다

B. 가장 단순한 주소로 접속

  • http://127.0.0.1:18789/
  • 안 되면 openclaw dashboard

여기서도 안 열리면, 주소보다 Gateway 또는 방화벽/바인딩 쪽을 의심하는 게 맞다.

C. 원격이면 pairing 여부 확인

브라우저에 pairing required가 보이면 아래 순서로 끝낸다.

openclaw devices list
openclaw devices approve <requestId>

D. 설치 직후라면 onboard 흐름으로 되돌아간다

처음 설치 직후인데 대시보드가 안 열리면, 수동 복구보다 onboarding이 중간에 잘 끝났는지 먼저 보는 편이 빠르다.

openclaw onboard --install-daemon

현장 미니 사례

사례 A) 대시보드가 안 열려서 브라우저 캐시부터 지움

  • 상황: 페이지가 안 열려서 브라우저 문제라고 생각함
  • 실제: openclaw gateway status를 보니 Gateway가 아예 실행 안 된 상태였음
  • 해결: Gateway 상태부터 확인하고 서비스 정상화 후 재접속
  • 결과: 브라우저 건드릴 필요 없이 복구

사례 B) 원격 주소로는 페이지가 뜨는데 연결이 바로 끊김

  • 상황: URL은 맞는 것 같은데 접속 직후 끊겨서 서버 불안정으로 오해함
  • 실제: 새 브라우저의 one-time pairing approval이 필요했음
  • 해결: openclaw devices list로 pending request 확인 후 approve
  • 결과: 접속 유지 정상화

설치 직후 체크리스트

  • openclaw gateway status에서 running 확인
  • http://127.0.0.1:18789/ 또는 openclaw dashboard로 접속 확인
  • 원격 접속이면 pairing required 여부 확인
  • openclaw devices list에 승인 대기 항목이 없는지 확인
  • 설치 직후라면 openclaw onboard --install-daemon 흐름이 끝났는지 확인

한 줄 결론

OpenClaw 대시보드가 안 열릴 때는 브라우저부터 만지지 말고, Gateway가 떠 있는지 → 접속 주소가 맞는지 → pairing 승인이 필요한지 이 세 단계로 나누면 대부분 빠르게 풀린다.

상황별 바로 다음 글 10선

AI 활용 고지

이 문서는 생성형 AI를 활용해 초안을 구성했고, OpenClaw 공개 문서와 실제 상태 확인 흐름을 함께 검토해 정리했습니다.

그래프 뷰

백링크