ALL_PROXY et l'erreur « Unknown scheme: http »
Un programme peut rejeter une valeur http:// dans ALL_PROXY alors que HTTP_PROXY l'accepte. C'est le consommateur de la variable qui définit les schémas pris en charge.
proxy: unknown scheme: http peut sembler absurde quand le même point de terminaison fonctionne dans curl. Le point de terminaison est peut-être correct. Un autre programme interprète la variable.
Les noms d'environnement sont des conventions, pas une API réseau universelle. Le paquet Go golang.org/x/net/proxy gère les URL avec une approche orientée SOCKS. Un consommateur qui utilise cet analyseur peut rejeter un schéma HTTP qu'un client HTTP complet prend en charge ailleurs.
Identifiez le composant qui émet l'erreur et la variable qu'il lit. Vérifiez sa version et les schémas documentés. Ne remplacez pas http:// par socks5:// à moins que le service en face ne parle réellement SOCKS5. Si ce consommateur exige SOCKS5 et qu'une route publique est autorisée, la liste de proxys SOCKS5 propose de vrais points de terminaison pour ce protocole ; gardez séparées les routes HTTP dont les autres clients ont besoin.
Un ancien rapport sur Docker Toolbox concernait une implémentation historique précise. Ce n'est pas une raison pour rétrograder une installation Docker moderne. Les paramètres actuels de proxy HTTP du démon Docker ont leur propre interface documentée.
Si la cause est une valeur ALL_PROXY héritée sans rapport, supprimez-la ou remplacez-la à la portée de processus prévue. Conservez le réglage de proxy HTTP dont les autres clients ont besoin. Un seul environnement contenant les deux valeurs peut révéler des différences que les applications isolées ne montreraient jamais.