Auditoría de servidor web (Apache/Nginx, PHP-FPM, MySQL): rendimiento y seguridad

¿Tu sitio web es lento, da errores 502/504 o le falta seguridad? ¿Tu servidor consume el 100 % de la CPU con solo 50 visitantes simultáneos? Realizo una auditoría técnica completa de tu servidor (Ubuntu/Debian, OVH/Scaleway, Contabo...) para reducir el TTFB, estabilizar la carga y reforzar la seguridad.

La auditoría abarca todo el stack técnico: protocolos de red (TLS/HTTP2), configuración del servidor web (Nginx/Apache), optimización de PHP-FPM, análisis de las consultas lentas de MySQL, hardening del sistema e implementación de herramientas de monitorización. Entregable: un informe claro y priorizado, con la posibilidad de que yo mismo aplique las correcciones.

¿Por qué hacer una auditoría de tu servidor web?

Los síntomas que deben alertarte

Tu infraestructura de servidor muestra signos de debilidad si te encuentras con uno o varios de estos problemas:

Rendimiento degradado:

• Tiempo de respuesta del servidor (TTFB) superior a 600 ms, cuando el objetivo es < 200 ms
• El sitio se vuelve lento o inaccesible en cuanto aumenta el tráfico (50-100 visitantes simultáneos)
• Las páginas tardan 5-10 segundos en cargar, cuando el HTML por sí solo debería servirse en < 1 segundo
• Las Core Web Vitals están en zona roja (LCP > 4 s, TTFB > 800 ms)

Errores recurrentes:

• Errores 502 Bad Gateway o 504 Gateway Timeout varias veces al día
• Errores 500 Internal Server Error sin causa aparente en los logs de la aplicación
• Conexiones de PHP-FPM que se saturan ("max children reached")
• MySQL que rechaza nuevas conexiones ("Too many connections")

Problemas de estabilidad:

• El servidor necesita reinicios frecuentes (varias veces por semana)
• Consumo de CPU o RAM al 90-100 % de forma permanente sin un pico de tráfico que lo justifique
• Los procesos de PHP-FPM o MySQL terminan de forma aleatoria (OOM Killer)
• Los logs muestran decenas de consultas lentas (> 2 segundos) cada día

Vulnerabilidades de seguridad:

• Certificado SSL/TLS caducado o configuración débil (cifrados obsoletos, sin HSTS)
• Ningún firewall configurado o reglas demasiado permisivas
• Ninguna protección contra ataques de fuerza bruta (sin fail2ban)
• Versiones de PHP, MySQL o del sistema operativo obsoletas y sin parches
• Acceso SSH como root con contraseña (en lugar de claves SSH)

Impacto de estos problemas en el negocio

Un servidor mal configurado tiene consecuencias directas y medibles en tu actividad:

Pérdida de ingresos: un sitio que tarda 5 segundos en cargar pierde el 20 % de sus visitantes (estudio de Google). Para una tienda online que factura 50.000 € al mes, eso supone 10.000 € de ingresos perdidos cada mes.

Penalizaciones SEO: Google penaliza los sitios lentos en su algoritmo. Una página que pasa de 2 a 5 segundos de carga puede perder entre el 30 y el 50 % de su tráfico orgánico en pocos meses.

Costos de infraestructura inflados: un servidor mal optimizado suele requerir una costosa ampliación de hardware (pasar de 4 a 8 CPU, duplicar la RAM), cuando una simple optimización del software resolvería el problema por 10 veces menos.

Riesgo de hackeo: el 43 % de los ciberataques se dirigen a pymes (informe de Verizon 2024). Un servidor sin hardening es una puerta de entrada para el phishing, el robo de datos de clientes o el ransomware.

Lo que analizo en detalle

Mi auditoría de servidor abarca 7 capas técnicas esenciales, con mediciones de antes y después para cuantificar las mejoras.

1. Red y protocolo

Lo que verifico:

• Configuración TLS/HTTPS: versión del protocolo (TLS 1.2 como mínimo, idealmente 1.3), suites de cifrado seguras, cadena de certificados completa
• Cabeceras de seguridad: HSTS, CSP, X-Frame-Options, X-Content-Type-Options
• HTTP/2 o HTTP/3 activado para la multiplexación y la compresión de cabeceras
• Compresión Gzip/Brotli configurada para HTML/CSS/JS/JSON
• DNS: tiempo de resolución, configuración de DNSSEC si corresponde

Lo que revela: los cifrados obsoletos (RC4, 3DES) hacen que tu sitio sea vulnerable a ataques BEAST o POODLE. La ausencia de HTTP/2 cuesta un 20-30 % de velocidad en las páginas con muchos recursos. Un TTFB de DNS elevado (> 100 ms) ralentiza sistemáticamente todas las solicitudes.

Impacto medible: pasar a TLS 1.3 + HTTP/2 + Brotli = reducción del 25-40 % del tiempo de carga total y calificación A+ en SSL Labs.

