Índice9
«Hemos puesto Cloudflare delante, estamos protegidos.» La frase es verdad a medias. Un proxy inverso colocado delante de un sitio o de una aplicación cambia muchas cosas: los ataques de saturación se detienen antes del servidor, las peticiones sospechosas se filtran, los archivos salen de una caché cercana al visitante. Pero solo ve lo que pasa por él, y a veces actúa en su nombre sin que usted lo haya pedido. Este artículo pone las cosas en su sitio, en el marco de nuestra guía de la base de infraestructura en la nube.
Tomamos Cloudflare como ejemplo porque lo usamos y sus ajustes están documentados públicamente. El mismo montaje existe en otros lugares: en las grandes nubes (Amazon CloudFront con AWS WAF, Azure Front Door, Google Cloud Armor), en redes de distribución como Fastly, Akamai o la europea Bunny, o con un proxy inverso instalado en su propio servidor. Las preguntas de este artículo valen para todos.
En resumen
- Un proxy inverso recibe todas las peticiones en lugar de su servidor y solo le transmite las que superan sus reglas.
- En Cloudflare, la protección contra los ataques de saturación está incluida en todas las ofertas, de la red a la aplicación.
- No protege una aplicación vulnerable, ni un servidor accesible directamente, ni credenciales robadas.
- Puede modificar lo que sirve su sitio, robots.txt incluido: compruebe la dirección de producción, no su código.
- Todo pasa por él: una avería del proxy es una avería de sus servicios, y el plan de recuperación debe preverla.
Lo que hace un proxy inverso
Definición
El proxy inverso
Un servidor situado delante de sus servicios, que recibe las peticiones de los visitantes en su lugar, decide qué hacer con ellas (rechazarlas, responder desde su caché, transmitirlas) y devuelve la respuesta. El visitante solo habla con el proxy; su servidor solo habla con el proxy.
El recorrido de una petición detrás de un proxy
- El visitante
Pide una página en su dirección habitual.
- El proxy
Filtra, cifra y responde desde su caché cuando puede.
- Su servidor
Solo recibe lo que el proxy ha dejado pasar.
- La respuesta
Vuelve por el proxy, que puede guardarla en caché.
Esta posición lo explica todo: el proxy protege lo que pasa por él, y solo eso.
Lo que protege
Los ataques de saturación. Un ataque que inunda un servidor de peticiones lo tumba, sea cual sea la calidad de su código. Una red mundial absorbe ese volumen antes de que llegue a usted. La documentación de Cloudflare sobre la protección DDoS indica que una protección estándar y sin límite de volumen, de las capas de red a la capa de aplicación, está incluida en todas las ofertas.
Las peticiones sospechosas. El cortafuegos de aplicaciones examina las peticiones web y de API entrantes y filtra el tráfico no deseado según conjuntos de reglas: reglas gestionadas por el editor, reglas que usted escribe, límites de frecuencia. El alcance depende de la oferta: en la oferta de entrada, un solo conjunto de reglas gestionadas y una sola regla de limitación de frecuencia.
El cifrado y la caché. El proxy presenta un certificado a los visitantes y sirve desde su caché los archivos que no cambian. Un sitio estático es el que más gana: sus páginas enteras son archivos.
La dirección de su servidor. Cuando los registros DNS pasan por el proxy, el visitante solo ve las direcciones del proxy. Con una condición, que se detalla más abajo: que nada más delate la dirección real.
Lo que no protege
Lo que pasa por el proxy
Los ataques de saturación contra su dominio
Las peticiones que corresponden a una regla conocida
El cifrado entre el visitante y el proxy
La carga de los archivos servidos desde la caché
Lo que se le escapa
Un servidor accesible directamente por su dirección
Una vulnerabilidad de la aplicación que las reglas no reconocen
Una contraseña o una clave de API robadas, usadas con normalidad
Los datos perdidos sin copia de seguridad
El servidor accesible directamente. Cloudflare detalla, en su página sobre la protección del servidor de origen, lo que puede delatar la dirección real: registros DNS no redirigidos (SPF, TXT), un servidor de correo alojado en la misma máquina, el historial DNS anterior a la instalación del proxy. Sus defensas: aceptar en el servidor solo el tráfico procedente de las direcciones de Cloudflare, autenticar las peticiones del proxy o un túnel saliente que evite cualquier dirección pública. Y cambiar la dirección del servidor después de la instalación.
La propia aplicación. Un cortafuegos de aplicaciones reconoce ataques conocidos; no corrige una extensión vulnerable ni una lógica defectuosa. Las actualizaciones siguen siendo cosa suya, como muestra nuestro artículo sobre los sitios WordPress pirateados.
Las credenciales. Un inicio de sesión con una contraseña o una clave de API robadas se parece a un inicio de sesión normal. Este riesgo se trata en otro lugar: un gestor de contraseñas para el equipo y la protección de las claves de API de los proyectos de IA.
Un proxy también actúa en su nombre
Un proxy puede modificar lo que sirve su sitio: añadir cabeceras, reescribir una dirección, inyectar un archivo. Estas opciones son útiles cuando se eligen, traicioneras cuando están activadas por defecto.
Atención
Un cliente lo descubrió en la auditoría
En Palmora Property, una plataforma de intermediación inmobiliaria en Phuket que acompañamos, el robots.txt del repositorio autorizaba a todos los robots. El que se servía en producción empezaba con un bloque añadido por Cloudflare, el «robots.txt gestionado», ausente del código, que rechazaba en particular a GPTBot, ClaudeBot y Google-Extended. La auditoría del 22 de julio de 2026 lo detectó, y la opción se desactivó ese mismo día.
La regla que se deriva es sencilla: se comprueba lo que sirve la dirección de producción, no lo que contiene el repositorio. Las consecuencias de este bloqueo en la visibilidad en los asistentes de IA se detallan en nuestro artículo sobre lo que hace que un sitio sea citable por las IA.
Un punto de paso único
Todo pasa por el proxy: si cae, sus servicios caen con él, aunque su servidor funcione bien. Cloudflare publicó el relato detallado de su avería del 18 de noviembre de 2025:
- 11:20 UTC
La red de Cloudflare empieza a fallar al encaminar el tráfico. Un archivo de configuración de la gestión de robots, que se había vuelto demasiado grande tras un cambio de permisos en una base de datos, hace caer el software del proxy.
- 17:06 UTC
Todos los sistemas de Cloudflare vuelven a funcionar con normalidad.
No es un argumento contra los proxys: un servidor solo también cae, y más a menudo. Es un argumento para escribirlo en el plan. Bastan tres precauciones: una sonda externa que pruebe el servicio a través del proxy (vea nuestra guía de la supervisión), un procedimiento escrito para servir el sitio sin el proxy si la avería se prolonga, y los accesos a la cuenta del proxy guardados con los demás accesos de emergencia en el plan de recuperación ante desastres.
Lo que hacemos nosotros
Sobre el terreno
Los servidores de nombres de este sitio están en Cloudflare desde el 2 de octubre de 2026, y sus páginas las sirve la red de Cloudflare desde el 18 de octubre de 2026. El montaje funciona porque las páginas son archivos sin datos personales; las solicitudes del formulario se registran en un espacio de almacenamiento sujeto a la restricción de jurisdicción europea. Las redirecciones, las cabeceras de seguridad y la configuración del alojamiento están escritas en el repositorio del sitio y se revisan como código.
En un servidor propio, el mismo principio se aplica a menor escala: un único proxy inverso delante de todos los servicios, que centraliza los certificados y las reglas de acceso, con los propios servicios cerrados a internet.
Por dónde empezar
- Inventariar lo que está expuesto.
Cada dominio y subdominio, lo que sirve y si pasa por el proxy.
- Cerrar el acceso directo.
El servidor solo acepta el proxy; después, cambiar su dirección si ya ha circulado.
- Revisar las opciones activadas.
Gestión de robots, reescrituras, archivos añadidos: conservar lo que se ha elegido, quitar el resto.
- Comprobar lo que se sirve.
Robots.txt, cabeceras y redirecciones, en la dirección de producción.
- Prever la avería.
Una sonda externa, un procedimiento de desvío escrito, accesos de emergencia.
El resto del proyecto
El proxy no es más que una capa de la base. El lugar de alojamiento se elige según el uso (servidor dedicado, VPS o nube) y su factura se vigila (las partidas que inflan una factura de nube). Lo que el proxy no protege se trata con las copias de seguridad, con una base de datos bien explotada (Postgres gestionado o propio) y con una infraestructura que se sabe reconstruir (la infraestructura como código). Kubernetes no es necesario para poner un proxy delante de algunos servicios (cuándo una pyme no lo necesita), y n8n en producción se coloca detrás de él como los demás (n8n autoalojado). El correo, que puede delatar la dirección de un servidor, tiene su propio artículo (correo profesional: Google, Microsoft o proveedor europeo). En cuanto a las decisiones: las herramientas que conviene sacar primero del SaaS, el coste de una salida del SaaS a tres años, la migración a la nube sin romperlo todo, la dependencia de la nube estadounidense, el hardware para hacer funcionar un modelo de IA y NIS2 en Francia.
Nuestra salida del SaaS instala sus herramientas detrás de un único proxy inverso, en un servidor de su propiedad, con copias de seguridad probadas y documentación de explotación: 5 500 € y tres semanas.
Preguntas frecuentes
¿Basta Cloudflare para proteger un sitio?
No. Protege lo que pasa por él: ataques de saturación, peticiones que corresponden a sus reglas, cifrado entre el visitante y el proxy. No corrige una aplicación vulnerable, no protege un servidor accesible directamente y no detecta un inicio de sesión con credenciales robadas. Las actualizaciones, los accesos y las copias de seguridad siguen siendo responsabilidad suya.
¿Hace falta un proxy delante de un sitio estático?
Un sitio estático no tiene servidor de aplicaciones que proteger, pero gana con el mismo montaje: cifrado, caché cercana al visitante y absorción de los ataques de saturación. De hecho, la mayoría de los proveedores de alojamiento de sitios estáticos ya funcionan así. El punto de atención sigue siendo el mismo: las opciones que modifican lo que sirve el sitio, como un robots.txt añadido por defecto.
¿Qué pasa si Cloudflare cae?
Los servicios que pasan por él se vuelven inaccesibles, aunque su servidor funcione. La avería del 18 de noviembre de 2025 lo demostró a gran escala. Prepare una sonda de supervisión que pruebe a través del proxy, un procedimiento escrito para servir el sitio sin él si la avería se prolonga, y accesos de emergencia a la cuenta, guardados en el plan de recuperación.
¿Existen alternativas europeas a Cloudflare?
Sí. Redes de distribución europeas, como Bunny, ofrecen caché, protección y reglas de filtrado, y un proxy inverso también puede funcionar en su propio servidor en Europa. Compare la protección contra los ataques de saturación, el cortafuegos de aplicaciones, el lugar de almacenamiento de los registros y la facilidad de salida. La elección sigue los mismos criterios que la de un proveedor de alojamiento.
Fuentes
- Cloudflare, protección DDoS (nueva pestaña)developers.cloudflare.com
- Cloudflare, cortafuegos de aplicaciones web (WAF) (nueva pestaña)developers.cloudflare.com
- Cloudflare, proteger el servidor de origen (nueva pestaña)developers.cloudflare.com
- Cloudflare, Cloudflare outage on November 18, 2025 (nueva pestaña)blog.cloudflare.com
Cloudflare, cortafuegos de aplicaciones web (WAF)
Leer en developers.cloudflare.com(nueva pestaña)Cloudflare, Cloudflare outage on November 18, 2025
Leer en blog.cloudflare.com(nueva pestaña)Jim · fundador de Brain Plus AI
Más artículos sobre infraestructura y nube
Guía práctica14 min La guía del tema
Infraestructura en la nube: la base común de todos sus proyectos
Antes del primer proyecto, una base de infraestructura en la nube resuelve de una vez por todas las cuentas, los accesos, las copias de seguridad y el presupuesto, y cada proyecto siguiente la hereda. Qué contiene, dónde montarla, cuánto cuesta y por qué su explotación cuenta más que su instalación.
Entender7 min
Cloud and AI Development Act: triplicar los centros de datos
Presentada el 3 de junio de 2026, la Cloud and AI Development Act quiere triplicar la capacidad de los centros de datos europeos y crear una escala de soberanía en cuatro niveles para las compras públicas de nube. Lo que contiene la propuesta, en qué punto está la negociación y lo que sigue siendo válido para elegir un proveedor de alojamiento hoy.
Entender8 min
Data Act: fin de los costes de salida de la nube en enero de 2027
El 12 de enero de 2027, un proveedor cloud ya no podrá cobrar el cambio de proveedor, y los objetos conectados nuevos ya devuelven sus datos a su usuario. Lo que el Data Act le permite exigir, y lo que no hará en su lugar.