Как использовать Wget через прокси и не попасться на типичные ловушки

Настройка прокси в Wget выглядит как дело на пять секунд — пока вы не проведёте час, пытаясь понять, почему запросы вообще не идут через прокси и при этом не появляется ни одной ошибки. Я видел это и у опытных системных администраторов, и у начинающих разработчиков.

Проблема почти никогда не в самом прокси. Причина — в четырёх разных местах, откуда Wget может брать настройки, в тихих сбоях при неправильном регистре переменных и в корпоративных особенностях сети, которые никто не удосуживается нормально объяснить в man-странице. В этом руководстве разобраны все способы настройки Wget через прокси, точные правила приоритета, если методы конфликтуют, реальный вывод терминала для самых частых ошибок, а также отдельный раздел для пользователей Windows и корпоративных сетей — то есть для аудитории, о которой почти все другие статьи будто бы забывают.

• Сложность: от начального до среднего уровня
• Время на чтение и настройку: примерно 15 минут; после этого — около 2 минут, когда уже понимаешь, что делать
• Что понадобится: установленный Wget (инструкция ниже), адрес прокси (хост + порт) и, при необходимости, учётные данные для авторизации

Попробуйте Thunderbit для структурированного извлечения данных

Что такое Wget и зачем использовать его через прокси?

Wget — это консольная утилита, которая скачивает файлы и веб-страницы из интернета без браузера. В официальном описании GNU она называется «сетевой загрузчик без интерактивного режима» — то есть она работает в фоне, умеет возобновлять прерванные загрузки и поддерживает рекурсивное скачивание без участия человека.

В этом контексте прокси — это промежуточный сервер. Вместо прямого соединения с целевым сайтом ваша машина отправляет запрос на прокси, а тот уже пересылает его дальше. Обычно это нужно по таким причинам:

• Требования корпоративного файрвола — весь исходящий трафик должен идти через одобренный прокси
• Приватность и управление IP — сайт видит IP прокси, а не ваш
• Тестирование географии — доступ к ресурсам с региональными ограничениями или проверка работы CDN из конкретного региона
• Пайплайны сбора данных — скачивание HTML через ротацию прокси для исследований или мониторинга
• CI/CD-среды — сборочные агенты в закрытых сетях, которые могут выходить в интернет только через прокси

Wget нативно поддерживает прокси для HTTP, HTTPS и FTP. SOCKS5 он не поддерживает. Если нужен SOCKS5, curl умеет это из коробки через схемы socks4://, socks5:// и socks5h:// — либо можно запустить Wget через обёртку вроде proxychains4.

Как установить Wget в Linux, macOS и Windows

Прежде чем настраивать прокси, нужно установить Wget. Этот раздел короткий — это просто необходимый шаг, а не основная тема.

Linux (Debian/Ubuntu и RHEL/CentOS)

# Debian/Ubuntu
sudo apt update
sudo apt install wget

# RHEL/CentOS/Fedora
sudo dnf install wget

# Проверка
wget --version

В Ubuntu 24.04 LTS поставляется Wget 1.21.4, а в Debian Trixie — 1.25.0. Пакеты CentOS Stream 10 показывают версию 1.24.5.

macOS (Homebrew)

brew install wget
wget --version

Формула Homebrew сейчас предлагает стабильный Wget 1.25.0, а за последний год его установили 396,818 раз.

Windows (Chocolatey и ручная установка)

choco install wget
wget --version

Пакет GNU Wget в Chocolatey сообщает о более чем 10 миллионах загрузок, хотя текущая версия — 1.21.4. Обычно бинарник находится по пути C:\ProgramData\chocolatey\bin\wget.exe.

Небольшое предупреждение для пользователей Windows: где именно Wget ищет .wgetrc, зависит от сборки. Подробности — в разделе про Windows ниже.

4 способа использовать Wget через прокси и какой выбрать

Есть четыре метода, и у каждого свой охват и свой уровень приоритета:

1. Флаги -e в командной строке — разовая настройка для одной команды
2. Файл настроек пользователя (~/.wgetrc) — применяется ко всем командам Wget этого пользователя
3. Системный конфиг (/etc/wgetrc) — действует для всех пользователей на машине
4. Переменные окружения (http_proxy, https_proxy) — работают во всей текущей сессии shell

Способ 1: флаги командной строки — разовый прокси

Лучший вариант для быстрых проверок. Настройки исчезают после завершения команды.

wget -e use_proxy=on -e http_proxy=http://HOST:PORT/ http://example.com/file.zip