2. Configuración de Nginx / Apache

Lo que verifico:

• Caché estática: directivas expires, cache-control, etag para imágenes/CSS/JS
• Cabeceras de compresión: gzip_types, brotli_types
• Logs: formato personalizado con $request_time y $upstream_response_time para depurar
• Rate limiting: protección contra scrapers y bots agresivos
• WAF básico: ModSecurity o limit_req de Nginx para bloquear los patrones de ataque habituales
• Archivos de configuración: worker_processes, worker_connections, keepalive_timeout, client_max_body_size

Lo que revela: unas worker_connections en 768 en lugar de 4096 limitan artificialmente el número de conexiones simultáneas. La ausencia de caché estática obliga al navegador a volver a descargar los recursos en cada visita. Un client_max_body_size de 2M bloquea la subida de archivos multimedia.

Impacto medible: una configuración óptima = 50-60 % de ancho de banda ahorrado gracias a la caché del navegador + capacidad para gestionar 4 veces más conexiones simultáneas.

3. PHP-FPM: el cuello de botella invisible

Lo que verifico:

• Estrategia de gestión de procesos: pm = dynamic frente a static frente a ondemand
• Dimensionamiento: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers
• Límites: pm.max_requests (reciclaje de los workers), request_timeout, request_terminate_timeout
• Opcache: opcache.memory_consumption, opcache.interned_strings_buffer, opcache.max_accelerated_files, tasa de aciertos
• Límites de PHP: memory_limit, max_execution_time, post_max_size, upload_max_filesize
• Slow log: activación y análisis de las solicitudes PHP lentas (> 1 s)

Lo que revela: es EL principal punto de bloqueo en el 80 % de los servidores. Ejemplo típico: pm.max_children = 5 en un servidor de 4 CPU → a partir de 6 solicitudes simultáneas, las siguientes se ponen en cola y se producen timeouts.

Un opcache mal configurado (demasiado pequeño, sin preloading de PHP 8.x) obliga a PHP a recompilar los scripts en cada solicitud, lo que multiplica la carga de CPU por 5-10.

Impacto medible: pasar de pm.max_children = 5 a pm.max_children = 40 (dimensionado según la RAM disponible) + opcache optimizado = reducción del 70 % del TTFB + desaparición de los errores "502 Bad Gateway".

Ejemplo concreto: sitio WordPress con WooCommerce, 4 GB de RAM, pm.max_children = 5 (valor por defecto).

• Antes: errores 502 a partir de 8 visitantes simultáneos, TTFB de 3-6 segundos
• Después: pm.max_children = 30, pm = dynamic, opcache activado → TTFB de 0,4 s, ningún 502 hasta 100 visitantes simultáneos

4. Base de datos MySQL / MariaDB

Lo que verifico:

• Configuración de las conexiones: max_connections, wait_timeout, interactive_timeout
• Búferes y caché: innodb_buffer_pool_size, query_cache_size (si MySQL < 8.0), tmp_table_size
• Slow query log: activación y análisis de las consultas de > 1 segundo
• Índices que faltan: EXPLAIN en las consultas más frecuentes para identificar los full table scans
• Bloqueos: detección de deadlocks y de transacciones largas
• Optimización de tablas: fragmentación, tablas sin uso, ANALYZE TABLE

Lo que revela: un innodb_buffer_pool_size de 128 MB (valor por defecto) en un servidor con 16 GB de RAM = MySQL no puede almacenar en caché los datos de uso frecuente y recurre constantemente al disco.

Las consultas sin índice obligan a MySQL a recorrer 500.000 filas en lugar de 10, lo que multiplica el tiempo de ejecución por 5000 (de 0,001 s a 5 s).

Impacto medible: innodb_buffer_pool_size ajustado al 70 % de la RAM + 3-5 índices estratégicos añadidos = reducción del 80 % de las slow queries + tiempo de respuesta de la página dividido por 3.

5. Rendimiento de la aplicación y TTFB

Lo que mido:

• TTFB (Time To First Byte) desde distintos puntos geográficos: objetivo < 200 ms para Europa
• LCP (Largest Contentful Paint): objetivo < 2,5 s
• Tiempo de generación del HTML puro (sin recursos): debe ser < 400 ms para una página dinámica
• Número de consultas SQL por página: más de 50 consultas = problema N+1 que hay que investigar
• Tamaño y peso de los recursos: imágenes sin optimizar, JS/CSS sin minificar
• Estrategia de caché de la aplicación: Redis/Memcached, caché HTML estática (Varnish, fastcgi_cache de nginx)

Lo que revela: un TTFB de 2-4 segundos indica que el servidor tarda ese tiempo solo en empezar a enviar los datos. Incluso con una conexión de fibra, el usuario espera. El problema suele ser una combinación de PHP lento + consultas MySQL sin optimizar + ausencia de caché.

