Los antiguos HTTP_PROXY_REQUEST_FULLURI de Composer y las soluciones FULLURI relacionadas ya no son necesarios ni se usan en la implementación documentada. Un indicador ignorado no puede reparar la ruta del cliente en ejecución.

Para Composer en la línea de comandos dentro de un shell POSIX, exporta las variables de proxy admitidas antes de invocar Composer desde ese shell:

export http_proxy=http://proxy.example:8080
export https_proxy=http://proxy.example:8080

Se prefieren los nombres en minúsculas. Ambos valores pueden empezar por http:// cuando el propio proxy usa HTTP normal; un destino HTTPS no requiere una conexión HTTPS al proxy. Sustituye el endpoint de ejemplo por el servicio aprobado. Para descargas públicas de paquetes en las que se permite un intermediario público, elige un candidato HTTP de la lista de proxies HTTP.

Un IDE o un agente de compilación necesita los valores en su propio entorno de proceso. Cambiar un ajuste persistente después no actualiza un proceso que ya se está ejecutando.

Cuando Composer se ejecuta fuera de la CLI

Para las solicitudes HTTP en un contexto que no es la CLI, Composer no usa http_proxy ni HTTP_PROXY. En su lugar documenta CGI_HTTP_PROXY, lo que evita que las cabeceras de la solicitud se tomen por una configuración de proxy de confianza. No copies la solución del shell en una aplicación web ni tomes ajustes de proxy de una solicitud no confiable.

Lee la operación fallida

Un nombre de proxy sin resolver, una conexión rechazada, un desafío 407 y un fallo de certificado apuntan a etapas distintas. Usa el primer error significativo en lugar de aplicar soluciones antiguas de IPv6 o de verificación de certificados.

Si la descarga HTTP de Composer funciona pero una dependencia basada en Git falla, revisa el proceso Git independiente, su ruta y su cuenta. Es un consumidor distinto de la descarga correcta de Composer.

Artículos relacionados