Debian 13 : les paramètres de proxy cassent apt/curl — où ils se cachent et comment les nettoyer

octobre 9, 2025 • février 3, 2026 • Lecture : 27 min • Views: 6

Cet article vous a aidé ?

Le symptôme est toujours le même : apt update se bloque, curl renvoie un 407 déroutant et la machine jure n’avoir « aucun proxy configuré ».
Puis vous découvrez que le proxy est configuré à cinq endroits, la moitié d’entre eux invisibles pour la personne qui tient le pager.

Debian 13 ne « casse » pas le réseau. Il suit simplement les instructions — certaines laissées par un script de bootstrap disparu, une image d’entreprise,
ou ce moment où quelqu’un a exporté http_proxy dans un profil de shell et oublié que ça existait. Traquons les paramètres de proxy, supprimons-les proprement
et prouvons que le système est réellement sans proxy.

Playbook de diagnostic rapide

Quand apt/curl échouent et que vous voulez le chemin le plus rapide vers la vérité, ne commencez pas par lire tous les fichiers de configuration de la planète.
Commencez par observer le comportement et demandez-vous : « Est-ce une décision de proxy, un problème DNS ou un problème TLS/chemin ? »

1) Vérifier si un proxy est utilisé (environnement + vue apt)

Exécutez env | grep -i proxy dans le même contexte que la commande qui échoue (votre shell, shell root, via sudo).
Exécutez apt-config dump | grep -i proxy pour voir ce qu’apt pense être configuré.

Si l’un ou l’autre affiche un proxy inattendu, vous avez déjà trouvé le goulot d’étranglement : de la configuration, pas du « réseau ».

2) Confirmer le routage et le DNS de base sans impliquer les proxies

Vérifier DNS : getent ahosts deb.debian.org
Vérifier l’accès HTTPS direct : curl -v --noproxy '*' https://deb.debian.org/

Si le direct fonctionne mais qu’apt échoue, c’est presque toujours la configuration d’apt ou une différence de politique d’interception TLS.

3) Réduire la recherche : quelle couche injecte le proxy ?

Si curl utilise un proxy de façon inattendue, ce sont généralement des variables d’environnement ou une config libcurl.
Si seul apt utilise un proxy, c’est généralement /etc/apt/apt.conf* ou un drop-in inclus.
Si des services (pas des shells interactifs) utilisent un proxy, soupçonnez les drop-ins d’environnement du gestionnaire systemd.

4) Prouvez la correction

Après les changements, relancez apt-config dump, systemctl show-environment et un test curl -v.
Ne vous fiez pas à « J’ai supprimé la ligne. » Fiez-vous aux sorties.

Faits et contexte : pourquoi les proxies fantômes sont fréquents

Un peu d’histoire aide à expliquer pourquoi les paramètres de proxy sont si glissants sur Linux, et pourquoi Debian 13 n’est pas spécial ici — juste assez moderne pour vous offrir plus d’endroits où se cacher.
Voici des faits concrets qui ressortent dans les environnements :

Les variables d’environnement proxy précèdent les outils d’aujourd’hui. http_proxy et consorts sont devenus une norme de fait car il était facile de les exporter et de les scripturer.
La casse compte, jusqu’à un certain point. Beaucoup d’outils vérifient d’abord les variables en minuscules (http_proxy), certains vérifient les majuscules, et d’autres les deux.
apt a appris à gérer les proxies tôt. Le mécanisme Acquire::Proxy existe depuis des années car les gestionnaires de paquets sont la cible favorite des politiques réseau d’entreprise.
HTTPS a rendu les proxies politiques. Le tunnel CONNECT est acceptable ; l’interception TLS est là où les magasins de confiance et les politiques entrent en collision. C’est là que « fonctionne dans le navigateur » diverge de « fonctionne dans apt ».
systemd a normalisé l’« environnement global des services ». Avec les environnements du gestionnaire et les drop-ins, il est devenu facile de faire hériter un proxy à tous les services — même quand les humains ne le voient pas.
Les environnements de bureau ont ajouté leurs propres couches de proxy. Les réglages GNOME, les gestionnaires de réseau et la configuration par utilisateur peuvent affecter certains clients tout en en laissant d’autres intacts.
Les conteneurs ont amplifié le problème. Les outils de build et les CI injectent souvent des proxies au moment du build, en les gravant dans les images ou en les laissant dans /etc/environment.
no_proxy n’est pas standardisé. Les clients l’interprètent différemment : points initiaux, CIDR, ports, littéraux IPv6 — attendez-vous à des surprises.
Les échecs d’authentification ressemblent à des échecs réseau. Un proxy renvoyant 407 peut apparaître comme « connexion refusée » selon le client et le niveau de logs.

