Debian 13: configuraciones de proxy que rompen apt/curl — dónde se esconden y cómo limpiarlas

octubre 9, 2025 • febrero 3, 2026 • Lectura: 25 min • Views: 8

¿Te fue útil?

El síntoma es siempre el mismo: apt update se queda colgado, curl devuelve un desconcertante 407, y la máquina insiste en que “no tiene proxy configurado.”
Entonces descubres que el proxy está configurado en cinco sitios, la mitad invisibles para la persona que atiende el pager en ese momento.

Debian 13 no “rompe” la red. Solo sigue las instrucciones fielmente—algunas dejadas por un script de arranque ya desaparecido, una imagen corporativa,
o esa vez que alguien exportó http_proxy en un perfil de shell y se le olvidó. Vamos a cazar las configuraciones de proxy, eliminarlas limpiamente,
y demostrar que el sistema está realmente sin proxy.

Guía de diagnóstico rápido

Cuando apt/curl fallan y buscas la vía más rápida hacia la verdad, no empieces leyendo todos los archivos de configuración del planeta.
Empieza observando el comportamiento y preguntando: “¿Es esto decisión de proxy, un problema de DNS, o un problema de TLS/ruta?”

1) Comprueba si se está usando un proxy (entorno + vista de apt)

Ejecuta env | grep -i proxy en el mismo contexto que el comando que falla (tu shell, shell root, vía sudo).
Ejecuta apt-config dump | grep -i proxy para ver qué cree apt que está configurado.

Si cualquiera muestra un proxy que no esperabas, ya encontraste el cuello de botella: configuración, no “red.”

2) Confirma el enrutamiento y DNS básicos sin involucrar proxies

Comprueba DNS: getent ahosts deb.debian.org
Comprueba la accesibilidad HTTPS directa: curl -v --noproxy '*' https://deb.debian.org/

Si la conexión directa funciona pero apt falla, casi siempre es configuración de apt o diferencias en la política de intercepción TLS.

3) Reduce el alcance: ¿qué capa está inyectando el proxy?

Si curl usa un proxy inesperadamente, suele ser vars de entorno o configuración de libcurl.
Si solo apt usa un proxy, suele estar en /etc/apt/apt.conf* o en un drop-in incluido.
Si los servicios (no los shells interactivos) usan un proxy, sospecha de drop-ins de entorno del gestor systemd.

4) Prueba la corrección

Después de los cambios, vuelve a ejecutar apt-config dump, systemctl show-environment, y una prueba con curl -v.
No confíes en “quité la línea.” Confía en las salidas.

Hechos y contexto: por qué los proxies fantasmas son comunes

Un poco de historia ayuda a explicar por qué las configuraciones de proxy son tan escurridizas en Linux, y por qué Debian 13 no es especial aquí—solo lo bastante moderno como para darte más sitios donde esconder problemas.
Aquí algunos hechos concretos que aparecen en entornos reales:

Las variables de entorno de proxy preceden a las herramientas actuales. http_proxy y afines se convirtieron en un estándar de facto porque eran fáciles de exportar y scriptar.
La distinción entre mayúsculas y minúsculas importa, hasta que no. Muchas herramientas comprueban primero las variables en minúsculas (http_proxy), otras en mayúsculas, y algunas en ambas.
apt aprendió a entender proxies pronto. El mecanismo Acquire::Proxy existe desde hace años porque los gestores de paquetes son el rehén favorito de las redes corporativas.
HTTPS volvió los proxies polémicos. El túnel CONNECT está bien; la intercepción TLS es donde chocan los almacenes de confianza y la política. Ahí es donde “funciona en el navegador” diverge de “funciona en apt.”
systemd normalizó el “entorno global de servicios.” Con entornos del gestor y drop-ins, fue fácil hacer que todos los servicios hereden un proxy—aunque los humanos no lo vean.
Las pilas de escritorio añadieron sus propias capas de proxy. Configuraciones de GNOME, gestores de red y configuración por usuario pueden afectar a algunos clientes dejando a otros intactos.
Los contenedores amplificaron el problema. Herramientas de build y CI inyectan proxies en tiempo de construcción, los hornean en imágenes o los dejan en /etc/environment.
no_proxy no está estandarizado. Diferentes clientes lo interpretan distinto: puntos iniciales, CIDR, puertos, literales IPv6—espera sorpresas.
Los fallos de autenticación parecen fallos de red. Un proxy que devuelve 407 puede aparecer como “conexión rechazada” dependiendo del cliente y del nivel de logs.

