Налаштування проксі для wget: всі способи, пріоритети та проблема SOCKS5

wget бере проксі з чотирьох джерел, і коли вони суперечать одне одному, він обирає одне з них без попередження. У цьому посібнику розглянуто всі чотири джерела, порядок їхнього пріоритету та те, що wget не вміє робити. Усе нижче перевірено на wget 1.25.0 30 вересня 2026 року через тестовий проксі, тому повідомлення про помилки справжні.

Коротка версія

# одна команда
https_proxy=http://login:password@proxy.example.com:10000 wget https://example.com/file.zip

# для всієї сесії оболонки
export http_proxy=http://login:password@proxy.example.com:10000
export https_proxy=http://login:password@proxy.example.com:10000
wget https://example.com/file.zip

Встановіть обидві змінні. http_proxy використовується для цілей http://, а https_proxy для https://, і зараз майже все працює через HTTPS. Сама адреса проксі в обох випадках починається з http://: це протокол, яким wget спілкується з проксі, а не протокол сайту.

Чотири джерела, де wget шукає проксі

1. Змінні оточення

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

2. Файл .wgetrc

Якщо машина або користувач завжди використовує один і той самий проксі, запишіть його в ~/.wgetrc:

use_proxy = on
http_proxy = http://login:password@proxy.example.com:10000
https_proxy = http://login:password@proxy.example.com:10000

Підійде будь-який файл, якщо вказати на нього змінною WGETRC. Так можна тримати окремі файли проксі для різних завдань.

3. Опція -e у командному рядку

-e встановлює команду .wgetrc для одного запуску:

wget -e use_proxy=yes -e https_proxy=http://login:password@proxy.example.com:10000 https://example.com/file.zip

4. --proxy-user та --proxy-password

Ці прапорці передають облікові дані окремо від адреси:

https_proxy=http://proxy.example.com:10000 wget --proxy-user=login --proxy-password='p@ss#word' https://example.com/file.zip

Це правильний вибір, коли пароль містить спецсимволи (причину розглянуто нижче).

Що перевизначає що

Ми встановили в чотирьох джерелах різні значення й перевірили, яке з них wget виконає:

Отже, .wgetrc на машині мовчки перемагає https_proxy, яку ви експортували для одного завдання, а прапорець --proxy-user мовчки замінює логін в адресі. Коли wget використовує неочікуваний проксі, зазвичай саме ці два правила винні.

Пастка зі спецсимволами

Наш тестовий пароль був p@ss#word. Коли ми вставили його в адресу як є, wget не дійшов до проксі:

Resolving ss... failed: nodename nor servname provided, or not known.
wget: unable to resolve host address 'ss'

Він прочитав перший @ як кінець логіна й спробував підключитися до хоста ss. Два виправлення, обидва перевірені:

# percent-кодування пароля всередині адреси
https_proxy=http://login:p%40ss%23word@proxy.example.com:10000 wget https://example.com/

# або передача окремо, кодування не потрібне
https_proxy=http://proxy.example.com:10000 wget --proxy-user=login --proxy-password='p@ss#word' https://example.com/

@ стає %40, # стає %23, : стає %3A, / стає %2F, а сам % стає %25.

Обхід проксі

Три способи, всі перевірені з проксі в оточенні, який би відхилив запит:

# ця команда йде напряму
wget --no-proxy https://example.com/

# ці хости завжди йдуть напряму
export no_proxy=example.com,internal.company.net
wget https://example.com/

# вимкнути проксі в .wgetrc або через -e
wget -e use_proxy=no https://example.com/

no_proxy - це список імен хостів або доменних суфіксів через кому. Він підходить для внутрішніх сервісів, які не повинні йти через проксі.

SOCKS5: те, чого wget не вміє

wget працює тільки з HTTP-проксі. Якщо подати йому адресу SOCKS, він одразу зупиниться:

Error parsing proxy URL socks5://127.0.0.1:1080: Unsupported scheme.

socks5h:// дає ту саму відповідь. Посібники, які показують рядок socks у .wgetrc, описують функцію, якої не існує. Є три виходи.