Impacto medible: optimización combinada (PHP-FPM + MySQL + caché Redis) = el TTFB pasa de 2,8 s a 0,3 s y el LCP de 6 s a 2,1 s → paso a la categoría "Good" de las Core Web Vitals.

6. Seguridad del sistema y hardening

Lo que verifico:

• Firewall: UFW o iptables configurado, mínimo de puertos abiertos (22, 80, 443), bloqueo de escaneos de puertos
• Fail2ban: protección de SSH, HTTP y MySQL contra ataques de fuerza bruta
• Acceso SSH: desactivación del inicio de sesión como root, autenticación solo con claves SSH, puerto no estándar
• Usuarios y permisos: ningún servicio ejecutado como root, separación de los usuarios web/db
• Actualizaciones: versiones de PHP, MySQL y del sistema operativo al día con los parches de seguridad
• Copias de seguridad: frecuencia, retención, prueba de restauración, almacenamiento fuera del servidor
• Rotación de logs: logrotate configurado, compresión, eliminación automática de los logs antiguos
• Detección de intrusiones: detección de archivos modificados, vigilancia de la integridad del sistema

Lo que revela: el 80 % de los servidores auditados no tienen fail2ban o lo tienen mal configurado, lo que permite miles de intentos de conexión SSH al día. La ausencia de copias de seguridad probadas = riesgo de pérdida total de datos en caso de fallo del disco o de ransomware.

Impacto medible: hardening completo = reducción del 95 % de los intentos de intrusión (logs de fail2ban) + garantía de restauración en < 2 h en caso de incidente grave.

7. Observabilidad y monitorización

Lo que implemento:

• Análisis de logs: errores de PHP, errores de Nginx, slow queries de MySQL, errores del sistema
• Métricas del servidor: CPU, RAM, disco, red, swap
• Alertas básicas: email/SMS si la CPU supera el 90 % durante 5 min, el disco supera el 85 % o un servicio se cae
• Herramientas: Netdata (ligera, gratuita) o New Relic (si hay presupuesto)
• Panel sencillo: un vistazo basta para ver la salud del servidor

Impacto: detección proactiva: recibes una alerta 10 minutos antes de que el servidor se caiga, en lugar de descubrir el problema por clientes descontentos. Reducción del MTTR (Mean Time To Repair) de 2 horas a 15 minutos.

Mi metodología completa

Fase 1: acceso y análisis preliminar (30 min)

Acceso:

• Conexión SSH (clave pública proporcionada) o acceso al panel de OVH/Plesk/ISPConfig
• Acceso de lectura a los logs (/var/log/nginx, /var/log/php-fpm, /var/log/mysql)
• Credenciales de MySQL de solo lectura para analizar las slow queries

Recopilación inicial:

• Inventario: versiones de PHP, MySQL, del sistema y del servidor web
• Estadísticas: uptime, load average, uso actual de CPU/RAM/disco
• Lectura rápida de los logs: detección de errores recurrentes

Fase 2: pruebas de rendimiento y de carga (1 h)

Mediciones de referencia:

• TTFB desde 3 ubicaciones diferentes (Europa, EE. UU., Asia) con curl/webpagetest
• Prueba de carga: simulación de 10, 50 y 100 usuarios simultáneos con Apache Bench o k6
• Profiling de PHP: activación de Xdebug o Blackfire para identificar las funciones lentas
• Análisis de MySQL: top 20 de consultas lentas con pt-query-digest (Percona Toolkit)

Identificación de los cuellos de botella: la prueba de carga revela exactamente dónde falla: ¿es PHP-FPM el que se satura? ¿MySQL el que se bloquea? ¿La RAM la que recurre al swap?

Fase 3: análisis de seguridad (45 min)

Escaneo de vulnerabilidades:

• Prueba SSL: ssllabs.com, testssl.sh para identificar las debilidades de TLS
• Escaneo de puertos abiertos: nmap para detectar los servicios expuestos innecesarios
• Verificación de CVE: versiones obsoletas de PHP/MySQL con vulnerabilidades conocidas
• Auditoría de archivos: archivos con permisos 777, posibles scripts backdoor

Revisión de la configuración:

• Análisis de /etc/ssh/sshd_config, reglas del firewall, jails de fail2ban
• Verificación de la existencia y la validez de las copias de seguridad

Fase 4: análisis de las configuraciones (1 h)

Análisis a fondo de las configuraciones:

• Nginx/Apache: lectura línea por línea de los archivos de configuración + benchmarks
• PHP-FPM: cálculo de la memoria total consumida (pm.max_children * memory_limit) frente a la RAM disponible
• MySQL: análisis de my.cnf, recomendaciones de MySQLTuner
• Sistema: configuración de los límites (ulimit), swap, parámetros del kernel

Fase 5: redacción del informe (1-2 h)

Estructura del informe:

1. Resumen ejecutivo (2 páginas)

