Configuración de proxy en terminal Linux y CI: guía paso a paso para HTTP_PROXY, HTTPS_PROXY, NO_PROXY

Imagina: abres la terminal, escribes un comando para instalar un paquete, y en respuesta el silencio o un error de conexión. A menudo la razón es que el acceso a la red solo pasa a través de un servidor proxy, y el sistema no lo sabe. Esta guía te enseñará a configurar proxy en todos los lugares donde sea necesario en Linux y en CI.

Introducción: qué obtendrás y para quién es esta guía

Al final de este tutorial, podrás configurar proxies con confianza en la terminal de Linux y en sistemas de integración continua. Entenderás cómo funcionan las variables de entorno, cómo armar correctamente la URL del proxy y cómo hacer que todas las herramientas clave del desarrollador funcionen a través del proxy.

Qué obtendrás exactamente:

• Una configuración funcional de proxy en la sesión actual de la terminal.
• Una configuración permanente que sobreviva a un reinicio.
• La configuración correcta para apt, dnf, git, npm, pip, curl, wget, Docker.
• Pipelines de CI que funcionen en GitHub Actions y GitLab Runner.
• Comprensión de cómo verificar que el tráfico realmente pasa por el proxy.
• Habilidades para almacenar de forma segura la contraseña del proxy.

Para quién es esta guía: para administradores de sistemas principiantes, desarrolladores e ingenieros DevOps que trabajan en un entorno con proxy corporativo. También incluye elementos para avanzados: detalles de systemd, ProxyCommand para SSH y enmascaramiento de secretos en CI.

Qué necesitas saber de antemano: debes saber abrir una terminal, ingresar comandos y entender qué es un archivo y una carpeta. Todo lo demás se explica sobre la marcha en lenguaje sencillo.

Cuánto tiempo tomará: la configuración básica tomará unos 15 minutos. Completar toda la guía con la configuración de todas las herramientas y CI tomará aproximadamente 60-90 minutos. No te apresures, es mejor hacerlo con calma.

Consejo: mantén esta guía abierta en una ventana aparte y ejecuta los comandos uno por uno. Así no te perderás ningún paso importante.

Preparación previa: dirección, puerto, inicio de sesión y URL correcta del proxy

Antes de configurar nada, necesitas reunir los datos de tu servidor proxy. Sin ellos, no se puede avanzar.

Dónde obtener los datos del proxy

Normalmente, el proxy lo proporciona una de las siguientes partes:

• El administrador del sistema de la empresa — si trabajas en una red corporativa. Pídele la dirección, el puerto y los datos de autenticación.
• El servicio de alquiler de proxies — en el panel de control suele haber un bloque con la configuración de acceso.
• Tu propio servidor — si levantaste el proxy por tu cuenta, conoces los datos.

Necesitas cuatro elementos: dirección (host), puerto (port), usuario (username) y contraseña (password). A veces no se requieren usuario ni contraseña; entonces el proxy es sin autenticación.

Cómo armar la URL del proxy

El proxy se define como una sola cadena: la URL. El formato general es:

esquema://usuario:contraseña@dirección:puerto

Analicemos un ejemplo. Supongamos que la dirección del proxy es proxy.example.com, el puerto 3128, el usuario ivan y la contraseña secret123. Entonces la URL se verá así:

http://ivan:secret123@proxy.example.com:3128

Si no se necesita autenticación, la URL es más simple:

http://proxy.example.com:3128

Sobre el esquema: la mayoría de las veces se usa el esquema http incluso para acceder a sitios HTTPS. Esto es normal: el esquema aquí indica el protocolo de comunicación con el proxy en sí, no con el sitio de destino. A veces hay proxies con esquema https o socks5.

Por qué los caracteres especiales en la contraseña deben codificarse

Esta es una de las causas más frecuentes de errores misteriosos. Si la contraseña contiene caracteres especiales como @, :, /, #, ?, estos rompen el análisis de la URL. Por ejemplo, el símbolo @ separa los datos de autenticación de la dirección. Si aparece en la contraseña, el sistema se confundirá y no sabrá dónde termina la contraseña y comienza la dirección.

La solución es el percent-encoding (codificación porcentual). Cada carácter problemático se reemplaza por un signo de porcentaje y su código en hexadecimal.

Los reemplazos principales:

• El símbolo @ se convierte en %40
• El símbolo : se convierte en %3A
• El símbolo / se convierte en %2F
• El símbolo # se convierte en %23
• El símbolo ? se convierte en %3F
• El símbolo de espacio se convierte en %20
• El símbolo % se convierte en %25

Ejemplo: si la contraseña es p@ss:word, entonces en la URL debe verse como p%40ss%3Aword. Entonces la URL completa será:

