Dlaczego curl łączy się z localhost zamiast ze zdalnym URL

Jeśli curl próbuje połączyć się z localhost niezależnie od podanego URL, VPN to złe miejsce na początek. Lokalny serwer proxy HTTP lub SOCKS może być zamierzonym pierwszym połączeniem, nawet gdy potrzebna usługa znajduje się zupełnie gdzie indziej. Jeśli ten serwer proxy już nie działa, próba połączenia z localhost kończy się niepowodzeniem, zanim curl dotrze do celu. Odpowiedź serwera proxy nie jest też dowodem, że cel odpowiedział.

Wykonaj te kroki po kolei i zatrzymaj się na pierwszym, który zmienia pierwszą próbę połączenia.

Najpierw przeczytaj własne reguły proxy curla

curl czyta zmienne proxy właściwe dla protokołu, takie jak https_proxy i HTTPS_PROXY, a także ALL_PROXY, gdy nie ma zastosowania żadna wartość właściwa dla protokołu. Sprawdź środowisko tej powłoki, usługi lub zadania, które faktycznie uruchamia curl, a nie swojego bieżącego terminala. Zadanie CI, jednostka systemd i powłoka interaktywna mogą odziedziczyć trzy różne zestawy. Właśnie zgadywanie na podstawie widocznej powłoki sprawia, że to dochodzenie traci całe popołudnie.

Jedna zasada jest warta zapamiętania. curl akceptuje http_proxy tylko małymi literami; wersja wielkimi literami HTTP_PROXY jest ignorowana, dlatego to samo środowisko zachowuje się inaczej w innych narzędziach.

Odczytaj wartości poufnie, ponieważ URL proxy często zawiera dane uwierzytelniające.

Następnie sprawdź domyślny plik konfiguracyjny curla pod kątem nadpisań proxy lub połączenia i potwierdź, który plik wykonywalny naprawdę uruchamiasz. Alias powłoki, funkcja lub skrypt opakowujący mogą dodawać opcje, które nigdy nie pojawiają się w wierszu poleceń.

Porównaj trzy wywołania z włączonym TLS

Użyj jednego zatwierdzonego celu diagnostycznego i tego samego pliku binarnego we wszystkich trzech przebiegach.

curl -v https://service.corp.example/status
curl -q -v https://service.corp.example/status
curl -q --proxy '' -v https://service.corp.example/status

-q wyłącza domyślny curlrc i aby działać, musi być pierwszym parametrem w wierszu. Nie usuwa zmiennych środowiskowych proxy, co zaskakuje osoby, które tego oczekują. Trzecia forma dodaje pustą wartość --proxy, nadpisując serwer proxy żądany przez środowisko tylko dla tego wywołania. Porównuj pierwszą próbę połączenia w każdym wyniku, a nie końcowy kod stanu.

Szczegółowe dane wyjściowe mogą ujawnić nagłówki, tokeny i dane uwierzytelniające proxy, więc trzymaj je lokalnie i czytaj fragmenty przed udostępnieniem.

Co wyklucza każdy wynik

Jeśli pominięcie konfiguracji domyślnej zmienia połączenie, źródłem jest plik konfiguracyjny. Jeśli zmienia je jawne wyłączenie odziedziczonego proxy, źródłem jest zmienna środowiskowa. Jeśli żadne z nich go nie zmienia, a localhost nadal się pojawia, sprawdź nadpisania połączenia w wierszu poleceń, rozwiązywanie nazw hostów i wybrany plik wykonywalny. Każde z nich ma inną poprawkę i żadne nie jest zmianą routingu.

Ładowanie niestandardowych bibliotek lub wstrzyknięte zachowanie sieci to późniejsza warstwa, a sama zmienna środowiskowa nie jest tego dowodem.

Trzymaj decyzję o proxy oddzielnie od VPN

Gdy curl wybierze bezpośredni cel, system operacyjny nadal kieruje to połączenie. Wyłączenie proxy aplikacji nie wyłącza trasy VPN ani jej polityki filtrowania. Porównania dostępu bezpośredniego wykonuj tylko tam, gdzie ta diagnostyka jest dozwolona. Test, który po cichu omija politykę, nie jest prawidłowym wynikiem, to incydent.

Jeśli wymagany jest lokalny serwer proxy, przywróć jego usługę i adres, zamiast usuwać jego ustawienia.

Jeśli dostęp bezpośredni jest potrzebny tylko wybranym celom prywatnym, dodaj wąski zatwierdzony wyjątek i zachowaj proxy dla wszystkiego innego. Zachowaj pierwszy błąd z wybranej ścieżki, ponieważ odmowa localhost, odrzucenie CONNECT przez proxy, błąd certyfikatu i błąd autoryzacji wskazują cztery różne etapy.