old_wsi != wsi 가드가 있어 자기 연결을 닫지는 않습니다. 제 재-HELLO 가설은 그 부분은 틀렸습니다. 다만 재등록 시 슬롯 번호가 바뀌고 alias가 초기화 됩니다. 디스패치가 무엇으로 찾는지가 관건입니다. 명령 실행함 핵심을 찾았습니다. 반복 HELLO는 무시됩니다 ( hello after already-registered, ignored ) — 응답도 없습니다. 즉 제 재-HELLO는 무해하지만 무의미했습니다. 진짜 문제는 슬롯 키입니다. 디스패치가 무엇으로 찾는지 봅니다. 명령 4개 실행함 · 2 노트 결함을 찾았습니다. mr_slot_bind_alias 의 별칭 충돌 검사에서 find_by_uuid_locked(alias_uuid) 를 씁니다. 그런데 이 함수는 정규 UUID뿐 아니라 별칭까지 훑습니다. 즉 재접속 시 이전 연결의 별칭이 아직 남아 있으면 자기 자신의 별칭을 "남의 것"으로 오인해 거부 합니다. 그 결과 슬롯은 등록되지만 별칭이 안 붙어, 대시보드 UUID로는 영영 찾을 수 없습니다. 거부 시 연결까지 끊는지 확인합니다. 명령 10개 실행함, 파일 읽음 · 8 노트 릴레이 소스를 보니 원인이 나왔습니다. 에이전트가 아니라 릴레이 문제였습니다. 제가 에이전트만 보고 세 번 헛짚은 이유입니다. 원인 — 릴레이가 자기 자신을 남으로 오인 mr_slot_bind_alias() 의 충돌 검사 두 곳이 잘못됐습니다. 첫째 , 별칭 도용 검사에 find_by_uuid_locked() 를 씁니다. 이 함수는 정규 uuid를 훑은 뒤 별칭까지 훑습니다. 그래서 이전 연결 슬롯이 아직 정리되지 않은 상태에서 같은 에이전트가 재접속하면, 자기가 직전에 쓰던 별칭 때문에 자기가 거부 됩니다. 둘째 , 낡은 슬롯이 같은 별칭을 들고 있으면 같은 인증서인데도 무조건 거부합니다. 그리고 호출부는 이 -2 를 신원 도용으로 보고: c send_frame(... "UUID_CONFLICT"); mr_slot_cleanup(slot); lws_set_timeout(wsi, PENDING_TIMEOUT_CLOSE_SEND, 1); // 연결 종료 슬롯을 지우고 연결을 끊습니다. 재접속하면 같은 일이 반복됩니다. 에이전트는 정상이고 HELLO도 정상인데 대시보드 UUID(별칭)로는 영영 못 찾습니다. 에이전트 재시작으로 가끔 풀린 것도 설명됩니다 — 타이밍이 맞아 이전 슬롯이 먼저 정리되면 별칭이 붙습니다. 수정 3가지 정규 uuid 전용 조회 추가 — 별칭 도용 검사에 별칭을 보지 않습니다 인증서 지문이 같으면 별칭 인수 — 같은 노드면 낡은 슬롯에서 넘겨받습니다. 지문이 다르면 종전대로 차단 반복 HELLO에 ACK 응답 — 무응답이면 에이전트가 등록 실패로 보고 멀쩡한 연결을 끊습니다 검증에서 재접속은 통과하고, 다른 인증서의 별칭·정규 uuid 도용은 둘 다 차단 됩니다. 보안은 그대로입니다. 적용 # 릴레이 (7490fb, FreeBSD) cd mihosrc_p2 && <빌드> && sudo service mihosrc restart grep -a 'alias bound\|UUID_CONFLICT' /var/log/mihosrc.log | tail -20 slot alias bound 가 보이고 UUID_CONFLICT 가 사라지면 해결입니다. 그 뒤 디스크 목록도 정상적으로 뜹니다 — 명령이 도달하지 못해서 안 보였던 것이니까요. 에이전트는 8.7.53을 같이 올리시면 됩니다(재-HELLO 기본 끔 + 스토리지 풀 자동 생성).