http://ivan:p%40ss%3Aword@proxy.example.com:3128

Consejo: para codificar rápidamente una contraseña, usa el comando python3 -c "import urllib.parse, sys; print(urllib.parse.quote(sys.argv[1], safe=''))" 'tu_contraseña'. Te dará la cadena lista para insertar en la URL.

⚠️ Atención: nunca ingreses la contraseña real directamente en la línea de comandos a la vista en una computadora compartida, porque quedará en el historial. Hablaremos sobre la entrada segura por separado al final de la guía.

✅ Verificación: debes tener una o varias URLs de proxy armadas, con todos los caracteres especiales de la contraseña codificados. Anótalas en un lugar seguro, preferiblemente en un gestor de contraseñas.

Conceptos básicos: variables de entorno, mayúsculas/minúsculas y formato de NO_PROXY

Para que la configuración no sea magia, analicemos tres conceptos fundamentales. Tomará cinco minutos, pero te ahorrará horas de depuración.

Qué son las variables de entorno

Una variable de entorno es un valor con nombre que el sistema operativo guarda en memoria y pasa a los programas que se ejecutan. Imagínalo como una nota que el sistema le muestra a cada nuevo programa: aquí está la dirección del proxy, úsala.

Muchas utilidades de red en Linux, al iniciarse, leen variables especiales y, si las encuentran, dirigen automáticamente el tráfico a través del proxy. Las más importantes son:

• HTTP_PROXY — proxy para solicitudes HTTP no cifradas.
• HTTPS_PROXY — proxy para solicitudes HTTPS cifradas.
• NO_PROXY — lista de direcciones a las que se debe acceder directamente, sin pasar por el proxy.
• FTP_PROXY — proxy para el protocolo FTP, actualmente se usa poco.
• ALL_PROXY — proxy para todos los protocolos a la vez, a menudo se usa para socks.

Diferencia entre http_proxy y HTTP_PROXY según mayúsculas/minúsculas

Este es un detalle sutil pero importante. Linux distingue entre mayúsculas y minúsculas, por lo que http_proxy y HTTP_PROXY son formalmente dos variables diferentes. Diferentes programas leen diferentes variantes.

Históricamente, se ha dado lo siguiente:

• La utilidad curl lee tanto la versión en minúsculas como en mayúsculas, pero la minúscula http_proxy tiene una característica de seguridad: curl ignora HTTP_PROXY mayúscula en entornos CGI para evitar ataques.
• La utilidad wget tradicionalmente prefiere los nombres en minúsculas.
• Muchos programas en diferentes lenguajes leen las versiones en mayúsculas.

Conclusión práctica: para no adivinar, define ambas versiones: la minúscula y la mayúscula. Esta es la estrategia más confiable, y la usaremos.

Formato de NO_PROXY y por qué no entiende CIDR

La variable NO_PROXY contiene una lista separada por comas de direcciones a las que se debe acceder directamente. Esto es crítico para recursos internos: bases de datos, servicios locales, metadatos de la nube.

Ejemplo de un valor correcto:

localhost,127.0.0.1,.example.com,.internal,169.254.169.254

Observa el punto antes de example.com. El punto significa que la regla aplica a todos los subdominios: api.example.com, git.example.com, etc.

⚠️ Atención: normalmente, NO_PROXY no entiende la notación CIDR ni las máscaras de subred. Una entrada como 10.0.0.0/8 no funcionará en la mayoría de las herramientas. Algunas versiones modernas de bibliotecas lo soportan, pero no se puede confiar en ello. Enumera direcciones específicas y sufijos de dominio explícitamente.

Además, NO_PROXY generalmente no admite asteriscos como comodín universal. No escribas *.example.com — usa un punto al inicio: .example.com.

Consejo: agrega siempre a NO_PROXY las direcciones localhost y 127.0.0.1. De lo contrario, las solicitudes locales irán a través del proxy y probablemente fallarán.

✅ Verificación: entiendes para qué sirven HTTP_PROXY, HTTPS_PROXY y NO_PROXY, conoces la diferencia de mayúsculas/minúsculas y recuerdas que NO_PROXY no acepta CIDR. Ahora podemos pasar a la práctica.

Paso 1: activamos el proxy en la sesión actual y lo verificamos con curl

Objetivo de la etapa: aprender a activar rápidamente el proxy en la terminal abierta y asegurarse de que funciona. Estos ajustes solo viven hasta que se cierra la ventana de la terminal, ideal para probar.

Definimos las variables con export

El comando export crea una variable de entorno en la sesión actual. Ejecuta los siguientes comandos, sustituyendo tu URL de proxy.

