In this Article
Trabajar con GitHub desde una red corporativa suele ser un problema de configuración repartido entre cinco herramientas que no comparten ajustes. Un clon funciona y npm install falla; npm funciona y Docker no puede descargar; todo funciona en la línea de comandos y el IDE no logra conectarse a nada.
Esta guía explica dónde lee cada herramienta sus ajustes de proxy, por qué SSH se comporta de forma distinta a HTTPS, cómo interpretar los cuatro tipos de error que realmente verá y los dos atajos que conviene rechazar.
Datos clave
- Cada herramienta tiene su propia configuración de proxy. Git, npm, pip, Docker y su intérprete de comandos leen ajustes distintos, por lo que arreglar una deja las demás sin funcionar.
- SSH suele fallar donde HTTPS funciona, porque la mayoría de los proxies corporativos reenvían solo HTTP CONNECT en puertos estándar.
- Los errores de certificado casi siempre significan inspección TLS, y la solución es confiar en la CA corporativa en lugar de desactivar la verificación.
- Nunca desactive la verificación de certificados para que funcione un clon. Convierte un problema de configuración visible en uno de seguridad invisible.
- Las credenciales en una URL de proxy se filtran en los registros y el historial del intérprete de comandos, así que use en su lugar el almacén de credenciales de la herramienta.
¿Dónde lee cada herramienta los ajustes de proxy?
Por separado, y esa es la raíz de gran parte de la confusión. Lo llamamos el modelo de cadena de herramientas de 4 partes.
| Herramienta | Dónde busca | Problema habitual |
|---|---|---|
| 1. Git | Su propia configuración y después las variables de entorno | Los remotos HTTPS funcionan mientras que los remotos SSH no |
| 2. Gestores de paquetes | Sus propios archivos de configuración y después las variables de entorno | Cada uno debe configurarse por separado; los registros pueden diferir de GitHub |
| 3. Docker | Configuración del daemon, no solo su intérprete de comandos | Las variables del intérprete de comandos no llegan al daemon que descarga imágenes |
| 4. IDE y editores | Sus propios ajustes, a veces el almacén del sistema | La terminal funciona, las funciones integradas no |
Por tanto, una configuración de proxy de GitHub que funcione implica cinco configuraciones, no una. El orden práctico es establecer variables de entorno para el intérprete de comandos, configurar git, después cada gestor de paquetes, luego el daemon de Docker e incluir desde el principio una lista de exclusión del proxy para hosts internos. Omitir el último paso es lo que hace que los servicios internos sean inaccesibles tras una configuración que por lo demás ha tenido éxito.
¿Por qué SSH falla cuando HTTPS funciona?
Porque son protocolos distintos en puertos diferentes, y la mayoría de los proxies corporativos solo reenvían HTTP CONNECT a un conjunto reducido de puertos.
Git mediante HTTPS es una solicitud web normal que un proxy gestiona de forma nativa. Git mediante SSH usa el puerto 22, que normalmente no está permitido a través del proxy. El resultado es que un repositorio se clona sin problemas con un remoto HTTPS y agota el tiempo de espera con un remoto SSH, y el mensaje de error rara vez explica el motivo.
Tres soluciones prácticas, por orden de preferencia: cambie el remoto a HTTPS con un token, use SSH mediante el puerto HTTPS cuando GitHub lo admita o pida al equipo de red que permita SSH hacia hosts específicos. La primera funciona en todas partes y es la opción por la que se decanta la mayoría de los equipos.
¿Cómo interpretar los errores?
| Error | Use esta solución cuando | Evítela cuando |
|---|---|---|
| Falló la verificación del certificado | Añada la CA corporativa al almacén de confianza de la herramienta | Nunca desactive la verificación, ya que oculta un riesgo real |
| Se agotó el tiempo de espera de conexión en un remoto SSH | Cambie a HTTPS o use SSH mediante el puerto HTTPS | Reintentar; el puerto está bloqueado, no es lento |
| Se requiere autenticación de proxy | Configure las credenciales en el almacén de la herramienta | Incluirlas en una URL, donde se filtran a los registros |
| Funciona en la terminal, falla en Docker | Configure el daemon de Docker y después reinícielo | Añadir más variables del intérprete de comandos, que el daemon nunca lee |
| Los hosts internos son inaccesibles tras la configuración | Añádalos a la lista de exclusión del proxy | Eliminar por completo la configuración de proxy |
Conviene ser firme especialmente con la primera fila. La inspección TLS significa que un dispositivo intermedio termina y vuelve a firmar sus conexiones, y la respuesta correcta es confiar deliberadamente en la CA de la organización. Desactivar la verificación hace que desaparezca el error y vuelve invisible toda interceptación futura.
¿Cuándo es un proxy externo la herramienta adecuada?
Rara vez para este problema, y conviene dejarlo claro.
Un proxy corporativo es infraestructura que gestiona su organización, y la solución para acceder a GitHub detrás de él es la configuración, no un segundo proxy. Sortear un control de red que su empleador ha implementado deliberadamente es una cuestión de política antes que técnica.
El caso en que un proxy comercial realmente aplica es otro trabajo que casualmente implica GitHub: recopilar datos de repositorios públicos a escala, comprobar cómo se representa una página pública desde otro país o ejecutar comprobaciones automatizadas desde varias regiones. Para recopilar datos de repositorios en concreto, la API de GitHub con un token es primero la respuesta adecuada, y es lo bastante generosa como para que el scraping rara vez esté justificado.
Cuando la recopilación necesita salidas distribuidas, los proxies residenciales de DataImpulse cubren 195 países a $1 por GB. Relacionado: proxies para web scraping, explicación de 403 Forbidden.
Preguntas frecuentes
¿Cómo configuro git para usar un proxy?
Establezca el proxy en la configuración propia de git o en las variables de entorno estándar y añada al mismo tiempo los hosts internos a una lista de exclusión del proxy. Git lee su propia configuración por separado de npm, pip y Docker, por lo que cada herramienta necesita configurarse individualmente.
¿Por qué git clone mediante SSH falla detrás de un proxy?
Porque SSH usa el puerto 22 y la mayoría de los proxies corporativos solo reenvían HTTP CONNECT a puertos web estándar. Los remotos HTTPS funcionan porque son solicitudes web normales. Cambiar el remoto a HTTPS con un token es la solución que funciona en más entornos.
¿Qué provoca errores de certificado detrás de un proxy corporativo?
La inspección TLS: un dispositivo intermedio termina y vuelve a firmar sus conexiones con la propia autoridad de certificación de la organización. La solución es añadir esa CA al almacén de confianza de cada herramienta. Desactivar la verificación de certificados elimina el error y elimina su capacidad de detectar una interceptación real.
¿Por qué Docker falla cuando mi terminal funciona?
Porque el daemon de Docker descarga imágenes, no su intérprete de comandos, y lee su propia configuración en lugar de sus variables de entorno. Configure los ajustes de proxy del daemon y reinícielo.
¿Debo usar un proxy comercial para acceder a GitHub en el trabajo?
No. Un proxy corporativo es infraestructura que su organización gestiona deliberadamente, y la solución es la configuración. Los proxies comerciales se aplican a otro trabajo, como recopilar datos públicos desde muchas regiones, e incluso ahí la API de GitHub con un token suele ser la mejor vía.
Cuando el trabajo es recopilación, no conectividad
Comprobar cómo se representan las páginas públicas desde otras regiones o recopilar datos públicos a escala es un problema distinto de la configuración de redes corporativas. Los proxies residenciales de DataImpulse cubren 195 países a $1 por GB. Cree una cuenta cuando ese sea el trabajo.
Relacionado: proxies para web scraping · 403 Forbidden al hacer web scraping · qué es un proxy web.
Última actualización: 17 de septiembre de 2026.