Чому curl підключається до localhost, а не до віддаленого URL

Якщо curl намагається підключитися до localhost незалежно від наданого вами URL, VPN — це неправильне місце для початку. Локальний проксі HTTP або SOCKS може бути навмисним першим з'єднанням, навіть якщо потрібний вам сервіс розташований зовсім в іншому місці. Якщо цей проксі більше не працює, спроба localhost зазнає невдачі ще до того, як curl досягне призначення. Відповідь проксі також не доводить, що призначення відповіло.

Виконуйте ці кроки по порядку й зупиніться на першому, який змінить першу спробу з'єднання.

Спершу прочитайте власні правила проксі curl

curl читає змінні проксі, специфічні для протоколу, наприклад https_proxy і HTTPS_PROXY, а також ALL_PROXY, коли не застосовується жодне значення, специфічне для протоколу. Перевірте середовище оболонки, служби або завдання, яке фактично запускає curl, а не того, що в поточному терміналі. Завдання CI, юніт systemd та інтерактивна оболонка можуть успадкувати три різні набори. Саме здогадки за видимою оболонкою й призводять до того, що це розслідування втрачає цілий день.

Один виняток варто запам'ятати. curl приймає http_proxy лише малими літерами; варіант великими літерами HTTP_PROXY ігнорується, тому те саме середовище поводиться інакше в інших інструментах.

Читайте значення конфіденційно, бо URL проксі часто містить облікові дані.

Далі перевірте типовий файл конфігурації curl на перевизначення проксі або з'єднання й підтвердьте, який саме виконуваний файл ви запускаєте. Псевдонім оболонки, функція або скрипт-обгортка можуть додати параметри, які ніколи не з'являються у вашому командному рядку.

Порівняйте три виклики з увімкненим TLS

Використовуйте одне затверджене діагностичне призначення та той самий бінарний файл для всіх трьох запусків.

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 пригнічує типовий curlrc і має бути першим параметром у рядку, щоб працювати. Він не видаляє змінні середовища проксі, що дивує тих, хто цього очікує. Третя форма додає порожнє значення --proxy, перевизначаючи запитаний середовищем проксі лише для цього виклику. Порівнюйте першу спробу з'єднання в кожному виводі, а не підсумковий код стану.

Докладний вивід може розкрити заголовки, токени й облікові дані проксі, тому тримайте його локально й читайте фрагменти, перш ніж ділитися.

Що виключає кожен результат

Якщо пропуск конфігурації за замовчуванням змінює з'єднання, джерелом є файл конфігурації. Якщо його змінює явне вимкнення успадкованого проксі, джерелом є змінна середовища. Якщо ні те, ні інше його не змінює, а localhost усе ще з'являється, подивіться на перевизначення з'єднання в командному рядку, розв'язання імен хостів і вибраний виконуваний файл. Кожне з них має інше виправлення, і жодне з них не є зміною маршрутизації.

Завантаження власних бібліотек або впроваджена мережева поведінка — це пізніший шар, і сама лише змінна середовища не є його доказом.

Тримайте рішення щодо проксі окремо від VPN

Щойно curl вибирає пряме призначення, операційна система все одно маршрутизує це з'єднання. Вимкнення проксі застосунку не вимикає маршрут VPN чи його політику фільтрації. Порівняння прямого доступу робіть лише там, де така діагностика дозволена. Тест, який тихо обходить політику, — не допустимий результат, а інцидент.

Якщо потрібен локальний проксі, відновіть його службу й адресу, а не видаляйте його налаштування.

Якщо прямий доступ потрібен лише окремим приватним призначенням, додайте вузький затверджений виняток і залиште проксі для всього іншого. Збережіть першу помилку на вибраному шляху, бо відмова localhost, відхилення CONNECT проксі, збій сертифіката й помилка авторизації вказують на чотири різні етапи.