Для HTTPS-целей:

wget -e use_proxy=on -e https_proxy=http://HOST:PORT/ https://example.com/

Быстрая проверка — узнать свой видимый IP через прокси:

wget -qO- -e use_proxy=on -e http_proxy=http://HOST:PORT/ http://ifconfig.me

Если в выводе отображается IP прокси, а не ваш, всё работает.

Способ 2: файл настроек пользователя (~/.wgetrc)

Добавьте такие строки в ~/.wgetrc (создайте файл, если его ещё нет):

use_proxy = on
http_proxy = http://proxy.company.com:8080/
https_proxy = http://proxy.company.com:8080/
no_proxy = localhost,127.0.0.1,.internal.company.com

Обратите внимание на пробелы вокруг = — именно такой синтаксис описан в документации .wgetrc. После этого все команды Wget, запущенные от этого пользователя, будут идти через прокси.

Способ 3: системный конфиг (/etc/wgetrc)

Те же директивы, что и в ~/.wgetrc, но размещённые в системном файле конфигурации. GNU описывает его как глобальный стартовый файл — точный путь зависит от того, куда установлен пакет. Часто встречаются такие варианты:

• /etc/wgetrc (в большинстве Linux-пакетов)
• /usr/local/etc/wgetrc (в некоторых сборках Homebrew)
• Путь, указанный в выводе wget --version рядом с Wgetrc:

Это удобно для общих серверов, Docker-контейнеров и любых сред, где всем пользователям нужен один и тот же прокси.

Способ 4: переменные окружения (http_proxy / https_proxy)

export http_proxy=http://HOST:PORT/
export https_proxy=http://HOST:PORT/
export no_proxy=localhost,127.0.0.1,.internal.company.com

Они влияют на всю вашу shell-сессию, а не только на Wget. Их также подхватят, например, curl и другие утилиты.

Важное предупреждение: Wget читает переменные окружения только в нижнем регистре. HTTP_PROXY в верхнем регистре просто игнорируется. Без ошибки, без предупреждения, вообще без какого-либо сигнала. Ниже я покажу точный вывод терминала, но это стоит запомнить уже сейчас.

Приоритет методов прокси: что перекрывает что, если задано сразу несколько вариантов

Если прокси указан и в переменных окружения, и в .wgetrc, и в командной строке — какой вариант победит? В документации это редко объясняют чётко, поэтому я проверил сам.

Вот протестированный и документированный порядок приоритета:

Приоритет	Метод	Область действия	Что перекрывает
1 (высший)	Флаги CLI -e	Одна команда	Всё
2	~/.wgetrc	Текущий пользователь	Системный конфиг + переменные окружения
3	/etc/wgetrc	Для всей системы	Только переменные окружения
4 (низший)	Переменные окружения http_proxy / https_proxy	Сессия shell	Ничего

Я проверил это на Wget 1.25.0, задавая конфликтующие прокси на каждом уровне. Когда в окружении был порт 3128, в конфиге — 3129, а в CLI — 3130:

• Конфиг сильнее окружения: Wget подключался к порту 3129, игнорируя 3128.
• CLI сильнее конфига: Wget подключался к порту 3130, игнорируя и 3129, и 3128.

Спасательный вариант — --no-proxy. Он игнорирует вообще все настройки прокси, независимо от того, где они заданы:

wget --no-proxy https://internal-server.company.com/report.pdf

Практический пример: ваш системный администратор прописал прокси в /etc/wgetrc, а вам нужно напрямую обратиться к внутреннему серверу. Используйте --no-proxy только для этой команды вместо редактирования системного конфига.

Как использовать Wget через прокси с авторизацией

Большинство коммерческих и домашних прокси требуют логин и пароль. Wget поддерживает это двумя способами, оба используют HTTP Basic authentication для учётных данных прокси.

Учётные данные прямо в URL прокси

wget -e use_proxy=on \
  -e http_proxy=http://USERNAME:PASSWORD@proxy.company.com:8080/ \
  http://example.com/file.zip

Это работает и в .wgetrc:

http_proxy = http://USERNAME:PASSWORD@proxy.company.com:8080/
https_proxy = http://USERNAME:PASSWORD@proxy.company.com:8080/

Использование флагов --proxy-user и --proxy-password

wget --proxy-user=USERNAME --proxy-password=PASSWORD \
  -e use_proxy=on \
  -e http_proxy=http://proxy.company.com:8080/ \
  http://example.com/file.zip

