Proxy en Docker: configuración mediante contenedor, red y variables de entorno — guía paso a paso

Docker se ha convertido en el estándar para ejecutar scrapers, bots, automatizaciones publicitarias y servicios pequeños. Pero los contenedores tienen una particularidad: viven en un entorno aislado y no saben nada de los proxies que configuraste en tu computadora. Como resultado, el script dentro del contenedor sale a internet con tu IP real, mientras tú crees que estás trabajando a través de un proxy móvil. Esta guía cierra esa brecha de una vez por todas.

Introducción: qué obtendrás y a quién le sirve esta guía

Después de completar la guía, sabrás configurar proxies en Docker en los tres niveles donde esto es posible: para un contenedor individual mediante variables de entorno, para todo el cliente y el demonio de Docker mediante archivos de configuración, y también a nivel de red mediante un contenedor-gateway independiente. Entenderás en qué se diferencian estos niveles, cuándo usar cada uno y cómo asegurarte de que el tráfico realmente pasa por el proxy y no por otro camino.

Para quién es esta guía paso a paso

• Especialistas en marketing y SMM que ejecutan en Docker servicios de publicación automática, analítica o monitoreo y quieren que cada herramienta funcione con su propia IP móvil.
• Mediadores de tráfico (arbitrajistas) que tienen decenas de contenedores con trackers, scrapers de ofertas y servicios de espionaje, y cada uno necesita una geolocalización distinta.
• Desarrolladores que necesitan probar una aplicación desde otra región o ejecutar pruebas de integración a través de un proxy.
• Dueños de negocios cuyos empleados o contratistas despliegan infraestructura en contenedores, y necesitan entender cómo funciona ahí el trabajo con proxies.

Qué necesitas saber de antemano

No asumimos conocimientos profundos. Es suficiente si sabes abrir una terminal, copiar un comando y leer lo que devolvió. Si nunca trabajaste con Docker, no te asustes: en la sección de conceptos básicos explicaremos todos los términos en lenguaje sencillo. Kubernetes, la orquestación de clústeres y las plataformas en la nube quedan deliberadamente fuera: es un tema aparte, y aquí nos mantenemos estrictamente en el nivel de Docker.

Cuánto tiempo tomará

El recorrido completo con verificaciones tomará entre 60 y 120 minutos. Si solo necesitas un escenario, por ejemplo un proxy para un único contenedor, bastarán 15 minutos. Si Docker aún no está instalado, añade 20–30 minutos para la instalación.

Preparación previa: herramientas, accesos y requisitos del sistema

Antes de configurar un proxy en Docker, reúne todo lo necesario. Así no te distraerás buscando un login o instalando utilidades a mitad del proceso.

Qué necesitarás

1. Una computadora o servidor con Docker. Sirve Linux (Ubuntu 22.04 o 24.04, Debian 12), macOS con Docker Desktop o Windows 10/11 con Docker Desktop y WSL2. En 2026 son actuales Docker Engine versión 27 y superior, y Docker Compose v2, que se invoca con el comando docker compose (con espacio, sin guion).
2. Datos del proxy móvil. Necesitas cuatro cosas: la dirección del host (IP o nombre de dominio), el puerto, el login y la contraseña. Los encontrarás en el panel de tu proveedor. Averigua también qué protocolo está disponible: HTTP o SOCKS5. La mayoría de los proveedores de proxies móviles, incluido mobileproxy.space, ofrece ambas variantes en puertos distintos.
3. Terminal. En Linux y macOS viene integrada. En Windows usa PowerShell o la terminal de WSL2 (la segunda opción es más cómoda porque los comandos serán idénticos a los de Linux).
4. Editor de texto. Cualquiera: nano, vim, VS Code, Notepad++. Lo necesitas para editar los archivos de configuración.
5. La utilidad curl. Normalmente ya está instalada. Te ayudará a verificar con qué IP sale el tráfico.

Requisitos del sistema

• Mínimo 2 GB de memoria RAM y 10 GB de espacio libre en disco para Docker y las imágenes.
• Permisos de administrador: en Linux es acceso a sudo, en Windows y macOS es una cuenta de administrador para instalar Docker Desktop.
• Conexión a internet estable para descargar las imágenes.

Copias de seguridad

Durante el proceso editaremos archivos de configuración de Docker. Un error en ellos puede hacer que Docker no arranque. Por eso, antes de modificar cualquier archivo, haz una copia. En Linux es un solo comando:

sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.bak

Lo mismo para el archivo ~/.docker/config.json. Si el archivo aún no existe, no hace falta crear una copia de seguridad, pero anota que lo creaste desde cero: entonces para revertir basta con eliminarlo.

Consejo: Crea un archivo de texto con la plantilla de tus datos de proxy en formato protocol://login:password@host:port. Vas a pegar esta cadena muchas veces, y una plantilla lista te ahorrará errores de tipeo.

Conceptos básicos: cómo funciona Docker y dónde vive el proxy en él

Para que configurar un proxy en Docker no se convierta en magia, aclaremos los términos. Si ya trabajas con contenedores con seguridad, repasa la sección rápido, pero presta atención al apartado sobre los tres niveles de proxy: ahí es donde se esconde la mayoría de los errores.

Términos clave en lenguaje sencillo

• Imagen (image) — es una plantilla, un conjunto "congelado" de archivos y programas. Por ejemplo, una imagen con Python o una imagen con un navegador.
• Contenedor (container) — una copia en ejecución de la imagen. De una sola imagen puedes lanzar cuantos contenedores quieras, y cada uno estará aislado de los demás.
• Demonio de Docker (daemon, dockerd) — el servicio en segundo plano que crea contenedores, descarga imágenes y gestiona las redes. Es el demonio el que sale a internet a buscar imágenes cuando escribes docker pull.
• Cliente de Docker (docker CLI) — el comando docker en la terminal. Envía tus órdenes al demonio.
• Variables de entorno (environment variables) — valores con nombre disponibles para los programas dentro del contenedor. Por ejemplo, HTTP_PROXY=http://user:pass@host:port. Muchos programas leen automáticamente estas variables y empiezan a pasar por el proxy indicado.
• Red de Docker (network) — una red virtual que une contenedores. Los contenedores en una misma red personalizada se ven entre sí por nombre.
• Docker Compose — una herramienta que describe varios contenedores, sus variables y redes en un único archivo YAML y los lanza con un solo comando.

Tres niveles de proxy en Docker

