In this Article
Lavorare con GitHub dall’interno di una rete aziendale è di solito un problema di configurazione distribuito tra cinque strumenti che non condividono le impostazioni. Un clone funziona e npm install fallisce; npm funziona e Docker non riesce a eseguire il pull; tutto funziona dalla riga di comando e l’IDE non riesce a raggiungere nulla.
Questa guida spiega dove ogni strumento legge le impostazioni del proxy, perché SSH si comporta diversamente da HTTPS, come interpretare i quattro tipi di errore che vedrai davvero e le due scorciatoie che vale la pena rifiutare.
Informazioni chiave
- Ogni strumento ha la propria configurazione del proxy. Git, npm, pip, Docker e la shell leggono tutti impostazioni diverse, ed è per questo che correggerne uno lascia gli altri non funzionanti.
- SSH di solito fallisce dove HTTPS funziona, perché la maggior parte dei proxy aziendali inoltra solo HTTP CONNECT sulle porte standard.
- Gli errori di certificato indicano quasi sempre l’ispezione TLS, e la soluzione è considerare attendibile la CA aziendale anziché disabilitare la verifica.
- Non disabilitare mai la verifica del certificato per far funzionare un clone. Trasforma un problema di configurazione visibile in un problema di sicurezza invisibile.
- Le credenziali in un URL del proxy finiscono nei log e nella cronologia della shell, quindi usa invece l’archivio delle credenziali dello strumento.
Dove legge ogni strumento le impostazioni del proxy?
Separatamente, ed è all’origine della maggior parte della confusione. Lo chiamiamo modello della toolchain in 4 parti.
| Strumento | Dove cerca | Lacuna comune |
|---|---|---|
| 1. Git | La propria configurazione, poi le variabili d’ambiente | I remote HTTPS funzionano mentre quelli SSH no |
| 2. Gestori di pacchetti | I propri file di configurazione, poi le variabili d’ambiente | Ognuno richiede una configurazione separata; i registry possono differire da GitHub |
| 3. Docker | Configurazione del daemon, non solo della shell | Le variabili della shell non raggiungono il daemon che esegue il pull delle immagini |
| 4. IDE ed editor | Le proprie impostazioni, talvolta l’archivio di sistema | Il terminale funziona, le funzioni integrate no |
Una configurazione github proxy funzionante significa quindi cinque configurazioni, non una. L’ordine pratico è impostare le variabili d’ambiente per la shell, poi configurare git, quindi ogni gestore di pacchetti, poi il daemon Docker e includere fin dall’inizio un elenco no-proxy per gli host interni. Saltare l’ultimo passaggio è ciò che rende i servizi interni irraggiungibili dopo una configurazione altrimenti riuscita.
Perché SSH fallisce quando HTTPS funziona?
Perché sono protocolli diversi su porte diverse, e la maggior parte dei proxy aziendali inoltra solo HTTP CONNECT verso un piccolo gruppo di porte.
Git tramite HTTPS è una normale richiesta web che un proxy gestisce nativamente. Git tramite SSH usa la porta 22, che di solito non è affatto consentita attraverso il proxy. Il risultato è che un repository viene clonato senza problemi con un remote HTTPS e va in timeout con un remote SSH, e il messaggio di errore raramente spiega il perché.
Tre soluzioni pratiche, in ordine di preferenza: passa il remote a HTTPS con un token, usa SSH sulla porta HTTPS dove GitHub lo supporta oppure chiedi al team di rete di consentire SSH verso host specifici. La prima funziona ovunque ed è quella adottata dalla maggior parte dei team.
Come interpretare gli errori?
| Errore | Usa questa soluzione quando | Evita quando |
|---|---|---|
| Verifica del certificato non riuscita | Aggiungi la CA aziendale all’archivio attendibile dello strumento | Non disabilitare mai la verifica, che nasconde un rischio reale |
| Timeout della connessione su un remote SSH | Passa a HTTPS o usa SSH sulla porta HTTPS | Riprovare; la porta è bloccata, non lenta |
| Autenticazione del proxy richiesta | Configura le credenziali nell’archivio dello strumento | Inserirle in un URL, perché finirebbero nei log |
| Funziona nel terminale, fallisce in Docker | Configura il daemon Docker, poi riavvialo | Aggiungere altre variabili della shell, che il daemon non legge mai |
| Host interni irraggiungibili dopo la configurazione | Aggiungili all’elenco no-proxy | Rimuovere completamente la configurazione del proxy |
La prima riga è quella su cui conviene essere inflessibili. L’ispezione TLS significa che un middlebox termina e firma nuovamente le connessioni, e la risposta corretta è considerare attendibile deliberatamente la CA dell’organizzazione. Disabilitare la verifica fa sparire l’errore e rende invisibile ogni futura intercettazione.
Quando un proxy esterno è lo strumento giusto?
Raramente per questo problema, ed è importante dirlo chiaramente.
Un proxy aziendale è un’infrastruttura gestita dalla tua organizzazione, e la soluzione per l’accesso a GitHub tramite esso è la configurazione, non un secondo proxy. Aggirare un controllo di rete che il tuo datore di lavoro ha deliberatamente predisposto è una questione di policy prima che tecnica.
Un proxy commerciale si applica davvero a un lavoro diverso che coinvolge comunque GitHub: raccogliere dati di repository pubblici su larga scala, verificare come una pagina pubblica viene visualizzata da un altro paese o eseguire controlli automatizzati da più regioni. Per raccogliere dati dei repository in particolare, l’API GitHub con un token è prima di tutto la soluzione giusta, ed è abbastanza generosa da rendere il web scraping raramente giustificato.
Quando la raccolta richiede davvero uscite distribuite, DataImpulse residential copre 195 paesi a $1 per GB. Correlati: proxy per il web scraping, spiegazione di 403 Forbidden.
Domande frequenti
Come configuro git per usare un proxy?
Imposta il proxy nella configurazione di git o nelle variabili d’ambiente standard, e aggiungi contemporaneamente gli host interni a un elenco no-proxy. Git legge la propria configurazione separatamente da npm, pip e Docker, quindi ogni strumento richiede una configurazione individuale.
Perché git clone tramite SSH fallisce dietro un proxy?
Perché SSH usa la porta 22 e la maggior parte dei proxy aziendali inoltra solo HTTP CONNECT verso le porte web standard. I remote HTTPS funzionano perché sono normali richieste web. Passare il remote a HTTPS con un token è la soluzione che funziona nel maggior numero di ambienti.
Quali sono le cause degli errori di certificato dietro un proxy aziendale?
L’ispezione TLS: un middlebox termina e firma nuovamente le connessioni con l’autorità di certificazione dell’organizzazione. La soluzione è aggiungere quella CA all’archivio attendibile di ogni strumento. Disabilitare la verifica del certificato rimuove l’errore e la capacità di rilevare un’intercettazione reale.
Perché Docker fallisce quando il terminale funziona?
Perché è il daemon Docker a eseguire il pull delle immagini, non la shell, e legge la propria configurazione anziché le variabili d’ambiente. Configura le impostazioni del proxy del daemon e riavvialo.
Dovrei usare un proxy commerciale per raggiungere GitHub al lavoro?
No. Un proxy aziendale è un’infrastruttura gestita deliberatamente dalla tua organizzazione, e la soluzione è la configurazione. I proxy commerciali si applicano a un lavoro diverso, come raccogliere dati pubblici da molte regioni, e anche in quel caso l’API GitHub con un token è di solito la soluzione migliore.
Quando il lavoro è la raccolta, non la connettività
Verificare come le pagine pubbliche vengono visualizzate da altre regioni o raccogliere dati pubblici su larga scala è un problema diverso dalla configurazione della rete aziendale. DataImpulse residential proxies coprono 195 paesi a $1 per GB. Crea un account quando è questo il lavoro da svolgere.
Correlati: proxy per il web scraping · 403 Forbidden durante il web scraping · che cos’è un web proxy.
Ultimo aggiornamento: 17 settembre 2026.