Debian 13: Налаштування проксі ламають apt/curl — де вони ховаються і як їх очистити

October 9, 2025 • February 3, 2026 • Читання: 7 хв • Views: 5

Було корисно?

Симптом завжди однаковий: apt update зависає, curl повертає дивний 407, а машина каже, що в неї «немає конфігурованого проксі».
Потім ви виявляєте, що проксі налаштовано в п’яти місцях, половина з яких невидима для людини, що тримає pager.

Debian 13 не «ламає» мережу. Він просто точнісінько виконує інструкції — деякі з яких залишив старий bootstrap-скрипт, корпоративний образ
або та єдина подія, коли хтось експортнув http_proxy у профілі оболонки і забув про це. Пошукаємо налаштування проксі, акуратно їх приберемо
і доведемо, що система справді без проксі.

Швидкий план діагностики

Коли apt/curl відмовляють і ви хочете найшвидший шлях до істини, не починайте з перегляду всіх конфігураційних файлів на планеті.
Почніть з спостереження поведінки й запитайте: «Це рішення про проксі, проблема DNS чи проблема TLS/шляху?»

1) Перевірте, чи використовується проксі (змінні середовища + вигляд apt)

Запустіть env | grep -i proxy в тому ж контексті, що й команда, яка падає (ваша оболонка, root shell, через sudo).
Запустіть apt-config dump | grep -i proxy, щоб побачити, що apt вважає налаштованим.

Якщо будь-що з цього показує проксі, якого ви не очікували, ви вже знайшли вузьке місце: конфігурація, а не «мережа».

2) Підтвердіть базову маршрутизацію й DNS без залучення проксі

Перевірте DNS: getent ahosts deb.debian.org
Перевірте доступність HTTPS напряму: curl -v --noproxy '*' https://deb.debian.org/

Якщо напряму працює, але apt падає, майже завжди це питання конфігурації apt або відмінностей у політиці TLS.

3) Звузьте: який шар вставляє проксі?

Якщо curl використовує проксі несподівано, зазвичай це змінні середовища або конфіг файли libcurl.
Якщо тільки apt використовує проксі, зазвичай це /etc/apt/apt.conf* або включений drop-in.
Якщо служби (не інтерактивні оболонки) використовують проксі, підозрюйте systemd manager environment drop-ins.

4) Доведіть виправлення

Після змін знову запустіть apt-config dump, systemctl show-environment і тестовий curl -v.
Не довіряйте «я видалив рядок». Довіряйте виводам.

Факти та контекст: чому привиди проксі часті

Трохи історії допомага пояснити, чому налаштування проксі такі слизькі на Linux, і чому Debian 13 тут не особливий — просто досить сучасний, щоб дати більше місць для приховування проблем.
Ось кілька конкретних фактів, що часто зустрічаються в реальних інфраструктурах:

Змінні проксі в середовищі випереджають сучасні інструменти. http_proxy і подібні стали де-факто стандартом через простоту експорту й скриптів.
Реєстр (великі/малі літери) має значення, поки ні. Багато інструментів перевіряють спочатку нижній регістр (http_proxy), деякі — верхній, а деякі обидва.
apt давно вміє працювати з проксі. Механізм Acquire::Proxy існує роками, бо менеджери пакетів — улюблена точка контролю в корпоративних мережах.
HTTPS зробив проксі політичним питанням. CONNECT-тунелювання працює; TLS-перехоплення — це коли конфліктують сховища довіри і політики. Тоді «працює в браузері» відрізняється від «працює в apt».
systemd унормував «глобальне середовище для служб». Через manager environments і drop-ins стало легко змусити всі служби успадковувати проксі — навіть якщо люди цього не бачать.
Десктопні стекі додали свої шари проксі. Налаштування GNOME, network manager і користувацькі конфіги можуть впливати на деякі клієнти, лишаючи інших осторонь.
Контейнери посилили проблему. Інструменти збірки й CI часто підсовують проксі під час білду, запікаючи їх у образи або лишаючи в /etc/environment.
no_proxy не стандартизовано. Різні клієнти трактують його по-різному: ведучі крапки, CIDR, порти, IPv6-літерали — чекайте сюрпризів.
Помилки аутентифікації виглядають як мережеві збої. Проксі, що повертає 407, може виглядати як «відмова у з’єднанні» залежно від клієнта і рівня логування.

