La lección más importante de esta parte del hilo sobre ProtonVPN/Gluetun es sencilla: poner qBittorrent en una red de Docker llamada gluetun no equivale a enrutar todo el tráfico de qBittorrent a través del contenedor de VPN Gluetun. El usuario de origen podía descargar torrents de prueba correctamente, mientras que las comprobaciones de IP pública dentro de qBittorrent seguían devolviendo la dirección del ISP.
La comunidad finalmente redujo el problema a la semántica de redes de Docker. Para compartir la pila de red de Gluetun, qBittorrent necesita una relación de Compose como network_mode: "service:gluetun", y la interfaz de ZimaOS puede sobrescribir o eliminar ese ajuste si la pila se edita posteriormente de formas incompatibles.
Gluetun ya estaba conectado
La solución de problemas de origen ya había llegado a un punto en el que los registros de Gluetun mostraban una IP pública de VPN y el inicio correcto del túnel. Eso significa que el propio contenedor de VPN no era el problema restante.
La siguiente pregunta era si qBittorrent utilizaba realmente el mismo espacio de nombres de red.
qBittorrent no gestionaba su propia VPN
El menú desplegable de red de ZimaOS seleccionó una red de Docker
gluetun hizo que qBittorrent compartiera un segmento de red, pero no el espacio de nombres de red de Gluetun.El usuario que respondió separó correctamente dos conceptos de Docker:
- unirse a la misma red de Docker definida por el usuario;
- compartir el espacio de nombres de red de otro servicio mediante
network_mode: service:gluetun.
Solo el segundo modelo obliga a que todo el tráfico de red de qBittorrent pase por la pila de Gluetun.
La prueba de IP pública demostró que qBittorrent estaba evitando la VPN
La comunidad recomendó comprobar la IP pública desde dentro del contenedor de qBittorrent y compararla con la IP de la VPN que aparecía en los registros de Gluetun.
El usuario de origen ejecutó las pruebas y ambas devolvieron la IP normal del ISP. Esa fue la prueba más contundente en el debate de la página 2, porque midió la ruta de tráfico real en lugar de inferirla a partir de los nombres de las interfaces.
network_mode debe sobrevivir a la importación de Compose en ZimaOS
Más adelante, otro participante descubrió que exportar la aplicación después de editarla en la interfaz de ZimaOS podía mostrar la network_mode faltaba una línea. Informaron que todo funcionó después de importar una definición de Compose que conservaba la relación de modo de red y evitaba configuraciones incompatibles puertos/redes configuración del servicio de qBittorrent.
Este es un comportamiento de ZimaOS verificado por la comunidad en 2026, no una garantía oficial de IceWhale sobre todos los editores YAML actuales de la App Store.
Mantén Gluetun y qBittorrent en un solo proyecto de Compose
En el hilo de origen, la comunidad explicó que service:gluetun funciona cuando ambos servicios forman parte del mismo proyecto de Compose. qBittorrent comparte entonces el espacio de nombres de red de Gluetun, por lo que la WebUI y los puertos entrantes de qBittorrent se publican en el servicio de Gluetun.
La comunidad de Gluetun utiliza la misma arquitectura de Docker Compose. Consulta el proyecto actual de Gluetun y la configuración de proveedores antes de copiar variables de entorno antiguas.
Usa las credenciales de WireGuard de ProtonVPN, no la contraseña normal de la cuenta de Proton
El hilo más amplio estableció otro error frecuente: la configuración de WireGuard de Gluetun necesita los valores adecuados de clave/configuración de WireGuard de Proton VPN, no la contraseña habitual de inicio de sesión de la cuenta.
Nunca publiques una clave privada de WireGuard en un foro público. El usuario original la expuso accidentalmente y la revocó correctamente después.
Verifica la ruta de interrupción, no solo el caso ideal
Una vez que la pila combinada esté en ejecución, verifica:
- Los registros de Gluetun muestran la IP pública de VPN esperada;
- La IP pública saliente de qBittorrent coincide con ella;
- qBittorrent pierde el acceso a Internet si el túnel de Gluetun se detiene o deja de estar saludable;
- La WebUI sigue siendo accesible a través del puerto publicado en Gluetun.
Esto confirma que la aplicación no está recurriendo silenciosamente a la conexión del ISP.
No todas las aplicaciones ARR necesitan estar detrás de la VPN
El hilo de origen también analizaba poner toda la pila ARR detrás de la VPN como forma de simplificar la comunicación. Puede funcionar, pero no siempre es necesario. Muchos usuarios enrutan solo el cliente de descargas a través de Gluetun, mientras Sonarr/Radarr permanecen en la red normal de Docker y se comunican mediante rutas y puertos explícitos del host/contenedor.
Elige la arquitectura deliberadamente en lugar de poner todos los servicios detrás del túnel simplemente porque eso resuelve un problema de comunicación.
Publica los Puertos de qBittorrent en Gluetun, No en qBittorrent
Cuando qBittorrent usa network_mode: "service:gluetun", ya no posee un espacio de nombres de red independiente. Eso significa que la interfaz web y cualquier puerto entrante de BitTorrent deben publicarse en el servicio de Gluetun en lugar del servicio de qBittorrent.
Si la interfaz web de qBittorrent desaparece después de pasar al modo de red compartida, comprueba la lista de puertos de Gluetun antes de concluir que la aplicación no se inició correctamente.
Ten Cuidado al Editar la Pila Importada en la Interfaz de ZimaOS
El informe posterior de la comunidad es especialmente importante para los usuarios de ZimaOS: el archivo Compose importado originalmente contenía network_mode, pero después de los cambios en la interfaz de usuario la definición exportada ya no lo hacía. El mismo participante dijo que eliminar los elementos en conflicto puertos y redes entradas y volver a importar la pila conservó la relación funcional.
Esto no demuestra que todas las ediciones actuales de YAML de ZimaOS se comporten así, pero sí significa que el Compose generado debe revisarse de nuevo después de cambiar la configuración de red mediante el editor gráfico.
La Topología de Docker Es Reutilizable entre Proveedores de VPN, pero las Credenciales No
La página 2 incluye un ejemplo de solución de problemas de Surfshark, mientras que el hilo original comenzó con ProtonVPN. La lección sobre redes de Docker es compartida: Gluetun proporciona el túnel y qBittorrent debe enrutar el tráfico a través de su espacio de nombres. Las claves específicas del proveedor, los selectores de servidor, las opciones de reenvío de puertos y los valores de autenticación no son intercambiables.
Construye siempre el entorno de Gluetun a partir de la configuración actual del proveedor, en lugar de copiar los valores de Surfshark o Proton de otro usuario.
No Pegues Claves Privadas de WireGuard en Capturas de Pantalla Públicas ni en Publicaciones de Foros
El autor original publicó accidentalmente una clave privada de WireGuard y la revocó después de que otro participante se lo advirtiera. Trata cualquier clave de VPN publicada como comprometida y rótala de inmediato.
Al solicitar ayuda, redacta las claves privadas, los tokens, las contraseñas, las cookies y los identificadores de cuenta del proveedor, pero deja visibles los registros no secretos y los mensajes de error.
Preguntas frecuentes sobre el enrutamiento de Gluetun
¿Unirse a una red de Docker llamada gluetun enruta el tráfico a través de la VPN?
No. La fuente demostró que qBittorrent podía seguir usando la ruta del ISP mientras estaba conectado a esa red.
¿Qué configuración comparte el espacio de nombres de red de Gluetun?
El patrón de Compose de origen y el patrón ascendente usan network_mode: "service:gluetun".
¿Cómo verificas la ruta?
Compara la IP pública que se ve desde qBittorrent con la IP de la VPN que informa Gluetun.