Une idée paraphrasée de Gene Kim (auteur fiabilité/ops) : Améliorez le système en améliorant la visibilité ; un retour d’information rapide bat la conjecture héroïque.
C’est l’esprit ici : ne devinez pas où habite le proxy. Instrumentez-le.

Comment apt et curl décident d’utiliser un proxy

Si vous dépannez, vous avez besoin d’un modèle mental. Pas parfait — juste assez précis pour arrêter de perdre du temps.

curl : principalement guidé par l’environnement, parfois par des préférences compilées

curl (via libcurl) regardera typiquement http_proxy, https_proxy et no_proxy (plus les variantes en majuscules).
Vous pouvez remplacer avec --proxy ou désactiver avec --noproxy ou --proxy ''.
Le diagnostic clé : curl -v vous dit s’il « Trying proxy … » ou « Connected to … directly. »

apt : fichiers de configuration en premier, puis l’environnement seulement si vous l’avez configuré

apt a son propre système de configuration et ses inclusions. Les crochets courants sont :

Acquire::http::Proxy, Acquire::https::Proxy
Acquire::http::Proxy-Auto-Detect scripts (rare, mais piège réel)
Drop-ins sous /etc/apt/apt.conf.d/

apt n’« utilise pas magiquement les réglages de proxy du bureau. » Il utilise la config d’apt. Mais apt est souvent lancé via sudo, et sudo peut préserver les variables d’environnement selon la politique.
C’est là que vous obtenez le scénario amusant : votre shell utilisateur n’a pas de variables proxy, mais sudo apt update en a.

Blague #1 : Un proxy, c’est comme un manager intermédiaire : parfois utile, souvent inévitable, et quand il est mal configuré vous l’entendrez tout de suite.

Où se cachent les paramètres de proxy sur Debian 13

Il n’y a qu’un nombre limité de cachettes. L’astuce est de les vérifier dans le bon ordre et dans le bon contexte d’exécution (shell interactif vs sudo vs service).

1) Variables d’environnement (interactives et non interactives)