Esta es la parte más importante de la teoría. Cuando se dice "proxy en Docker", se pueden estar refiriendo a tres cosas totalmente distintas, y se configuran de maneras diferentes.

1. Proxy para el demonio. Se necesita para que el propio Docker descargue imágenes a través del proxy. Esto aplica a los comandos docker pull y docker build cuando bajan imágenes base. Este nivel no afecta el tráfico de tus aplicaciones dentro de los contenedores.
2. Proxy para contenedores mediante variables de entorno. Dentro del contenedor se pasan HTTP_PROXY, HTTPS_PROXY y NO_PROXY, y la aplicación decide por sí misma si los usa o no. Es la forma más popular y sencilla, pero solo funciona con programas que respetan estas variables.
3. Proxy a nivel de red. El tráfico del contenedor se dirige a través de otro contenedor-gateway o mediante una red especialmente configurada. La aplicación interna puede no saber nada del proxy. Es más confiable, pero requiere más configuración.

Qué es importante entender antes de empezar

Las variables de entorno con proxy son solo una recomendación para el programa. La utilidad curl, el gestor de paquetes pip, la biblioteca requests de Python, Node.js con el paquete global-agent, wget, apt — todos ellos leen HTTP_PROXY. Pero los navegadores en modo headless, algunas aplicaciones en Go y muchas utilidades binarias pueden ignorar las variables. Por eso, después de configurar, verifica siempre la IP externa real y no confíes en que la variable está puesta.

Otro detalle es el uso de mayúsculas y minúsculas. Históricamente, algunas aplicaciones leen http_proxy en minúsculas y otras HTTP_PROXY en mayúsculas. La práctica confiable es definir ambas variantes a la vez. La variable NO_PROXY enumera las direcciones para las que no se debe usar el proxy: localhost, 127.0.0.1, dominios internos, nombres de contenedores vecinos.

Por último, el formato de la dirección del proxy. Para un proxy HTTP, la cadena se ve así: http://login:password@host:port. Para SOCKS5: socks5://login:password@host:port o socks5h://login:password@host:port. La letra h al final significa que las consultas DNS también salen por el proxy, lo cual para proxies móviles suele ser preferible: así el sitio objetivo no ve el resolutor DNS de tu proveedor.

Paso 1: Verificamos Docker y preparamos los datos del proxy

Objetivo de la etapa: asegurarte de que Docker funciona y de que tus datos de proxy son correctos y accesibles desde esta computadora. Sin esta verificación, corres el riesgo de pasar media hora buscando un error en la configuración cuando el problema era un error de tipeo en la contraseña.

Verificación de Docker

1. Abre la terminal.
2. Escribe el comando docker --version y presiona Enter. Debes ver una línea del tipo Docker version 27.x.x. Si la terminal dice que no se encontró el comando, Docker no está instalado: instala Docker Desktop (Windows, macOS) o Docker Engine (Linux) según la documentación oficial y vuelve aquí.
3. Escribe docker compose version. Salida esperada: Docker Compose version v2.x.x.
4. Escribe docker run --rm hello-world. Docker descargará una imagen de prueba diminuta y mostrará un saludo con las palabras Hello from Docker. Esto significa que el demonio funciona y que tienes permisos para lanzar contenedores.

Consejo: Si en Linux el comando docker pide sudo, agrega tu usuario al grupo docker: sudo usermod -aG docker $USER, luego cierra sesión y vuelve a entrar. Después, todos los comandos de esta guía funcionarán sin sudo.

Verificación del proxy desde el host

Antes de llevar el proxy dentro del contenedor, verifiquemos que al menos responde. Reemplaza el ejemplo con tus datos. En los ejemplos usaremos la dirección 185.10.10.10, el puerto 1050 para HTTP y 1051 para SOCKS5, el login user123 y la contraseña secret. Tú tendrás tus propios valores, por supuesto.

1. Primero averigua tu IP normal sin proxy: curl -s ifconfig.me. Anota o memoriza el resultado.
2. Ahora una consulta a través del proxy HTTP: curl -s -x http://user123:secret@185.10.10.10:1050 ifconfig.me
3. Si tienes SOCKS5: curl -s -x socks5h://user123:secret@185.10.10.10:1051 ifconfig.me
4. Compara el resultado con el paso 1. La IP debe ser distinta y pertenecer a un operador móvil.

Caracteres especiales en la contraseña

Si el login o la contraseña contienen los caracteres @, :, /, #, ? o un espacio, hay que codificarlos en formato URL, de lo contrario la cadena del proxy se romperá. El carácter @ se convierte en %40, : en %3A, / en %2F, # en %23, ? en %3F, el espacio en %20. Por ejemplo, la contraseña pa@ss en la cadena del proxy se escribe como pa%40ss.

✅ Verificación: El comando curl a través del proxy devolvió una IP distinta de la de tu casa, y la respuesta llegó en uno a tres segundos. Si recibiste un error 407, revisa el login y la contraseña. Si recibiste Connection refused o un timeout, revisa el host, el puerto y si tu IP actual está agregada a la lista blanca en el panel del proveedor (en algunos planes la autorización por IP viene activada por defecto).

Paso 2: Configuramos el proxy para un contenedor mediante variables de entorno

Objetivo de la etapa: lanzar un contenedor cuyo tráfico HTTP pase por el proxy móvil y comprobarlo mediante la IP externa. Este es el escenario básico con el que conviene empezar: no toca la configuración del sistema y es fácil de revertir.

Ejecución con el flag -e

El flag -e (o --env) del comando docker run pasa una variable de entorno dentro del contenedor. Pasaremos cuatro variables a la vez: proxy para HTTP, para HTTPS y las exclusiones, cada una en dos registros (mayúsculas y minúsculas).

1. Copia el comando de abajo en el editor y reemplaza los datos del proxy por los tuyos.
2. Ejecuta el comando en la terminal. Lanzará un contenedor temporal con curl que hará una consulta y terminará.

docker run --rm -e HTTP_PROXY=http://user123:secret@185.10.10.10:1050 -e HTTPS_PROXY=http://user123:secret@185.10.10.10:1050 -e http_proxy=http://user123:secret@185.10.10.10:1050 -e https_proxy=http://user123:secret@185.10.10.10:1050 -e NO_PROXY=localhost,127.0.0.1 -e no_proxy=localhost,127.0.0.1 curlimages/curl -s ifconfig.me