• Los 3 problemas críticos identificados
• Impacto estimado en el negocio (p. ej.: pérdida del 15 % del tráfico SEO, 25 % de visitantes que abandonan)
• Presupuesto de correcciones: 0-500 € (configuración), 500-1.500 € (optimizaciones complejas), > 1.500 € (migración/ampliación de hardware)

2. Diagnósticos detallados (5-10 páginas)

• Cada problema documentado con capturas de pantalla, extractos de logs y métricas
• Explicación técnica accesible (sin jerga innecesaria)
• Gravedad: Crítico / Importante / Oportunidad

3. Plan de acción priorizado (2-3 páginas) Tabla: Acción | Impacto estimado | Complejidad | Tiempo | Costo

Ejemplo:

• Aumentar pm.max_children de 5 a 30 | Reducción del 70 % de los errores 502 | Baja | 10 min | Incluido
• Añadir 3 índices MySQL en la tabla orders | Consultas 50 veces más rápidas | Media | 1 h | Incluido
• Migrar a un servidor de 8 GB de RAM | Soporta 3 veces más carga | Alta | 4 h | 150 € de migración

4. Recomendaciones a largo plazo

• Plan de monitorización continua
• Frecuencia de actualización recomendada
• Hoja de ruta de mejoras a 6-12 meses

Caso real de cliente: tienda online con WooCommerce

Contexto inicial

Cliente: tienda online especializada en productos artesanales, 500-800 visitantes/día, 5000 productos, ticket medio de 85 €.

Infraestructura:

• VPS OVH Comfort (4 vCPU, 4 GB de RAM)
• Ubuntu 20.04, Nginx 1.18, PHP 7.4, MySQL 5.7
• WordPress 6.1 + WooCommerce 7.5 + 15 plugins activos

Síntomas reportados

• Picos de lentitud todos los días entre las 14:00 y las 16:00 (pausa del almuerzo = tráfico máximo)
• Errores 502 Bad Gateway 2-3 veces al día que obligaban a reiniciar PHP-FPM
• Páginas de producto que tardaban 6-8 segundos en cargar
• Google Search Console marcaba "Poor" en el 70 % de las páginas (LCP > 4 s)
• Tasa de rebote que pasó del 45 % al 62 % en 3 meses
• Pérdida estimada: 200-300 € al día en ventas perdidas

Diagnósticos de la auditoría (2 h 30 min)

1. PHP-FPM: configuración catastrófica

pm = dynamic
pm.max_children = 5 ATTENTION: (CRITIQUE)
pm.start_servers = 2
memory_limit = 128M

Cálculo: 5 procesos hijos × 128 MB = 640 MB como máximo para PHP, cuando hay 4 GB de RAM disponibles → a partir de 6 solicitudes simultáneas, se ponen en cola → timeout 502

2. MySQL: consultas lentas e índices que faltan

• 847 consultas de > 2 segundos en las últimas 24 h
• Consulta sobre wp_postmeta sin índice: 3,8 s para filtrar por meta_key
• innodb_buffer_pool_size = 128M (valor por defecto) con una base de datos de 2,1 GB

3. Opcache de PHP: desactivado

• PHP recompilaba todos los archivos de WordPress/WooCommerce en cada solicitud
• Carga de CPU innecesaria multiplicada por 8-10

4. Sin caché de aplicación

• Ningún plugin de caché HTML (WP Super Cache, W3 Total Cache)
• Cada página se recalculaba en cada visita, incluso para los visitantes no conectados

5. Seguridad débil

• Fail2ban no instalado: 3200 intentos de inicio de sesión SSH al día
• PHP 7.4: 12 CVE críticas sin parchear (PHP 8.1 disponible)

Correcciones aplicadas (3 h)

PHP-FPM (15 min)

pm.max_children = 30 (4GB RAM / 130MB par enfant)
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 15
pm.max_requests = 500

Opcache (5 min)

opcache.memory_consumption = 256
opcache.interned_strings_buffer = 16
opcache.max_accelerated_files = 10000
opcache.validate_timestamps = 0 (prod)
opcache.enable_cli = 1

MySQL (45 min)

-- Ajout index manquant
ALTER TABLE wp_postmeta ADD INDEX meta_key_value (meta_key, meta_value(20));
-- Configuration
innodb_buffer_pool_size = 2G (50% de la RAM)
max_connections = 200
query_cache_size = 0 (inutile MySQL 5.7+)

Caché de aplicación (30 min)

• Instalación de WP Rocket (licencia del cliente)
• Configuración: caché HTML, minificación de CSS/JS, lazy loading de imágenes
• Generación de la caché para las 500 páginas principales

Seguridad (1 h)

• Actualización de PHP 7.4 → 8.1
• Instalación de fail2ban con jails para SSH + HTTP
• Hardening de SSH: root desactivado, solo claves
• Copias de seguridad automáticas diarias en S3

