Как настроить прокси в 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. Оба исправления проверены:

# кодирование пароля процентами внутри адреса
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 на одном и том же порту для резидентных адресов и на разных портах для статических, так что исправление сводится к замене socks5:// на http://.

Использовать 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-запросы идти через прокси, а это именно то, что вам нужно по причинам, описанным в статье что такое 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. Суффикс сессии в логине удерживает все запросы зеркала в течение часа на одном выходном адресе, и сайт видит одного посетителя, а не толпу. Синтаксис суффиксов описан в справке по строке подключения.
FAQ
Как заставить 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", когда я задаю прокси?
Какой-то символ в пароле, обычно @, разрезал адрес не в том месте. Закодируйте пароль в процентной нотации или передайте через --proxy-user и --proxy-password.
Что важнее, переменная окружения или .wgetrc?
.wgetrc. А -e в командной строке бьёт обоих.