Una idea parafraseada de Gene Kim (autor sobre fiabilidad/operaciones): Mejora el sistema mejorando cómo lo ves; retroalimentación rápida vence adivinanzas heroicas.
Ese es el espíritu aquí: no adivines dónde vive el proxy. Instruméntalo.

Cómo deciden apt y curl usar un proxy

Si estás depurando, necesitas un modelo mental. No perfecto, solo lo suficientemente exacto para dejar de perder el tiempo.

curl: mayormente impulsado por el entorno, a veces por preferencias de compilación

curl (vía libcurl) suele mirar http_proxy, https_proxy y no_proxy (más variantes en mayúsculas).
Puedes anular con --proxy o desactivar con --noproxy o --proxy ''.
El diagnóstico clave: curl -v te dirá si está “Trying proxy …” o “Connected to … directly.”

apt: archivos de configuración primero, luego entorno solo si lo configuraste

apt tiene su propio sistema de configuración e inclusiones. Los ganchos comunes son:

Acquire::http::Proxy, Acquire::https::Proxy
Acquire::http::Proxy-Auto-Detect scripts (raro, pero peligro real)
Drop-ins bajo /etc/apt/apt.conf.d/

apt no “usa mágicamente la configuración de proxy del escritorio.” Usa la configuración de apt. Pero apt a menudo se ejecuta mediante sudo, y sudo puede preservar variables de entorno según la política.
Ahí obtienes el escenario divertido: tu shell de usuario no tiene variables de proxy, pero sudo apt update sí.

Broma #1: Un proxy es como un gerente intermedio: a veces útil, a menudo inevitable, y cuando está mal configurado lo oirás de inmediato.

Dónde se esconden las configuraciones de proxy en Debian 13

Solo hay tantos escondites. El truco es revisarlos en el orden correcto y en el contexto de ejecución adecuado (shell interactivo vs sudo vs servicio).

1) Variables de entorno (interactivas y no interactivas)

