커뮤니티 솔루션

ZimaOS에서 Gluetun, network_mode 및 IP 확인을 사용해 qBittorrent를 ProtonVPN으로 라우팅하기

A page-2 segment of a long 2026 community thread about routing qBittorrent and ARR apps through Gluetun. The key discovery was that attaching qBittorrent to a Docker network named gluetun did not make it share Gluetun's network namespace. A later user reported success only after preserving network_mode: service:gluetun in the imported Compose stack.

The most important lesson from this part of the ProtonVPN/Gluetun thread is simple: putting qBittorrent on a Docker network called gluetun is not the same thing as routing all of qBittorrent's traffic through the Gluetun VPN container. The source user could download test torrents successfully while public-IP checks inside qBittorrent still returned the ISP address.

이 ProtonVPN/Gluetun 스레드의 이 부분에서 얻을 수 있는 가장 중요한 교훈은 간단합니다. qBittorrent을 gluetun이라는 Docker 네트워크에 연결하는 것은 qBittorrent의 모든 트래픽을 Gluetun VPN 컨테이너를 통해 라우팅하는 것과 같지 않습니다. 소스 사용자는 테스트 토렌트를 성공적으로 다운로드할 수 있었지만 qBittorrent 내부의 공인 IP 확인 결과는 여전히 ISP 주소를 반환했습니다. network_mode: "service:gluetun"커뮤니티에서는 결국 문제를 Docker 네트워킹의 작동 방식으로 좁혔습니다. Gluetun의 네트워크 스택을 공유하려면 qBittorrent에 다음과 같은 Compose 관계가 필요합니다.

그리고 ZimaOS UI는 스택을 호환되지 않는 방식으로 나중에 편집하면 해당 설정을 덮어쓰거나 삭제할 수 있습니다.

Gluetun 자체는 이미 연결되어 있었음

소스 문제 해결은 이미 Gluetun 로그에 VPN 공인 IP와 터널 시작 성공 메시지가 표시되는 단계까지 진행되었습니다. 이는 VPN 컨테이너 자체가 더 이상 문제의 원인이 아니라는 뜻입니다.

다음 질문은 qBittorrent이 실제로 동일한 네트워크 네임스페이스를 사용했는지 여부였습니다.

qBittorrent은 자체 VPN을 관리하지 않았음
PUID, PGID, TZ, UMASK는 표시되지만 별도의 VPN 자격 증명은 없는 ZimaOS qBittorrent 환경 변수
ZimaOS 네트워크 드롭다운에서는 Docker 네트워크가 선택되어 있었음
ZimaOS qBittorrent 네트워크 드롭다운에 bridge, 여러 Docker 네트워크, host, gluetun이 표시됨 Docker 네트워크 이름을 선택하는 것 gluetun

qBittorrent이 네트워크 세그먼트를 공유하도록 했지만 Gluetun의 네트워크 네임스페이스를 공유하게 하지는 않았습니다.

  • 동일한 사용자 정의 Docker 네트워크에 참여하는 것은 다릅니다.
  • 다른 서비스의 네트워크 네임스페이스를 공유하는 것과 network_mode: service:gluetun.

두 번째 모델만 모든 qBittorrent 네트워크 트래픽이 Gluetun의 네트워크 스택을 통과하도록 강제합니다.

공인 IP 테스트 결과 qBittorrent이 VPN을 우회하는 것으로 확인됨

커뮤니티에서는 qBittorrent 컨테이너 내부에서 공인 IP를 확인하고, Gluetun 로그에 표시된 VPN IP와 비교하라고 권장했습니다.

소스 사용자가 테스트를 실행한 결과 두 테스트 모두 일반 ISP IP를 반환했습니다. 이는 인터페이스 이름으로 추론한 것이 아니라 실제 트래픽 경로를 측정했기 때문에 2페이지 논의에서 가장 강력한 증거였습니다.

qBittorrent 옵션의 동작 탭에 사용자가 기대했던 이전 공인 IP 표시 기능이 없음
소스 사용자는 기존 UI 기반 공인 IP 확인 기능을 찾지 못해 컨테이너 내부에서 테스트하는 방식으로 문제 해결을 진행했습니다.

network_mode ZimaOS Compose 가져오기에서 반드시 유지

이후 다른 참여자는 ZimaOS UI에서 앱을 편집한 뒤 앱을 내보내면 다음과 같이 표시될 수 있다는 사실을 발견했습니다. network_mode 줄이 누락되었습니다. 네트워크 모드 관계를 유지하고 호환되지 않는 설정을 피한 Compose 정의를 가져온 후 성공했다고 보고했습니다. 포트/네트워크 qBittorrent 서비스의 설정에서

이는 2026년에 커뮤니티에서 검증된 ZimaOS 동작이며, 현재 App Store YAML 편집기의 모든 버전에 대한 IceWhale의 공식 보장은 아닙니다.

Gluetun과 qBittorrent를 하나의 Compose 프로젝트에 유지하세요

원본 스레드에서 커뮤니티는 다음과 같이 설명했습니다. service:gluetun 두 서비스가 동일한 Compose 프로젝트에 속해 있으면 작동합니다. 그러면 qBittorrent가 Gluetun의 네트워크 네임스페이스를 공유하므로 qBittorrent의 WebUI와 인바운드 포트는 대신 Gluetun 서비스에 게시됩니다.

상위 Gluetun 커뮤니티에서도 동일한 Docker Compose 아키텍처를 사용합니다. 이전 환경 변수를 복사하기 전에 현재 Gluetun 프로젝트 및 제공업체 구성을 확인하세요.