1. Abre la terminal.
2. Ingresa el comando para HTTP: export http_proxy="http://ivan:secret123@proxy.example.com:3128"
3. Ingresa el comando para HTTPS: export https_proxy="http://ivan:secret123@proxy.example.com:3128"
4. Duplica en mayúsculas: export HTTP_PROXY="$http_proxy"
5. Y otra vez: export HTTPS_PROXY="$https_proxy"
6. Define las excepciones: export no_proxy="localhost,127.0.0.1,.example.com"
7. Duplica: export NO_PROXY="$no_proxy"

La construcción "$http_proxy" sustituye el valor de la variable en minúsculas ya definida, para no escribir la URL de nuevo.

Consejo: observa que toda la URL está entre comillas dobles. Esto protege contra la interpretación incorrecta de caracteres especiales por parte de tu shell bash.

Verificamos con curl

Ahora comprobemos que las variables se leen. La utilidad curl es perfecta para esto.

1. Verifica que la variable esté definida: echo $http_proxy — deberías ver tu URL.
2. Realiza una solicitud con salida detallada: curl -v http://example.com
3. En la salida, busca una línea que mencione Connected to proxy.example.com — esto significa que curl pasó por el proxy.

Si la autenticación es correcta y el proxy está accesible, obtendrás una página HTML en la respuesta. Si ves un error 407, el problema está en el usuario o la contraseña; vuelve a la sección sobre codificación de contraseñas.

Consejo: la bandera -v (verbose) muestra los detalles de la conexión. Es tu principal herramienta de depuración de proxy. Sin ella, no verás hacia dónde va realmente la solicitud.

Para desactivar el proxy en la sesión actual, usa el comando unset: unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY no_proxy NO_PROXY. Todas las variables desaparecerán.

✅ Verificación: el comando curl -v http://example.com muestra la conexión a través de tu servidor proxy y devuelve el contenido de la página. Si es así, el primer paso se ha completado con éxito.

Paso 2: hacemos la configuración permanente

Objetivo de la etapa: lograr que el proxy se active automáticamente cada vez que inicies sesión y sobreviva a un reinicio. Aquí hay varios niveles; elige el adecuado.

Opción A: solo para tu usuario mediante ~/.bashrc

El archivo ~/.bashrc se ejecuta cada vez que abres una terminal interactiva con tu usuario. Es la opción más segura: no afecta a otros usuarios del sistema.

1. Abre el archivo con un editor: nano ~/.bashrc
2. Desplázate hasta el final del archivo.
3. Agrega las mismas líneas export que en el Paso 1.
4. Guarda el archivo: presiona Ctrl+O, luego Enter, luego Ctrl+X para salir.
5. Aplica los cambios sin reiniciar: source ~/.bashrc

Consejo: antes de editar, haz una copia de seguridad con cp ~/.bashrc ~/.bashrc.backup. Si algo sale mal, podrás restaurar el original fácilmente.

Opción B: para todo el sistema mediante /etc/environment

El archivo /etc/environment define variables para todos los usuarios y funciona incluso fuera de bash. El formato aquí es especial: sin la palabra export, solo NOMBRE=valor.

1. Abre el archivo con permisos de administrador: sudo nano /etc/environment
2. Agrega líneas sin export, por ejemplo: http_proxy="http://ivan:secret123@proxy.example.com:3128"
3. Agrega de manera similar https_proxy, HTTP_PROXY, HTTPS_PROXY, no_proxy, NO_PROXY.
4. Guarda y sal.
5. Para aplicar, cierra sesión y vuelve a iniciarla, o reinicia.

Opción C: mediante /etc/profile.d

Una forma más flexible a nivel de sistema es crear un script separado en la carpeta /etc/profile.d. Todos los archivos .sh allí se ejecutan al iniciar sesión.

1. Crea el archivo: sudo nano /etc/profile.d/proxy.sh
2. Dentro, usa los comandos export normales, como en el Paso 1.
3. Guarda el archivo.
4. Hazlo ejecutable: sudo chmod +x /etc/profile.d/proxy.sh

Este método es más práctico que /etc/environment porque admite la sintaxis completa del shell.

Opción D: para servicios del sistema mediante systemd drop-in

Atención, este es un detalle importante. Los servicios en segundo plano gestionados por systemd no leen tu ~/.bashrc y a menudo ignoran /etc/environment. Necesitan un enfoque aparte: un archivo drop-in.

Supongamos que necesitas que un servicio específico, por ejemplo some-service, funcione a través del proxy.