Fíjate en que para HTTPS_PROXY también indicamos http:// al inicio. No es un error. Así se define el proxy por el que pasarán las consultas HTTPS, mientras que la conexión con el servidor proxy propiamente dicha es normal. El esquema https:// en el valor de HTTPS_PROXY significaría que hay que conectarse al propio proxy por TLS, lo cual la mayoría de los proveedores no admite.

Archivo de variables en lugar de un comando largo

El comando quedó engorroso. Docker sabe leer variables de un archivo mediante el flag --env-file. Es más cómodo y más seguro: la contraseña no queda en el historial de la terminal.

1. Crea el archivo proxy.env en la carpeta de trabajo: nano proxy.env
2. Escribe en él las líneas, una variable por línea, sin comillas y sin espacios alrededor del signo igual:

HTTP_PROXY=http://user123:secret@185.10.10.10:1050 HTTPS_PROXY=http://user123:secret@185.10.10.10:1050 http_proxy=http://user123:secret@185.10.10.10:1050 https_proxy=http://user123:secret@185.10.10.10:1050 NO_PROXY=localhost,127.0.0.1 no_proxy=localhost,127.0.0.1

En el archivo real, cada variable debe ir en su propia línea. Guarda el archivo (en nano es Ctrl+O, Enter y luego Ctrl+X) y lanza el contenedor:

docker run --rm --env-file proxy.env curlimages/curl -s ifconfig.me

Verificación desde dentro de un contenedor en ejecución

A menudo es necesario ver lo que ve un contenedor de larga duración. Lanzaremos Alpine Linux en modo interactivo y verificaremos las variables.

1. Ejecuta docker run -it --rm --env-file proxy.env alpine sh. Estarás dentro del contenedor, el prompt cambiará a una almohadilla o a un signo de dólar.
2. Escribe env | grep -i proxy. Verás la lista de tus variables.
3. Escribe apk add --no-cache curl. El gestor de paquetes apk tomará por sí mismo https_proxy y descargará el paquete a través del proxy.
4. Escribe curl -s ifconfig.me y verifica que la IP sea móvil.
5. Escribe exit para salir. El contenedor se eliminará automáticamente gracias al flag --rm.

Consejo: Para verificar la IP, además de ifconfig.me conviene usar servicios que devuelven JSON con información del país, la ciudad y el proveedor. Así verás de inmediato que la IP pertenece a un operador móvil de la región correcta, y no simplemente a "otra" IP.

✅ Verificación: Ambas ejecuciones con curl devolvieron la IP del proxy móvil. El comando env dentro del contenedor mostró las variables HTTP_PROXY y HTTPS_PROXY con tus datos.

Posibles problemas en este paso

• La IP no cambió. La aplicación dentro del contenedor ignora las variables de entorno. Con curl esto no pasa, así que si curl muestra la IP móvil y tu aplicación no, pasa al método de red del paso 6.
• Error invalid reference format. Normalmente es un espacio de más o un salto de línea en el comando. Arma el comando en una sola línea.
• Las variables no se ven. En el archivo env-file no debe haber comillas alrededor de los valores: Docker las pasará literalmente y la dirección del proxy quedará incorrecta.

Paso 3: Configuramos el proxy para el cliente de Docker, para que las variables se pasen automáticamente

Objetivo de la etapa: lograr que cada nuevo contenedor y cada compilación de imagen reciban automáticamente las variables de proxy sin flags -e. Esto ahorra tiempo si lanzas constantemente distintos contenedores a través del mismo proxy móvil.

Cómo funciona

El cliente de Docker lee el archivo config.json en la carpeta ~/.docker (en Windows es la carpeta .docker en el perfil del usuario). Si contiene una sección proxies, el cliente, en cada docker run y docker build, agrega las variables indicadas al contenedor. El demonio no se toca, por lo que docker pull seguirá yendo directo.

Configuración paso a paso

1. Verifica si existe el archivo: cat ~/.docker/config.json. Si el archivo existe y ya tiene ajustes (por ejemplo, auths con datos de inicio de sesión en el registro), haz una copia: cp ~/.docker/config.json ~/.docker/config.json.bak
2. Abre el archivo en el editor: nano ~/.docker/config.json. Si el archivo no existe, el editor lo creará.
3. Agrega la sección proxies. Si el archivo estaba vacío, su contenido completo será así:

{ "proxies": { "default": { "httpProxy": "http://user123:secret@185.10.10.10:1050", "httpsProxy": "http://user123:secret@185.10.10.10:1050", "noProxy": "localhost,127.0.0.1,*.local" } } }

Si el archivo ya tenía otras claves, agrega proxies como una clave más de nivel superior separada por coma, sin eliminar las existentes. Cuida el emparejamiento de llaves y comillas: JSON no perdona una coma faltante.

1. Guarda el archivo.
2. Verifica la sintaxis. En Linux y macOS es cómodo así: python3 -m json.tool ~/.docker/config.json. Si la salida repite tu archivo bien formateado, todo está bien. Si aparece un error con el número de línea, corrígelo.
3. Lanza un contenedor de verificación sin ningún flag: docker run --rm curlimages/curl -s ifconfig.me. La IP debe ser móvil.
4. Mira las variables de cualquier contenedor: docker run --rm alpine env. En la salida estarán HTTP_PROXY, HTTPS_PROXY, NO_PROXY y sus variantes en minúsculas: Docker agrega ambos registros por sí mismo.

⚠ Atención: La sección proxies en config.json afecta a todos los contenedores que lances con este usuario, incluidas bases de datos, servidores web locales y todo lo demás. Si algún servicio se comunica con una API externa que no es accesible a través de tu proxy, se romperá. Agrega esas direcciones a noProxy o quita temporalmente la sección.

Distintos proxies para distintas conexiones

La clave default se aplica a todas las conexiones con el demonio. Si gestionas varios hosts de Docker mediante contextos o la variable DOCKER_HOST, en lugar de default puedes indicar la dirección de un demonio concreto, por ejemplo tcp://192.168.1.50:2376, y el proxy se aplicará solo a él. Para el trabajo local, default es suficiente.

Proxy al compilar imágenes

Los ajustes de config.json también se pasan a docker build como argumentos de compilación. Esto significa que los comandos RUN apt-get install o RUN pip install dentro del Dockerfile pasarán por el proxy. Punto importante: estas variables no se guardan en la imagen final, lo cual es bueno desde el punto de vista de la seguridad: la contraseña del proxy no se filtrará a quienes le entregues la imagen.

