REMOTE_ADDR vs CF-Connecting-IP: cómo obtener la IP real del visitante tras Cloudflare

Si un plugin de seguridad de WordPress te advierte sobre la "configuración de detección de IP," o tu aplicación PHP de repente registra el mismo puñado de IPs para cada visitante, la causa casi siempre es la misma: un proxy inverso como Cloudflare se sitúa entre tus visitantes y tu servidor. La versión corta — mantén REMOTE_ADDR como valor por defecto, nunca confíes ciegamente en HTTP_CLIENT_IP y lee CF-Connecting-IP solo cuando hayas confirmado que la petición realmente llegó a través de Cloudflare. Aquí está el porqué de cada uno de esos puntos.

Qué significa realmente cada valor

En PHP estos llegan como entradas de $_SERVER. No son intercambiables — provienen de lugares completamente distintos, y esa diferencia lo es todo:

• REMOTE_ADDR — la dirección IP de quien abrió la conexión TCP a tu servidor. El servidor web rellena este valor a partir del propio socket, de modo que un cliente no puede falsificarlo. Este es el único valor fiable.
• HTTP_CLIENT_IP y HTTP_X_FORWARDED_FOR — cabeceras HTTP ordinarias de la petición. Cualquier entrada HTTP_* en $_SERVER no es más que una cabecera que envió el cliente, lo que significa que cualquiera puede ponerle el valor que quiera con una sola línea de curl.
• HTTP_CF_CONNECTING_IP — la cabecera CF-Connecting-IP que añade Cloudflare, que contiene la IP real del visitante. Fiable solo cuando puedes garantizar que la petición pasó a través de Cloudflare.

Por qué detrás de Cloudflare REMOTE_ADDR está "mal"

Cuando Cloudflare hace de proxy de tu dominio, tus visitantes se conectan al edge de Cloudflare, y Cloudflare abre una conexión nueva hacia tu servidor de origen. Desde el punto de vista de tu servidor, el visitante es Cloudflare — así que REMOTE_ADDR es una IP del edge de Cloudflare, la misma para miles de personas distintas. Nada está roto; el proxy simplemente está haciendo su trabajo.

Para entregarte el visitante original, Cloudflare adjunta la cabecera CF-Connecting-IP en cada petición. Así que detrás de Cloudflare la fuente correcta es $_SERVER['HTTP_CF_CONNECTING_IP'], recurriendo a REMOTE_ADDR cuando esa cabecera no está presente.

La trampa de seguridad: por qué no puedes confiar sin más en la cabecera

Es tentador escribir "lee HTTP_CLIENT_IP o X-Forwarded-For, en caso contrario REMOTE_ADDR" y seguir adelante. Ese es exactamente el patrón que deja sitios comprometidos. Como son cabeceras suministradas por el cliente, un atacante puede enviar:

curl https://your-site.example/wp-login.php \
  -H "X-Forwarded-For: 8.8.8.8" \
  -H "Client-IP: 1.1.1.1"

Si tu limitación de inicios de sesión, tu firewall o tu registro de auditoría leen esas cabeceras, el atacante puede rotar una IP falsa en cada petición — burlando los límites de tasa, eludiendo los bloqueos por IP y envenenando tus logs. Por eso un buen plugin de seguridad te advierte antes de cambiar el método de detección: la opción "más cómoda" suele ser la insegura.

CF-Connecting-IP está a salvo de esto solo por una condición extra: tu origen debe aceptar tráfico únicamente de Cloudflare. Si tu servidor también es accesible directamente por su IP pública, un atacante puede saltarse Cloudflare y falsificar CF-Connecting-IP él mismo. Blinda el origen con Authenticated Origin Pulls o un firewall que solo permita los rangos de IP de Cloudflare, y la cabecera pasa a ser fiable.

La configuración correcta, dicho claramente

• Servidor normal, sin proxy: usa REMOTE_ADDR. Listo.
• Detrás de Cloudflare: usa CF-Connecting-IP (HTTP_CF_CONNECTING_IP) y restringe tu origen a Cloudflare para que la cabecera no pueda falsificarse.
• Detrás de otro proxy/CDN o un balanceador de carga: usa la cabecera que documente ese proxy (a menudo X-Forwarded-For, tomando el salto fiable más a la derecha) y, de nuevo, asegúrate de que el origen solo acepta tráfico de ese proxy.

En plugins de seguridad de WordPress como All-In-One Security, esta es exactamente la opción que controla el ajuste de "detección de IP". Déjalo en REMOTE_ADDR a menos que estés detrás de Cloudflare, en cuyo caso cámbialo a CF-Connecting-IP.

Cómo verificar que lo has hecho bien

La comprobación más rápida es comparar lo que detecta tu servidor con tu IP pública real. Abre whatsmy.fyi desde la misma máquina: muestra la IP pública exacta con la que el mundo exterior te ve. Si la IP que tu plugin o aplicación registra para tu propia visita coincide con esa, la detección está funcionando. (whatsmy.fyi corre sobre el propio Cloudflare, así que lee tu dirección desde CF-Connecting-IP igual que lo haría un origen correctamente configurado — y no guarda nada.)

Si estás depurando de forma programática, el endpoint sin clave devuelve el mismo valor para scripts:

curl https://whatsmy.fyi/ip
# → tu IP pública real, tal como se ve en el edge

Dos IPs que coinciden significa que tu detección es correcta. Si tu servidor registra una IP de Cloudflare mientras whatsmy.fyi muestra la tuya real, sigues leyendo REMOTE_ADDR detrás del proxy — cambia a CF-Connecting-IP. Si difieren de cualquier otra manera, hay una VPN, una división IPv4/IPv6 o un segundo proxy en el camino — nuestra nota sobre por qué una IP puede mostrar la ubicación equivocada cubre esos casos.

La conclusión en una línea

REMOTE_ADDR es la verdad sobre la que no se puede mentir a tu servidor; HTTP_CLIENT_IP es una afirmación que cualquiera puede hacer. Detrás de Cloudflare, prefiere CF-Connecting-IP y blinda tu origen para que siga siendo fiable — y luego confirma el resultado contra tu dirección real en whatsmy.fyi.