Використовуйте HTTP-порт проксі. Більшість платних проксі підтримують обидва протоколи. Наші відповідають на HTTP і SOCKS5 на одному резидентному порті й на окремих портах для статичних адрес, тому виправлення - це записати http:// замість socks5://.

Використовуйте curl замість wget. curl підтримує SOCKS5 нативно:

curl -x socks5h://login:password@proxy.example.com:1080 -O https://example.com/file.zip

Обгорніть wget у proxychains4, коли це обов'язково має бути wget (наприклад, усередині скрипта, який ви не можете змінити). Ми прогнали його через SOCKS5-сервер з логіном і паролем, і воно спрацювало:

sudo apt install -y proxychains4

cat > socks.conf <<'EOF'
strict_chain
proxy_dns
[ProxyList]
socks5 proxy.example.com 1080 login password
EOF
proxychains4 -q -f socks.conf wget https://example.com/file.zip
Параметр proxy_dns змушує імена хостів розв'язуватися через проксі, що вам і потрібно з причин, викладених у статті що таке DNS-проксі.
З'єднання з проксі не шифрується
Ще одне обмеження. Якщо ви вказуєте адресу проксі як https://, wget не встановлює TLS-з'єднання з проксі-сервером. У наших тестах він підключався звичайним текстом і надсилав запит точно так само, як зробив би це для проксі з http://. Тобто логін для проксі передається без шифрування між вами та проксі-сервером, яку б схему ви не вказали. У мережах, які ви не контролюєте, це вагомий аргумент на користь білого списку IP-адрес (якщо провайдер це підтримує) або клієнта, який уміє шифрувати з'єднання з проксі, як це робить curl.
Як читати помилки wget
wget каже
Що сталося
Proxy tunneling failed: Proxy Authentication Required, потім Unable to establish SSL connection.
Проксі повернув 407: неправильний логін, неправильний пароль або облікові дані взагалі не передано. Перелік перевірок є в гайді по 407
unable to resolve host address 'ss' або подібне
Символ у паролі поламав адресу. Закодуйте його або використайте --proxy-user
Error parsing proxy URL ...: Unsupported scheme.
SOCKS-адреса. wget не вміє з нею працювати
Connecting to 127.0.0.1:18499... failed: Connection refused.
Неправильний порт або проксі не працює
Завантаження працює, але з неправильного місця
Якесь інше джерело перевизначає ваше. Перевірте .wgetrc та -e
Ввічливе масове завантаження через проксі
Найважливіше налаштування, коли wget завантажує багато сторінок, це не проксі, а темп:
export https_proxy=http://login_c_US_s_7_ttl_1h:password@proxy.sotaproxy.com:10000

wget --mirror --no-parent --wait=2 --random-wait --limit-rate=500k \
     --user-agent="my-mirror/1.0 (+mailto:you@example.com)" \
     https://example.com/docs/
Параметри --wait і --random-wait розносять запити в часі, --limit-rate обмежує пропускну здатність, а wget за замовчуванням дотримується robots.txt під час рекурсивного завантаження. Суфікс сесії в логіні прив'язує всі запити дзеркалювання до однієї вихідної адреси протягом години, тож сайт бачить одного відвідувача, а не натовп. Синтаксис суфіксів описано в довіднику рядків підключення.
Поширені питання
Як змусити wget використовувати проксі?
Встановіть у середовищі http_proxy та https_proxy зі значенням http://login:password@host:port, або додайте ті самі рядки в ~/.wgetrc разом з use_proxy = on.
Як змусити wget ігнорувати проксі?
wget --no-proxy для однієї команди, no_proxy=host1,host2 у середовищі для конкретних хостів або -e use_proxy=no.
Чи підтримує wget SOCKS5?
Ні. Він відхиляє адресу з повідомленням "Unsupported scheme". Використовуйте HTTP-порт проксі, curl або обгорніть wget у proxychains4.
Чому wget каже "unable to resolve host address", коли я встановлюю проксі?
Символ у паролі, зазвичай @, розрізав адресу не в тому місці. Закодуйте пароль через percent-encoding або передайте його через --proxy-user і --proxy-password.
Що має пріоритет: змінна середовища чи .wgetrc?
.wgetrc. А -e у командному рядку перевершує обидва.