1. Crea el directorio drop-in y el archivo con el comando: sudo systemctl edit some-service
2. Se abrirá un editor. Escribe el bloque de configuración.
3. En la sección [Service], agrega líneas como Environment="HTTP_PROXY=http://ivan:secret123@proxy.example.com:3128"
4. Agrega líneas Environment similares para HTTPS_PROXY y NO_PROXY.
5. Guarda el archivo.
6. Vuelve a cargar la configuración: sudo systemctl daemon-reload
7. Reinicia el servicio: sudo systemctl restart some-service

La directiva Environment define la variable específicamente para ese servicio. Esta es la única forma correcta para servicios de systemd.

⚠️ Atención: en RHEL, CentOS, Fedora y AlmaLinux, las rutas y herramientas son las mismas: systemd funciona igual. Las diferencias aparecerán más adelante, en la sección sobre gestores de paquetes.

✅ Verificación: abre una nueva terminal (no la que usaste para hacer export manual) y ejecuta echo $http_proxy. Si ves tu URL, la configuración permanente funciona.

Paso 3: configuramos los gestores de paquetes y utilidades por separado

Objetivo de la etapa: muchas herramientas no leen las variables de entorno o tienen sus propios archivos de configuración. Configuraremos cada una por separado para que nada falle.

apt en Ubuntu y Debian

El gestor de paquetes apt a menudo se ejecuta con sudo y puede no ver tus variables. Es más seguro definir el proxy en su propio archivo de configuración.

1. Crea el archivo: sudo nano /etc/apt/apt.conf.d/95proxies
2. Agrega la línea: Acquire::http::Proxy "http://ivan:secret123@proxy.example.com:3128";
3. Agrega la línea para HTTPS: Acquire::https::Proxy "http://ivan:secret123@proxy.example.com:3128";
4. Guarda el archivo.
5. Verifica: sudo apt update

Observa el punto y coma al final de cada línea; es un elemento obligatorio de la sintaxis de apt.

dnf y yum en RHEL, Fedora, AlmaLinux

En sistemas de la familia RHEL, en lugar de apt se usan dnf y yum. El proxy se define en el archivo de configuración principal.

1. Abre el archivo: sudo nano /etc/dnf/dnf.conf (para sistemas antiguos /etc/yum.conf)
2. En la sección [main], agrega la línea: proxy=http://proxy.example.com:3128
3. Si se necesita autenticación, agrega por separado: proxy_username=ivan y proxy_password=secret123
4. Guarda el archivo.
5. Verifica: sudo dnf makecache

En dnf, es más práctico definir el usuario y la contraseña con directivas separadas, en lugar de incluirlos en la URL.

npm mediante .npmrc

1. Define el proxy con el comando: npm config set proxy "http://ivan:secret123@proxy.example.com:3128"
2. Define para HTTPS: npm config set https-proxy "http://ivan:secret123@proxy.example.com:3128"
3. La configuración se escribirá automáticamente en el archivo ~/.npmrc.
4. Verifica: npm config get proxy

pip mediante pip.conf

1. Crea el directorio: mkdir -p ~/.config/pip
2. Abre el archivo: nano ~/.config/pip/pip.conf
3. Agrega la sección [global] y la línea proxy = http://ivan:secret123@proxy.example.com:3128
4. Guarda el archivo.
5. Verifica instalando cualquier paquete: pip install requests

Alternativamente, puedes indicar el proxy directamente en el comando: pip install requests --proxy http://proxy.example.com:3128

git mediante http.proxy

1. Define globalmente: git config --global http.proxy "http://ivan:secret123@proxy.example.com:3128"
2. Si es necesario, por separado para HTTPS: git config --global https.proxy "http://ivan:secret123@proxy.example.com:3128"
3. Verifica: git config --global --get http.proxy

Para eliminar la configuración: git config --global --unset http.proxy

git por SSH mediante ProxyCommand

Si clonas repositorios por SSH (dirección del tipo git@github.com), la configuración http.proxy no servirá, porque SSH es otro protocolo. Aquí se necesita ProxyCommand.

1. Abre el archivo: nano ~/.ssh/config
2. Agrega un bloque para el host deseado: línea Host github.com, luego con sangría la línea ProxyCommand nc -X connect -x proxy.example.com:3128 %h %p
3. Guarda el archivo.
4. Instala la utilidad netcat si no está: sudo apt install netcat-openbsd en Ubuntu, sudo dnf install nmap-ncat en RHEL.

Aquí %h y %p se reemplazan automáticamente por el host y el puerto de destino. La bandera -X connect indica a netcat que use un proxy HTTP.

curl mediante .curlrc

1. Abre el archivo: nano ~/.curlrc
2. Agrega la línea: proxy = "http://ivan:secret123@proxy.example.com:3128"
3. Guarda el archivo.

Ahora curl usará el proxy siempre, incluso sin variables de entorno.