Эти флаги перекрывают любые user:pass@, встроенные в URL прокси.

Как не засветить учётные данные

Оба варианта могут раскрыть пароль. GNU предупреждает, что пароль в командной строке виден через ps и аналогичные инструменты просмотра процессов. Что можно сделать:

• Однопользовательские машины: храните учётные данные в ~/.wgetrc и ограничьте доступ к файлу: chmod 600 ~/.wgetrc
• CI/CD-пайплайны: используйте зашифрованные secrets в GitHub Actions или аналогичный механизм вашей платформы. Передавайте их как переменные окружения в нижнем регистре в определении шага — не вшивайте значения в YAML
• Docker-сборки: не используйте ARG или ENV для секретов. В документации Docker прямо сказано, что build arguments могут попасть в финальный образ. Вместо этого используйте secret mounts BuildKit
• Контроль версий: никогда не коммитьте .wgetrc с паролями. Добавьте его в .gitignore

Ещё один нюанс Wget для GitHub Actions: секреты обычно хранятся в верхнем регистре, но переменные окружения, которые вы передаёте Wget, должны быть в нижнем регистре (http_proxy, а не HTTP_PROXY).

Как использовать Wget через прокси в Windows и в корпоративной сети

Большинство статей заканчиваются на фразе «установите через Chocolatey». Если вы на Windows или за корпоративным прокси, именно там проблемы только начинаются.

Где Windows ищет .wgetrc

Документация GNU говорит, что Wget читает $HOME/.wgetrc, если только переменная WGETRC не указывает на другой файл. В Windows $HOME может соответствовать %USERPROFILE% (например, C:\Users\alice), а может и нет — это зависит от того, используете ли вы сборку Chocolatey, MSYS2, Git Bash или отдельный бинарник.

Моя рекомендация: не гадать, а использовать флаг --config, чтобы поведение было предсказуемым:

wget --config=C:\Users\alice\wgetrc https://example.com/file.zip

Чтобы проверить, читает ли ваша сборка конфиг из конкретного места, создайте тестовый файл с заведомо неверным прокси:

; C:\Users\alice\wget-test.rc
use_proxy = on
http_proxy = http://127.0.0.1:3128/

Затем выполните:

wget --config=C:\Users\alice\wget-test.rc --spider http://example.com/

Если Wget попытается подключиться к 127.0.0.1:3128, значит файл был прочитан.

Как задать переменные прокси в Windows

CMD (только для текущей сессии):

set http_proxy=http://HOST:PORT/
set https_proxy=http://HOST:PORT/
wget http://example.com/

PowerShell (только для текущей сессии):

$env:http_proxy = "http://HOST:PORT/"
$env:https_proxy = "http://HOST:PORT/"
wget http://example.com/

Постоянно (переживает перезагрузку):

setx http_proxy http://HOST:PORT/
setx https_proxy http://HOST:PORT/

После setx нужно открыть новое окно терминала. Текущая сессия изменения не увидит.

Типичные ловушки корпоративного прокси: PAC-файлы, NTLM и поиск адреса прокси

Есть три вещи, на которых корпоративные пользователи спотыкаются чаще всего:

PAC-файлы: во многих компаниях используют Proxy Auto-Configuration (PAC) — JavaScript-скрипты, которые говорят браузеру, какой прокси использовать для каждого URL. У Wget нет JavaScript-движка, поэтому он не умеет читать PAC-файлы. В документации curl сказано то же самое. Обходной путь: открыть PAC-файл (или спросить у IT), найти результат PROXY host:port для нужного домена и прописать этот статический адрес в Wget.

Аутентификация NTLM: прокси-аутентификация Wget поддерживает только Basic auth. Если корпоративный прокси требует NTLM и вы видите 407 Proxy Authentication Required, не тратьте время на перебор вариантов --proxy-user. Установите Cntlm — локальный ретранслятор, который обрабатывает NTLM/NTLMv2 и выдаёт Wget интерфейс Basic-auth. Cntlm всё ещё поддерживается (последнее обновление — октябрь 2025, около 395 загрузок в неделю).

Дерево решений для корпоративного прокси:

1. Попробуйте set http_proxy=http://YOUR_PROXY:PORT/ и запустите Wget.
2. Если получаете ошибку 407, а в компании используется NTLM → установите Cntlm, настройте его с учётными данными домена и укажите Wget локальный порт Cntlm (обычно http://127.0.0.1:3128/).
3. Если компания использует PAC-файл → извлеките реальный PROXY host:port из PAC-файла или попросите IT дать статический адрес прокси.

Типичные корпоративные порты прокси: 3128 (в стиле Squid), 8080 (общий HTTP-прокси), 8888 (отладочные прокси вроде Fiddler/Charles). Это не правило, а лишь распространённые соглашения.

Частые ловушки при использовании Wget через прокси с реальными ошибками

А теперь — та самая часть, ради которой и написан заголовок. Все приведённые ниже примеры воспроизведены на Wget 1.25.0 (macOS, Homebrew) 2026-06-01.

Ловушка 1: отсутствует префикс http://

Некоторые старые инструкции утверждают, что это всегда ломает работу. В Wget 1.25.0 значение http_proxy=127.0.0.1:3128 на самом деле работает — Wget молча добавляет http://:

Prepended http:// to '127.0.0.1:3128'
Spider mode enabled. Check if remote file exists.
--2026-06-01 10:38:15--  http://example.com/
Connecting to 127.0.0.1:3128... failed: Operation not permitted.

То есть он всё равно подключается к нужному прокси. Но я всё же советую всегда явно указывать префикс http:// и завершающий слэш. Так меньше двусмысленности между версиями Wget, а синтаксис с учётными данными (http://user:pass@host:port/) становится однозначным.

Ловушка 2: use_proxy=yes против use_proxy=on

В моих тестах Wget 1.25.0 принимал и yes, и on. Но некорректные значения вызывают понятную ошибку:

wget: use_proxy: Invalid boolean 'true'; use `on' or `off'.

Для максимальной совместимости используйте on — это соответствует формату булевых значений, описанному в руководстве, и подсказке самого Wget.

Ловушка 3: HTTP_PROXY в верхнем регистре тихо игнорируется

Это самая раздражающая проблема, потому что ошибки здесь нет вообще. Wget просто подключается напрямую, как будто прокси вы не задавали.

Верхний регистр (не работает — прокси не используется):

HTTP_PROXY=http://127.0.0.1:3128/ wget --no-config --spider http://example.com/

Spider mode enabled. Check if remote file exists.
--2026-06-01 10:40:06--  http://example.com/
Resolving example.com (example.com)... 198.18.58.61
Connecting to example.com (example.com)|198.18.58.61|:80... connected.
HTTP request sent, awaiting response... 200 OK

Нижний регистр (работает — попытка подключения к прокси есть):

http_proxy=http://127.0.0.1:3128/ wget --no-config --spider http://example.com/

Spider mode enabled. Check if remote file exists.
--2026-06-01 10:40:16--  http://example.com/
Connecting to 127.0.0.1:3128... failed: Connection refused.

Видите разницу? Вариант с верхним регистром резолвит example.com напрямую. Вариант с нижним регистром пытается идти через прокси. Предупреждений нет ни в одном случае. У curl есть похожая особенность — он принимает верхний регистр для большинства proxy-переменных, но специально отклоняет HTTP_PROXY из соображений безопасности.

Исправление: всегда используйте http_proxy и https_proxy в нижнем регистре.

Ловушка 4: устаревший прокси в .wgetrc вызывает "Connection refused"

Если вы (или ваш системный администратор, или Docker-образ) оставили старый адрес прокси в конфиге, вы увидите что-то вроде этого:

Spider mode enabled. Check if remote file exists.
--2026-06-01 10:39:10--  http://example.com/
Connecting to 127.0.0.1:3128... failed: Connection refused.

Ошибка указывает на старый IP прокси, а не на целевой сайт. Порядок диагностики лучше строить по иерархии приоритета:

1. Проверьте команду на наличие флагов -e или shell-алиасов
2. Проверьте ~/.wgetrc (или файл, указанный через WGETRC)
3. Проверьте системный конфиг (путь указан в wget --version)
4. Проверьте окружение: env | grep -i proxy

Для отладки --no-config — ваш лучший друг: он заставляет Wget пропустить все конфигурационные файлы:

wget --no-config --spider http://example.com/

Если так всё заработало, значит проблема в одном из конфигов.

Ловушка 5: путаница в синтаксисе HTTPS-прокси

Это часто сбивает людей с толку. Когда вы задаёте https_proxy, сам URL прокси обычно всё равно начинается с http://, а не с https://. Причина в том, что Wget отправляет через прокси HTTP CONNECT-запрос, чтобы создать туннель для зашифрованной HTTPS-сессии.

Правильно:

https_proxy=http://proxy.company.com:8080/
wget https://example.com/

Wget отправляет на прокси CONNECT example.com:443 HTTP/1.1, а затем проксирует HTTPS через туннель.

Неправильно (для HTTP-target URL с HTTPS-эндпоинтом прокси):

http_proxy=https://127.0.0.1:18082/
wget http://example.com/

Error in proxy URL https://127.0.0.1:18082/: Must be HTTP.

Wget 1.25.0 вообще не принимает https:// как URL прокси для HTTP-целей. Используйте https_proxy=http://HOST:PORT/, если только в вашей организации не задокументирован именно HTTPS-эндпоинт прокси и вы не проверили его на своей сборке Wget.

Шпаргалка по командам Wget для прокси

Добавьте эту таблицу в закладки. Здесь собраны все флаги и директивы Wget, связанные с прокси, в одном месте.

Флаг / директива	Контекст	Пример	Примечания
-e use_proxy=on	CLI	-e use_proxy=on	on — самый безопасный вариант; некоторые сборки также принимают yes
-e http_proxy=	CLI	-e http_proxy=http://proxy:8080/	Обязательно указывайте префикс http:// и завершающий /
-e https_proxy=	CLI	-e https_proxy=http://proxy:8080/	URL прокси обычно остаётся http://, даже для HTTPS-целей
--proxy-user	CLI	--proxy-user=admin	Перекрывает встроенный user:pass@
--proxy-password	CLI	--proxy-password=secret	Видно в ps — не используйте на общих системах
--no-proxy	CLI	--no-proxy	Полностью игнорирует ВСЕ прокси-настройки из любых источников
--no-config	CLI	--no-config	Пропускает все конфиги — полезно для диагностики
--config=FILE	CLI	--config=/tmp/wgetrc	Предсказуемый путь к конфигу — удобно для Windows и CI
http_proxy	.wgetrc / env	http_proxy = http://proxy:8080/	В файле конфигурации вокруг = нужны пробелы; в переменной окружения — нижний регистр
https_proxy	.wgetrc / env	https_proxy = http://proxy:8080/	Такой же формат, как у http_proxy
ftp_proxy	.wgetrc / env	ftp_proxy = http://proxy:8080/	Для загрузок по FTP
no_proxy	.wgetrc / env	no_proxy = localhost,127.0.0.1,.corp	Список доменов через запятую
proxy_user	.wgetrc	proxy_user = admin	Аналогично --proxy-user
proxy_password	.wgetrc	proxy_password = secret	Защитите файл через chmod 600

Когда Wget + прокси — не лучший выбор и что использовать вместо него

После всей этой настройки прокси вот контраргумент: иногда лучше вообще не возиться с Wget.

Многие, кто ищет «wget proxy», на самом деле не хотят просто скачать один файл. Им нужно собрать структурированные данные с сайтов — цены товаров, списки контактов, объявления недвижимости — и они по умолчанию берут Wget, потому что это знакомая консольная утилита. Проблема в том, что Wget даёт вам сырой HTML. Его всё равно нужно разобрать, очистить и превратить в структуру. А если ещё и прокси ротируются, чтобы не ловить блокировки, у вас уже не один инструмент, а целый набор: список прокси, скрипт загрузки, парсер и экспортный пайплайн.

Ваша задача	Лучший инструмент	Почему
Скачать один файл через прокси	wget с флагами прокси	Просто и в одну команду
Зеркалировать сайт или каталог через прокси	wget --recursive + настройка прокси	Рекурсивное скачивание — сильная сторона Wget
Собирать структурированные данные (таблицы, каталоги, контакты)	Thunderbit	Wget даёт только сырой HTML — его ещё нужно парсить. Thunderbit с помощью AI читает страницу и сразу выдаёт структурированные данные в Excel, Google Sheets, Airtable или Notion без кода. Облачный сбор данных сам справляется с ротацией IP и антибот-защитой, так что настройка прокси не нужна.
Делать запросы к REST API через прокси	curl	Лучше контроль заголовков, нативная поддержка JSON, поддержка SOCKS5
Регулярно и по расписанию собирать данные	Thunderbit Scheduled Scraper или cron + wget	Thunderbit адаптируется, если меняется структура страницы; скрипты на cron + wget ломаются молча

Wget отлично подходит для загрузки файлов. Но цепочка «настроить прокси → ротировать IP → скачать HTML → написать парсер → выгрузить в таблицу» содержит слишком много звеньев, если вам на самом деле нужна просто таблица данных. Если это ваш случай, наше расширение для Chrome делает весь процесс за два клика. Подробнее об этом подходе читайте в наших материалах про AI web scraping и веб-скрапинг без программирования.

Но если ваша цель — «скачать этот ZIP-файл через корпоративный прокси», Wget по-прежнему правильный инструмент, и теперь вы знаете, как настроить его без ошибок.

Основные выводы

Кратко:

• Четыре способа и понятный приоритет: флаги CLI перекрывают пользовательский конфиг, который перекрывает системный конфиг, который перекрывает переменные окружения. --no-proxy перекрывает всё.
• Всегда используйте нижний регистр для переменных окружения (http_proxy, а не HTTP_PROXY). Верхний регистр Wget молча игнорирует.
• Всегда указывайте http:// в URL прокси, даже для https_proxy. Эндпоинт прокси — HTTP, а HTTPS он туннелирует через CONNECT.
• Для булевых значений используйте on в .wgetrc и флагах -e. Это самый безопасный вариант для разных версий Wget.
• Пользователи Windows: используйте --config=C:\path\to\wgetrc, чтобы избежать неоднозначности с файлом конфигурации. Для переменных прокси в текущей сессии используйте set в CMD или $env: в PowerShell.
• Пользователи корпоративных прокси: Wget не умеет читать PAC-файлы и нативно не поддерживает NTLM. При необходимости используйте Cntlm как локальный ретранслятор.
• Сохраните шпаргалку выше — она избавит вас от повторного чтения статьи каждый раз, когда нужно вспомнить название флага.

Если ваша настоящая цель — извлечение структурированных данных, Thunderbit или curl могут подойти лучше. Самая удачная отладка — та, которую вам вообще не пришлось начинать.

Часто задаваемые вопросы

1. Поддерживает ли Wget прокси SOCKS5?

Нет. GNU Wget 1.x поддерживает только прокси HTTP, HTTPS и FTP. В проекте Wget2 поддержка SOCKS5 запрашивалась, но это не стандартная документированная опция. Для SOCKS5 используйте curl с нативными схемами socks5:// или socks5h://, либо запускайте Wget через proxychains4, чтобы принудительно направлять трафик через SOCKS.

2. Почему мои настройки прокси игнорируются, если я использую HTTP_PROXY в верхнем регистре?

Wget читает только переменные окружения в нижнем регистре (http_proxy, https_proxy, ftp_proxy, no_proxy). Варианты в верхнем регистре, такие как HTTP_PROXY, просто игнорируются — без ошибки и без предупреждения. Это одна из самых частых и раздражающих проблем, потому что внешне всё выглядит как будто нормально. Всегда используйте нижний регистр.

3. Как обойти прокси для отдельных доменов?

Используйте директиву no_proxy, либо как переменную окружения, либо в .wgetrc:

export no_proxy=localhost,127.0.0.1,.mycompany.com

Или в ~/.wgetrc:

no_proxy = localhost,127.0.0.1,.mycompany.com

Домены перечисляются через запятую. Точка в начале (.mycompany.com) захватывает все поддомены.

4. Можно ли использовать Wget с ротирующимися прокси?

У самого Wget нет встроенной ротации прокси. Есть два варианта: использовать провайдера прокси, который ротирует IP на своей стороне (тогда вы всегда подключаетесь к одному шлюзу, а внешний IP меняется), либо написать shell-скрипт, который выбирает случайный прокси из списка и передаёт его через -e http_proxy=... при каждом запуске. Для более сложных сценариев — автоматической ротации, ретраев, обхода антибот-защиты — обычно лучше взять специализированный инструмент для скрапинга.

5. В чём разница между http_proxy и https_proxy в Wget?

http_proxy используется, когда целевой URL начинается с http://. https_proxy — когда целевой URL начинается с https://. В обоих случаях сам URL прокси обычно тоже начинается с http://. Для HTTPS-целей Wget отправляет через прокси HTTP CONNECT-запрос, чтобы создать туннель, а настоящее шифрование HTTPS происходит напрямую между Wget и целевым сервером. Прокси видит имя хоста из CONNECT-запроса, но не может прочитать зашифрованный трафик.

Попробуйте Thunderbit для AI веб-скрапинга Get Started Free

Узнать больше

• Лучшие автоматизированные инструменты для веб-скрапинга
• Как получить данные с сайта с помощью Python
• Лучшие сервисы для веб-скрапинга
• Как делать веб-скрапинг без блокировок
• Как настроить сервер прокси