Najważniejszy wniosek z tej części wątku ProtonVPN/Gluetun jest prosty: podłączenie qBittorrent do sieci Docker o nazwie gluetun nie jest tym samym co kierowanie całego ruchu qBittorrent przez kontener VPN Gluetun. Użytkownik mógł pomyślnie pobierać testowe torrenty, podczas gdy testy publicznego adresu IP wykonywane wewnątrz qBittorrent nadal zwracały adres dostawcy internetu.
Społeczność ostatecznie zawęziła problem do semantyki sieci Docker. Aby współdzielić stos sieciowy Gluetun, qBittorrent potrzebuje relacji Compose takiej jak network_mode: "service:gluetun", a interfejs ZimaOS może nadpisać lub usunąć to ustawienie, jeśli stos zostanie później zmodyfikowany w niezgodny sposób.
Sam Gluetun był już połączony
Źródłowa diagnostyka doszła już do etapu, na którym logi Gluetun pokazywały publiczny adres IP VPN i pomyślne uruchomienie tunelu. Oznaczało to, że sam kontener VPN nie był już problemem.
Następne pytanie dotyczyło tego, czy qBittorrent rzeczywiście korzystał z tej samej przestrzeni nazw sieci.
qBittorrent nie zarządzał własnym VPN-em
Lista rozwijana sieci w ZimaOS wybrała sieć Docker
gluetun sprawiło, że qBittorrent współdzielił segment sieci, ale nie przestrzeń nazw sieci Gluetun.Autor odpowiedzi prawidłowo rozdzielił dwa pojęcia związane z Dockerem:
- dołączenie do tej samej zdefiniowanej przez użytkownika sieci Docker;
- udostępnianie przestrzeni nazw sieci innej usługi poprzez
network_mode: service:gluetun.
Tylko drugi model wymusza kierowanie całego ruchu sieciowego qBittorrent przez stos Gluetun.
Test publicznego adresu IP potwierdził, że qBittorrent omijał VPN
Społeczność zaleciła sprawdzenie publicznego adresu IP wewnątrz kontenera qBittorrent i porównanie go z adresem IP VPN wyświetlanym w logach Gluetun.
Użytkownik wykonał testy i oba zwróciły zwykły publiczny adres IP dostawcy internetu. Był to najmocniejszy dowód w dyskusji na drugiej stronie, ponieważ pomiar dotyczył rzeczywistej ścieżki ruchu, zamiast wnioskowania na podstawie nazw interfejsów.
network_mode musi przetrwać import Compose w ZimaOS
Późniejszy uczestnik odkrył, że eksportowanie aplikacji po edycjach interfejsu ZimaOS mogło pokazywać ten network_mode brakujący wiersz. Zgłosili sukces po zaimportowaniu definicji Compose, która zachowywała relację network-mode i unikała niezgodnych ports/networks ustawieniach usługi qBittorrent.
To zweryfikowane przez społeczność zachowanie ZimaOS z 2026 roku, a nie oficjalna gwarancja IceWhale dotycząca każdego obecnego edytora YAML w App Store.
Trzymaj Gluetun i qBittorrent w jednym projekcie Compose
W wątku źródłowym społeczność wyjaśniła, że service:gluetun działa, gdy obie usługi należą do tego samego projektu Compose. qBittorrent współdzieli wtedy przestrzeń nazw sieci Gluetun, więc interfejs WebUI i porty przychodzące qBittorrent są publikowane zamiast tego w usłudze Gluetun.
Społeczność Gluetun korzysta z tej samej architektury Docker Compose. Przed skopiowaniem starych zmiennych środowiskowych zapoznaj się z aktualnym projektem Gluetun i konfiguracją dostawców.
Używaj danych uwierzytelniających WireGuard ProtonVPN, a nie zwykłego hasła do konta Proton
W szerszym wątku ustalono jeszcze jeden częsty błąd: konfiguracja WireGuard w Gluetun wymaga odpowiednich wartości klucza/konfiguracji WireGuard Proton VPN, a nie zwykłego hasła logowania do konta.
Nigdy nie publikuj prywatnego klucza WireGuard na forum publicznym. Oryginalny użytkownik przypadkowo go ujawnił, a następnie prawidłowo go unieważnił.
Zweryfikuj ścieżkę awaryjnego odcięcia, nie tylko pomyślny scenariusz
Po uruchomieniu połączonego stosu sprawdź:
- Dzienniki Gluetun pokazują oczekiwany publiczny adres IP VPN;
- Publiczny adres IP qBittorrent podczas połączeń wychodzących jest z nim zgodny;
- qBittorrent traci dostęp do internetu, jeśli tunel Gluetun zostanie zatrzymany lub będzie niesprawny;
- Interfejs WebUI pozostaje dostępny przez port opublikowany w Gluetun.
Potwierdza to, że aplikacja nie korzysta po cichu z połączenia dostawcy internetu.
Nie wszystkie aplikacje ARR muszą działać za VPN-em
W długim wątku źródłowym omawiano również umieszczenie całego stosu ARR za VPN-em jako sposób na uproszczenie komunikacji. To może działać, ale nie zawsze jest konieczne. Wielu użytkowników kieruje przez Gluetun wyłącznie klienta pobierania, podczas gdy Sonarr/Radarr pozostają w zwykłej sieci Dockera i komunikują się za pośrednictwem jawnie określonych ścieżek oraz portów hosta/kontenera.
Starannie wybierz architekturę, zamiast przenosić każdą usługę za tunel tylko dlatego, że rozwiązuje to jeden problem z komunikacją.
Publikuj porty qBittorrent w Gluetun, a nie w qBittorrent
Gdy qBittorrent używa network_mode: "service:gluetun", nie ma już niezależnej przestrzeni nazw sieci. Oznacza to, że jego WebUI i wszelkie przychodzące porty BitTorrent należy publikować w usłudze Gluetun, a nie w usłudze qBittorrent.
Jeśli WebUI qBittorrent zniknie po przejściu do współdzielonego trybu sieci, sprawdź listę portów Gluetun, zanim uznasz, że aplikacja nie uruchomiła się poprawnie.
Zachowaj ostrożność podczas edytowania zaimportowanego stosu w interfejsie ZimaOS
Późniejszy raport społeczności jest szczególnie ważny dla użytkowników ZimaOS: zaimportowany plik Compose pierwotnie zawierał network_mode, ale po zmianach w interfejsie użytkownika wyeksportowana definicja już jej nie zachowała. Ten sam uczestnik powiedział, że usunięcie sprzecznych ports oraz networks wpisów i ponowne zaimportowanie stosu zachowały działającą konfigurację.
Nie dowodzi to, że każda bieżąca edycja YAML w ZimaOS działa w ten sposób, oznacza jednak, że po zmianie ustawień sieciowych w edytorze graficznym należy ponownie sprawdzić wygenerowany plik Compose.
Topologia Dockera nadaje się do ponownego użycia u różnych dostawców VPN, ale dane uwierzytelniające już nie
Strona 2 zawiera przykład rozwiązywania problemów z Surfsharkiem, podczas gdy oryginalny wątek rozpoczął się od ProtonVPN. Lekcja dotycząca sieci Docker jest wspólna: Gluetun zapewnia tunel, a qBittorrent musi kierować ruch przez jego przestrzeń nazw. Klucze specyficzne dla dostawcy, selektory serwerów, opcje przekierowania portów i dane uwierzytelniające nie są wzajemnie wymienne.
Zawsze twórz środowisko Gluetun na podstawie aktualnej konfiguracji dostawcy, zamiast kopiować wartości Surfshark lub Proton od innego użytkownika.
Nie wklejaj prywatnych kluczy WireGuard na publiczne zrzuty ekranu ani do postów na forum
Autor oryginalnego posta przypadkowo ujawnił prywatny klucz WireGuard i unieważnił go po ostrzeżeniu od innego uczestnika. Każdy opublikowany klucz VPN należy uznać za przejęty i natychmiast go zmienić.
Podczas proszenia o pomoc usuń zrzutów prywatne klucze, tokeny, hasła, pliki cookie i identyfikatory kont dostawcy, pozostawiając widoczne niejawne logi oraz komunikaty o błędach.
FAQ dotyczące routingu Gluetun
Czy dołączenie do sieci Docker o nazwie gluetun kieruje ruch przez VPN?
Nie. Źródło wykazało, że qBittorrent może pozostać na trasie dostawcy usług internetowych, będąc podłączonym do tej sieci.
Które ustawienie współdzieli przestrzeń nazw sieci Gluetun?
Wzorzec źródłowy i nadrzędny Compose używają network_mode: "service:gluetun".
Jak zweryfikować trasę?
Porównaj publiczny adres IP widoczny wewnątrz qBittorrent z adresem IP VPN zgłaszanym przez Gluetun.
