Как настроить прокси в Splash в 2026 году - поэтапное руководство
Суть
Splash маршрутизирует прокси через один HTTP-параметр, proxy, который принимает либо URL прокси, либо имя профиля. Формат URL — [протокол://][пользователь:пароль@]хост[:порт], при этом http или socks5 являются протоколом, а порт 1080 — значением по умолчанию, если не указано.
Именованные профили прокси требуют запуска Splash с --proxy-profiles-path и указания на папку с файлами .ini; профиль default.ini автоматически применяется ко всем запросам, если запрос явно не передает proxy=none.
Секция [proxy] каждого профиля содержит host, port, необязательные username/password и type (HTTP или SOCKS5), в то время как секция [rules] ограничивает прокси, соответствующие URL-адресам, с помощью регулярных выражений allowlist/denylist.
Попробуйте Nstproxy - Начните бесплатный тест сегодня
Для логики прокси на уровне запроса или ресурса Lua API Splash предоставляет request:set_proxy{host, port, username, password, type} внутри обратного вызова splash:on_request, который выполняется перед отправкой запроса и может назначать разные прокси для разных типов ресурсов на одной странице.
scrapy-splash передает HTTP-параметры Splash без изменений, так что словарь args для SplashRequest может содержать proxy так же, как это делает вызов render.html`.
Поставщик вращающегося прокси, такой как Nstproxy, может быть подключен любым из трех вышеуказанных методов — прямой URL, профиль .ini или Lua set_proxy — поскольку Splash рассматривает прокси как обычный host:port плюс необязательные учетные данные, независимо от того, кто их выдает.
Введение: маршрутизация трафика через Splash без потери нити
Splash — это безголовый, скриптуемый браузерный рендеринг-сервис от Scrapinghub/Zyte, чаще всего доступный через свой HTTP API или через интеграцию scrapy-splash. Он рендерит страницы с тяжелым JavaScript и возвращает HTML, PNG, JSON или HAR, но по умолчанию каждый запрос рендеринга покидает хост Splash с помощью собственного исходящего IP. Сайты, использующие отпечатки по IP, блокирующие по ASN или ограничивающие по исходному адресу, будут обрабатывать каждый запрос одинаково, независимо от того, сколько разных целевых страниц посещает скрейпер — пока между Splash и целевым сайтом не будет сидеть прокси.
Splash предоставляет три отдельных способа вставки этого прокси: один параметр запроса proxy для одноразовых или вручную вращаемых прокси, папка .ini с параметром --proxy-profiles-path для повторно используемых именованных профилей и вызов Lua request:set_proxy для управления на уровне запроса или типа ресурса. Этот гид проходит через все три метода, а также через необходимую проводку scrapy-splash, чтобы передать значение proxy из паука Scrapy, и заканчивается тем, как подключить вращающийся пул жилых прокси к любому из трех методов.
Предварительные требования
Запущенный экземпляр Splash — примеры ниже используют официальный Docker-образ scrapinghub/splash, поскольку собственные документы по установке Splash рекомендуют Docker вместо локальной установки Python для большинства настроек. Исходный код и трекер проблем Splash находятся в репозитории scrapinghub/splash на GitHub.
Docker установлен локально (или на удаленном хосте, к которому можно получить доступ на порту 8050).
Учетные данные прокси от поставщика — хост, порт и (если требуется) имя пользователя/пароль. Реальные учетные данные никогда не печатаются в этой статье; каждый пример использует заполнители, такие как YOUR_PROXY_HOST и YOUR_PROXY_PASSWORD.
Установлены scrapy и scrapy-splash (pip install scrapy scrapy-splash) только для разделов, которые используют Scrapy.
Ни одна из команд ниже не была выполнена против работающего контейнера Splash в окружении, которое произвело эту статью — Docker runtime не был доступен. Каждое имя команды и параметра проверено по документации и исходным данным Splash (splash.readthedocs.io, github.com/scrapinghub/splash), а не придумано, и каждый блок кода помечен как иллюстративный или только для конфигурации ниже.
Установка и запуск Splash
Запустите Splash так, как рекомендует его собственная документация, сопоставляя порт API с хостом. Эта команда соответствует задокументированному синтаксису; она не выполнялась непосредственно в этой среде (Docker runtime не был доступен), поэтому воспринимайте ее как иллюстративную:
docker run -it-p8050:8050 --rm scrapinghub/splash
API становится доступным по адресу http://localhost:8050. Подтвердите, что он отвечает, прежде чем подключать прокси:
Как только Splash может напрямую достичь целевого сайта, следующий режим сбоя обычно заключается в том, что целевой сайт блокирует собственный IP Splash — ротационный жилой пул, такой как прокси Residential Lite от Nstproxy, предоставляет Splash новый исходящий IP для каждой сессии вместо одного статического адреса, который каждый сайт может отметить.
Самый быстрый способ маршрутизировать один вызов рендеринга через прокси — это аргумент запроса proxy в Splash, доступный на render.html, render.png, render.json, execute и других конечных точках рендеринга. Он принимает URL прокси в формате [protocol://][user:password@]proxyhost[:port], где протокол — это http или socks5, а порт по умолчанию равен 1080, если он не указан:
Это правильный инструмент, когда сценарий собирает URL прокси во время запроса — например, получая свежую конечную точку с ротацией сессий от провайдера перед каждым вызовом Splash. Это не тот инструмент, когда один и тот же прокси должен применяться автоматически ко всем запросам без повторения URL каждый раз; с этим справляются профили прокси.
Настройте повторно используемые профили прокси с помощью файлов .ini
Профиль прокси — это именованный файл .ini, который Splash читает один раз при запуске, а затем повторно использует по имени вместо полного URL. Включите профили, запустив Splash с --proxy-profiles-path, указывая на папку:
Или, с помощью Docker, смонтируйте эту папку в ожидаемый путь контейнера (иллюстративный — документированный синтаксис, здесь не выполненный вживую):
docker run -p8050:8050 \-v /local/path/to/proxy-profiles:/etc/splash/proxy-profiles \ scrapinghub/splash
Каждый профиль — это файл .ini с секцией [proxy] и дополнительной секцией [rules] (только для конфигурирования, сохраняется как /etc/splash/proxy-profiles/myprovider.ini):
host и port обязательны; username, password и type optional (type по умолчанию равен HTTP, и Splash также принимает SOCKS5). Секции [rules]allowlist и denylist являются разделенными переносами регулярными выражениями: запрос проксируется только тогда, когда его URL соответствует allowlist и не соответствует denylist, поэтому приведенный выше пример проксирует все, кроме расширений общих статических активов.
Сохраните файл как default.ini внутри папки профилей, чтобы он автоматически применялся ко всем запросам без указания имени, или сохраните его под другим именем и явно укажите:
Передайте proxy=none в любом отдельном запросе, чтобы пропустить профиль default.ini, если он настроен. Это различие — активный «silent» default.ini против профиля, который необходимо именовать — является наиболее распространенным источником сообщений о том, что «мой прокси не используется» в отношении Splash: запрос либо соответствовал правилу denylist, либо default.ini переопределяет предположение о том, что прокси вообще не установлен.
Управление прокси на каждом запросе с помощью API сценариев Lua
Конечная точка сценариев Lua Splash (execute) может проверять и изменять запрос перед его отправкой, используя обратный вызов splash:on_request и метод set_proxy объекта запроса:
Этот Lua-скрипт является иллюстративным — совпадает с документированным API объекта запроса, не выполняется против живого экземпляра Splash:
functionmain(splash, args) splash:on_request(function(request)if request.url:find("%.png$")or request.url:find("%.jpg$")then request.abort()returnend request:set_proxy{ host ="YOUR_PROXY_HOST", port =tonumber("YOUR_PROXY_PORT"), username ="YOUR_PROXY_USER", password ="YOUR_PROXY_PASSWORD", type ="HTTP",}end)assert(splash:go(args.url))assert(splash:wait(0.5))return splash:html()end
set_proxy работает только внутри splash:on_request и только до того, как запрос фактически будет отправлен — вызов его позже в обратном вызове не имеет эффекта. Пропустите username и password для прокси, который не требует аутентификации. Установка type = "HTTP" по-прежнему правильно проксирует HTTPS-цели, поскольку Splash реализует этот случай с помощью стандартного метода CONNECT, а не требует отдельного типа прокси для HTTPS.
Этот обратный вызов срабатывает один раз для каждого ресурса, а не один раз для страницы, поэтому скрипт может направить основной документ через один прокси и пропустить проксирование (или использовать другой прокси) для изображений, шрифтов или аналитических маяков на одной и той же странице — этого не может сделать ни параметр proxy, ни статический профиль самостоятельно, поскольку оба применяются на уровне одного вызова рендеринга.
Отправьте скрипт на конечную точку execute с исходным кодом Lua в качестве параметра lua_source:
scrapy-splash отправляет запросы Scrapy на экземпляр Splash и напрямую передает словарь args как параметры запроса самого Splash, так что ключ proxy внутри args ведет себя точно так же, как параметр строки запроса proxy, использованный ранее. Документация пакета README описывает точные названия промежуточного программного обеспечения и настроек ниже.
Установите и свяжите промежуточное программное обеспечение, необходимое Scrapy для маршрутизации запросов через Splash:
pip install scrapy scrapy-splash
Этот фрагмент settings.py является config-only, соответствует документированным значениям README для scrapy-splash:
Затем передайте proxy внутри args объекта SplashRequest:
Этот пример паука является prerequisite-gap — он не был выполнен против живой стековой комбинации Splash+Scrapy в этой среде, поскольку не было доступно никакой среды выполнения Docker/сети:
from scrapy import Spider
from scrapy_splash import SplashRequest
classProxyExampleSpider(Spider): name ="proxy_example"defstart_requests(self):yield SplashRequest( url="https://example.com/", callback=self.parse, args={"proxy":"http://YOUR_PROXY_USER:YOUR_PROXY_PASSWORD@YOUR_PROXY_HOST:YOUR_PROXY_PORT","wait":0.5,}, endpoint="render.html",)defparse(self, response):yield{"title": response.css("title::text").get()}
Значения args сопоставляются один к одному с параметрами HTTP API Splash, поэтому именованный профиль прокси работает так же: args={"proxy": "myprovider"}. Поскольку SplashDeduplicateArgsMiddleware присваивает отпечатки запросам по их аргументам Splash, изменение значения proxy при каждом запросе (вместо повторного использования одного статического значения) также предотвращает слой дедупликации Scrapy от обработки запросов с вращающимся прокси как дубликатов друг друга.
Маршрутизация провайдера вращающегося прокси через Splash
Все три механизма Splash выше ожидают те же три или четыре факта о прокси: хост, порт и — для аутентифицированных пулов — имя пользователя и пароль. Провайдер вращающегося резидентного или датацентрического прокси предоставляет точно эти факты, как правило, через один общий шлюз хоста и порта, который вращает выходной IP за сессию или за запрос за кулисами, так что никакие настройки прокси Splash не нужно менять, чтобы использовать его.
Nstproxy предоставляет HTTP(S)- и SOCKS5-совместимые прокси-шлюзы через несколько продуктовых линий, включая Residential Lite Proxies, которые охватывают более 50 миллионов резидентных IP-адресов в более чем 200 странах и регионах по модели биллинга на основании предоплаченного пакета. Подробности о хосте шлюза, порте и учетных данных для активного плана доступны в документации Nstproxy после регистрации. Поскольку Splash нуждается лишь в стандартных host:port плюс необязательные учетные данные user:pass, конечная точка Residential Lite шлюза вписывается в любой из вышеуказанных шаблонов — параметр URL proxy= для одноразовых вызовов, раздел [proxy] профиля .ini для фиксированного по умолчанию, или request:set_proxy в Lua для маршрутизации по ресурсам:
Контроль сессий — шлюз Nstproxy обычно предлагает режимы сессий с фиксированной и вращающейся привязкой через саму строку имени пользователя, что важно для Splash, потому что профиль .ini или вызов Lua set_proxy фиксирован на время жизни файла или скрипта; ротация затем происходит со стороны провайдера при каждой новой сессии, а не путем редактирования конфигурации Splash.
Согласование протоколов — поле type в Splash распознает только HTTP и SOCKS5; подтвердите, какой протокол ожидает шлюз конкретной линии продуктов Nstproxy перед написанием профиля, поскольку несоответствие значения type фактическому протоколу шлюза приводит к сбоям в подключении, которые выглядят как сбои прокси.
Масштабирование без изменения конфигурации Splash — поскольку учетные данные находятся в одном хосте и порту шлюза, а не в списке отдельных прокси IP, масштабирование от одного работника Splash до многих не требует распределения или ротации списка прокси-серверов между этими работниками.
Взгляните быстро
Управления прокси на основе Lua и профиля Splash маршрутизируют трафик — они не вращают IP-адреса самостоятельно, поэтому сочетание Splash с жилым шлюзом Nstproxy на самом деле распределяет запросы рендеринга по различным выходным IP с течением времени.
Неправильно настроенный прокси в Splash редко вызывает ошибки громко — он просто тихо возвращается к собственному IP Splash или блокирует законный запрос, что является повторяющейся жалобой за несколькими открытыми проблемами в репозитории scrapinghub/splash на GitHub. Пройдите через эти проверки в порядке:
Проверьте наличие тихого default.ini. Если файл default.ini существует в папке профилей-прокси, он применяется ко каждому запросу автоматически; запрос, который должен обойти прокси, нуждается в явном proxy=none.
Проверьте совпадения в allowlist/denylist. Раздел [rules] профиля проксирует только URL-адреса, соответствующие allowlist, и не соответствующие denylist — целевой URL, который не проходит ни один из тестов, извлекается без прокси, без поднятия ошибки.
Убедитесь, что type соответствует фактическому протоколу шлюза. Запрос HTTP-прокси к шлюзу только для SOCKS5 (или наоборот) приводит к сбою подключения, а не к четкому сообщению "неправильный протокол".
Помните о времени set_proxy. Он действует только при вызове внутри splash:on_request, до отправки запроса; вызов его где-либо еще в скрипте Lua будет тихо неэффективным.
Проверьте, что Splash действительно был запущен с --proxy-profiles-path. Без этого флага именованные профили вообще не загружаются, и параметр proxy=myprovider не имеет ничего, на что можно было бы ссылаться.
Честные ограничения
Поддержка прокси в Splash работает исключительно на уровне соединения: хост, порт, протокол и необязательная аутентификация. Она не управляет ротацией прокси, проверкой работоспособности или стойкостью сессий; эти поведения должны исходить от того, что стоит позади host:port, на который указывает профиль или вызов set_proxy, будь то скрипт, вращающий URL, или шлюз провайдера, вращающий сессии внутренне. Splash также применяет прокси на каждый вызов рендеринга или на каждый ресурс, а не в рамках контекста браузера так, как это делает полноценная автоматизация браузера с прокси, установленным на постоянную сессию при загрузке нескольких страниц. Как только проект по сбору данных превышает возможности одного статического шлюза и требует правил маршрутизации по нескольким пулам, смотрите как краулить с Proxy Manager для следующего уровня.
Заключение
Splash предоставляет скребку три рычага для маршрутизации прокси-трафика — одноразовый параметр URL proxy, многоразовый профиль .ini, загружаемый через --proxy-profiles-path, и вызов Lua request:set_proxy для управления на уровне ресурсов внутри splash:on_request — и все три принимают одинаковую форму хоста/порта/учетной записи, которую предоставляет ротационный прокси-провайдер. Для того, чтобы маршрутизация прокси действительно вступила в силу, в основном необходимо избежать двух тихих режимов сбоя: незамеченный профиль default.ini и несоответствие allowlist/denylist, позволяющее запросам проходить без прокси без поднятия ошибки.
Часто задаваемые вопросы
Вопрос: Какие протоколы прокси поддерживает Splash?
Splash поддерживает http и socks5 в параметре запроса proxy и HTTP/SOCKS5 как в .ini файлах профиля прокси, так и в поле type вызова Lua request:set_proxy; отдельного типа прокси HTTPS не существует, поскольку проксирование по типу HTTP уже обрабатывает адреса HTTPS с помощью метода CONNECT.
Вопрос: Нужно ли мне использовать --proxy-profiles-path для работы с прокси вообще?
Нет — --proxy-profiles-path требуется только для именованных, многоразовых профилей прокси; одноразовый прокси может быть передан напрямую в качестве URL в параметре запроса proxy без каких-либо специальных флагов запуска.
Вопрос: Почему мой прокси в Splash, кажется, игнорируется при некоторых запросах?
Наиболее распространенные причины ошибки — это несоответствующий шаблон allowlist/denylist в разделе [rules] профиля прокси, файл default.ini, который бесшумно переопределяет предполагаемый запрос "без прокси", или вызов request:set_proxy, размещенный в каком-либо месте, кроме splash:on_request, до отправки запроса.
Вопрос: Могу ли я использовать разные прокси для разных ресурсов на одной странице?
Да — колбек Lua splash:on_request срабатывает один раз для каждого ресурса (документ, изображение, скрипт и так далее), поэтому вызов request:set_proxy с разными значениями внутри этого колбека направляет разные типы ресурсов через разные прокси в рамках одного вызова рендеринга.
Вопрос: Нужны ли special settings для передачи прокси через scrapy-splash?
Дополнительные настройки, помимо стандартной настройки middleware scrapy-splash, не требуются — ключ proxy в словаре args объекта SplashRequest передается в Splash точно так же, как параметр proxy в строке запроса HTTP.
Вопрос: Splash автоматически меняет IP прокси?
Нет — Splash просто передает запрос через тот хост, порт и учетные данные, которые ему даны; изменение фактического выхода IP со временем должно происходить от шлюза провайдера прокси (например, режим с изменением сессии) или от скрипта, который изменяет значение прокси между запросами.
Вопрос: Ограничен ли этот рабочий процесс авторизованными целями для сканирования?
Да — всё в этой статье предполагает доступ к общедоступным страницам в соответствии с условиями сайта; перенаправление трафика через прокси не уполномочивает на обход аутентификации, платных стен или средств контроля доступа к непубличным данным.
Ivy Lin
Aug. 20th 2026
110M+ реальных IP с 99.9% успешных доступов
Средний отклик ~0.5с для задач высокой конкуренции
Всего от $0.1/GB
Мгновенный доступ к премиальным residential, datacenter, IPv6 и ISP пулам.