일반 Proton 계정 비밀번호가 아닌 ProtonVPN WireGuard 자격 증명을 사용하세요

또한 전체 스레드에서는 자주 발생하는 또 다른 실수가 확인되었습니다. Gluetun의 WireGuard 구성에는 일반 계정 로그인 비밀번호가 아니라 적절한 Proton VPN WireGuard 키/구성 값이 필요합니다.

WireGuard 개인 키를 공개 포럼에 절대 게시하지 마세요. 원래 사용자는 실수로 개인 키를 노출했지만 이후 올바르게 폐기했습니다.

정상 경로뿐 아니라 차단 경로도 확인하세요

통합 스택이 실행되면 다음을 확인하세요.

  • Gluetun 로그에 예상한 VPN 공인 IP가 표시됩니다.
  • qBittorrent의 외부 공인 IP가 해당 IP와 일치합니다.
  • Gluetun 터널이 중지되거나 비정상 상태가 되면 qBittorrent는 인터넷 연결을 잃습니다.
  • WebUI는 Gluetun에 게시된 포트를 통해 계속 접속할 수 있습니다.

이는 애플리케이션이 ISP 연결로 조용히 폴백되지 않는다는 것을 확인합니다.

모든 ARR 앱이 VPN 뒤에 있어야 하는 것은 아닙니다

긴 원본 스레드에서는 통신을 간소화하는 방법으로 전체 ARR 스택을 VPN 뒤에 배치하는 방안도 논의했습니다. 이 방법도 가능하지만 항상 필요한 것은 아닙니다. 많은 사용자는 Gluetun을 통해 다운로드 클라이언트만 라우팅하고, Sonarr/Radarr는 일반 Docker 네트워킹을 유지한 채 명시적인 호스트/컨테이너 경로와 포트를 통해 통신합니다.

단일 통신 문제를 해결한다는 이유만으로 모든 서비스를 터널 뒤로 이동하지 말고, 아키텍처를 신중하게 선택하세요.

qBittorrent가 아니라 Gluetun에 qBittorrent 포트를 게시하세요

qBittorrent가 다음을 사용할 때 network_mode: "service:gluetun"더 이상 독립적인 네트워크 네임스페이스를 소유하지 않습니다. 즉, WebUI와 들어오는 BitTorrent 포트는 qBittorrent 서비스가 아니라 Gluetun 서비스에 게시해야 합니다.

공유 네트워크 모드로 전환한 후 qBittorrent WebUI가 사라지면, 애플리케이션이 시작되지 않았다고 결론 내리기 전에 Gluetun의 포트 목록을 확인하세요.

ZimaOS UI에서 가져온 스택을 편집할 때 주의하세요

이후의 커뮤니티 보고는 ZimaOS 사용자에게 특히 중요합니다. 가져온 Compose 파일에는 원래 다음이 포함되어 있었습니다 network_mode도 유지되었지만, UI에서 변경한 후에는 내보낸 정의가 더 이상 이를 유지하지 않았습니다. 같은 참여자는 충돌하는 포트네트워크 항목을 삭제하고 스택을 다시 가져오면 작동하던 연결 관계가 유지되었습니다.

현재의 모든 ZimaOS YAML 편집이 항상 그렇게 작동한다는 뜻은 아니지만, 그래픽 편집기에서 네트워킹을 변경한 후에는 생성된 Compose를 다시 확인해야 한다는 의미입니다.

Docker 토폴로지는 VPN 제공업체 간에 재사용할 수 있지만 자격 증명은 재사용할 수 없습니다

2페이지에는 Surfshark 문제 해결 예제가 포함되어 있지만, 원래 스레드는 ProtonVPN으로 시작되었습니다. Docker 네트워킹의 핵심은 동일합니다. Gluetun이 터널을 제공하고 qBittorrent가 해당 네임스페이스를 통해 라우팅해야 합니다. 제공업체별 키, 서버 선택기, 포트 포워딩 옵션 및 인증 값은 서로 호환되지 않습니다.

다른 사용자의 Surfshark 또는 Proton 값을 복사하지 말고, 항상 현재 제공업체 구성에서 Gluetun 환경을 구성하세요.

공개 스크린샷이나 포럼 게시물에 WireGuard 개인 키를 붙여 넣지 마세요

원 게시자가 실수로 개인 WireGuard 키를 공개했고, 다른 참여자가 경고한 후 해당 키를 폐기했습니다. 공개된 VPN 키는 모두 손상된 것으로 간주하고 즉시 교체하세요.

도움을 요청할 때는 개인 키, 토큰, 비밀번호, 쿠키, 제공업체 계정 식별자를 가리고, 비밀이 아닌 로그와 오류 메시지는 표시된 상태로 남겨 두세요.

Gluetun 라우팅 FAQ

gluetun이라는 Docker 네트워크에 참여하면 트래픽이 VPN을 통해 라우팅되나요?

아니요. 소스에서는 qBittorrent가 해당 네트워크에 연결된 상태에서도 ISP 경로를 계속 사용할 수 있음이 입증되었습니다.

Gluetun의 네트워크 네임스페이스를 공유하는 설정은 무엇인가요?

소스와 상위 Compose 패턴은 다음을 사용합니다 network_mode: "service:gluetun".

라우팅을 어떻게 확인하나요?

qBittorrent 내부에서 확인되는 공인 IP와 Gluetun이 보고하는 VPN IP를 비교하세요.