openclaw channels status --probe를 돌렸는데 기대한 works가 안 보이거나, 특정 채널만 계속 흔들리면 많은 사람이 그 순간부터 재로그인이나 재설치를 먼저 떠올린다. 그런데 OpenClaw 공식 문서 기준으로 이 명령은 단순 연결 확인이 아니라 계정별 transport 상태와 probe 결과를 좁혀 보는 진단 도구에 가깝다. 그래서 실패를 봤을 때도 바로 다시 까는 것보다, 어느 층이 실패했는지 먼저 자르는 편이 훨씬 빠르다.
공식 gateway troubleshooting과 channel troubleshooting은 공통으로 openclaw status → openclaw gateway status → openclaw logs --follow → openclaw doctor → openclaw channels status --probe 사다리를 먼저 보라고 안내한다. CLI help도 openclaw channels status --probe를 “channel status checks and probes”로 설명한다. 핵심은 간단하다. probe 실패는 채널 전체 장애일 수도 있지만, 더 자주 보이는 것은 특정 계정, 특정 정책, 특정 transport 축의 실패다.
안내: 본문은 생성형 AI로 초안을 정리하고, OpenClaw 공식 문서와 실제 CLI help 출력을 교차 확인해 보정했습니다.
flowchart TD A[`openclaw channels status --probe`] --> B{무엇이 실패했나?} B -->|gateway 자체 이상| C[`openclaw gateway status`] B -->|특정 채널/계정만 실패| D[`openclaw logs --follow`] B -->|probe는 되지만 실제 답이 없음| E[pairing / mention / allowlist 확인] C --> F[`openclaw doctor`] D --> G{DM인가 그룹인가?} G -->|DM| H[`openclaw pairing list`] G -->|그룹| I[`groupPolicy` `requireMention` 확인] E --> J[[Tip/Troubleshooting/30-OpenClaw-채널연결됐는데-답이없을때-해결|30번 문서로 이동]] F --> K[설정/서비스 축 복구] H --> L[승인 또는 DM 정책 조정] I --> M[멘션/allowlist 범위 조정] K --> N[다시 probe] L --> N M --> N
칠판 치트시트
--probe는 연결 여부보다 채널별 실제 점검 결과를 좁혀 보는 명령이다works나audit ok가 안 보이면 채널 전체보다 계정 범위를 먼저 의심한다- DM 무반응은 pairing, 그룹 무반응은 mention gating이 먼저다
- probe 실패와 실제 답장 실패는 겹치지만 완전히 같은 문제는 아니다
status → gateway status → logs → doctor → channels status --probe순서를 거꾸로 하지 않는 편이 빠르다
이런 증상이면 이 문서가 바로 맞다
openclaw channels status --probe를 돌렸는데 특정 채널만 실패한다.openclaw status는 괜찮아 보이는데 probe에서 transport가 흔들린다.- 채널은 연결된 것 같은데
works나audit ok가 안 보인다. - Slack, Telegram, Discord 중 일부 채널만 probe 결과가 다르게 나온다.
- 실제 답이 없어서 봤더니 probe도 애매하고 logs를 어디부터 봐야 할지 모르겠다.
먼저 알아둘 것, probe는 “답장 가능”을 100퍼센트 보장하는 명령이 아니다
공식 gateway troubleshooting 문서는 healthy signal 예시로 Runtime: running, Connectivity probe: ok, 그리고 openclaw channels status --probe에서 계정별 live transport status와 works 또는 audit ok 같은 결과를 제시한다. 여기서 중요한 점은, probe가 잘 나왔더라도 실제 답장 정책까지 모두 통과했다는 뜻은 아니라는 점이다.
작은 미니 케이스로 보면 더 쉽다. Telegram 계정의 transport는 살아 있지만 그룹에서 멘션이 빠져 답장이 없는 경우가 있고, Discord bot은 온라인인데 guild/channel allowlist가 안 맞아 실제 반응이 없는 경우도 있다. 이때 probe는 “연결은 살아 있다”고 보여 줄 수 있지만, 실제 운영 체감은 여전히 고장처럼 느껴진다.
즉 probe는 매우 중요하지만, 의미를 정확히 읽어야 한다. 연결 계층을 자르는 데는 강하고, 정책 계층까지 자동으로 해결해 주지는 않는다.
가장 빠른 5분 점검 순서
1) 먼저 status와 gateway status로 바닥이 살아 있는지 본다
공식 runbook이 channels status --probe보다 먼저 openclaw status와 openclaw gateway status를 두는 이유가 있다. gateway 자체가 흔들리면 채널 probe 결과도 연쇄적으로 이상해질 수 있기 때문이다.
openclaw status
openclaw gateway status
openclaw channels status --probe이 순서로 보면 판단이 빨라진다.
gateway status도 비정상이면 채널보다 서비스 축이 먼저다.gateway는 정상인데 특정 채널 probe만 흔들리면 계정별 문제 가능성이 크다.status는 안정적이고 probe도 안정적인데 실제 답이 없으면 정책 축으로 내려가야 한다.
2) probe 실패가 특정 채널 하나인지, 계정 전체인지 자른다
CLI help 기준으로 openclaw channels status는 gateway channel status를 보여 주고 --probe는 credential/probe 점검을 추가한다. 실무에서는 여기서 한 채널만 실패하는지, 같은 채널의 특정 계정만 실패하는지를 먼저 가르는 편이 빠르다.
예를 들어 Slack만 실패하면 Slack 토큰이나 app token, bot token 축으로 좁혀지고, Telegram만 실패하면 API 호출, DNS, polling 축을 먼저 본다. 반대로 여러 채널이 동시에 흔들리면 채널별 문제가 아니라 gateway, 네트워크, 설정 변경 쪽일 수 있다.
3) DM이면 pairing, 그룹이면 mention gating을 바로 확인한다
공식 pairing 문서는 DM policy가 pairing일 때 승인 전 메시지는 처리되지 않는다고 설명한다. 또 groups 문서는 그룹 기본값이 allowlist이며 reply triggering은 requireMention 같은 mention gating을 따른다고 정리한다.
그래서 probe가 얼핏 괜찮아도 실제 반응이 없으면 아래처럼 자르는 편이 맞다.
- DM 무반응:
openclaw pairing list <channel> - 그룹 무반응:
groupPolicy,groups,groupAllowFrom,requireMention
이 분기를 빼먹으면 probe 결과만 보고 괜히 토큰 재발급부터 하게 된다.
4) logs에서 드롭 시그니처를 같이 본다
공식 gateway troubleshooting과 channel troubleshooting은 logs를 매우 앞단에 둔다. 이유는 단순하다. probe만 보면 “안 됨”까지만 보이지만, 로그를 보면 왜 안 되는지가 드러나기 때문이다.
openclaw logs --follow특히 아래 같은 문자열은 바로 힌트가 된다.
pairing requestdrop guild message (mention requiredblockedallowlist
즉 probe 실패 자체보다 로그의 실패 서명이 더 직접적인 경우가 많다.
5) 구조 문제가 남으면 마지막에 doctor로 내려간다
공식 문서의 사다리에서도 doctor는 probe보다 앞이나, 실무에서는 probe와 logs로 범위를 좁힌 뒤 구조 문제를 정리할 때 더 가치가 크다. 예를 들어 channel credential 배치, service config, auth drift가 의심되면 openclaw doctor가 빠른 확인점이 된다.
이 흐름은 41. OpenClaw doctor 경고 우선순위 정리와도 자연스럽게 이어진다.
채널별로 자주 갈리는 실패 패턴
Telegram, bot은 살아 있는데 그룹만 조용한 경우
공식 channel troubleshooting은 Telegram에서 “bot online but group stays silent”일 때 mention requirement와 bot privacy mode를 먼저 보라고 정리한다. 이 경우 probe가 transport connected처럼 보여도, 실제로는 그룹 가시성이나 멘션 정책이 병목일 수 있다.
작은 미니 케이스를 들면 이렇다. /start는 되는데 그룹방에서 아무 반응이 없다면, 토큰보다 privacy mode와 멘션 조건이 먼저다. 이때는 30번과 21번을 함께 보는 편이 빠르다.
Slack, 연결은 있어 보이는데 configured_unavailable처럼 흔들리는 경우
공식 channel troubleshooting은 Slack에서 socket mode는 connected처럼 보이는데 responses가 없을 때 app token, bot token, required scopes를 먼저 확인하라고 설명한다. SecretRef 기반 설정에서는 botTokenStatus나 appTokenStatus = configured_unavailable 같은 상태를 같이 보라고도 적혀 있다.
이 상황은 눈으로 볼 때 꽤 헷갈린다. 설정은 넣은 것 같은데 probe만 흔들리기 때문이다. 이때는 무조건 재로그인보다 현재 command path에서 자격증명이 실제로 읽히는지를 먼저 보는 편이 낫다.
Discord, 온라인인데 guild replies만 안 나오는 경우
공식 channel troubleshooting은 Discord에서 bot online but no guild replies일 때 openclaw channels status --probe와 함께 guild/channel allow와 message content intent를 보라고 안내한다. 즉 probe는 입구일 뿐이고, guild 설정 범위가 빠져 있으면 실제 반응은 계속 없을 수 있다.
이 경우는 “연결 실패”보다 권한 범위와 group policy 실패에 더 가깝다. 그래서 probe만 보지 말고 groups 문서의 allowlist 구조까지 같이 보는 편이 안전하다.
운영자가 바로 판단하는 기준
| 상황 | 먼저 볼 것 | 이유 |
|---|---|---|
| 여러 채널이 동시에 흔들림 | openclaw gateway status | 채널별 문제보다 서비스/네트워크 축일 가능성이 큼 |
| 특정 채널만 probe 실패 | 해당 채널 logs + 자격증명 범위 | 계정별 transport 또는 credential 문제를 빨리 좁힐 수 있음 |
| probe는 괜찮은데 DM만 무반응 | openclaw pairing list | 승인 전 메시지는 처리되지 않을 수 있음 |
| probe는 괜찮은데 그룹만 무반응 | requireMention, groupPolicy, groupAllowFrom | 그룹은 연결과 응답 조건이 분리됨 |
| status 경고도 같이 많음 | 42번 | probe 문제와 status 경고를 분리해서 읽어야 함 |
검색형 FAQ
Q1. openclaw channels status --probe가 실패하면 바로 재로그인해야 하나요?
대개는 아니다. 공식 문서 기준으로는 먼저 status, gateway status, logs, doctor 순서를 거친 뒤 probe를 해석하는 편이 더 빠르다. 여러 채널이 동시에 흔들리면 채널 토큰 문제가 아닐 수도 있다.
Q2. probe가 성공이면 실제 답장도 무조건 성공인가요?
그렇지 않다. probe는 transport와 계정 상태 확인에는 강하지만, DM pairing이나 그룹 mention gating 같은 정책 계층까지 자동 보장하지는 않는다.
Q3. DM만 안 되는데 probe는 괜찮으면 어디를 봐야 하나요?
공식 pairing 문서 기준으로는 DM policy가 pairing일 수 있다. 이때는 openclaw pairing list <channel>로 승인 대기 상태를 먼저 보는 편이 맞다.
Q4. 그룹만 안 되는데 probe는 괜찮으면 어디를 봐야 하나요?
공식 groups 문서 기준으로는 groupPolicy, groups, groupAllowFrom, requireMention을 먼저 봐야 한다. 그룹은 기본적으로 더 제한적이다.
Q5. works나 audit ok가 안 보이면 무조건 장애인가요?
그렇게 단정하기는 이르다. transport 결과, 자격증명 가시성, policy drop이 섞일 수 있다. logs와 실제 증상을 함께 봐야 한다.
다음 읽기
- 30. OpenClaw 채널은 연결됐는데 답이 없을 때 해결
- 41. OpenClaw doctor에서 경고가 여러 개 뜰 때 우선순위 정리
- 42. OpenClaw status —all에서 경고가 떠도 먼저 볼 것
- 27. OpenClaw 대시보드가 안 열릴 때 해결
- 33. OpenClaw gateway status는 정상인데 browser가 안 될 때 해결
- 21. 텔레그램 Privacy Mode 때문에 반응 없을 때 복구
- 17. cron은 돌았는데 텔레그램 전달이 안 올 때
- 🚀 OpenClaw 허브
- Troubleshooting 허브
한 줄 결론
openclaw channels status --probe는 “채널이 붙었는가”보다 어느 채널, 어느 계정, 어느 정책 층에서 막혔는지 자르는 명령으로 읽는 편이 훨씬 유용하다.
※ 이 문서는 생성형 AI를 활용해 작성되었습니다.