Consejo: Si quieres pasar el proxy solo para una compilación, sin tocar config.json, usa los flags docker build --build-arg HTTP_PROXY=http://user123:secret@185.10.10.10:1050 --build-arg HTTPS_PROXY=http://user123:secret@185.10.10.10:1050 . Docker entiende estos argumentos predefinidos sin declarar ARG en el Dockerfile.

✅ Verificación: El contenedor lanzado sin flags -e sale a internet con la IP del proxy. El comando docker run --rm alpine env muestra las variables del proxy.

Cómo revertir

Elimina la sección proxies de config.json o restaura el archivo desde la copia de seguridad: cp ~/.docker/config.json.bak ~/.docker/config.json. No hace falta reiniciar nada, los cambios se aplican al siguiente lanzamiento de contenedor.

Paso 4: Configuramos el proxy para el demonio de Docker, para que las imágenes se descarguen a través del proxy

Objetivo de la etapa: hacer que el propio Docker (el demonio) vaya a buscar las imágenes a través del proxy. Esto es necesario cuando el acceso directo al registro de imágenes desde tu servidor está restringido por una política corporativa, es lento, o cuando quieres que toda la actividad de red del servidor pase por un solo canal. Para tareas de marketing este paso suele no ser necesario, pero conviene conocerlo: los errores a nivel del demonio se confunden con frecuencia con errores a nivel del contenedor.

Método 1: archivo daemon.json (Linux, Docker 23 y más reciente)

1. Haz una copia: sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.bak (si el archivo no existe, el comando dará un error, esto es normal).
2. Abre el archivo: sudo nano /etc/docker/daemon.json
3. Agrega la sección proxies:

{ "proxies": { "http-proxy": "http://user123:secret@185.10.10.10:1050", "https-proxy": "http://user123:secret@185.10.10.10:1050", "no-proxy": "localhost,127.0.0.1" } }

Fíjate en que aquí las claves se escriben con guion y en minúsculas: esto difiere del config.json del cliente, donde las claves son del estilo httpProxy. Confundirlas es un error clásico.

1. Guarda el archivo y reinicia el demonio: sudo systemctl restart docker
2. Verifica que el demonio haya levantado: sudo systemctl status docker. En la salida debe aparecer active (running).
3. Verifica la aplicación: docker info | grep -i proxy. Verás las líneas HTTP Proxy y HTTPS Proxy con tu dirección, y la contraseña aparecerá oculta con asteriscos.

Método 2: archivo drop-in de systemd (Linux, cualquier versión)

Este es el método clásico, que funciona incluso en versiones antiguas de Docker.

1. Crea la carpeta: sudo mkdir -p /etc/systemd/system/docker.service.d
2. Crea el archivo: sudo nano /etc/systemd/system/docker.service.d/http-proxy.conf
3. Escribe el contenido, cada directiva en su propia línea:

[Service] Environment="HTTP_PROXY=http://user123:secret@185.10.10.10:1050" Environment="HTTPS_PROXY=http://user123:secret@185.10.10.10:1050" Environment="NO_PROXY=localhost,127.0.0.1"

1. Guarda, luego vuelve a leer la configuración de systemd: sudo systemctl daemon-reload
2. Reinicia Docker: sudo systemctl restart docker
3. Verifica: sudo systemctl show --property=Environment docker. En la salida estarán tus variables.

⚠ Atención: No configures el proxy del demonio con los dos métodos a la vez. Si tanto daemon.json como el archivo systemd contienen direcciones distintas, el comportamiento se volverá impredecible y la depuración, tortuosa. Elige un método y sé fiel a él.

Método 3: Docker Desktop (Windows y macOS)

1. Abre Docker Desktop, haz clic en el icono de engranaje en la esquina superior derecha.
2. En el menú de la izquierda elige Resources, luego Proxies.
3. Activa el interruptor Manual proxy configuration.
4. En los campos Web Server (HTTP) y Secure Web Server (HTTPS) pega la dirección del proxy en formato http://user123:secret@185.10.10.10:1050.
5. En el campo Bypass proxy settings for these hosts escribe localhost,127.0.0.1.
6. Haz clic en Apply and restart. Docker Desktop se reiniciará, esto tomará 30–60 segundos.

Docker Desktop aplica estos ajustes tanto al demonio como a los contenedores a la vez, por lo que editar config.json por separado en los sistemas de escritorio suele no ser necesario.

Verificación del resultado

1. Elimina alguna imagen pequeña, si la tienes: docker rmi alpine
2. Descárgala de nuevo: docker pull alpine. La descarga debe completarse correctamente.
3. Si del lado del proxy hay estadísticas de tráfico (en el panel de mobileproxy.space las hay), verás que el volumen de tráfico consumido creció varios megabytes.

✅ Verificación: docker info muestra la dirección del proxy, docker pull descarga imágenes sin errores, el servicio docker está en estado active.

Posibles problemas

• Docker no arranca después de editar daemon.json. Casi siempre la culpa es de la sintaxis JSON. Verifica el archivo con el comando python3 -m json.tool /etc/docker/daemon.json o restaura la copia.
• docker pull se cuelga. El proxy no deja pasar las conexiones al registro o se superó el límite de tráfico del plan. Verifica el proxy desde el host con curl, como en el paso 1.
• Error x509 certificate. El proxy sustituye los certificados (aplica a proxies corporativos; en proxies móviles es poco frecuente). Consulta con el proveedor.

Paso 5: Configuramos el proxy en Docker Compose

Objetivo de la etapa: describir el proxy en el archivo compose.yaml de modo que un grupo de contenedores se lance con un solo comando con los ajustes necesarios, y que distintos servicios puedan usar distintos proxies móviles. Este es precisamente el escenario que más necesitan los mediadores de tráfico y los especialistas en marketing: un scraper trabaja a través del proxy de Moscú, el segundo a través del proxy de Kazán, y la base de datos va sin proxy.

Preparación del proyecto

1. Crea la carpeta del proyecto y entra en ella: mkdir proxy-demo, luego cd proxy-demo
2. Crea el archivo .env (con punto al inicio) para guardar los secretos: nano .env
3. Escribe las variables, una por línea:

PROXY_MSK=http://user123:secret@185.10.10.10:1050 PROXY_KZN=http://user456:secret2@185.10.10.20:1050

Compose lee el archivo .env automáticamente y sus valores se pueden sustituir en compose.yaml mediante la sintaxis ${NOMBRE}. Agrega .env a .gitignore si el proyecto está bajo control de versiones: las contraseñas no deben terminar en el repositorio.

Archivo compose.yaml

Crea el archivo compose.yaml (nano compose.yaml) y describe tres servicios. En YAML las indentaciones son importantes: usa dos espacios por nivel, no tabulaciones.

