ZimaOS의 Sonarr, Radarr, Lidarr, Transmission 또는 기타 컨테이너가 IP 주소로는 서로 연결할 수 있지만 다음과 같은 안정적인 이름을 사용할 수 없다면 transmission:9091, 문제는 일반적으로 기본적인 컨테이너 연결이 아니라 이름 확인입니다. 이러한 차이가 2025년 11월 IceWhale Community 스레드에서 핵심 발견이 되었습니다.
Docker의 기본 bridge network는 사용자 정의 브리지와 같은 방식으로 컨테이너 이름에 대한 자동 DNS를 제공하지 않습니다. 이후 이 스레드에서는 ZimaOS와 관련된 두 번째 문제가 드러났습니다. 수동으로 만든 브리지 네트워크가 Docker에서는 존재하더라도 ZimaOS WebUI에 올바르게 표시되기까지 시간이 걸릴 수 있으며, Compose 레이블 요구 사항 때문에 UI가 유효한 Docker 네트워크를 거부할 수도 있었습니다.
핵심 증상: IP로는 작동하지만 컨테이너 이름으로는 실패함
기존 사용자는 Radarr가 다음을 사용하여 Transmission에 연결하기를 원했습니다:
http://transmission:9091재부팅이나 업데이트 후 컨테이너 IP 주소가 변경되므로 하드코딩하는 것은 신뢰할 수 없었습니다. 컨테이너는 IP로 서로 연결할 수 있었지만 호스트 이름을 기반으로 한 호출은 실패했습니다.
기본 Docker 브리지가 이 문제를 해결하지 못하는 이유
Docker의 최신 브리지 네트워크 문서에 따르면 기본 브리지의 컨테이너는 IP로 통신할 수 있지만, 사용자 정의 브리지는 컨테이너 간 자동 DNS 확인을 제공합니다.
따라서 “모든 앱이 bridge를 사용한다”는 말이 Docker의 임베디드 DNS가 활성화된 이름 있는 사용자 정의 브리지를 사용한다는 의미는 아닐 수 있습니다.
사용자 정의 브리지 만들기
sudo -i
docker network create media-net동일한 사용자 정의 브리지에 연결된 컨테이너는 일반적으로 컨테이너 이름이나 네트워크 별칭으로 서로를 확인할 수 있습니다.
현재 ZimaOS 문서에서도 동일한 패턴을 사용합니다
현재 ZimaSpace 문서에서는 기본 브리지가 원하는 컨테이너 DNS 동작을 제공하지 않기 때문에 Zabbix 가이드에서 사용자 정의 네트워크를 명시적으로 사용합니다:
sudo docker network create zabbix-net현재 ZimaOS Zabbix 설치 가이드를 참조하세요.
ZimaOS 특유의 문제: WebUI 동기화
원본 스레드에서는 Docker 또는 Portainer를 통해 사용자 지정 브리지를 생성해도 ZimaOS 앱 설정에서 해당 네트워크를 즉시 사용할 수 없었습니다. 사용자에게 다음과 같은 오류가 표시되었습니다.
network internal-network was found but has incorrect label
com.docker.compose.network set to ""엔지니어와 테스트한 후 Zima-Giorgio는 Docker 네트워킹 자체는 정상적으로 작동하지만 WebUI가 Docker 백엔드와 동기화되지 않을 수 있다고 말했습니다.
커뮤니티에서 확인된 단계: 네트워크 생성 후 재부팅
sudo -i
docker network create net-a
docker network create net-b
재부팅재부팅 후 새로 생성된 네트워크가 앱 설정 패널에 표시되었습니다. 또 다른 참여자는 자신의 테스트에서 누락된 재부팅이 핵심 단계였으며, 이후 사용자 지정 브리지에서 이름 확인이 작동했다고 확인했습니다.
표준 Docker에서는 일반적으로 전체 호스트를 재부팅할 필요가 없습니다 docker network create이는 2025년 스레드에서 관찰된 ZimaOS 특유의 동작입니다.
Compose 레이블 호환성 문제는 여전히 남아 있었습니다
재부팅 후 동기화 문제가 명확해졌지만, 해당 스레드에는 또 다른 제한 사항도 기록되어 있습니다. ZimaOS에서 수동으로 생성한 네트워크의 레이블이 잘못되었다고 표시할 수 있었습니다. com.docker.compose.network 레이블.
Zima-Giorgio는 결국 생성된 일부 네트워크를 선택할 수 없는 문제가 있는 것으로 보이며 팀에 전달하겠다고 말했습니다. 해당 스레드에는 모든 네트워크 선택 관련 예외 상황이 해결되었다는 이후 확인 내용은 없습니다.
Docker에서 네트워크를 확인하고 UI만 확인하지 마세요
docker network inspect media-net
docker inspect CONTAINER_A
docker inspect CONTAINER_B그런 다음 한 컨테이너에서 이름 확인을 테스트하세요.
docker exec CONTAINER_A ping -c 2 CONTAINER_B이미지에 다음이 포함되어 있지 않다면 ping다른 진단 도구나 동일한 네트워크의 임시 테스트 컨테이너를 사용하세요.
IP 주소를 변경하는 대신 이름 또는 별칭 사용
사용자 정의 브리지에서 Docker DNS가 작동하면 다음과 같은 안정적인 엔드포인트로 애플리케이션을 구성하세요.
http://transmission:9091또는 Compose에 정의된 네트워크 별칭.
Cloudflared가 원인이었나요?
원본 스레드에서는 Cloudflared를 근본 원인으로 지목하지 않았습니다. IP 통신은 이미 작동했으며, 문제는 Docker DNS/이름 확인 동작과 일치했습니다.
임시 해결 방법: 호스트 IP와 공개된 포트
원본 게시자는 일시적으로 ZimaOS 호스트에 고정 LAN IP를 예약하고, 앱이 해당 IP와 공개된 포트를 사용하도록 구성했습니다. 이 방법은 작동할 수 있지만, Docker 내부의 안정적인 서비스 이름 라우팅이 아니라 호스트의 공개 포트 경로를 통해 연결됩니다.
ZimaOS 컨테이너 이름 확인 체크리스트
- IP 간 통신이 작동하는지 확인하세요.
- 컨테이너가 기본 브리지에 있는지, 이름이 지정된 사용자 정의 브리지에 있는지 확인하세요.
- 안정적인 DNS가 필요하면 사용자 지정 브리지를 생성하세요.
- 필요한 모든 서비스를 동일한 사용자 지정 네트워크에 연결하세요.
- 원본 스레드와 일치하는 ZimaOS 버전에서는 WebUI가 Docker 네트워크 상태를 새로 고치도록 재부팅하세요.
- 다음으로 확인하세요
docker inspect및docker network inspect. - 다른 컨테이너 내부에서 컨테이너 이름 확인을 테스트하세요.
- ZimaOS에서 Compose 레이블 불일치를 보고하면 Docker 네트워크가 유효하지 않다는 증거가 아니라 UI/통합 문제로 간주하세요.
ZimaOS Docker 브리지 FAQ
브리지의 컨테이너들이 서로의 이름을 확인하지 못하는 이유는 무엇인가요?
Docker의 기본 브리지는 IP 통신을 허용하지만, 사용자가 정의한 브리지처럼 컨테이너 이름에 대한 자동 DNS를 제공하지는 않습니다.
docker network create 후에 재부팅해야 하나요?
일반적인 Docker에서는 보통 그렇지 않습니다. 이 2025년 ZimaOS 스레드에서는 ZimaOS WebUI가 새 네트워크 상태를 가져오도록 재부팅이 필요했습니다.
Cloudflared가 Docker 브리지 DNS를 중단시키나요?
원본 스레드에서는 이를 확정하지 않았습니다.
Docker에 고정 IP를 할당해야 하나요?
대체로 그렇지 않습니다. 사용자가 정의한 Docker DNS와 별칭이 컨테이너 IP를 하드코딩하는 것보다 이식성이 높습니다.
