이 스레드에서 가장 강력한 테스트는 라우터를 교체한 것입니다. TP-Link Deco 메시를 통해 서로를 검색하지 못했던 동일한 ZimaOS 서버와 모바일 클라이언트가 ISP에서 제공한 ZTE 라우터 뒤에서 서버를 테스트했을 때는 즉시 작동했습니다. 따라서 원래 사례는 로컬 검색/멀티캐스트 문제였으며, ZimaOS 서버 자체가 오프라인이었다는 증거는 아닙니다.
이후 스레드에서는 mDNS 리플렉터 활성화를 포함한 커뮤니티 Avahi 변경 사항을 시도했지만, 원글 작성자는 이러한 변경으로 Deco 사례가 해결되지 않았다고 확인했습니다. 현재 ZimaOS는 더 나은 대체 방법을 제공합니다. 최신 시작하기 문서에 따르면 로컬 검색에 실패할 경우 브라우저에서 장치의 IP 주소를 직접 열 수 있으며, Remote ID/Network ID를 통해 또 다른 장치 식별 경로를 사용할 수도 있습니다.
이는 실제로 iOS만의 문제가 아니었습니다
2페이지에서 santhora는 Android에서도 서버를 검색하지 못했다고 강조했습니다. 따라서 이는 iOS 권한이나 Apple 전용 클라이언트의 문제로 한정되지 않았습니다.
네트워크 구성은 단순했습니다. Deco 메인 장치 → 2.5GbE → Beelink ZimaOS 서버였고, 휴대폰은 Deco 시스템에 Wi-Fi로 연결되어 있었습니다.
ISP 라우터 테스트가 가장 효과적인 격리 테스트였습니다
클라이언트 격리는 이미 비활성화되어 있었습니다
원문에서는 Deco의 클라이언트/격리 설정을 확인했고, 비활성화되어 있다고 밝혔습니다. 휴대폰과 ZimaOS 장치를 동일한 Deco 장치에 연결해도 검색 기능은 복구되지 않았습니다.
이는 “AP 격리를 끄라”는 조언이 좋은 첫 번째 확인 사항이기는 하지만, 여기서는 최종 해결책이 아니었다는 점에서 중요합니다.
Avahi 리플렉터 수정은 작동하지 않았습니다
커뮤니티의 한 답변에서는 /etc/avahi/avahi-daemon.conf를 편집하고 리플렉터를 활성화하라고 제안했습니다. 사용자가 이를 시도했지만 변경 사항이 없다고 보고했습니다.
이 해결 방법이 실패했기 때문에 스레드에서는 변경 사항을 되돌리라고 안내했습니다. 포럼에서 제안되었다는 이유만으로 오래된 검색 설정을 그대로 남겨 두지 마세요.
현재 ZimaOS는 브라우저를 통한 직접 IP 접근을 공식적으로 지원합니다
현재 IceWhale 시작하기 문서에서는 ZimaClient가 장치를 찾지 못할 경우 라우터의 DHCP 클라이언트 목록에서 서버 IP를 확인한 뒤 해당 IP를 브라우저에 입력하라고 안내합니다. 설정/대시보드 화면은 동일합니다.
Avahi를 수정하기 전에 현재 지원되는 직접 IP 대체 방법을 사용하세요.
Remote ID는 또 다른 지원되는 식별 경로를 제공합니다
현재 ZimaOS 문서에서는 설정 → 네트워크에서 Remote ID/NetworkID를 확인할 수 있습니다. 이 정보는 장치를 식별하고 접근 권한을 공유하는 데 사용될 수 있으므로 자격 증명처럼 취급하세요.
현재 Remote ID 접근 방식을 확인하세요.
Deco 또는 다른 메시 시스템에서 확인할 사항
- 클라이언트/AP 격리;
- 게스트 네트워크 분리;
- 유선 및 무선 세그먼트 간 멀티캐스트/mDNS 전달;
- VLAN 분리;
- 클라이언트가 이동할 때 메시 노드의 동작;
- 펌웨어 업데이트 및 제조업체별 멀티캐스트 옵션.
인터넷에 정상적으로 연결되고 핑이 성공하더라도 멀티캐스트 서비스 검색이 전달되고 있다고 단정할 수는 없습니다.
ZimaClient 검색 FAQ
IPv6를 비활성화하면 원래 사례가 해결되었나요?
아니요. 사용자는 IPv6를 비활성화해도 도움이 되지 않았다고 명확히 보고했습니다.
Avahi 리플렉터를 활성화하면 Deco 메시 문제가 해결되었나요?
아니요. 원글 작성자가 이를 시도했지만 변경 사항이 없다고 보고했습니다.
로컬 검색에 실패했을 때 현재 가장 안전한 대체 방법은 무엇인가요?
장치의 LAN IP를 브라우저에서 사용하거나, 검증되지 않은 호스트 서비스 설정을 수정하는 대신 지원되는 Remote ID/원격 접근 경로를 사용하세요.
