Elija un proxy para cada recurso de Splash
Seleccione un proxy de Splash en el ámbito de renderizado o en una devolución de llamada on_request cuando recursos individuales necesiten rutas distintas.
Una solicitud de Scrapy puede llegar a Splash correctamente mientras el navegador dentro de Splash aún necesita una ruta de salida distinta. Son dos conexiones:
Scrapy → Splash API
Splash browser → forward proxy → websitePara un proxy por renderizado, pase el argumento proxy de la API HTTP. Splash 3.5 documenta una URL de proxy como http://proxy.example:8080, o un nombre de perfil de proxy configurado. Su formato de URL también admite SOCKS5 y credenciales opcionales.
Cuando recursos individuales de la página necesitan puntos de salida diferentes, use un script execute y registre la selección antes de navegar:
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()
endPase default_proxy y special_proxy como nombres de host, y special_resource como la URL exacta del recurso que debe enrutarse por separado. Sustituya el único puerto del ejemplo cuando los dos escuchas difieran. Los demás recursos reciben la ruta predeterminada. La lista de proxies HTTP ofrece candidatos de punto de salida para estos campos de host y puerto cuando se permiten rutas de recursos públicos y no se aplican credenciales de proxy a los candidatos.
El método request acepta los campos opcionales username y password. Con el tipo HTTP, los destinos HTTPS usan CONNECT a través de ese proxy HTTP; no necesitan un tipo de proxy HTTPS inventado.
La devolución de llamada se ejecuta antes de cada solicitud. Sus métodos request no pueden cambiar una solicitud una vez enviada, y la devolución de llamada no puede llamar a métodos asíncronos de Splash como splash:go o splash:wait.
Mantenga estable la selección de ruta cuando la página espera una sola sesión o identidad de origen. Asignar al azar cada imagen y solicitud de API a otra salida puede producir una página renderizada cuyas solicitudes ya no pertenecen a una sesión coherente.