Одна перефразована ідея від Gene Kim (автора з надійності/операцій): Покращуйте систему, покращуючи те, як ви її бачите; швидкий фідбек кращий за героїчне гадання.
Саме в цьому духі: не гадати, де живе проксі. Інструментуйте.

Як apt і curl вирішують використовувати проксі

Якщо ви займаєтесь усуненням несправностей, вам потрібна ментальна модель. Не ідеальна — лише достатньо точна, щоб припинити марнувати час.

curl: здебільшого керується середовищем, іноді зкомпільованими преференціями

curl (через libcurl) зазвичай дивиться на http_proxy, https_proxy і no_proxy (плюс варіанти в верхньому регістрі).
Ви можете перевизначити через --proxy або вимкнути через --noproxy чи --proxy ''.
Ключова діагностика: curl -v покаже, чи «Trying proxy …», чи «Connected … directly».

apt: спочатку файли конфігурації, потім середовище лише якщо ви його налаштували

apt має власну систему конфігурації та include-файли. Звичні точки:

Acquire::http::Proxy, Acquire::https::Proxy
Acquire::http::Proxy-Auto-Detect скрипти (рідко, але бувають)
Drop-in під /etc/apt/apt.conf.d/

apt не «магічно» використовує налаштування проксі десктопа. Він читає apt-конфіг. Але apt часто запускають через sudo, і sudo може зберігати змінні середовища залежно від політики.
Ось де виникає весела ситуація: у вашій користувацькій оболонці немає змінних проксі, але sudo apt update їх має.

Жарт #1: Проксі як середній менеджер: інколи корисний, часто неминучий, і коли неправильно сконфігурований — ви про це досить швидко дізнаєтесь.

Де приховані налаштування проксі в Debian 13

Місць для приховування не так багато. Трюк — перевіряти їх у правильному порядку та в правильному контексті виконання (інтерактивна оболонка vs sudo vs системна служба).

1) Змінні середовища (інтерактивні та неінтерактивні)