services: parser-msk: image: curlimages/curl command: -s ifconfig.me environment: HTTP_PROXY: ${PROXY_MSK} HTTPS_PROXY: ${PROXY_MSK} http_proxy: ${PROXY_MSK} https_proxy: ${PROXY_MSK} NO_PROXY: localhost,127.0.0.1,db no_proxy: localhost,127.0.0.1,db parser-kzn: image: curlimages/curl command: -s ifconfig.me environment: HTTP_PROXY: ${PROXY_KZN} HTTPS_PROXY: ${PROXY_KZN} http_proxy: ${PROXY_KZN} https_proxy: ${PROXY_KZN} NO_PROXY: localhost,127.0.0.1,db no_proxy: localhost,127.0.0.1,db db: image: postgres:16-alpine environment: POSTGRES_PASSWORD: example

Aquí, en el archivo real, cada línea va por separado con las indentaciones correctas: services en el nivel cero, los nombres de los servicios con dos espacios de sangría, sus parámetros con cuatro, y las variables de entorno con seis. Fíjate en el nombre db en NO_PROXY: así los scrapers accederán a la base de datos directamente por la red interna de Docker, en lugar de intentar alcanzarla a través del proxy móvil, lo cual no funcionaría de ninguna manera.

Ejecución y verificación

1. Verifica cómo Compose sustituyó las variables: docker compose config. El comando mostrará el archivo final con los valores ya expandidos. Asegúrate de que en lugar de ${PROXY_MSK} esté la dirección real.
2. Lanza: docker compose up. Compose descargará las imágenes y arrancará los tres servicios, mostrando sus logs en la terminal.
3. En los logs verás líneas del tipo parser-msk-1 | 91.xxx.xxx.xxx y parser-kzn-1 | 176.xxx.xxx.xxx: dos IP distintas de dos proxies distintos. Postgres arrancará y esperará conexiones.
4. Detén todo con Ctrl+C, luego elimina los contenedores: docker compose down

Alternativa: env_file para cada servicio

Si hay muchas variables, en lugar del bloque environment conviene indicar un archivo:

services: parser-msk: image: curlimages/curl command: -s ifconfig.me env_file: - proxy-msk.env

El archivo proxy-msk.env contiene las mismas seis líneas que el proxy.env del paso 2. Así cada proxy está en su propio archivo, y puedes reemplazarlo sin abrir compose.yaml.

Proxy al compilar en Compose

Si el servicio se compila desde un Dockerfile en lugar de tomarse ya listo, pasa el proxy a la compilación mediante build.args:

services: app: build: context: . args: HTTP_PROXY: ${PROXY_MSK} HTTPS_PROXY: ${PROXY_MSK}

Así pip, npm o apt dentro del Dockerfile funcionarán a través del proxy, y los valores no terminarán en la imagen final.

Consejo: Compose admite varios archivos. Mantén un compose.yaml base sin proxy, y en compose.proxy.yaml describe solo los bloques environment. Lanza docker compose -f compose.yaml -f compose.proxy.yaml up cuando necesites el proxy, y simplemente docker compose up cuando no. Esto es cómodo al depurar: cambias entre modos en un segundo.

✅ Verificación: docker compose config muestra las direcciones de proxy sustituidas, y en los logs de docker compose up los servicios con distintos proxies muestran IP distintas.

Paso 6: Configuramos el proxy a nivel de red mediante un contenedor-gateway

Objetivo de la etapa: levantar un contenedor aparte que reciba conexiones de sus vecinos en la red de Docker y las reenvíe al proxy móvil. Los demás contenedores se dirigen al gateway por nombre y no guardan el login ni la contraseña. Esto resuelve tres tareas a la vez: centraliza la gestión del proxy, elimina las contraseñas de decenas de configuraciones y permite cambiar el proxy sin reiniciar los contenedores de trabajo.

Para qué se necesita un gateway si ya hay variables

Imagina que tienes veinte contenedores con scrapers y el proveedor te asignó un nuevo puerto. Con variables de entorno tendrás que editar veinte configuraciones y reiniciar todo. Con un gateway cambias una línea en un solo lugar. Además, algunas aplicaciones no soportan la autenticación en el proxy por login y contraseña, pero funcionan perfectamente con un proxy sin autenticación. El gateway dentro de la red cerrada de Docker no requiere autenticación, mientras que él mismo se conecta al proxy móvil con tus datos.

Creamos la red

1. Crea la red personalizada: docker network create proxynet
2. Verifica que apareció: docker network ls. En la lista estará proxynet con el driver bridge.

La red personalizada es necesaria porque solo en ella funciona la resolución de nombres: el contenedor podrá dirigirse al gateway por el nombre gateway, y no por la IP, que cambia en cada reinicio.

Lanzamos el gateway

Como gateway usaremos gost, un servidor proxy compacto capaz de recibir conexiones en un protocolo y reenviarlas a otro con autenticación. La imagen está disponible en el registro público con el nombre gogost/gost.

1. Lanza el contenedor-gateway:

docker run -d --name gateway --network proxynet --restart unless-stopped gogost/gost -L=http://:8118 -F=http://user123:secret@185.10.10.10:1050

Analicemos los parámetros. El flag -d lanza el contenedor en segundo plano. El flag --name gateway define el nombre con el que se dirigirán a él los vecinos. El flag --network proxynet lo conecta a nuestra red. El flag --restart unless-stopped levanta el gateway después de reiniciar el servidor. El parámetro -L=http://:8118 le dice a gost que acepte conexiones de proxy HTTP en el puerto 8118 sin autenticación. El parámetro -F indica a dónde reenviar: a tu proxy móvil con login y contraseña.

1. Verifica que el gateway funciona: docker logs gateway. En el log debe haber una línea indicando que el servidor escucha en el puerto 8118, sin errores.

⚠ Atención: No publiques el puerto del gateway hacia afuera con el flag -p si no es estrictamente necesario. El gateway funciona sin autenticación, y un puerto 8118 abierto en un servidor público significa que cualquiera en internet podrá usar tu proxy móvil y consumir tu tráfico. Dentro de la red proxynet solo es accesible para tus contenedores, y eso es suficiente.

Conectamos los contenedores de trabajo

1. Lanza un contenedor de verificación en la misma red, indicando el gateway como proxy:

docker run --rm --network proxynet -e HTTP_PROXY=http://gateway:8118 -e HTTPS_PROXY=http://gateway:8118 curlimages/curl -s ifconfig.me