wget mediante .wgetrc

1. Abre el archivo: nano ~/.wgetrc
2. Agrega las líneas: http_proxy = http://proxy.example.com:3128 y https_proxy = http://proxy.example.com:3128
3. Agrega use_proxy = on
4. Guarda el archivo.

composer para PHP

Composer lee la variable de entorno HTTP_PROXY, por lo que a menudo no se necesita una configuración aparte. Si quieres definirla explícitamente, usa la variable al momento de ejecución: HTTP_PROXY=http://proxy.example.com:3128 composer install

Go y GOPROXY: una advertencia importante

⚠️ Atención: la variable GOPROXY NO es un servidor proxy en nuestro sentido. No se deben confundir. GOPROXY apunta a un espejo de módulos de Go, un servicio desde donde se descargan las bibliotecas. Es una dirección de repositorio, no un proxy de red.

Para que Go acceda a Internet a través de tu proxy normal, usa las variables estándar HTTP_PROXY y HTTPS_PROXY. Y deja GOPROXY con su valor predeterminado, a menos que tengas una tarea específica de cambiar el espejo de módulos.

Consejo: recuerda la regla: si el nombre de una variable contiene la palabra PROXY, eso no significa que se trate de tu proxy de red. GOPROXY, npm registry y similares son sobre las fuentes de los paquetes.

✅ Verificación: ejecuta una operación de prueba con cada herramienta configurada: sudo apt update, npm install, git ls-remote, etc. Todas deben poder acceder a la red correctamente.

Paso 4: configuramos Docker y Kubernetes

Objetivo de la etapa: Docker es un caso especial. Tiene tres lugares diferentes para configurar el proxy, y confundirlos es un error típico. Analicemos cada uno.

Lugar 1: el demonio de Docker mediante systemd drop-in

Esta configuración es necesaria para que el propio Docker pueda descargar imágenes del registro. El demonio de Docker está gestionado por systemd, por lo que usamos el mecanismo drop-in ya conocido.

1. Crea el directorio: sudo mkdir -p /etc/systemd/system/docker.service.d
2. Crea el archivo: sudo nano /etc/systemd/system/docker.service.d/proxy.conf
3. Agrega la sección [Service].
4. Agrega la línea Environment="HTTP_PROXY=http://proxy.example.com:3128"
5. Agrega líneas similares para HTTPS_PROXY y NO_PROXY.
6. Vuelve a cargar la configuración: sudo systemctl daemon-reload
7. Reinicia Docker: sudo systemctl restart docker

Puedes verificarlo con: sudo systemctl show --property=Environment docker

Lugar 2: construcción de imágenes mediante build-arg

Al construir una imagen, los comandos dentro del Dockerfile (por ejemplo, apt install) se ejecutan en un entorno aislado que no ve el proxy del host. El proxy debe pasarse explícitamente.

1. En el Dockerfile, agrega las instrucciones ARG http_proxy y ARG https_proxy antes de los comandos RUN.
2. Construye la imagen pasando los argumentos: docker build --build-arg http_proxy=http://proxy.example.com:3128 --build-arg https_proxy=http://proxy.example.com:3128 -t myimage .

⚠️ Atención: no escribas la contraseña del proxy directamente en el Dockerfile con la instrucción ENV. Quedará en las capas de la imagen y cualquiera que obtenga la imagen verá la contraseña. Usa build-arg, o mejor aún, un proxy sin contraseña para la construcción.

Lugar 3: contenedores al ejecutarse mediante ~/.docker/config.json

Para que los contenedores en ejecución reciban automáticamente las variables de proxy, configura el archivo de configuración del cliente Docker.

1. Abre el archivo: nano ~/.docker/config.json
2. Agrega el bloque proxies con la sección default.
3. Dentro, indica httpProxy, httpsProxy y noProxy con sus valores.
4. Guarda el archivo.

Ahora, cada vez que ejecutes docker run, las variables se pasarán automáticamente al interior del contenedor.

Variables en el manifiesto de Kubernetes

En Kubernetes, el proxy se define mediante variables de entorno en la especificación del contenedor. En la sección env del manifiesto Pod o Deployment, agrega elementos con name HTTP_PROXY, HTTPS_PROXY, NO_PROXY y sus respectivos value.

Consejo: los valores secretos en Kubernetes guárdalos en un objeto Secret y conéctalos mediante valueFrom, no escribas la contraseña directamente en el manifiesto. Así la contraseña no aparecerá en el sistema de control de versiones.

✅ Verificación: ejecuta docker pull hello-world — la imagen debería descargarse. Luego docker run --rm alpine env | grep -i proxy — verás las variables pasadas dentro del contenedor.