Resultados medidos (7 días después)

Rendimiento:

• TTFB: ~~3,2 s~~ → 0,4 s (-87 %)
• LCP: ~~6,1 s~~ → 2,0 s (-67 %)
• Página de producto: ~~7,2 s~~ → 1,8 s (-75 %)
• Core Web Vitals: ~~12 % Good~~ → 89 % Good

Estabilidad:

• Errores 502: ~~2-3/día~~ → 0 en 7 días
• Load average: ~~4,5~~ → 0,8 (con 4 CPU)
• RAM utilizada: ~~92 %~~ → 65 %

Negocio:

• Tasa de rebote: ~~62 %~~ → 48 % (-14 puntos)
• Tiempo en el sitio: +22 %
• Conversiones: +18 % (calculado sobre 7 días frente a la semana anterior)
• Estimación: +280 € al día de facturación, es decir, +8.400 € al mes

Seguridad:

• Intentos SSH bloqueados: 3200/día → 0 (IP bloqueadas automáticamente)
• Vulnerabilidades CVE: ~~12 críticas~~ → 0

Costo total: auditoría (490 €) + ejecución (350 €) + licencia de WP Rocket (59 €/año) = 899 € sin IVA ROI: amortizado en 3 días de facturación adicional

Auditoría de servidor frente a otros tipos de auditorías

Es importante distinguir bien los distintos tipos de auditorías web, porque no cubren los mismos aspectos:

Mi consejo: si tu sitio va lento, empieza siempre por la auditoría de servidor. No sirve de nada optimizar tus imágenes si tu TTFB es de 4 segundos por un PHP-FPM mal configurado.

Checklist: ¿necesitas una auditoría de servidor?

Responde con sinceridad a las siguientes preguntas. Si marcas 3 casillas o más, se recomienda encarecidamente una auditoría de servidor.

• [ ] Mi sitio tarda más de 3 segundos en cargar con una buena conexión
• [ ] Tengo errores 502, 504 o 500 al menos una vez por semana
• [ ] Mi servidor necesita un reinicio manual al menos una vez al mes
• [ ] No sé cuál es el valor de pm.max_children de mi PHP-FPM
• [ ] Mi sitio se ralentiza mucho cuando tengo más de 50 visitantes simultáneos
• [ ] Nunca he optimizado mi base de datos MySQL
• [ ] Mi certificado SSL tiene una calificación < A en SSL Labs
• [ ] No he actualizado el sistema ni PHP desde hace más de 6 meses
• [ ] No tengo un sistema de copias de seguridad automáticas probado
• [ ] Mi proveedor de hosting ya me ha contactado por "uso excesivo de recursos"
• [ ] Google Search Console indica "Poor" en mis Core Web Vitals
• [ ] Mi tasa de rebote ha aumentado más de un 10 % en los últimos meses sin motivo aparente

Puntuación:

• 0-2 marcas: tu servidor parece estar bien, pero se recomienda igualmente una revisión preventiva cada 12-18 meses
• 3-5 marcas: auditoría aconsejable en 1-2 meses; probablemente tengas quick wins fáciles
• 6 o más marcas: auditoría urgente; probablemente estés perdiendo clientes y facturación cada día

Entregables y desarrollo

Lo que recibes

1. Informe de auditoría completo (PDF de 15-25 páginas)

• Resumen ejecutivo con los 3 problemas críticos principales
• Diagnósticos detallados con capturas de pantalla y extractos de logs
• Plan de acción priorizado por impacto/complejidad
• Recomendaciones a largo plazo

2. Archivos de configuración optimizados

• Configuraciones de Nginx/Apache comentadas y listas para desplegar
• Pool de PHP-FPM dimensionado para tu servidor
• Archivo my.cnf de MySQL optimizado
• Scripts básicos de monitorización y alertas

3. Documentación de procedimientos

• Checklist para desplegar las correcciones
• Guía de rollback en caso de problema
• Procedimiento de restauración de copias de seguridad

4. Seguimiento posterior a la intervención (opcional)

• Acceso al panel de monitorización durante 30 días
• Soporte por email durante 7 días para tus preguntas
• Sesión de formación de 30 min (configuración, lectura de las métricas)

Desarrollo típico

D0: primer contacto

• Reunión telefónica o por videollamada de 15 min para entender tus problemas
• Envío de un cuestionario técnico previo
• Presupuesto en 24 h

D+1 a D+2: accesos y preparación

• Creación de los accesos SSH/panel
• Instalación de herramientas de monitorización no intrusivas, si las aceptas
• Recopilación de los logs y de las métricas de referencia

D+3: auditoría (2-4 horas)

• Análisis en profundidad de todas las capas (red, servidor, PHP, MySQL, seguridad)
• Pruebas de carga para identificar los límites
• Documentación de los hallazgos en tiempo real

D+4 a D+5: redacción y presentación