1. Debes ver la IP del proxy móvil. Fíjate: en las variables no hay ni login, ni contraseña, ni la dirección real del proxy. Todo esto solo lo sabe el gateway.

Lo mismo en Compose

Para el trabajo permanente, describe el gateway y los servicios de trabajo en un solo compose.yaml:

services: gateway: image: gogost/gost command: -L=http://:8118 -F=${PROXY_MSK} restart: unless-stopped networks: - proxynet worker: image: curlimages/curl command: -s ifconfig.me environment: HTTP_PROXY: http://gateway:8118 HTTPS_PROXY: http://gateway:8118 NO_PROXY: localhost,127.0.0.1 depends_on: - gateway networks: - proxynet networks: proxynet: driver: bridge

La directiva depends_on garantiza que el gateway arranque antes que el worker. El valor PROXY_MSK se toma del archivo .env, como en el paso 5.

Varios gateways para varias geos

¿Quieres distintos proxies para distintos grupos de contenedores? Levanta varios gateways: gateway-msk, gateway-kzn, gateway-spb, cada uno con su -F. Los contenedores de trabajo simplemente indican el nombre necesario en HTTP_PROXY. Puedes ir más lejos y crear una red separada para cada geo, así los contenedores del grupo de Moscú no podrán físicamente caer por error en el gateway de Kazán.

Aislamiento: contenedor sin salida directa a internet

La variante más estricta es prohibirle al contenedor de trabajo cualquier salida a internet que no sea a través del gateway. Para eso, crea una red interna con el flag --internal: docker network create --internal isolated. Los contenedores en esa red no tienen ruta hacia afuera. Conecta el gateway a dos redes a la vez (isolated y la normal proxynet), y los workers solo a isolated. Ahora, incluso si la aplicación ignora las variables del proxy, simplemente no podrá salir a internet directamente y no habrá fuga de la IP real.

1. docker network create --internal isolated
2. docker network connect isolated gateway
3. docker run --rm --network isolated -e HTTP_PROXY=http://gateway:8118 -e HTTPS_PROXY=http://gateway:8118 curlimages/curl -s ifconfig.me
4. Para control, lanza el mismo contenedor sin variables de proxy: docker run --rm --network isolated curlimages/curl -s -m 5 ifconfig.me. La consulta debe terminar en timeout: no hay salida directa.

Consejo: La combinación de red interna y gateway es el mejor seguro contra fugas en el trabajo con multicuentas. Incluso si el desarrollador olvidó poner el proxy en un nuevo servicio, este no podrá exponer la IP del servidor: o irá a través del gateway, o no irá a ningún lado.

✅ Verificación: El contenedor en la red proxynet con la variable HTTP_PROXY=http://gateway:8118 muestra la IP del proxy móvil. El contenedor en la red interna sin proxy no puede salir a internet en absoluto.

Posibles problemas

• Could not resolve host: gateway. El contenedor de trabajo no está en la red correcta o se lanzó en la red por defecto, donde los nombres no se resuelven. Verifica el flag --network.
• El gateway se reinicia. Error en la cadena -F: un error de tipeo en la contraseña o un puerto incorrecto. Mira docker logs gateway.
• Va lento. Los proxies móviles por naturaleza son más lentos que los de centro de datos, pero si la latencia se cuenta en decenas de segundos, verifica si el DNS se está saliendo del proxy: usa socks5h en lugar de socks5 en la cadena -F, si el proveedor ofrece SOCKS5.

Verificación del resultado: checklist de un proxy en Docker funcionando

Repasa la lista. Si marcas cada punto, dominaste por completo la configuración de proxies en Docker en la práctica.

Checklist

• curl desde el host a través del proxy devuelve la IP móvil.
• El contenedor con el flag --env-file proxy.env devuelve la IP móvil.
• El contenedor sin flags después de configurar config.json devuelve la IP móvil (si hiciste el paso 3).
• docker info muestra la dirección del proxy y docker pull funciona (si hiciste el paso 4).
• docker compose up lanza los servicios, y en los logs se ven IP distintas para distintos proxies.
• El contenedor-gateway funciona, los vecinos salen a través de él sin login ni contraseña.
• El contenedor en la red interna sin proxy no puede salir a internet.

Cómo probar todo en conjunto

1. Lanza un contenedor de larga duración: docker run -d --name test --network proxynet -e HTTP_PROXY=http://gateway:8118 -e HTTPS_PROXY=http://gateway:8118 alpine sleep 3600
2. Entra en él: docker exec -it test sh
3. Instala curl: apk add --no-cache curl. La instalación debe pasar por el proxy.
4. Haz cinco consultas seguidas: for i in 1 2 3 4 5; do curl -s ifconfig.me; echo; done. Las cinco deben devolver la IP móvil. Si tu proxy tiene activada la rotación automática, las IP pueden diferir entre consultas, es normal.
5. Sal (exit) y elimina el contenedor: docker rm -f test

Indicadores de éxito

Una configuración exitosa significa que puedes responder en un segundo a tres preguntas: por qué IP sale un contenedor concreto, dónde se guarda la contraseña del proxy y qué hay que cambiar para pasar un contenedor a otro proxy. Si la respuesta a cada pregunta es obvia, el objetivo está cumplido.

Errores típicos al configurar un proxy en Docker y sus soluciones

Error 1: la IP no cambia aunque las variables estén puestas

Causa: la aplicación dentro del contenedor no lee las variables de entorno del proxy. Esto es característico de los navegadores headless, algunos programas en Go y utilidades que usan sus propios stacks de red.

Solución: revisa la documentación de la aplicación para ver si tiene su propio flag de proxy (en los navegadores suele ser --proxy-server). Si no hay flag, usa el gateway y la red interna del paso 6, o el proxying transparente de la sección para avanzados.

Error 2: 407 Proxy Authentication Required

Causa: login o contraseña incorrectos, o caracteres especiales en ellos no codificados, o el proxy tiene activada la autorización por IP y la IP del servidor no está en la lista blanca.

Solución: verifica los datos desde el host con curl. Codifica los caracteres especiales. Agrega la IP del servidor a la lista blanca en el panel o cambia el proxy a autorización por login y contraseña.

Error 3: Docker no arranca después de editar daemon.json

Causa: error de sintaxis en el JSON: una coma de más, una comilla faltante, claves al estilo de config.json en lugar del estilo de daemon.json.

