Выберыце проксі для кожнага рэсурсу Splash

Запыт Scrapy можа паспяхова звязацца з Splash, але браўзер унутры Splash усё яшчэ мае патрэбу ў іншым зыходным маршруце. Гэта два злучэнні:

Scrapy → Splash API
Splash browser → forward proxy → website

Для аднаго проксі на рэндэр перадайце аргумент proxy HTTP API. Splash 3.5 апісвае URL проксі, напрыклад http://proxy.example:8080, або назву наладжанага профілю проксі. Фармат URL таксама падтрымлівае SOCKS5 і неабавязковыя ўліковыя даныя.

Калі асобным рэсурсам старонкі патрэбны розныя канчатковыя пункты, выкарыстайце скрыпт execute і зарэгіструйце выбар перад навігацыяй:

function main(splash, args)
  splash:on_request(function(request)
    local host = args.default_proxy
    if request.url == args.special_resource then
      host = args.special_proxy
    end
    request:set_proxy{host = host, port = 8080, type = 'HTTP'}
  end)

  assert(splash:go(args.url))
  return splash:html()
end

Перадайце default_proxy і special_proxy як імёны хастоў, а special_resource — як дакладны URL рэсурсу для асобнай маршрутызацыі. Замяніце адзіны порт з прыкладу, калі два слухачы адрозніваюцца. Іншыя рэсурсы атрымаюць маршрут па змаўчанні. Спіс HTTP-проксі прапануе кандыдатаў у канчатковыя пункты для гэтых палёў хаста і порта, калі дазволены маршруты публічных рэсурсаў і да кандыдатаў не прымяняюцца ўліковыя даныя проксі.

Метад request прымае неабавязковыя палі username і password. З тыпам HTTP мэты HTTPS выкарыстоўваюць CONNECT праз гэты HTTP-проксі; ім не патрэбны выдуманы тып HTTPS-проксі.

Зваротны выклік выконваецца перад кожным запытам. Яго метады request не могуць змяніць ужо адпраўлены запыт, а зваротны выклік не можа выклікаць асінхронныя метады Splash, такія як splash:go ці splash:wait.

Трымайце выбар маршруту стабільным, калі старонка чакае адну сесію або адзін ідэнтыфікатар крыніцы. Выпадковае прызначэнне кожнай выявы і API-запыту іншаму выхаду можа стварыць адрэндараваную старонку, запыты якой ужо не належаць адной узгодненай сесіі.