• Redacción del informe completo
• Videollamada de 30-45 min para presentar los hallazgos y las recomendaciones
• Respuestas a tus preguntas técnicas

D+6 (opcional): ejecución de las correcciones

• Copia de seguridad completa del sistema antes de la intervención
• Aplicación de las optimizaciones por orden de prioridad
• Pruebas de no regresión después de cada cambio
• Mediciones posteriores a la intervención: verificación de que se alcanzan los objetivos

D+7: validación y cierre

• Informe de validación con métricas de antes y después
• Transferencia de conocimientos y formación rápida
• Documentación final + soporte durante 7 días

Resultados típicos tras la auditoría + optimización

Sobre la base de más de 40 auditorías de servidores realizadas desde 2020, estas son las mejoras medias observadas:

Rendimiento

• TTFB reducido entre un 30 y un 70 %: de 1,5-3 s a 0,3-0,8 s de media
• LCP mejorado en un 40-60 %: la mayoría de los sitios pasan de "Poor" a "Good" (< 2,5 s)
• Capacidad de carga multiplicada por 3-5: un servidor que se caía con 30 visitantes simultáneos ahora soporta 100-150
• Desaparición de los errores 5xx: el 90 % de los sitios ya no tienen ningún error 502/504 tras la optimización

Seguridad

• Reducción de más del 95 % de los intentos de intrusión gracias a fail2ban
• Superficie de ataque reducida: cierre de los puertos innecesarios, actualizaciones de seguridad aplicadas
• Calificación SSL que pasa de B/C a A+ gracias al hardening de TLS
• Cumplimiento reforzado: RGPD (cifrado, copias de seguridad), PCI DSS (si es un e-commerce)

Costos

• 30-50 % de ahorro en infraestructura: a menudo evita una costosa ampliación del servidor
• Reducción del 70-80 % del tiempo de mantenimiento: menos apagar incendios, monitorización proactiva
• ROI medio: 3-6 meses para un e-commerce (gracias al aumento de las conversiones)

SEO y conversión

• Mejora del tráfico orgánico del 15-30 % gracias a las Core Web Vitals (factor de posicionamiento de Google)
• Bajada de la tasa de rebote de 10-20 puntos: los visitantes ya no se van por la lentitud
• Aumento de la tasa de conversión del 10-25 %: un sitio rápido convierte mejor

Entornos cubiertos

Sistemas operativos

• Ubuntu 18.04, 20.04, 22.04, 24.04 LTS
• Debian 10, 11, 12
• Otras distribuciones Linux bajo demanda (CentOS, Rocky Linux, Alpine)

Proveedores de hosting e infraestructuras

• OVH / OVHcloud (VPS, Dedicated, Public Cloud)
• Scaleway (Instances, Elastic Metal)
• Contabo (VPS, Dedicated)
• Hetzner (Cloud, Dedicated)
• DigitalOcean, Linode, Vultr
• Servidores dedicados on-premise

Paneles de administración

• Plesk Obsidian
• ISPConfig 3.x
• cPanel/WHM (menos experiencia, pero factible)
• Configuración manual (sin panel): la opción preferida para un rendimiento máximo

Servidores web

• Nginx 1.18+ (recomendado por su rendimiento)
• Apache 2.4+ con MPM Event o Worker
• OpenLiteSpeed (bajo demanda)
• Configuraciones híbridas (Nginx como proxy inverso + Apache como backend)

PHP

• PHP 7.4, 8.0, 8.1, 8.2, 8.3 (todas las versiones FPM)
• Soporte de varias versiones de PHP simultáneas
• Extensiones: opcache, APCu, Redis, Memcached, imagick, etc.

Bases de datos

• MySQL 5.7, 8.0+
• MariaDB 10.3, 10.5, 10.6, 10.11+
• PostgreSQL (bajo demanda, menos experiencia que con MySQL)

Aplicaciones web habituales

• WordPress / WooCommerce (80 % de mi experiencia)
• Magento 2.x
• PrestaShop 1.7, 8.x
• Drupal 9, 10
• Laravel, Symfony, CodeIgniter (frameworks PHP)
• Aplicaciones PHP a medida

Precios y plazos

Modalidades de auditoría

Auditoría Esencial – 390 € sin IVA

• Servidor sencillo: 1 sitio, stack estándar (Nginx/Apache + PHP + MySQL)
• 2-3 h de análisis
• Informe de 10-15 páginas con plan de acción priorizado
• Archivos de configuración optimizados incluidos
• Ideal para: sitio web corporativo, blog, pequeña tienda online (< 1.000 visitantes/día)

Auditoría Avanzada – 690 € sin IVA

• Servidor complejo: varios sitios, configuraciones personalizadas, tráfico elevado
• 4-6 h de análisis en profundidad
• Informe de 20-30 páginas + pruebas de carga + profiling de la aplicación
• Recomendaciones de arquitectura (Redis, CDN, balanceo de carga)
• Presentación de los hallazgos por videollamada (1 h)
• Ideal para: e-commerce mediano/grande, SaaS, aplicaciones de gestión