Solución: mira el journal: sudo journalctl -u docker -n 50. Ahí se indicará la línea con el error. Corrígelo o restaura la copia de seguridad y reinicia el servicio.

Error 4: los contenedores dejaron de verse entre sí

Causa: después de la configuración global del proxy en config.json, las consultas a los contenedores vecinos también pasaron por el proxy móvil, que no sabe qué es db o redis.

Solución: agrega los nombres de los servicios y las subredes internas a NO_PROXY: localhost,127.0.0.1,db,redis,172.16.0.0/12. Ten en cuenta que las máscaras de subred no las entienden todas las aplicaciones, así que es más confiable enumerar los nombres explícitamente.

Error 5: docker build falla en apt-get o pip

Causa: la compilación va sin proxy, porque las variables están definidas para los contenedores y no para la compilación, o el proxy del demonio está configurado pero no influye en los pasos RUN.

Solución: pasa --build-arg HTTP_PROXY y HTTPS_PROXY, o configura la sección proxies en el config.json del cliente: también se aplica a la compilación.

Error 6: la contraseña del proxy se ve en docker inspect y en los logs

Causa: las variables de entorno se guardan en los metadatos del contenedor en texto plano, y cualquiera que tenga acceso a Docker las verá con docker inspect.

Solución: usa un gateway: los contenedores de trabajo solo conocen la dirección gateway:8118. La contraseña queda en un solo contenedor y en el archivo .env con permisos restringidos (chmod 600 .env).

Error 7: después de reiniciar el servidor el proxy dejó de funcionar

Causa: el contenedor-gateway no se lanzó con política de reinicio o la dirección del host del proxy móvil cambió.

Solución: agrega --restart unless-stopped al gateway. Usa el nombre de dominio del proxy en lugar de la IP, si el proveedor lo ofrece. Verifica docker ps -a: si el gateway está en estado Exited, mira sus logs.

Error 8: los sitios HTTPS no abren, pero HTTP funciona

Causa: solo está definida HTTP_PROXY, y HTTPS_PROXY está vacía, o en HTTPS_PROXY se indicó el esquema https:// en lugar de http://.

Solución: define siempre ambas variables con el mismo valor y el mismo esquema http://.

Funciones adicionales para avanzados: proxying transparente, rotación de IP y seguridad

Esta sección es para quienes ya pasaron los pasos básicos y quieren sacarle el máximo a la combinación de Docker y proxies móviles. Aquí hay menos listas paso a paso y más ideas con los comandos clave.

Proxying transparente: cuando la aplicación no sabe nada del proxy

Si tienes una aplicación que no sabe trabajar con proxies de ninguna manera, puedes envolver todo su tráfico TCP a nivel del stack de red. La idea es esta: el contenedor de trabajo se lanza con el parámetro network_mode: service:gateway (en Compose) o --network container:gateway (en docker run). Así usa por completo el stack de red del contenedor-gateway: la misma IP, las mismas interfaces, las mismas reglas de enrutamiento.

En el gateway, entonces, corre un programa como redsocks, que escucha en un puerto local y reenvía las conexiones a un proxy SOCKS5, mientras que reglas de iptables redirigen a ese puerto todo el tráfico TCP saliente. Para eso, el gateway necesita permisos: cap_add: NET_ADMIN. La aplicación en el contenedor de trabajo hace una consulta normal al sitio, el kernel la intercepta y la dirige a redsocks, y este — al proxy móvil. Sin variables de entorno. La configuración requiere cuidado: una regla de iptables incorrecta puede hacer un bucle con el tráfico, así que prueba en una máquina aparte. Ten en cuenta también que con network_mode: service el contenedor de trabajo pierde sus propios puertos y conexiones a otras redes, todo eso hay que describirlo en el gateway.

Rotación de IP desde el contenedor

Los proxies móviles tienen una particularidad por la que se los elige: la IP se puede cambiar a pedido. Los proveedores ofrecen un enlace especial de cambio de IP que basta con abrir para que el módem se reconecte. Desde el contenedor, esto se hace con el mismo curl. Un patrón útil: un servicio pequeño aparte en Compose que, según un horario, llama al enlace de rotación. No debe ir a través del proxy (de lo contrario, tras el cambio de IP perderá la conexión él mismo), así que lánzalo sin variables de proxy o explícitamente con HTTP_PROXY vacío. Ten en cuenta que tras el cambio de IP las conexiones activas de los contenedores de trabajo se romperán: prevé reintentos en los scrapers.

Salud del gateway: healthcheck

Agrega en Compose una verificación de que el gateway realmente hace de proxy y no solo está lanzado:

healthcheck: test: ["CMD", "gost", "-V"] interval: 30s timeout: 10s retries: 3

Es una verificación mínima de que el proceso está vivo. Para verificar la salida real a internet conviene un contenedor-monitor aparte, que una vez por minuto hace una consulta a través del gateway y escribe el resultado en un log o envía una notificación. Si de repente la IP se convirtió en la IP del servidor, es una alarma: el gateway se cayó y los contenedores salieron directo. La red interna del paso 6 justamente protege de ese escenario.

Almacenamiento seguro de contraseñas

El archivo .env es bueno para el trabajo local, pero en un servidor con varios usuarios conviene protegerlo: chmod 600 .env, dueño el usuario desde el que se lanza Compose. Compose también admite secretos mediante la directiva secrets, que se montan en el contenedor como archivo en /run/secrets/ en lugar de como variable de entorno. Gost no lee la contraseña de un archivo directamente, pero puedes escribir un pequeño script contenedor que arme la cadena -F a partir del archivo del secreto al arrancar. Así la contraseña no terminará ni en docker inspect ni en la salida de docker compose config.

Varios proyectos y una sola infraestructura de proxy

Si tienes varios proyectos de Compose y los proxies son compartidos, separa los gateways en un proyecto aparte con red externa: en él declara networks con el parámetro name: proxynet, y en los demás proyectos conéctate a ella como external: true. Entonces los gateways viven de forma independiente, y los proyectos de trabajo se pueden reiniciar cuanto quieras sin tocar los proxies.

Limitación de tráfico

El tráfico móvil suele facturarse, y un scraper descontrolado puede descargar decenas de gigabytes en una noche. A nivel de Docker no hay cuotas estrictas de tráfico, pero hay medidas indirectas: limitar la frecuencia de consultas en la propia aplicación, limitar el tiempo de vida del contenedor mediante timeout en el comando de lanzamiento y monitorear con docker stats, que muestra NET I/O por cada contenedor en tiempo real. Compara estas cifras con regularidad con las estadísticas del panel del proveedor.