Paso 5: configuramos el proxy en CI — GitHub Actions y GitLab Runner

Objetivo de la etapa: lograr que los pipelines de CI funcionen a través del proxy, almacenando el acceso de forma segura y sin exponer la contraseña en los registros.

Almacenamiento del acceso en secretos

La regla principal de CI: nunca escribas la contraseña del proxy directamente en el archivo YAML del pipeline. El archivo está en el repositorio y la contraseña la verán todos. Usa el mecanismo de secretos.

En GitHub Actions, los secretos se agregan en la configuración del repositorio, sección Settings, luego Secrets and variables, luego Actions. Crea un secreto con el nombre PROXY_URL y pega allí la URL completa del proxy.

En GitLab, los secretos se denominan CI/CD variables. Se agregan en Settings, luego CI/CD, luego Variables. Asegúrate de marcar las casillas Masked y Protected para valores sensibles.

Configuración de GitHub Actions

1. En el archivo del pipeline .github/workflows, agrega a nivel de job un bloque env.
2. Define HTTP_PROXY con el valor del secreto usando la sintaxis de dobles llaves con secrets.PROXY_URL.
3. Define de manera similar HTTPS_PROXY y NO_PROXY.
4. Estas variables estarán disponibles en todos los pasos del job.

Configuración de GitLab Runner

En GitLab hay dos niveles. Puedes definir variables en el propio archivo .gitlab-ci.yml mediante el bloque variables, o a nivel del runner en su archivo de configuración config.toml mediante la sección environment.

1. Para el proyecto: agrega en .gitlab-ci.yml un bloque variables con referencias a las variables protegidas.
2. Para todos los proyectos del runner: abre el config.toml del runner y en la sección [[runners]] agrega el parámetro environment con la lista de las variables necesarias.

Enmascaramiento de la contraseña en los registros

Incluso con secretos, la contraseña puede terminar accidentalmente en el registro si algún comando la imprime. GitHub Actions enmascara automáticamente los valores de los secretos con asteriscos. En GitLab, esto lo maneja la casilla Masked, pero solo funciona si el valor cumple ciertos requisitos (sin algunos caracteres especiales y con la longitud suficiente).

⚠️ Atención: evita comandos con la bandera -v o echo que impriman la URL completa del proxy en el registro. Incluso con enmascaramiento, es mejor no arriesgarse. Para depurar, imprime solo la dirección y el puerto sin usuario ni contraseña.

Consejo: almacena la URL del proxy sin la contraseña incrustada, y guarda el usuario y la contraseña como secretos separados. Así será más fácil enmascararlos y rotarlos.

✅ Verificación: ejecuta el pipeline manualmente. El paso que realiza una solicitud de red (por ejemplo, instalar dependencias) debe completarse con éxito. En los registros, la contraseña no debe ser visible.

Verificación del resultado: asegurémonos de que el tráfico realmente pase por el proxy

Configurar no es suficiente; hay que demostrar que el tráfico realmente pasa por el proxy y no va directamente. Aquí tienes una lista de verificación.

Lista de verificación: qué debería funcionar

• El comando echo $http_proxy en una terminal nueva muestra tu URL.
• curl -v http://example.com muestra la línea Connected to proxy.
• sudo apt update actualiza correctamente las listas de paquetes.
• git ls-remote hacia un repositorio remoto funciona.
• docker pull descarga una imagen.
• El pipeline de CI se completa en verde.

Cómo probar de manera confiable

La forma más honesta es saber qué dirección IP externa ve el servidor de destino. Realiza una solicitud a un servicio que muestre tu IP. Si pasas por el proxy, verás la IP del servidor proxy, no la tuya.

1. Realiza la solicitud sin proxy: env -u http_proxy -u https_proxy curl -s http://ifconfig.me — verás tu IP real.
2. Realízala con proxy: curl -s http://ifconfig.me — verás la IP del proxy.
3. Si las dos direcciones son diferentes, el proxy funciona.

Otra forma es mirar los registros del propio servidor proxy, si tienes acceso a ellos. Tus solicitudes deberían aparecer allí.

Consejo: el comando env -u elimina temporalmente la variable solo para un comando, sin afectar la sesión. Es útil para comparar el comportamiento con y sin proxy.

✅ Verificación: la IP con proxy es diferente de la IP directa. Esta es una prueba al cien por cien de que el tráfico pasa por el proxy.

Errores típicos y sus soluciones

Analicemos los problemas frecuentes. Formato simple: problema, causa, solución.

Problema 1: sudo no hereda las variables

Causa: sudo por defecto limpia el entorno por razones de seguridad. Tus export no llegan al comando ejecutado con sudo.