Auditoría + Ejecución – Con presupuesto (normalmente 900-1.500 € sin IVA)

• Auditoría Avanzada + aplico yo mismo las correcciones
• Copia de seguridad completa antes de la intervención
• Pruebas de no regresión
• Mediciones de antes y después con informe de validación
• Soporte durante 7 días después de la intervención
• Ideal si: no tienes conocimientos de sistemas en tu equipo

Auditoría Urgente (< 24 h) – Tarifa × 1,5

• Intervención en 24 h (días hábiles)
• Informe exprés en 48 h
• Ideal para: crisis en curso, sitio caído, hackeo reciente

Opciones complementarias

• Sesión de formación (1 h): +150 € sin IVA
  • Lectura de las métricas, uso de la monitorización, mantenimiento preventivo
• Soporte de mantenimiento mensual: desde 200 € sin IVA/mes
  • Actualizaciones de seguridad mensuales
  • Monitorización 24/7 con alertas
  • Intervenciones correctivas incluidas (hasta 2 h/mes)
• Auditoría de seguimiento (6 meses después): -50 % sobre la tarifa inicial
  • Verificación de que las optimizaciones se mantienen en el tiempo
  • Ajustes si cambia el tráfico

Plazos estándar

• Presupuesto: en 24 h tras la reunión inicial
• Accesos y preparación: D+1 a D+2
• Auditoría: D+3 (2-4 h de trabajo concentrado)
• Entrega del informe: D+4 a D+5
• Ejecución (si se contrata la opción): D+6
• Validación final: D+7

Plazo total: 7 días hábiles de media, 3-4 días en caso de urgencia.

Lo que incluyen todas las tarifas

Análisis completo de las 7 capas (red, servidor, PHP, MySQL, seguridad, rendimiento, monitorización) Informe PDF detallado con capturas y recomendaciones aplicables Archivos de configuración optimizados listos para desplegar Presentación de los hallazgos por videollamada de 30 min (modalidad Avanzada y superiores) 1 ronda de preguntas y respuestas por email tras la entrega

Formas de pago

• Transferencia bancaria (IBAN indicado en la factura)
• Tarjeta bancaria a través de Stripe (enlace de pago seguro)
• PayPal (empresas francesas)

Condiciones: 50 % al hacer el pedido (tras aceptar el presupuesto), 50 % a la entrega del informe.

Preguntas frecuentes

¿Qué cubre exactamente la auditoría de servidor web?

La auditoría analiza 7 capas técnicas: protocolo de red (TLS/HTTP2), configuración del servidor web (Nginx/Apache), optimización de PHP-FPM (pm.*, opcache), base de datos MySQL (consultas lentas, índices que faltan), seguridad del sistema (fail2ban, firewall, actualizaciones), rendimiento de la aplicación (TTFB, Core Web Vitals) y monitorización (logs, métricas, alertas). Recibes un informe detallado con un plan de acción priorizado.

¿Puedes corregir los problemas encontrados o solo identificarlos?

Ambas cosas son posibles. Las modalidades "Auditoría Esencial" y "Avanzada" identifican los problemas y proporcionan los archivos de configuración optimizados que tu equipo técnico puede desplegar. La modalidad "Auditoría + Ejecución" incluye la aplicación de las correcciones por mi parte, con copia de seguridad previa, pruebas de no regresión y mediciones de antes y después. Es la opción recomendada si no tienes un administrador de sistemas en tu equipo.

¿Cuáles son los plazos y el costo de una auditoría?

Auditoría básica desde 390 € sin IVA para un servidor sencillo, realizada en 7 días hábiles (urgencia en 24 h posible con un recargo). La modalidad "Auditoría + Ejecución" se presupuesta según la complejidad (normalmente 900-1.500 € sin IVA). Una reunión inicial gratuita de 15 min permite elaborar un presupuesto preciso en 24 h.

¿Tengo que detener mi sitio durante la auditoría?

No, la auditoría no es intrusiva. El análisis se hace principalmente por SSH en modo lectura (logs, configuraciones, métricas). Las pruebas de carga se hacen de acuerdo contigo y pueden programarse en horas de poco tráfico si lo prefieres. Solo la ejecución de las correcciones (modalidad opcional) puede requerir 2-5 minutos de indisponibilidad para reiniciar servicios (PHP-FPM, MySQL), algo que se planifica con antelación.

Mi servidor está alojado en OVH/Scaleway/otro proveedor, ¿es un problema?

En absoluto. Trabajo con frecuencia con OVH, Scaleway, Hetzner, Contabo, DigitalOcean y otros proveedores de hosting estándar. La auditoría se realiza independientemente del proveedor, siempre que tenga acceso SSH o al panel (Plesk, ISPConfig). Si tu proveedor es muy específico (p. ej.: hosting gestionado en AWS con restricciones), una reunión previa permitirá validar la viabilidad.

