La lezione più importante di questa parte della discussione su ProtonVPN/Gluetun è semplice: inserire qBittorrent in una rete Docker denominata gluetun non equivale a instradare tutto il traffico di qBittorrent attraverso il container VPN Gluetun. L'utente della fonte riusciva a scaricare torrent di prova, mentre i controlli dell'IP pubblico eseguiti all'interno di qBittorrent continuavano a restituire l'indirizzo dell'ISP.
La community ha infine ricondotto il problema alla semantica delle reti Docker. Per condividere lo stack di rete di Gluetun, qBittorrent ha bisogno di una relazione Compose come network_mode: "service:gluetun"e l'interfaccia utente di ZimaOS può sovrascrivere o eliminare questa impostazione se lo stack viene successivamente modificato in modi incompatibili.
Gluetun era già connesso
La risoluzione dei problemi della fonte era già arrivata a un punto in cui i log di Gluetun mostravano un IP pubblico VPN e l'avvio corretto del tunnel. Ciò significa che il container VPN in sé non era più il problema.
La domanda successiva era se qBittorrent utilizzasse effettivamente lo stesso spazio dei nomi di rete.
qBittorrent non gestiva la propria VPN
Il menu a discesa della rete di ZimaOS selezionava una rete Docker
gluetun ha fatto condividere a qBittorrent un segmento di rete, ma non lo spazio dei nomi di rete di Gluetun.Il responder della fonte ha separato correttamente due concetti di Docker:
- l'adesione alla stessa rete Docker definita dall'utente;
- condividendo lo spazio dei nomi di rete di un altro servizio tramite
network_mode: service:gluetun.
Solo il secondo modello forza tutto il traffico di rete di qBittorrent attraverso lo stack di Gluetun.
Il test dell'IP pubblico ha dimostrato che qBittorrent aggirava la VPN
La community ha consigliato di controllare l'IP pubblico dall'interno del container qBittorrent e di confrontarlo con l'IP VPN mostrato nei log di Gluetun.
L'utente della fonte ha eseguito i test ed entrambi hanno restituito il normale IP dell'ISP. Questa è stata la prova più forte nella discussione della pagina 2, perché misurava il percorso effettivo del traffico invece di dedurlo dai nomi delle interfacce.
network_mode deve sopravvivere all'importazione del Compose in ZimaOS
Un partecipante successivo ha scoperto che l'esportazione dell'app dopo le modifiche apportate nell'interfaccia di ZimaOS poteva mostrare la network_mode riga mancante. Hanno segnalato che l'importazione di una definizione Compose che manteneva la relazione network-mode ed evitava impostazioni incompatibili ha avuto esito positivo. ports/networks impostazioni sul servizio qBittorrent.
Questo è un comportamento di ZimaOS verificato dalla community nel 2026, non una garanzia ufficiale di IceWhale per ogni editor YAML dell'App Store attualmente disponibile.
Mantieni Gluetun e qBittorrent nello stesso progetto Compose
Nel thread originale, la community ha spiegato che service:gluetun funziona quando entrambi i servizi fanno parte dello stesso progetto Compose. qBittorrent condivide quindi lo spazio dei nomi di rete di Gluetun, perciò la WebUI e le porte in ingresso di qBittorrent vengono pubblicate invece sul servizio Gluetun.
La community upstream di Gluetun usa la stessa architettura Docker Compose. Consulta il progetto Gluetun attuale e la configurazione dei provider prima di copiare variabili d'ambiente obsolete.
Usa le credenziali WireGuard di ProtonVPN, non la normale password dell'account Proton
La discussione più ampia ha evidenziato un altro errore frequente: la configurazione WireGuard di Gluetun richiede i valori appropriati della chiave/configurazione WireGuard di Proton VPN, non la normale password di accesso all'account.
Non pubblicare mai una chiave privata WireGuard in un forum pubblico. L'utente originale l'ha esposta accidentalmente e l'ha revocata correttamente in seguito.
Verifica il percorso di interruzione, non solo quello ottimale
Dopo l'avvio dello stack combinato, verifica:
- i log di Gluetun mostrano l'indirizzo IP pubblico VPN previsto;
- l'indirizzo IP pubblico in uscita di qBittorrent corrisponde a quello;
- qBittorrent perde l'accesso a Internet se il tunnel Gluetun viene arrestato o non è integro;
- La WebUI rimane raggiungibile tramite la porta pubblicata su Gluetun.
Questo conferma che l'applicazione non sta passando silenziosamente alla connessione dell'ISP.
Le app ARR non devono essere tutte dietro la VPN
La lunga discussione originale ha trattato anche l'idea di mettere l'intero stack ARR dietro la VPN per semplificare la comunicazione. Può funzionare, ma non è sempre necessario. Molti utenti instradano solo il client di download tramite Gluetun, mentre Sonarr/Radarr rimangono sulla normale rete Docker e comunicano attraverso percorsi e porte espliciti tra host e container.
Scegli deliberatamente l'architettura invece di spostare ogni servizio dietro il tunnel solo perché risolve un problema di comunicazione.
Pubblica le porte di qBittorrent su Gluetun, non su qBittorrent
Quando qBittorrent utilizza network_mode: "service:gluetun", non possiede più uno spazio dei nomi di rete indipendente. Ciò significa che la WebUI e tutte le porte BitTorrent in ingresso devono essere pubblicate sul servizio Gluetun anziché sul servizio qBittorrent.
Se la WebUI di qBittorrent scompare dopo il passaggio alla modalità di rete condivisa, controlla l’elenco delle porte di Gluetun prima di concludere che l’applicazione non sia riuscita ad avviarsi.
Fai attenzione quando modifichi lo stack importato nell’interfaccia utente di ZimaOS
La segnalazione successiva della community è particolarmente importante per gli utenti di ZimaOS: il file Compose importato conteneva originariamente network_mode, ma dopo le modifiche nell’interfaccia utente la definizione esportata non lo faceva più. Lo stesso partecipante ha detto di aver rimosso gli elementi in conflitto ports e networks le voci e reimportando lo stack ha mantenuto il collegamento funzionante.
Questo non dimostra che ogni modifica YAML attuale in ZimaOS si comporti in quel modo, ma significa che il Compose generato dovrebbe essere ricontrollato dopo aver modificato le impostazioni di rete tramite l’editor grafico.
La topologia Docker è riutilizzabile tra i provider VPN, ma le credenziali no
La pagina 2 include un esempio di risoluzione dei problemi di Surfshark, mentre la discussione originale era iniziata con ProtonVPN. La lezione sul networking Docker è la stessa: Gluetun fornisce il tunnel e qBittorrent deve instradare il traffico attraverso il suo spazio dei nomi. Le chiavi specifiche del provider, i selettori dei server, le opzioni di port forwarding e i valori di autenticazione non sono intercambiabili.
Crea sempre l’ambiente Gluetun a partire dalla configurazione attuale del provider, invece di copiare i valori Surfshark o Proton di un altro utente.
Non incollare le chiavi private WireGuard in screenshot o post pubblici sui forum
L’autore del post originale ha esposto accidentalmente una chiave privata WireGuard e l’ha revocata dopo che un altro partecipante lo ha avvertito. Considera compromessa qualsiasi chiave VPN pubblicata e sostituiscila immediatamente.
Quando chiedi assistenza, oscura le chiavi private, i token, le password, i cookie e gli identificativi dell’account del provider, lasciando visibili i log non segreti e i messaggi di errore.
FAQ sul routing di Gluetun
L’adesione a una rete Docker denominata gluetun instrada il traffico attraverso la VPN?
No. La fonte ha dimostrato che qBittorrent poteva rimanere sul percorso dell’ISP pur essendo collegato a quella rete.
Quale impostazione condivide lo spazio dei nomi di rete di Gluetun?
Il modello Compose originale e quello upstream usano network_mode: "service:gluetun".
Come verifichi il percorso?
Confronta l’IP pubblico visualizzato dall’interno di qBittorrent con l’IP VPN segnalato da Gluetun.
