Cómo configurar proxies en Splash en 2026 - Guía paso a paso
Resumen
Las rutas de Splash envían proxies a través de un parámetro HTTP, proxy, que acepta ya sea una URL de proxy o un perfil nombrado. El formato de la URL es [protocolo://][usuario:contraseña@]host[:puerto], con http o socks5 como protocolo y el puerto 1080 como el predeterminado cuando se omite.
Los perfiles de proxy nombrados requieren iniciar Splash con --proxy-profiles-path y apuntarlo a una carpeta de archivos .ini; un perfil default.ini se aplica automáticamente a cada solicitud a menos que la solicitud pase explícitamente proxy=none.
La sección [proxy] de cada perfil contiene host, puerto, nombre de usuario/contraseña opcionales, y tipo (HTTP o SOCKS5), mientras que su sección [rules] restringe el proxy a URLs coincidentes a través de patrones regex en allowlist/denylist.
Para lógica de proxy por solicitud o por tipo de recurso, la API Lua de Splash expone request:set_proxy{host, port, username, password, type} dentro de un callback splash:on_request, que se ejecuta antes de que se envíe la solicitud y puede asignar un proxy diferente a diferentes tipos de recursos en la misma página.
scrapy-splash adelante los parámetros HTTP de Splash sin cambios, por lo que el diccionario args de un SplashRequest puede llevar proxy de la misma manera que lo hace una llamada render.html sin procesar.
Un proveedor de proxy rotativo como Nstdata se conecta a cualquiera de los tres métodos anteriores — URL directa, perfil .ini, o Lua set_proxy — porque Splash trata el proxy como un host:puerto ordinario más credenciales opcionales, sin importar quién las emita.
Introducción: enrutar el tráfico a través de Splash sin perder el hilo
Splash es el servicio de renderizado de navegador sin cabeza y programable de Scrapinghub/Zyte, al que se accede comúnmente a través de su API HTTP o a través de la integración de scrapy-splash en Scrapy. Renderiza páginas pesadas en JavaScript y devuelve HTML, PNG, JSON o HAR, pero por defecto, cada solicitud de renderizado sale del host de Splash en la propia IP saliente de Splash. Los sitios que identifican por IP, bloquean por ASN o limitan la tasa por dirección de origen tratarán cada solicitud de la misma manera, sin importar cuántas páginas objetivo diferentes visite un scraper, hasta que un proxy se interponga entre Splash y el sitio objetivo.
Splash expone tres formas separadas de insertar ese proxy: un único parámetro de solicitud proxy para proxies de una sola vez o rotados manualmente, una carpeta --proxy-profiles-path de archivos .ini para perfiles nombrados reutilizables, y una llamada Lua request:set_proxy para control de por solicitud o por tipo de recurso. Esta guía recorre los tres métodos, además del cableado de scrapy-splash necesario para pasar un valor de proxy desde un spider de Scrapy, y concluye con cómo conectar un grupo de proxies residenciales rotativos a cualquiera de los tres métodos.
Requisitos previos
Una instancia de Splash en funcionamiento — los ejemplos a continuación utilizan la imagen oficial de Docker scrapinghub/splash, ya que la propia documentación de instalación de Splash recomienda Docker sobre una instalación local de Python para la mayoría de las configuraciones. El código fuente y el rastreador de problemas de Splash se encuentran en el repositorio scrapinghub/splash en GitHub.
Docker instalado localmente (o un host remoto al que pueda alcanzar en el puerto 8050).
Credenciales de proxy de un proveedor — host, puerto, y (si es necesario) nombre de usuario/contraseña. Las credenciales reales nunca se imprimen en este artículo; cada ejemplo usa marcadores de posición como YOUR_PROXY_HOST y YOUR_PROXY_PASSWORD.
scrapy y scrapy-splash instalados (pip install scrapy scrapy-splash) solo para las secciones que utilizan Scrapy.
Ninguno de los comandos a continuación se ejecutó contra un contenedor Splash en vivo en el entorno que produjo este artículo — no se dispuso de tiempo de ejecución de Docker. Cada nombre de comando y parámetro se verifica con la propia documentación y código fuente de Splash (splash.readthedocs.io, github.com/scrapinghub/splash) en lugar de ser inventado, y cada bloque de código se etiqueta como ilustrativo o solo configuración a continuación.
Instalar e iniciar Splash
Inicie Splash de la manera que su propia documentación recomienda, mapeando el puerto de la API al host. Este comando coincide con la sintaxis documentada; no se ejecutó en vivo en este entorno (sin tiempo de ejecución de Docker disponible), así que trátelo como ilustrativo:
docker run -it-p8050:8050 --rm scrapinghub/splash
La API se vuelve accesible en http://localhost:8050. Confirme que responde antes de conectar un proxy:
Una vez que Splash puede alcanzar un sitio objetivo directamente, el siguiente modo de fallo suele ser que el sitio objetivo bloquee la propia IP de Splash: un pool residencial rotativo como los proxies Residential Lite de Nstdata le da a Splash una IP de salida fresca por sesión en lugar de una dirección estática que todos los sitios pueden marcar.
Configurar un proxy con el parámetro de solicitud proxy
La forma más rápida de enrutar una sola llamada de renderización a través de un proxy es el argumento de solicitud proxy de Splash, disponible en render.html, render.png, render.json, execute y otros puntos finales de renderizado. Acepta una URL de proxy en la forma [protocolo://][usuario:contraseña@]hostproxy[:puerto], donde el protocolo es http o socks5 y el puerto predeterminado es 1080 si se omite:
Esta es la herramienta correcta cuando un script ensambla la URL del proxy en el momento de la solicitud, por ejemplo, obteniendo un nuevo punto final de sesión rotativa de un proveedor antes de cada llamada a Splash. No es la herramienta adecuada cuando el mismo proxy necesita aplicarse automáticamente a cada solicitud sin repetir la URL cada vez; eso es lo que manejan los perfiles de proxy.
Configurar perfiles de proxy reutilizables con archivos .ini
Un perfil de proxy es un archivo .ini nombrado que Splash lee una vez al inicio y luego reutiliza por nombre en lugar de una URL completa. Habilita los perfiles iniciando Splash con --proxy-profiles-path apuntando a una carpeta:
O, con Docker, monta esa carpeta en la ruta esperada del contenedor (ilustrativo — sintaxis documentada, no ejecutada aquí en vivo):
docker run -p8050:8050 \-v /ruta/local/a/proxy-profiles:/etc/splash/proxy-profiles \ scrapinghub/splash
Cada perfil es un archivo .ini con una sección [proxy] y una sección [rules] opcional (solo-configuración, guardada como /etc/splash/proxy-profiles/miproveedor.ini):
host y port son obligatorios; username, password y type son opcionales (type predeterminado es HTTP, y Splash también acepta SOCKS5). Las allowlist y denylist de la sección [rules] son expresiones regulares separadas por nuevas líneas: una solicitud se enruta a través del proxy solo cuando su URL coincide con la allowlist y no coincide con la denylist, por lo que el ejemplo anterior enruta todo excepto extensiones de activos estáticos comunes.
Guarda el archivo como default.ini dentro de la carpeta de perfiles para que se aplique automáticamente a cada solicitud sin nombrarlo, o guárdalo con otro nombre y referencia explícitamente:
Pasa proxy=none en cualquier solicitud individual para omitir un perfil default.ini cuando uno esté configurado. Esta distinción — un default.ini que está activamente silencioso frente a un perfil que debes nombrar — es la fuente más común de informes de "mi proxy no está siendo utilizado" contra Splash: la solicitud coincide con una regla de denylist o un default.ini está sobreescribiendo una suposición de que no se configuró ningún proxy.
Controlar proxies por solicitud con la API de scripting Lua
El punto final de scripting Lua de Splash (execute) puede inspeccionar y modificar una solicitud antes de que se envíe, usando el callback splash:on_request y el método set_proxy del objeto de solicitud:
Este script Lua es ilustrativo — coincidido con la API documentada del objeto de solicitud, no ejecutado contra una instancia en vivo de 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 ="SU_HOST_PROXY", port =tonumber("SU_PUERTO_PROXY"), username ="SU_USUARIO_PROXY", password ="SU_CONTRASEÑA_PROXY", type ="HTTP",}end)assert(splash:go(args.url))assert(splash:wait(0.5))return splash:html()end
set_proxy solo funciona dentro de splash:on_request, y solo antes de que la solicitud se haya enviado realmente; llamarlo más tarde en el callback no tiene efecto. Omita username y password para un proxy que no requiera autenticación. Establecer type = "HTTP" aún proxifica correctamente los objetivos HTTPS, ya que Splash implementa ese caso con el método estándar CONNECT en lugar de requerir un tipo de proxy HTTPS separado.
Este callback se activa una vez por recurso, no una vez por página, por lo que un script puede enrutar el documento principal a través de un proxy y omitir la proxy (o usar un proxy diferente) para imágenes, fuentes o balizas de análisis en la misma página; algo que ni el parámetro proxy ni un perfil estático pueden hacer por sí solos, ya que ambos se aplican a nivel de una única llamada de renderizado.
Envíe el script al endpoint execute con la fuente Lua como el parámetro lua_source:
scrapy-splash envía solicitudes de Scrapy a una instancia de Splash y reenvía el diccionario args directamente como los propios parámetros de solicitud de Splash, por lo que una clave proxy dentro de args se comporta exactamente como el parámetro de consulta proxy utilizado anteriormente. El README del paquete documenta los nombres exactos de middleware y configuraciones a continuación.
Instale y configure los middlewares que Scrapy necesita para enrutar solicitudes a través de Splash:
pip install scrapy scrapy-splash
Este fragmento de settings.py es solo-configuración, que coincide con los valores documentados en el README de scrapy-splash:
Luego, pase proxy dentro de los args de un SplashRequest:
Este ejemplo de spider es un gap-de-requisitos; no se ejecutó contra una pila activa de Splash+Scrapy en este entorno, ya que no había disponible ejecución de Docker/red:
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()}
Los valores de args se asignan uno a uno a los parámetros de la API HTTP de Splash, por lo que un perfil de proxy nombrado funciona de la misma manera: args={"proxy": "myprovider"}. Debido a que SplashDeduplicateArgsMiddleware identifica solicitudes por sus argumentos de Splash, rotar el valor de proxy en cada solicitud (en lugar de reutilizar un valor estático) también evita que la capa de deduplicación de Scrapy trate las solicitudes de proxy rotadas como duplicados entre sí.
Enrutar un proveedor de proxy rotatorio a través de Splash
Los tres mecanismos de Splash anteriores esperan los mismos tres o cuatro datos sobre un proxy: un host, un puerto y, para grupos autenticados, un nombre de usuario y una contraseña. Un proveedor de proxy residencial o de centro de datos rotatorio proporciona exactamente esos datos, típicamente a través de un único host y puerto de puerta de enlace compartidos que rotan la IP de salida por sesión o por solicitud detrás de escena, por lo que ningún manejo de proxy de Splash tiene que cambiar para usar uno.
Nstdata proporciona puertas de enlace de proxy compatibles con HTTP(S) y SOCKS5 a través de varias líneas de productos, incluidos Residential Lite Proxies, que cubren más de 50 millones de IP residenciales en más de 200 países y regiones con un modelo de facturación de paquete prepagado. Los detalles de host de puerta de enlace, puerto y credenciales para un plan activo están disponibles en la documentación de Nstdata después del registro. Dado que Splash solo necesita host:puerto estándar más las credenciales opcionales usuario:contraseña, un endpoint de puerta de enlace de Residential Lite se adapta a cualquiera de los patrones anteriores: el parámetro de URL proxy= para llamadas únicas, la sección [proxy] de un perfil .ini para un predeterminado fijo, o request:set_proxy en Lua para el enrutamiento por recurso:
Control de sesión: La puerta de enlace de Nstdata típicamente expone modos de sesión pegajosos y rotatorios a través de la propia cadena de nombre de usuario, lo cual es importante para Splash porque un perfil .ini o una llamada set_proxy en Lua es fija durante la vida del archivo o script; la rotación ocurre entonces del lado del proveedor por cada nueva sesión en lugar de editar la configuración de Splash.
Coincidencia de protocolo — El campo type de Splash solo reconoce HTTP y SOCKS5; confirma qué protocolo espera la puerta de enlace de una línea de productos de Nstdata antes de escribir un perfil, ya que desajustar el valor de type respecto al protocolo real de la puerta de enlace produce fallas de conexión que parecen fallas de proxy.
Escalar sin tocar la configuración de Splash — dado que las credenciales residen en un solo host y puerto de la puerta de enlace en lugar de una lista de IPs de proxy individuales, escalar de un trabajador de Splash a muchos no requiere distribuir o rotar una lista de servidores proxy entre esos trabajadores.
Échale un vistazo rápido
Los controles de proxy basados en Lua y en perfiles de Splash solo dirigen el tráfico; no rotan IPs por su cuenta, por lo que emparejar Splash con la puerta de enlace residencial de Nstdata es lo que realmente distribuye las solicitudes de renderización a través de diferentes IPs de salida a lo largo del tiempo.
Un proxy mal configurado en Splash rara vez genera un error ruidoso; simplemente vuelve silenciosamente a la propia IP de Splash o bloquea una solicitud legítima, que es el patrón recurrente de quejas detrás de varios problemas abiertos en el repositorio de GitHub scrapinghub/splash. Trabaja a través de estas comprobaciones en orden:
Verifica un default.ini silencioso. Si existe un archivo default.ini en la carpeta de perfiles de proxy, se aplica automáticamente a cada solicitud; una solicitud que supuestamente debe omitir un proxy necesita un proxy=none explícito.
Verifica coincidencias en la allowlist/denylist. La sección [rules] de un perfil solo envía a través del proxy las URL que coinciden con la allowlist y que no coinciden con la denylist; una URL de destino que no pase ninguna de las pruebas se obtiene sin el proxy, sin que se genere un error.
Confirma que el type coincide con el protocolo real de la puerta de enlace. Solicitar un proxy HTTP contra una puerta de enlace solo SOCKS5 (o viceversa) produce una falla de conexión, no un mensaje claro de "protocolo equivocado".
Recuerda el momento de set_proxy. Solo tiene efecto cuando se llama dentro de splash:on_request, antes de que se envíe la solicitud; llamarlo en cualquier otro lugar de un script Lua es ineficaz en silencio.
Verifica que Splash realmente se haya iniciado con --proxy-profiles-path. Sin esa bandera, los perfiles nombrados no se cargan en absoluto, y un parámetro proxy=myprovider no tiene nada a qué resolverse.
Límites honestos
El soporte de proxy de Splash opera puramente a nivel de conexión: host, puerto, protocolo y autenticación opcional. No gestiona la rotación de proxies, la verificación de salud o la persistencia de sesiones por sí mismo; esos comportamientos deben provenir de lo que esté detrás del host:port al que apunta un perfil o una llamada a set_proxy, ya sea un script que rota URL o el gateway de un proveedor que rota sesiones internamente. Splash también aplica un proxy por cada llamada de renderización o por cada recurso, no por contexto de navegador de la manera en que un marco completo de automatización de navegador podría limitar un proxy a una sesión persistente a través de múltiples cargas de página. Una vez que un proyecto de scraping supera una sola puerta de enlace estática y necesita reglas de enrutamiento a través de múltiples grupos, consulta cómo rastrear con Proxy Manager para esa siguiente capa.
Conclusión
Splash le da a un scraper tres palancas para enrutamiento de tráfico de proxy: un parámetro de URL proxy único, un perfil reutilizable .ini cargado a través de --proxy-profiles-path, y una llamada Lua request:set_proxy para control por recurso dentro de splash:on_request; y los tres aceptan la misma forma de host/puerto/credencial que un proveedor de proxy rotatorio emite. Hacer que el enrutamiento de proxy tenga efecto es principalmente cuestión de evitar los dos modos de falla silenciosos: un perfil default.ini no notado y un desajuste de allowlist/denylist que permite que las solicitudes pasen sin proxy sin generar un error.
FAQ
Q: ¿Qué protocolos de proxy soporta Splash?
Splash soporta http y socks5 en el parámetro de solicitud proxy y HTTP/SOCKS5 en ambos archivos .ini de perfil de proxy y el campo typerequest:set_proxy; no hay un tipo de proxy HTTPS separado, ya que el proxying tipo HTTP ya maneja objetivos HTTPS a través del método CONNECT.
Q: ¿Necesito --proxy-profiles-path para usar un proxy en absoluto?
No — --proxy-profiles-path solo es requerido para perfiles de proxy nombrados y reutilizables; un proxy único puede ser pasado directamente como una URL en el parámetro de solicitud proxy sin ninguna bandera especial de inicio.
Q: ¿Por qué parece que mi proxy de Splash se ignora en algunas solicitudes?
Las causas más comunes son un patrón de allowlist/denylist desajustado en la sección [rules] de un perfil de proxy, un default.ini que anula silenciosamente una solicitud de "sin proxy" asumida, o una llamada a request:set_proxy colocada en un lugar diferente a dentro de splash:on_request antes de que se envíe la solicitud.
P: ¿Puedo usar un proxy diferente para diferentes recursos en la misma página?
Sí — el callback Lua splash:on_request se activa una vez por recurso (documento, imagen, script, etc.), por lo que llamar a request:set_proxy con diferentes valores dentro de ese callback dirige diferentes tipos de recursos a través de diferentes proxies en una sola llamada de renderizado.
P: ¿Necesita scrapy-splash configuraciones especiales para pasar un proxy?
No se necesitan configuraciones adicionales más allá de la configuración estándar del middleware de scrapy-splash; una clave proxy dentro del diccionario args de un SplashRequest se envía a Splash exactamente como el parámetro de cadena de consulta proxy en una llamada HTTP directa.
P: ¿Rotan las IPs de proxy automáticamente Splash?
No — Splash solo dirige una solicitud a través de cualquier host, puerto y credenciales que se le den; rotar la IP de salida real con el tiempo debe venir del gateway del proveedor de proxy (por ejemplo, un modo de sesión rotativa) o de un script que cambie el valor del proxy entre solicitudes.
P: ¿Está este flujo de trabajo limitado a objetivos de scraping autorizados?
Sí — todo en este artículo asume acceso a páginas de libre acceso público bajo los términos de un sitio; dirigir tráfico a través de un proxy no autoriza eludir autenticaciones, muros de pago o controles de acceso sobre datos no públicos.
Compara los flujos de trabajo de proxy residencial de IPRoyal y Nstdata por facturación, comportamiento de identidad, recopilación, operaciones y salida utilizable.
Kai Watanabe
Sep. 11th 2026
110M+ IP reales con 99.9% de acceso exitoso
Respuesta media ultrarrapida ~0.5s para tareas de alta concurrencia
Desde solo $0.1/GB
Acceso inmediato a pools premium de proxies residenciales, datacenter, IPv6 e ISP.