¿Qué pasa si encuentras fallos de seguridad críticos?

Te aviso inmediatamente (incluso antes de terminar la auditoría completa) si detecto una vulnerabilidad crítica explotable activamente (backdoor, versión de PHP con una CVE crítica explotada en la práctica, servidor completamente abierto). Después, el informe incluye un plan de acción priorizado con las correcciones urgentes al principio de la lista. Con la modalidad "Auditoría + Ejecución", puedo aplicar los parches de seguridad de forma prioritaria en cuanto se identifican.

¿La auditoría cubre la optimización del código de mi aplicación?

La auditoría de servidor se centra en la infraestructura y la configuración del sistema (servidor, PHP, MySQL). Puedo identificar que una página hace 150 consultas SQL o que ciertas funciones PHP son lentas (mediante profiling), pero la optimización detallada del código de la aplicación (refactorización, reescritura de consultas complejas) corresponde a una auditoría de aplicación específica. Sin embargo, el 80 % de los problemas de rendimiento provienen de la configuración del servidor, por lo que la auditoría resuelve la mayoría de los casos.

¿Ofreces una garantía de resultados?

Garantizo que el informe contendrá recomendaciones aplicables y medibles. En la modalidad "Auditoría + Ejecución", me comprometo con objetivos cuantificados definidos juntos de antemano (p. ej.: TTFB < 400 ms, 0 errores 502 durante 7 días, Core Web Vitals "Good" en más del 80 % de las páginas). Si los objetivos no se alcanzan tras la intervención, retomo la optimización sin costo adicional hasta que quedes satisfecho.

¿Puedo obtener un ejemplo de informe de auditoría?

Sí, puedo enviarte por email un informe anonimizado (datos del cliente ocultos) si lo solicitas, lo que te dará una idea precisa del nivel de detalle y del formato. Escríbeme a [votre email] con el asunto "Ejemplo de informe de auditoría".

¿Ofreces seguimiento o mantenimiento después de la auditoría?

Sí, hay varias opciones:

• Soporte posterior a la auditoría incluido: 7 días de preguntas y respuestas por email tras la entrega
• Auditoría de seguimiento a los 6 meses: -50 % sobre la tarifa inicial para verificar que todo se mantiene en el tiempo
• Mantenimiento mensual: desde 200 €/mes, con actualizaciones de seguridad, monitorización 24/7 e intervenciones correctivas (hasta 2 h/mes)

Mi sitio funciona con WordPress/Shopify/otro CMS, ¿cambia algo?

La auditoría de servidor es independiente del CMS, ya que se centra en la capa del sistema (Linux, Nginx, PHP, MySQL). Sin embargo, mi amplia experiencia con WordPress/WooCommerce (80 % de mis auditorías) me permite ir más allá: puedo auditar los plugins problemáticos, optimizar la base de datos de WP (wp_options, transients), configurar una caché de objetos (Redis), etc. Para Shopify alojado, la auditoría de servidor no es aplicable (infraestructura gestionada por Shopify), pero puedo auditar las apps de Shopify a medida si están alojadas en tu servidor.

¿Qué accesos necesitas a mi servidor?

Mínimo necesario:

• Acceso SSH (cuenta de usuario con sudo, o root si lo aceptas) mediante una clave pública que yo te proporciono
• Acceso de lectura a los logs (/var/log/nginx, /var/log/php-fpm, /var/log/mysql)
• Credenciales de MySQL de solo lectura para analizar las slow queries

Opcional (pero recomendado):

• Acceso al panel (Plesk, ISPConfig) si existe
• Credenciales del CMS (administrador de WordPress) para probar en condiciones reales
• Acceso a Google Search Console / Analytics para correlacionar con las métricas de negocio

Seguridad: todos los accesos proporcionados se eliminan inmediatamente después de la auditoría (en un plazo máximo de 48 h). Se puede firmar un acuerdo de confidencialidad (NDA) si lo solicitas.

Si buscas soluciones complementarias, consulta también:

• Auditoría de seguridad web: enfoque en la aplicación (vulnerabilidades XSS/CSRF/SQLi, plugins obsoletos, cumplimiento del RGPD)
• Reparación de sitios hackeados: intervención de urgencia tras un hackeo (limpieza de backdoors, restauración)
• Optimización de las Core Web Vitals: mejora de LCP/FID/CLS en el front-end
• Optimización de la velocidad web: optimización global (front-end + back-end)
• Reparación y optimización de sitios web: visión general de mis servicios de reparación
• Rendimiento y velocidad: recursos y guías sobre optimización web
• Seguridad y cumplimiento normativo: centro de recursos de seguridad (RGPD, SSL, copias de seguridad)

¿Listo para impulsar el rendimiento y la seguridad de tu servidor? Solicita tu auditoría gratuita