Користувацька оболонка: ~/.bashrc, ~/.profile, ~/.bash_profile, ~/.zshrc тощо.
Системні: /etc/environment, /etc/profile, /etc/profile.d/*.sh
sudo: /etc/sudoers і /etc/sudoers.d/* можуть зберігати змінні проксі (env_keep).

2) Конфігурація apt і drop-in

/etc/apt/apt.conf
/etc/apt/apt.conf.d/* (це зазвичай підозрюваний)
Іноді — навіть у визначеннях репозиторіїв, якщо автоматизація генерує дивні Acquire-стовпці.

3) systemd manager environment і unit drop-in

Якщо збій відбувається у службах (apt timers, unattended-upgrades, кастомні апдейтери), перевірте:

systemctl show-environment (manager environment)
Drop-in під /etc/systemd/system/*.d/ і /etc/systemd/system.conf.d/
Файли юнітів з рядками Environment=

4) Конфігурація специфічна для інструментів (wget, git, docker тощо)

Не завжди проблема в apt/curl. Іноді apt завантажує нормально, але postinst-скрипт використовує git і падає. Або curl працює, а wget ні.
Debian-системи збирають налаштування проксі по інструментах:

~/.wgetrc, /etc/wgetrc
~/.curlrc (рідше, але буває)
~/.gitconfig, /etc/gitconfig (http.proxy)

5) Корпоративне TLS-перехоплення: проксі, який не видалиш

Іноді проксі не так «налаштовано», як «примусово ввімкнено». Ви можете видалити налаштування проксі і все одно зазнати невдачі, тому що вихідний 443 прозоро перехоплюється,
і машина має довіряти корпоративному CA, щоб валідувати MITM-сертифікат. Це інша проблема: сховище довіри, а не налаштування проксі.
Але симптом схожий: apt і curl падають по TLS, тоді як браузери виглядають нормальними, бо браузер довіряє CA через політику.

Практичні завдання: команди, виводи й рішення

Нижче — перевірені у полі завдання, які ви можете виконати на хості Debian 13. Кожне містить: команду, реалістичний вивід, що це означає, і яке рішення прийняти далі.
Виконуйте їх у тому самому контексті виконання, де проявляється проблема.

Task 1: See whether your current shell exports proxy variables

cr0x@server:~$ env | grep -i proxy
http_proxy=http://proxy.corp:3128
https_proxy=http://proxy.corp:3128
no_proxy=localhost,127.0.0.1,.corp

Значення: Поточне середовище процесу каже клієнтам використовувати проксі. Якщо ви думали «проксі немає», це було бажаним мисленням.

Рішення: Знайдіть, де ці змінні встановлюються (користувацький профіль, /etc/environment, systemd, CI-обгортка). Не редагуйте файли наосліп — ідентифікуйте джерело.

Task 2: Check what sudo does to proxy variables

cr0x@server:~$ sudo env | grep -i proxy
http_proxy=http://proxy.corp:3128
https_proxy=http://proxy.corp:3128
no_proxy=localhost,127.0.0.1,.corp

Значення: sudo зберігає змінні проксі в оточенні root. Це звично в корпоративних образах через Defaults env_keep.

Рішення: Якщо потрібно, щоб apt працював без проксі, слід або видалити змінні в джерелі, або відрегулювати sudoers. Як тимчасовий тест, обережно використовуйте sudo -H env -u root -i, або явно знесталюйте змінні для однієї команди.

Task 3: Test curl’s proxy behavior explicitly

cr0x@server:~$ curl -v https://deb.debian.org/ -o /dev/null
* Uses proxy env variable https_proxy == 'http://proxy.corp:3128'
*   Trying 10.20.30.40:3128...
* Connected to proxy.corp (10.20.30.40) port 3128
> CONNECT deb.debian.org:443 HTTP/1.1
< HTTP/1.1 407 Proxy Authentication Required
curl: (56) CONNECT tunnel failed, response 407

Значення: curl підпорядковується https_proxy, доходить до проксі і отримує відмову через відсутність аутентифікації або зміну політики.

Рішення: Або налаштуйте облікові дані проксі правильно (не найулюбленіший варіант), або приберіть конфігурацію проксі. Якщо хост не повинен використовувати проксі — зосередьтесь на очищенні. Якщо повинен — виправте аутентифікацію і no_proxy.

Task 4: Prove direct connectivity by bypassing proxy variables

cr0x@server:~$ curl -v --noproxy '*' https://deb.debian.org/ -o /dev/null
* Host deb.debian.org:443 was resolved.
*   Trying 151.101.2.132:443...
* Connected to deb.debian.org (151.101.2.132) port 443
* SSL connection using TLSv1.3
> GET / HTTP/1.1
< HTTP/1.1 200 OK

Значення: Мережа, DNS і TLS до дзеркала Debian працюють, якщо обійти логіку проксі.

Рішення: Припиніть дебаг фаєрволів. Це проблема налаштування проксі, а не підключення.

Task 5: Ask apt what it thinks about proxies

cr0x@server:~$ apt-config dump | grep -iE 'Acquire::(http|https).*Proxy'
Acquire::http::Proxy "http://proxy.corp:3128/";
Acquire::https::Proxy "http://proxy.corp:3128/";

Значення: apt налаштований використовувати проксі незалежно від змінних оболонки. Навіть якщо ви знесталюєте змінні середовища, apt все одно буде проксувати.

Рішення: Знайдіть apt-файл, що містить ці директиви, і видаліть/перезапишіть його.

Task 6: Locate the apt drop-in that defines the proxy

cr0x@server:~$ sudo grep -RIn --color=never 'Acquire::.*Proxy' /etc/apt/apt.conf /etc/apt/apt.conf.d
/etc/apt/apt.conf.d/02proxy:1:Acquire::http::Proxy "http://proxy.corp:3128/";
/etc/apt/apt.conf.d/02proxy:2:Acquire::https::Proxy "http://proxy.corp:3128/";

Значення: У вас явний apt proxy-файл.

Рішення: Вирішіть, видалити файл (якщо цей хост ніколи не повинен проксувати) або керувати ним через конфігураційний менеджер з чіткою власністю.

Task 7: Check /etc/environment for persistent proxy injection

cr0x@server:~$ sudo sed -n '1,200p' /etc/environment
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
http_proxy="http://proxy.corp:3128"
https_proxy="http://proxy.corp:3128"
no_proxy="localhost,127.0.0.1,.corp"

Значення: Кожна сесія входу успадковуватиме налаштування проксі, залежно від PAM та контексту служби.

Рішення: Видаліть ці рядки, якщо машина не повинна використовувати проксі. Якщо лише деякі служби повинні, не використовуйте /etc/environment — це молоток.

Task 8: See what systemd manager environment contains

cr0x@server:~$ systemctl show-environment | grep -i proxy
http_proxy=http://proxy.corp:3128
https_proxy=http://proxy.corp:3128
no_proxy=localhost,127.0.0.1,.corp

Значення: systemd утримує змінні проксі на рівні менеджера. Служби, запущені systemd, можуть успадковувати їх, навіть якщо інтерактивні оболонки не бачать цього.

Рішення: Знайдіть, де вони були встановлені (systemctl set-environment, drop-in або скрипт образу). Плануйте зняти їх і перезапустити уражені служби.

Task 9: Search for systemd drop-ins that inject proxy settings

cr0x@server:~$ sudo grep -RIn --color=never -E 'http_proxy|https_proxy|no_proxy' /etc/systemd
/etc/systemd/system.conf.d/proxy.conf:2:DefaultEnvironment="http_proxy=http://proxy.corp:3128" "https_proxy=http://proxy.corp:3128" "no_proxy=localhost,127.0.0.1,.corp"

Значення: Проксі встановлено глобально для служб, що керуються systemd, через DefaultEnvironment.

Рішення: Видаліть цей drop-in, якщо він неправильний, або звужуйте його лише до тих юнітів, що потребують проксі. Глобальні значення — джерело технічного боргу.

Task 10: Check sudoers for env_keep that preserves proxies

cr0x@server:~$ sudo grep -RIn --color=never 'env_keep.*proxy' /etc/sudoers /etc/sudoers.d
/etc/sudoers.d/proxy:1:Defaults env_keep += "http_proxy https_proxy no_proxy"

Значення: Навіть якщо ви очистили змінні у профілі, хтось міг навмисно зберегти їх через sudo.

Рішення: Якщо хост має бути без проксі, видаліть це і перевірте, що автоматизація (Ansible, cloud-init) не додає його знову.

Task 11: Inspect apt’s actual failure with debug output

cr0x@server:~$ sudo apt -o Debug::Acquire::https=true update
Ign:1 https://deb.debian.org/debian trixie InRelease
Connecting to proxy.corp (10.20.30.40)
Answer for: https://deb.debian.org/debian/dists/trixie/InRelease
HTTP/1.1 407 Proxy Authentication Required
Err:1 https://deb.debian.org/debian trixie InRelease
  407  Proxy Authentication Required [IP: 10.20.30.40 3128]
Reading package lists... Done

Значення: apt однозначно використовує проксі, і проксі відхиляє його. Дебаг-вивід знімає сумніви.

Рішення: Виправте аутентифікацію проксі (якщо потрібно) або приберіть конфігурацію проксі. Не витрачайте час на вибір дзеркала чи перемикання IPv6.

Task 12: Neutralize apt proxy for a single run (safe diagnostic)

cr0x@server:~$ sudo apt -o Acquire::http::Proxy="" -o Acquire::https::Proxy="" update
Hit:1 https://deb.debian.org/debian trixie InRelease
Hit:2 https://security.debian.org/debian-security trixie-security InRelease
Reading package lists... Done

Значення: З вимкненими проксі apt успішно працює. Оце ваш курящий пістолет.

Рішення: Перейдіть до постійного очищення: приберіть директиви проксі та змінні середовища, потім верифікуйте.

Task 13: Confirm no stray wget proxy config

cr0x@server:~$ grep -nE 'use_proxy|http_proxy|https_proxy' ~/.wgetrc /etc/wgetrc 2>/dev/null
/etc/wgetrc:16:use_proxy = on
/etc/wgetrc:18:http_proxy = http://proxy.corp:3128/

Значення: wget використовуватиме проксі, навіть якщо ви почистили apt і curl-змінні. Конфігурації інструментів мають значення.

Рішення: Або видаліть/відключіть проксі в конфігу wget, або прийміть, що wget залишиться через проксі (та документуйте це).

Task 14: Validate trust store when a proxy intercepts TLS

cr0x@server:~$ openssl s_client -connect deb.debian.org:443 -servername deb.debian.org -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Peer certificate: CN = deb.debian.org
Verification: OK

Значення: Прямий TLS верифікується. Якщо той же запит через проксі дає помилки верифікації, ви маєте TLS-перехоплення і питання довіри.

Рішення: Не «виправляйте» це відключенням верифікації. Встановіть правильний корпоративний CA (якщо політика вимагає перехоплення) або обійдіть інтерсептуючий проксі.

Task 15: Catch no_proxy mismatches that force internal traffic through proxy

cr0x@server:~$ env | grep -i no_proxy
no_proxy=localhost,127.0.0.1,.corp,10.0.0.0/8

Значення: Хтось спробував використовувати CIDR у no_proxy. Багато інструментів не інтерпретують CIDR тут; вони очікують доменні суфікси або літеральні IP.

Рішення: Замініть CIDR на явні домени і ключові IP, що мають значення, і протестуйте під кожним клієнтом. Припускайте невідповідності, поки не доведено зворотне.

Task 16: Confirm what unattended-upgrades sees (service context)

cr0x@server:~$ systemctl cat unattended-upgrades.service
# /lib/systemd/system/unattended-upgrades.service
[Service]
Type=oneshot
ExecStart=/usr/bin/unattended-upgrade

cr0x@server:~$ systemctl show -p Environment unattended-upgrades.service
Environment=http_proxy=http://proxy.corp:3128 https_proxy=http://proxy.corp:3128 no_proxy=localhost,127.0.0.1,.corp

Значення: Служба має в оточенні змінні проксі (можливо через drop-in).

Рішення: Приберіть середовище на рівні юніта або додайте оверрайд, який очищає його, якщо ви хочете, щоб unattended-upgrades виходив напряму.

Стратегія очищення: видалити, нейтралізувати і зафіксувати

Очищення налаштувань проксі легко зробити неправильно. «Я видалив рядок» — це як отримати тиждень переривчастих збоїв, бо проксі з’являється з іншого шару.
Правильний підхід нудний: ідентифікуйте джерела, видаліть або звужуйте їх, потім доведіть, що середовище виконання чисте.

Step 1: Decide the policy for this host

Почніть з прямого питання: Чи має ця машина взагалі використовувати HTTP(S) проксі?

Ні: видаліть налаштування проксі всюди; також приберіть sudo env_keep; переконайтеся, що systemd default environment не містить проксі.
Так, глобально: централізуйте в одному місці (apt drop-in + systemd DefaultEnvironment) і документуйте; забезпечте правильну аутентифікацію й довіру CA.
Тільки для певних служб: ніколи не ставте /etc/environment або глобальні systemd defaults; використовуйте unit-specific drop-ins.

Step 2: Clean apt the right way

apt детермінований. Це хороша новина. Покладіть конфігурацію проксі в один явний файл, якщо вона потрібна, і видаліть усе інше.

Бажано: один файл, наприклад /etc/apt/apt.conf.d/02proxy (власник — конфігураційний менеджер).
Уникайте: розсипання Acquire-директив по різних drop-in з незрозумілим порядком.

Якщо ви видаляєте проксі, видаліть цей файл (або закоментуйте) і перевірте за допомогою apt-config dump.

Step 3: Clean environment injection

Якщо ви хочете систему без проксі, /etc/environment вам не друг. Це глобальний важіль і має звичку переживати причину свого створення.
Видаліть рядки проксі там і в профільних скриптах.

Потім розберіться з sudo. Якщо env_keep зберігає змінні проксі, ви будете постійно їх реінтегрувати в root-команди.

Step 4: Clean systemd’s global environment

Якщо systemctl show-environment містить змінні проксі, виправте корінь проблеми:

Видаліть DefaultEnvironment записи з systemd drop-ins, якщо вони не потрібні.
Скиньте змінні менеджера середовища і перезапустіть уражені служби (або перезавантажте для грубої гарантії).

Systemd дуже добре виконує те, що йому сказали. Це включає довге виконання помилок.

Step 5: Verify with tests that match your failure mode

Верифікація має включати:

env | grep -i proxy (користувацька оболонка)
sudo env | grep -i proxy (root через sudo)
systemctl show-environment | grep -i proxy (менеджер служб)
apt-config dump | grep -i proxy (вигляд apt)
curl -v (поведінка)

Жарт #2: Єдине більш наполегливе, ніж неправильно налаштований проксі — це тикет із проханням «тільки швидко змінити» перед святами.

Три корпоративні міні-історії з життя

Міні-історія 1: Інцидент через хибне припущення

Команда мігрувала флот серверів Debian з одного сегменту мережі в інший. Старий сегмент вимагав вихідного проксі.
Новий сегмент мав прямий egress зі суворими правилами фаєрвола і без проксі. Усі погодились: «Проксі більше не потрібно».

Вони прибрали проксі з CI-пайплайна і перестали передавати змінні http_proxy у білди. Тести здавались нормальними.
Потім, через два тижні, розгортання оновлення безпеки почало падати — але лише на підмножині хостів. Деякі оновилися, інші зависли, а кілька закидали логи помилками 407.

Хибне припущення: «Якщо цього немає в CI-змінних, то воно зникло». На проблемних хостах проксі був у /etc/apt/apt.conf.d/ від старого золотого образу.
Ці машини були створені місяці тому і ніколи не перевиправлені, лише патчені на місці. Ім’я проксі все ще резолвилось, але проксі тепер вимагав аутентифікації з іншої доменної зони.

Виправлення було смішно простим: видалити apt proxy drop-in, очистити застарілі рядки в /etc/environment і перестати зберігати проксі через sudo.
Урок: інвентаризуйте, звідки може походити конфігурація. Припущення не масштабуються, а Debian охоче зберігає старі інструкції назавжди.

Міні-історія 2: «Оптимізація», яка призвела до катастрофи

Інша організація хотіла швидших оновлень. Вони налаштували внутрішнє кешуюче проксі і направили весь трафік apt туди.
Здавалося, чиста оптимізація: менше трафіку, швидші інсталяції, менше тайм-аутів по WAN.

Перший місяць усе було чудово. Потім планове обслуговування проксі. Проксі з’явився з новою політикою TLS-перехоплення і ротацією корпоративного CA.
Браузери оновили довіру автоматично через керування пристроями. Сервери — ні.

Раптом apt почав падати з помилками верифікації сертифікатів. Хтось «вирішив» це, вимкнувши перевірку TLS в apt на короткий проміжок.
Той «короткий проміжок» тривав довше, ніж потрібно, бо помилки зникли і люди перейшли далі. Проксі залишався одною точкою відмови та прихованою залежністю довіри.

Коли аудит запитав, як забезпечується цілісність пакетів, відповідь була купою пояснень і паніки, щоб знову увімкнути перевірку й розгорнути оновлення CA правильно.
Оптимізація не була помилкою. Помилкою була недостатня операційна зрілість навколо неї.

Довготривале рішення: усунути TLS-перехоплення для трафіку до дзеркал Debian, де можливо, або керувати розповсюдженням CA як первинною залежністю.
Для продуктивності використовуйте локальні дзеркала або apt-кеші, що не вимагають MITM.

Міні-історія 3: Нудна практика, що врятувала день

Команда платформи мала нудну, але корисну звичку: кожен образ, запечений у продакшн, мав «network contract» файл, перевірений CI.
У ньому вказувалося, чи має хост використовувати проксі, і якщо так — де саме це налаштовано (apt drop-in, systemd unit overrides, керований CA bundle).

Під час міграції дата-центру партія VM Debian 13 раптом не могла встановлювати пакети в ізольованому staging VLAN.
Зовні інцидент виглядав драматично — оповіщення, провалені деплоя, затримка cutover — але всередині все було процедурно.

Вони запустили три команди: apt-config dump для директив проксі, systemctl show-environment для успадкованих змінних і curl -v --noproxy '*' для валідації прямого egress.
За кілька хвилин довели, що VLAN блокує прямий інтернет, і staging-підмережа за дизайном потребує проксі.

Врятувальна частина: їхні налаштування проксі не були розкидані.
Один apt drop-in і один systemd drop-in могли бути ввімкнені для цього середовища через менеджмент конфігурацій.
Ніяких ручних правок, ніякого гадання, ніякого «працює в моїй оболонці». Міграція пройшла з чистим документуванням.

Типові помилки: симптом → корінь проблеми → виправлення

Ось шаблони, які я найчастіше бачу в Debian-інфраструктурах. Найкраще — вони передбачувані.

1) apt падає з 407, curl падає з 407

Симптом: Proxy Authentication Required в apt і curl.

Корінь проблеми: Проксі налаштовано (змінні середовища або apt), але облікові дані відсутні/некоректні, або політика проксі змінилась.

Виправлення: Якщо проксі не повинен використовуватись — видаліть його з apt-конфіг і джерел середовища. Якщо повинен — використовуйте авторизований метод проксі, затестіть через curl -v.

2) curl працює, apt падає (або навпаки)

Симптом: Один інструмент працює, інший таймаутить або проксується.

Корінь проблеми: Різні джерела конфігурації: apt використовує /etc/apt/apt.conf.d; curl — змінні середовища або ~/.curlrc.

Виправлення: Порівняйте apt-config dump і env | grep -i proxy. Виправте шар, що відповідає за проблемний інструмент.

3) «Я видалив проксі, але служби все ще його використовують»

Симптом: Інтерактивні тести проходять; unattended-upgrades або демон все ще звертається через проксі.

Корінь проблеми: systemd manager environment або unit drop-ins досі визначають змінні проксі.

Виправлення: Перевірте systemctl show-environment і systemctl show -p Environment <unit>. Видаліть/переопишіть і перезапустіть службу (або перезавантажте для впевненості).

4) apt падає з TLS-помилками тільки коли присутній проксі

Симптом: certificate verify failed, іноді після зміни проксі.

Корінь проблеми: TLS-перехоплення вимагає корпоративного CA, який не встановлено в системному сховищі довіри.

Виправлення: Встановіть корпоративний CA в довірену крамницю Debian стандартним методом і перевірте через openssl s_client. Не вимикайте перевірку в apt як «тимчасове» рішення.

5) no_proxy «нічого не робить» для внутрішніх доменів

Симптом: Внутрішні кінцеві точки все ще йдуть через проксі, викликаючи затримки або помилки аутентифікації.

Корінь проблеми: Формат no_proxy не підходить (CIDR не підтримується, поведінка ведучої крапки відрізняється, порти ігноруються).

Виправлення: Використовуйте доменні суфікси і явні хости. Перевіряйте під кожним клієнтом за допомогою curl -v і точної URL, якою користується процес.

6) Все працює як користувач, але падає під sudo

Симптом: curl успішний; sudo curl використовує проксі і падає.

Корінь проблеми: sudoers зберігає змінні проксі (env_keep) або профілі root відрізняються.

Виправлення: Аудитуйте /etc/sudoers.d і стартові файли shell для root. Не зберігайте змінні проксі глобально, якщо немає політики, що вимагає цього.

Контрольні списки / покроковий план

Checklist A: 10-хвилинна тріаж-проба (інтерактивно)

Запустіть env | grep -i proxy. Якщо є — ідентифікуйте джерело (користувацькі/системні профілі).
Запустіть sudo env | grep -i proxy. Якщо відрізняється від користувача — перевірте sudoers env_keep.
Запустіть apt-config dump | grep -i proxy. Якщо є — знайдіть файл у /etc/apt/apt.conf.d.
Запустіть curl -v https://deb.debian.org/ -o /dev/null, щоб побачити, чи використовує він проксі.
Запустіть curl -v --noproxy '*' https://deb.debian.org/ -o /dev/null, щоб довести, що напряму працює.
Якщо служби падають, запустіть systemctl show-environment | grep -i proxy.

Checklist B: План видалення проксі (хост має бути прямим)

Видаліть або закоментуйте директиви apt proxy у знайденому файлі під /etc/apt/apt.conf.d/.
Приберіть рядки проксі з /etc/environment та будь-яких скриптів у /etc/profile.d, що їх встановлюють.
Видаліть правила sudoers, що зберігають змінні проксі, якщо вони не потрібні.
Видаліть systemd DefaultEnvironment проксі-налаштування (або обмежте їх конкретними юнітами).
Перезапустіть уражені служби; для масштабних змін заплануйте перезавантаження.
Повторно перевірте п’ять виводів: користувацьке середовище, sudo середовище, systemd environment, apt-config dump, поведінка curl -v.

Checklist C: Проксі потрібен, але зробіть його адекватним

Обирайте один авторитетний механізм конфігурації на область застосування:
- Для apt: один керований файл у /etc/apt/apt.conf.d/.
- Для служб: unit drop-ins з Environment= (не глобальні defaults, якщо не потрібно).
Ретельно визначіть no_proxy: включіть метадані, контрольні плейн-кластеру, внутрішні реєстри і localhost.
Якщо є TLS-перехоплення, керуйте розповсюдженням корпоративного CA і перевіряйте на хостах (не покладайтеся на браузери).
Документуйте відповідальність: хто змінює хост/порт/аутентифікацію проксі і як зміни розгортаються безпечно.

FAQ

1) Чому `apt update` використовує проксі, коли в моїй оболонці немає `http_proxy`?

Тому що apt може бути сконфігурований незалежно через /etc/apt/apt.conf і /etc/apt/apt.conf.d/*.
Перевірте через apt-config dump | grep -i proxy.

2) Чому `sudo apt update` поводиться інакше ніж `apt update`?

sudo може зберігати змінні проксі (env_keep), і root може мати інші стартові файли або середовище.
Порівняйте env | grep -i proxy та sudo env | grep -i proxy.

3) Де «головне» місце зберігання налаштувань проксі в Debian?

Одного такого місця немає. Для apt — це apt-конфіги; для багатьох CLI-інструментів — змінні середовища; для служб — systemd-середовище або unit overrides.
Саме тому очищення проксі — це пошук, якщо ви не стандартизували підхід.

4) Чи можна просто встановити `Acquire::https::Proxy "false";`?

Можна відключити проксі, встановивши порожні рядки для опцій проксі, або видаливши директиви. Для одноразового запуску використайте:
apt -o Acquire::https::Proxy="" -o Acquire::http::Proxy="" update.
Для постійної поведінки видаліть файл-джерело або керуйте ним явно.

5) Чому `no_proxy` не працює для CIDR-діапазонів?

Тому що підтримка відрізняється між клієнтами, і багато хто не парсить CIDR у no_proxy. Віддавайте перевагу явним доменам і іменам хостів.
Тестуйте з точним клієнтом і URL; не припускайте крос-платформенність.

6) Я видалив проксі, але unattended-upgrades все ще падають. Чому?

Unattended upgrades запускаються як служба. systemd може все ще надавати змінні проксі через менеджерське середовище або unit drop-ins.
Перевірте systemctl show-environment і systemctl show -p Environment unattended-upgrades.service.

7) apt падає з помилками сертифікатів тільки в корпоративних мережах. Це проблема проксі?

Часто це TLS-перехоплення. «Проксі» робить MITM і підмінює сертифікати, підписані корпоративним CA, якого немає в системному сховищі довіри Debian.
Виправте, встановивши корпоративний CA або обійшовши перехоплення для дзеркал Debian, якщо політика дозволяє.

8) Який найбезпечніший спосіб довести, що проксі — це причина, не змінюючи конфігурацію?

Для curl: запустіть curl -v --noproxy '*' і порівняйте поведінку.
Для apt: запустіть apt -o Acquire::http::Proxy="" -o Acquire::https::Proxy="" update.
Якщо це працює — ви ізолювали винуватця.

9) Чи зберігати облікові дані проксі в apt-конфіг файлах?

Уникайте, якщо можливо. Паролі легко опиняються доступними в багатьох місцях (резервні копії, логи, бандли підтримки).
Якщо організація вимагає аутентифікований проксі, використовуйте погоджений механізм розповсюдження секретів і скоротіть місця зберігання.

10) Як зупинити повернення налаштувань проксі?

Знайдіть автора змін: cloud-init, конфігураційний менеджер, скрипти запікання образу або інструменти відповідності. Прибравши лише «на сервері», ви отримаєте повторну появу при наступному прогоні.

Висновок: практичні кроки далі

Проблеми з проксі виглядають як мережеві, бо режим відмови — «не можна дістатись інтернету». Зазвичай це питання конфігурації, бо система виконує приховані інструкції.
Debian 13 дає набір чистих важелів — apt-конфіг, середовище, systemd — але також і достатньо мотузки, щоб наробити безладу.

Наступні кроки, які реально працюють у продакшні:

Запустіть швидкі діагностичні команди й вирішіть, чи має хост використовувати проксі взагалі.
Зробіть конфігурацію проксі єдиним джерелом та обмеженою за областю: один apt drop-in, unit-specific systemd env, без глобального /etc/environment, якщо це не необхідно.
Видаліть sudo env_keep для проксі на хостах, що мають бути прямими.
Доведіть виправлення не відчуттями, а виводами: apt-config dump, systemctl show-environment і curl -v з обхідним проксі та без нього.