Sitios web y aplicaciones bloqueados
Un proveedor de proxies puede mantener una lista de recursos a los que sus clientes no pueden acceder a través de su red. Un destino puede añadirse tras una denuncia de abuso o una exigencia de un suministrador de infraestructura. Otros se bloquean de antemano porque el proveedor considera demasiado alto el riesgo de incidentes.
Este es uno de los límites de uso de los proxies que determinan adónde puede llevar tu tráfico el servicio. El proxy puede estar disponible y correctamente configurado y, aun así, rechazar conexiones con un destino de la lista.
Cómo una denuncia acaba convirtiéndose en un destino bloqueado
Cuando un cliente utiliza un proxy, el destino recibe tráfico de la IP de salida del proxy. Si ese tráfico causa un problema, el operador del sitio puede denunciar la dirección ante la organización responsable de su red. La denuncia puede llegar directamente al proveedor de proxies o a través de la empresa de alojamiento, el centro de datos o el operador de red que suministran su infraestructura.
Una denuncia de abuso es un aviso sobre el posible uso indebido de un servicio. Puede referirse a intentos repetidos de acceso no autorizado, escaneos o tráfico que sobrecarga un sistema. Un suministrador de infraestructura puede exigir a su cliente —el proveedor de proxies— que detenga la actividad. Según las normas del suministrador y el incidente, dejar el problema sin resolver puede poner en riesgo un servidor o el acceso a la red.
Si sus registros permiten identificar la cuenta implicada, el proveedor puede investigar y restringir esa cuenta. También puede bloquear el destino afectado en parte o en la totalidad de su servicio. Estas medidas resuelven problemas distintos: restringir una cuenta actúa sobre un cliente concreto, mientras que bloquear un destino impide que otros clientes envíen tráfico a ese recurso a través del servicio cubierto.
Pensemos en un portal gubernamental que recibe tráfico no deseado de forma repetida desde un servicio de proxies. Tras una denuncia y una exigencia de detener ese tráfico, el proveedor añade el portal a su lista de bloqueo. Más tarde, otro cliente intenta descargar un documento público y recibe un error. Ese segundo cliente no ha hecho nada indebido, pero la regla compartida para el destino también se aplica a su conexión.
Por qué los proveedores bloquean recursos antes de que ocurra un incidente
Un proveedor no tiene que esperar una denuncia independiente sobre cada sitio web. Después de gestionar incidentes relacionados con un tipo de recurso, puede decidir restringir destinos parecidos de antemano. Así, la lista de bloqueo se convierte tanto en una medida preventiva como en un registro de problemas anteriores.
El posible coste va más allá de gestionar una denuncia. Los incidentes repetidos consumen tiempo del personal, perjudican la relación con los suministradores de infraestructura y pueden amenazar la disponibilidad del servicio para otros clientes. Un proveedor puede decidir que transportar tráfico a una categoría sensible no compensa esos riesgos, aunque algunos clientes tengan motivos legítimos para acceder a ella.
Esto explica por qué una restricción amplia puede mantenerse después de retirar al cliente original. El proveedor intenta evitar que se repita el problema. Puede restringir toda una categoría sin determinar antes si cada nuevo visitante pretende leer una página, iniciar sesión o realizar una acción no deseada.
Qué recursos pueden incluirse en una lista de bloqueo
Los recursos gubernamentales y financieros son ejemplos de categorías que los proveedores pueden restringir por precaución. Incluyen sistemas en los que un acceso no autorizado o una interrupción pueden afectar a expedientes personales, servicios públicos, cuentas o dinero. Un proveedor puede optar por una regla amplia porque evaluar la actividad prevista de cada cliente es más difícil que denegar el acceso al destino.
| Recursos | Por qué podría restringirlos un proveedor |
|---|---|
| Portales gubernamentales y sistemas del sector público | Para reducir el riesgo de intentos de acceso no autorizado, escaneos o interrupciones que afecten a los servicios públicos. |
| Bancos, servicios de pago y otras plataformas financieras | Para limitar las posibilidades de ataques a cuentas y fraude financiero a través de la red proxy. |
| Otros recursos asociados a denuncias repetidas | Un sitio web o servicio concreto puede añadirse tras varios incidentes, independientemente de su categoría. |
No existe una lista de bloqueo única que utilicen todos los proveedores de proxies. Un servicio puede restringir dominios individuales, mientras otro bloquea toda una categoría. Incluso dentro de una misma empresa, las reglas pueden variar entre productos o redes. Que un sitio gubernamental aparezca en la lista de un proveedor no demuestra que todos lo bloqueen.
Una categoría también debe traducirse en reglas técnicas. Los recursos gubernamentales utilizan muchas formas de nombrar sus dominios, de modo que bloquear solo direcciones que terminan en .gov no equivale a bloquear todos los sitios gubernamentales. Un proveedor puede mantener su propia lista o utilizar un servicio de clasificación para identificar destinos.
Cómo aplica el proxy la lista de bloqueo
Antes de conectarte con un recurso, el proxy necesita conocer el destino. Con un proxy HTTP, un cliente puede solicitar un túnel HTTPS mediante CONNECT portal.example:443. Esa solicitud proporciona al proxy el nombre de host y el puerto de destino. SOCKS5 también transporta una dirección de destino, que puede facilitarse como nombre de host o dirección IP.
El servicio compara ese destino con sus reglas de acceso. Si una regla coincidente lo prohíbe, puede rechazar la conexión antes de reenviar la solicitud del cliente al sitio web. Una regla de dominio comprueba un nombre; una regla de dirección comprueba la IP o el bloque de destino. Una regla de categoría puede basarse en una lista de dominios o direcciones asignados a esa categoría.
Esto no requiere que el proxy lea una página cifrada. En un túnel HTTPS habitual, el destino se conoce antes de que empiece el intercambio protegido con el sitio web. Por tanto, el bloqueo puede producirse sin inspeccionar el contenido de la página, la ruta completa de la URL o la contraseña que habría introducido el visitante.
Importa el alcance de la regla. Bloquear un nombre de host no bloquea automáticamente todos los subdominios de la misma organización. A la inversa, una regla de dominio amplia o una regla de IP que abarque un servidor compartido pueden afectar a más recursos que el que originó la denuncia. Los cambios de dirección de los sitios web también obligan a mantener actualizada la lista de bloqueo.
Por qué el acceso depende del producto
Un proveedor puede aplicar reglas de acceso distintas a productos diferentes. Un sitio web puede estar bloqueado en sus proxies de centro de datos o ISP, disponible mediante su red residencial o accesible solo a través de un servicio gestionado de recopilación de datos.
Algunos proveedores permiten acceder a ciertos recursos únicamente después de un proceso KYC (Know Your Customer), que verifica la identidad del cliente. También pueden necesitar aprobar la tarea concreta. El acceso concedido después de estas comprobaciones puede seguir limitado a un producto o destino determinado; no elimina todas las restricciones de la cuenta.
También importa cómo gestiona el servicio las solicitudes. Con un proxy habitual, el navegador o programa del cliente decide qué solicitudes enviar. Con una API de extracción, el cliente envía una tarea, como obtener una página o recopilar datos de productos, y el sistema del proveedor la ejecuta. El resultado puede ser el HTML de la página o datos extraídos en un formato estructurado.
En un servicio gestionado de este tipo, el proveedor puede seleccionar la red proxy, configurar las cabeceras de las solicitudes y las cookies, repetir solicitudes fallidas y procesar la respuesta. El reparto exacto del control depende del producto: algunos ajustes son automáticos y otros puede facilitarlos el cliente dentro de los límites permitidos. El proveedor controla el intercambio con el sitio de destino para esa tarea y puede restringir qué parámetros de solicitud acepta.
Esto permite al proveedor autorizar una operación concreta y mantener restringido el acceso más amplio. Por ejemplo, un servicio puede permitir que una API recopile precios públicos de productos y, al mismo tiempo, denegar el acceso proxy habitual al mismo dominio. Ese permiso no cubre automáticamente iniciar sesión, enviar formularios o gestionar una cuenta. Un producto puede permitir leer ciertas páginas sin admitir todas las acciones disponibles en el sitio web.
Comprueba el acceso para la combinación de producto, destino y operación prevista. Que un sitio web funcione a través de la API de un proveedor no demuestra que funcione mediante su paquete de proxies. Una API gestionada también tiene sus propias restricciones. Antes de comprar, pregunta qué producto permite realizar tu tarea y si requiere verificación o aprobación independiente.
Qué ve el cliente
El resultado más claro es un mensaje explícito que indica que el destino no está permitido. En otros casos, el software solo comunica un fallo de conexión o un tiempo de espera agotado. La información que recibe el cliente depende tanto de la respuesta del servicio como de los detalles que muestra la aplicación.
Un destino bloqueado puede seguir siendo inaccesible a través de muchas IP proxy que, por lo demás, funcionan correctamente. Si la misma regla cubre todo el paquete, sustituir sus direcciones no cambia el resultado. Comprar más tráfico o aumentar el límite de conexiones simultáneas tampoco modifica esa regla de destino.
Una aplicación puede fallar solo en parte. Por ejemplo, su página principal puede utilizar un dominio y su servicio de inicio de sesión otro. Si la segunda dirección está bloqueada, la página se abre, pero el inicio de sesión falla. Lo mismo puede ocurrir con descargas de archivos u otras funciones que utilizan servidores independientes. Una lista de bloqueo se aplica a los destinos de red con los que contacta la aplicación, no simplemente al nombre de la aplicación.
En qué se diferencia de que un sitio web rechace tu proxy
La lista de bloqueo de un proveedor detiene el tráfico de camino al destino. Por su parte, un sitio web puede rechazar el tráfico que llega a sus servidores o a su servicio de seguridad: por ejemplo, porque rechaza la IP de salida o considera sospechosa la actividad. En ese caso, la denegación procede del destino.
Un simple HTTP 403 o una conexión fallida no identifican por sí solos quién bloqueó el acceso. Un mensaje del proveedor que indique el destino prohibido es más útil que el código de estado por sí solo. Cuando la causa no está clara, soporte necesita la dirección exacta, el servicio utilizado, la hora del intento y el texto completo del error para comprobar si intervino una regla del proveedor.
También existe otro tipo de restricción independiente: los puertos de destino bloqueados. Un bloqueo de dominio deniega el acceso a un recurso, mientras que una restricción de puertos puede impedir un tipo concreto de conexión con muchos servidores distintos. Por tanto, un sitio o una aplicación inaccesibles son un síntoma; la lista de destinos es una de sus posibles causas.
¿Puede retirarse un recurso de la lista de bloqueo?
Depende de por qué existe la regla y de quién la controla. Si el proveedor añadió un destino por precaución, puede estar dispuesto a revisar una tarea concreta. Si el acceso está excluido por el suministrador de infraestructura o por una regla fija del producto, una solicitud habitual a soporte puede no bastar para cambiarlo.
Cuando existen excepciones, una solicitud útil identifica el recurso exacto y explica la actividad prevista: qué datos o función se necesitan, si hace falta iniciar sesión y cuál es la carga esperada. Así, el proveedor puede evaluar un uso concreto en lugar de una petición indefinida para abrir toda una categoría.
La verificación o la aprobación no eliminan necesariamente todas las restricciones de una cuenta. Una excepción puede cubrir solo un destino o producto concreto. Todo acceso que conceda el proveedor de proxies sigue sujeto a los controles de acceso del propio sitio web.
Las listas de bloqueo pueden cambiar cuando llegan denuncias nuevas o el proveedor revisa su evaluación del riesgo. Un recurso que funcionaba puede dejar de estar disponible al añadirse una regla. Si una tarea depende de un sitio web concreto, establece antes de elegir el servicio si ese destino y la operación necesaria están admitidos; el número de IP disponibles no responde a esa pregunta.