A lição mais importante desta parte da discussão sobre ProtonVPN/Gluetun é simples: colocar o qBittorrent numa rede Docker denominada gluetun **não** é o mesmo que encaminhar todo o tráfego do qBittorrent através do contentor VPN Gluetun. O utilizador de origem conseguia transferir torrents de teste com sucesso, enquanto as verificações do IP público dentro do qBittorrent continuavam a devolver o endereço do ISP.
A comunidade acabou por circunscrever o problema à semântica das redes Docker. Para partilhar a pilha de rede do Gluetun, o qBittorrent precisa de uma relação no Compose, como network_mode: "service:gluetun", e a interface do ZimaOS pode substituir ou eliminar essa definição se a stack for posteriormente editada de formas incompatíveis.
O próprio Gluetun já estava ligado
A resolução de problemas na origem já tinha chegado a um ponto em que os registos do Gluetun apresentavam um IP público de VPN e o túnel iniciava com sucesso. Isso significa que o próprio contentor VPN já não era o problema.
A questão seguinte era saber se o qBittorrent utilizava realmente o mesmo espaço de nomes de rede.
O qBittorrent não geria a sua própria VPN
A lista pendente de redes do ZimaOS selecionou uma rede Docker
gluetun colocou o qBittorrent na mesma rede, mas não no espaço de nomes de rede do Gluetun.O autor da resposta separou corretamente dois conceitos do Docker:
- aderir à mesma rede Docker definida pelo utilizador;
- partilhar o espaço de nomes de rede de outro serviço através de
network_mode: service:gluetun.
Apenas o segundo modelo força todo o tráfego de rede do qBittorrent a passar pela pilha do Gluetun.
O teste do IP público provou que o qBittorrent estava a contornar a VPN
A comunidade recomendou verificar o IP público a partir do interior do contentor do qBittorrent e compará-lo com o IP da VPN apresentado nos registos do Gluetun.
O utilizador de origem executou os testes e ambos devolveram o IP normal do ISP. Essa foi a evidência mais forte na discussão da página 2, porque mediu o percurso de tráfego real em vez de o inferir a partir dos nomes das interfaces.
network_mode tem de sobreviver à importação do Compose no ZimaOS
Um participante posterior descobriu que exportar a aplicação depois de editar a interface do ZimaOS podia mostrar o network_mode linha em falta. Relataram sucesso depois de importarem uma definição Compose que mantinha a relação network-mode e evitava portas/redes definições no serviço qBittorrent.
Este é um comportamento do ZimaOS verificado pela comunidade em 2026, não uma garantia oficial da IceWhale relativamente a todos os editores YAML atuais da App Store.
Mantenha o Gluetun e o qBittorrent num único projeto Compose
No tópico original, a comunidade explicou que service:gluetun funciona quando ambos os serviços fazem parte do mesmo projeto Compose. O qBittorrent partilha então o espaço de nomes de rede do Gluetun, pelo que a WebUI e as portas de entrada do qBittorrent são publicadas, em vez disso, no serviço Gluetun.
A comunidade oficial do Gluetun utiliza a mesma arquitetura Docker Compose. Consulte o projeto Gluetun atual e a configuração dos fornecedores antes de copiar variáveis de ambiente antigas.
Utilize credenciais WireGuard da ProtonVPN, não a palavra-passe normal da conta Proton
O tópico mais abrangente revelou outro erro frequente: a configuração WireGuard do Gluetun precisa dos valores de chave/configuração WireGuard adequados da Proton VPN, não da palavra-passe normal de início de sessão da conta.
Nunca publique uma chave privada WireGuard num fórum público. O utilizador original expôs acidentalmente uma e revogou-a corretamente depois.
Verifique o caminho de bloqueio, não apenas o caminho normal
Depois de a stack combinada estar em execução, verifique:
- Os registos do Gluetun mostram o IP público VPN esperado;
- O IP público de saída do qBittorrent corresponde ao mesmo IP;
- O qBittorrent perde o acesso à Internet se o túnel Gluetun for parado ou ficar não íntegro;
- A WebUI continua acessível através da porta publicada no Gluetun.
Isto confirma que a aplicação não está a recorrer silenciosamente à ligação do ISP.
As aplicações ARR não precisam todas de estar atrás da VPN
O tópico original também discutia colocar toda a stack ARR atrás da VPN como forma de simplificar a comunicação. Isso pode funcionar, mas nem sempre é necessário. Muitos utilizadores encaminham apenas o cliente de transferências através do Gluetun, enquanto o Sonarr/Radarr permanecem na rede Docker normal e comunicam através de caminhos e portas explícitos entre o anfitrião e o contentor.
Escolha deliberadamente a arquitetura, em vez de colocar todos os serviços atrás do túnel apenas porque isso resolve um problema de comunicação.
Publique as portas do qBittorrent no Gluetun, não no qBittorrent
Quando o qBittorrent utiliza network_mode: "service:gluetun", deixa de ter um espaço de nomes de rede independente. Isso significa que a WebUI e quaisquer portas BitTorrent de entrada do qBittorrent têm de ser publicadas no serviço Gluetun, e não no serviço qBittorrent.
Se a WebUI do qBittorrent desaparecer depois de mudar para o modo de rede partilhada, verifique a lista de portas do Gluetun antes de concluir que a aplicação não arrancou.
Tenha cuidado ao editar a stack importada na interface do ZimaOS
O relatório posterior da comunidade é particularmente importante para os utilizadores do ZimaOS: o ficheiro Compose importado continha originalmente network_mode, mas depois das alterações na interface a definição exportada já não o fazia. O mesmo participante afirmou que a remoção de portas e redes as entradas e reimportar a stack preservou a relação funcional.
Isto não prova que todas as edições atuais de YAML no ZimaOS se comportem dessa forma, mas significa que o Compose gerado deve ser verificado novamente depois de alterar as definições de rede através do editor gráfico.
A topologia Docker é reutilizável entre fornecedores de VPN, mas as credenciais não
A página 2 inclui um exemplo de resolução de problemas do Surfshark, enquanto o tópico original começou com a ProtonVPN. A lição sobre redes Docker é a mesma: o Gluetun fornece o túnel e o qBittorrent tem de encaminhar o tráfego através do respetivo espaço de nomes. As chaves específicas do fornecedor, os seletores de servidor, as opções de reencaminhamento de portas e os valores de autenticação não são intercambiáveis.
Crie sempre o ambiente do Gluetun a partir da configuração atual do fornecedor, em vez de copiar os valores Surfshark ou Proton de outro utilizador.
Não cole chaves privadas WireGuard em capturas de ecrã públicas ou publicações em fóruns
O autor da publicação original expôs acidentalmente uma chave privada WireGuard e revogou-a depois de outro participante o ter avisado. Considere comprometida qualquer chave VPN publicada e substitua-a imediatamente.
Ao pedir ajuda, oculte chaves privadas, tokens, palavras-passe, cookies e identificadores de contas do fornecedor, mantendo visíveis os registos não secretos e as mensagens de erro.
FAQ de encaminhamento do Gluetun
A adesão a uma rede Docker denominada gluetun encaminha o tráfego através da VPN?
Não. A fonte demonstrou que o qBittorrent podia continuar a utilizar a ligação do ISP enquanto estava ligado a essa rede.
Que definição partilha o espaço de nomes de rede do Gluetun?
O padrão de Compose da fonte e o padrão upstream utilizam network_mode: "service:gluetun".
Como verifica a rota?
Compare o IP público apresentado no interior do qBittorrent com o IP da VPN indicado pelo Gluetun.