Shell de usuario: ~/.bashrc, ~/.profile, ~/.bash_profile, ~/.zshrc, etc.
A nivel sistema: /etc/environment, /etc/profile, /etc/profile.d/*.sh
sudo: /etc/sudoers y /etc/sudoers.d/* pueden conservar variables de proxy (env_keep).

2) Configuración y drop-ins de apt

/etc/apt/apt.conf
/etc/apt/apt.conf.d/* (este es el culpable habitual)
A veces incluso dentro de definiciones de repositorios si la automatización genera extraños bloques Acquire.

3) Entorno del gestor systemd y drop-ins de unidades

Si la falla ocurre en servicios (timers de apt, unattended-upgrades, actualizadores personalizados), revisa:

systemctl show-environment (entorno del gestor)
Drop-ins bajo /etc/systemd/system/*.d/ y /etc/systemd/system.conf.d/
Archivos de unidad con líneas Environment=

4) Configuración específica de herramientas (wget, git, docker, etc.)

No siempre es apt/curl. A veces apt descarga bien, pero un script postinst usa git y falla. O curl funciona, pero wget no.
Los sistemas Debian acumulan configuraciones de proxy entre herramientas:

~/.wgetrc, /etc/wgetrc
~/.curlrc (menos común, pero existe)
~/.gitconfig, /etc/gitconfig (http.proxy)

5) Intercepción TLS corporativa: el proxy que no puedes quitar

A veces el proxy no está tanto “configurado” como “impuesto.” Puedes quitar las configuraciones de proxy y seguir fallando porque el 443 saliente es interceptado de forma transparente,
lo que significa que la máquina debe confiar en una CA corporativa para validar el certificado del MITM. Ese es otro problema: almacén de confianza, no configuración de proxy.
Pero el síntoma es similar: apt y curl fallan TLS mientras los navegadores parecen bien porque el navegador confía en la CA empresarial vía política.

Tareas prácticas: comandos, salidas y decisiones

A continuación hay tareas probadas en campo que puedes ejecutar en un host Debian 13. Cada una incluye: comando, salida realista, qué significa y qué decisión tomar a continuación.
Ejecútalas en el mismo contexto de ejecución donde ocurre el problema.

Tarea 1: Ver si tu shell actual exporta variables de proxy

cr0x@server:~$ env | grep -i proxy
http_proxy=http://proxy.corp:3128
https_proxy=http://proxy.corp:3128
no_proxy=localhost,127.0.0.1,.corp

Significado: El entorno de tu proceso actual indica a los clientes que usen un proxy. Si pensabas “no hay proxy,” eso era desear demasiado.

Decisión: Encuentra dónde se establecen estas vars (perfil de usuario, /etc/environment, systemd, wrapper de CI). No edites archivos al azar aún—identifica la fuente.

Tarea 2: Comprobar qué hace sudo con las variables de proxy

cr0x@server:~$ sudo env | grep -i proxy
http_proxy=http://proxy.corp:3128
https_proxy=http://proxy.corp:3128
no_proxy=localhost,127.0.0.1,.corp

Significado: sudo está preservando variables de proxy en el entorno root. Esto es común en imágenes corporativas mediante Defaults env_keep.

Decisión: Si necesitas que apt se ejecute sin proxy, debes eliminar las vars en la fuente o ajustar sudoers. Como prueba temporal, usa sudo -H env -u root -i con cuidado, o invalida explícitamente variables para un solo comando.

Tarea 3: Probar explícitamente el comportamiento de proxy de curl

cr0x@server:~$ curl -v https://deb.debian.org/ -o /dev/null
* Uses proxy env variable https_proxy == 'http://proxy.corp:3128'
*   Trying 10.20.30.40:3128...
* Connected to proxy.corp (10.20.30.40) port 3128
> CONNECT deb.debian.org:443 HTTP/1.1
< HTTP/1.1 407 Proxy Authentication Required
curl: (56) CONNECT tunnel failed, response 407

Significado: curl obedece https_proxy, llega al proxy y es rechazado por falta de auth o por política equivocada.

Decisión: O configura credenciales para el proxy (no mi opción favorita) o elimina la configuración del proxy. Si el host no debe usar proxy, céntrate en la limpieza. Si debe, corrige la autenticación y no_proxy.

Tarea 4: Probar conectividad directa evitando variables de proxy

cr0x@server:~$ curl -v --noproxy '*' https://deb.debian.org/ -o /dev/null
* Host deb.debian.org:443 was resolved.
*   Trying 151.101.2.132:443...
* Connected to deb.debian.org (151.101.2.132) port 443
* SSL connection using TLSv1.3
> GET / HTTP/1.1
< HTTP/1.1 200 OK

Significado: La red, DNS y TLS hacia el mirror de Debian funcionan bien cuando se omite la lógica de proxy.

Decisión: Deja de depurar firewalls. Esto es un problema de configuración de proxy, no de conectividad.

Tarea 5: Pregunta a apt qué piensa sobre proxies

cr0x@server:~$ apt-config dump | grep -iE 'Acquire::(http|https).*Proxy'
Acquire::http::Proxy "http://proxy.corp:3128/";
Acquire::https::Proxy "http://proxy.corp:3128/";

Significado: apt está configurado para usar un proxy independientemente del entorno del shell. Incluso si quitas variables de entorno, apt seguirá proxificando.

Decisión: Encuentra el archivo de configuración de apt que proporciona estas directivas y elimínalo/sobrescríbelo.

Tarea 6: Localiza el drop-in de apt que define el proxy

cr0x@server:~$ sudo grep -RIn --color=never 'Acquire::.*Proxy' /etc/apt/apt.conf /etc/apt/apt.conf.d
/etc/apt/apt.conf.d/02proxy:1:Acquire::http::Proxy "http://proxy.corp:3128/";
/etc/apt/apt.conf.d/02proxy:2:Acquire::https::Proxy "http://proxy.corp:3128/";

Significado: Tienes un archivo de proxy explícito para apt.

Decisión: Decide si borrar el archivo (si este host nunca debe usar proxy) o gestionarlo mediante configuración con propiedad clara.

Tarea 7: Comprueba /etc/environment por inyección persistente de proxy

cr0x@server:~$ sudo sed -n '1,200p' /etc/environment
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
http_proxy="http://proxy.corp:3128"
https_proxy="http://proxy.corp:3128"
no_proxy="localhost,127.0.0.1,.corp"

Significado: Cada sesión de login heredará configuraciones de proxy, dependiendo de PAM y del contexto del servicio.

Decisión: Elimina estas líneas si la máquina no debe usar proxy. Si solo algunos servicios deben usarlo, no uses /etc/environment—es un martillo.

Tarea 8: Ver qué contiene el entorno del gestor systemd

cr0x@server:~$ systemctl show-environment | grep -i proxy
http_proxy=http://proxy.corp:3128
https_proxy=http://proxy.corp:3128
no_proxy=localhost,127.0.0.1,.corp

Significado: systemd mantiene variables de proxy a nivel del gestor. Los servicios iniciados por systemd pueden heredarlas aun cuando los shells interactivos no lo hagan.

Decisión: Identifica dónde se establecieron (systemctl set-environment, un drop-in o un script de imagen). Planea anularlas y reiniciar los servicios afectados.

Tarea 9: Busca drop-ins de systemd que inyecten proxy

cr0x@server:~$ sudo grep -RIn --color=never -E 'http_proxy|https_proxy|no_proxy' /etc/systemd
/etc/systemd/system.conf.d/proxy.conf:2:DefaultEnvironment="http_proxy=http://proxy.corp:3128" "https_proxy=http://proxy.corp:3128" "no_proxy=localhost,127.0.0.1,.corp"

Significado: El proxy está establecido globalmente para servicios gestionados por systemd mediante DefaultEnvironment.

Decisión: Elimina ese drop-in si es incorrecto, o aplícalo solo a las unidades que lo necesiten. Los valores por defecto globales son fábrica de deuda técnica.

Tarea 10: Comprueba sudoers por env_keep que preserve proxies

cr0x@server:~$ sudo grep -RIn --color=never 'env_keep.*proxy' /etc/sudoers /etc/sudoers.d
/etc/sudoers.d/proxy:1:Defaults env_keep += "http_proxy https_proxy no_proxy"

Significado: Incluso si limpias variables en tu perfil, alguien puede haberlas preservado deliberadamente vía sudo.

Decisión: Si el host debe estar sin proxy, elimina esto y valida que la automatización (Ansible, cloud-init) no lo esté reintroduciendo.

Tarea 11: Inspecciona la falla real de apt con salida de depuración

cr0x@server:~$ sudo apt -o Debug::Acquire::https=true update
Ign:1 https://deb.debian.org/debian trixie InRelease
Connecting to proxy.corp (10.20.30.40)
Answer for: https://deb.debian.org/debian/dists/trixie/InRelease
HTTP/1.1 407 Proxy Authentication Required
Err:1 https://deb.debian.org/debian trixie InRelease
  407  Proxy Authentication Required [IP: 10.20.30.40 3128]
Reading package lists... Done

Significado: apt está definitivamente usando un proxy, y el proxy lo rechaza. La salida de depuración elimina las dudas.

Decisión: Arregla la autenticación del proxy (si hace falta) o elimina la configuración del proxy. No pierdas tiempo en selección de mirrors o ajustes de IPv6.

Tarea 12: Neutralizar el proxy de apt para una ejecución (diagnóstico seguro)

cr0x@server:~$ sudo apt -o Acquire::http::Proxy="" -o Acquire::https::Proxy="" update
Hit:1 https://deb.debian.org/debian trixie InRelease
Hit:2 https://security.debian.org/debian-security trixie-security InRelease
Reading package lists... Done

Significado: Con los proxies deshabilitados, apt tiene éxito. Ese es tu indicio contundente.

Decisión: Procede con la limpieza permanente: elimina directivas de proxy y variables de entorno, luego verifica.

Tarea 13: Confirma que no hay configuración de proxy residual en wget

cr0x@server:~$ grep -nE 'use_proxy|http_proxy|https_proxy' ~/.wgetrc /etc/wgetrc 2>/dev/null
/etc/wgetrc:16:use_proxy = on
/etc/wgetrc:18:http_proxy = http://proxy.corp:3128/

Significado: wget usará un proxy aunque hayas limpiado apt y las vars de entorno de curl. Las configuraciones específicas de cada herramienta importan.

Decisión: O elimina/desactiva el proxy en la configuración de wget o acepta que wget siga con proxy (pero documenta y sé consistente).

Tarea 14: Validar el almacén de confianza cuando un proxy intercepta TLS

cr0x@server:~$ openssl s_client -connect deb.debian.org:443 -servername deb.debian.org -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Peer certificate: CN = deb.debian.org
Verification: OK

Significado: TLS directo verifica correctamente. Si el mismo comando a través de un proxy da fallos de verificación, estás tratando con intercepción TLS y confianza.

Decisión: No “arregles” esto deshabilitando la verificación. Instala la CA empresarial correcta (si la política requiere intercepción) o evita el proxy interceptador.

Tarea 15: Captura desacoples en no_proxy que fuerzan tráfico interno por el proxy

cr0x@server:~$ env | grep -i no_proxy
no_proxy=localhost,127.0.0.1,.corp,10.0.0.0/8

Significado: Alguien intentó usar CIDR en no_proxy. Muchas herramientas no interpretan CIDR aquí; quieren sufijos de host o IPs literales.

Decisión: Sustituye CIDR por dominios explícitos y las IPs clave que importen, y prueba por herramienta. Asume inconsistencia hasta comprobar lo contrario.

Tarea 16: Confirma qué ve unattended-upgrades (contexto de servicio)

cr0x@server:~$ systemctl cat unattended-upgrades.service
# /lib/systemd/system/unattended-upgrades.service
[Service]
Type=oneshot
ExecStart=/usr/bin/unattended-upgrade

cr0x@server:~$ systemctl show -p Environment unattended-upgrades.service
Environment=http_proxy=http://proxy.corp:3128 https_proxy=http://proxy.corp:3128 no_proxy=localhost,127.0.0.1,.corp

Significado: El propio servicio tiene el entorno de proxy establecido (quizá vía un drop-in).

Decisión: Elimina el entorno a nivel de unidad, o añade una anulación que lo limpie si quieres que unattended-upgrades vaya directo.

Estrategia de limpieza: eliminar, neutralizar y asegurarlo

Limpiar configuraciones de proxy es fácil hacerlo mal. “Borré la línea” es cómo obtienes una semana de fallos intermitentes porque el proxy reaparece por otra capa.
El enfoque correcto es aburrido: identifica las fuentes, elimínalas o delimítalas, y demuestra que el entorno en ejecución está limpio.

Paso 1: Decide la política para este host

Empieza con una pregunta directa: ¿Debe esta máquina usar alguna vez un proxy HTTP(S)?

No: elimina las configuraciones de proxy por todas partes; también quita env_keep en sudo; asegúrate de que el entorno por defecto de systemd no contenga proxy.
Sí, globalmente: centralízalo en un solo lugar (drop-in de apt + DefaultEnvironment de systemd) y documenta; asegúrate de que la autenticación y la confianza CA sean correctas.
Sólo para servicios específicos: nunca pongas en /etc/environment o en defaults globales de systemd; usa drop-ins por unidad.

Paso 2: Limpia apt correctamente

apt es determinista. Eso es buena noticia. Coloca la configuración de proxy en un único archivo explícito si lo necesitas, y borra todo lo demás.

Preferido: un solo archivo como /etc/apt/apt.conf.d/02proxy (gestionado por control de configuración).
Evita: esparcir directivas Acquire en múltiples drop-ins con ordenamiento poco claro.

Si estás eliminando proxies, borra ese archivo (o coméntalo) y verifica con apt-config dump.

Paso 3: Limpiar inyección de entorno

Si quieres un sistema sin proxy, /etc/environment no es tu amigo. Es una palanca global y tiende a sobrevivir a la razón por la que se creó.
Elimina las líneas de proxy allí y en scripts de profile.

Luego aborda sudo. Si env_keep preserva variables de proxy, seguirás reintroduciéndolas en comandos root.

Paso 4: Limpiar el entorno global de systemd

Si systemctl show-environment contiene variables de proxy, arregla la causa raíz:

Elimina entradas DefaultEnvironment de drop-ins de systemd si no están pensadas.
Anula variables del gestor y reinicia servicios relevantes (o reinicia para garantía contundente).

systemd es extremadamente bueno haciendo exactamente lo que se le dijo. Eso incluye obedecer errores para siempre.

Paso 5: Verifica con pruebas que coincidan con tu modo de falla

La verificación debe incluir:

env | grep -i proxy (shell de usuario)
sudo env | grep -i proxy (root vía sudo)
systemctl show-environment | grep -i proxy (gestor de servicios)
apt-config dump | grep -i proxy (vista de apt)
curl -v (comportamiento)

Broma #2: Lo único más persistente que un proxy mal configurado es el ticket que solicita “solo un cambio rápido” justo antes de un festivo.

Tres microhistorias corporativas de la vida real

Microhistoria 1: El incidente causado por una suposición equivocada

Un equipo migró una flota de servidores Debian desde un segmento antiguo de red a uno nuevo. El segmento antiguo requería un proxy de salida.
El nuevo segmento tenía egress directo con reglas de firewall estrictas y ningún proxy. Todos acordaron: “Ya no se necesita proxy.”

Quitaron el proxy del pipeline de CI y dejaron de pasar variables http_proxy en las builds. Las pruebas parecían bien.
Luego, dos semanas después, un despliegue de actualizaciones de seguridad empezó a fallar—pero solo en un subconjunto de hosts. Algunos actualizaron bien, otros se quedaron colgados, y unos pocos llenaron logs con errores 407.

La suposición equivocada: “Si no está en las variables de CI, se fue.” En los hosts que fallaban, el proxy vivía en /etc/apt/apt.conf.d/ desde una imagen golden antigua.
Esas máquinas se habían creado meses antes y nunca reprovisionaron, solo se parchearon. El hostname del proxy aún resolvía, pero el proxy ahora requería autenticación de otro realm.

La solución fue embarazosa y simple: eliminar el drop-in de apt, quitar entradas obsoletas en /etc/environment, y dejar de preservar proxies mediante sudo.
La lección fue el verdadero triunfo: inventariar dónde puede venir la configuración. Las suposiciones no escalan, y Debian está feliz de mantener instrucciones antiguas para siempre.

Microhistoria 2: La “optimización” que salió mal

Otra organización quiso actualizaciones más rápidas. Montaron un proxy caché interno y apuntaron todo el tráfico apt a él.
Parecía una optimización limpia: menos ancho de banda, instalaciones más rápidas, menos timeouts por enlaces WAN.

El primer mes fue estupendo. Luego hubo una ventana de mantenimiento. El proxy volvió con una nueva política de intercepción TLS y una CA empresarial rotada.
Los navegadores actualizaron la confianza automáticamente vía gestión de dispositivos. Los servidores no.

De pronto apt empezó a fallar con errores de verificación de certificado. Alguien “arregló” poniendo apt para ignorar la verificación TLS temporalmente.
Esa “ventana corta” duró más de lo previsto, porque los fallos cesaron y la gente siguió con su trabajo. El proxy siguió siendo un punto único de falla, además de una dependencia silenciosa del ancla de confianza.

Cuando una auditoría preguntó cómo se aseguraba la integridad de paquetes, la respuesta fue mucha aclaración de garganta y una carrera por volver a habilitar la verificación y desplegar las actualizaciones de CA correctamente.
La optimización no estaba mal. La madurez operacional alrededor de ella sí.

La solución durable: eliminar la intercepción TLS para el tráfico de mirrors de Debian cuando sea posible, o gestionar la distribución de la CA como una dependencia de primera clase.
Y para rendimiento, usa mirrors locales o capas de caché apt que no requieran MITM.

Microhistoria 3: La práctica aburrida que salvó el día

Un equipo de plataforma tenía una práctica tediosa: cada imagen horneada para producción tenía un archivo “contrato de red” verificado por CI.
Indicaba si el host debía usar proxy y, de ser así, exactamente dónde estaba configurado (drop-in de apt, overrides de unidades systemd y un bundle de CA gestionado).

Durante una migración de datacenter, un lote de VMs Debian 13 de pronto no pudo instalar paquetes en una VLAN de staging aislada.
La respuesta a incidentes parecía dramática desde fuera—alertas, despliegues fallidos, cortes en la migración—pero internamente fue procedimental.

Ejecutaron tres comandos: apt-config dump para directivas de proxy, systemctl show-environment para variables heredadas, y curl -v --noproxy '*' para validar egress directo.
En minutos demostraron que la VLAN bloqueaba el acceso directo a Internet, y que la subnet de staging necesitaba proxy por diseño.

Aquí lo que salvó el día: sus configuraciones de proxy no estaban dispersas.
Un solo drop-in de apt y un solo drop-in de systemd podían habilitarse para ese entorno vía gestión de configuración.
Sin ediciones manuales, sin adivinanzas, sin “funciona en mi shell.” La migración se completó con traza documental limpia.

Errores comunes: síntoma → causa raíz → solución

Estos son los patrones que veo más a menudo en parques Debian. La mejor parte es que son predecibles.

1) apt falla con 407, curl falla con 407

Síntoma: Proxy Authentication Required en apt y curl.

Causa raíz: El proxy está configurado (env o apt), pero faltan credenciales/son inválidas, o la política del proxy cambió.

Solución: Si no debe usarse proxy, elimínalo de configs de apt y de las fuentes de entorno. Si debe, usa un método de proxy autenticado apropiado para tu organización y prueba con curl -v.

2) curl funciona, apt falla (o viceversa)

Síntoma: Una herramienta funciona, la otra se agota o usa proxy.

Causa raíz: Fuentes de configuración distintas: apt usa /etc/apt/apt.conf.d; curl usa vars de entorno o ~/.curlrc.

Solución: Compara apt-config dump y env | grep -i proxy. Arregla la capa que corresponde a la herramienta que falla.

3) “Quité el proxy, pero los servicios aún lo usan”

Síntoma: Las pruebas interactivas tienen éxito; unattended-upgrades o un demonio aún toca el proxy.

Causa raíz: El entorno del gestor systemd o drop-ins de unidad aún definen variables de proxy.

Solución: Revisa systemctl show-environment y systemctl show -p Environment <unit>. Elimina/anula y reinicia el servicio (o reinicia para certeza).

4) apt falla con errores TLS solo cuando hay proxy

Síntoma: certificate verify failed, a veces tras un cambio de proxy.

Causa raíz: La intercepción TLS requiere una CA empresarial que no está instalada en el almacén de confianza del sistema.

Solución: Instala la CA empresarial en el almacén de Debian usando el método estándar y verifica con openssl s_client. No desactives la verificación en apt como “parche temporal.”

5) no_proxy “no hace nada” para dominios internos

Síntoma: Endpoints internos siguen yendo por proxy, causando latencia o fallos de autenticación.

Causa raíz: Formato de no_proxy incompatible (CIDR no soportado, comportamiento del punto inicial distinto, puertos ignorados).

Solución: Usa sufijos de dominio y hostnames explícitos. Valida por cliente con curl -v y la URL exacta usada por el proceso que falla.

6) Todo funciona como usuario, falla con sudo

Síntoma: curl funciona; sudo curl usa proxy y falla.

Causa raíz: sudoers preserva variables de proxy (env_keep) o los perfiles del shell root difieren.

Solución: Audita /etc/sudoers.d y los archivos de inicio del shell root. Evita preservar globalmente variables de proxy a menos que haya una razón de política.

Listas de verificación / plan paso a paso

Lista A: Triaje de proxy de 10 minutos (interactivo)

Ejecuta env | grep -i proxy. Si aparece, identifica la fuente (perfiles de usuario/sistema).
Ejecuta sudo env | grep -i proxy. Si difiere del usuario, revisa sudoers env_keep.
Ejecuta apt-config dump | grep -i proxy. Si aparece, encuentra el archivo en /etc/apt/apt.conf.d.
Ejecuta curl -v https://deb.debian.org/ -o /dev/null para ver si usa proxy.
Ejecuta curl -v --noproxy '*' https://deb.debian.org/ -o /dev/null para demostrar que la ruta directa funciona.
Si fallan servicios, ejecuta systemctl show-environment | grep -i proxy.

Lista B: Plan de eliminación de proxy (host debe ser directo)

Elimina o comenta directivas de proxy de apt en el archivo identificado en /etc/apt/apt.conf.d/.
Elimina líneas de proxy de /etc/environment y de cualquier script en /etc/profile.d que las establezca.
Elimina reglas de sudoers que preserven variables de proxy a menos que sean necesarias.
Elimina ajustes DefaultEnvironment de systemd o limítalos a unidades específicas.
Reinicia servicios afectados; para cambios amplios, programa un reinicio.
Vuelve a verificar con las cinco salidas: env de usuario, env de sudo, entorno systemd, apt-config dump y comportamiento de curl -v.

Lista C: El proxy debe existir, pero hazlo sensato

Elige un mecanismo de configuración autoritativo por ámbito:
- Para apt: un archivo gestionado en /etc/apt/apt.conf.d/.
- Para servicios: drop-ins por unidad con Environment= (no defaults globales salvo que sea realmente global).
Define no_proxy cuidadosamente: incluye endpoints de metadata, planos de control del clúster, registros internos y localhost.
Si hay intercepción TLS, gestiona la distribución de la CA empresarial y verifica en hosts (no confíes en navegadores).
Documenta la propiedad: quién cambia host/puerto/auth del proxy y cómo se despliegan los cambios de forma segura.

Preguntas frecuentes

1) ¿Por qué `apt update` usa un proxy cuando mi shell no muestra `http_proxy`?

Porque apt puede configurarse de forma independiente vía /etc/apt/apt.conf y /etc/apt/apt.conf.d/*.
Compruébalo con apt-config dump | grep -i proxy.

2) ¿Por qué `sudo apt update` se comporta distinto de `apt update`?

sudo puede preservar variables de proxy (env_keep), y root puede tener archivos de inicio o entorno distintos.
Compara env | grep -i proxy vs sudo env | grep -i proxy.

3) ¿Dónde está el “lugar principal” donde Debian guarda las configuraciones de proxy?

No hay uno. Para apt son los archivos de configuración de apt; para muchas herramientas CLI son variables de entorno; para servicios son entornos de systemd o overrides de unidad.
Por eso limpiar proxies es una búsqueda a menos que estandarices.

4) ¿Puedo simplemente poner `Acquire::https::Proxy "false";`?

Puedes deshabilitar proxies estableciendo cadenas vacías para las opciones de proxy, o eliminando las directivas. Para una ejecución puntual, usa:
apt -o Acquire::https::Proxy="" -o Acquire::http::Proxy="" update.
Para comportamiento permanente, elimina el archivo fuente o gestiona explícitamente la configuración.

5) ¿Por qué `no_proxy` no funciona para rangos CIDR?

Porque el soporte varía por cliente, y muchos no parsean CIDR en no_proxy. Prefiere dominios explícitos y hostnames.
Prueba con el cliente y la URL exacta; no asumas portabilidad.

6) Quité proxies, pero unattended-upgrades sigue fallando. ¿Por qué?

Unattended-upgrades corre como servicio. systemd puede seguir proveyendo variables de proxy mediante el entorno del gestor o drop-ins de unidad.
Revisa systemctl show-environment y systemctl show -p Environment unattended-upgrades.service.

7) apt falla con errores de certificado solo en redes corporativas. ¿Es eso un problema de proxy?

A menudo es intercepción TLS. El “proxy” hace MITM y presenta certificados firmados por una CA empresarial que no está en el almacén de Debian.
Arregla instalando correctamente la CA empresarial, o evitando la intercepción para mirrors de Debian si la política lo permite.

8) ¿Cuál es la forma más segura de probar que el proxy es el problema sin cambiar la configuración?

Para curl: ejecuta curl -v --noproxy '*' y compara comportamientos.
Para apt: ejecuta apt -o Acquire::http::Proxy="" -o Acquire::https::Proxy="" update.
Si eso funciona, aislaste al culpable.

9) ¿Debería almacenar credenciales del proxy en archivos de configuración de apt?

Evítalo si puedes. Las credenciales quedan legibles en más sitios de los que imaginas (backups, logs, bundles de soporte).
Si la organización requiere proxies autenticados, usa el mecanismo aprobado de distribución de secretos y minimiza dónde residen.

10) ¿Cómo evito que las configuraciones de proxy vuelvan?

Encuentra al escritor: cloud-init, gestión de configuración, scripts de bake de imágenes o herramientas de cumplimiento. Elimina la fuente de verdad ahí.
Si solo “arreglas el servidor,” la siguiente ejecución lo reintroducirá.

Conclusión: pasos prácticos siguientes

Los problemas de proxy parecen problemas de red porque el modo de fallo es “no puede alcanzar Internet.” Por lo general son problemas de configuración porque el sistema está obedeciendo instrucciones ocultas.
Debian 13 te da un conjunto claro de palancas—configuración de apt, entorno, systemd—pero también suficiente cuerda para complicarlo.

Pasos siguientes que realmente funcionan en producción:

Ejecuta los comandos de diagnóstico rápido y decide si el host debe usar proxy.
Haz que la configuración de proxy sea de una sola fuente y con alcance: un drop-in de apt, entorno systemd por unidad, no /etc/environment global salvo necesidad real.
Quita env_keep de sudo para proxies en hosts que deben ser directos.
Prueba la corrección con salidas, no con buenas sensaciones: apt-config dump, systemctl show-environment y curl -v sin y con bypass de proxy.