브라우저 자동화 작업을 돌릴 때 Cannot connect to Chrome on port 9222가 뜨면, 대부분 “툴이 고장났다”로 생각하고 멈춥니다. 실제로는 고장이라기보다 실행 위치와 인증 방식이 어긋난 상태인 경우가 훨씬 많습니다. 이 글은 그 어긋남을 20분 안에 복구하는 실전 루틴입니다.
안내: 이 문서는 생성형 AI를 활용해 초안을 작성했고, 공개 문서와 실제 운영 사례를 기준으로 정리했습니다.
flowchart LR A[오류 발생: 9222 연결 실패] --> B[실행 위치 확인] B --> C[Chrome/Relay 상태 점검] C --> D[인증 방식 전환] D --> E[재검증]
🧠 칠판 치트시트
- 9222 오류의 핵심은 “도구 문제”보다 “환경 불일치”
- 원격 셸에서 로컬 Chrome에 직접 붙으려 하면 자주 실패
- 먼저 실행 위치/Chrome 상태를 확인하고, 그다음 인증 방식을 바꿔라
- 마지막엔 반드시 재검증 명령으로 닫아야 한다
한 줄 결론
9222 오류는 대부분 실행 위치 확인 → Chrome 상태 확인 → 인증 경로 전환 3단계로 복구됩니다.
왜 이 오류가 자주 생기나
Chrome 원격 디버깅 포트(9222)는 “Chrome이 실제로 떠 있는 위치”와 “명령을 실행한 위치”가 맞아야 안정적으로 붙습니다. 그래서 서버 SSH 환경에서 로컬 데스크톱 Chrome에 바로 붙으려 하면 실패가 반복됩니다.
- Chrome 원격 디버깅 공식 문서: https://developer.chrome.com/docs/devtools/remote-debugging/
원인 분해 (MECE)
1) 환경 원인
- Chrome이 켜진 머신과 명령을 실행한 머신이 다름
- 9222 포트를 열었지만 접근 가능한 네트워크 경로가 없음
2) 실행 원인
- 헤드리스/원격 환경에서 GUI 의존 인증을 강제로 시도
- 브라우저 확장/Relay 연결 없이 Chrome attach를 기대
3) 운영 원인
- 오류 이후 재검증 루틴이 없어 “고쳐진 줄 착각”
- 토큰 갱신 경로(파일 위치/권한) 혼선
20분 복구 루틴
0~5분: 실행 위치 확인
hostname
which openclaw
echo $DISPLAYDISPLAY가 비어 있고 원격 호스트라면, 로컬 Chrome attach 방식은 실패 가능성이 큽니다.
5~10분: Chrome/Relay 상태 확인
- Chrome이 실제 실행 중인지 확인
- OpenClaw Browser Relay를 쓰는 경우, 확장 아이콘이 붙은 탭인지 확인
- OpenClaw 동작/연결 상태 점검: https://docs.openclaw.ai
10~15분: 인증 방식 전환
- GUI attach가 막히면, provider 전환(예: openclaw/manual)로 우회
- 토큰 파일 경로를 고정해 중복 인증 루프를 끊기
15~20분: 재검증(필수)
# 예시: 인증 체크 후 최소 기능 명령 1회
nlm login --check
nlm notebook list | head -n 5- 체크 명령 + 실제 기능 명령까지 통과해야 “복구 완료”로 봅니다.
현장형 미니 사례
사례 A (실패)
원격 SSH 셸에서 계속 9222 연결만 재시도한 케이스. 포트 값만 바꾸며 반복하다 시간이 더 소모됐고, 실제 원인은 로컬 Chrome 미연결이었습니다.
사례 B (성공)
실행 위치를 먼저 확인하고, attach 대신 provider 전환으로 인증 경로를 바꾼 뒤 login --check + notebook list로 닫았습니다. 같은 오류가 다음날 재발하지 않았습니다.
복구 후 재발 방지 체크리스트
- 실행 위치(로컬/원격) 먼저 확인했는가
- Chrome/Relay 연결 여부를 눈으로 확인했는가
- 인증 방식 우회 경로를 문서에 남겼는가
- 체크 명령 + 실제 기능 명령으로 복구를 닫았는가
다음 읽기
※ AI 생성 결과물을 포함한 가이드입니다. 실제 환경에서는 공식 문서와 현재 버전 명령어를 함께 확인하세요.