[Inicio](https://servghost.com/es) /
[Guías de Alojamiento Privado](https://servghost.com/es/guides) /
Protección DDoS en VPS: dónde acaba tu proveedor y empieza la capa 7






Operaciones


# Sobrevivir a un ataque DDoS en tu VPS



Todo plan de hosting dice «protección DDoS incluida», y en todos ellos significa exactamente lo mismo, y es algo limitado: la red absorbe inundaciones medidas en gigabits. Los ataques que realmente tumban los sitios pequeños se miden en solicitudes por segundo, casi no le cuestan nada al atacante, y llegan con aspecto totalmente legítimo. Esta guía traza la línea entre ambos, muestra cómo distinguir en menos de un minuto en cuál de los dos estás, y cubre lo que realmente aguanta en el lado de la línea que te corresponde a ti.


[Leer la guía](#guide-body)
[Preguntas frecuentes](#guide-faq)






## En esta página




- [Guía](#guide-body)

- [Preguntas frecuentes](#guide-faq)

- [Guías relacionadas](#guide-related)

- [Páginas recomendadas](#guide-cta)






Sin KYC
Solo cripto
Sin registros
DMCA ignorado
Root completo
NVMe SSD





24 min de lectura
Actualizado Sep 2026

En esta página

[01Dos ataques distintos que comparten un nombre](#dos-ataques-distintos-que-comparten-un-nombre)
[02Qué compra realmente la «protección DDoS incluida»](#qué-compra-realmente-la-protección-ddos-incluida)
[03Primero, decide si esto es siquiera un ataque](#primero-decide-si-esto-es-siquiera-un-ataque)
[04Leer el ataque desde el propio servidor](#leer-el-ataque-desde-el-propio-servidor)
[05Los primeros diez minutos](#los-primeros-diez-minutos)
[06Límites de tasa que aguantan, y el error que comete todo el mundo](#límites-de-tasa-que-aguantan-y-el-error-que-comete-todo-el-m)
[07La caché es la mitigación más barata que desplegarás jamás](#la-caché-es-la-mitigación-más-barata-que-desplegarás-jamás)
[08Los techos que deciden si te caes](#los-techos-que-deciden-si-te-caes)
[09Poner algo delante del origen](#poner-algo-delante-del-origen)
[10Un origen oculto vale más que cualquier filtro](#un-origen-oculto-vale-más-que-cualquier-filtro)
[11Elegir hardware y ubicación para que los ataques resulten aburridos](#elegir-hardware-y-ubicación-para-que-los-ataques-resulten-ab)
[12Cinco cosas que no hay que hacer](#cinco-cosas-que-no-hay-que-hacer)
[13La versión corta](#la-versión-corta)
[FAQPreguntas frecuentes](#guide-faq)
[→Páginas recomendadas](#guide-cta)







Hay dos momentos en los que se aprende cómo funciona realmente la mitigación de DDoS. El primero es tranquilo, en el momento de la compra, leyendo una lista de características que dice «protección DDoS incluida» y dando por hecho, sin pensarlo demasiado, que esa frase lo cubre todo. El segundo es a las tres de la madrugada, cuando el sitio está caído, las gráficas se ven mal de una forma que no tiene sentido, y esa protección incluida no está haciendo nada en absoluto — correctamente, y por diseño.

Ambos momentos involucran el mismo producto y la misma verdad: un proveedor de hosting filtra los ataques que llegan como volumen bruto, porque es dueño de la tubería por la que viajan esos paquetes y tú no. No puede filtrar los ataques que llegan como solicitudes de aspecto normal, porque desde el punto de vista de la red son solicitudes de aspecto normal. Esa línea — entre la inundación que absorbe tu proveedor y la que tienes que sobrevivir tú mismo — es todo el tema. Lo que sigue trata de averiguar en qué lado de esa línea estás, y qué hacer en cada uno.

## Dos ataques distintos que comparten un nombre

«DDoS» es una sola palabra que cubre dos problemas que casi no tienen nada en común salvo el resultado. Se detienen en lugares distintos, por personas distintas, con herramientas distintas, y confundirlos es la razón por la que tanto esfuerzo de mitigación termina en la capa equivocada.

| | Volumétrico — capas 3 y 4 | Aplicación — capa 7 |
| --- | --- | --- |
| Qué llega | Inundaciones SYN, amplificación UDP vía reflectores DNS abiertos, NTP o memcached, inundaciones ACK, paquetes de basura pura | Solicitudes HTTP normales: inundaciones GET, inundaciones POST, Slowloris, cadenas de consulta que anulan la caché |
| Se mide en | Gigabits y millones de paquetes por segundo | Solicitudes por segundo — a menudo solo unos pocos miles |
| Ancho de banda necesario para hacerte daño | Enorme. Es una competición de capacidad | Casi ninguno. Un solo portátil puede lograrlo si el endpoint es lo bastante costoso |
| Dónde hay que detenerlo | **Aguas arriba, por tu proveedor.** Para cuando los paquetes llegan a tu puerto, el daño ya está hecho | **En tu servidor, por ti**, o en un proxy que controles delante de él |
| Qué aspecto tiene en la máquina | Interfaz saturada, contadores de paquetes absurdos, la CPU puede estar inactiva | Ancho de banda modesto, pero todos los workers ocupados, la carga subiendo, la cola de la base de datos creciendo |
| Quién lo arregla | La depuración de tu proveedor, automáticamente, normalmente en segundos | Tu configuración — límites de tasa, caché, techos de conexión |

Lee otra vez las dos últimas filas, porque ahí está el punto práctico. Si la interfaz está saturada, nada de lo que escribas en el servidor va a ayudar: los paquetes ya han consumido el puerto, y la única parte que puede descartarlos es la que es dueña del router aguas arriba. Si la interfaz está tranquila pero el sitio sigue caído, ocurre lo contrario — tu proveedor no ve nada malo porque, en su capa, no *hay* nada malo, y el arreglo es enteramente tuyo.

Las inundaciones volumétricas se filtran aguas arriba, donde está la capacidad. Lo que sobrevive a ese filtro es tráfico de aspecto normal — y detenerlo es tu trabajo, no el de tu proveedor.

## Qué compra realmente la «protección DDoS incluida»

La protección a nivel de red es real, valiosa, y casi siempre se interpreta mal. Cuando un proveedor anuncia filtrado L3/L4, quiere decir que su red monitoriza el tráfico destinado a tu dirección, y que cuando se detecta una inundación, el tráfico se desvía a través de hardware de depuración que descarta la parte maliciosa y reenvía lo que parece legítimo. Ocurre sin necesidad de un ticket de soporte y normalmente sin que notes más que un breve parpadeo.

Esa única frase está haciendo mucho trabajo, así que merece la pena desglosar qué incluye y qué no:

- **Cubre los ataques que no puedes sobrevivir solo.** Una inundación de amplificación de 200 Gbps contra un servidor con un puerto de 1 Gbps no es un problema de configuración. Es aritmética. La depuración aguas arriba es la única respuesta que existe.

- **No tiene estado respecto a tu aplicación.** El filtro no sabe cuáles de tus URLs son costosas, qué visitantes han iniciado sesión, ni que una solicitud a tu endpoint de búsqueda cuesta cuatrocientas veces más que una solicitud a tu logotipo.

- **Reacciona ante un umbral, no ante tu sufrimiento.** La detección se activa por volumen de tráfico. Un ataque que nunca cruza el umbral nunca lo activa, sin importar lo exhaustivamente que haya tumbado tu sitio.

- **Puede aplicar brevemente una ruta nula (null-routing) en casos extremos.** Toda red tiene un techo. Si un ataque amenaza la infraestructura compartida, la dirección puede quedar bloqueada durante un tiempo — esto es estándar, universal, y conviene saberlo antes de que ocurra y no durante.

**La versión de una línea:** tu proveedor protege su red, y tú te beneficias de eso. No protege tu aplicación, y no tiene forma de hacerlo. La capa 7 no es un extra que te hayan negado — es una capa a la que tu proveedor no puede ver sin terminar tu TLS, lo cual, para cualquiera que aloje offshore, es un intercambio con sus propios costes serios.

## Primero, decide si esto es siquiera un ataque

Una proporción considerable de los presuntos incidentes de DDoS son otra cosa disfrazada, y las soluciones no son intercambiables. Antes de limitar la tasa de nada, dedica dos minutos a descartar a los impostores — un diagnóstico equivocado aquí te cuesta una hora y, a veces, tus usuarios reales.

- **Te has vuelto popular.** Un enlace en un gran agregador produce una forma de tráfico que parece exactamente una inundación de capa 7, salvo que los referrers son reales y las solicitudes piden páginas que un humano querría ver. Es un problema de capacidad con una causa feliz; limitar su tasa es autolesión.

- **Un rastreador perdió los modales.** Los scrapers agresivos y los bots de entrenamiento de IA pueden superar a un servidor pequeño con total facilidad. El user-agent suele delatarlo, y el arreglo es robots.txt más un límite específico, no uno general.

- **Rompiste algo.** Un despliegue que desactivó la caché, una tarea cron descontrolada, una base de datos que perdió un índice — todo se presenta como «carga repentina, sin causa evidente». Si el momento coincide con un cambio que hiciste, cree en el cambio.

- **Tu propia monitorización es la inundación.** Poco frecuente, embarazoso, y mucho más común de lo que nadie admite. Un bucle de comprobación de salud que reintenta sin backoff puede generar una tasa de solicitudes genuinamente impresionante.

La pregunta que marca la diferencia es simple: *¿el tráfico quiere algo?* La carga real — incluso la carga real de aspecto hostil — tiene una forma. Golpea páginas que existen, sigue enlaces, carga activos, y proviene de una dispersión plausible de redes. Un ataque normalmente no se molesta en hacer eso.

## Leer el ataque desde el propio servidor

No necesitas un panel para clasificar lo que está pasando. Cuatro comandos, ejecutados en orden, te dirán en menos de un minuto en qué capa estás luchando — y saber eso determina todo lo que haces a continuación.

**¿Está la tubería llena?** Observa los contadores de la interfaz. Si el rendimiento está clavado cerca del techo del puerto, estás en un ataque volumétrico y tu trabajo es un ticket de soporte, no un cambio de configuración:

- vnstat -tr 10 — rendimiento medio en diez segundos, la lectura honesta más rápida sobre la saturación.

- cat /proc/net/dev dos veces, con un segundo de diferencia — deltas de paquetes y bytes por interfaz, sin necesidad de herramientas.

**¿Es una inundación SYN?** Las conexiones semiabiertas se acumulan en SYN-RECV. Un puñado es normal; miles no lo es:

- ss -s — la línea de resumen, recuentos de conexiones por estado de un vistazo.

- ss -tn state syn-recv | wc -l — el número concreto que importa.

**¿Es capa 7?** Si el ancho de banda no llama la atención pero todo va lento, cuenta las solicitudes por cliente en tu log de acceso. Una sola dirección con decenas de miles de peticiones es un aficionado; cien mil direcciones con tres peticiones cada una es lo real:

- tail -n 100000 access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -30

- Cambia $1 por $7 para clasificar en su lugar las rutas solicitadas. Si un endpoint costoso domina, has encontrado el objetivo y la mitad del arreglo.

**¿Qué es lo que realmente se ha agotado?** El load average por sí solo dice poco. Busca el techo específico que has alcanzado: los procesos de PHP-FPM todos ocupados, las conexiones de la base de datos en su límite, los descriptores de archivo agotados, o workers atascados en estado D esperando al disco. Ese techo — no el tráfico — es lo que tumbó el sitio, y subirlo suele ser más rápido que filtrar nada.

**Ten esto presente mientras miras:** si administras un servicio centrado en la privacidad, un ataque es precisamente el momento en que más tentado estás de subir el nivel de registro y dejarlo así. Súbelo si es necesario, y luego vuelve a bajarlo y rota los archivos agresivamente después. Un incidente que deja un mes de logs de visitantes con todo detalle en disco ha cambiado un problema por otro peor y más duradero. Nuestra [guía de OpSec para servidores](https://servghost.com/es/guides/server-opsec-staying-anonymous) cubre la disciplina a la que pertenece esto.

## Los primeros diez minutos

Bajo presión, la gente recurre a la palanca más grande disponible, y la palanca más grande suele ser la equivocada. Este es el orden que limita el daño, aproximadamente de más rápido y seguro a menos:

- **Clasifica antes de actuar.** Interfaz saturada significa volumétrico; interfaz tranquila con workers ocupados significa capa 7. Treinta segundos invertidos aquí te ahorran una hora arreglando la capa equivocada.

- **Si es volumétrico, abre un ticket de inmediato** e incluye la dirección de destino, la hora de inicio, y tus contadores de interfaz. Luego deja de escribir en el servidor — no puedes arreglar esto desde dentro.

- **Si es capa 7, activa la caché primero.** Activar un caché de página completa agresivo para visitantes anónimos es la forma más rápida de convertir una caída en un encogimiento de hombros, y es la única medida que también ayuda contra el tráfico real.

- **Luego limita la tasa** — primero el endpoint objetivo, después todo lo demás. Empieza de forma conservadora. Un límite que deja fuera a tus propios usuarios es una continuación autoinfligida del ataque.

- **Bloquea solo lo que sea inequívoco.** Una docena de direcciones con cien mil solicitudes cada una, un user-agent obviamente falso, un país en el que no tienes usuarios. Resiste el impulso de escribir reglas elaboradas mientras estás bajo fuego; no las recordarás el mes que viene.

- **Reduce carga deliberadamente si es necesario.** Servir una página estática de «en mantenimiento» a los visitantes no autenticados mantiene la máquina viva, mantiene tu API en pie, y compra tiempo para pensar. Decidir qué sacrificar es mejor que dejar que lo decidan por ti.

- **Anota lo que hiciste.** Cada regla temporal que añadiste es una mina terrestre para tu yo futuro. Las reglas que ayudaron se vuelven permanentes; el resto se retira mañana.

## Límites de tasa que aguantan, y el error que comete todo el mundo

La limitación de tasa es el instrumento principal para la capa 7, y nginx lo hace bien con dos directivas que resuelven dos problemas genuinamente distintos. limit_req limita la *tasa* de solicitudes — con qué frecuencia puede preguntar un cliente. limit_conn limita la *concurrencia* — cuántas conexiones puede mantener abiertas a la vez un mismo cliente. Las inundaciones necesitan lo primero; los ataques Slowloris, que mantienen miles de conexiones casi inactivas para agotar tu grupo de workers, necesitan lo segundo. Si despliegas solo uno, estás cubierto contra la mitad del problema.

Tres detalles separan un límite que funciona de uno que es decorativo:

- **Usa un burst, y usa nodelay.** Los navegadores reales van a ráfagas — una sola vista de página dispara una docena de solicitudes de activos casi simultáneas. Un límite sin margen estrangula a los visitantes genuinos mientras un atacante que se dosifica justo por debajo del umbral pasa sin problema.

- **Limita los endpoints costosos por separado.** Tu página de búsqueda, el formulario de inicio de sesión, el restablecimiento de contraseña y cualquier endpoint que escriba en la base de datos merecen un presupuesto mucho más estricto que tus activos estáticos. Los atacantes los encuentran sin esfuerzo, porque son los que hacen daño.

- **Devuelve 429, no 503.** El código de estado es una señal para los clientes bien educados y para los motores de búsqueda de que esto es limitación y no fallo — y evita que una mala tarde se convierta en un problema de posicionamiento.

**El error que lo anula todo silenciosamente:** si algo se sitúa delante de tu servidor — un CDN, un balanceador de carga, tu propio proxy inverso — entonces cada solicitud llega desde *su* dirección, no la del visitante. Un límite de tasa por cliente entonces cuenta a todo internet como un solo cliente, y o bien no hará nada en absoluto, o bien bloqueará a toda tu audiencia de golpe. Debes configurar tu origen de IP real (en nginx, set_real_ip_from para los rangos del proxy más real_ip_header para la cabecera que envía) *antes* de que los límites signifiquen algo. Restríngelo también a los rangos propios del proxy: confiar en una cabecera proporcionada por el cliente desde el internet abierto permite que un atacante falsifique una identidad nueva en cada solicitud y atraviese sin más todos los límites que tengas.

## La caché es la mitigación más barata que desplegarás jamás

Un límite de tasa rechaza trabajo. Una caché hace que el trabajo no exista. Para todo lo que ve un visitante anónimo, el caché de página completa cambia la economía de todo el ataque: una solicitud que habría costado un viaje de ida y vuelta a la base de datos, el renderizado de una plantilla y un worker de PHP se convierte en una lectura de archivo medida en microsegundos. El mismo servidor que colapsaba a las cuatrocientas solicitudes dinámicas por segundo servirá decenas de miles de solicitudes cacheadas sin inmutarse.

Lo que importa cuando lo activas en pleno apuro:

- **Cachea solo para visitantes anónimos.** Sáltala con una cookie de sesión. Servir la página de un usuario con sesión iniciada a otro es un incidente mucho peor que la caída que estabas arreglando.

- **Sirve contenido obsoleto a propósito.** proxy_cache_use_stale de nginx con updating error timeout hace que, cuando tu backend está en apuros, los visitantes reciban una página ligeramente antigua en lugar de un error. Durante un ataque, esta es la diferencia entre un sitio que parece estar bien y uno que parece muerto.

- **Colapsa los fallos de caché duplicados.** proxy_cache_lock garantiza que mil solicitudes simultáneas de la misma página sin cachear produzcan una sola solicitud al backend, no mil. Sin esto, un ataque que anula la caché la atraviesa directamente y golpea tu base de datos a plena fuerza.

- **Neutraliza las cadenas de consulta que anulan la caché.** El truco habitual es añadir ? y un valor aleatorio para que cada solicitud sea una clave única y falle siempre. Normaliza tu clave de caché para ignorar los parámetros de consulta que tu aplicación no usa realmente.

Hay una asimetría agradable aquí que merece la pena interiorizar: cada hora que dedicas a la caché también hace que el sitio sea más rápido en su mejor día, más barato de operar, y mejor sobreviviendo al éxito. Casi ninguna otra línea de defensa paga un dividendo cuando no pasa nada malo.

## Los techos que deciden si te caes

La mayoría de los servidores no mueren porque se les acabe la CPU. Mueren porque chocan con un techo invisible que nadie fijó deliberadamente — un valor por defecto de hace una década que tenía sentido en un hardware que ya nadie usa. Bajo ataque, esto es lo que realmente se rompe primero:

- **Los workers de la aplicación.** El pm.max_children de PHP-FPM, tu número de workers de Python, el tamaño de tu clúster de Node. Este es el límite real de concurrencia de tu sitio. Cuando están todos ocupados, cada visitante adicional se pone en cola, y el sitio está caído sin importar lo ociosa que parezca la CPU. Súbelo solo hasta donde lo permita la memoria — el swapping es peor que la cola.

- **La cola de aceptación.** net.core.somaxconn y tu backlog de escucha deciden cuántas conexiones pueden esperar a ser aceptadas. Un backlog pequeño convierte una ráfaga que se podría sobrevivir en conexiones rechazadas.

- **Las cookies SYN.** net.ipv4.tcp_syncookies permite que el kernel responda a una inundación SYN sin reservar estado para conexiones que nunca se completarán. Los kernels modernos lo activan por defecto; verifícalo en lugar de darlo por hecho, porque no cuesta nada y te salva de la inundación más común que existe.

- **Los descriptores de archivo.** Cada conexión es un descriptor. El límite nofile por defecto suele ser más bajo que el número de conexiones que intentas atender, y el modo de fallo — los accepts fallando mientras todo parece sano — es genuinamente confuso a las tres de la madrugada.

- **Las conexiones a la base de datos.** Subir el número de workers sin subir el pool de conexiones simplemente mueve la cola a un lugar más difícil de ver. Estos dos números deben ajustarse juntos.

Ajusta esto en un día tranquilo, no durante un incidente. El sentido de conocerlos es que, cuando el sitio se caiga, puedas nombrar el techo que golpeó en lugar de adivinar — y un techo con nombre es un techo arreglado.

## Poner algo delante del origen

Todo lo anterior ocurre en el servidor. El siguiente paso es decidir si el servidor debería ser lo que recibe el tráfico directamente. Hay tres opciones honestas, y la respuesta correcta depende mucho más de lo que alojas que de lo que puedes permitirte.

| Enfoque | Qué te da | Qué te cuesta |
| --- | --- | --- |
| Origen expuesto directamente, reforzado | Sencillez, sin terceros, sin terminación de TLS que no controlas | Tu dirección es pública y permanente. La capa 7 es enteramente cosa tuya |
| CDN comercial o servicio de depuración | Enorme capacidad de absorción, una página de desafío a un clic, caché global | Un servicio de abuso con opinión sobre tu contenido, y una empresa que puede ver tu tráfico. Para proyectos offshore o sensibles a DMCA, esto puede ser el eslabón más débil de una configuración por lo demás cuidadosa |
| Tu propio nodo frontal — un VPS pequeño ejecutando nginx, haciendo proxy hacia un origen protegido por firewall | Control total, sin terceros en la ruta de la solicitud, una dirección que puedes quemar y sustituir, y una dirección real que permanece oculta | Sus propios límites de capacidad, y una máquina más que mantener. Dos o tres frontales en redes distintas hacen que sea considerablemente más difícil de tumbar |

El nodo frontal autoalojado merece más atención de la que suele recibir, en particular para cualquiera que eligiera hosting offshore por razones con las que un gran CDN podría no simpatizar. El patrón no tiene nada de glamuroso: nodos proxy baratos delante, origen protegido por firewall para aceptar conexiones solo desde esos nodos, DNS apuntando a los frontales. Si se ataca un frontal, lo sustituyes por una dirección nueva en minutos y el origen ni se entera. La versión completa de esta arquitectura — incluidas las seis formas en que una dirección de origen se filtra de todos modos — es el tema de nuestra guía sobre [ocultar la IP de tu servidor de origen](https://servghost.com/es/guides/hiding-your-origin-server-ip).

## Un origen oculto vale más que cualquier filtro

Merece la pena decirlo sin rodeos, porque invierte la prioridad habitual: la mitigación de DDoS más barata que tienes a tu alcance es una dirección que el atacante no tiene. Filtrar es lo que haces cuando eso ya ha fallado.

Esto importa más de lo que parece, porque las direcciones de origen se filtran constante y silenciosamente. Los registros DNS históricos de antes de poner un proxy delante sobreviven al cambio durante años. El correo enviado directamente desde la aplicación lleva la dirección en sus cabeceras. Un certificado TLS emitido sobre la dirección en crudo se publica permanentemente en los registros de Certificate Transparency. Una página de error, una redirección, o un subdominio olvidado que nunca se proxeó, todo lo delata. Si has puesto un CDN delante de un servidor que antes estuvo expuesto, da por hecho que la dirección antigua es conocida hasta que la hayas cambiado.

**El corolario es una regla de firewall, y es la línea individual más valiosa de esta guía:** en cuanto algo se sitúa delante, el origen debería rechazar las conexiones en los puertos 80 y 443 de todo lo que no sean las direcciones de ese frontal. Sin eso, el proxy es una sugerencia — cualquiera que averigüe la dirección real simplemente lo rodea y te ataca directamente, y todo lo que configuraste en el frontal se vuelve decorativo.

## Elegir hardware y ubicación para que los ataques resulten aburridos

Parte de esto se decide antes de que ocurra ningún ataque, en el momento en que eliges un plan. Tres propiedades importan mucho más de lo que sugiere la hoja de especificaciones:

- **Ancho de banda ilimitado.** En un plan medido, un ataque no es solo una caída — es una factura. El tráfico que nunca pediste y no pudiste rechazar sigue contando contra tu asignación. La transferencia ilimitada convierte un riesgo financiero en uno puramente técnico, que es una clase de problema mucho mejor.

- **Si el puerto es tuyo.** En un host virtualizado compartido, un vecino bajo ataque puede degradarte a ti, y tu propio techo de protección es compartido. El [hardware dedicado](https://servghost.com/es/dedicated) con su propio puerto elimina ambos efectos. Para un proyecto que espera atención hostil, esta es la razón más clara para dar el salto desde un [VPS](https://servghost.com/es/vps) — más que los núcleos o la RAM.

- **Dónde está la red.** Una red europea bien conectada con capacidad de tránsito real absorbe una inundación que una mal conectada no absorberá, y la jurisdicción que elegiste por razones legales también tiene características de red. Merece la pena comprobar ambas cosas al elegir entre las [ubicaciones](https://servghost.com/es/locations) disponibles.

También hay un argumento de escala que favorece discretamente la sencillez. Un sitio estático detrás de una caché en un servidor modesto es extraordinariamente difícil de tumbar; el mismo contenido en un CMS pesado con un endpoint de búsqueda sin cachear puede romperlo una sola persona decidida con un script. Reducir lo que es dinámico es una mitigación, y es gratis. Si tu proyecto realmente vive bajo carga sostenida, nuestras notas de [hosting de alto tráfico](https://servghost.com/es/use-cases/high-traffic-hosting) cubren el aspecto del dimensionamiento de la misma cuestión.

## Cinco cosas que no hay que hacer

Los modos de fallo aquí son lo bastante consistentes como para enumerarlos, y cada uno le ha costado un fin de semana a alguien:

- **No apliques null-routing sobre ti mismo.** Aplicar un agujero negro (blackholing) a tu propia dirección termina el ataque de la forma más literal posible — nadie puede alcanzarte, incluidos tus usuarios. Es un recurso de último extremo para tu proveedor, no una acción que tomes voluntariamente.

- **No trates fail2ban como protección DDoS.** Es una buena herramienta contra intentos de fuerza bruta desde unas pocas direcciones. Contra una inundación distribuida, reacciona en minutos a algo que llega en segundos, y una regla que bloquea miles de direcciones puede costar más en procesamiento de firewall de lo que te costó el ataque.

- **No pagues un rescate.** La inmensa mayoría de los correos de extorsión que amenazan con un ataque devastador vienen de gente sin ninguna capacidad que envía miles de mensajes idénticos. La pequeña minoría que sí puede cumplir volverá, porque has demostrado que pagas.

- **No te tomes la revancha.** Además de ser ilegal prácticamente en todas partes, las fuentes son terceros comprometidos. Estarías atacando a víctimas, y haciéndolo desde una dirección que es inequívocamente tuya.

- **No migres en pánico.** Cambiar de proveedor en mitad de un ataque significa que la dirección nueva es pública en minutos y no tienes ninguna configuración funcionando. Estabiliza primero, muévete deliberadamente después — y si te mudas, nuestra guía sobre [migrar sin tiempo de inactividad](https://servghost.com/es/guides/migrate-website-to-offshore-hosting) existe precisamente para que la mudanza no sea un segundo incidente.

## La versión corta

Despojado del razonamiento, el modelo de trabajo cabe en ocho líneas:

- **Clasifica primero.** Interfaz saturada significa volumétrico y le pertenece a tu proveedor. Interfaz tranquila con workers agotados significa capa 7 y te pertenece a ti.

- **Para lo volumétrico, abre un ticket** con la dirección, la marca de tiempo y tus contadores — y luego deja de tocar el servidor.

- **Cachea agresivamente para visitantes anónimos,** sirve contenido obsoleto bajo estrés, y colapsa los fallos de caché duplicados. Este es el cambio de mayor impacto que puedes hacer.

- **Limita la tasa por frecuencia de solicitudes y por concurrencia,** lo más estricto en los endpoints que más cuestan, y devuelve 429.

- **Arregla tu configuración de IP real antes que nada,** o todo límite por cliente detrás de un proxy será o bien inútil o bien catastrófico.

- **Conoce tus techos** — workers, backlog, descriptores, conexiones de base de datos — y súbelos deliberadamente en un día tranquilo.

- **Mantén la dirección de origen secreta y protegida por firewall,** de modo que solo puedan alcanzarla tus nodos frontales. Esto vale más que todos los filtros juntos.

- **Compra ancho de banda ilimitado** para que el tráfico que no pediste nunca sea también una factura.

Nada de esto te hace inmune, y quien te venda inmunidad te está vendiendo otra cosa. Lo que sí hace es sacarte de la población a la que un adolescente aburrido puede dejar fuera de línea, y meterte en la que requiere recursos genuinos e intención genuina para perturbarla — algo que, para la inmensa mayoría de los proyectos, es indistinguible de estar a salvo. El resto es el mismo trabajo sin glamour que hace que un servidor sea bueno en todo lo demás: [reforzado desde el primer día](https://servghost.com/es/guides/first-hour-vps-hardening-checklist), [restaurable en el peor](https://servghost.com/es/guides/vps-backup-strategy), y alojado en algún lugar que trate tu tráfico como el negocio que es.





Preguntas frecuentes

## DDoS en un servidor pequeño — preguntas frecuentes





### 01
¿Significa «protección DDoS incluida» que estoy a salvo de todo?



No, y la brecha es precisa, no vaga. La protección incluida es filtrado a nivel de red: descarta inundaciones volumétricas — SYN, amplificación UDP, tormentas de paquetes en bruto — aguas arriba, antes de que lleguen a tu puerto. Esa es la categoría que genuinamente no puedes manejar tú solo, así que tiene sentido que venga incluida. No inspecciona tu aplicación, así que una inundación HTTP de unos pocos miles de solicitudes por segundo contra un endpoint costoso la atraviesa intacta y tumba tu sitio mientras todas las gráficas de red se ven normales. La capa 7 es configuración tuya: caché, límites de tasa y techos de conexión.





### 02
¿Cómo distingo un ataque DDoS de un pico de tráfico normal?



Pregúntate si el tráfico quiere algo. Los visitantes reales, incluso una avalancha repentina de ellos por un enlace popular, piden páginas que existen, cargan los activos de esas páginas, llegan con referrers plausibles y se reparten entre muchas redes siguiendo un patrón natural. Un ataque suele machacar una sola ruta, ignora los activos, envía user-agents inverosímiles o ausentes, y muestra una distribución que parece sintética. Revisa tu log de acceso por solicitudes por dirección de cliente y por ruta: si un endpoint domina y no se carga nada más, es un ataque. Si se sirven las mismas páginas que querría un humano y tus referrers son reales, tienes un problema de capacidad con una causa feliz.





### 03
¿Cuál es la medida más eficaz que puedo tomar mientras sufro un ataque?



Activa el caché de página completa para visitantes anónimos, y configúralo para servir contenido obsoleto cuando el backend esté en apuros. Un límite de tasa rechaza trabajo; una caché hace que el trabajo no exista. Una solicitud que costaba una consulta a la base de datos, el renderizado de una plantilla y un worker de la aplicación se convierte en una lectura de archivo, y el mismo hardware que colapsaba con unos pocos cientos de solicitudes dinámicas por segundo servirá decenas de miles de solicitudes cacheadas. Es también la única medida de la lista que ayuda igual contra el tráfico real, así que, a diferencia de un límite de tasa, no puede volverse en contra de tus propios usuarios.





### 04
¿Por qué dejó de funcionar mi límite de tasa de nginx al poner un CDN delante?



Porque ahora cada solicitud llega desde la dirección del CDN en lugar de la del visitante, así que un límite por cliente está contando a todo internet como un solo cliente. Según el umbral, o nunca se activará, o bloqueará todo tu tráfico de golpe. Configura tu origen de IP real — en nginx, los rangos de proxy de confianza más la cabecera que envía el proxy — para que el límite vuelva a basarse en el visitante real. Restringe esa confianza a los rangos propios del proxy: si aceptas una cabecera proporcionada por el cliente desde el internet abierto, un atacante puede falsificar una identidad nueva en cada solicitud y atravesar todos los límites que tengas.





### 05
¿Basta fail2ban para detener un ataque DDoS?



No. fail2ban lee los logs a intervalos y bloquea las direcciones infractoras al superar un umbral, lo cual sirve para intentos de fuerza bruta desde un número reducido de fuentes. Un ataque distribuido llega en segundos desde miles de direcciones que envían solo un puñado de solicitudes cada una, así que el umbral nunca se alcanza, y el tiempo de reacción es de todos modos demasiado lento. Peor aún, un conjunto de reglas que crece a decenas de miles de entradas puede consumir más recursos que el propio ataque. Resérvalo para SSH y los endpoints de inicio de sesión, y maneja las inundaciones con caché, limitación de tasa y un filtro aguas arriba.





### 06
¿Debería usar un CDN, o montar mi propio proxy inverso delante?



Depende de lo que alojas, más que de tu presupuesto. Un CDN comercial aporta una capacidad de absorción que no puedes igualar y una página de desafío a un clic de distancia, pero heredas su servicio de abuso y puede ver tu tráfico — lo cual, para proyectos offshore o sensibles a DMCA, suele ser el eslabón más débil de una configuración por lo demás cuidadosa. Tus propios nodos frontales cuestan más trabajo y tienen límites de capacidad reales, pero no hay terceros en la ruta de la solicitud, y un frontal atacado se puede sustituir por una dirección nueva en minutos. En cualquier caso, el origen debe estar protegido por firewall para aceptar tráfico web solo desde el frontal, o toda la disposición es decorativa.





### 07
¿Un ataque me va a costar dinero además de tiempo de actividad?



En un plan medido, sí — el tráfico que nunca pediste y no pudiste rechazar sigue contando contra tu asignación de transferencia, y una inundación sostenida puede producir una factura por exceso más grande que un año de hosting. Esta es la razón práctica por la que el ancho de banda ilimitado importa más de lo que parece en una hoja de especificaciones: convierte un riesgo financiero en uno puramente técnico. También conviene saber de antemano que, si un ataque amenaza la infraestructura compartida, los proveedores pueden aplicar una ruta nula temporal a la dirección (null-routing); es una práctica estándar en todas partes, no un fallo de tu proveedor en particular.





### 08
¿Mudarse a un proveedor offshore o sin KYC hace más probables los ataques?



La elección de hosting en sí es neutra; lo que atrae la atención es lo que ejecutas. Los servidores de juegos, los foros, el streaming, los marketplaces y cualquier cosa con un competidor o un rencor de por medio atraen ataques sin importar la jurisdicción. Lo que sí cambia offshore es tu margen de maniobra: es menos probable que te den de baja por resultar incómodo, lo cual tiene doble filo — la protección es técnica y no contractual. Elige una ubicación con capacidad de tránsito genuina, contrata ancho de banda ilimitado, mantén oculta la dirección de origen, y trata la capa 7 como responsabilidad tuya desde el primer día y no desde el primer incidente.




Guías relacionadas

## Seguir leyendo


[### Cómo Elegir una Jurisdicción de Alojamiento Offshore en 2026

Compra


Un marco práctico de decisión para elegir una jurisdicción offshore: legislación de retención de datos, exposición al MLAT, postura ante DMCA, velocidad judicial y aplicación real — país por país.


FAQ de 6 preguntas](https://servghost.com/es/guides/choosing-an-offshore-jurisdiction)
[### VPS vs Servidor Dedicado para Cargas de Trabajo Críticas de Privacidad

Compra


Cuándo un VPS es suficiente, cuándo la tenencia compartida es un riesgo y cuándo el bare metal es la única respuesta honesta. Aislamiento de hardware, riesgo de hipervisor y coste frente a modelo de amenazas.


FAQ de 6 preguntas](https://servghost.com/es/guides/vps-vs-dedicated-for-privacy)
[### VPN Autogestionada en un VPS Sin KYC: WireGuard vs OpenVPN

Operaciones


Por qué una VPN autogestionada supera a los proveedores comerciales, y cómo WireGuard y OpenVPN se comparan realmente en privacidad, rendimiento y riesgo operativo en 2026.


FAQ de 6 preguntas](https://servghost.com/es/guides/self-hosted-vpn-wireguard-vs-openvpn)
[### RTX 4090 vs H100 SXM5 para inferencia IA (y dónde encaja la RTX 5090)

Compra


Guía de decisión de compra: qué GPU NVIDIA elegir para LLM, imagen, video, voz y cargas de trabajo de fine-tuning autoalojadas en 2026. RTX 4090 vs RTX 5090 vs H100 SXM5 vs dual H100 — VRAM, rendimiento, $/token, cuándo gana cada una.


FAQ de 6 preguntas](https://servghost.com/es/guides/rtx-4090-vs-h100-for-ai-inference)
[### RDP Windows Offshore para Trading Forex con MT4 / MT5 / cTrader

Operaciones


Guía completa: por qué usar un RDP Windows para trading forex, cómo elegir una jurisdicción offshore de baja latencia, configuración de MT4 / MT5 / cTrader / Expert Advisor, latencia a servidores de broker, y el proceso de checkout sin KYC.


FAQ de 6 preguntas](https://servghost.com/es/guides/offshore-windows-rdp-for-forex-trading)
[### Alojamiento Ignorado por DMCA: Lo Que Realmente Significa en 2026

Compra


Qué ofrece realmente el alojamiento «ignorado por DMCA», qué jurisdicciones lo respaldan de verdad, para qué cargas de trabajo es necesario, y las trampas sobre derechos de autor que el término no cubre.


FAQ de 6 preguntas](https://servghost.com/es/guides/dmca-ignored-hosting-explained)
[### Registro Anónimo de Dominios con Cripto: Privacidad WHOIS en 2026

Privacidad


Una guía práctica de 2026 para registrar dominios sin revelar tu identidad: regímenes WHOIS por TLD, elección de registrador, opciones de pago en cripto, y los errores operativos que te delatan igualmente.


FAQ de 6 preguntas](https://servghost.com/es/guides/anonymous-domain-registration-with-crypto)
[### Pagos Cripto para Alojamiento: Monero vs Bitcoin vs USDT

Privacidad


Cómo la elección de la moneda afecta lo que tu proveedor aprende sobre ti. Privacidad, comisiones, finalidad y exposición al análisis de cadena para XMR, BTC y USDT — con una recomendación clara.


FAQ de 6 preguntas](https://servghost.com/es/guides/crypto-payments-monero-vs-bitcoin-vs-usdt)
[### ¿Es realmente anónimo el hosting offshore? Una respuesta honesta

Privacidad


El hosting offshore sin KYC elimina la identidad que un proveedor normal recopila, pero «anónimo» depende del pago, del registro de logs del proveedor y de tu propia opsec. Esto es lo que realmente se puede rastrear.


FAQ de 6 preguntas](https://servghost.com/es/guides/is-offshore-hosting-truly-anonymous)
[### La primera hora de hardening de un VPS: una checklist

Operaciones


Una checklist concreta y ordenada para asegurar un VPS nuevo en menos de una hora: claves SSH, un firewall, fail2ban, actualizaciones automáticas y la reducción de superficie de ataque que detiene la mayoría de los ataques oportunistas.


FAQ de 6 preguntas](https://servghost.com/es/guides/first-hour-vps-hardening-checklist)
[### ¿Qué es el Hosting sin KYC? Definición, Legalidad y Cómo Funciona

Privacidad


El hosting sin KYC te permite alquilar un servidor sin ninguna verificación de identidad: sin nombre, sin correo electrónico, sin identificación. Aquí encontrarás exactamente qué significa, cómo funciona técnicamente, si es legal y cómo elegir un proveedor genuino.


FAQ de 6 preguntas](https://servghost.com/es/guides/what-is-no-kyc-hosting)
[### ¿Es Legal el Hosting Offshore? La Respuesta Honesta para 2026

Compra


El hosting offshore es legal, tanto para ti como para el proveedor. Aquí explicamos qué significa realmente el término, dónde está la línea legal, los mitos que vale la pena descartar y cómo utilizarlo de forma responsable.


FAQ de 6 preguntas](https://servghost.com/es/guides/is-offshore-hosting-legal)
[### Cómo pagar el alojamiento con Monero (XMR) — Guía paso a paso

Privacidad


Guía paso a paso para pagar un VPS o servidor dedicado con Monero (XMR): por qué XMR es la opción más privada, cómo adquirirlo y cómo funciona el proceso de pago — desde la factura hasta un servidor en funcionamiento en minutos.


FAQ de 6 preguntas](https://servghost.com/es/guides/how-to-pay-for-hosting-with-monero)
[### Cómo alojar un sitio web de forma anónima — Guía práctica 2026

Privacidad


Una guía práctica y por capas para alojar un sitio web sin revelar tu identidad: la cuenta, el pago, el dominio, la jurisdicción, la conexión y el contenido — cada capa explicada en detalle.


FAQ de 6 preguntas](https://servghost.com/es/guides/how-to-host-a-website-anonymously)
[### Cómo configurar una VPN WireGuard en un VPS — Guía paso a paso

Operaciones


Crea tu propia VPN privada en un VPS con WireGuard: por qué una VPN autoalojada supera a una comercial, la configuración completa desde la instalación hasta el primer cliente conectado, y cómo reforzar la seguridad.


FAQ de 6 preguntas](https://servghost.com/es/guides/how-to-set-up-wireguard-vpn-on-a-vps)
[### Cómo alojar tu propio LLM en un servidor GPU — Guía 2026

Operaciones


Ejecuta tu propio modelo de lenguaje en un servidor GPU alquilado: por qué el autoalojamiento supera a una API, qué GPU y modelo elegir, la configuración con Ollama o vLLM, y cuánto cuesta.


FAQ de 6 preguntas](https://servghost.com/es/guides/self-host-an-llm-on-a-gpu-server)
[### Hosting Bulletproof vs Hosting Offshore — ¿Cuál es la diferencia?

Compra


El hosting bulletproof y el hosting offshore se confunden constantemente, pero no son lo mismo. Aquí encontrarás la diferencia real, por qué importa y cuál es el que verdaderamente necesitas.


FAQ de 6 preguntas](https://servghost.com/es/guides/bulletproof-vs-offshore-hosting)
[### Cómo comprar un VPS con Bitcoin — paso a paso (2026)

Compra


Una guía accesible para comprar un VPS con Bitcoin: cómo obtener BTC, elegir un plan, pagar la factura y lo que obtienes a cambio — un servidor en funcionamiento sin tarjeta y sin nombre vinculado.


FAQ de 6 preguntas](https://servghost.com/es/guides/how-to-buy-a-vps-with-bitcoin)
[### Los mejores países para hosting ignorado por DMCA en 2026

Compra


Dónde alojar cuando necesitas servidores fuera del alcance de las órdenes de retirada al estilo estadounidense: las jurisdicciones que funcionan, qué significa realmente «ignorado por DMCA» y cómo elegir.


FAQ de 6 preguntas](https://servghost.com/es/guides/best-countries-for-dmca-ignored-hosting)
[### Cómo alojar un servicio oculto de Tor (sitio .onion) — Guía 2026

Operaciones


Configura un servicio onion de Tor en un VPS: qué es un servicio oculto, por qué es la forma más sólida de alojamiento anónimo, el proceso completo de configuración y cómo mantener el anonimato real.


FAQ de 6 preguntas](https://servghost.com/es/guides/how-to-host-a-tor-hidden-service)
[### Configuración de un servidor de correo offshore — Aloja tu propio email privado en 2026

Operaciones


Ejecuta tu propio servidor de correo privado en un VPS offshore: por qué alojar el email tú mismo, qué necesitas, la configuración práctica con una solución todo-en-uno y cómo garantizar la entregabilidad.


FAQ de 6 preguntas](https://servghost.com/es/guides/offshore-mail-server-setup)
[### Guía de alojamiento de nodos cripto — Ejecuta un nodo blockchain en un VPS

Operaciones


Cómo alojar un nodo blockchain en un servidor: por qué ejecutar tu propio nodo, cómo dimensionar el servidor para Bitcoin, Ethereum, Monero y otras redes, la configuración inicial y cómo mantenerlo privado.


FAQ de 6 preguntas](https://servghost.com/es/guides/crypto-node-hosting-guide)
[### Hosting GPU para Stable Diffusion — Monta tu propio servidor de imágenes

Operaciones


Ejecuta Stable Diffusion en tu propio servidor GPU: por qué autoalojar la generación de imágenes, qué GPU elegir, la configuración con una interfaz web y qué cuesta frente a un servicio alojado.


FAQ de 6 preguntas](https://servghost.com/es/guides/gpu-hosting-for-stable-diffusion)
[### OpSec para servidores — Mantener el anonimato cuando gestionas un servidor

Privacidad


Seguridad operacional para quien gestiona un servidor anónimo: los errores que desvelan identidades, los hábitos que los previenen y cómo mantener las identidades verdaderamente separadas.


FAQ de 6 preguntas](https://servghost.com/es/guides/server-opsec-staying-anonymous)
[### Guía de configuración de seedbox — Crea tu propio seedbox privado en 2026

Operaciones


Cómo construir tu propio seedbox en un servidor: qué es un seedbox, cómo dimensionarlo, instalar un cliente torrent con interfaz web y mantenerlo privado y seguro.


FAQ de 6 preguntas](https://servghost.com/es/guides/seedbox-setup-guide)
[### Cómo eludir la censura DPI con tu propio VPS (guía 2026)

Privacidad


¿Tu VPN dejó de funcionar? Cómo eludir la censura DPI con tu propio VPS: qué detecta realmente la inspección profunda de paquetes, cuál de los cinco protocolos de 2026 vence a cada tipo de bloqueo, y una guía completa de VLESS+REALITY paso a paso.


FAQ de 6 preguntas](https://servghost.com/es/guides/bypass-dpi-censorship-with-your-own-vps)
[### Cifrado de disco completo en un VPS: configurar LUKS y qué protege

Operaciones


Cómo cifrar un VPS con LUKS: volúmenes cifrados, cifrado de raíz completa con desbloqueo remoto por SSH, los ajustes que importan en un servidor pequeño, y qué detiene realmente el cifrado de disco.


FAQ de 8 preguntas](https://servghost.com/es/guides/full-disk-encryption-on-a-vps)
[### Ocultar la IP de origen: CDN, proxy inverso y qué se filtra

Privacidad


Si conviene poner un CDN delante de un servidor offshore: qué oculta, el servicio de abuso que heredas, las seis formas en que la IP de origen se filtra igualmente, y cómo auditar la tuya.


FAQ de 8 preguntas](https://servghost.com/es/guides/hiding-your-origin-server-ip)
[### Backup de VPS: cifrado, fuera del sitio y que realmente restaura

Operaciones


Tu proveedor no guarda copias. Qué destruye realmente un servidor, por qué el backup por push muere con él, restic vs Borg, y cómo probar que restaura de verdad.


FAQ de 8 preguntas](https://servghost.com/es/guides/vps-backup-strategy)
[### Autoalojar un servidor Matrix: federación, metadatos y qué no cifra el E2EE

Operaciones


Qué cambia autoalojar tu propio servidor Matrix: Synapse frente a Conduit, el server_name que no puedes cambiar y lo que la federación sigue revelando.


FAQ de 8 preguntas](https://servghost.com/es/guides/self-host-a-matrix-server)
[### Cómo migrar un sitio web a alojamiento offshore sin inactividad

Operaciones


El orden que convierte una migración de servidor en algo aburrido: baja el TTL de DNS con días de antelación, mantén los dos servidores en paralelo, congela las escrituras solo minutos, no horas, y limpia el rastro de DNS pasivo, Certificate Transparency y WHOIS que deja el traslado.


FAQ de 8 preguntas](https://servghost.com/es/guides/migrate-website-to-offshore-hosting)
[### How to Self-Host a Crypto Payment Gateway with BTCPay Server

Operaciones


Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out.


FAQ de 8 preguntas](https://servghost.com/es/guides/self-host-a-crypto-payment-gateway)




## Ponlo en un lugar que filtre las inundaciones



Servidores KVM offshore en siete jurisdicciones con filtrado DDoS L3/L4, ancho de banda ilimitado, root completo y almacenamiento NVMe. Sin KYC, pago en cripto, desplegado minutos después de confirmarse la transacción.


[Ver planes VPS](https://servghost.com/es/vps)
[Servidores Dedicados](https://servghost.com/es/dedicated)
[Hosting offshore](https://servghost.com/es/offshore-hosting)


## Structured data (JSON-LD)

```json
{
    "@context": "https://schema.org",
    "@type": "Organization",
    "@id": "https://servghost.com/#organization",
    "name": "ServGhost",
    "url": "https://servghost.com",
    "description": "VPS y servidores dedicados offshore en 7 jurisdicciones privacy-friendly. Sin KYC, sin registros, solo criptomonedas. Privacidad por arquitectura.",
    "logo": {
        "@type": "ImageObject",
        "url": "https://servghost.com/ServGhost.webp",
        "width": 512,
        "height": 512
    },
    "foundingDate": "2025",
    "areaServed": [
        {
            "@type": "Country",
            "name": "Iceland"
        },
        {
            "@type": "Country",
            "name": "Panama"
        },
        {
            "@type": "Country",
            "name": "Moldova"
        },
        {
            "@type": "Country",
            "name": "Romania"
        },
        {
            "@type": "Country",
            "name": "Switzerland"
        },
        {
            "@type": "Country",
            "name": "Netherlands"
        },
        {
            "@type": "Country",
            "name": "Russia"
        }
    ],
    "knowsAbout": [
        "Offshore hosting",
        "Offshore VPS",
        "Bare-metal dedicated servers",
        "DMCA-ignored hosting",
        "No KYC hosting",
        "Cryptocurrency payments",
        "Privacy engineering",
        "Token-based authentication",
        "Anonymous domain name registration",
        "No-KYC domain registrar",
        "WHOIS privacy",
        "Cheap .com domains",
        "Crypto-paid domain names",
        "NVIDIA GPU compute",
        "Windows RDP hosting",
        "Agentic commerce"
    ],
    "contactPoint": {
        "@type": "ContactPoint",
        "contactType": "customer support",
        "url": "https://servghost.com/contact",
        "availableLanguage": [
            "en",
            "ru",
            "zh",
            "es",
            "fr",
            "de",
            "pt",
            "ar",
            "ja",
            "ko",
            "hi",
            "id",
            "it",
            "tr",
            "fa",
            "vi"
        ]
    },
    "sameAs": [
        "https://servghost.com/canary",
        "https://servghost.com/press"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "WebSite",
    "@id": "https://servghost.com/#website",
    "url": "https://servghost.com",
    "name": "ServGhost",
    "publisher": {
        "@id": "https://servghost.com/#organization"
    },
    "inLanguage": [
        "en",
        "ru",
        "zh",
        "es",
        "fr",
        "de",
        "pt",
        "ar",
        "ja",
        "ko",
        "hi",
        "id",
        "it",
        "tr",
        "fa",
        "vi"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": "Protección DDoS en VPS: dónde acaba tu proveedor y empieza la capa 7",
    "description": "Tu proveedor filtra las inundaciones de paquetes; las de solicitudes son cosa tuya. Cómo funciona la depuración L3/L4 y qué caché, límites de tasa y techos de conexión mantienen en línea a un VPS offshore mientras lo atacan.",
    "image": "https://servghost.com/assets/img/guides/surviving-a-ddos-attack-on-your-vps.webp?v=1788769011",
    "author": {
        "@type": "Organization",
        "@id": "https://servghost.com/#editorial",
        "name": "ServGhost Editorial",
        "url": "https://servghost.com/about",
        "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.",
        "knowsAbout": [
            "Offshore hosting jurisdictions",
            "Data retention law",
            "MLAT and judicial cooperation",
            "WireGuard and OpenVPN deployment",
            "Tor relay operation",
            "Monero and Bitcoin payment privacy",
            "KVM virtualization and bare-metal hosting",
            "DMCA-ignored hosting"
        ],
        "parentOrganization": {
            "@id": "https://servghost.com/#organization"
        }
    },
    "publisher": {
        "@id": "https://servghost.com/#organization"
    },
    "datePublished": "2026-09-07T00:00:00+00:00",
    "dateModified": "2026-09-07T00:00:00+00:00",
    "mainEntityOfPage": "https://servghost.com/guides/surviving-a-ddos-attack-on-your-vps",
    "inLanguage": "es",
    "keywords": "protección DDoS para VPS, cómo detener un ataque DDoS en un servidor, mitigación DDoS capa 7, limitar tasa de peticiones en nginx, hosting offshore con protección DDoS, filtrado DDoS L3 L4, cómo frenar una inundación SYN, ocultar la IP del servidor de origen",
    "articleSection": "Operaciones",
    "wordCount": 4673
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
        {
            "@type": "Question",
            "name": "¿Significa «protección DDoS incluida» que estoy a salvo de todo?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "No, y la brecha es precisa, no vaga. La protección incluida es filtrado a nivel de red: descarta inundaciones volumétricas — SYN, amplificación UDP, tormentas de paquetes en bruto — aguas arriba, antes de que lleguen a tu puerto. Esa es la categoría que genuinamente no puedes manejar tú solo, así que tiene sentido que venga incluida. No inspecciona tu aplicación, así que una inundación HTTP de unos pocos miles de solicitudes por segundo contra un endpoint costoso la atraviesa intacta y tumba tu sitio mientras todas las gráficas de red se ven normales. La capa 7 es configuración tuya: caché, límites de tasa y techos de conexión."
            }
        },
        {
            "@type": "Question",
            "name": "¿Cómo distingo un ataque DDoS de un pico de tráfico normal?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Pregúntate si el tráfico quiere algo. Los visitantes reales, incluso una avalancha repentina de ellos por un enlace popular, piden páginas que existen, cargan los activos de esas páginas, llegan con referrers plausibles y se reparten entre muchas redes siguiendo un patrón natural. Un ataque suele machacar una sola ruta, ignora los activos, envía user-agents inverosímiles o ausentes, y muestra una distribución que parece sintética. Revisa tu log de acceso por solicitudes por dirección de cliente y por ruta: si un endpoint domina y no se carga nada más, es un ataque. Si se sirven las mismas páginas que querría un humano y tus referrers son reales, tienes un problema de capacidad con una causa feliz."
            }
        },
        {
            "@type": "Question",
            "name": "¿Cuál es la medida más eficaz que puedo tomar mientras sufro un ataque?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Activa el caché de página completa para visitantes anónimos, y configúralo para servir contenido obsoleto cuando el backend esté en apuros. Un límite de tasa rechaza trabajo; una caché hace que el trabajo no exista. Una solicitud que costaba una consulta a la base de datos, el renderizado de una plantilla y un worker de la aplicación se convierte en una lectura de archivo, y el mismo hardware que colapsaba con unos pocos cientos de solicitudes dinámicas por segundo servirá decenas de miles de solicitudes cacheadas. Es también la única medida de la lista que ayuda igual contra el tráfico real, así que, a diferencia de un límite de tasa, no puede volverse en contra de tus propios usuarios."
            }
        },
        {
            "@type": "Question",
            "name": "¿Por qué dejó de funcionar mi límite de tasa de nginx al poner un CDN delante?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Porque ahora cada solicitud llega desde la dirección del CDN en lugar de la del visitante, así que un límite por cliente está contando a todo internet como un solo cliente. Según el umbral, o nunca se activará, o bloqueará todo tu tráfico de golpe. Configura tu origen de IP real — en nginx, los rangos de proxy de confianza más la cabecera que envía el proxy — para que el límite vuelva a basarse en el visitante real. Restringe esa confianza a los rangos propios del proxy: si aceptas una cabecera proporcionada por el cliente desde el internet abierto, un atacante puede falsificar una identidad nueva en cada solicitud y atravesar todos los límites que tengas."
            }
        },
        {
            "@type": "Question",
            "name": "¿Basta fail2ban para detener un ataque DDoS?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "No. fail2ban lee los logs a intervalos y bloquea las direcciones infractoras al superar un umbral, lo cual sirve para intentos de fuerza bruta desde un número reducido de fuentes. Un ataque distribuido llega en segundos desde miles de direcciones que envían solo un puñado de solicitudes cada una, así que el umbral nunca se alcanza, y el tiempo de reacción es de todos modos demasiado lento. Peor aún, un conjunto de reglas que crece a decenas de miles de entradas puede consumir más recursos que el propio ataque. Resérvalo para SSH y los endpoints de inicio de sesión, y maneja las inundaciones con caché, limitación de tasa y un filtro aguas arriba."
            }
        },
        {
            "@type": "Question",
            "name": "¿Debería usar un CDN, o montar mi propio proxy inverso delante?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Depende de lo que alojas, más que de tu presupuesto. Un CDN comercial aporta una capacidad de absorción que no puedes igualar y una página de desafío a un clic de distancia, pero heredas su servicio de abuso y puede ver tu tráfico — lo cual, para proyectos offshore o sensibles a DMCA, suele ser el eslabón más débil de una configuración por lo demás cuidadosa. Tus propios nodos frontales cuestan más trabajo y tienen límites de capacidad reales, pero no hay terceros en la ruta de la solicitud, y un frontal atacado se puede sustituir por una dirección nueva en minutos. En cualquier caso, el origen debe estar protegido por firewall para aceptar tráfico web solo desde el frontal, o toda la disposición es decorativa."
            }
        },
        {
            "@type": "Question",
            "name": "¿Un ataque me va a costar dinero además de tiempo de actividad?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "En un plan medido, sí — el tráfico que nunca pediste y no pudiste rechazar sigue contando contra tu asignación de transferencia, y una inundación sostenida puede producir una factura por exceso más grande que un año de hosting. Esta es la razón práctica por la que el ancho de banda ilimitado importa más de lo que parece en una hoja de especificaciones: convierte un riesgo financiero en uno puramente técnico. También conviene saber de antemano que, si un ataque amenaza la infraestructura compartida, los proveedores pueden aplicar una ruta nula temporal a la dirección (null-routing); es una práctica estándar en todas partes, no un fallo de tu proveedor en particular."
            }
        },
        {
            "@type": "Question",
            "name": "¿Mudarse a un proveedor offshore o sin KYC hace más probables los ataques?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "La elección de hosting en sí es neutra; lo que atrae la atención es lo que ejecutas. Los servidores de juegos, los foros, el streaming, los marketplaces y cualquier cosa con un competidor o un rencor de por medio atraen ataques sin importar la jurisdicción. Lo que sí cambia offshore es tu margen de maniobra: es menos probable que te den de baja por resultar incómodo, lo cual tiene doble filo — la protección es técnica y no contractual. Elige una ubicación con capacidad de tránsito genuina, contrata ancho de banda ilimitado, mantén oculta la dirección de origen, y trata la capa 7 como responsabilidad tuya desde el primer día y no desde el primer incidente."
            }
        }
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
        {
            "@type": "ListItem",
            "position": 1,
            "name": "Inicio",
            "item": "https://servghost.com/es/"
        },
        {
            "@type": "ListItem",
            "position": 2,
            "name": "Guías de Alojamiento Privado",
            "item": "https://servghost.com/es/guides"
        },
        {
            "@type": "ListItem",
            "position": 3,
            "name": "Protección DDoS en VPS: dónde acaba tu proveedor y empieza la capa 7",
            "item": "https://servghost.com/es/guides/surviving-a-ddos-attack-on-your-vps"
        }
    ]
}
```