In this Article
Praca z GitHub w sieci firmowej jest zazwyczaj problemem konfiguracyjnym rozproszonym między pięć narzędzi, które nie współdzielą ustawień. Klonowanie działa, a npm install zawodzi; npm działa, a Docker nie może pobrać obrazu; wszystko działa w wierszu poleceń, ale IDE nie może się z niczym połączyć.
Ten przewodnik wyjaśnia, skąd każde narzędzie odczytuje ustawienia proxy, dlaczego SSH zachowuje się inaczej niż HTTPS, jak interpretować cztery typy błędów, które faktycznie zobaczysz, oraz których dwóch skrótów warto nie stosować.
Najważniejsze informacje
- Każde narzędzie ma własną konfigurację proxy. Git, npm, pip, Docker i powłoka odczytują różne ustawienia, dlatego naprawienie jednego z nich pozostawia pozostałe niesprawne.
- SSH zazwyczaj zawodzi tam, gdzie działa HTTPS, ponieważ większość firmowych proxy przekazuje jedynie HTTP CONNECT na standardowych portach.
- Błędy certyfikatów prawie zawsze oznaczają inspekcję TLS, a rozwiązaniem jest zaufanie firmowemu CA zamiast wyłączania weryfikacji.
- Nigdy nie wyłączaj weryfikacji certyfikatów, aby uruchomić klonowanie. Zmienia to widoczny problem konfiguracyjny w niewidoczny problem bezpieczeństwa.
- Dane uwierzytelniające w URL proxy trafiają do logów i historii powłoki, dlatego zamiast tego użyj magazynu danych uwierzytelniających narzędzia.
Skąd każde narzędzie odczytuje ustawienia proxy?
Oddzielnie, co jest źródłem większości niejasności. Nazywamy to 4-częściowym modelem łańcucha narzędzi.
| Narzędzie | Gdzie szuka | Typowa luka |
|---|---|---|
| 1. Git | Własna konfiguracja, potem zmienne środowiskowe | Zdalne repozytoria HTTPS działają, a zdalne repozytoria SSH nie |
| 2. Menedżery pakietów | Własne pliki konfiguracyjne, potem zmienne środowiskowe | Każdy wymaga osobnej konfiguracji; rejestry mogą różnić się od GitHub |
| 3. Docker | Konfiguracja demona, nie tylko powłoki | Zmienne powłoki nie docierają do demona pobierającego obrazy |
| 4. IDE i edytory | Własne ustawienia, czasem magazyn systemowy | Terminal działa, a zintegrowane funkcje nie |
Działająca konfiguracja proxy GitHub oznacza zatem pięć konfiguracji, a nie jedną. W praktyce najpierw ustaw zmienne środowiskowe dla powłoki, potem skonfiguruj git, następnie każdy menedżer pakietów, później demona Docker i od początku dodaj listę wykluczeń proxy dla hostów wewnętrznych. Pominięcie ostatniego kroku sprawia, że po pozornie udanej konfiguracji usługi wewnętrzne stają się nieosiągalne.
Dlaczego SSH zawodzi, gdy działa HTTPS?
Ponieważ są to różne protokoły działające na różnych portach, a większość firmowych proxy przekazuje jedynie HTTP CONNECT do niewielkiego zestawu portów.
Git przez HTTPS to zwykłe żądanie internetowe, które proxy obsługuje natywnie. Git przez SSH używa portu 22, który zazwyczaj w ogóle nie jest dozwolony przez proxy. W rezultacie repozytorium klonuje się bez problemu przez zdalne repozytorium HTTPS, a przy zdalnym repozytorium SSH występuje przekroczenie czasu, zaś komunikat błędu rzadko wyjaśnia dlaczego.
Trzy praktyczne rozwiązania, w kolejności preferencji: zmień zdalne repozytorium na HTTPS z tokenem, użyj SSH przez port HTTPS tam, gdzie GitHub to obsługuje, albo poproś zespół sieciowy o zezwolenie na SSH do konkretnych hostów. Pierwsze działa wszędzie i na nim poprzestaje większość zespołów.
Jak interpretować błędy?
| Błąd | Użyj tego rozwiązania, gdy | Unikaj, gdy |
|---|---|---|
| Weryfikacja certyfikatu nie powiodła się | Dodaj firmowy CA do magazynu zaufanych certyfikatów narzędzia | Nigdy nie wyłączaj weryfikacji, ponieważ ukrywa rzeczywiste ryzyko |
| Przekroczono czas połączenia ze zdalnym repozytorium SSH | Przejdź na HTTPS albo SSH przez port HTTPS | Ponawiania prób; port jest zablokowany, a nie wolny |
| Wymagane jest uwierzytelnienie proxy | Skonfiguruj dane uwierzytelniające w magazynie narzędzia | Umieszczania ich w URL, ponieważ trafiają do logów |
| Działa w terminalu, zawodzi w Docker | Skonfiguruj demona Docker, a następnie uruchom go ponownie | Dodawania kolejnych zmiennych powłoki, których demon nigdy nie odczytuje |
| Hosty wewnętrzne są nieosiągalne po konfiguracji | Dodaj je do listy wykluczeń proxy | Całkowitego usuwania konfiguracji proxy |
Warto stanowczo traktować pierwszy wiersz. Inspekcja TLS oznacza, że urządzenie pośredniczące kończy i ponownie podpisuje Twoje połączenia, a właściwą reakcją jest świadome zaufanie CA organizacji. Wyłączenie weryfikacji usuwa błąd i sprawia, że każde przyszłe przechwycenie staje się niewidoczne.
Kiedy zewnętrzne proxy jest właściwym narzędziem?
Rzadko w przypadku tego problemu i warto to jasno powiedzieć.
Firmowe proxy jest infrastrukturą obsługiwaną przez Twoją organizację, a rozwiązaniem problemu dostępu do GitHub za nim jest konfiguracja, nie drugie proxy. Omijanie kontroli sieciowej, którą pracodawca celowo wdrożył, jest najpierw kwestią zasad, a dopiero potem techniczną.
Komercyjne proxy rzeczywiście ma zastosowanie w innej pracy związanej z GitHub: zbieraniu na dużą skalę danych z publicznych repozytoriów, sprawdzaniu sposobu renderowania publicznej strony z innego kraju albo uruchamianiu automatycznych kontroli z wielu regionów. W przypadku zbierania danych z repozytoriów właściwym rozwiązaniem w pierwszej kolejności jest GitHub API z tokenem, które oferuje na tyle duże limity, że web scraping rzadko jest uzasadniony.
Gdy zbieranie danych rzeczywiście wymaga rozproszonych wyjść, DataImpulse residential obejmuje 195 krajów za $1 za GB. Powiązane: proxy do web scraping, wyjaśnienie błędu 403 Forbidden.
Często zadawane pytania
Jak skonfigurować git do używania proxy?
Ustaw proxy we własnej konfiguracji git lub w standardowych zmiennych środowiskowych i jednocześnie dodaj hosty wewnętrzne do listy wykluczeń proxy. Git odczytuje swoją konfigurację niezależnie od npm, pip i Docker, dlatego każde narzędzie wymaga osobnej konfiguracji.
Dlaczego git clone przez SSH zawodzi za proxy?
Ponieważ SSH używa portu 22, a większość firmowych proxy przekazuje jedynie HTTP CONNECT na standardowe porty internetowe. Zdalne repozytoria HTTPS działają, ponieważ są zwykłymi żądaniami internetowymi. Zmiana zdalnego repozytorium na HTTPS z tokenem jest rozwiązaniem działającym w największej liczbie środowisk.
Co powoduje błędy certyfikatów za firmowym proxy?
Inspekcja TLS: urządzenie pośredniczące kończy i ponownie podpisuje Twoje połączenia własnym urzędem certyfikacji organizacji. Rozwiązaniem jest dodanie tego CA do magazynu zaufanych certyfikatów każdego narzędzia. Wyłączenie weryfikacji certyfikatu usuwa błąd i pozbawia Cię możliwości wykrycia rzeczywistego przechwycenia.
Dlaczego Docker zawodzi, gdy działa mój terminal?
Ponieważ obrazy pobiera demon Docker, a nie Twoja powłoka, i odczytuje on własną konfigurację zamiast zmiennych środowiskowych. Skonfiguruj ustawienia proxy demona i uruchom go ponownie.
Czy w pracy powinienem używać komercyjnego proxy, aby uzyskać dostęp do GitHub?
Nie. Firmowe proxy to infrastruktura celowo obsługiwana przez Twoją organizację, a rozwiązaniem jest konfiguracja. Komercyjne proxy ma zastosowanie w innej pracy, takiej jak zbieranie publicznych danych z wielu regionów, a nawet wtedy GitHub API z tokenem jest zazwyczaj lepszą drogą.
Gdy zadaniem jest zbieranie danych, a nie łączność
Sprawdzanie, jak publiczne strony renderują się w innych regionach, lub zbieranie publicznych danych na dużą skalę to inny problem niż konfiguracja sieci firmowej. DataImpulse residential proxies obejmują 195 krajów za $1 za GB. Utwórz konto, gdy to jest Twoim zadaniem.
Powiązane: proxy do web scraping · błąd 403 Forbidden podczas web scraping · czym jest proxy internetowe.
Ostatnia aktualizacja: 17 września 2026 r.