Shell utilisateur : ~/.bashrc, ~/.profile, ~/.bash_profile, ~/.zshrc, etc.
Au niveau système : /etc/environment, /etc/profile, /etc/profile.d/*.sh
sudo : /etc/sudoers et /etc/sudoers.d/* peuvent conserver les variables proxy (env_keep).

2) Configuration apt et drop-ins

/etc/apt/apt.conf
/etc/apt/apt.conf.d/* (c’est le coupable habituel)
Parfois même dans les définitions de dépôts si l’automatisation génère des strophes Acquire étranges.

3) Environnement du gestionnaire systemd et drop-ins d’unité

Si l’échec survient dans des services (timers apt, unattended-upgrades, updaters personnalisés), vérifiez :

systemctl show-environment (environnement du gestionnaire)
Drop-ins sous /etc/systemd/system/*.d/ et /etc/systemd/system.conf.d/
Fichiers d’unité avec des lignes Environment=

4) Configuration spécifique aux outils (wget, git, docker, etc.)

Ce n’est pas toujours apt/curl. Parfois apt télécharge bien, mais un script postinst utilise git et échoue. Ou curl va bien, mais wget non.
Les systèmes Debian accumulent des paramètres proxy pour différents outils :

~/.wgetrc, /etc/wgetrc
~/.curlrc (moins courant, mais existe)
~/.gitconfig, /etc/gitconfig (http.proxy)

5) Interception TLS d’entreprise : le proxy qu’on ne peut pas enlever

Parfois le proxy n’est pas tant « configuré » que « imposé ». Vous pouvez supprimer les réglages de proxy et continuer d’échouer parce que le port 443 sortant est intercepté de façon transparente,
ce qui signifie que la machine doit approuver une CA d’entreprise pour valider le certificat MITM. C’est un problème différent : magasin de confiance, pas configuration de proxy.
Mais le symptôme est similaire : apt et curl échouent en TLS tandis que les navigateurs semblent fonctionner parce qu’ils font confiance à la CA d’entreprise via une politique.

Tâches pratiques : commandes, sorties et décisions

Ci‑dessous se trouvent des tâches éprouvées que vous pouvez exécuter sur un hôte Debian 13. Chacune inclut : commande, sortie réaliste, ce que cela signifie et la décision à prendre ensuite.
Exécutez-les dans le même contexte d’exécution où le problème se produit.

Task 1: See whether your current shell exports proxy variables

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

Signification : Votre environnement de processus actuel indique aux clients d’utiliser un proxy. Si vous pensiez « il n’y a pas de proxy », c’était de l’optimisme.

Décision : Trouvez où ces variables sont définies (profil utilisateur, /etc/environment, systemd, wrapper CI). Ne modifiez pas des fichiers au hasard — identifiez la source.

Task 2: Check what sudo does to proxy variables

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

Signification : sudo préserve les variables proxy dans l’environnement root. C’est courant dans les images d’entreprise via Defaults env_keep.

Décision : Si vous avez besoin qu’apt s’exécute sans proxy, vous devez soit supprimer les variables à la source, soit ajuster sudoers. Comme test temporaire, utilisez prudemment sudo -H env -u root -i, ou déclarez explicitement unset pour une seule commande.

Task 3: Test curl’s proxy behavior explicitly

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

Signification : curl obéit à https_proxy, atteint le proxy et se fait refuser à cause d’un manque d’authentification ou d’une politique erronée.

Décision : Soit configurez correctement les informations d’authentification du proxy (ce que je préfère éviter), soit supprimez la configuration du proxy. Si l’hôte ne doit pas utiliser de proxy, concentrez-vous sur le nettoyage. Si oui, corrigez l’auth et le no_proxy.

Task 4: Prove direct connectivity by bypassing proxy variables

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

Signification : Le réseau, le DNS et le TLS vers le mirror Debian fonctionnent bien lorsqu’on bypasse la logique proxy.

Décision : Arrêtez de déboguer les pare-feu. C’est un problème de configuration de proxy, pas de connectivité.

Task 5: Ask apt what it thinks about 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/";

Signification : apt est configuré pour utiliser un proxy indépendamment de l’environnement du shell. Même si vous unsettez les vars, apt proxifiera encore.

Décision : Trouvez le fichier de configuration apt fournissant ces directives et supprimez-le/overrides-le.

Task 6: Locate the apt drop-in that defines the 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/";

Signification : Vous avez un fichier proxy explicite pour apt.

Décision : Décidez de supprimer le fichier (si cet hôte ne doit jamais proxy) ou de le gérer via la configuration centralisée avec une propriété claire.

Task 7: Check /etc/environment for persistent proxy injection

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"

Signification : Chaque session de connexion héritera des paramètres proxy, selon PAM et le contexte de service.

Décision : Supprimez ces lignes si la machine ne doit pas proxyer. Si seuls certains services doivent utiliser un proxy, n’utilisez pas /etc/environment — c’est une massue.

Task 8: See what systemd manager environment contains

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

Signification : systemd conserve des variables proxy au niveau du gestionnaire. Les services lancés par systemd peuvent les hériter même si les shells interactifs ne les ont pas.

Décision : Identifiez où elles ont été définies (systemctl set-environment, un drop-in, ou un script d’image). Prévoyez de les unsetter et de redémarrer les services concernés.

Task 9: Search for systemd drop-ins that inject proxy settings

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"

Signification : Le proxy est défini globalement pour les services gérés par systemd via DefaultEnvironment.

Décision : Supprimez ce drop-in s’il est incorrect, ou limitez-le aux unités qui en ont besoin. Les defaults globaux créent une dette opérationnelle.

Task 10: Check sudoers for env_keep that preserves 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"

Signification : Même si vous nettoyez les variables dans votre profil, quelqu’un peut les avoir délibérément préservées via sudo.

Décision : Si l’hôte doit être sans proxy, supprimez ceci et validez que l’automatisation (Ansible, cloud-init) ne le réintroduit pas.

Task 11: Inspect apt’s actual failure with debug output

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

Signification : apt utilise définitivement un proxy, et le proxy le rejette. La sortie debug enlève tout doute.

Décision : Corrigez l’auth proxy (si nécessaire) ou supprimez la config proxy. Ne perdez pas de temps sur le choix de mirror ou les bascules IPv6.

Task 12: Neutralize apt proxy for a single run (safe diagnostic)

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

Signification : Avec les proxies désactivés, apt réussit. C’est votre preuve irréfutable.

Décision : Poursuivre avec un nettoyage permanent : retirez les directives proxy et les variables d’environnement, puis vérifiez.

Task 13: Confirm no stray wget proxy config

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/

Signification : wget utilisera un proxy même si vous avez nettoyé apt et les vars curl. Les configs spécifiques aux outils comptent.

Décision : Supprimez/désactivez le proxy dans la config wget ou acceptez que wget reste proxifié (mais alors soyez cohérent et documentez-le).

Task 14: Validate trust store when a proxy intercepts 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

Signification : Le TLS direct se vérifie correctement. Si la même commande via un proxy donne des échecs de vérification, vous êtes en présence d’une interception TLS nécessitant confiance.

Décision : Ne « corrigez » pas cela en désactivant la vérification. Installez la CA d’entreprise correcte (si la politique l’exige) ou évitez l’interception du trafic vers les mirrors Debian.

Task 15: Catch no_proxy mismatches that force internal traffic through proxy

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

Signification : Quelqu’un a tenté d’utiliser un CIDR dans no_proxy. Beaucoup d’outils n’interprètent pas les CIDR ici ; ils veulent des suffixes de domaine ou des IP littérales.

Décision : Remplacez le CIDR par des domaines explicites et les IP clés qui comptent, et testez par outil. Assumez l’incohérence jusqu’à preuve du contraire.

Task 16: Confirm what unattended-upgrades sees (service context)

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

Signification : Le service lui‑même a l’environnement proxy défini (peut‑être via un drop-in).

Décision : Supprimez l’environnement au niveau de l’unité, ou ajoutez un override qui le vide si vous voulez que les unattended-upgrades utilisent la connexion directe.

Stratégie de nettoyage : supprimer, neutraliser, et verrouiller

Nettoyer les paramètres de proxy est facile à faire de travers. « J’ai supprimé la ligne » est la façon d’avoir une semaine d’échecs intermittents parce que le proxy réapparaît via une autre couche.
La bonne approche est ennuyeuse : identifiez les sources, supprimez‑les ou scopez‑les, puis prouvez que l’environnement d’exécution est propre.

Step 1: Decide the policy for this host

Commencez par une question franche : Cette machine doit‑elle jamais utiliser un proxy HTTP(S) ?

Non : supprimez les paramètres proxy partout ; retirez aussi l’env_keep sudo ; assurez-vous que l’environnement par défaut systemd ne contient pas de proxy.
Oui, globalement : centralisez‑le en un seul endroit (drop-in apt + DefaultEnvironment systemd) et documentez ; assurez‑vous que l’auth et la confiance CA sont correctes.
Seulement pour certains services : ne mettez jamais de /etc/environment ou de defaults systemd globaux ; utilisez des drop‑ins unitaires.

Step 2: Clean apt the right way

apt est déterministe. C’est une bonne nouvelle. Mettez la configuration proxy dans un seul fichier explicite si vous devez en avoir un, et supprimez tout le reste.

Préféré : un fichier unique comme /etc/apt/apt.conf.d/02proxy (géré par la gestion de configuration).
À éviter : répandre des directives Acquire dans plusieurs drop-ins avec un ordre flou.

Si vous supprimez les proxies, enlevez ce fichier (ou commentez‑le) et vérifiez avec apt-config dump.

Step 3: Clean environment injection

Si vous voulez un système sans proxy, /etc/environment n’est pas votre ami. C’est un levier global qui a tendance à survivre à la raison de sa création.
Supprimez les lignes proxy là‑bas et dans les scripts de profile.

Ensuite, adressez sudo. Si env_keep préserve les variables proxy, vous continuerez à les réintroduire dans les commandes root.

Step 4: Clean systemd’s global environment

Si systemctl show-environment contient des variables proxy, corrigez la cause racine :

Retirez les entrées DefaultEnvironment des drop-ins systemd si elles ne sont pas intentionnelles.
Unsettez les variables d’environnement du gestionnaire et redémarrez les services concernés (ou redémarrez pour la garantie la plus simple).

Systemd est extrêmement bon pour faire exactement ce qu’on lui dit. Cela inclut obéir aux erreurs pour toujours.

Step 5: Verify with tests that match your failure mode

La vérification devrait inclure :

env | grep -i proxy (shell utilisateur)
sudo env | grep -i proxy (root via sudo)
systemctl show-environment | grep -i proxy (gestionnaire de services)
apt-config dump | grep -i proxy (vue apt)
curl -v (comportement)

Blague #2 : La seule chose plus persistante qu’un proxy mal configuré est le ticket demandant « juste un petit changement » juste avant un jour férié.

Trois mini-récits d’entreprise tirés de la vraie vie

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une équipe a migré une flotte de serveurs Debian depuis un ancien segment réseau vers un nouveau. L’ancien segment exigeait un proxy sortant.
Le nouveau segment avait un egress direct avec des règles de pare‑feu strictes et aucun proxy. Tout le monde était d’accord : « Pas de proxy nécessaire désormais. »

Ils ont retiré le proxy de leur pipeline CI et ont cessé de passer les variables http_proxy dans les builds. Les tests semblaient corrects.
Puis, deux semaines plus tard, un déploiement de mise à jour de sécurité a commencé à échouer — mais seulement sur un sous‑ensemble d’hôtes. Certains se mettaient à jour correctement, d’autres restaient bloqués, et quelques‑uns remplissaient les logs de 407.

La mauvaise hypothèse : « Si ce n’est pas dans les variables CI, c’est disparu. » Sur les hôtes en échec, le proxy vivait dans /etc/apt/apt.conf.d/ provenant d’une ancienne image golden.
Ces machines avaient été créées des mois plus tôt et jamais reprovisionnées, seulement patchées in situ. Le nom du proxy se résolvait encore, mais le proxy exigeait maintenant une authentification d’un autre domaine.

La correction fut embarrassante de simplicité : supprimer le drop-in apt proxy, enlever les entrées obsolètes dans /etc/environment et arrêter de préserver les proxies via sudo.
La vraie victoire fut la leçon : inventoriez les endroits d’où la configuration peut venir. Les hypothèses ne s’échelonnent pas, et Debian garde volontiers d’anciennes instructions pour toujours.

Mini-récit 2 : L’« optimisation » qui s’est retournée contre eux

Une autre organisation voulait des mises à jour plus rapides. Ils ont mis en place un proxy cache interne et dirigé tout le trafic apt vers lui.
Ça ressemblait à une optimisation propre : moins de bande passante, installations plus rapides, moins de timeouts sur les liaisons WAN.

Le premier mois était excellent. Puis une fenêtre de maintenance du proxy est survenue. Le proxy est revenu avec une nouvelle politique d’interception TLS et une CA d’entreprise tournée.
Les navigateurs ont mis à jour la confiance automatiquement via la gestion des appareils. Les serveurs, non.

Soudain apt a commencé à échouer avec des erreurs de vérification de certificat. Quelqu’un a « réparé » cela en demandant à apt d’ignorer la vérification TLS pour une courte période.
Cette « courte période » a duré plus longtemps que prévu, parce que les échecs ont cessé et les gens ont continué leur travail. Le proxy est resté un point unique de défaillance, plus une dépendance silencieuse de l’ancre de confiance.

Lors d’un audit sur l’intégrité des paquets, la réponse fut beaucoup d’hésitations et une course pour réactiver la vérification et déployer correctement les CA.
L’optimisation n’était pas fausse. La maturité opérationnelle autour l’était.

La correction durable : éliminer l’interception TLS pour le trafic des mirrors Debian quand c’est possible, ou gérer la distribution des CA comme une dépendance de première classe.
Et pour la performance, utiliser des mirrors locaux ou des caches apt qui n’exigent pas de MITM.

Mini-récit 3 : La pratique ennuyeuse qui a sauvé la mise

Une équipe plateforme avait une habitude qui paraissait fastidieuse : chaque image déployée en production avait un fichier « contrat réseau » vérifié par la CI.
Il indiquait si l’hôte devait utiliser un proxy, et si oui, exactement où il était configuré (drop-in apt, overrides unitaires systemd, et un bundle CA géré).

Lors d’une migration de datacenter, un lot de VM Debian 13 n’a soudainement plus pu installer de paquets dans un VLAN de staging isolé.
La réponse incident a paru dramatique de l’extérieur — alertes, déploiements échoués, bascule retardée — mais en interne c’était procédural.

Ils ont exécuté trois commandes : apt-config dump pour les directives proxy, systemctl show-environment pour les variables héritées, et curl -v --noproxy '*' pour valider l’egress direct.
En quelques minutes ils ont prouvé que le VLAN bloquait l’internet direct, et que le subnet de staging nécessitait un proxy par conception.

La partie salvatrice : leurs réglages proxy n’étaient pas éparpillés.
Un seul drop-in apt et un seul drop-in systemd pouvaient être activés pour cet environnement via la gestion de configuration.
Pas d’éditions manuelles, pas de devinettes, pas de « ça marche dans mon shell ». La migration s’est terminée avec une traçabilité propre.

Erreurs courantes : symptôme → cause racine → correctif

Voici les schémas que je vois le plus souvent sur des parcs Debian. La meilleure partie : ils sont prévisibles.

1) apt échoue avec 407, curl échoue avec 407

Symptôme : Proxy Authentication Required dans apt et curl.

Cause racine : Le proxy est configuré (env ou apt), mais les identifiants sont manquants/invalides, ou la politique du proxy a changé.

Correctif : Si le proxy ne doit pas être utilisé, retirez‑le des configs apt et des sources d’environnement. S’il doit être utilisé, employez une méthode d’authentification du proxy conforme à votre organisation et testez avec curl -v.

2) curl fonctionne, apt échoue (ou vice versa)

Symptôme : Un outil fonctionne, l’autre se met en timeout ou proxy.

Cause racine : Sources de configuration différentes : apt utilise /etc/apt/apt.conf.d ; curl utilise des vars d’env ou ~/.curlrc.

Correctif : Comparez apt-config dump et env | grep -i proxy. Corrigez la couche correspondant à l’outil en échec.

3) « J’ai supprimé le proxy, mais les services l’utilisent encore »

Symptôme : Les tests interactifs réussissent ; unattended-upgrades ou un daemon tape toujours sur le proxy.

Cause racine : L’environnement du gestionnaire systemd ou des drop-ins d’unité définissent encore des variables proxy.

Correctif : Vérifiez systemctl show-environment et systemctl show -p Environment <unit>. Supprimez/overridez, puis redémarrez le service (ou redémarrez pour certitude).

4) apt échoue avec des erreurs TLS seulement quand le proxy est impliqué

Symptôme : certificate verify failed, parfois après un changement de proxy.

Cause racine : L’interception TLS nécessite une CA d’entreprise qui n’est pas installée dans le magasin de confiance système.

Correctif : Installez la CA d’entreprise dans le magasin de confiance Debian via la méthode standard et vérifiez avec openssl s_client. Ne désactivez pas la vérification dans apt comme « solution temporaire ».

5) no_proxy « ne sert à rien » pour des domaines internes

Symptôme : Les endpoints internes passent toujours par le proxy, causant latence ou échecs d’auth.

Cause racine : Format no_proxy incompatible (CIDR non supporté, comportement du point initial différent, ports ignorés).

Correctif : Utilisez des suffixes de domaine et des hostnames explicites. Validez par client avec curl -v et l’URL exacte utilisée par le processus défaillant.

6) Tout fonctionne en utilisateur, échoue sous sudo

Symptôme : curl réussit ; sudo curl utilise un proxy et échoue.

Cause racine : sudoers préserve les variables proxy (env_keep) ou les profils shell root diffèrent.

Correctif : Auditez /etc/sudoers.d et les fichiers de démarrage du shell root. Préférez ne pas préserver globalement les variables proxy sauf motif politique.

Listes de contrôle / plan étape par étape

Checklist A: 10-minute proxy triage (interactive)

Exécutez env | grep -i proxy. Si présent, identifiez la source (profils utilisateur/système).
Exécutez sudo env | grep -i proxy. Si différent de l’utilisateur, vérifiez sudoers env_keep.
Exécutez apt-config dump | grep -i proxy. Si présent, trouvez le fichier dans /etc/apt/apt.conf.d.
Exécutez curl -v https://deb.debian.org/ -o /dev/null pour voir s’il utilise un proxy.
Exécutez curl -v --noproxy '*' https://deb.debian.org/ -o /dev/null pour prouver que le chemin direct fonctionne.
Si les services échouent, exécutez systemctl show-environment | grep -i proxy.

Checklist B: Proxy removal plan (host should be direct)

Supprimez ou commentez les directives proxy apt dans le fichier identifié sous /etc/apt/apt.conf.d/.
Retirez les lignes proxy de /etc/environment et de tout script /etc/profile.d qui les définit.
Retirez les règles sudoers préservant les variables proxy sauf si explicitement requis.
Retirez les DefaultEnvironment proxy systemd (ou limitez-les à des unités spécifiques).
Redémarrez les services concernés ; pour des changements étendus, planifiez un reboot.
Re‑vérifiez avec les cinq sorties : env utilisateur, env sudo, env systemd, apt-config dump, comportement curl -v.

Checklist C: Proxy must exist, but make it sane

Choisissez un mécanisme de configuration faisant autorité par périmètre :
- Pour apt : un seul fichier géré dans /etc/apt/apt.conf.d/.
- Pour les services : drop-ins unitaires avec Environment= (pas de defaults globaux sauf si global réel).
Définissez no_proxy avec soin : incluez endpoints metadata, plans de contrôle de cluster, registres internes et localhost.
Si l’interception TLS est impliquée, gérez la distribution de la CA d’entreprise et vérifiez sur les hôtes (ne comptez pas sur les navigateurs).
Documentez la propriété : qui change l’hôte/port/auth du proxy, et comment les changements sont déployés en toute sécurité.

FAQ

1) Pourquoi `apt update` utilise un proxy alors que mon shell n’affiche pas `http_proxy` ?

Parce qu’apt peut être configuré indépendamment via /etc/apt/apt.conf et /etc/apt/apt.conf.d/*.
Vérifiez avec apt-config dump | grep -i proxy.

2) Pourquoi `sudo apt update` se comporte différemment de `apt update` ?

sudo peut préserver les variables proxy (env_keep), et root peut avoir des fichiers de démarrage ou un environnement différent.
Comparez env | grep -i proxy vs sudo env | grep -i proxy.

3) Où est l’endroit « principal » où Debian stocke les paramètres proxy ?

Il n’y en a pas un seul. Pour apt c’est les fichiers de config apt ; pour de nombreux outils CLI ce sont les variables d’environnement ; pour les services ce sont les environnements systemd ou les overrides d’unité.
C’est pourquoi le nettoyage du proxy ressemble à une chasse au trésor à moins de standardiser.

4) Puis-je juste définir `Acquire::https::Proxy "false";` ?

Vous pouvez désactiver les proxies en définissant des chaînes vides pour les options proxy, ou en supprimant les directives. Pour un run ponctuel, utilisez :
apt -o Acquire::https::Proxy="" -o Acquire::http::Proxy="" update.
Pour un comportement permanent, supprimez le fichier source ou gérez‑le explicitement.

5) Pourquoi `no_proxy` ne fonctionne pas pour les plages CIDR ?

Parce que le support varie selon le client, et beaucoup ne parsèment pas les CIDR dans no_proxy. Préférez des domaines explicites et des hostnames.
Testez avec le client et l’URL exacte ; ne présumez pas la portabilité.

6) J’ai supprimé les proxies, mais les unattended upgrades échouent toujours. Pourquoi ?

Les unattended upgrades s’exécutent comme service. systemd peut encore fournir des variables proxy via l’environnement du gestionnaire ou des drop-ins d’unité.
Vérifiez systemctl show-environment et systemctl show -p Environment unattended-upgrades.service.

7) apt échoue avec des erreurs de certificat uniquement sur les réseaux d’entreprise. Est-ce un problème de proxy ?

Souvent c’est de l’interception TLS. Le « proxy » fait du MITM et présente des certificats signés par une CA d’entreprise qui n’est pas dans le magasin de confiance Debian.
Corrigez en installant la CA d’entreprise correctement, ou en contournant l’interception pour les mirrors Debian si la politique le permet.

8) Quelle est la façon la plus sûre de prouver que le proxy est en cause sans changer la config ?

Pour curl : lancez curl -v --noproxy '*' et comparez le comportement.
Pour apt : lancez apt -o Acquire::http::Proxy="" -o Acquire::https::Proxy="" update.
Si cela fonctionne, vous avez isolé le coupable.

9) Dois‑je stocker des identifiants proxy dans les fichiers de config apt ?

Évitez si possible. Les identifiants deviennent lisibles à plus d’endroits que prévu (sauvegardes, logs, bundles de support).
Si l’organisation exige des proxies authentifiés, utilisez le mécanisme d’agrégation de secrets approuvé et minimisez l’endroit où les secrets résident.

10) Comment empêcher les paramètres proxy de revenir ?

Trouvez l’écrivain : cloud‑init, gestion de configuration, scripts de bake d’image, ou outils de conformité. Supprimez la source de vérité là‑bas.
Si vous ne « réparez que le serveur », la prochaine exécution le réintroduira.

Conclusion : étapes pratiques suivantes

Les problèmes de proxy donnent l’impression d’être des problèmes réseau parce que le mode d’échec est « incapable d’atteindre internet ». Ce sont le plus souvent des problèmes de configuration parce que le système suit des instructions cachées.
Debian 13 vous donne un ensemble propre de leviers — config apt, environnement, systemd — mais il vous donne aussi assez de corde pour faire un gâchis.

Étapes suivantes qui fonctionnent vraiment en production :

Exécutez les commandes de diagnostic rapide et décidez si l’hôte doit du tout être proxyé.
Rendez la configuration proxy single-source et scopiée : un drop-in apt, env systemd unitaires, pas de /etc/environment global sauf besoin réel.
Supprimez env_keep pour les proxies sur les hôtes qui doivent être directs.
Prouvez la correction avec des sorties, pas des impressions : apt-config dump, systemctl show-environment, et curl -v avec et sans contournement du proxy.