Es posible bloquear o desafiar visitantes según su país o región, pero la medida debe aplicarse con cuidado. La geolocalización de una IP es aproximada, los rangos cambian y usuarios legítimos pueden viajar, usar una VPN o conectarse desde redes internacionales.
Si el dominio utiliza Cloudflare con la nube naranja activa, normalmente conviene filtrar el tráfico allí, antes de que llegue al servidor. Mantener manualmente miles de rangos IPv4 e IPv6 en .htaccess es más complejo y puede quedar desactualizado.
Cuándo puede ser útil un filtro geográfico
- Ataques o automatizaciones concentrados en regiones donde no tenés clientes.
- Intentos reiterados contra páginas de acceso o formularios.
- Servicios disponibles únicamente para una zona definida.
- Reducción temporal de tráfico abusivo durante un incidente.
El país por sí solo no determina si una solicitud es maliciosa. Siempre que sea posible, combiná ubicación con ruta, método, frecuencia, reputación o comportamiento.
Bloquear desde una regla personalizada de Cloudflare
En el panel del dominio ingresá en Seguridad → Reglas de seguridad → Crear regla personalizada. Los nombres pueden variar según la versión de la interfaz. Elegí el campo Country o utilizá el editor de expresiones con ip.src.country.
Por ejemplo, para evaluar dos códigos ISO de país:
(ip.src.country in {"CN" "RU"})
Los países del ejemplo son ilustrativos: reemplazalos por los que correspondan al análisis real de tu tráfico. La documentación oficial de Cloudflare sobre geobloqueo muestra que las reglas personalizadas pueden evaluar país, continente o ASN.
Después elegí una acción. Para una primera implementación suele ser más prudente Managed Challenge que Block, porque permite observar falsos positivos antes de aplicar una denegación definitiva.
Limitar la regla a rutas sensibles
Bloquear un país en todo el dominio puede afectar lectores, clientes, APIs y servicios externos. Una regla más precisa puede evaluar también la ruta:
(ip.src.country in {"CN" "RU"} and
starts_with(http.request.uri.path, "/wp-login.php"))
También pueden protegerse formularios o áreas administrativas concretas. No copies rutas sin adaptarlas al sitio. En WordPress, admin-ajax.php y la API REST pueden recibir solicitudes legítimas desde el frontend y desde integraciones.
Orden de las reglas y excepciones
Las reglas personalizadas de Cloudflare se evalúan en orden y una acción de bloqueo puede impedir que se ejecuten reglas posteriores. Colocá antes las excepciones estrictamente necesarias y después la regla geográfica.
Revisá especialmente:
- pasarelas de pago y sus webhooks;
- APIs de proveedores;
- servicios de monitoreo;
- motores de búsqueda verificados;
- correo, CRM y formularios externos;
- usuarios administrativos que viajan o usan VPN.
No crees una excepción global por agente de usuario si puede falsificarse. Combiná criterios y limitá el alcance a la ruta o servicio que realmente lo necesita.
El dominio debe estar realmente detrás de Cloudflare
Las reglas sólo inspeccionan solicitudes que pasan por el proxy. Si el registro DNS está con nube gris, el tráfico va directamente al origen. También debe evitarse que terceros accedan a la IP del servidor por fuera de Cloudflare, porque podrían eludir el filtro.
Antes de activar reglas, confirmá la configuración siguiendo la guía para activar Cloudflare en un dominio.
Managed Challenge, Block o Rate Limiting
- Managed Challenge: Cloudflare decide cómo verificar la solicitud. Es útil para reducir bots con menor impacto inicial.
- Block: deniega inmediatamente. Reservalo para tráfico claramente no deseado y revisado.
- Rate Limiting: limita solicitudes repetidas. Puede ser mejor cuando el problema es frecuencia y no ubicación.
Un desafío en todo el sitio puede degradar la experiencia, afectar conversiones o interferir con clientes que no ejecutan JavaScript. Aplicalo a rutas de riesgo o como medida temporal cuando sea posible.
Cómo revisar el resultado en Cloudflare
- Guardá la regla con un nombre descriptivo.
- Revisá Seguridad → Eventos durante las primeras horas.
- Filtrá por nombre de regla, país, ruta y acción.
- Comprobá si aparecen clientes, bots legítimos o integraciones.
- Ajustá la expresión antes de cambiar de desafío a bloqueo.
Documentá la fecha, el motivo y los países incluidos. Las reglas antiguas suelen quedar activas después de que el incidente termina y pueden generar problemas meses más tarde.
Bloquear países desde .htaccess
Apache 2.4 permite restringir IPs y redes mediante Require. Para excluir un rango concreto puede utilizarse una estructura como:
<RequireAll>
Require all granted
Require not ip 198.51.100.0/24
</RequireAll>
Sin embargo, un país completo contiene numerosos rangos IPv4 e IPv6 que cambian con el tiempo. Debés obtenerlos de una fuente mantenida, actualizar la lista y comprobar que el archivo no se vuelva demasiado grande. Una lista extensa en .htaccess también agrega complejidad al procesamiento.
La directiva Require de Apache 2.4 trabaja con direcciones y redes, no con nombres de países. Por eso, para geolocalización, una capa especializada suele ser más adecuada.
Diferencia entre bloquear una IP y un país
Si el abuso proviene de una o pocas direcciones, un bloqueo específico genera menos falsos positivos. Podés revisar cómo bloquear una dirección IP desde cPanel.
Si las IP cambian constantemente dentro de una misma región y el sitio no tiene audiencia allí, una regla geográfica puede ser razonable. Aun así, observá el tráfico antes de ampliarla.
Limitaciones de la geolocalización
- Una VPN o proxy puede mostrar un país diferente al real.
- Redes móviles y corporativas pueden salir por otro territorio.
- Las bases de geolocalización no son perfectas.
- Servicios legítimos pueden ejecutar infraestructura global.
- Los atacantes pueden cambiar de red o región.
El geobloqueo reduce una parte del tráfico; no corrige vulnerabilidades ni impide ataques distribuidos.
Cuándo no conviene aplicarlo
Evitá un bloqueo general si vendés internacionalmente, recibís consultas de viajeros, dependés de APIs globales o no tenés datos que justifiquen la medida. Tampoco lo uses para reemplazar actualizaciones, contraseñas únicas, 2FA, ModSecurity, protección de formularios y rate limiting.
Plan de reversión
Antes de guardar, conservá la expresión anterior y una captura de la configuración. Si se bloquea una función crítica, desactivá la regla completa para confirmar la causa y después corregí la condición. No agregues excepciones amplias bajo presión sin entender qué tráfico permitirán.
La estrategia más segura es gradual: medir, aplicar Managed Challenge en rutas sensibles, revisar eventos y bloquear sólo cuando el patrón sea claro. De esa forma, el filtro geográfico complementa al resto de las defensas sin convertirse en una fuente permanente de falsos positivos.