Solución: usa la bandera -E para conservar el entorno: sudo -E apt update. O configura la conservación permanente mediante el archivo sudoers. Ejecuta sudo visudo y agrega la línea Defaults env_keep += "http_proxy https_proxy HTTP_PROXY HTTPS_PROXY no_proxy NO_PROXY". Después de esto, sudo siempre pasará estas variables.

Problema 2: errores de certificados

Causa: algunos proxies corporativos interceptan HTTPS y reemplazan los certificados por su propio certificado raíz. El sistema no lo reconoce y se queja de una conexión no confiable.

Solución: obtén del administrador el certificado raíz del proxy. En Ubuntu y Debian, cópialo en /usr/local/share/ca-certificates con extensión .crt y ejecuta sudo update-ca-certificates. En RHEL, colócalo en /etc/pki/ca-trust/source/anchors y ejecuta sudo update-ca-trust. Después de esto, todas las herramientas confiarán en el proxy.

Problema 3: curl funciona, apt no funciona

Causa: curl lee las variables de entorno, pero apt bajo sudo no las ve y no tiene su propio archivo de configuración de proxy.

Solución: configura el proxy en /etc/apt/apt.conf.d, como se describió en el Paso 3. Es una configuración aparte de las variables de entorno, y es la que necesita apt.

Problema 4: contraseña con caracteres especiales

Causa: los caracteres @, :, / en la contraseña sin codificar rompen el análisis de la URL.

Solución: aplica percent-encoding de la sección de Preparación. Reemplaza @ por %40, : por %3A, etc.

Problema 5: error 407 Proxy Authentication Required

Causa: usuario o contraseña incorrectos, o el proxy requiere autenticación y no la has proporcionado.

Solución: verifica el usuario y la contraseña. Asegúrate de que los datos de autenticación estén en la URL. Verifica la codificación de caracteres especiales.

Problema 6: recursos internos inaccesibles

Causa: las solicitudes a direcciones locales e internas pasan por el proxy, que no las conoce.

Solución: agrega esas direcciones a NO_PROXY. No olvides localhost, 127.0.0.1 y los dominios internos con un punto al inicio.

Problema 7: el demonio de Docker no ve el proxy

Causa: configuraste las variables en bashrc, pero el demonio de Docker es gestionado por systemd y no las lee.

Solución: usa el systemd drop-in del Paso 4, no olvides daemon-reload y restart docker.

Problema 8: la configuración no se aplicó

Causa: editaste bashrc pero no reiniciaste la terminal.

Solución: ejecuta source ~/.bashrc o abre una nueva ventana de terminal.

Opciones adicionales y configuraciones avanzadas

Cuando la configuración básica funciona, se puede mejorar la comodidad y flexibilidad.

Funciones de conmutación de proxy

Es útil definir en ~/.bashrc dos funciones: proxy_on para activar y proxy_off para desactivar. Dentro de proxy_on coloca los comandos export, dentro de proxy_off los comandos unset. Así el cambio será un solo comando.

Diferentes proxies para diferentes tareas

Puedes definir un proxy solo para un comando, sin cambiar todo el entorno. Ejemplo: https_proxy=http://other:3128 curl https://example.com. La variable solo actúa para ese comando.

Proxy SOCKS

Si tienes un proxy de tipo SOCKS5, usa el esquema socks5 en la URL y la variable ALL_PROXY. Para curl, existe la bandera --socks5. Ten en cuenta que no todas las utilidades pueden trabajar con SOCKS.

Consejo: para herramientas que no soportan proxy en absoluto, existen envoltorios como proxychains. Pero úsalos con conciencia, ya que modifican el comportamiento de las llamadas de red del programa.

Tabla resumen de configuraciones

Ten este resumen a mano. Formato: herramienta — archivo de configuración — variable o directiva.

• Sesión de shell — temporal en memoria — export http_proxy y HTTP_PROXY.
• Usuario — ~/.bashrc — export de variables.
• Todo el sistema — /etc/environment — http_proxy sin export.
• Todo el sistema — /etc/profile.d/proxy.sh — export de variables.
• Servicio systemd — drop-in mediante systemctl edit — directiva Environment.
• apt (Ubuntu, Debian) — /etc/apt/apt.conf.d/95proxies — Acquire::http::Proxy.
• dnf, yum (RHEL) — /etc/dnf/dnf.conf — proxy, proxy_username, proxy_password.
• npm — ~/.npmrc — proxy y https-proxy.
• pip — ~/.config/pip/pip.conf — proxy en sección global.
• git por HTTPS — configuración global de git — http.proxy.
• git por SSH — ~/.ssh/config — ProxyCommand.
• curl — ~/.curlrc — proxy.
• wget — ~/.wgetrc — http_proxy, https_proxy, use_proxy.
• composer — entorno — HTTP_PROXY.
• Demonio de Docker — /etc/systemd/system/docker.service.d/proxy.conf — Environment.
• Construcción de Docker — comando build — build-arg http_proxy.
• Contenedores Docker — ~/.docker/config.json — bloque proxies.
• Kubernetes — manifiesto Pod — env con HTTP_PROXY.
• GitHub Actions — archivo workflow — bloque env con secrets.
• GitLab — .gitlab-ci.yml o config.toml — variables o environment.

