이 2026년 5월 스레드는 ZimaOS를 하룻밤 장시간 사용한 뒤 느낀 답답한 첫인상에서 시작되었습니다. AdGuard Home과 Pi-hole은 사용자의 192.168.60.0/24 LAN이 아닌 격리된 Docker 네트워크에서 실행되는 것처럼 보였고, Jellyfin은 여러 번 시도한 후에야 작동했으며, MacBook Pro의 Time Machine 백업은 실패했습니다. 그러나 추가 테스트 후 처음의 결론 중 두 가지가 바뀌었습니다. AdGuard Home은 정상적으로 작동하게 되었고, Time Machine 문제는 MacBook을 TrueNAS 공유 폴더에 연결했을 때도 재현되어 ZimaOS의 문제일 가능성이 낮아졌습니다.
따라서 이 스레드는 운영 체제에 대한 평가라기보다 문제 해결 사례로서 더 유용합니다. NAS 플랫폼 자체를 탓하기 전에 Docker 네트워킹, 애플리케이션 템플릿, 클라이언트 측 백업 동작을 서로 분리해 확인해야 하는 이유를 보여주기 때문입니다.
AdGuard 설정 마법사에 LAN IP 대신 Docker 주소가 표시됨
표준 설치 후 사용자의 AdGuard Home 설정 화면에는 127.0.0.1 및 172.17.0.2와 같은 주소가 표시되었습니다. 사용자는 ZimaOS 호스트의 고정 LAN 주소인 192.168.60.241이 표시되기를 기대했습니다.
호스트 네트워킹으로 전환해도 깔끔한 해결책은 아니었음
사용자는 Compose 네트워크 모드를 host로 변경하는 커뮤니티 방식의 해결책을 찾았습니다. 앱 설정도 변경한 후 설치된 앱에 접근할 수 없게 되었습니다. 이 결과가 중요한 이유는 호스트 네트워킹이 포트 소유권과 App Store 템플릿의 전제를 모두 바꾸기 때문입니다.
DNS 컨테이너의 보편적인 해결책으로 network_mode: host를 사용하지 마세요. 앱에 실제로 호스트 수준의 네트워크 가시성이 필요한 경우에는 유용할 수 있지만, ZimaOS 대시보드나 다른 DNS 리졸버 또는 다른 컨테이너와 포트 충돌을 일으킬 수도 있습니다.
결국 다른 앱 변형으로 AdGuard를 작동시킴
원 작성자는 나중에 스레드를 업데이트하면서 기본 패키지 대신 AdGuard 앱의 Network 버전을 사용하고 필요한 웹 인터페이스 포트 매핑을 추가하는 안내를 찾았다고 밝혔습니다. 설정 도우미에는 여전히 예상했던 192.168.60.x 주소가 표시되지 않았지만 AdGuard는 정상적으로 작동했습니다.
이는 중요한 진단 원칙을 확인해 줍니다. LAN 클라이언트의 DNS 요청에 응답하기 위해 컨테이너의 설정 마법사에 호스트의 LAN 주소가 표시될 필요는 없습니다. 중요한 것은 공개된 DNS 포트와 웹 포트에 네트워크에서 접근할 수 있는지 여부입니다.
ZimaOS 호스트 자체에는 유효한 고정 네트워크 구성이 있었음
DNS 컨테이너에서는 보기 좋은 마법사 주소보다 올바른 포트가 더 중요함
AdGuard Home과 Pi-hole은 일반적인 웹 애플리케이션보다 네트워킹에 더 민감합니다. 클라이언트가 일반적으로 UDP와 TCP 모두에서 포트 53을 통해 DNS에 접근해야 하기 때문입니다. 관리 UI는 별도의 웹 포트를 사용합니다.
DNS 앱이 정상 상태로 표시되지만 LAN 클라이언트에서 사용할 수 없다면 호스트의 고정 IP를 변경하기 전에 실제로 공개된 포트와 다른 서비스가 이미 포트 53을 사용하고 있는지 확인하세요.
Jellyfin이 작동한 것은 Docker 또는 저장소 전체의 장애가 아님을 보여줌
사용자는 결국 Jellyfin이 작동했다고 말했습니다. 이는 AdGuard의 네트워킹이 올바르다는 것을 증명하지는 않지만, 동일한 설치 환경에서 ZimaOS가 Docker 애플리케이션을 실행하고 미디어 저장소에 접근할 수 있다는 점은 보여줍니다. 따라서 문제 해결의 초점을 전체 컨테이너 스택이 사용할 수 없는 상태라고 보기보다 애플리케이션별 네트워크 구성에 맞출 수 있었습니다.
Time Machine 오류는 MacBook을 따라 TrueNAS에서도 재현됨
스레드에서 가장 중요한 정정은 다음 날 나왔습니다. 사용자는 ZimaOS를 초기화하고 다시 설치한 뒤 Time Machine을 다시 테스트했습니다. Monterey를 실행하는 구형 Mac mini에서는 백업이 성공했지만 최신 MacBook에서는 여전히 실패했습니다.
그 후 TrueNAS의 Time Machine 공유 폴더를 사용해 보았지만 MacBook에서는 여기서도 실패했습니다. 이 교차 테스트를 통해 원인으로 추정되는 대상이 ZimaOS에서 MacBook 또는 macOS/SMB 동작 쪽으로 이동했습니다.
다른 NAS로 교차 테스트하는 것이 중요한 이유
동일한 클라이언트가 서로 독립적인 두 NAS 플랫폼에서 모두 실패하고, 다른 Mac은 ZimaOS 대상에 정상적으로 연결된다면 “ZimaOS의 Time Machine이 고장 났다”는 설명은 더 이상 가장 단순한 원인으로 보기 어렵습니다.
이는 NAS 문제 해결에 유용한 일반 원칙입니다. 연결의 한쪽만 한 번에 변경하세요. 두 번째 서버나 두 번째 클라이언트를 사용하면 문제가 서버를 따라가는지, 클라이언트를 따라가는지, 아니면 특정 조합에서만 발생하는지 빠르게 확인할 수 있습니다.
현재 ZimaOS는 최신 저장소 및 앱 설정을 기준으로 평가해야 함
원본 스레드는 2026년 5월의 ZimaOS를 다룹니다. 그 이후에도 앱 구성, YAML 편집, 저장소 관리, 백업 동작을 비롯한 플랫폼의 여러 부분이 계속 변경되었습니다. 새로 설치할 때는 2026년의 모든 App Store 템플릿이 그대로라고 가정하기보다, 이전 문제 해결 조언을 적용하기 전에 현재 ZimaOS 기능 및 저장소 모델부터 확인하세요.
새로 설치할 때 더 나은 테스트 순서
- 여러 앱을 설치하기 전에 저장소와 앱 데이터 위치를 설정합니다.
- Jellyfin 또는 다른 웹 서비스처럼 간단한 앱 하나가 작동하는지 확인합니다.
- DNS 앱의 경우 WebUI와 별도로 포트 53을 확인합니다.
- 기존 브리지 및 포트 매핑을 이해하기 전에는 호스트 네트워킹으로 전환하지 않습니다.
- 가능하다면 Time Machine에서 다른 Mac 또는 다른 SMB Time Machine 대상을 테스트합니다.
- 문제가 특정 구성 요소를 따라간다는 사실을 확인한 후에야 해당 구성 요소를 근본 원인으로 간주합니다.
새로운 ZimaOS 문제 해결 FAQ
원 작성자 환경에서 AdGuard Home은 결국 작동했나요?
예. 사용자는 Network 앱 변형과 추가 포트 구성을 사용하자 작동했다고 말했습니다.
AdGuard 설정 마법사에 예상했던 192.168.60.x 주소가 표시된 적이 있나요?
아니요. 하지만 애플리케이션은 정상적으로 작동했습니다. 마법사는 컨테이너에서 볼 수 있는 인터페이스를 표시하고 있었습니다.
Time Machine 오류의 원인이 ZimaOS라고 입증되었나요?
아니요. MacBook은 TrueNAS의 Time Machine 공유 폴더에서도 실패했지만, 구형 Mac mini는 ZimaOS에서 정상적으로 작동했습니다.