Logs sin secretos

Muchas aplicaciones al arrancar imprimen las variables de entorno en el log, incluida HTTP_PROXY con la contraseña. Si los logs van a un sistema centralizado, la contraseña se filtrará allí. El gateway resuelve también este problema: en los logs de los contenedores de trabajo solo aparecerá gateway:8118.

Consejo: Cada trimestre rota las contraseñas de los proxies y actualiza el .env. Con el gateway esto toma un minuto: editas una línea, haces docker compose up -d gateway, y todos los workers siguen funcionando sin reiniciarse.

FAQ: preguntas frecuentes sobre la configuración de proxies en Docker

¿Hay que reiniciar el contenedor para aplicar nuevas variables de proxy?

Sí. Las variables de entorno se definen en el momento de crear el contenedor y no se pueden cambiar en uno en ejecución. Detén, elimina y crea el contenedor de nuevo (en Compose esto es docker compose up -d --force-recreate nombre_servicio). Si los reinicios molestan, usa un gateway: sus ajustes se pueden cambiar de forma independiente.

¿En qué se diferencia configurar el proxy para docker pull del proxy para la aplicación en el contenedor?

Son dos niveles distintos. docker pull lo ejecuta el demonio, y para él el proxy se configura en daemon.json o mediante systemd. La aplicación en el contenedor es un proceso aparte con su propio entorno; para ella el proxy se configura con variables, con el config.json del cliente o con la red. Uno no reemplaza al otro.

¿Se puede usar SOCKS5 en lugar de un proxy HTTP en las variables de entorno?

Se puede, si la aplicación soporta SOCKS. curl, Python requests (con el paquete PySocks instalado) y git lo soportan. apt y muchas otras, no. La salida universal es el gateway gost, que acepta HTTP a la entrada y envía a SOCKS5 a la salida: -L=http://:8118 -F=socks5://user:pass@host:port.

¿Cómo verificar qué proxy usa un contenedor ya lanzado?

Ejecuta docker inspect -f '{{.Config.Env}}' nombre_contenedor. Verás todas las variables de entorno. Para verificar la IP real usa docker exec nombre_contenedor curl -s ifconfig.me, si en el contenedor hay curl, o wget -qO- ifconfig.me.

¿Por qué en Docker Desktop el proxy funciona y en un servidor Linux los mismos ajustes no funcionan?

Docker Desktop aplica los ajustes de la ventana Proxies tanto al demonio como a los contenedores a la vez. En Linux son dos lugares separados: daemon.json para el demonio y ~/.docker/config.json para los contenedores. Verifica que configuraste ambos, si necesitas los dos.

¿Cómo definir un proxy solo para un dominio y dejar el resto directo?

Las variables de entorno no pueden hacer eso: funcionan con el principio de "todo por el proxy, excepto NO_PROXY". Si necesitas la lógica inversa, usa un archivo PAC del lado de la aplicación (los navegadores lo soportan) o reglas de enrutamiento en gost, que sabe dirigir el tráfico a distintos canales de salida según el dominio.

¿Es seguro guardar la contraseña del proxy en compose.yaml?

Mejor no. Guárdala en .env con permisos 600 y sustitúyela mediante ${NOMBRE}. No subas .env al repositorio. Para servidores usa un gateway, así la contraseña está en un solo lugar.

¿Qué hacer si el proxy móvil cambió de IP y las conexiones en los contenedores se cortaron?

Es un comportamiento normal durante la rotación. La aplicación debe saber reintentar las consultas. Si la rotación ocurre según el horario del proveedor, averigua el intervalo y sincroniza con él las operaciones pesadas. Si la rotación es por tu enlace, llámalo entre lotes de tareas, no en medio.

¿Funcionan estos ajustes en Windows sin WSL2?

Docker Desktop en Windows usa WSL2 o Hyper-V por debajo, y todos los comandos docker run y docker compose funcionan igual desde PowerShell. Solo cambian las rutas: el archivo config.json está en C:\Users\NombreUsuario\.docker\config.json, y los ajustes del demonio se hacen desde la ventana de Docker Desktop, no editando daemon.json a mano.

¿Cuántos contenedores se pueden pasar por un solo proxy móvil?

Técnicamente, los que quieras; la única limitación es el ancho de banda del canal móvil y los límites del plan. En la práctica, para tareas con cuentas es razonable mantener un proxy por cada entidad lógica (cuenta, proyecto, región), para que el comportamiento parezca natural y un error en un contenedor no afecte a los demás.

Conclusión: qué hiciste y hacia dónde avanzar

Resumamos. Verificaste el funcionamiento del proxy desde el host y aclaraste el formato de la cadena de conexión. Configuraste el proxy para un contenedor individual mediante variables de entorno y un archivo env-file. Hiciste automática la transmisión de variables mediante el config.json del cliente. Aclaraste cómo y para qué configurar el proxy del propio demonio de Docker de tres maneras. Describiste varios servicios con distintos proxies móviles en Docker Compose, sacando los secretos a .env. Y, finalmente, construiste un contenedor-gateway con red aislada, la solución más confiable para producción, que protege de fugas de la IP real incluso si la aplicación ignora las variables.

Ahora el proxy en Docker para ti no es una caja negra, sino tres niveles claros con límites bien definidos: demonio, contenedor, red. Sabes dónde buscar el problema si de repente la IP resultó ser otra, y sabes verificarlo con un solo comando.

Qué hacer después

1. Pasa tus proyectos de trabajo al esquema con gateway y red interna. Empieza con un servicio no crítico, asegúrate de que todo funciona y luego escala.
2. Agrega un contenedor-monitor que una vez por minuto verifique la IP externa a través del gateway y avise si coincide con la IP del servidor.
3. Configura la rotación de IP según el horario que necesites y enséñale a las aplicaciones a sobrevivir a la caída de la conexión.
4. Ordena los secretos: .env con permisos 600, ninguna contraseña en compose.yaml ni en el Dockerfile.

Hacia dónde desarrollarse

El siguiente paso lógico es conectar Docker con navegadores antidetect y herramientas de multicuentas, donde a cada perfil le corresponde su propio contenedor y su propio proxy móvil. Otra dirección es la automatización mediante la API del proveedor: obtener la lista de proxies, verificar su estado y rotarlos directamente desde tus servicios. Ambos temas quedan fuera del alcance de esta guía, pero el fundamento que acabas de sentar los hace mucho más simples. ¡Éxitos en los lanzamientos y que tengas IP estables!