FAQ: preguntas frecuentes sobre configuración de proxy

¿Es necesario definir tanto las variables en minúsculas como en mayúsculas?

Sí, es la estrategia más confiable. Diferentes programas leen diferentes mayúsculas/minúsculas, por lo que definir ambas versiones evita sorpresas.

¿Por qué curl ve el proxy pero apt no?

Porque apt bajo sudo no hereda las variables de entorno y tiene su propio archivo de configuración. Configura apt por separado mediante un archivo en /etc/apt/apt.conf.d.

¿Cómo desactivar temporalmente el proxy para un solo comando?

Usa env -u http_proxy -u https_proxy antes del comando. Esto eliminará las variables solo para esa ejecución.

¿Se puede especificar una subred en NO_PROXY?

Generalmente no. NO_PROXY no entiende la notación CIDR de manera confiable. Enumera direcciones específicas y sufijos de dominio con un punto al inicio.

¿GOPROXY es mi servidor proxy?

No. GOPROXY apunta a un espejo de módulos de Go, no a un proxy de red. Para el proxy de red en Go, usa HTTP_PROXY y HTTPS_PROXY.

¿Cómo almacenar la contraseña del proxy de forma segura?

En CI, usa secretos. Localmente, emplea un archivo .netrc con permisos 600 o un gestor de contraseñas. Evita que la contraseña quede en el historial de comandos.

¿Por qué git por SSH no pasa por http.proxy?

Porque SSH es un protocolo diferente. Configura ProxyCommand en el archivo ~/.ssh/config para el host correspondiente.

¿Qué hacer con errores de certificados a través del proxy?

Instala el certificado raíz del proxy en el almacén de confianza del sistema y actualiza la confianza con el comando update-ca-certificates en Debian o update-ca-trust en RHEL.

Las configuraciones en bashrc no funcionan en una nueva sesión, ¿por qué?

Posiblemente editaste el archivo equivocado, no guardaste los cambios o no abriste una nueva terminal. Verifica con echo y source.

¿Cómo comprobar que el tráfico realmente pasa por el proxy?

Compara la IP externa con y sin proxy usando curl a un servicio de detección de IP. Direcciones diferentes confirman que el proxy está funcionando.

Conclusión: qué has aprendido y hacia dónde seguir

Felicitaciones, has recorrido un largo camino. Resumamos lo que ahora sabes hacer.

Has aprendido a armar una URL de proxy correcta y a codificar caracteres especiales en la contraseña. Entendiste las variables HTTP_PROXY, HTTPS_PROXY y NO_PROXY, incluyendo los detalles de mayúsculas/minúsculas y el formato de exclusiones. Sabes activar el proxy en una sesión y hacer la configuración permanente de varias maneras, incluido el systemd drop-in para servicios.

Has configurado el proxy para todas las herramientas clave: apt y dnf, npm y pip, git por HTTPS y por SSH, curl y wget, composer, y entendiste la importante diferencia de GOPROXY. Dominaste los tres lugares de configuración de Docker y las variables en Kubernetes. Finalmente, configuraste el proxy en GitHub Actions y GitLab con almacenamiento seguro de secretos y enmascaramiento de contraseñas.

Qué hacer a continuación: afianza los conocimientos con la práctica. Configura un proxy en una máquina de prueba desde cero siguiendo la guía. Crea funciones de conmutación para mayor comodidad. Estudia los registros de tu servidor proxy para ver el tráfico con tus propios ojos.

Hacia dónde avanzar: el siguiente paso es la automatización de la configuración mediante herramientas de gestión de configuración como Ansible, para desplegar proxies en decenas de máquinas con un solo comando. También es útil profundizar en el manejo de certificados y diferentes tipos de proxy.

Consejo: guarda la tabla resumen de esta guía como chuleta. Te ahorrará mucho tiempo cuando necesites recordar rápidamente dónde se configura el proxy para una herramienta concreta.

Lo has hecho muy bien. Ahora el proxy en la terminal de Linux y en CI no es ningún misterio para ti. ¡Buena suerte con las configuraciones y que tengas conexiones estables!