이 자료는 일반적인 속도 테스트만으로는 느린 Docker/App Store 설치 문제를 진단하기에 충분하지 않은 이유를 보여 줍니다. 사용자의 ZimaBoard는 100Mbps 광섬유 연결을 사용했고 MySpeed에서도 정상적인 인터넷 처리량이 측정되었지만, 애플리케이션 이미지 다운로드 속도는 KB/s에 불과했으며 각 설치에 약 20~30분이 걸렸습니다.
IceWhale은 DNS를 의심했지만 증거는 엇갈립니다. 사용자는 AdGuard Home/Nginx를 비활성화하고 DNS를 Google의 8.8.8.8로 변경했지만 설치 속도는 여전히 느렸습니다. 며칠 후 1.4.4.4-1로 업데이트하고 DNS를 Cloudflare의 1.1.1.1로 변경한 뒤 재부팅하자 설치 속도가 정상으로 돌아왔습니다. 여러 변수가 동시에 변경되었으므로, 이 자료만으로는 DNS가 문제를 일으켰거나 해결했다고 입증할 수 없습니다.
빠른 속도 테스트만으로 Docker 레지스트리 다운로드 속도가 빠르다고 입증할 수는 없습니다
웹 속도 테스트는 가까운 테스트 서버에 연결됩니다. Docker 이미지 설치는 서로 다른 지역에 있는 DNS 리졸버, 레지스트리 엔드포인트, 인증 서비스 및 CDN 호스트에 연결할 수 있습니다.
정상적인 웹 탐색이나 빠른 로컬 속도 테스트와 느린 컨테이너 이미지 다운로드는 동시에 발생할 수 있습니다.
DNS는 합리적인 가설이었지만 자료만으로 입증되지는 않았습니다
사용자의 환경에는 AdGuard Home, Quad9 및 Nginx가 있었습니다. Giorgio는 DNS 관련 앱을 비활성화하고 1.1.1.1 또는 8.8.8.8 같은 공용 DNS를 사용해 보라고 제안했습니다.
첫 번째 대조 테스트인 DNS 관련 앱 비활성화 및 8.8.8.8로의 변경으로는 느린 설치 문제가 해결되지 않았습니다. 따라서 “AdGuard가 원인이었다”거나 “Google DNS로 해결된다”고 작성해서는 안 됩니다.
다른 컴퓨터에서 docker pull을 비교하세요
IceWhale의 다음 진단 질문은 특히 유용했습니다. 동일한 네트워크에 연결된 다른 컴퓨터에서 같은 이미지에 대해 Docker pull을 실행해 보라는 것이었습니다.
두 장치 모두 느리다면 ISP/레지스트리/CDN/DNS 라우팅을 조사하세요. ZimaOS만 느리다면 ZimaOS의 Docker/네트워크/시스템 상태에 집중하세요.
저장 공간과 쓰기 성능도 확인하세요
이미지 설치 과정에서는 레이어를 기록하고 압축 해제하기도 합니다. 시스템 디스크가 거의 가득 찼거나, 저장 장치가 느리거나 고장 나고 있거나, 동시에 많은 I/O가 발생하면 다운로드 자체는 정상이어도 설치가 네트워크 문제처럼 보일 수 있습니다.
최신 ZimaOS에서는 Docker 이미지/AppData를 더 큰 저장 장치로 옮기고 앱 저장 공간 사용량을 확인할 수 있습니다.
자료에서 복구 시 변경된 것은 DNS만이 아니었습니다
최종적으로 성공한 상태에는 다음이 포함되었습니다.
- ZimaOS가
1.4.4.4-1로 업데이트됨; - DNS가
1.1.1.1로 변경됨; - 서버가 재시작됨.
따라서 문제가 실제로 해결된 것은 맞지만 근본 원인은 밝혀지지 않았습니다.
현재 ZimaOS는 1.4.4보다 훨씬 최신 버전입니다
ZimaOS 1.7에서는 App Store 2.0이 도입되었으며, 이후 릴리스에서는 Docker 시작, 네트워크 구성, YAML 호환성 및 앱 마이그레이션이 개선되었습니다. 2025년의 해결 방법을 적용하기 전에 현재 안정 버전에서 느린 pull 증상을 재현해 보세요.
현재 ZimaOS 1.7.1 기준을 사용하세요.
느린 앱 설치 FAQ
자료에서 인터넷 연결이 느렸다는 사실이 입증되었나요?
아니요. 서버의 일반적인 속도 테스트 결과는 App Store의 KB/s 이미지 다운로드 속도보다 훨씬 빨랐습니다.
8.8.8.8로 변경해서 문제가 해결되었나요?
아니요. 사용자는 해당 테스트 후에도 문제가 계속되었다고 명시했습니다.
결국 무엇이 복구와 동시에 발생했나요?
1.4.4.4-1로 업데이트하고, DNS를 1.1.1.1로 변경한 뒤 재부팅했습니다. 어떤 변경이 결정적이었는지는 자료만으로 구분할 수 없습니다.
